はじめに
データ基盤の話になると、いつのまにか「どのツールを使うか」という議論になりがちです。Snowflakeか BigQueryか、dbt を入れるか、Airflowか Dagsterか。もちろん重要な論点ではありますが、その手前にある「そもそも何を作ろうとしているのか」「なぜそれが必要なのか」という問いは、意外と語られないまま進んでしまいます。
本書『データエンジニアリングの基礎』は、まさにその手前の部分を丁寧に言語化した一冊です。特定の製品の使い方はほとんど出てきません。その代わりに、データを扱うシステムがどんな段階を経て価値になるのか、その各段階で何を判断しなければならないのかを、一貫したフレームワークで説明していきます。
設計やアーキテクチャに関心のあるエンジニアにとって、本書は「データ領域版のアーキテクチャ入門」として読める内容になっています。この記事では、本書の構成と中心概念、そして読んでいて印象に残った視点を整理してご紹介します。
書誌情報
| 項目 | 内容 |
|---|---|
| 書名 | データエンジニアリングの基礎 ―データプロジェクトで失敗しないために |
| 原題 | Fundamentals of Data Engineering |
| 著者 | Joe Reis、Matt Housley |
| 訳者 | 中田 秀基 |
| 出版社 | オライリー・ジャパン |
| 発行 | 2024年3月25日 初版第1刷 |
| ISBN | 978-4-8144-0065-2 |
著者の2人は、自らを「回復期のデータサイエンティスト」と冗談めかして名乗っています。適切な基礎知識を持たないままデータサイエンスのプロジェクトを任され、データ収集やクレンジング、アクセス、変換、インフラといった土台の部分で苦労した経験が本書の出発点になっている、と「まえがき」で述べられています。この立ち位置は本書全体のトーンによく表れていて、理論書というよりは「現場で何度も踏んだ地雷の地図」に近い読み味です。
本書が「しない」こと
本書の「まえがき」には、珍しく「本書は何ではないか」という節があります。ここで著者は、本書が特定のツール・技術・プラットフォームの解説書ではないことをはっきり宣言しています。理由もはっきりしていて、そうした本は寿命が短いからです。
個々のツールの資料は世の中に十分ある。しかし、それらのコンポーネントを組み合わせて実世界で使える一貫したシステムにする方法については良い資料がなく、エンジニアが苦しんでいる。本書はそのギャップを埋める――というのが著者の問題意識です。
この宣言は誠実だと感じました。逆に言えば、「明日から使える手順書」を期待して読むと肩透かしになります。本書が提供するのは手順ではなく、判断の枠組みです。
なお本書はクラウドファーストの立場を明確に取っており、著者はそれについて「謝罪する気はない」と書いています。インフラは短命（ephemeral）でスケーラブルなものだという前提に立っているため、オンプレミス中心の環境で読む場合は、そこは差し引いて読む必要があります。
中心概念1：データエンジニアリングライフサイクル
本書の背骨になっているのが「データエンジニアリングライフサイクル」という概念です。データが価値になるまでの流れを、次の5つのステージに分解します。
- 生成（ソースシステム）
- 保存（ストレージ）
- 取り込み
- 変換
- 提供
著者による定義はこうです。データエンジニアリングとは、生データを取り込み、下流の分析や機械学習などで利用しやすい高品質で一貫性のある情報を生成するシステムとプロセスの、開発・実装・維持管理である。そしてデータエンジニアは、このライフサイクルを管理する役割を担う、と。
このモデルの価値は、議論の焦点をテクノロジからデータそのものへと引き戻してくれる点にあります。「Kafka を入れるべきか」ではなく「取り込みステージにおける頻度・信頼性・ペイロードの要件は何か」という問いに変換される。要件が先で、道具が後になります。
著者は、ツールやベンダは現れては消えていくが、このライフサイクル自体は本質的に変わっていない、という観察を繰り返し強調しています。実際、本書の第II部はこの5ステージにほぼ1章ずつを割り当てる構成になっており、この枠組みが本の骨格そのものになっています。
中心概念2：底流（undercurrents）
もう1つの中心概念が「底流（undercurrents）」です。これはライフサイクルの特定のステージに属するのではなく、全ステージを縦に貫く観点を指します。
- セキュリティ
- データ管理
- DataOps
- データアーキテクチャ
- オーケストレーション
- ソフトウェアエンジニアリング
この6つが、ライフサイクルの各ステージすべてに関わってきます。本書の各章の末尾には、必ず「底流」という節が置かれていて、そのステージにおける6観点の具体的な影響が整理されます。この繰り返し構造が本書を読みやすくしている大きな要因だと感じました。
底流の筆頭がセキュリティであることには意味があります。著者は、データエンジニアにとってセキュリティは最重要課題であり、無視することは危険だとして、最小権限の原則の徹底を求めています。セキュリティ経験の浅いエンジニアが全ユーザに管理者権限を与えてしまうのは典型的なアンチパターンだ、という指摘は耳が痛い人も多いのではないでしょうか。
また、どの企業でも最大の脆弱性は人と組織構造である、という指摘も印象的でした。技術的対策の前に、組織全体にセキュリティの文化を浸透させることが第一の防御策になる、と述べられています。
各章のハイライト
第I部 データエンジニアリングの基礎と構成要素
1章 データエンジニアリング概説
まず「データエンジニアリングとは何か」の定義から始まります。著者は複数の既存定義を並べたうえで、それらに共通するパターンを抽出して自分たちの定義を組み立てるという、丁寧な手続きを踏んでいます。
歴史パートも面白く読めました。データウェアハウスに端を発し、Inmon と Kimball のモデリング手法、MPP データベース、ドットコムブーム、Google の GFS / MapReduce 論文、Hadoop の登場、そしてクラウドへ。「歴史は繰り返さないが、韻を踏む」という見出しの通り、古い概念が形を変えて再登場するパターンが繰り返し指摘されます。
もう1つ有用なのが、データエンジニアの役割を「タイプA（抽象化）」から「タイプB（構築）」までのスペクトラムとして捉える整理です。同じ職種名でも、組織のデータ成熟度によって求められる仕事がまったく違うことが明快に説明されます。
2章 データエンジニアリングライフサイクル
前述の5ステージと6つの底流を、それぞれ詳細に展開する章です。本書の設計図にあたる章なので、ここを丁寧に読んでおくと以降の章の見通しがよくなります。
データ管理の節では、DAMA DMBOK の定義を引きながら、データガバナンス・メタデータ管理・マスターデータ管理・データ品質といったトピックが扱われます。著者は「データエンジニアリングは『大企業的』になりつつある」と表現していますが、これはネガティブな意味ではなく、かつて大企業だけのものだった規律があらゆる規模の組織に降りてきた、という前向きな評価として述べられています。
データガバナンスが機能しない例として挙げられているエピソードが具体的でした。アナリストがどのテーブルを使えばいいか分からず、何十ものテーブルを当てずっぽうに探し、「方向性は正しい」レポートを作る。受け取る側も妥当性を疑う。結果として、会社の業績すら分からなくなる――という連鎖です。
3章 適切なデータアーキテクチャの設計
設計・アーキテクチャに関心があるなら、本書で最も読み応えのある章です。
著者はまずエンタープライズアーキテクチャを「柔軟性とトレードオフのバランスを取ること」と定義し、そのサブセットとしてデータアーキテクチャを位置づけます。そして自分たちの定義として、「企業の進化するデータへの要求をサポートするシステムの設計であり、トレードオフを慎重に評価した上での柔軟で可逆な決定を通じて実現される」を提示します。
「可逆」という言葉が定義に組み込まれているのがポイントです。
そのうえで、良いデータアーキテクチャの9原則が示されます。
| 原則 | 内容 |
|---|---|
| 原則1 | 共通コンポーネントを賢く選択する |
| 原則2 | 障害に備える |
| 原則3 | スケーラビリティ設計 |
| 原則4 | アーキテクチャはリーダーシップだ |
| 原則5 | 常に設計し続ける |
| 原則6 | 疎結合システムを構築する |
| 原則7 | 可逆な決定をする |
| 原則8 | セキュリティを優先する |
| 原則9 | FinOps を活用する |
AWS Well-Architected Framework と Google Cloud の「5つの原則」を下敷きにしつつ、データ領域向けに練り直したものだと説明されています。
特に印象に残ったのは原則6と原則7です。
原則6の疎結合については、2002年のいわゆる「ベゾス API 指令」が引かれています。すべてのチームはサービスインタフェース経由でのみ通信すること、直接リンクや他チームのデータストアの直接読み込みは一切禁止、そしてすべてのインタフェースは外部公開できる前提で設計すること。この指令が AWS 誕生の分水嶺になったという評価です。
さらに著者は、この技術的特性を組織の特性に置き換えて論じます。疎結合なアーキテクチャは疎結合なチーム編成を可能にし、各チームが他チームと無関係にコンポーネントを進化させられるようになる、と。コンウェイの法則を設計側から扱っている議論として読めます。
原則7の「可逆な決定」では、ベゾスの「双方向ドア」の比喩が紹介されます。通り抜けて気に入らなければ戻れる決定と、戻れない決定を区別し、可能な限り前者を目指せというものです。Martin Fowler の「アーキテクトの最も重要な仕事の1つは、ソフトウェア設計における不可逆性を排除する方法を見つけること」という言葉も引かれています。
章の後半では、データウェアハウス、データレイク、データレイクハウス、モダンデータスタック、Lambda アーキテクチャ、Kappa アーキテクチャ、Dataflow モデル、IoT 向けアーキテクチャ、データメッシュといった代表的なアーキテクチャパターンが横並びで比較されます。それぞれの前提と限界が短くまとまっているので、カタログとしても使えます。
冒頭に置かれた「最も良いアーキテクチャを目指してはいけない。最悪ではないアーキテクチャを目指せ」という引用（『ソフトウェアアーキテクチャの基礎』より）が、この章全体のトーンをよく表しています。
4章 データエンジニアリングライフサイクルにおけるテクノロジの選択
著者は「アーキテクチャとテクノロジをまとめて議論することが多いが、これら2つはまったく異なる」と明言しており、3章と4章を意図的に分けています。3章が「何を」、4章が「何で」に対応します。
判断軸として挙げられるのは、チームのサイズと容量、市場投入までのスピード、相互運用性、コスト最適化とビジネス価値、そして設置場所です。コストの節では TCO に加えて「所有の総機会費用」という概念が導入されるのが特徴的でした。あるツールを選ぶことで選べなくなったものの価値まで含めて評価する、という考え方です。
さらに、以下の対立軸がそれぞれ節を立てて検討されます。
- 不変テクノロジ vs. 一過性テクノロジ
- オンプレミス vs. クラウド vs. ハイブリッド vs. マルチクラウド
- 構築 vs. 購入（OSS vs. プロプライエタリ）
- モノリス vs. モジュール
- サーバレス vs. サーバ
各節の末尾に「アドバイス」という小節が置かれ、著者の立場が明示されるのが親切です。曖昧に両論併記して終わらせず、条件つきで踏み込んだ推奨をしてくれます。
「分散モノリスパターン」への言及も実務的でした。マイクロサービスに分割したつもりが、結局密結合のまま分散しただけになる失敗パターンです。
最後の「最適化、性能、ベンチマーク戦争」の節では、ベンダのベンチマークがいかに無意味な比較になりやすいかが辛口に語られます。非対称な最適化の話は、製品選定でベンチマーク資料を見る機会がある人には特に読む価値があります。
第II部 データエンジニアリングライフサイクルの詳細
著者自身が「このII部が間違いなく本書の中心であり、他の部はこの部で説明する核となる考え方を支持するために存在する」と書いている、本書の核です。
5章 ソースシステムにおけるデータ生成
データが生まれる場所の章です。ファイル、API、OLTP データベース、OLAP システム、CDC、各種ログ、CRUD とインサートオンリー、メッセージとストリームといった概念が整理されます。
時間の扱いに1節が割かれているのが良かった点です。イベント時刻・取り込み時刻・処理時刻の区別は、後の章（特に7章の遅延到着データや8章のストリーム処理）で効いてきます。
データエンジニアはソースシステムを所有していないことが多い、という前提のもとで、上流の変更にどう備えるかという視点が一貫しています。スキーマ進化への対応は、その代表例です。
6章 ストレージへの保存
磁気ディスク、SSD、RAM、ネットワーク、CPU といった物理層の特性から始まり、シリアライズ、圧縮、キャッシュを経て、ファイル／ブロック／オブジェクトストレージ、HDFS、ストリーミングストレージへと積み上がっていく構成です。
下から積み上げる構成のおかげで、「なぜオブジェクトストレージがこれほど中心的になったのか」「なぜコンピュートとストレージの分離が主流になったのか」が納得感をもって理解できます。インデックス、パーティション分割、クラスタリングの節も実用的でした。
データウェアハウス／データレイク／データレイクハウスを「ストレージ抽象」として並べて整理する視点は、用語が混乱しがちなこの領域では特に有用です。
7章 データ取り込み
本書で最もページ数が多く、実務的な章です。
前半では検討事項が体系化されます。区切りありデータと区切りなしデータ、頻度、同期と非同期、シリアライズとデシリアライズ、スループット、信頼性と耐久性、ペイロード、そしてプッシュ／プル／ポーリング。
後半ではバッチ取り込みとストリーム取り込みがそれぞれ扱われます。ETL と ELT の比較、スナップショットと差分抽出、そしてストリーム側ではスキーマ進化、遅延到着データ、順序と多重配送、リプレイ、TTL、デッドレターキューといった論点が並びます。
取り込み方法のカタログも網羅的で、直接データベース接続、CDC、API、メッセージキュー、マネージドコネクタ、オブジェクトストレージ経由、EDI、Webhook、Web スクレイピング、さらには物理的な転送アプライアンスまで登場します。
「一緒に仕事する人」という節が上流・下流の利害関係者に分けて書かれているのも、この章の性格をよく表しています。取り込みは技術というより交渉の仕事でもある、というメッセージが読み取れます。
8章 クエリ、データモデリング、変換
クエリのライフサイクル、クエリオプティマイザ、性能改善から始まり、データモデリングへ進みます。
モデリングの節では、概念・論理・物理の3層、正規化、そしてバッチアナリティクス向けの主要な手法（Inmon、Kimball、Data Vault など）が扱われます。ストリームデータのモデリングという、比較的まとまった資料の少ない話題にも節が割かれています。
変換の節では、バッチ変換、マテリアライズドビュー、フェデレーテッドクエリ、データ仮想化、ストリーミング変換が整理されます。
設計に関心のある読者には、この章と3章をセットで読むことをおすすめします。アーキテクチャの原則が、データモデルという具体物にどう落ちるかが見えてきます。
9章 アナリティクス、機械学習、リバースETLへのデータの提供
ライフサイクルの出口にあたる章です。ここで最初に問われるのが「ユースケースは何か？ ユーザは誰か？」という問いなのが、本書らしいところです。
「データプロダクト」という概念が導入され、良い定義として「データの利用によって最終目標の達成を促すプロダクト」が示されます。作って終わりではなく、使われて初めて意味を持つ、という当然だけれど忘れられがちな前提です。
信頼の節に置かれた「評判を築くには20年かかるが、台無しにするには5分で済む」という引用は、データ基盤の運用に携わったことがあれば実感を伴って読めるはずです。一度でも数字が合わないことがあると、その後どれだけ正しくても疑われ続けます。
提供方法としては、ファイル交換、データベース、ストリーミング、クエリフェデレーション、データ共有、セマンティックレイヤ／メトリクスレイヤ、ノートブックが並びます。最後にリバースETL――分析結果を業務システムに戻す流れ――が扱われます。
第III部 セキュリティとプライバシー、およびデータエンジニアリングの未来
10章 セキュリティとプライバシー
人・プロセス・テクノロジの3層で整理される章です。
「人材」の節では、ネガティブ思考の力、常に心配性でいること、といった心構えから入ります。「プロセス」では、劇場型セキュリティと習慣としてのセキュリティの対比が印象的でした。監査のための形式的な対策ではなく、日常の習慣として組み込まれているかどうかが問われます。
最小権限の原則、クラウドでの責任共有モデル、バックアップの徹底といった基本が繰り返し強調され、「テクノロジ」ではパッチ管理、暗号化、ロギング・監視・アラート、ネットワークアクセスが扱われます。
GDPR や CCPA 以降、プライバシーの軽視が法的な結果を伴うようになったという指摘も、まえがきから一貫しています。
11章 データエンジニアリングの未来
著者自身が「非常に不確かな予測」と断ったうえでの展望です。
- データエンジニアリングライフサイクルは消えない
- 複雑さは衰退し、使いやすいデータツールが興隆する
- クラウドスケールのデータOSと相互運用性の改善
- データエンジニアリングの「大企業化」
- 職種名と担当範囲は変化する
- モダンデータスタックからライブデータスタックへ
ツールが簡単になればデータエンジニアは不要になるのでは、という見方に対して、著者は明確に反論しています。ツールが使いやすくなればデータエンジニアはバリューチェーンの上位に移動し、より高度な業務に専念するようになる、という立場です。
これはデータ領域に限らず、抽象化が進む技術分野全般に当てはまる話だと感じました。
付録
- 付録A：シリアライズフォーマット、データベースストレージエンジン、圧縮（gzip、bzip2、Snappy など）
- 付録B：クラウドネットワークのトポロジ、CDN、データエグレス料金
どちらも短いですが、本文に収まりきらなかった実務的トピックとして有用です。特に付録Bのエグレス料金の話は、クラウド設計のコスト構造を理解するうえで押さえておきたい内容でした。
印象に残った視点
アーキテクチャは「決定」であり、良い決定とは可逆な決定である
本書を通じて最も繰り返されるのがこの主張です。良いアーキテクチャの定義に「可逆」が組み込まれ、原則7として独立し、テクノロジ選択の章でも判断軸になります。
変化の速い領域では、正解を当てにいくより、間違えたときに戻れるようにしておくほうが期待値が高い。当たり前のようでいて、実際の設計では「戻りにくい決定」を無自覚に積み重ねてしまいがちです。
底流という縦串の発想
セキュリティやデータ管理を、ライフサイクルのどこか1ステージの責務にせず、全ステージを貫く観点として扱う設計は、そのまま他の分野にも応用できます。
「セキュリティ担当が最後にレビューする」構造ではなく、各ステージの設計判断にセキュリティ観点が組み込まれている状態を目指す。この構造化の仕方自体が、本書から持ち帰れる資産だと感じました。
技術的な話と組織の話が同じ章に同居している
原則4「アーキテクチャはリーダーシップだ」や、原則6の疎結合を組織構造に読み替える議論のように、本書は技術と組織を分けずに扱います。
データ基盤の失敗が純粋に技術的な理由で起きることは実は少なく、多くは所有権の曖昧さや、上流と下流のコミュニケーション不全に起因します。各章に「一緒に仕事する人」という節が置かれているのは、その認識の表れでしょう。
判断を保留しない
「アドバイス」節に代表されるように、著者は条件を明示したうえで自分の立場を述べます。両論併記で終わらせないので、読者は同意するにせよ反対するにせよ、自分の考えを言語化しやすくなります。
読む前に知っておくとよいこと
- 前提知識：SQL とプログラミング言語（Python など）の基礎、および何らかのクラウドサービスの利用経験が想定されています
- コードはほとんど出てきません：概念と判断の書です
- クラウド前提：オンプレミス中心の環境では、そのまま適用できない議論もあります
- 分量はあります：全11章＋付録2つで、7章と8章は特に厚めです
各章末の「参考資料」が充実しているのも本書の特徴です。気になったトピックはそこから深掘りできる構成になっています。
こんな人におすすめ
強くおすすめできる方
- データ基盤の設計に関わっている、あるいはこれから関わる方
- 個々のツールは触れるが、全体像が繋がっていない感覚がある方
- ソフトウェアアーキテクチャに関心があり、その視点をデータ領域に広げたい方
- 技術選定の判断軸を言語化したい方
- データチームのリードやマネジメントに携わる方
あまり向かない方
- 特定ツールの実装手順を求めている方
- コードを書きながら学びたい方
- すでにデータ基盤の設計を長く経験しており、体系化も済んでいる方
おすすめの読み方
- 1〜2章を丁寧に読む：ライフサイクルと底流という語彙を身につける
- 3章を時間をかけて読む：本書で最も設計に効く章
- 第II部（5〜9章）は自分の関心の近い章から：全部を順に読む必要はありません
- 10〜11章と付録は必要に応じて
再読するときは3章と4章だけ読み返す、という使い方もできます。原則リストが手元にあるだけで、設計レビューの質は変わってきます。
まとめ
本書の価値は、データ基盤という捉えどころのない対象に、「ライフサイクル×底流」という二次元の座標を与えてくれる点にあります。この座標があると、目の前の課題が全体のどこに位置していて、どの観点が抜けているのかを構造的に把握できるようになります。
そして本書が提示する原則の多くは、データ領域に閉じた話ではありません。可逆な決定を選ぶこと、疎結合を保つこと、セキュリティを後付けにしないこと、常に設計し続けること。これらはソフトウェア設計全般に通じる考え方です。
「データプロジェクトで失敗しないために」という副題は、やや控えめすぎるかもしれません。本書が実際に扱っているのは、変化し続ける環境の中でシステムをどう設計し、どう判断していくかという、もっと普遍的な問題だからです。
ツールは変わり続けます。だからこそ、変わらない部分を扱った本には長く読む価値があると思います。