DWH・データレイク・レイクハウスの違い――選定時に見るべき要件

データ基盤の構想で最初につまずきやすいのが、「DWH（データウェアハウス）、データレイク、レイクハウスのどれを選ぶべきか」という問いです。しかし、この三つは単純な世代交代ではありません。構造化された経営指標を安定して提供するのか、ログや文書を含む多様なデータを将来の分析に残すのか、BIとAIを同じデータから動かすのかによって、適した構成は変わります。

重要なのは製品名から入らず、事業上の意思決定、データ特性、サービスレベル、統制、運用能力を要件に変換することです。本記事では、三方式の違いと選定手順を、エンタープライズアーキテクチャ（EA）とDAMA-DMBOKの観点も交えて整理します。

結論：名称ではなく「提供するデータサービス」で選ぶ

DWHは、定義と構造を整えたデータを、経営管理や定型分析へ安定して提供することを得意とします。データレイクは、多様な形式のデータを元の状態に近い形で保持し、探索、データサイエンス、将来の再利用に備える基盤です。レイクハウスは、オープンなファイルストレージを土台に、トランザクション、スキーマ管理、品質管理、BI向けのクエリ性能などを組み合わせる設計思想です。

現実の企業アーキテクチャでは、三択ではなく併用も一般的です。たとえば、原本として保持すべきデータはレイクに保持し、標準化したデータをレイクハウス上で加工し、経営報告向けにはDWHまたはSQL提供層を置く構成です。構成要素を増やせば連携、監視、権限、コストの管理も増えるため、「できること」ではなく「必要なこと」から範囲を決めます。

DWH・データレイク・レイクハウスの比較

Microsoftの公式アーキテクチャガイドでも、単一のデータ管理方式があらゆる保存・分析タスクに適するわけではなく、実環境では複数方式を組み合わせることが示されています。したがって、「レイクハウスならDWHは不要」といった一般論ではなく、自社のワークロード単位で評価すべきです。

選定時に確認する7つの要件

1．意思決定と利用シナリオ

最初に「誰が、どの判断を、いつ行い、その結果どの行動を変えるか」を記述します。月次の予実管理、日次の需給調整、不正検知、顧客行動の探索では、必要な粒度、鮮度、応答時間が異なります。画面一覧ではなく、業務上の問いと意思決定を起点にしてください。

2．データ形式と変化の大きさ

基幹テーブル中心か、JSON、センサーログ、画像、文書まで扱うかを確認します。項目が安定し、業務定義が明確な領域はDWHと相性がよく、形式や用途が未確定なデータはレイクの柔軟性が有効です。両方を同じデータ資産として扱うなら、レイクハウスを含む統合構成を検討します。

3．品質を保証する段階

経営数値には、重複排除、コード統一、締め処理、訂正反映などの品質保証が必要です。原本を残すだけでよい領域と、公開前に品質基準を満たす領域を分け、データセットごとに「raw／validated／business-ready」などの状態を明示します。保存場所の名称より、誰がどの基準で昇格を承認するかが重要です。

4．鮮度、性能、同時利用

更新頻度は「リアルタイム」という言葉だけで決めず、発生から利用可能になるまでの許容時間、ピーク時の利用者数、代表クエリの応答目標を数値で定義します。バッチ、マイクロバッチ、ストリーミングを用途別に使い分け、不要な低遅延化を避けます。

5．ガバナンス、セキュリティ、監査

機密区分、保存期間、越境、行・列レベルのアクセス、暗号化、利用ログ、削除要求を確認します。また、カタログ、業務用語、データ責任者、リネージュが基盤をまたいで追跡できることも要件です。多様なデータを集めるほど、発見性と利用条件の整備が欠かせません。

6．組織のスキルと運用モデル

SQL中心のチームか、分散処理、ソフトウェア開発、機械学習の運用まで担えるかを見ます。新方式の採用は、権限設計、パイプライン監視、コスト管理、障害対応、データプロダクトの責任者まで含む運用変更です。必要な人材を調達・育成できない構成は、技術的に優れていても持続しません。

7．TCOと変更容易性

保存・計算費だけでなく、データコピー、変換、監視、テスト、ネットワーク、ライセンス、専門人材、障害復旧を含めて比較します。将来の変更に備え、データ形式、API、メタデータの可搬性、契約終了時の移行方法も確認します。

要件から方式を絞る判断表

EAとDMBOKで「基盤だけの最適化」を防ぐ

EAでは、データ基盤を単独の製品導入ではなく、事業能力、業務プロセス、情報、アプリケーション、テクノロジーのつながりとして設計します。現行と目標のアーキテクチャを描き、段階移行の単位を決めることで、短期のユースケースと全社標準の両方を扱えます。

DAMA-DMBOKの視点では、Data Warehousing & Business Intelligenceだけでなく、データガバナンス、データアーキテクチャ、モデリング、統合、品質、メタデータ、セキュリティを横断して確認します。方式選定表にこれらの責任と成果物を追加すると、「基盤は完成したが、数値が信用されない」という失敗を抑えられます。

選定を進める実務ステップ

1. 優先する3〜5件の意思決定ユースケースを選ぶ
2. 必要データ、粒度、履歴、鮮度、品質、権限を定義する
3. 現行データフローと重複・ボトルネックを可視化する
4. 候補方式を同じ評価項目と代表ワークロードで比較する
5. 小さな実証で性能だけでなく、運用、品質、コストを測る
6. 目標構成と段階移行ロードマップを意思決定する

要件を具体化する際は、DWH構築の要件定義チェックリストもご覧ください。セルフサービス利用を広げる場合は、セルフサービスBIのガバナンスまで一体で設計する必要があります。

まとめ

DWH、データレイク、レイクハウスの選定に唯一の正解はありません。正解に近づく方法は、意思決定を起点に、データ、品質、性能、統制、スキル、TCOを同じ土俵で比較し、必要なら複数方式の責任境界を設計することです。Version株式会社では、EAとDMBOKをベースに、製品選定前のデータ基盤構想から段階移行まで支援しています。自社の要件整理や候補構成の第三者レビューをご希望の場合は、お問い合わせください。

BI／DWHテーマクラスター：BI要件定義 ／ 経営ダッシュボード ／ セルフサービスBI統制 ／ DWH・データレイク・レイクハウス ／ DWH要件定義 ／ セマンティックレイヤー ／ BI数値不一致とリネージュ ／ レガシーDWH刷新 ／ BI CoE ／ DWH受入テスト