オライリー・ジャパンから 2026 年 2 月にデータアーキテクチャの入門書が発売されたということで、ちょうどデータレイク周りをキャッチアップしたかったタイミングだったので、早速購入してみました。
https://www.amazon.co.jp/dp/4814401507
著者の James Serra 氏は IT 業界歴 40 年、ここ 15 年はデータウェアハウスに取り組んできた方で、執筆時点での肩書は Microsoft のデータアーキテクトです。本書は、RDW・データレイク・モダンデータウェアハウス・データファブリック・データレイクハウス・データメッシュといった、ここ十数年で登場してきた主要なデータアーキテクチャを、それぞれの設計思想とトレードオフから整理する一冊で、データアーキテクト向けの初級〜中級程度の内容を網羅的に扱っています。
内容自体はググれば出てくるものも多いのですが、著者の視点や長年の経験に基づいた言及が随所にあり、単なる用語集ではなく生きた知識になっている印象でした。これからデータ基盤に取り組む人や、各アーキテクチャの違いを自分の言葉で説明できるようになりたい人に向いていると思います。
なお、本書はあくまで各概念の概説であって、具体的な構築の手順が紹介されているわけではありません。キーワードの把握やアーキテクチャ選定の勘所をつかむのには向いていそうですが、現場ですぐに活かせるわけではなさそうです。また、各システムの RDB などのデータを集約して活用する、というのが大きな趣旨なので、RDB について多少知っておいたほうが読みやすいと思います。
以下、各章でどんな学びがあったかまとめています。また、より詳細な章立ては こちら から確認することができます。
第 I 部 基礎
第 I 部は、ビッグデータとは何か、組織のデータ活用はどの段階にあるのか、そしてどんなデータアーキテクチャが存在するのか、という土台の部分です。最後の章では、それらをビジネス目標と擦り合わせる「アーキテクチャデザインセッション（ADS）」という進め方が紹介されています。
１．ビッグデータ
最初の章はビッグデータの定義と、企業におけるデータ活用の現状から始まります。データを「V」で始まる複数の特性で定義する話や、データを石油にたとえる話などが出てきますが、このあたりは比較的一般的な内容でした。
参考になったのは、組織のデータ活用レベルを段階で評価する「エンタープライズデータマチュリティ」という考え方です。MLOps 界隈の成熟度モデル（3大クラウド各社の MLOps 成熟度モデルの比較 など）は聞いたことがありましたが、そのデータ活用版にあたるのかなと理解しました。成熟度モデル自体はさまざまなものが提案されているようで、データマチュリティってなんだよ（Data Maturity） なども参考になりました。最終的に目指すのは、IT 部門を介さずに全社員が自分の欲しいデータを欲しい形で扱える「セルフサービス BI」の状態で、そのゴールから逆算してデータアーキテクチャを考えていく、という流れだと理解しました。
２．データアーキテクチャの種類
この章では、RDW・データレイク・モダンデータウェアハウス（MDW）・データファブリック・データレイクハウス・データメッシュという主要なアーキテクチャを、歴史的な進化の流れとともに概観しています。各アーキテクチャの概要そのものは、ググればわかる範囲の内容です（たとえば いまさら聞けない！「レイクハウス」と DWH、データレイクの違いとは のような記事が参考になります）。
この章で価値があると感じたのは、各アーキテクチャを「中央集権か否か」「スキーマオンライトかスキーマオンリードか」「コストや運用難易度」といった複数の観点で横並びにした比較表でした。この 1 枚で全体像の見通しがかなり良くなった感触がありました。なお、各アーキテクチャの詳細は 4 章以降で扱われます。
３．アーキテクチャデザインセッション
ADS は、どんなデータを集めて加工し、どんな出力を経て、どんなビジネス価値を生むのか、をステークホルダーが一堂に会して議論する場と位置づけられています。データソリューションの方針を固め、PoC などのネクストアクションを決めるのがゴールとされています。
この章は、事前準備から当日の進行、開催後のフォローまでを、著者の経験に基づく運営ノウハウとして具体的に扱っているのが特徴です。この手の実運用の知見は検索ではなかなか得にくく、本書の価値が出ている部分だと感じました。ただ、私自身がそういう仕事をしているわけではないので、ここに書かれているノウハウが日本のシーンにマッチしているかは判断できていません。
第 II 部 データアーキテクチャの共通概念
第 II 部は、各アーキテクチャを語るうえで共通して登場するビルディングブロックの解説です。RDW・データレイクといった器から（4-5 章）、ストレージソリューション、設計手法、モデリング、インジェストまで（6-9 章）、多くの概念が一通り整理されます。用語の辞書としても使える部でした。
４．リレーショナルデータウェアハウス
RDW は、複数のソースから構造化データを統合する中央リポジトリとされます。このアプローチでは一般に ETL データパイプラインがセットで構築されます。私は AWS を仕事で扱っているのですが、AWS でいえば Redshift にあたるのかなという理解です。
単に DB をコピーしただけのものや、ビューで結合しただけのものは DW とは呼べない、というアンチパターンの整理や、活用目的（可視化・レポート作成など）から逆算して設計するトップダウンアプローチの考え方が説明されています。また、データレイクが成熟すれば長期的に RDW は不要になるのか、という問いに対して著者が懐疑的な立場をとっているのも印象的でした。平たく言えば、クレンジング済みのデータを SQL で扱える RDW は利用のハードルが低く、RDW で十分な人がわざわざ移行する必要はない、という主張でした。
５．データレイク
データレイクは、未加工の構造化/非構造化データをとりあえず元の形のまま溜めておく場所です（AWS 的にいえば S3 のようなものなのでしょうか？）。スキーマオンリードのため、利用時に好きな加工を施せる柔軟さがあり、整合性維持のためのメンテナンス時間も不要で、最低限ストレージさえあれば計算資源は目的に応じてオンデマンドで用意すればよいため、一般的に RDW より低コストなのだそうです。
この章で重要だと感じたのは、事前設計なしにデータレイクを作るとただの「データスワンプ（管理不能なデータの塊）」になってしまう、という指摘です。生データ・クレンジング済み・プレゼンテーションといった論理レイヤに分ける、フォルダ構造やアクセス制御・ライフサイクル・メタデータを設計する、といった具合に、データレイクとはいえ事前に決めておくべきことは意外と多く、とりあえず格納すればよいというものではない、という点が印象的でした。
６．データストレージソリューション
ここでは、データを貯めておくコンポーネント（データマート、オペレーショナルデータストア、データハブなど）と、それを管理する処理プロセス（マスターデータ管理、データ仮想化、データカタログ、データマーケットプレイスなど）を紹介しています。
なかでもデータ仮想化は、データを物理的に移動させずに論理的な統合ビューを提供する、という考え方です。物理的にデータを移動させる方式と、移動させずに参照する仮想化とを、コストやセキュリティ・データの鮮度といった観点で比較しており、どちらを採るかの判断材料になりそうでした。
７．設計手法
ここでは、システムの速度と信頼性を高めるための設計手法をまとめています。OLTP と OLAP、SMP と MPP といった対比に加え、バッチとストリームの両方を扱う Lambda アーキテクチャと、ストリーム処理に一本化した Kappa アーキテクチャが紹介されています（この 2 つはいまいちピンとこなかったのですが AWS で実現する Lambda アーキテクチャと Kappa アーキテクチャ などを追加で読んで補強しました）。最後に出てくるポリグロット永続化（用途に応じて複数のデータストレージを使い分ける設計）は、マイクロサービスの文脈で聞いたことがありました。
８．データモデリング
ここでは、データを整理・理解するための論理構造をまとめています。主に、正規化を前提とするリレーショナルモデリングと、分析を効率化するためのディメンショナルモデリングが対比されています。私の場合、前者のほうにしか馴染みがなかったので、ディメンショナル・モデルの概要とこれからの活用局面（１） などで理解を補いました。
９．データインジェスト
ここでは、ソースからデータを取り込むインジェスト手法をまとめています。事前にクレンジングする ETL とオンデマンドで変換する ELT の整理から始まり（参考：ETL と ELT）、分析結果を業務システムに書き戻すリバース ETL や、バッチとリアルタイムの使い分け、そしてデータガバナンスの話へと進みます。インジェストまわりの選択肢を一通り見渡せる構成でした。
第 III 部 データアーキテクチャ
第 III 部は、主要 4 アーキテクチャ（MDW・データファブリック・データレイクハウス・データメッシュ）の詳細です。IT 部門が中央で管理する集権型から、ビジネスドメインが自らデータを所有する非集権型へ、という流れと、そのトレードオフ（俊敏性と引き換えの複雑さ・コスト）が軸になっています。
１０．モダンデータウェアハウス
MDW は、RDW (4 章) の堅牢性とデータレイク (5 章) の柔軟性を組み合わせたものです。基本的にはデータをまずデータレイクに取り込み、その一部をモデル化して RDW にコピーし、可視化や分析に使う、という構成になります。ネックは複雑さとコストで、最近はデータレイクを直接クエリして可視化・分析までできるようになってきた（→ 12 章データレイクハウス）ということでした。扱うデータの種類や規模に応じて RDW・MDW・データファブリックなどを選び分ける、という目安も示されていて参考になりそうでした。
１１．データファブリック
データファブリックは MDW の進化形で、リアルタイム処理やデータアクセスポリシー、メタデータカタログといった要素を加え、サイロ化したシステムを仮想的に統合しようとするものとされています。ただ、MDW とデータファブリックをあまり区別しない立場もあるようで、著者独自の定義との違いや、提唱されている技術の一部はまだ実用化に至っていない、という現実的な指摘もありました。大規模化や多様化には対応しやすい一方、初期コストの重さは相変わらずなので、小規模なら MDW で十分、という整理の仕方でした。
１２．データレイクハウス
データレイクハウスは、MDW（or データファブリック）から RDW を抜いたようなもので、データレイクにレイヤを追加して RDW のように扱えるようにしたものです。そのレイヤにあたるのが Delta Lake・Apache Iceberg・Apache Hudi などのテーブルフォーマットで、ACID トランザクションやスキーマ強制、タイムトラベルといった機能をデータレイク上で実現するようです（各フォーマットの違いについては テーブルフォーマットのファイル構造を比較する(Iceberg, Delta Lake, Hudi, Paimon) などいくつか記事が見つかります）。
一方でトレードオフもあり、一般に RDB へのクエリのほうが速く、行レベル・列レベルのセキュリティのような高度な機能はまだ追いついていない場合がある、と整理されています。慣れたユーザーが新しい環境へ移る際の再トレーニングといった人的なコストにも触れられていて、メリットだけでなく欠点も正直に書かれている点に好感を持ちました。ちなみに、Delta Lake については 詳解 データレイクハウスアーキテクチャ – O’Reilly Japan でメイントピックとして扱われているようで、もし実務で触ることがあれば読んでみようと思います。
１３．データメッシュの基礎
データメッシュは、中央の IT チームが管理する従来モデルの限界を打破するために提唱された、非中央集権のアーキテクチャ概念です。各ドメインチームが自分たちのデータを所有し、それをプロダクトとして他チームに提供する、といった原則から成ります（4 つの原則は ズバッと解説 データメッシュとは がコンパクトにまとまっています）。
注目すべきは、著者がこの概念にかなり否定的なことです。本番環境で実際に運用している企業を見たことがない、という実感や、単にデータを複数箇所で管理するだけでは「データフェデレーション」であってデータメッシュとは呼べないのではないか、といった立場が率直に語られます。このあたりをさらに深掘りしたい場合は、同じオライリーの 大規模データ管理 第2版 が詳しそうでした。
１４．データメッシュの詳細
前章の続きで、データメッシュ導入で直面する誤解や懸念が整理されています。専門人材を各ドメインに配置する難しさや、ドメインをまたぐ結合のパフォーマンス、そしてかつての分散型データマートが招いた混乱の歴史を繰り返すのではないか、といった指摘などがありました。章の最後には、ここまで見てきた各アーキテクチャをどう使い分けるかのまとめがあり、第 III 部の総括として頭の整理に役立ちます。
第 IV 部 人、プロセス、テクノロジー
最後の第 IV 部は実践編で、優れたアーキテクチャを絵に描いた餅で終わらせないための「人・プロセス・テクノロジー」の話です。ツール選定だけでなく、それを動かす人間の役割分担や、失敗を避けるためのプロセスこそが成否を分ける、というメッセージで、DevOps の文脈でもこの 3 本柱の話は聞いたことがあるな、という感想です。
１５．人・プロセス
データアーキテクチャは技術を採用するだけでは成功せず、組織文化（データの活用方法）を変えることが重要、というのが基本的なメッセージです。データアーキテクト・データエンジニア・データスチュワード・DBA・データサイエンティストなど、必要なロールが一通り定義され、データメッシュの場合はさらにロールが増えることも示されています。
個人的に響いたのは、著者が経験したプロジェクトの頓挫理由と成功理由が対比されている部分です。技術以前に、経営層やユーザーをどう巻き込み、どう価値を示すか、といった泥臭いところで成否が分かれる、という話はデータ活用以外のシーンでもよく聞くので説得力がありました。こうした実践知は検索では拾いにくく、本書ならではの読みどころだと思います。
１６．テクノロジー
最後はテクノロジーとプラットフォームの選択です。インフラはスケーラビリティやマネージドサービスの活用という観点からクラウドが基本で、仮想化の度合いとしては PaaS あたりがちょうどよい、というお話でした。IaaS/PaaS/SaaS のトレードオフや、マルチクラウド戦略のメリットと難しさにも触れられています。
その上で動かすソフトウェアフレームワークとして、Hadoop・Databricks・Snowflake の 3 つが取り上げられます（Databricks と Snowflake の設計思想の違いは Databricks と Snowflake は何が根本的に違うのか が参考になります）。Hadoop は 2010 年代に人気を集めたがクラウドの進化でシェアは減少傾向にあること、Databricks は Spark エコシステムをクラウド上に展開しつつ独自開発も進めていること、Snowflake はデータウェアハウスをクラウド上に展開しデータレイクとしても機能すること、といった整理に加え、オープンソースの歴史的な経緯まで説き起こす構成になっていて、技術選定の背景を俯瞰できる章でした。
おわりに
ここまで各章を見てきましたが、本書は、データアーキテクチャという広い領域を、用語の定義から各アーキテクチャの選び分けまで、一冊で見渡せるようにしてくれる本でした。個々のトピックはそれぞれ専門書やネット上に無料の解説記事があるテーマばかりですが、まずは全体の地図を手に入れたい、各アーキテクチャの違いを自分の言葉で説明できるようになりたい、という段階の人にはちょうどよい一冊だと思います。一方で、具体的な構築手順やコードまで求める人には物足りないはずなので、そこは別の書籍やドキュメントで補う前提で手に取るのがよさそうです。同じオライリー・ジャパンの書籍でいえば、未読ですが クラウドデータレイク – O’Reilly Japan あたりがネクストステップの候補となりそうです。
コメント