AWS でのデータウェアハウスとデータレイクの構築

データ ウェアハウス、データ レイク、レイクハウス。これらの言葉のどれにも少しでも共感できない場合は、あなたの仕事がデータに関連していないことは明らかです。 👨‍💻

しかし、今日ではすべてがデータに関連しているように思われるため、それはかなり非現実的な前提になります。あるいは、企業のリーダーたちはそれを次のように表現します。

• データ中心およびデータドリブンのビジネス。
• いつでも、どこでも、とにかくデータを。

最も重要な資産

データはますます多くの企業にとって最も価値のある資産になっているようです。大企業は常に大量のデータを生成していたことを覚えています。毎月数テラバイトもの新しいデータが生成されると思います。それはまだ10〜15年前のことです。しかし今では、その量のデータを数日以内に簡単に生成できるようになりました。たとえそれが誰でも使うであろうコンテンツであっても、本当に必要なのかと疑問に思う人もいるでしょう。そして、はい、それは絶対に違います 😃。

内容のすべてが役に立つわけではありませんし、一度も役に立たない部分もあります。私は、企業が大量のデータを生成したが、読み込みが成功した後に役に立たなくなってしまう様子を最前線でよく目撃しました。

しかし、それはもう関係ありません。現在はクラウドにあるデータ ストレージは安価で、データ ソースは急激に増加しており、新しいサービスがシステムに導入されて 1 年後に何が必要になるかは、今日では誰も予測できません。その時点で、古いデータであっても価値のあるものになる可能性があります。

したがって、戦略はできるだけ多くのデータを保存することです。ただし、できるだけ効果的な形で。これにより、データを効果的に保存できるだけでなく、クエリ、再利用、変換、さらに分散することもできます。

AWS 内でこれを実現する 3 つのネイティブな方法を見てみましょう。

• Athena Database – クラウド内にデータレイクを作成する簡単な方法ですが、安価で効果的です。
• Redshift Database – データ ウェアハウスの本格的なクラウド バージョンであり、データの急激な増加に追いつけない現在のオンプレミス ソリューションの大部分を置き換える可能性があります。
• Databricks – データ レイクとデータ ウェアハウスを 1 つのソリューションに組み合わせ、さらにいくつかのボーナスを加えたもの。

AWS Athena によるデータレイク

データ レイクは、受信データを非構造化、半構造化、または構造化形式で高速に保存できる場所です。同時に、このデータは保存後に変更されることは想定されていません。代わりに、それらを可能な限りアトミックで不変にする必要があります。これだけが、後の段階での再利用の可能性を最大限に高めることができます。データ レイクへの最初のロード直後にデータのこのアトミック プロパティを失った場合、この失われた情報を再び取り戻す方法はありません。

AWS Athena は、 バックグラウンドで実行されているサーバークラスターを使用せず、S3 バケット上に直接ストレージを備えたデータベースです。つまり、非常に安価なデータレイクサービスです。寄木細工ファイルやカンマ区切り値 (CSV) ファイルなどの構造化ファイル形式により、データ構成が維持されます。 S3 バケットにはファイルが保持されており、プロセスがデータベースからデータを選択するたびに Athena がそれらのファイルを参照します。

Athena は、更新ステートメントなど、標準とみなされているさまざまな機能をサポートしていません。このため、Athena を非常にシンプルなオプションとして考える必要があります。一方で、それができないという理由だけでアトミック データ レイクの変更を防ぐのにも役立ちます 😐。

インデックス作成とパーティション化をサポートしているため、効果的な選択ステートメントの実行や、論理的に分離されたデータ チャンク (たとえば、日付列やキー列で区切られたデータ) の作成に使用できます。また、インフラストラクチャに新しいバケットを追加するのと同じくらい複雑であるため、水平方向に非常に簡単に拡張することもできます。

長所と短所

考慮すべき利点:

• Athena が安いという事実 (S3 バケットと使用ごとの SQL 使用コストのみで構成される) が、最も重要な利点となります。 AWS で手頃な価格のデータレイクを構築したい場合は、これが最適です。
• Athena はネイティブ サービスとして、データ視覚化のための Amazon QuickSight や永続的な構造化メタデータを作成するための AWS Glue データ カタログなど、他の便利な AWS サービスと簡単に統合できます。
• インフラストラクチャ全体を維持することなく、大量の構造化データまたは非構造化データに対してアドホック クエリを実行する場合に最適です。

考慮すべき欠点:

• Athena は、特にデータ レイクからデータをリクエストする方法を設計したデータ モデルの前提にクエリが従わない場合、複雑な選択クエリを高速に返すのに特に効果的ではありません。
• これにより、データ モデルの将来の潜在的な変更に対する柔軟性も低下します。
• Athena は、そのままでは追加の高度な機能をサポートしていないため、特定のものをサービスの一部にしたい場合は、それを最上位に実装する必要があります。
• より高度なプレゼンテーション層でデータレイクのデータを使用することが予想される場合、多くの場合、AWS Aurora や AWS Dynamo DB など、その目的により適した別のデータベース サービスと組み合わせることが唯一の選択肢になります。

目的と実際の使用例

高度なデータ ウェアハウスのような機能を持たない単純なデータレイクの作成がターゲットの場合は、Athena を選択してください。たとえば、データ レイク上で定期的に実行される本格的な高パフォーマンスの分析クエリが期待できない場合です。代わりに、データ ストレージを簡単に拡張できる不変データのプールを確保することが優先されます。

スペース不足について過度に心配する必要はもうありません。 S3 バケット ストレージのコストも、データ ライフ サイクル ポリシーを実装することでさらに削減できます。これは基本的に、さまざまなタイプの S3 バケット間でデータを移動することを意味し、取り込みの戻り時間は遅くなりますが、コストは低くなり、アーカイブの目的により重点が置かれています。

Athena の優れた機能は、SQL クエリの結果の一部であるデータで構成されるファイルを自動的に作成することです。その後、このファイルを取得して、あらゆる目的に使用できます。したがって、複数のステップでデータをさらに処理する多くの Lambda サービスがある場合には、これは良いオプションです。各ラムダの結果は、自動的に、後続の処理に備えた入力として構造化ファイル形式の結果になります。

Athena は、大量の生データがクラウド インフラストラクチャに送信され、読み込み時にそれを処理する必要がない場合に適したオプションです。つまり、必要なのは、理解しやすい構造のクラウド上の高速ストレージだけです。

別の使用例は、別のサービスのデータ アーカイブを目的とした専用スペースを作成することです。このような場合、Athena DB は、現時点では必要のないすべてのデータの安価なバックアップ場所になりますが、将来的には変更される可能性があります。この時点では、データを取り込んでさらに送信するだけです。

AWS Redshift によるデータウェアハウス

データ ウェアハウスは、データが非常に構造化された方法で保存される場所です。ロードと抽出が簡単です。その目的は、非常に複雑なクエリを多数実行し、複雑な結合を介して多くのテーブルを結合することです。既存のデータに対してさまざまな統計を計算するために、さまざまな分析関数が用意されています。最終的な目標は、既存のデータを活用して、今後のビジネスに活用できる将来予測や事実を抽出することです。

Redshift は本格的なデータ ウェアハウス システムです。水平方向および垂直方向に調整および拡張できるクラスター サーバーと、複雑なクエリを迅速に返すために最適化されたデータベース ストレージ システムを備えています。ただし、現在では Redshift をサーバーレス モードでも実行できます。 S3 などにはファイルがありません。これは、独自のストレージ形式を備えた標準のデータベース クラスター サーバーです。

すぐに使用できるパフォーマンス監視ツールが備わっており、ユースケースに合わせてパフォーマンスを微調整するために使用および監視できるカスタマイズ可能なダッシュボード メトリクスも備えています。管理には、別のダッシュボードからもアクセスできます。考えられるすべての機能と設定、およびそれらがクラスターに与える影響を理解するには、ある程度の努力が必要です。それでも、Oracle サーバーの管理は、オンプレミス ソリューションの場合ほど複雑ではありません。

Redshift にはさまざまな AWS 制限があり、日々の使用方法の境界を設定していますが (たとえば、1 つのデータベース クラスター内の同時アクティブ ユーザーまたはセッションの量に対するハード制限)、実際の操作は非常に高速に実行されるため、これらの制限をある程度回避することができます。

長所と短所

考慮すべき利点:

• 他のサービスと簡単に統合できる、ネイティブ AWS クラウド データ ウェアハウス サービス。
• 非常に異なるソース システムからのさまざまなタイプのデータ ソースを保存、監視、取り込むための中心的な場所。
• サーバーレス データ ウェアハウスを維持するためのインフラストラクチャなしで導入したいと思っていた場合でも、今ならそれが可能です。
• 高性能の分析とレポート作成のために最適化されています。データ レイク ソリューションとは異なり、すべての受信データを保存するための強力なリレーショナル データ モデルがあります。
• Redshift データベース エンジンは PostgreSQL を起源とし、他のデータベース システムとの高い互換性を保証します。
• S3 バケットとの間でデータをロードおよびアンロードするための非常に便利な COPY および UNLOAD ステートメント。

考慮すべき欠点:

• Redshift は、大量の同時アクティブ セッションをサポートしません。セッションは保留され、順番に処理されます。操作は非常に高速であるため、ほとんどの場合は問題になりませんが、多くのアクティブ ユーザーがいるシステムでは制限要因となります。
• Redshift は、成熟した Oracle システムで以前から知られていた多くの機能をサポートしていますが、それでも同じレベルには達していません。期待される機能の一部は存在しない可能性があります (DB トリガーなど)。または、Redshift は、非常に限定された形式 (具体化されたビューなど) でそれらをサポートします。
• より高度なカスタム データ処理ジョブが必要な場合は、それを最初から作成する必要があります。ほとんどの場合、Python または JavaScript コード言語を使用します。 Oracle システムの場合、これは PL/SQL ほど自然ではありません。Oracle システムでは、関数やプロシージャでも SQL クエリによく似た言語が使用されます。

目的と実際の使用例

Redshift は、これまでクラウドの外に存在していたさまざまなデータ ソースすべての中央ストアとして使用できます。これは、以前の Oracle データ ウェアハウス ソリューションの有効な代替品です。リレーショナル データベースでもあるため、Oracle からの移行も非常に簡単な操作です。

多くの場所に既存のデータ ウェアハウス ソリューションがあり、アプローチ、構造、またはデータ上で実行する事前定義された共通プロセスのセットの点であまり統一されていない場合、Redshift は最適な選択肢です。

これは、さまざまな場所や国のすべてのさまざまなデータ ウェアハウス システムを 1 つ屋根の下で統合する機会を提供するだけです。データを安全に保ち、必要な人だけがアクセスできるように、データを国ごとに分離することもできます。しかし同時に、すべての企業データをカバーする統合ウェアハウス ソリューションを構築できるようになります。

別のケースとしては、セルフサービスの広範なサポートを備えたデータ ウェアハウス プラットフォームを構築することが目標である場合が考えられます。個々のシステムユーザーが構築できる一連の処理として理解できます。しかし同時に、それらは共通のプラットフォーム ソリューションの一部ではありません。つまり、そのようなサービスは、作成者または作成者によって定義された人々のグループのみがアクセスできる状態になります。他のユーザーにはまったく影響しません。

Datalake と Datawarehouse の比較を確認してください。

AWS 上の Databricks による Lakehouse

Lakehouse は、実際には Databricks サービスに関連する用語です。ネイティブの AWS サービスではない場合でも、AWS エコシステム内で非常にうまく機能し、他の AWS サービスに接続して統合するためのさまざまなオプションを提供します。

Databricks は、 (以前は) 非常に個別だった領域を接続することを目的としています。

• 非構造化データ、半構造化データ、構造化データをデータ レイク ストレージに保存するためのソリューション。
• データ ウェアハウスの構造化されたクエリ データに迅速にアクセスできるソリューション (デルタ レイクとも呼ばれます)。
• データレイク上での分析と機械学習コンピューティングをサポートするソリューション。
• 集中管理とすぐに使用できるツールを備えた上記のすべての領域のデータ ガバナンスにより、さまざまなタイプの開発者とユーザーの生産性をサポートします。

これは、データ エンジニア、SQL 開発者、機械学習データ サイエンティストが同時に使用できる共通のプラットフォームです。各グループには、タスクを達成するために使用できるツールのセットもあります。

そこで Databricks は何でも屋のソリューションを目指し、データ レイクとデータ ウェアハウスの利点を 1 つのソリューションに統合しようとしています。さらに、構築済みのデータ ストア上で機械学習モデルを直接テストおよび実行するためのツールも提供します。

長所と短所

考慮すべき利点:

• Databricks は、拡張性の高いデータ プラットフォームです。ワークロードのサイズに応じて拡張され、さらに自動的に拡張されます。
• データ サイエンティスト、データ エンジニア、ビジネス アナリストのための共同作業環境です。これらすべてを同じスペースで一緒に実行できることは、大きな利点です。組織的な観点からだけでなく、別の環境に必要な別のコストも節約できます。
• AWS Databricks は、Amazon S3、Amazon Redshift、 Amazon EMR などの他の AWS サービスとシームレスに統合します。これにより、ユーザーはサービス間でデータを簡単に転送し、AWS クラウド サービスをすべて利用できるようになります。

考慮すべき欠点:

• Databricks は、特にビッグ データ処理に慣れていないユーザーにとって、セットアップと管理が複雑になる場合があります。プラットフォームを最大限に活用するには、かなりのレベルの技術的専門知識が必要です。
• Databricks は従量課金制の料金モデルという点では費用対効果が高いですが、大規模なデータ処理プロジェクトの場合は依然として高価になる可能性があります。特にユーザーがリソースをスケールアップする必要がある場合、プラットフォームの使用コストが急速に増加する可能性があります。
• Databricks はさまざまな事前構築されたツールとテンプレートを提供しますが、これはより多くのカスタマイズ オプションを必要とするユーザーにとって制限となる場合もあります。このプラットフォームは、ビッグ データ処理ワークフローに対する柔軟性と制御を必要とするユーザーには適していない可能性があります。

目的と実際の使用例

AWS Databricks は、非常に大量のデータを扱う大企業に最適です。ここでは、さまざまな外部システムからさまざまなデータ ソースをロードしてコンテキスト化するという要件をカバーできます。

多くの場合、要件はリアルタイムでデータを提供することです。これは、データがソース システムに表示された時点から、プロセスが即座に処理を開始し、即時または最小限の遅延でデータを処理して Databricks に保存することを意味します。遅延が 1 分を超える場合は、ほぼリアルタイムの処理とみなされます。いずれの場合も、多くの場合、両方のシナリオが Databricks プラットフォームで実現可能です。これは主に、他のさまざまな AWS ネイティブ サービスに接続する大量のアダプターとリアルタイム インターフェイスによるものです。

Databricks は、 Informatica ETL システム とも簡単に統合できます。組織システムが既に Informatica エコシステムを広範囲に使用している場合、Databricks はプラットフォームへの優れた互換性の追加のように見えます。

最後の言葉

データ量は指数関数的に増加し続けるため、それに効果的に対処できるソリューションがあることを知っておくのは良いことです。かつては管理と維持が悪夢のようでしたが、今では管理作業はほとんど必要ありません。チームはデータから価値を生み出すことに集中できます。

ニーズに応じて、対応できるサービスを選択してください。 AWS Databricks は、おそらく決定後に固執する必要があるものですが、他の代替手段、特にサーバーレス モードでは、たとえ機能が劣っていても、非常に柔軟です。後で別のソリューションに移行するのは非常に簡単です。