データレイクハウスとは？DWH・データレイクとの違いと導入の5ステップを解説！

データレイクハウスとは

データレイクハウスとは、データレイクの低コストで柔軟なストレージと、DWHが持つデータ管理・分析機能を1つの基盤で両立させるデータアーキテクチャのことです。名称は「データレイク」と「データウェアハウス」を組み合わせた造語です。

この概念は、2021年に米Databricks社の研究者らが発表した論文「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」で体系的に示されました。同論文では、データレイクとDWHを併用する「2層構成」が、データの信頼性、鮮度、高度な分析への対応、総保有コストの面で課題を抱えていると指摘されています。

データレイクハウスの主な特徴は以下の通りです。

• オープンなファイル形式での保存
  データは「Apache Parquet」などのオープンなファイル形式で、クラウドの安価なオブジェクトストレージに保存されます。特定の製品に依存しない形式のため、複数の分析ツールから同じデータを直接読み込むことができます。
• テーブルフォーマットによる管理機能
  ファイル群の上に「Apache Iceberg」「Delta Lake」「Apache Hudi」といったテーブルフォーマットと呼ばれるメタデータ層を重ねます。これにより、書き込みの整合性を保証する「ACIDトランザクション」や、過去時点のデータを参照する「タイムトラベル」が可能になります。
• ストレージとコンピュートの分離
  データを保存する層と、処理を実行する層が独立しています。そのため、データ量と処理量をそれぞれの必要に応じて拡張することが可能です。
• 多様なワークロードへの対応
  BI（ビジネスインテリジェンス）による定型レポートと、機械学習やAIの学習処理を、同じデータに対して実行できます。用途ごとにデータを複製する必要性が下がる点が特徴です。

DWH・データレイクとの違い

データレイクハウスを理解するには、DWHとデータレイクがそれぞれ何を得意とし、何を苦手としてきたかを押さえることが有効です。

DWHは、1990年代初頭にビル・インモン氏が提唱した概念で、分析用に整理・統合されたデータを時系列で蓄積する仕組みです。保存前にデータ構造を定義する「スキーマオンライト」を前提とするため、品質の揃ったデータで高速に集計できます。一方で、非構造化データの扱いや、構造変更への柔軟な対応は苦手とされてきました。

データレイクは、2010年頃に米Pentaho社のCTO（最高技術責任者）であったジェームズ・ディクソン氏が提唱したと言われている概念です。あらゆるデータを元の形式のまま保存し、利用時に構造を解釈する「スキーマオンリード」を採用しています。柔軟で低コストな反面、管理が行き届かないと、どこに何があるか分からない「データスワンプ（データの沼）」に陥りやすいと指摘されています。

データレイクハウスは、この両者の長所を1つの基盤で実現しようとする考え方です。3者の違いを整理すると、以下の通りです。

なお、データを1か所に集める以外の選択肢として、データを移動させずに複数のデータソースを横断して参照する「データフェデレーション」という手法もあります。詳しくは弊社ブログの「データフェデレーションとは」で解説しています。

データレイクハウスのビジネスメリット

データレイクハウスを採用することで、以下のようなビジネスメリットが得られると言われています。

• データ基盤の簡素化とコストの最適化
  DWHとデータレイクの間でデータを複製・同期する処理を減らすことができます。二重保存のストレージ費用や、連携処理の開発・保守にかかる工数の削減に繋がります。
• データ鮮度の向上
  データレイクからDWHへの転送を待たずに分析できるため、意思決定に使うデータの鮮度を高めることが可能です。営業やマーケティングの現場で、より新しい状況を踏まえた判断がしやすくなります。
• BIとAI活用の共通基盤化
  経営ダッシュボードと機械学習モデルが同じデータを参照するため、部門や用途によって数字が食い違うリスクを抑えられます。生成AIの活用に向けて、社内の文書データと業務データを同じ基盤で扱える点も評価されています。
• 特定ベンダーへの依存の低減
  オープンなファイル形式とテーブルフォーマットを採用することで、将来的に分析エンジンを切り替えやすくなります。近年は主要なクラウド事業者やデータ基盤製品がApache Icebergへの対応を進めており、製品間の相互運用性が高まりつつあると言われています。

データレイクハウスの課題

データレイクハウスには多くのメリットがある一方で、導入・運用にはいくつかの課題が伴います。

• 設計・運用の複雑さ
  ストレージ、テーブルフォーマット、カタログ（メタデータ管理）、分析エンジンなど、組み合わせる要素が多くなります。どの技術を選ぶか、権限やコストをどう管理するかといった設計判断が求められます。
• 既存環境からの移行負荷
  稼働中のDWHやデータレイクをすぐに置き換えることは容易ではありません。既存のレポートや連携処理への影響を見極めながら、段階的に移行する計画が必要になります。
• ガバナンス不在によるデータスワンプ化の再発
  技術的に管理機能が備わっていても、データの所有者や命名ルール、品質基準が定まっていなければ、データレイクと同じ混乱が起こり得ます。基盤の導入と同時に、運用ルールを整備することが重要と考えられます。
• データの「中身」の品質は自動では揃わない
  データレイクハウスは保存と処理の仕組みを統合するものであり、データの意味や品質を自動で揃えるものではありません。たとえば、同じ取引先が部門ごとに「株式会社〇〇」「（株）〇〇」「〇〇社」と別々に登録されていれば、1つの基盤に集めても「顧客数」は正しく数えられません。部門ごとに分断されたデータの課題については、弊社ブログの「データのサイロ化とは？」もご参照ください。

データレイクハウス導入のプロセス

データレイクハウスでは、データを段階的に整えていく「メダリオンアーキテクチャ」と呼ばれる設計パターンが広く用いられています。ブロンズ（元データ）、シルバー（整備済みデータ）、ゴールド（業務向けデータ）の3層でデータの品質を高めていく考え方です。導入は以下のプロセスで進めることが一般的です。

1. 目的とユースケースの特定
   どの部門が、どの意思決定のためにデータを使うのかを明確にします。全社一斉ではなく、効果が見えやすいテーマから着手することが推奨されます。
2. データの取り込み（ブロンズ層）
   基幹システム、SFA（営業支援システム）、MA（マーケティングオートメーション）などのデータを、元の形式のまま取り込みます。元データを履歴として残しておくことで、後から処理をやり直すことが可能です。
3. データの整備（シルバー層）
   欠損値の補完、重複の削除、表記の統一を行い、「顧客」「商品」といった業務の基本単位でデータを揃えます。取引先データでは、表記の揺れを吸収して同一企業を特定する「名寄せ」がこの工程の中心になります。
4. 業務向けデータの作成（ゴールド層）
   売上レポートや顧客分析など、用途ごとに集計・加工したテーブルを作成します。BIツールや機械学習モデルは、主にこの層のデータを参照します。
5. 運用とガバナンスの定着
   各層の処理を定期的に実行するジョブ管理と、アクセス権限や品質の監視を整えます。データアーキテクト、データエンジニア、業務部門のデータオーナーが役割を分担することが重要です。データの流れを管理する考え方については、弊社ブログの「データオーケストレーションとは」で解説しています。

おわりに

本記事のポイントを3点にまとめます。①データレイクハウスはDWHの管理機能とデータレイクの柔軟性を1つの基盤で両立する考え方、②基盤を統合しても取引先データの表記揺れや重複は自動では解消されない、③導入は目的を絞り、名寄せを含むデータ整備とガバナンスを並行して進めることが重要、という点です。

データレイクハウスは、DWHとデータレイクの2層構成が抱えていたコストや鮮度の課題を解消し、BIからAIまでを同じデータで支える基盤として期待されています。一方で、その価値を引き出すには、シルバー層で「1社」を正しく特定できる状態をつくることが欠かせません。顧客マスタの整備手段の検討には、弊社ブログの「MDM・CDPの選び方とは？」も参考になります。

弊社の顧客データ統合ソリューション「ユーソナー」は、日本最大級の企業情報データベースを搭載し、社内に散在する取引先データの名寄せと統合を支援しています。「LBC」という独自のコード体系による顧客情報の管理に加え、独自に収集した鮮度の高い企業データを継続的に取得できるため、データレイクハウスのシルバー層・ゴールド層で使う顧客マスタの精度向上に貢献します。

詳細についてはぜひこちらのページから、お気軽にお問い合わせください。