データレイクハウスとは

これまで組織では、データレイクとデータウェアハウスを組み合わせて使用することがよくありました。データレイクは、生の構造化、半構造化、非構造化データのキャッチオールシステムとして機能し、その後、ETL/ELTパイプラインを使用して、ビジネス・インテリジェンス（BI）や予測分析などの下流のユースケースのためにデータウェアハウスに移動されました。

しかし、信頼性の高いデータを提供するためにこれらのシステムを調整することは、特にデータ分析やAIのワークロードにとっては、時間とリソースの両方でコストがかかる可能性があります。データの移動はデータの陳腐化や冗長性につながる可能性があり、ETL/ELTの追加レイヤーはデータ品質と一貫性に関するリスクをもたらす可能性があります。

データレイクハウスは、ウェアハウススタイルのデータ管理と分析機能をデータレイクに保存されているデータに直接提供することで、これらの課題を軽減します。この配置は、データ・チームがデータ管理を統合し、データ処理を加速し、データ品質を向上させ、スケーラブルな人工知能（AI）と機械学習（ML）のワークロードをサポートするのに役立ちます。

データレイクと同様に、データレイクハウスは低コストのクラウド・オブジェクト・ストレージを使用します。このアプローチにより、ほぼすべての形式（構造化、半構造化、非構造化）でデータを保管できます。

レイクハウスらしいのは、そのストレージの上にウェアハウス型のデータ管理レイヤーが組み込まれており、データ構造とガバナンスを追加して分析やBIワークロードをサポートすることです。

ほとんどのデータレイクハウスはオープン・テーブル形式（OTF）に依存しており、通常は次のとおりです。

• Apache Hudi（元々はUberで構築され、増分データ処理向けに設計されたもの）
• Apache Iceberg（大規模解析テーブルの高性能フォーマット）
• Delta Lake（Databricksが開発し、2019年にオープンソース化された人気のオプション）

これらのテクノロジーは、メタデータレイヤーとして機能し、Apache Parquetに保管されているようなオープンデータファイルを論理的かつデータベースのようなテーブルに整理します。

このアプローチにより、組織は生のレイク・データを構造化されたウェアハウス・データのように操作できるようになり、タイム・トラベル、バージョン管理、スキーマの進化、データ操作、トランザクション一貫性（ACID）などの主要な機能がサポートされます。

（「ACID」は原子性、一貫性、独立性、耐久性を表します。これらのプロパティにより、データ・トランザクションの整合性と信頼性が確保されます）。

これらの追加されたレイヤーと機能により、レイクハウスはデータレイクの信頼性と直感性を高めます。また、構造化クエリー言語（SQL）のクエリー、分析ワークロード、その他の高度なユースケースをデータレイク上で直接実行し、BI、AI、ML、データインテリジェンス（DI）を効率化することもできます。

データレイクハウスのアーキテクチャーは通常、次の5つの層で構成されています。

• 取り込み層
• ストレージ層
• メタデータ層
• API層
• 消費層

この最初のレイヤーは、内部および外部のさまざまなソースからデータを収集し、ストレージおよび分析のために準備します。取り込み層はコネクターを使って、データベース管理システム、NoSQLデータベース、SaaSアプリケーション、ソーシャルメディアフィードなどのソースと統合できます。取り込みは、バッチまたはリアルタイムで行うことができます。

ストレージ層は、低コストのクラウド・オブジェクト・ストレージにおいて構造化、非構造化、半構造化データセットを保持します。一般的なサービスには、Amazon Simple Storage Service（Amazon S3）、Microsoft Azure Blob Storage、Google Cloud Storage、IBM Cloud Object Storageなどがあります。

データは通常、Apache ParquetやOptimized Row Columnar（ORC）など、大規模な分析ワークロード向けに最適化された列指向ストレージ形式で保管されます。この層は、事実上すべてのデータ・タイプにコスト効率よく対応できるという点で、データレイクハウスの大きなメリットとなっています。

メタデータ層は、レイク内のデータに関する情報を整理して提供する統合カタログです。通常、Apache Iceberg、Apache Hudi、Delta Lakeなどのオープン・テーブル形式を利用しています。

このレイヤーの機能により、ACIDトランザクション、タイム・トラベル、スキーマの強制が可能になり、データ・ガバナンスの向上に役立ちます。このレイヤーにおける強固なアクセス制御は、機密データを扱う組織にとって不可欠であり、データへのアクセスや変更を追跡して監査証跡を維持するためにも重要です。¹

アプリケーション・プログラミング・インターフェース（API）は、レイクハウスのデータとメタデータへの標準化されたアクセスを提供します。具体的には、このレイヤーは、データ・コンシューマーと開発者に、さまざまな分析エンジンと機械学習フレームワーク（TensorFlowなど）を使用して、レイクハウスのデータで高度な分析とモデル学習を直接実行する機会を提供します。

データレイクハウス・アーキテクチャーの最後の層では、レイクに保存されているすべてのデータにアクセスできるアプリとツールがホストされます。これにより、組織全体のユーザーがデータにアクセスできるようになり、レイクハウスを使用して、ビジネス・インテリジェンスダッシュボード、データの可視化、機械学習のジョブといったさまざまなタスクを実行できます。

メダリオン・データ・アーキテクチャ（MDA）は、レイクハウスデータが取り込みから消費に至るまで段階的にクレンジングされ、検証され、信頼できるものとなるよう設計された多層的な品質重視のデータ設計手法です。これにより、組織は、日常のビジネス・レポートだけでなく、高度な分析や機械学習のワークロードに適した、スケーラブルで管理されたデータレイクハウスを構築できます。

この拡張性は、データ量が増加するにつれて品質を維持するために不可欠です。2025年1月のベンチマーク調査によると、87.4％の組織が、レガシーのデータ品質フレームワークが7ペタバイトを超えると運用上持続不可能になったと感じています。²

このフレームワークは、ライフサイクル全体を通じてデータを銅、シルバー、ゴールドの3つの異なる層に編成し、各段階でデータ品質を向上させます。

• ブロンズ層は未加工データ用です。元のデータを、ソース・システムから受信したときとまったく同じ状態で保存します。これにより、常に不変のソース・ファイルが存在することが保証され、変換中にデータが失われたり上書きされたりするリスクが取り除かれます。
  
  
• シルバー層は、データが積極的にクレンジング、構造化、および強化される場所です。分析と運用レポート作成用に、競合または重複するレコードを単一のデータ・ソースに統合します。
  
  
• ゴールド層には、洗練されたビジネス対応データが含まれており、戦略的な意思決定に最適な、信頼できる唯一の情報源です。すべてのクリティカルなビジネス・メトリクスは、この層で定義され、事前計算されます。

ゴールド層はAI対応も強化します。AI対応の高品質なデータを直接MLパイプラインに提供し、モデルの精度向上とデータ準備の手間軽減に役立ちます。

この構造化されたデータの進行により、最終データファイルが元の状態にトランスフォーメーションされるまで逆に追跡できることが保証されます。また、データ・ストレージとコンピューティング・リソースを各層の目的に応じて最適化できるため、予測可能性が高く、多くの場合、コストが削減されます。

データレイクハウスにはいくつかの重要な機能があります。

• オープンファイルフォーマット
• ACIDトランザクション
• 統合データ
• コスト効率に優れたストレージ
• ワークロードの柔軟性
• 強固なデータ・ガバナンス
• 拡張性
• リアルタイム・ストリーミング・サポート

Apache ParquetやORCのようなオープンな列指向ストレージフォーマット（またはオープンデータフォーマット）は、効率的な圧縮、カラムのプルーニング、述語プッシュダウンにより、クエリーのパフォーマンスを向上させ、ストレージコストを削減します。これらの形式は、組織が同じデータに同時にアクセスできる一般的な分析エンジンと互換性があります。この機能により、ベンダー・ロックインを回避し、さまざまなツール間での相互運用性を実現できます。

ほとんどのデータレイクハウスは、Apache Iceberg、Apache Hudi、Delta Lakeなどのオープン・テーブル形式を使用してACIDトランザクションを提供しています。挿入、更新、削除などのこれらのトランザクションは、オペレーション中もオペレーション後もデータの一貫性と信頼性を維持することを保証します。

単一のデータ・ストレージ・システムは、あらゆるビジネス・データ需要を満たすことができる集中型プラットフォームを構築し、システムやチーム間のデータのサイロ化や重複を削減します。様々なデータ・パイプラインやシステムを介したデータの移動が大幅に削減されるため、この一元化によってエンドツーエンドのデータオブザーバビリティーも簡素化されます。

データレイクハウスは、低コストのクラウド・オブジェクト・ストレージを活用することで、従来のデータウェアハウスよりも大容量のデータやワークロードに対するコスト効率を高めています。データレイクハウスのハイブリッド・アーキテクチャーのおかげで複数のデータ・ストレージ・システムを維持する必要がなくなるので、多くの場合、運用コストが削減されます。

データレイクハウスは、データ管理のライフサイクル全体でさまざまなユースケースに対応できます。ビジネス・インテリジェンスやデータ駆動型の可視化ワークフローをサポートすることも、より複雑なデータサイエンス・プロジェクト（機械学習モデルのトレーニングやリアルタイム分析など）をサポートすることもできます。

データレイクハウス・アーキテクチャーは、集中型メタデータカタログ、スキーマの強制、組み込みのデータ品質管理ツールを通じて、データレイクのガバナンス問題を緩和します。データ・セキュリティーは、アクセス制御、監視、監査、データの匿名化、ブロックチェーン、さらには量子コンピューティングを利用して強化することができます。^3,4

データレイクハウスはストレージとコンピューティングを分離するため、データ・チームはそれらを個別に拡張できます。この分離により、アプリケーションごとに異なるコンピューティング・エンジンまたはノードを使用しながら、同じデータにアクセスできる柔軟性も提供されます。

現代のデータレイクハウスは、今日のビジネスと技術に合わせて構築されています。多くのデータ・ソースには、リアルタイムのストリーミング・データが含まれています。例えば、モノのインターネット・デバイスからのデータです。レイクハウス・システムは、リアルタイムでのデータ取り込みと増分処理を通じて、これらのソースをサポートします。

データレイクハウスは、単にデータウェアハウスとデータレイクを組み合わせたものではありません。両方の優れた部分を1つのプラットフォームにまとめた統合アーキテクチャーです。

データウェアハウスは、構造化された分析のために構築されています。企業データを保存および変換することで、ビジネス・インテリジェンス・アプリケーションとレポートに優れた性能をもたらします。

ただし、データウェアハウスにはデータレイクの柔軟性が欠けています。データ量とワークロードが増加するにつれて、非効率性とコストのために限界があります。データ・ウェアハウジングには厳格なスキーマも必要です。つまり、データはデータ・リポジトリー（スキーマオンライト）に取り込まれる前に、事前に定義されたモデルに準拠している必要があります。これらの制約により、AIやMLのユースケースにとってクリティカルな非構造化データや半構造化データではうまく機能しません。

データレイクを使用すると、組織は、さまざまなソースからのあらゆる種類のデータ、つまり構造化データ、非構造化データ、半構造化データを1か所に保管できます。これらはスキーマオンリード・アプローチを使用するため、データ・モデルはデータが保管されているときではなく、使用されるときに適用されます。また、通常、よりスケーラブルで手頃な価格のデータ・ストレージ（多くの場合、クラウド・オブジェクト・ストレージ）を備えています。

ただし、データ処理ツールが組み込まれておらず、分析を実行するには外部機能を利用します。その規模と複雑さは、データサイエンティストやデータ・エンジニアなど、より技術的なユーザーの専門知識を必要とすることもあります。そして、データ・ガバナンスが下流で行われるため、データレイクはデータ・サイロになりやすく、結果的にデータ・スワンプ（管理が不十分なために適切なデータにアクセスできない状態）に陥ることがあります。

データレイクハウスは、データウェアハウスとデータレイクの課題を解決し、そのメリットを1つのプラットフォームで実現するように設計されています。幅広いデータ・タイプをサポートする柔軟で低コストのストレージを活用し、BI、分析、AI/MLワークロードをサポートするデータ管理機能と高性能機能を単一のアーキテクチャーで提供します。

IBM Softwareのプリンシパル・プロダクト・マネージャーであるAnson Kokkatは、最新のAIプログラムにおけるレイクハウスの重要性を次のように強調しています。

「AIモデルの良し悪しは、その下にある管理されたスケーラブルなデータ・プラットフォームと同程度になります。適切なデータレイクハウスは、未加工のエンタープライズ・データを実稼働対応のAIに変える基盤となります。オープンアーキテクチャーに基づいて構築されると、AIの柔軟性が向上します。1つのエンジンに縛られることなく、Presto、Apache Spark、OpenSearch、Cassandraなどの既存のオープンソース・ツールと統合できます」

もう1つの大きなメリット：組織は、多くの場合、完全に解体して再構築することなく、既存のデータレイクやデータウェアハウスと並行してデータレイクハウスを実装できます。

現在、多くのプロバイダーがオープンなデータレイクハウスを提供しています。このアーキテクチャーはオープン・データとオープン・フォーマットをサポートし、Parquet、Avro、Apache ORCなど、ベンダーに依存しない形式で膨大な量のデータを保存可能です。また、Apache Icebergを活用して、オープン・テーブル形式で大量のデータを共有することもできます。

データレイクハウスの一般的な課題には、実装の複雑さ（既存データ・プラットフォームからの移行を含む）が含まれます。統合されたデータ・アクセスによるデータ・ガバナンスとセキュリティーのバランスを取ります。また、データ量が増加してもクエリーの性能が最適に維持されるようにします。

はい。データレイクハウスは、強力なガバナンスで大量の多様なデータへの統合アクセスを提供することで、AIやMLのワークロードをサポートします。オープン・データとオープン・テーブル形式を使用して、ベンダー・ロックインを防ぎ、ストレージ層とMLフレームワーク間の直接統合を可能にします。

それは可能ですが、それを行うべきかどうかは、データの優先順位によって異なります。レイクハウスは多様なビッグデータの保管やAI/MLワークロードのサポートに強力な選択肢であり、ウェアハウスはより構造化された高性能・低遅延のデータ・ニーズに依然として有用です。多くの組織は両方のプラットフォームを使用しています。

データ沼を回避するには、強力なデータ・ガバナンス、データ品質、データ・セキュリティー対策が必要です。さらに、階層型（メダリオン）ストレージ・アーキテクチャーによりデータは整理され、ACIDトランザクションを使用したオープン・テーブル形式によりデータの整合性、一貫性、信頼性が確保されます。