イラストで覚えるデータウェアハウス・レイク・レイクハウス
0.対象となる読者
Ⅰ.大量のデータの処理や保管について悩んでいる方
Ⅱ.データウェアハウスやデータレイク、データレイクハウスの違いや概念をしっかり理解しておきたい方
Ⅲ.難しい用語はわからないし、簡単にイメージとして理解しておきたい方
全部読む時間なんかない、違いや概念を度忘れしただけだよという方は
まとめだけ読んで頂いても構いません。
1. はじめに
最近、生成AIによる業務の自動化や効率化が進み、「AIの時代」が到来していますね。このAIを支える原動力が「データ」で、その「データ」の重要性は、これまで以上に高まっています。
しかし、膨大なデータをどのように活用し、効率的に処理するのかという課題に直面している方々も多いでしょう。特に、従来のデータアーキテクチャだけでは対応しきれない状況も多く見られます。
この記事では、データの保存と処理を支える「データウェアハウス(Data Warehouse)」と「データレイク(Data Lake)」、そして「データレイクハウス(Data LakeHouse)」の役割や違いについて解説します。
この記事を読むことで、これらの概念を理解し、それぞれの特徴や重要性をつかんでいただけることを目指しています。
さらに、イラストを用いて各概念の役割を視覚的に説明してより分かりやすくお伝えできるように工夫しました。
2. データウェアハウス、データレイクまたレイクハウスの違い
2.1 データウェアハウス(Data WareHouse)【DWH】
・主な用途
- 過去データの集計や分析、レポートやダッシュボード作成
→ 構造化データ を用いた意思決定支援
Tip: データを使う前にスキーマ[1]を定義して整理する必要があり、これが 「構造化データに最適化」と言われる理由 です。
・長所
- 高速なクエリ性能: SQLを使ったクエリが高速で、BIツールとの相性が良い。
-
効率的なデータ管理: 事前に整形された表形式データを RDBMS[2] で管理。
- 各テーブル間の関係性を定義することで、効率的なデータ検索や管理が可能。
- スキーマ・オン・ライト[3]: データの保存時に整理し分析が速い。
・課題
-
柔軟性の低さ
- 新しいデータ形式や非構造化データに対応する際に制約がある。
- 動画や画像などの非構造化データは、別のストレージツール(例: データレイク)と連携が必要。
-
高コスト
- ストレージや計算リソースに多くの費用がかかる。
- データの変換・整備に手間とコストが必要。これがデータレイクハウスに比べてコストが高い要因となる。
・イメージ
データウェアハウスのイメージ
自分はData WareHouseという名前どおり倉庫をイメージしました。
様々な物流センターや倉庫の(データウェアハウス)中で、段ボールで包装された(構造化)荷物(データ)が積み重ねている感じです。
-
包装されて段ボールに入っている荷物(構造化データ) は 倉庫に格納 できる。
→ 包装されてない荷物(半構造・非構造データ) は形がばらばらなので 倉庫の格納に向いてない - 物流センター・倉庫ということで荷物の管理がとても効率的。
- 物流センター・倉庫を借りるにはお金がかかる。 → 高いコスト
2.2 データレイク(Data Lake)【DL】
・主な用途
- 機械学習モデルのトレーニングや非構造化データの保存と初期分析。
→ 非構造化データ(画像、動画、ログデータ etc)、半構造化データ(JSON、XML)、構造化データのすべてに対応可能
・長所
- 柔軟性: 多様な形式(構造・半構造・非構造)のデータをそのまま保存し、後から用途に応じた構造を適用できる。
-
低コスト・スケーラビリティ: 専用のインフラが不要で、クラウドストレージの利用により運用コストを抑えられる。
- ペタバイト規模のデータも低コストで管理し、容易に拡張可能。
- リアルタイム対応: IoTデータやログデータのリアルタイム保存・処理が可能。
- スキーマ・オン・リード[4]: データの形式を柔軟に扱えるため、保存時に制約が少ない。
・課題
-
検索性と効率性の欠如
- スキーマのないデータが格納されるため、特定のデータセットを見つけるのが困難。
- インデックスや最適化されていないデータセットのクエリ実行に時間がかかる。
-
データスワンプ化のリスク
-
データスワンプとは?
データレイク内に保存されたデータが整理されず、どのデータが何に使えるのかが分からなくなる状態。
→ 結果: 必要なデータを見つけられない、分析に信頼性が欠ける問題を引き起こす
-
データスワンプとは?
・イメージ
データレイクのイメージ
自分はData Lakeという名前どおり湖をイメージしました。
とても広く巨大な湖に石を投げる(入れる)と考えてみましょう。
どのような石を投げても別に大きな問題はなさそうですね。(そもそも湖に勝手に石を投げたりするのはだめですが)
- 湖(データレイク)には どのような石(データの構造関係なく)投げても大丈夫です
- 物流センター・倉庫(データウェアハウス)より湖に大量の石(データ)が入る → 大量のデータに適切
- 物流センター・倉庫を借りて石を保管するより湖に投げた方が安いですね → 低いコスト
- どこにどのような石を投げたのか探するのが難しい、時間がかかる → 検索性と効率性がよくない
2.3 データレイクハウス (Data LakeHouse)【DLH】
・主な用途
-
データ分析とビジネスインテリジェンス(BI)
- 既存のデータウェアハウスの代替・拡張として利用可能。例:売上データや在庫データを基にしたダッシュボードの構築。
-
統合分析基盤
- データレイクが非構造化データ(ex:画像、ログファイル)を格納し、データウェアハウスが構造化データ(ex:売上データ)を分析するのに対し、データレイクハウスでは両者を単一のプラットフォームで効率的に処理可能。
-
データサイエンス・機械学習
- 顧客データをもとにした購買予測モデルのトレーニングや、リアルタイムでの異常検知に対応可能。
・長所
-
柔軟性
- データレイクの柔軟性を継承しつつ、DWHのようなスキーマ管理とクエリ性能を併せ持つため、幅広いユースケースに対応可能。
-
一元管理
- 単一プラットフォーム上でデータを効率的に保管・管理できる。これにより、構造化・非構造化を問わず多様なデータを活用可能。
-
オープンスタンダード[5]
- Apache ParquetやDelta Lakeなどの汎用フォーマットを採用し、特定のクラウドやプロバイダーに依存せず、データ移行やツール連携が容易になる。
・課題
-
運用の複雑性
- 構造化データと非構造化データを統合的に扱うため、クエリ設計やデータスキーマの管理に熟練した知識が必要。
-
パフォーマンスチューニング
- クエリ処理速度を向上させるためのデータパーティショニングや、インデックス作成における最適化作業が求められる。
・イメージ
データレイクハウスのイメージ
今回の画像はChat GPTに作ってもらいました。
イラストだけではかなり想像しにくいかと思いますが、以下のように覚えていただきたいですね。
- 物流センター・倉庫や湖が両方存在するので、データの種類関係なく処理・格納可能。
→ 造化・半構造化・非構造化データの形式に対応 - データの形によって倉庫や湖を選択して利用できるのでコストが効率的。
→ ストレージコストはデータウェアハウスより安く、データレイクよりは高い
一言でまとめると、
データウェアハウスとデータレイクのメリットを合わせた一つのプラットフォームになります。
4. まとめ
特徴/項目 | データウェアハウス | データレイク | データレイクハウス |
---|---|---|---|
対象データ形式 | 構造化データのみ | 構造化・半構造化・非構造化データ | 構造化・半構造化・非構造化データ |
スキーマ管理 | スキーマ・オン・ライト | スキーマ・オン・リード | スキーマ・オン・リード+ライト |
ストレージコスト | 高い | 低い | 中程度 |
処理性能 | 高速 | 処理エンジンに依存(例: Spark) | 高速 |
主要用途 | BI分析、定型レポート | 大容量データ保存、AI/ML活用 | BI分析+AI/ML活用 |
代表例 | Snowflake、Google BigQuery | Amazon S3、Azure Data Lake | Databricks、Delta Lake、Snowflake |
1.整然としたデータで素早く分析したいときなら、データウェアハウス(DWH)
- 高速なクエリ処理やビジネスインテリジェンス(BI)に最適。
- スキーマが厳格で、データの整合性が重視される。
2.様々な形式のデータを柔軟に保存したいときなら、データレイク(DL)
- 構造化・非構造化データを低コストで大規模に保管可能。
- 保存を重視するが、分析性能や管理は弱い。
3.多様なデータを統合し、効率的に分析・活用したいときなら、データレイクハウス(DLH)
- DWHの性能とDLの柔軟性を兼ね備え、機械学習や高度な分析も可能。
- オープンスタンダードを活用し、ベンダーロックイン[6]を回避できるのも強み。
最終的には
DWHは 「分析特化型」
DLは 「保存特化型」
DLHは 「統合型」
となり、各々の状況や目的に合わせて適切なものを選ぶことが大事ですね。
-
どんなデータを、どのような形式で保存して、どう扱うのかを決めた設計図またはルールのようなもの。 ↩︎
-
Relational Database Management Systemの略で、データをテーブル(表)形式で構造化し、行と列で管理するシステム。 ↩︎
-
スキーマ・オン・ライト(Schema-on-Write):保存時にスキーマを適用し、データを整えてから保存する方法。整然としたデータが保存され、クエリが高速で正確なのが特徴。 ↩︎
-
スキーマ・オン・リード(Schema-on-Read):保存時はそのまま保存し、読み出すときにスキーマを適用する方法。どんな形式のデータも保存可能で柔軟だが、クエリは遅くなる場合もある。 ↩︎
-
広く公開され、誰でも自由に利用できる仕様や基準 ↩︎
-
製品、サービス、または技術を利用した結果、それに依存する形となり、他の製品やサービスへの移行が難しくなる状況。 ↩︎
Discussion