Fundamentals of Data Engineering 輪読会資料 第18回分 2023/9/4開催

本記事の位置づけ

本記事は、Fundamentals of Data Engineering輪読会の資料として作成しました。
英語で技術書を読もう：Fundamentals of Data Engineering 第18回で議論する部分の要約です。

• Chapter 2. The Data Engineering Lifecycle
  • Major Undercurrents Across the Data Engineering Lifecycle より
    • Orchestration
    • Software Engineering
    • Conclusion
      （Additional Resourcesは要約の対象外）

要約

Orchestration
オーケストレーションはデータプラットフォームとデータのライフサイクルの主要な要素であり、定期的なジョブを迅速かつ効率的に実行するためのプロセスである。時間のみを認識する単なるスケジューラ（例: cron）とは異なり、オーケストレーションエンジンはジョブの依存関係に関するメタデータを組み込んでいる。なお、一般的にDAG（directed acyclic graph,有向非巡回グラフ）の形で表現される。

なお、オーケストレーションシステムは次のような特徴や背景を持つ。

• 新しいタスクを自動的に開始し、外部のシステムやツールを監視する。
• かつては、オーケストレーションシステムに手が出せたのは一部の大手企業だけであったが、Apache OozieやAirflowなどのツールの登場で取り入れやすくなった。（Airflowはオープンソースで、Pythonで書かれており、多くのユースケースに拡張可能。）
• オーケストレーションは厳密にはバッチ処理の一種。
  • ストリーミングが必要なケースはストリーミングDAGが使用される。

Software Engineering
ソフトウェアエンジニアリングは、データエンジニアの重要なスキルであるが、変化を続けている。

2000年～2010年：データエンジニアはC、C++、JavaでMapReduceジョブを書いていた。
2010年代半ば：詳細な技術要素を意識させないフレームワークの使用が増加した。

現在は、クラウドのDWHが強力な変換機能をSQLで実行可能な形で持つようになり、また、Sparkなどのツールは更にユーザーフレンドリーになった。フレームワークを活用することでコーディング等の細かな技術要素を意識せずにデータを取りまわせるようになったが、依然として、ソフトウェアエンジニアリングはデータエンジニアリングに不可欠な要素である。

本書では、ソフトウェアエンジニアリングのなかでも、特にデータエンジニアリングライフサイクルと関わりの深い分野が以下のように説明されていた。

• Core data processing code

  • データをより抽象的なレベルで扱えるようになり、管理が容易になったが、コアデータ処理のコードは書かれる必要がある。
  • データエンジニアリングのライフサイクル全体でこのコードは頻出する。
  • データの取り込み、変換、またはデータの提供に関わらず、データエンジニアはSpark、SQL、Beamなどのフレームワークや言語に非常に熟練している必要がある。
  • SQLがコードではないという考え方は受け入られない。
  • データエンジニアは、単体、回帰、統合、E2E、スモークなどの適切なコードテスト方法を理解する必要がある。

• Development of open source frameworks

  • データエンジニアの多くは、オープンソースのフレームワークの開発に深く関与している。
  • データエンジニアリングのライフサイクルでの特定の問題を解決するためにこれらのフレームワークを採用し、コミュニティに貢献するためにフレームワークのコードの開発を続けている。
    ビッグデータ時代には、Hadoopエコシステム内でのデータ処理フレームワークが急増した。
  • オープンソースツールの新しい世代は、データを管理、強化、接続、最適化、モニタリングの面でエンジニアをサポートすることに重心を移行しつつある。
    • 例として、2015年から2020年初頭までAirflowがオーケストレーション領域を支配していたが、現在はPrefect、Dagster、Metaflowなどの新しいオープンソースの競合が出現している。
  • データエンジニアが新しい内部ツールの開発を始める前に、公開されているツールを一通り把握すべきである。
    • 既存のオープンソースプロジェクトで課題が解決できる可能性があり、同じものを作るよりも既存ツールを利用し発展に貢献する方がよい。

• Streaming

  • ストリーミングデータ処理は、バッチ処理よりも複雑で、ツールやパラダイムが成熟していない状態にある。
  • ストリーミングデータがデータエンジニアリングのライフサイクルのあらゆる段階で普及してきたため、データエンジニアはソフトウェアエンジニアリングに関連した問題に直面している。
  • 例えば、バッチ処理では当たり前となっているJOIN（データの結合）のようなデータ処理タスクは、リアルタイムでの処理がより複雑になり、さらに高度なソフトウェアエンジニアリングが求められることが多い。
  • エンジニアは、様々なウィンドウ化メソッドを適用するためのコードを書く必要がある。ウィンドウ化により、リアルタイムシステムで統計データなどの価値ある指標を計算することができる。
  • エンジニアは、個々のイベントを処理するためのさまざまな関数実行プラットフォーム（OpenFaaS、AWS Lambda、Google Cloud Functions）や、報告やリアルタイムのアクションをサポートするためのストリームを分析する専用のストリームプロセッサ（Spark、Beam、Flink、Pulsar）など、多くのフレームワークから選択することができる。

• Infrastructure as code

  • Infrastructure as Code (IaC) は、インフラの設定と管理にソフトウェアエンジニアリングを適用するものである。
  • ビッグデータ時代のインフラ管理の負担は、企業がDatabricksやAmazon Elastic MapReduce (EMR)などの管理型ビッグデータシステムやクラウドデータウェアハウスに移行するなかで減少している。
  • データエンジニアがクラウド環境で自らのインフラを管理する必要がある場合、手動でインスタンスを起動したりソフトウェアをインストールしたりするのではなく、IaCフレームワークで行うことが増えている。
  • いくつかの汎用的なフレームワークとクラウドプラットフォーム固有のフレームワークがあり、定義された仕様に基づいてインフラの自動デプロイを可能にする。これらのフレームワークの多くは、インフラだけでなくクラウドサービスも管理できる。
  • コンテナやKubernetesを使用したIaCの概念も存在し、Helmのようなツールを使用している。
  • これらの実践はDevOpsの重要な部分であり、デプロイのバージョン管理と再現性を可能にする。
  • これらのスキルは、データエンジニアリングのライフサイクル全体を通じて非常に重要で、とりわけDataOpsを実践する際に重宝する。

• Pipelines as code

  • 現在のオーケストレーションシステムのコアコンセプトで、データエンジニアリングのライフサイクルの各段階に関わる。
  • データエンジニアはコード（通常はPython）を使用して、データタスクとそれらの間の依存関係を定義する。
  • オーケストレーションエンジンは、これらの指示を解釈して、利用可能なリソースを使用して各ステップを実行する。

• General-purpose problem solving

  • 実際には、どのハイレベルなツールを採用しても、データエンジニアはデータエンジニアリングのライフサイクル全体で、選択したツールで対応できる範囲を越える問題を克服することを迫られ、結局はカスタムコードで対応せざるを得ない特殊なケースに度々直面する。
  • Fivetran、Airbyte、Matillionなどのフレームワークを使用している場合、データエンジニアは既存のコネクタがないデータソースに遭遇し、何らかのカスタムコードを書く必要がある。
  • APIを理解し、データを取得・変換し、例外処理を行うなど、ソフトウェアエンジニアリングに精通している必要がある。

Conclusion

過去のデータエンジニアリングに関する議論は、技術に焦点を当てており、データライフサイクルマネジメントの全体像を捉えきれていない。

技術がより抽象的になり、多くの作業に対応できるようになるにつれて、データエンジニアはより高いレベルで（全体像を俯瞰して）考え、行動することが求められる。

データエンジニアリングのライフサイクルは、データエンジニアリングの作業を整理するための非常に有用な考え方である。

• データエンジニアリングライフサイクルのステージ
  • Generation（生成）
  • Storage（保存）
  • Ingestion（取込）
  • Transformation（変換）
  • Serving Data（提供）
• データエンジニアリングライフサイクルの根底に流れるもの（Undercurrents）
  • セキュリティ
  • データ管理
  • DataOps
  • データアーキテクチャ
  • オーケストレーション
  • ソフトウェアエンジニアリング
• データエンジニアの主な目標:
  • ROIの最適化、財務コストおよび機会費用の削減
  • リスクの削減（セキュリティ、データ品質）
  • データの価値と有用性の最大化

学んだ英単語や表現

原文	直訳	備考
center of gravity	重心	本文では「主要な要素」や「最も重要な部分」といった意味で使われていた。"central skill for~"も本文中に出てきており、こちらも「中心的なスキル」でなく、重要なスキルと訳した。
as it comes to ~	～に関しては
cadence	拍子、歩調	ビジネスでは「頻度」という意味で使われる。
builds in ~	～を組み込む	builds in metadata という文で使われていた。
heterogeneous	異質な
A anytime B	AのたびにBする	"run new jobs anytime they are deployed"（新しいジョブがデプロイされるたびに実行する）という形で使われていた。everytimeと似た使い方。参考：anytimeとeverytimeの違い
top of mind	最も意識される
mindshare	消費者の心（マインド）のシェア率のことで「自社ブランドがどれくらい存在感があるか」を示す割合	本文では "mindshare leader" =「市場での認知度が高い、注目されている」
aim to ~	〜を目指す
strictly	厳密には
at the peak of ~	〜のピーク時に
reject~	～を拒否する	we reject the notion that「私たちは〜という考えを拒否する」という意味で、強い主張を示していた。
Cambrian explosion	カンブリア爆発	種類が急増したことの比喩で使われていた。
inherently	本質的に
spin up~	～に回転をつける	spinning up instances=「インスタンスを立ち上げる」という意味で使われた。
run into corner cases	特殊なケースに遭遇する
bigger picture	全体像、より広い視点
heavy lifting	大変な作業、難しい仕事
cut across ~	～に関連する、～に影響を及ぼす
era	時代、期間	本文では特定の技術やトレンドが支配的だった時間を指す。
reinventing the wheel	車輪の再発明	「必要のない新しい取り組みをする」という意味。
general-purpose	汎用、多目的、一般的な

他の回のまとめ

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