Fundamentals of Data Engineering 輪読会資料 第17回分

この記事について

2022年に発売された書籍 Fundamentals of Data Engineering の輪読会が定期開催されています。
この記事は次回 英語で技術書を読もう：Fundamentals of Data Engineering 第17回 で議論する部分の要約です。

輪読会の流れ

以下の流れで進行しています。

• まず要約を要約担当が共有
• 本を読む過程で新しく覚えた英語表現や分からなかった英語表現を各人が共有
• 技術的に興味のある個所や分からなかった箇所を各人が共有、ディスカッション

英語とデータエンジニアリングの両方が勉強できてお得ですね。

第17回の範囲

Chapter2 The Data Engineering Lifecycle Serving Dataの一部分、The major undercurrents of data engineeringとして紹介されている要素のうち、DataOpsとデータアーキテクチャの概要を述べた部分になります。
自分は途中参加なのですが、参加者の要望の多いところを順不同で選んでいるということです。(第1回はChapter3 Good Data Architectureの一部分だったとのこと)

要約

DataOps

DataOpsとは、アジャイル手法、DevOps、SPC(統計的工程管理)をデータに適用したものである。
DevOpsはソフトウェアプロダクトのリリースサイクルの短縮と品質の改善が目的だが、DataOpsはデータプロダクトに対して同じことをする。
ソフトウェアプロダクトがユーザに技術的な機能を提供するが、データプロダクトはユーザのビジネス上の意思決定に関するビジネスロジックやメトリクスを中心に構築されている。このため、データエンジニアがソフトウェアプロダクトの技術的な側面だけではなく¹、ビジネスロジックやメトリクスも理解することがいいデータプロダクトの実現に繋がる。

DataOpsは次のようなことを可能にする。

• イノベーションや実験を素早く繰り返すことで、ユーザに提供する洞察を短期間で改善する
• データ品質を向上する
• 人材、テクノロジー、環境を横断してコラボレーションする
• 明確な測定とモニタリングを行い、洞察についての透明性を担保する

DataOpsは次のような組織風土が根付いていないといい成果が得られない：
ビジネスとコミュニケーション・コラボレーションして、サイロを打破して、成功事例や失敗事例から継続的に学ぶ…それらを素早く繰り返す。

DataOpsをどのように導入するかはその組織のデータ成熟度²によって異なる。
そもそもデータ基盤がないのであれば、ゼロから作り上げるチャンス。
データ基盤はあるがDataOpsはしていないのであれば、DataOpsを導入していくことができる。まずは後述のObservability and monitoringから始めるのがオススメ。
データ成熟度が高い組織では、データエンジニアはDataOpsチームと協力してデータエンジニアリングライフサイクルを改善していくことになるだろう。

DataOpsの重要な要素はAutomation、Observability and monitoring、Incident responseの3つである。それぞれ以下で述べる。

Automation

DataOpsにおいてもAutomation(自動化)は重要。それはDevOpsにおける変更管理、CI/CD、IaCと同じで、改善を素早く繰り返すために役立つ。

データ品質、データドリフトの有無、メタデータの正確さなどの計測を自動化することで、データの信頼性を担保することができる。
データ成熟度に応じた自動化の改善過程を想像してみると例えば以下のようになる：

• データ成熟度が低いときは、cronでジョブを順番に実行することでデータ変換を行っている。もしジョブが失敗したり遅延したりするとアナリストに適切なデータを提供できないが、そもそもアナリストから指摘されるまで問題が生じていることに気付かない。
• データ成熟度が高まるにつれて、AirflowやDagsterのようなDAG³ベースのオーケストレーションツールを使うようになる。オーケストレーションツールの運用は大変だが、得られるメリットがそれを上回るだろう。ジョブの依存関係を確認できるし、前のジョブが完了したら次のジョブがすぐに実行されるのでより多くのジョブを処理できるようになる。cronからは徐々に移行していくことになるだろう。
• さらなる改善の余地がある。例えば、DAGの登録にCI/CDを適用すれば信頼性が高まる。

DataOpsにおいては変化し続けることが大事である。「変化のための変化」ではなく、どうすれば仕事が楽になるか、ユーザに提供できる価値を向上できるか、目的を意識して改善していくことが必要。

Observability and monitoring

著者はよく「データは静かな殺し屋」と表現している。データに関する問題は発見されないままに致命的な結果を引き起こしがちである。
例えば間違ったデータが混入したまま数カ月気付かれない、という状況がしばしば存在する。もしそのデータに基づいて経営判断が下されたら…？
こういった悲劇を防ぐためにはSPCのようなアプローチが重要である。つまり、データパイプラインの各段でその処理性能や入出力されるデータの信頼性を指標化することである。
このような発想によるアプローチが以前の節でも紹介したDODD⁴である。
DODDでは、データのObservabilityが最優先検討事項に置かれている。

Incident response

DataOpsを高度に使いこなしているとしても、間違いは避けられないものである。
システムの故障を初めとして、データエンジニアリングライフサイクルのあらゆるところで様々な問題が生じうる。
Incident response(障害対応)とは、前述の自動化やObservabilityを活用することでより素早く原因特定し、それを解消することである。

障害対応には技術やツールも役立つがそれだけではない。チーム内外を問わないオープンで真摯なコミュニケーションも重要である。
Amazon.comのCTO、Werner Vogels氏が"Everything breaks all the time. (すべてのものはいつでも壊れる)"⁵と述べているように、データエンジニアは常に災害に備えなければならない。
データエンジニアはユーザが問題に気付いて報告してくる前にそれを発見しなければならない。ユーザからの報告で初めて問題を把握するよりも、ユーザが問題に気付いたときには既にその解決に向けて取り組んでいる方がユーザとの信頼関係が守られるからだ。
障害対応とは、問題が発生する前に予防的に対応することであり、問題が発生した後に事後的に対応することでもある。

まとめ

実際のところ、DataOpsはまだ発展途上のものである。先駆者たちがデータへのDevOpsの適用を通じて、DataOpsという概念を描き出したところである。
データエンジニアはDataOpsの実現に他の業務より優先して取り組むべきである。そうすることが、データプロダクトのリリースサイクルの短縮やデータの信頼性の向上を通じて、長期的にはより高い価値を生み出すからである。

データエンジニアリングはソフトウェアエンジニアリングと比べるとまだ少し未熟である。
例えばデータエンジニアリングに使われるツールには自動化に適していないものもある。
しかしながらAirflowのようなツールがその道を切り拓いている。本書に記載している実践は野心的なものであるが、自分たちの組織への適用に臨んでほしい。

データアーキテクチャ

データアーキテクチャはデータに関する長期的な要望や戦略から決まる。
しかしながら、組織からの要件は次々に変わり、またツールや事例も毎日のように新しいものが現れる。そのため、データエンジニアはそれに対応できるいいデータアーキテクチャを学ばなければならない。
詳細はChapter 3で述べる。

まず、データエンジニアはビジネスにおける要望を理解して、新しいユースケースから生じる要件を収集しないといけない。
次に、収集した要件から、コストと運用性のバランスを考慮した実現方法を検討しなければならない。
これにはデザインパターン、技術、あるいは様々なツールにおけるトレードオフを理解することが必要である。
これはデータエンジニアがデータアーキテクト⁶と同じということではない。データエンジニアはデータアーキテクトの設計を実現して、さらにアーキテクチャに関してフィードバックすることが望ましい。

よく分からなかった英語表現

原文	直訳	備考
greenfield	未開発の	いい意味で使うらしい。ブルーオーシャン的な？
hypothetical	仮説の	語源から科学的な考え方が感じられてちょっと面白い
(operational) burden	(運用上の)重荷
outweigh	上回る
have room for	～する余地がある	この表現好き。英語って感じ！
tenets	教義	クリストファー・ノーラン監督の映画、まだ見てない…
undermined	損なわれる
inevitably	避けられない
blameless	潔白な、誠実な
retroactive	過去に遡って、遡及的に	proactiveの逆かな？retrospectiveのretroだ
up-front	事前の
immature	未熟
aspirational	野心的な
the fullest extent possible	可能な限り最大限に

技術的に気になったポイント

アジャイル手法の思想を理解していないとDataOpsの説明が分かりにくい印象でした。ちょっとだけでもかじっていてよかった。かじっていなければ即死だった。

また、DataOpsの説明は本書でも引用されているDataKitchen社の記事が分かりやすかったです。
参考：What Is DataOps?

他の回のまとめ

輪読会の参加者の皆様が作成した他の回の資料のまとめはこちら。

1. データプロダクトが提供するデータは、ビジネス上の意思決定だけではなく、ソフトウェアプロダクトの開発にも役立つから、という意図だと思われる。 ↩

2. データ成熟度に関する解説記事：DX時代の成功を左右する「データ成熟度」とは？ ↩

3. 有向非巡回グラフのこと。ジョブの依存関係を表現するために用いられる。参考：DAGs - Airflow Documentation ↩

4. Data Observability Driven Development。データオブザーバビリティの運用・改善を組織全体の共通かつ重要な課題に位置付けることで組織内のデータの信頼性を高めるアプローチ。参考：Data Observability Driven Development (DODD): A Proactive Approach for Ensuring Data Quality and Reliability ↩

5. "Everything fails, all the time."と言うことも。2020年代前半から言い続けているそうです。参考：AWS re:Invent 2020ミニレポート ↩

6. データアーキテクトに関する解説記事：データアーキテクトとは？企業における役割と価値、求められるスキルについて解説 ↩