データレイク vs. クラウドデータウェアハウス：データサイエンティストのための実践ガイド

データレイクは、低コストのクラウドオブジェクトストレージを使用して、構造化、半構造化、非構造化といった生のデータをネイティブ形式で保存する中央リポジトリです。データをロードする前に事前定義されたスキーマを強制するクラウドデータウェアハウスとは異なり、データレイクは読み取り時にのみ構造を適用するため、データサイエンティストやデータエンジニアは、事前の変換なしで多様なデータタイプを操作できる最大限の柔軟性を得られます。どちらのアーキテクチャもクラウドインフラストラクチャ上で動作しますが、大規模なデータの収集、処理、取得方法について、根本的に異なる課題に対応します。

このガイドは、ベンダーの売り込みではなく、実践的な意思決定フレームワークを必要としているデータサイエンティスト、データエンジニア、アナリティクスリーダー向けに作成されています。これを読めば、データレイクとクラウドデータウェアハウスの主な違い、データレイクハウスがそのギャップをどのように埋めるか、そして特定のワークロードに適したデータストレージアーキテクチャの選択方法を理解できます。

推奨事項のクイックサマリー

仕組みを詳しく説明する前に、ほとんどのチームが最初に必要とする実践的なガイダンスを紹介します。

主なニーズが、機械学習、データサイエンス、またはまだ定義されていない将来のアナリティクスのユースケース向けに、ペタバイト規模の生のマルチフォーマットデータを保存することである場合は、データレイクを選択してください。データレイクは、クラウドデータウェアハウスよりもギガバイトあたりのコストを抑えてスケーラビリティを提供し、取り込み前にスキーマを必要とせずにすべてのデータタイプをサポートします。

ワークロードが、構造化されたビジネスデータに対する高速で並行な SQL クエリ（ダッシュボード、財務レポート、顧客口座明細、運用アナリティクスなど、ストレージの柔軟性よりも低いクエリレイテンシと高い並行性が重視される分野）を中心に構成されている場合は、クラウドデータウェアハウスを選択してください。

組織が機械学習とビジネスインテリジェンス（BI）の両方のワークロードを実行しており、レイクとウェアハウス間のデータの重複を排除する統合プラットフォームを必要としている場合は、データレイクハウスを選択してください。レイクハウスは、レイクストレージ上で直接 ACID トランザクションサポートを提供するため、ほとんどのモダンなデータプラットフォームにとって実質的なデフォルトの選択肢となります。

データレイクとは？

データレイクは、分析に必要になるまで、すべてのデータ（構造化、半構造化、非構造化）を元の生の形式で保存するように設計された中央リポジトリです。データレイクは、従来のリレーショナルデータベースやデータウェアハウスでは経済的に対応できなかった、非構造化データストレージニーズの爆発的な増加に対処するために登場しました。

データレイクの決定的な特徴は、Extract, Load, Transform (ELT) 手法を使用してデータを即座に受け入れ、スキーマオンライト（書き込み時スキーマ適用）ではなくスキーマオンリード（読み取り時スキーマ適用）を適用することです。これにより、データエンジニアは、データのクエリ方法を事前に定義することなく、ログファイル、 JSON イベント、画像、動画、センサーストリーム、データベーステーブルを同じシステムに取り込むことができます。データサイエンティストは、どのような形式で届いたデータであっても、未処理の生のデータに直接アクセスできます。これは、特徴量エンジニアリングや機械学習モデルの開発に不可欠です。

クラウドデータレイクは通常、事実上無制限の容量を提供するオブジェクトストレージサービス（Amazon S3、Azure Data Lake Storage (ADLS)、Google Cloud Storage）上で動作します。データレイクは、固定された制限なしにペタバイト規模の情報を保存でき、ギガバイトあたりのコストは、レガシーなデータウェアハウスで使用される独自のストレージよりも大幅に低くなります。このギガバイトあたりの低コストでのスケーラビリティにより、データレイクは、データ量が主な懸念事項であるビッグデータストレージにとって実用的な選択肢となります。

データレイクは、構造化されたデータベースのエクスポート、 JSON や Parquet などの半構造化フォーマット、テキストコーパス、音声、画像などの完全な非構造化コンテンツなど、すべてのデータタイプをサポートします。この幅広さにより、取り込み時にはまだ定義されていないユースケースを含め、将来の分析のために生のデータを保持する必要があるあらゆる組織にとって、データレイクは自然なランディングゾーンとなります。

クラウドデータウェアハウスとリレーショナルデータベースの背景

クラウドデータウェアハウスは、構造化されたビジネス対応データに対する高並行性の SQL クエリに最適化された、管理型のアナリティクスデータベースです。リアルタイムで個々の行を挿入および更新するトランザクションワークロード向けに設計されたリレーショナルデータベースとは異なり、クラウドデータウェアハウスは、大量の履歴データをスキャンして集計、レポート、ダッシュボードを生成する分析ワークロード向けに構築されています。

クラウドデータウェアハウスはスキーマオンライトモデルを強制します。つまり、データをロードする前に、データをクレンジングし、型を定義し、事前定義されたスキーマに適合させる必要があります。この制約は、データウェアハウスの最大の強みであると同時に、最も重大な制限の要因でもあります。すべてのテーブルのすべての行が既知の構造に適合しているため、列指向ストレージやクエリ高速化技術（述語プッシュダウン、ゾーンマップ、結果キャッシュ）を積極的に適用でき、ビジネスユーザーやデータアナリストがダッシュボードに期待する1秒未満のクエリパフォーマンスを実現できます。

Amazon Redshift、Google BigQuery、Snowflake、Databricks Lakehouse などの主要なクラウドデータウェアハウスベンダーは、コンピューティングとストレージを分離しているため、クエリ容量を保存データとは無関係にスケーリングできます。このアーキテクチャは、何百人ものユーザーが競合することなく同時にクエリを実行する、高並行性のワークロードをサポートします。ビジネスインテリジェンス（BI）のユースケース（収益レポート、顧客口座明細、在庫アナリティクスなど）では、クエリパフォーマンスとデータの整合性が譲れないため、クラウドデータウェアハウスが依然として有力な選択肢となっています。

クラウドデータウェアハウスが苦手とするのは、リレーショナルモデルに適合しないデータタイプ（非構造化テキスト、生のセンサーストリーム、画像埋め込み、半構造化イベントログなど）です。これらのデータをウェアハウスにロードするには、大幅な変換作業が必要になり、スキーマに適合させるためにデータが破棄されたり近似されたりすることが多く、機械学習ワークロードが求める完全性が損なわれます。

データレイクのアーキテクチャとストレージソリューション

データレイクアーキテクチャ は通常、3つのゾーンに整理されており、それぞれが段階的に高くなるデータ品質とビジネスへの即応性を表しています。

Raw ゾーン（Bronze レイヤー）

Raw ゾーンは、外部のソースシステムから取り込まれたデータが最初に格納される領域です。データは、データベースのエクスポート、 API レスポンス、ストリーミングイベント、フラットファイルなどのネイティブ形式で到着し、最小限の変換でオブジェクトストレージに書き込まれます。目的は再現性（フィデリティ）です。元のレコードを保存することで、ダウンストリームのロジックが変更された場合に、パイプライン全体を最初から再実行できるようにします。メタデータ、ロード時のタイムスタンプ、ソース識別子が追加されますが、データ自体は変更されません。

Cleansed ゾーン（Silver レイヤー）

Cleansed ゾーンでは、生のデータが照合、マージされ、統一されたエンタープライズビューに適合されます。データ品質チェックが適用され、重複レコードが解決され、複数のソースからのデータが、顧客、取引、製品などの一貫したエンティティに結合されます。このレイヤーは、ダウンストリームの利用者に未処理の生のデータを公開することなく、探索的分析、アドホックレポート、データサイエンスの実験をサポートします。

Curated ゾーン（Gold レイヤー）

Curated ゾーンには、ダッシュボード、運用アナリティクス、機械学習モデルで利用できる、本番環境グレードのビジネスレベルの集計データが含まれています。このレイヤーのデータはすべての品質ゲートを通過しており、高パフォーマンスのクエリをサポートする、すぐに利用可能な構造（スタースキーマ、ワイドテーブル、事前集計されたメトリクスなど）に整理されています。Bronze、Silver、Gold を個別のパイプラインステージとして形式化する メダリオンアーキテクチャは、データレイクアーキテクチャを整理するために最も広く採用されているパターンです。

オブジェクトストレージは、これら3つのゾーンすべての基盤です。Apache Parquet や Apache ORC などのフォーマットは、ストレージフットプリントを削減し、分析スキャンを高速化する列指向エンコーディングを提供します。オープンフォーマットはデータを特定のベンダーの処理エンジンから切り離すため、コピーすることなく、複数のツールで同じファイルに対してクエリを実行できます。

データストレージのコストとスケーラビリティ

モダンなアーキテクチャではストレージとコンピューティングが分離されているため、データレイクとクラウドデータウェアハウスのコスト比較では、両方を個別に考慮する必要があります。

クラウドオブジェクトストレージ層でのデータレイクストレージは、独自のウェアハウスストレージよりも大幅に安価であり、生のギガバイトあたりの価格では桁違いに安くなることがよくあります。クエリの頻度が低い大量の生のデータや履歴データを保存する組織の場合、コールドストレージ層（Amazon S3 Glacier、Azure Archive）を使用すると、取得レイテンシは高くなりますが、コストをさらに削減できます。データレイクがデータウェアハウスよりも費用対効果が高いのは、まさにオブジェクトストレージがクエリパフォーマンスではなく、耐久性とスケールを目的として設計されているためです。

クラウドデータウェアハウスは、クエリごと、またはコンピューティングユニットごとの価格設定を適用するため、定期的で価値の高いワークロードには費用対効果が高くなりますが、大規模なデータセットに対するアドホックなクエリや探索的なクエリには高コストになります。モダンなクラウドデータウェアハウスの従量課金制モデル（固定のクラスターサイズではなく、実行されたクエリに対して支払う）は役立ちますが、処理されたデータ1テラバイトあたりのコストは、レイクストレージよりも大幅に高いままです。

実用的な観点から言えば、データストレージのアーキテクチャを決定する際、どちらか一方だけを選ぶということはほとんどありません。多くの組織は、コスト効率を考慮してすべてのデータをレイクに保存し、その後、同時実行性の高いBIのために、厳選されたデータセットを選択的にウェアハウスに移動しています。レイクとウェアハウスにそれぞれ1つずつ、計2つのコピーを保持する重複コストこそが、レイクハウス導入の主な原動力となっています。

データサイエンティストのための機械学習と高度な分析

データレイクは機械学習のために構築されました。生データを元のフォーマットのまま保存できるため、データサイエンティストは、事前に集計されたデータやスキーマに制限されたサブセットではなく、履歴データの完全な再現性にアクセスできます。これは、高品質なモデルをトレーニングするために不可欠です。

機械学習の特徴量エンジニアリングでは、さまざまなデータタイプにわたって、反復的かつ探索的な変換を行う必要があります。不正検知モデルをトレーニングするデータサイエンティストには、生の取引ログ、デバイスのフィンガープリントデータ、行動シーケンス、アカウント履歴などが必要ですが、そのほとんどはリレーショナルスキーマにすっきりと収まりません。データレイクは、MLパイプラインが必要とする生のフォーマットを維持しながら、さまざまなアプリケーション間でコアデータの整合性を提供します。

データレイクは、データサイエンスや高度な分析ツールとネイティブに統合します。Apache Sparkは、大規模な分散MLの事実上の標準であり、オープンフォーマットを使用してオブジェクトストレージから直接読み込みます。モデルのトレーニングに使用されるPythonライブラリ（PyTorch、TensorFlow、scikit-learnなど）は、同じS3互換のAPIを介してレイクストレージにアクセスします。データエンジニアは、データを別のシステムに移動することなく、リアルタイムの特徴量をモデルに供給するストリーミングデータパイプラインを実行できます。

クラウドデータウェアハウスは、主に推論とスコアリングのフェーズでMLワークフローに貢献します。モデルがトレーニングされると、構造化されたウェアハウスのテーブルに対する運用スコアリング（顧客テーブルでの解約予測の実行、CRMエクスポートでのリードのスコアリングなど）は、ウェアハウスのインデックス作成とクエリ最適化の恩恵を受けます。成熟したMLアーキテクチャでは、特徴量ストアを境界に配置します。生の特徴量計算はレイクで行われ、サービング準備の整った特徴量テーブルは、ウェアハウスとモデルサービングレイヤーの両方からアクセス可能なフォーマットで実体化（マテリアライズ）されます。

データ分析とBIワークロード

ビジネスインテリジェンス（BI）ワークロード（ダッシュボード、定期レポート、ビジネスアナリストによるアドホッククエリなど）には、機械学習とは根本的に異なる要件があります。BIユーザーは、低レイテンシの応答（ダッシュボードの読み込みに1秒未満）、同時実行ユーザー間での一貫した結果、そして生のソース値ではなく、合意されたビジネス定義を反映したデータを必要とします。

クラウドデータウェアハウスは、これらの要件に合わせて専用設計されています。列指向（カラムナ）ストレージ、結果のキャッシュ、マテリアライズドビューにより、データが増大しても、一般的なダッシュボードクエリはミリ秒単位で結果を返します。きめ細かなアクセス制御により、データアナリストは他の部門の機密レコードを公開することなく、自部門のデータにクエリを実行できます。ビジネスユーザーは、基盤となるデータストレージのオプションやファイルフォーマットを理解していなくても、構造化テーブルに対してSQLを直接実行できます。

データレイクは、SQLクエリエンジン（Apache Hive、Presto、Trino、Spark SQLなど）を介してBIワークロードに対応できますが、従来は専用設計のウェアハウスと比較してクエリパフォーマンスが劣っていました。スキーマオンリードの柔軟性にはクエリプランニングのオーバーヘッドが伴い、これは高い同時実行性の下で顕著になります。リアルタイムのダッシュボードや同時実行性の高いビジネスインテリジェンスには、クラウドデータウェアハウス、または高性能なSQLレイヤーを備えたレイクハウスが適切な選択肢です。

リアルタイムダッシュボード用のストリーミングデータ（センサーの読み取り値、Webサイトのクリックストリーム、決済イベントなど）は、ますます一般的になっています。データレイクとクラウドデータウェアハウスはどちらも、KafkaやKinesisなどのシステムへのコネクタを介したストリーミング取り込みをサポートしていますが、スキーマの制約がないストリーミングデータパイプラインをサポートするレイクは、高速でスキーマが可変のイベントストリームにとって、より自然なランディングゾーンとなります。

主な違い：データレイクとクラウドデータウェアハウス

以下の比較では、アーキテクチャの決定において最も重要となる要素を取り上げます。

スキーマモデル

データレイクは「スキーマオンリード」を使用します。構造はデータの書き込み時ではなく、クエリ実行時に適用されます。事前の設計なしに、あらゆるデータタイプをすぐに取り込むことができます。クラウドデータウェアハウスは「スキーマオンライト」を必要とします。データはロード前に事前定義された構造に準拠している必要があり、これによりデータ品質は確保されますが、取り込みが遅くなり、柔軟性が制限されます。この違いが、以下に示す他のほとんどの違いの原因となっています。

クエリパフォーマンス

クラウドデータウェアハウスは、構造化されたSQLベースのワークロードにおいて、特に高い同時実行性の下で優れたクエリパフォーマンスを発揮します。専用設計の列指向エンジン、インテリジェントなキャッシュ、クエリコンパイルの最適化により、一般的なBIパターンに対して1秒未満の応答を実現します。従来のデータレイククエリエンジンは、同時実行SQLに対して低速ですが、最新のベクトル化エンジンによって大幅に改善されています。ウェアハウスのコンピュートコストが非常に高額になるような、大規模なバッチ処理やMLトレーニングワークロードにおいては、依然としてデータレイクの方が高速です。

データガバナンスとキュレーションの成熟度

クラウドデータウェアハウスは、テーブルレベルおよび列レベルのアクセス制御、監査ログ、データリネージの追跡、強制的なデータタイプなど、より成熟した組み込みのガバナンス機能を標準で備えています。従来のデータレイクが同等のガバナンス成熟度に達するには、データカタログ、メタデータ管理レイヤー、外部アクセス制御システムなどの追加ツールが必要です。Unity Catalogのようなカタログサービスにより、このギャップは大幅に縮まりましたが、厳格なコンプライアンス要件を持つ組織にとっては、依然としてウェアハウスに分があります。

テラバイトあたりのコスト

データレイクは、クラウドデータウェアハウスよりもテラバイトあたりのコストが大幅に低く、ストレージ階層やクエリの頻度によっては10〜100倍安くなることもよくあります。大容量データ、履歴データ、生の取り込みデータにおいて、レイクのコストメリットは決定的です。厳選され、頻繁にクエリが実行されるビジネスデータについては、ウェアハウスのパフォーマンスがその高いコストを正当化します。

サポートされるデータタイプとフォーマット

データレイクは、構造化されたリレーショナルエクスポート、半構造化されたJSONやXML、非構造化テキスト、画像、音声、バイナリファイルなど、すべてのデータタイプをサポートします。ウェアハウスはデータベーステーブルに保存される構造化データに最適化されており、非構造化データや半構造化データのネイティブサポートは限定的であるか、まったくありません。金融取引や画像メタデータと並んでログファイルを保存するなど、多様なデータを保存することは、レイクの代表的なユースケースです。

主なユーザーペルソナ

データエンジニアとデータサイエンティストは、データレイク環境の主なユーザーです。彼らは、パイプラインの開発やモデルのトレーニングのために、元のフォーマットのすべてのデータへの生アクセスを必要とします。データアナリストとビジネスユーザーは、クラウドデータウェアハウスの主な消費者です。彼らは、SQLクエリやレポート作成のために、クリーンで信頼性が高く、応答の速いデータを必要とします。データレイクハウスは、単一のプラットフォームから両方のペルソナに対応します。これが、レイクハウスが急速に普及している主な理由です。

データレイクハウス：レイクとウェアハウスの架け橋

データレイクハウスは、データレイクの低コストで柔軟なストレージと、データウェアハウスのデータ管理機能およびクエリパフォーマンスを単一の統合システム上で組み合わせたデータプラットフォームアーキテクチャです。レイクハウスは、2システム構成 of アーキテクチャで最も高額な運用コスト、つまりウェアハウスに厳選されたデータの別コピーを保持するコストを排除します。

トランザクションストレージレイヤーは、重要なイノベーションです。オープンテーブルフォーマット（Delta Lake、Apache Iceberg、Apache Hudiなど）は、オブジェクトストレージにACIDトランザクションサポートを直接追加します。ACIDトランザクションにより、すべての書き込み操作が完全に成功するか、完全にロールバックされるかのどちらかになり、同時書き込みによるデータの破損を防ぎます。データウェアハウスが何十年も提供してきたこの保証は、歴史的にデータレイクでは利用できませんでした。レイクハウスは、レイクのオープンフォーマットとコスト構造を維持しながら、データの信頼性のためにACIDトランザクションサポートを提供します。

Delta Lakeは、最も広く採用されているレイクハウスのテーブルフォーマットです。クラウドオブジェクトストレージ上のParquetファイルにデータを保存し、すべてのスキーマ変更、挿入、更新、削除を記録するトランザクションログを維持します。SQLからクエリ可能なタイムトラベル機能により、データサイエンティストや監査人はテーブルの任意の履歴スナップショットを読み取ることができます。自動ファイル圧縮とデータスキップインデックスにより、手動のチューニングなしでクエリパフォーマンスが向上します。Delta Lakeは、オープンソースでクラウドに依存せず、Apache SparkやSQLエンジンとネイティブに統合するため、レイクハウスアーキテクチャで一般的に使用されるテクノロジーです。

Apache IcebergとApache Hudiは、異なる設計上のトレードオフを持ちながら、同様の機能を提供します。Icebergは、複雑な分析ワークロード向けに、より強力なスキーマ進化と隠しパーティショニングを提供します。Hudiは、レコードレベルのアップサート（upsert）とストリーミング取り込みパターンに特化しています。これら3つのフォーマットはすべて、Apache XTableのようなオープンスタンダードを通じて相互運用性がますます高まっています。

2025年までに、レイクとウェアハウスを同期させるのではなく、1つのプラットフォームを管理するという運用のシンプルさに後押しされ、エンタープライズ分析ワークロードの半分以上をレイクハウスが占めるようになるでしょう。新しいデータプラットフォームを構築する組織にとって、レイクハウスは実質的なデフォルトの選択肢です。

リレーショナルデータベースおよびデータマートとの統合パターン

データレイクとクラウドデータウェアハウスが他のシステムに対してどのような位置づけにあるかを理解することで、それぞれをいつ使用すべきかが明確になります。

オンライントランザクション処理（OLTP）リレーショナルデータベース（MySQL、PostgreSQL、Oracleなど）は、現在も業務アプリケーションの信頼できる唯一の情報源（system of record）です。これらは、注文管理、在庫追跡、ユーザー認証など、書き込み処理の多いトランザクションワークロードに最適化されています。クエリの負荷がアプリケーションのトランザクションと競合するため、分析ワークロードをOLTPデータベースに対して直接実行すべきではありません。標準的なパターンは、変更データキャプチャ（CDC）を介してOLTPデータをレイクまたはウェアハウスに複製することです。CDCは、業務パフォーマンスに影響を与えることなく、ソースデータベースからの行レベルの変更をイベントとしてストリーミングする技術です。

データマートは、財務、マーケティング、サプライチェーンなど、特定のビジネス機能向けに整理された、より大きなデータウェアハウスまたはレイクの特定のテーマに特化したサブセットです。これらは、ビジネスアナリストが企業全体のデータモデルを完全に理解していなくてもクエリを実行できるように、整理され、事前に結合されたデータセットを提供します。部門ごとに異なるガバナンス要件がある組織や、パフォーマンスのためにクエリの分離が必要な組織において、データマートは引き続き重要です。レイクハウスアーキテクチャでは、ゴールドレイヤーのテーブルが、個別の物理システムを必要とせずに、データマートの機能を効果的に果たします。

ETL（Extract, Transform, Load）は、スキーマオンライト（schema-on-write）システムにロードするための適切なパターンです。データがウェアハウスに入る前に変換が適用され、ターゲットスキーマへの適合が保証されます。ELT（Extract, Load, Transform）は、スキーマオンリード（schema-on-read）システムに適したパターンです。まず生データがレイクに格納され、その後、クエリ実行時またはパイプラインのステージで変換が適用されます。ほとんどの最新データプラットフォームは、レイクへの取り込みにELTを使用し、その後ETLスタイルの整理を適用してゴールドレイヤーのテーブルを作成します。

セキュリティ、ガバナンス、コンプライアンス

クラウドデータレイクにおけるデータガバナンスには、ウェアハウスシステムがデフォルトで提供しているような、明確な投資が必要です。

ファイルレベルでのアクセス制御（権限のないユーザーがオブジェクトストレージ内の生データを読み取るのを防ぐこと）は、基本的な要件です。クラウドプロバイダーはバケットレベルやプレフィックスレベルのアクセスポリシーを提供していますが、きめ細かな列レベルおよび行レベルの制御には、その上にガバナンスレイヤーが必要です。Databricksの統合ガバナンスプラットフォームであるUnity Catalogは、データベース管理者がすでに熟知している標準的なSQL DCL構文を使用して、単一のインターフェースからレイクおよびウェアハウスのテーブル全体にわたり、テーブルレベル、列レベル、行レベルのセキュリティポリシーを提供します。

データカタログとメタデータ管理は、ガバナンスの第2のレイヤーです。カタログは、どのテーブルが存在するか、そのスキーマは何か、誰が所有しているか、そしてそれらがどのように作成されたか（ソースから消費までのデータリネージ）を追跡します。カタログがないと、データレイクは「データスワンプ（データの沼）」になってしまいます。これは、ドキュメントがないままデータが蓄積され、エンジニアがデータを分析するよりも探すことに多くの時間を費やすことになるリポジトリです。ブロンズでの取り込みから、シルバーでの結合、ゴールドでの集計までの変換パスを追跡する自動リネージは、パイプラインのデバッグ、コンプライアンスの検証、およびスキーマ変更の影響を理解するために不可欠です。

保存データおよび転送データのすべてに暗号化が必要です。クラウドオブジェクトストレージは、サーバー側の暗号化を使用してデフォルトで保存データを暗号化し、転送は常にTLSを介して暗号化されます。より厳格な要件を持つ組織は、クラウドのキー管理サービスを介してカスタマー管理キー（CMK）を使用して独自の暗号化キーを管理し、クラウドプロバイダーであっても明示的な許可なしにデータを復号できないようにします。

移行とアーキテクチャ決定のフレームワーク

データレイク、クラウドデータウェアハウス、データレイクハウスのいずれかを選択するには、アーキテクチャの機能とワークロードの要件を一致させる必要があります。

まず、ワークロードの適合性評価から始めます。分析ワークロードを、主な利用者（データサイエンティスト、アナリスト、ビジネスユーザー）、必要なデータタイプ（構造化、半構造化、非構造化）、クエリパターン（バッチ、インタラクティブ、ストリーミング）、およびレイテンシ要件（秒、分、時間）ごとに分類します。構造化されたSQLレポートが中心のワークロードは、ウェアハウスに対応します。多様なデータタイプ、MLモデルのトレーニング、または将来の柔軟性を必要とするワークロードは、レイクに対応します。混在するワークロードは、レイクハウスに対応します。

パフォーマンスと並行してコストを評価します。既存のデータウェアハウスは現在のワークロードに対して許容可能なパフォーマンスを発揮するかもしれませんが、別の場所に存在する生データのストレージ、データの重複コスト、および同期パイプラインの維持にかかるエンジニアリングオーバーヘッドを含む総コストを計算してください。数テラバイト以上の生データを保存しているほとんどの組織にとって、レイクのストレージコストの優位性は、時間の経過とともに大幅に高まります。

チームのスキルセットを客観的に評価してください。クラウドデータウェアハウスは、SQL優先の分析チームにとって、より使いやすいツールを備えています。データレイクでは、パイプライン開発、カタログ管理、およびガバナンスツールへのより深いエンジニアリング投資が必要です。レイクハウスはそのギャップを縮小しますが、大規模なワークロードには依然としてSparkまたは同等の分散処理の知識が必要です。

従来のデータウェアハウスから移行する組織にとっては、段階的なアプローチが最も効果的です。パイロット段階では、価値の高い単一のワークロード（特定のMLユースケースや、既存のウェアハウスでは処理が困難なデータタイプなど）を特定し、それをレイクまたはレイクハウスに配置します。拡張する前に、既存のシステムと比較して、実際のコスト、パフォーマンス、およびガバナンスの成果を測定します。これにより、新しいアーキテクチャが検証される前に本番環境の分析を混乱させてしまう、一斉移行（ビッグバン移行）というよくある失敗パターンを避けることができます。

データレイク、ウェアハウス、レイクハウスの選択

決定フレームワークは、主なワークロードタイプに基づいて3つのパスに簡素化されます。

ワークロードが機械学習、データサイエンスの実験、または大量の生データや非構造化データの保存に偏っている場合は、データレイクから始めてください。コスト効率とフォーマットの柔軟性は決定的な利点であり、レポート作成のニーズが成熟した段階で、後からSQLクエリレイヤーを追加することができます。

ワークロードが構造化SQL分析、高同時実行ダッシュボード、および厳格なレイテンシ要件を伴うビジネスレポートを中心に構成されており、ソースデータがすでに構造化されている場合、クラウドデータウェアハウスはその特定のユースケースに対して最高の費用対効果を提供します。

組織が両方のタイプのワークロードを実行している場合、または12〜18か月以内に両方を実行する予定がある場合は、最初からレイクハウスアーキテクチャ上に構築してください。成熟した2システム構成のアーキテクチャを後から統合レイクハウスに移行するコストは、最初から統合された基盤の上に構築するコストよりも大幅に高くなります。

いずれの場合も、完全な移行を行う前に、パイロットプロジェクトで前提条件を検証してください。パイロットを開始する前に、測定可能な成功指標を定義します。これには、P95でのクエリレイテンシ、1か月あたりのテラバイト単価、生データの取り込みから分析準備完了までの時間、新規機能開発に対するパイプラインメンテナンスの比率などが含まれます。これらの指標は、組織内での議論になりがちなアーキテクチャの決定に対して、客観的な根拠を提供します。

FAQとよくある誤解

データレイクは、あらゆるケースでクラウドデータウェアハウスに取って代わるものですか？

データレイクは、すべてのケースでクラウドデータウェアハウスに取って代わるわけではありません。データレイクは、生データやマルチフォーマットのデータを低コストで保存し、機械学習ワークロードをサポートすることに優れていますが、従来のデータレイクは、専用のウェアハウスと比較して、高同時実行のSQLワークロードに対するクエリパフォーマンスが劣ります。成熟したビジネスインテリジェンス要件を持つ組織は、クラウドデータウェアハウス、またはレイクストレージ上でウェアハウスレベルのクエリパフォーマンスを直接提供する統合アーキテクチャであるレイクハウスの恩恵を受けることができます。

データレイクは従来のリレーショナルデータベースとどのように異なりますか？

データレイクは、事前定義されたスキーマなしでオブジェクトストレージ上にネイティブフォーマットで生データを保存するのに対し、リレーショナルデータベースは固定スキーマを強制し、データベーステーブルに構造化データを保存し、個々のレコードの挿入や更新といったトランザクションワークロードに最適化されています。データレイクはペタバイト規模の分析および機械学習ワークロード向けに設計されています。リレーショナルデータベースは、個々の行に対して低レイテンシでACIDトランザクションを必要とする業務アプリケーション向けに設計されています。

データレイクとデータレイクハウスの違いは何ですか？

データレイクは、トランザクションの保証なしにオブジェクトストレージに生データを保存するため、同時書き込みやスキーマの進化が複雑になります。データレイクハウスは、Delta Lake、Apache Iceberg、Apache Hudiなどのオープンテーブルフォーマットレイヤーを追加し、レイクストレージ上でACIDトランザクションのサポート、スキーマの強制、およびデータ品質の監視を直接提供します。レイクハウスは、データの重複を必要とせずに、レイクの柔軟性とコスト効率、そしてウェアハウスの信頼性とクエリパフォーマンスの両方を提供します。

データレイクやウェアハウスではなく、データマートを使用すべきなのはどのような場合ですか？

財務、マーケティング、営業業務などの特定のビジネス機能が、その機能のクエリパターンに最適化され、整理・事前結合されたデータセットを必要とする場合、およびガバナンスやパフォーマンス上の理由から、そのデータセットをより広範な企業データプラットフォームから分離する必要がある場合に、データマートを使用します。レイクハウスアーキテクチャでは、ゴールドレイヤーのテーブルがデータマートの機能を効果的に果たすため、個別の物理データマートや、それに伴う同期の複雑さの必要性が軽減されます。

データレイクが「データスワンプ（データの沼）」になってしまう原因は何ですか？また、それを防ぎますか？

適切なメタデータ管理、データ品質管理、またはアクセスガバナンスがないままデータが蓄積されると、データレイクは「データスワンプ（データの沼）」になってしまいます。その結果、ユーザーが必要なデータを見つけたり、信頼したり、アクセスしたりすることが困難になります。これを防ぐには、3つの管理策が必要です。それは、テーブルスキーマ、所有権、リネージを記録するデータカタログ、パイプラインの各ステージ（Bronze、Silver、Gold）に適用されるデータ品質チェック、および不正な書き込みによって整理されたデータセットが汚染されるのを防ぐアクセス制御です。メダリオンアーキテクチャは、生のデータを本番レベルのテーブルから隔離した状態に保ち、段階的な品質向上を強制します。

付録：技術パターンとツール

バッチおよびストリーミングのサンプルアーキテクチャ。 標準的なバッチ取り込みパターンでは、ソースシステムからエクスポートされたデータを毎日Bronzeレイクストレージにロードし、クレンジング変換を適用してSilverに保存し、BIで利用するためにGoldの集計データを実体化します。ストリーミングパターンでは、Apache Kafkaやクラウドのイベントストリーミングサービスを使用して、ほぼリアルタイムでイベントをBronzeに配信し、ストリーミングテーブルフレームワークによってSilverおよびGoldの増分更新を実行します。どちらのパターンも同じレイクストレージ上で動作し、Delta Lakeがこれら2つの取り込みモード間のトランザクション分離を処理します。

レイヤー別の一般的なツール。 取り込み用：Lakeflow、Apache Kafka、クラウドネイティブのCDCサービス。変換用：Apache Spark（PySpark、Spark SQL）、dbt（SQL中心のチーム向け）。オーケストレーション用：Apache Airflow、クラウドネイティブのワークフローサービス。SQL分析用：Databricks Lakehouse、BigQuery、Snowflake、Amazon Redshift。ガバナンス用：Unity Catalog、Apache Atlas、クラウドネイティブのカタログサービス。ML用：MLflow、Apache Spark MLlib、クラウドネイティブのモデルトレーニングサービス。

スキーマ設計テンプレート。 GoldレイヤーのBIテーブルでは、ダッシュボードのパフォーマンスを確保するために、中心となるファクトテーブルをディメンションテーブルで囲むキンボール式のスタースキーマが依然として標準となっています。ファクトテーブルにはイベント（トランザクション、セッション、コンバージョン）が含まれ、ディメンションテーブルにはエンティティの属性（顧客、製品、店舗）が含まれます。ML特徴量テーブルでは、エンティティごとに1行、すべての特徴量を列とする非正規化したワイドテーブルを使用することで、トレーニング中の結合の複雑さを最小限に抑えます。ストリーミング分析では、イベントのタイムスタンプでパーティショニングされた追加専用のイベントテーブルを使用することで、リアルタイムダッシュボード向けの効率的な時間範囲スキャンが可能になります。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事