スケーラブルでコスト効率の高いレイクハウスデータプラットフォームの構築方法

過去10年間で、私たちは硬直的なデータウェアハウスから柔軟なデータレイクへ、そして最近では両者の長所を組み合わせることを約束するレイクハウスアーキテクチャへと移行してきました。

しかし、あるデータプラットフォーム世代から次の世代への移行は、予想以上に困難であることが証明されています。すでにこの道を歩んでいる人々は、古い設計パターンを新しいシステムに持ち込むことで、課題を発見し、過ちを繰り返しています。

複数の組織が現代のデータプラットフォームを設計し拡張するのを支援してきた経験から、成功はツールではなく規律に依存することを見てきました。この記事は実用的なガイドです。効果的に移行する方法、避けるべきこと、技術的選択を測定可能なビジネス価値に変換する方法について説明します。

ビッグデータの純粋な歴史がもはや役に立たない理由

振り返ると、ビッグデータムーブメントは無制限のストレージと終わりのない実験という夢から始まりました。2010年代半ば頃、企業はあらゆるログ、クリック、トランザクションを収集し始め、量だけで洞察がもたらされると確信していました。実際には、この信念はより多くの複雑さを生み出しただけでした。データレイクはウェアハウスの流行的な後継者として登場しましたが、そのほとんどはすぐにデータスワンプとなり、情報は簡単に入るものの、使用可能な形で戻ってくることはほとんどありませんでした。

2022年までに業界は成熟し、問題は変わり始めました。チームはもはやどれだけのデータを保存できるかではなく、すでに持っているものをどのように信頼し使用できるかを問うようになりました。今日の真の課題は容量ではなくガバナンスであり、取り込みではなく解釈です。

ここでの重要な教訓はシンプルです。より多くのデータを収集することが企業をデータドリブンにするわけではありません。本当に重要なのは、データを理解し、適切なガバナンスを維持し、効率的に使用することです。

すべてのデータセットの所有権を定義し、明確な保持と品質のポリシーを設定し、ビジネス上の意思決定を直接サポートするデータにエンジニアリングの努力を集中させることをお勧めします。この基盤がなければ、最も高度なレイクハウスでさえ、最終的には現代のスワンプになります。

転機としてのレイクハウス

レイクハウスの台頭は、まさにこの変化を反映しています。パフォーマンスと柔軟性のどちらかを選ぶのではなく、レイクハウスモデルは両方を組み合わせます。その中核では、DeltaやIcebergなどの形式で安価なクラウドストレージを使用し、メタデータとトランザクション保証で充実させています。その結果、レイクと同じくらい低コストで、クエリ時にはウェアハウスのように動作するシステムが生まれます。

これはビジネスリーダーにとって重要です。なぜなら、履歴データ用の安価なストレージとライブ分析用の高価なシステムの間の絶え間ないトレードオフがなくなるからです。私は常に、レイクハウスを他のすべてを置き換えるものとしてではなく、従来の分析と機械学習の両方を1つの環境で可能にする共有基盤として位置づけることを提案します。

レイクハウスでは、同じ環境がCFO向けのダッシュボード、顧客行動を予測する機械学習モデル、プロダクトアナリストからのアドホッククエリをサポートできます。データはシステム間で複製されなくなり、ガバナンスがシンプルになり、コスト最適化が自然に実現します。

データレイクハウス導入における構造とガバナンスの課題

企業が従来のデータウェアハウスやデータレイクから、より柔軟なレイクハウスアーキテクチャに移行する際、その移行はめったにスムーズではありません。多くのチームは、既存の構造を目的を再考することなく古いウェアハウスから新しい環境にコピーします。その結果、データサイロ、つまり断片化が発生します。データの1つのバージョンはウェアハウスに、別のバージョンはレイクに、3つ目はその中間のどこかに存在します。レイクハウス用のスキーマをゼロから再設計することでこれを回避してください。レガシーウェアハウスロジックではなく、アクセスパターンとコンシューマーのニーズに基づいてデータをモデル化してください。

もう1つの繰り返される問題は正規化です。これはどういう意味でしょうか?ウェアハウスは、数十の相互接続されたテーブルを持つ厳格で深く正規化された構造の上に構築されています。これらが直接レイクにコピーされると、すべてのクエリが多数の結合を必要とします。パフォーマンスが低下し、エンジニアはインフラストラクチャを非難し、プロジェクトは信頼性を失います。代わりに、パフォーマンスに役立つ場所で非正規化し、関連エンティティを近くに配置してシャッフルを最小化してください。パフォーマンス設計を後の最適化ではなく、データモデリングの一部として扱ってください。

ガバナンスと制御は重要です。データレイクでは、チームがファイルを直接操作するため、監視がほとんどないことがよくあります。ウェアハウスでは、行レベルのセキュリティ、ロールベースのアクセス、詳細な監査証跡などの厳格なルールが適用されます。レイクハウスは、説明責任を失うことなく開放性を確保することでバランスを取る必要があります。最初からロールベースのアクセスとリネージュトラッキングを実装する必要があります。ガバナンスは、プラットフォームとともに成長し、信頼の基盤となるときに最もうまく機能します。

パフォーマンスもスマートな設計に依存します。従来のウェアハウスは自動インデックス作成に依存していますが、レイクハウスでは、効率はパーティショニングまたはリキッドクラスタリング、キャッシング、分析に適したファイル形式の選択から生まれます。パーティショニング戦略とファイルレイアウトをアーキテクチャの第一級市民として扱うことをお勧めします。

コスト最適化はレイクハウスのもう1つの重要な約束ですが、自動的には実現しません。クラウドストレージは安価で、分析は必要に応じてスケールアップまたはダウンできますが、これらの利点は、不適切なデータ設計と制御されない成長によって相殺されることがよくあります。データセットのライフサイクルを積極的に管理し、未使用のコピーを削除する必要があります。このプロセスが無視されると、クラウドコストは時間の経過とともに静かに増加します。

第一のルールとしてのコスト最適化

レイクハウスアーキテクチャの主要な利点の1つであるため、コスト最適化に焦点を当てたいと思います。

レイクハウスアーキテクチャがコストを削減する主要な方法の1つは、シャッフル、つまりシステムまたは処理ノード間のデータの移動を最小化することです。これを実現するには、関連するエンティティが一緒に保存されるようにデータを常に設計してください。

すべてのデータを1か所に保持し、関連するエンティティを近くに保存することで、レイクハウスは過度の結合とデータ転送の必要性を排除します。分析を実行する場合、たとえば顧客分析用の機械学習モデルを構築する場合、システム間でコピーまたは移動することなく、履歴データと実際のトランザクションデータの両方を使用できます。

コスト最適化を可能にするもう1つの重要な原則は、ストレージとコンピューティングの分離です。データストレージとデータ処理は、実際の需要に基づいて独立してスケールします。大規模な固定容量システムを維持する代わりに、使用するリソースに対してのみ支払います。ストレージは安価でスケーラブルなままであり、コンピューティングパワーは必要に応じて増減できます。この柔軟性により、インフラストラクチャコストが低下し、データ操作がより効率的になります。常に小規模から始めて、自動スケーリングにその仕事をさせてください。予約容量にコミットする前に、使用状況を監視し、ワークロードパターンを理解してください。

自動スケーリングクラスターは、コストの制御をさらに支援します。機械学習ワークロードには、クラウド内のコンピューティングリソース、通常のコンピューターと同様のメモリと処理能力を持つ仮想マシンが必要です。過去には、企業は事前に物理サーバーを購入またはリースし、その固定容量でプロセスを実行していました。クラウドでは、実際の使用量、時間単位、リソース量に基づいてコンピューティングに支払います。最小限のクラスターサイズから始め、スケーリング動作を観察し、コストの暴走を防ぐために上限を設定することを強くお勧めします。

適切なアーキテクチャアプローチの選択

レイクハウスアーキテクチャについて話しましょう。多くの点で、その設計はデータモデルの構造化方法に依存します。最も一般的で効果的なアプローチは、レイヤー化、またはメダリオンアーキテクチャであり、各レイヤーは特定の目的を果たし、さまざまなタイプのユーザーとワークロードをサポートします。

— 最初のレイヤーは、しばしばrawまたはbronzeと呼ばれ、ソースデータの直接コピーです。主に技術的なニーズに対応し、必要に応じて迅速な再処理を可能にするために短期間のみ保持されます。一時的なストレージとして扱うべきです。

— 2番目のレイヤー、または正規化レイヤーには、クリーンで構造化されたデータが含まれ、ユーザーや注文などの他のテーブルと結合されることもあります。これは、機械学習モデルがよくトレーニングされる場所です。この段階でデータ検証とスキーマ適用を自動化することがベストプラクティスです。一貫性を維持することは、大量のデータを処理することよりも価値があります。

— 最終レイヤーは、goldレイヤーとして知られ、集約されたデータが存在する場所です。ダッシュボードやTableauやPower BIなどのBIツールは、通常このレイヤーに接続して、準備されたメトリックと視覚化にアクセスします。それでも、すべてを事前計算できるわけではありません。

各レイヤーには目的があり、一緒に機械学習とビジネスインテリジェンスの両方を繁栄させます。

レイヤー戦略を消費パターンと整合させる必要があります。データサイエンティストは通常silverレイヤーで作業し、経営陣はgoldレイヤーからの回答を期待します。柔軟性はレイクハウスの真の強みであり、複数の個別システムを構築および維持することなく、複数のオーディエンスにサービスを提供する能力です。

現場からの洞察

ゼロから設計するとしたら、業界が過去にデータにアプローチした方法とは異なることをいくつか行うでしょう。

以下は、実際の実装から学んだ教訓と、現在推奨していることです。

1. 小規模から始め、迅速に提供する

すべてを一度に移行することは常に最適ではありません。企業はしばしばテラバイトのデータを新しいシステムにリフトアンドシフトしようとしますが、誰も使用しないことに気付きます。より良い道は、レコメンデーションエンジン、ダイナミックプライシング、顧客維持モデルなど、明確なビジネス価値を提供する単一のユースケースから始めることです。その分野での成功は、信頼性とスケーリングの青写真の両方を提供します。

1. ビジネス要件を早期に変換する

ビジネス要件をできるだけ早く技術的要件に変換します。レポートが地域でフィルタリングする必要がある場合、その要件はストレージレベルで地域別のパーティショニングを意味します。アナリストがほぼリアルタイムの更新を期待する場合、それはインデックス作成またはキャッシングに関する決定を促進します。この変換がなければ、テクノロジーはビジネス目標から離れ、信頼は低下します。

1. テクノロジーを組織の能力に合わせる

常にテクノロジーを組織の能力に合わせます。強力なエンジニアリング文化を持つ企業は、オープンソースコンポーネントと最大限の制御を好むかもしれません。技術リソースが限られている企業は、アナリストにSQLインターフェースを公開するマネージドサービスの方が適しているかもしれません。普遍的な解決策はありません。重要なのは、野心を能力に合わせることです。

最後に、レイクハウスが単により良いレイクであるという仮定に挑戦します。実際には、それは異なるパラダイムです。レイクとウェアハウスの両方のいくつかの機能を継承していますが、すべてのユースケースの代替ではありません。たとえば、高頻度のトランザクションワークロードには、依然として専用システムが必要な場合があります。これらの境界を認識することで、失望を防ぎ、レイクハウスが真に優れている場所で使用されることを保証します。