データファブリック、データレイクハウス、データメッシュは、これまで広く使われてきたデータウェアハウスに代わる選択肢として登場しています。ただし、これらはいずれも万能というわけではありません。本書は、それぞれの長所と短所を理解できるよう、これらのアーキテクチャを分かりやすく解説します。データウェアハウスがデータレイクの機能と連携するためにどのように進化してきたかを含めて、データアーキテクチャを体系的に説明します。データレイクハウスで実現できることや、データメッシュをめぐる過大な期待と現実を学ぶことで、自分のニーズに適したデータアーキテクチャを判断できるようになります。また、より良いデータソリューションを構築するために必要な基本概念やアーキテクチャデザインセッションの進め方、チーム編成、プロジェクト成功のポイントについても学びます。

本書への賛辞
訳者まえがき
まえがき
はじめに

第I部　基礎編

1章　ビッグデータ
    1.1　ビッグデータの定義とその価値
    1.2　データマチュリティ
        1.2.1　レベル1：事後対応段階
        1.2.2　レベル2：情報提供段階
        1.2.3　レベル3：予測段階
        1.2.4　レベル4：変革段階
    1.3　セルフサービスビジネスインテリジェンス
    1.4　まとめ

2章　データアーキテクチャの種類
    2.1　データアーキテクチャの進化
    2.2　リレーショナルデータウェアハウス
    2.3　データレイク
    2.4　モダンデータウェアハウス
    2.5　データファブリック
    2.6　データレイクハウス
    2.7　データメッシュ
    2.8　まとめ

3章　アーキテクチャデザインセッション
    3.1　ADS（アーキテクチャデザインセッション）とは何か
    3.2　ADS を開催する理由
    3.3　ADS 開催前
        3.3.1　準備
        3.3.2　招待する参加者
    3.4　ADS の実施
        3.4.1　自己紹介
        3.4.2　ディスカバリーフェーズ
        3.4.3　ホワイトボードの活用
    3.5　ADS 開催後
    3.6　ADS を実施する際のヒント
    3.7　まとめ

第II部　データアーキテクチャの共通概念編

4章　リレーショナルデータウェアハウス
    4.1　リレーショナルデータウェアハウスとは何か？
    4.2　データウェアハウスではないもの
    4.3　トップダウンアプローチ
    4.4　リレーショナルデータウェアハウスを使用する理由
    4.5　リレーショナルデータウェアハウスのデメリット
    4.6　データウェアハウスの構築
        4.6.1　データを抽出する頻度
        4.6.2　抽出方法
        4.6.3　前回の抽出時以降に変更されたデータを特定する方法
    4.7　リレーショナルデータウェアハウスの終焉は誇張
    4.8　まとめ

5章　データレイク
    5.1　データレイクとは何か
    5.2　データレイクを使用する理由
    5.3　ボトムアップアプローチ
    5.4　データレイク設計のベストプラクティス
    5.5　複数のデータレイク
        5.5.1　メリット
        5.5.2　デメリット
    5.6　まとめ

6章　データストレージソリューションとプロセス
    6.1　データストレージソリューション
        6.1.1　データマート
        6.1.2　オペレーショナルデータストア
        6.1.3　データハブ
    6.2　データ処理
        6.2.1　マスターデータ管理
        6.2.2　データ仮想化とデータフェデレーション
        6.2.3　データカタログ
        6.2.4　データマーケットプレイス
    6.3　まとめ

7章　設計手法
    7.1　オンライントランザクション処理とオンライン分析処理
    7.2　オペレーショナルデータと分析データ
    7.3　対称型マルチプロセッシングと超並列プロセッシング
    7.4　Lambda アーキテクチャ
    7.5　Kappa アーキテクチャ
    7.6　ポリグロット永続化とポリグロットデータストア
    7.7　まとめ

8章　データモデリング
    8.1　リレーショナルモデリング
        8.1.1　キー
        8.1.2　エンティティ・リレーションシップ図
        8.1.3　正規化ルールと形式
        8.1.4　変更のトラッキング
    8.2　ディメンショナルモデリング
        8.2.1　ファクト、ディメンション、キー
        8.2.2　変更のトラッキング
        8.2.3　非正規化
    8.3　共通データモデル
    8.4　データボルト
    8.5　Kimball とInmon のデータウェアハウジング手法
        8.5.1　Inmon のトップダウン手法
        8.5.2　Kimball のボトムアップ手法
        8.5.3　手法の選択
        8.5.4　ハイブリッドモデル
    8.6　手法に関する誤解
    8.7　まとめ

9章　データインジェスト手法
    9.1　ETL とELT
    9.2　リバースETL
    9.3　バッチ処理とリアルタイム処理
        9.3.1　バッチ処理のメリットとデメリット
        9.3.2　リアルタイム処理のメリットとデメリット
    9.4　データガバナンス
    9.5　まとめ

第III部　データアキテクチャ編

10章　モダンデータウェアハウス
    10.1　MDWアーキテクチャ
    10.2　MDWアーキテクチャのメリットとデメリット
    10.3　RDWとデータレイクの統合
        10.3.1　データレイク
        10.3.2　リレーショナルデータウェアハウス
    10.4　MDWへの足がかり
        10.4.1　EDW拡張
        10.4.2　一時的なデータレイクとEDWの組み合わせ
        10.4.3　オールインワン
    10.5　ケーススタディ：ウィルソン＆ガンカーク社のMDWへの移行戦略
        10.5.1　課題
        10.5.2　ソリューション
        10.5.3　アウトカム
    10.6　まとめ

11章　データファブリック
    11.1　データファブリックアーキテクチャ
        11.1.1　データアクセスポリシー
        11.1.2　メタデータカタログ
        11.1.3　マスターデータ管理
        11.1.4　データ仮想化
        11.1.5　リアルタイム処理
        11.1.6　API
        11.1.7　サービス
        11.1.8　製品
    11.2　MDWからデータファブリックアーキテクチャに移行する理由
    11.3　懸念事項
    11.4　まとめ

12章　データレイクハウス
    12.1　Delta Lake の機能
    12.2　パフォーマンスの向上
    12.3　データレイクハウスアーキテクチャ
    12.4　リレーショナルデータウェアハウスを組み込まない場合の懸念事項
    12.5　リレーショナルサービングレイヤー
    12.6　まとめ

13章　データメッシュの基礎
    13.1　非中央集権型データアーキテクチャ
    13.2　データメッシュブーム
    13.3　Dehghani 氏のデータメッシュの4 原則
        13.3.1　原則1：ドメインオーナーシップ
        13.3.2　原則2：プロダクトとしてのデータ
        13.3.3　原則3：セルフサービス型データ基盤プラットフォーム
        13.3.4　原則4：連合型計算ガバナンス
    13.4　「純粋な」データメッシュ
    13.5　データドメイン
    13.6　データメッシュ論理アーキテクチャ
    13.7　さまざまなトポロジー
    13.8　データメッシュとデータファブリック
    13.9　ユースケース
    13.10　まとめ

14章　データメッシュを採用すべきか。誤解、懸念、そして未来
    14.1　誤解
        14.1.1　誤解：データメッシュは、データに関するすべての課題を迅速に解決する「銀の弾丸」である
        14.1.2　誤解：データメッシュはデータレイクとデータウェアハウスを置き換える
        14.1.3　誤解：データウェアハウスプロジェクトはすべて失敗しており、データメッシュがその問題を解決する
        14.1.4　誤解：データメッシュを構築することは、すべてを完全に非中央集権化することである
        14.1.5　誤解：データ仮想化を使用してデータメッシュを作成できる
    14.2　懸念事項
        14.2.1　哲学的および概念的な問題
        14.2.2　非中央集権型環境におけるデータ結合
        14.2.3　非中央集権化に関するその他の課題
        14.2.4　複雑さ
        14.2.5　重複
        14.2.6　フィージビリティ
        14.2.7　人材
        14.2.8　ドメインレベルの障壁
    14.3　組織アセスメント：データメッシュを採用すべきか？
    14.4　データメッシュの実現に向けた推奨事項
    14.5　データメッシュの未来
    14.6　ズームアウト：データアーキテクチャとアプリケーション
    14.7　まとめ

第IV部　人、プロセス、テクノロジー編

15章　人とプロセス
    15.1　チーム編成：役割と責任
        15.1.1　MDW、データファブリック、データレイクハウスにおける役割
        15.1.2　データメッシュにおける役割
    15.2　プロジェクトが失敗する理由：落とし穴と予防策
        15.2.1　落とし穴：経営陣の「BI は簡単だ」という思い込み
        15.2.2　落とし穴：間違ったテクノロジーの使用
        15.2.3　落とし穴：ビジネス要件を収集しすぎること
        15.2.4　落とし穴：ビジネス要件の収集が不十分
        15.2.5　落とし穴：内容を検証せずにレポートを提示すること
        15.2.6　落とし穴：経験不足のコンサルティング会社を採用すること
        15.2.7　落とし穴：開発をオフショアチームに外注するコンサルティング会社を契約してしまうこと
        15.2.8　落とし穴：プロジェクトのオーナーシップをコンサルタントに委ねてしまうこと
        15.2.9　落とし穴：知識の組織へのフィードバックの必要性を軽視
        15.2.10　落とし穴：プロジェクトの途中で予算を大幅削減すること
        15.2.11　落とし穴：終了日を先に設定し、逆算で計画を立てること
        15.2.12　落とし穴：データウェアハウスをビジネスニーズではなくソースデータに合わせて設計すること
        15.2.13　落とし穴：エンドユーザーに、応答速度が遅いなどパフォーマンスに問題のあるソリューションを提供すること
        15.2.14　落とし穴：データアーキテクチャの設計に時間をかけすぎる（または、時間をかけなさすぎる）こと
        15.2.15　落とし穴：IT 部門とビジネスドメイン間のコミュニケーション不足
    15.3　成功のためのヒント
        15.3.1　投資を惜しまないこと
        15.3.2　ユーザーを巻き込み、結果を示し、彼らをやる気にさせること
        15.3.3　新しいレポートとダッシュボードに価値を追加すること
        15.3.4　エンドユーザーにプロトタイプを作成してもらうこと
        15.3.5　プロジェクトチャンピオン／スポンサーを探すこと
        15.3.6　プロジェクト計画を作成するときは、80% の効率を想定すること
    15.4　まとめ

16章　テクノロジー
    16.1　プラットフォームの選択
        16.1.1　オープンソースソリューション
        16.1.2　オンプレソリューション
        16.1.3　クラウドプロバイダーソリューション
    16.2　クラウドサービスモデル
        16.2.1　主要なクラウドサービスプロバイダー
        16.2.2　マルチクラウドソリューション
    16.3　ソフトウェアフレームワーク
        16.3.1　Hadoop
        16.3.2　Databricks
        16.3.3　Snowflake
    16.4　まとめ

索引

コラム目次
    ADS 質問集
    ETL とELT を混同しない方法