Fundamentals of Data Engineering (Convergence~Dataflow)要約と疑問

準備してみての感想
範囲
要約
疑問や気づき
- 英語について
- 内容に関して
メモ(今回調べた単語)

準備してみての感想

(英語)細かく日本語訳をメモしていったけど、日本語ってややこしいな..って思いました
(内容)streamデータのアーキテクチャに関しては、大枠は理解できたけど、具体的な処理については消化しきれてない感がある

範囲

コンバージェンス(一点に集まること)、次の世代のデータレイクとデータプラットフォーム
Modern Data Stack
Lambda アーキテクチャ
Kappa アーキテクチャ
データフローモデル、バッチとストリーミングの統合

要約

コンバージェンス(一点に集まること)、次の世代のデータレイクとデータプラットフォーム

第一世代のDatalakeの限界を受けて、そのデメリットを克服しようと多くの人が刷新に勤めました

Databricks社の例

データレイクハウスという概念を提唱

　レイクハウスは、データウェアハウスに見られる制御、データ管理、データ構造を取り入れながら、オブジェクトストレージにデータを収容し、さまざまなクエリーと変換エンジンをサポートします
ACID（atomicity, consistency, isolation, and durability=原子性、一貫性、独立性、永続性 )特性をサポート
- 参考: ACID特性: ACID トランザクション | Databricks
- (私の認識)たとえデータ操作(更新など)時にエラーが発生してもデータの整合性を保つ、排他制御を行う、トランザクションが完了したら、その結果は記録され失われることはない、などの性質/仕様
単にデータを流し込むだけで更新や削除を行わないという本来のデータレイクとは大きく異なる
lakehouseという表現はdatalake と data warehouseの境界線をなくすことを示唆

今後は

datalakeとdata warehouseは別々のアーキテクチャとして存在すると思われるが、将来的にそれぞれの機能は収束されてゆくだろう
データエンジニアはアーキテクチャを選択するのではなく、どのサービスを採用するか選択する時代がくる

Modern Data Stack

現在流行しているアナリティクスアーキテクチャ

過去のデータスタックが高価でモノリシックなツールセットに依存していたのに対し、Modern Data Stackは下記の特徴を持っている

クラウドベースのplug-and-play(「挿せば使える」)
使いやすい
モジュール式でコスト効率が高い
(ストレージ、変換、データ管理など)さまざまな構成要素(サービス)がある
複雑さを軽減し、モジュール化していくという目的は今も同じ

モダンデータスタックは何をもたらしたか(Key outcomes of the modern data stack )

シンプルで目的に特化したツール(proprietary tools)
コミュニティ
- 機能の提案、コード改善のプルリク
セルフサービス(自由にサービスを選定できる？)
アジャイルデータ管理
オープンソース
明確な価格体系

今後は

引き続きplug-and-playのモジュール性と明確な価格体系は大事なポイントになる
アナリティクスエンジニアリングでは、データアーキテクチャのデフォルトの選択肢になる

Lambda アーキテクチャ

Lambda アーキテクチャが生まれた背景

スケーラビリティの高いメッセージキューとしてのKafkaや、ストリーミング/リアルタイム分析のためのApache StormやSamzaなどが登場した
そのおかげで大量データを利用した新しいタイプの分析やモデリング、ユーザーの集計やランキング、製品の推奨を実現できた
バッチデータとストリーミングデータを単一のアーキテクチャに調整する方法としてLambda アーキテクチャが誕生

内容

ソースシステムは、理想的にはイミュータブルで追記型
ストリームとバッチの2つの処理先にデータを送信
ストリーム処理では、「スピード」レイヤー（通常はNoSQLデータベース）で、可能な限り低いレイテンシーでデータを提供
バッチ層では、データはデータウェアハウスなどのシステムで処理・変換され、事前に計算されたデータの集約ビューが作成
サービング層では、2つの層からのクエリ結果を集約し、viewを作成

デメリット

異なるコードベースを持つ複数のシステムを管理するため、コードとデータの整合性を取るのが難しくてエラーが発生しやすい

データアーキテクチャを検索するとよく結果に出てくる設計であるが、ストリーミングとバッチを組み合わせる場合本書ではお勧めしない

Kappa アーキテクチャ

Jay KrepsはKappaアーキテクチャと呼ばれる代替案を提案

すべてのデータ処理（取り込み、保存、提供）をストリーム処理プラットフォームをバックボーンとして使用する設計
ライブイベントストリームを直接読み込み、大きなデータチャンクを再生してバッチ処理する

2014年にKappaアーキテクチャの原型となる記事が登場したが、広く採用されなかった

広く採用されなかった理由

ストリーミング自体が多くの企業にとってまだ謎の部分が多い
実行が難しい
複雑でコストが高い(膨大なデータ量に対応できるストリーミングシステムもあることはある)

データフローモデル、バッチとストリーミングの統合

LambdaとKappaで残る課題

バッチ処理とストリーム処理を管理する際の中心的な問題の一つは、複数のコードパスを統一すること
Kappaはキューイングとストレージのレイヤーを統一していますが、リアルタイム統計の収集やバッチ集計のジョブの実行には、異なるツールを使用する必要があった

そこで登場したのがGoogleが開発したDataflowモデルと、それを実装したApache Beamフレームワーク

※ DataflowとApache Beamについて個人的に調べたこと
- Dataflowと言うサービス自体はApacheBeamを実行できる環境の一つ, Dataflowを使えばお手軽にApatche Beamを実装できる
- Apatch Beamはストリーミング処理とバッチ処理のプログラミング的な記述の違いが少ない

データフローモデルの考え方(… この項目こそ図が欲しかった)

すべてのデータをイベントとして捉える
継続的なリアルタイムのイベントストリームは、境界のないデータ
データバッチは単純に境界のあるイベントストリームであり、境界は自然なウィンドウを提供
リアルタイム集計のためのウィンドウを、スライディングやタンブリングなど、さまざまなタイプから選ぶことができる
リアルタイム処理とバッチ処理は、ほぼ同じコードを使って同じシステムで処理できる

FlinkやSparkなどが同様のアプローチを採用している

疑問や気づき

英語について

1. operatingは「活動」? , spaceは「分野」？

~ projects and companies operating in the modern data stack space (typically have user bases~)

2. response

The Lambda architecture was one of the early popular responses to this problem

problem(問題)に対してresponseがくるのは違和感があった(answer, solutionならしっくりくるけど)

3.“batch as a special case of streaming”

「ストリーミングの特別なケースのバッチ処理」と訳す？

内容に関して

1.windowとは?

処理を行う対象の行(レコードor データ)のグループのこと(であってますかね..?)

SQLのwindow関数と同じ認識を持ってます

2.スライディングやタンブリングって何だろう

Engineers can choose from various windows for real-time aggregation, such as sliding or tumbling.

スライディングやタンブリングとは、データを一時領域に保持する時の保存方法？

調べていたらIBM Streamというサービスの記載を見つけた

参考: タンブリング・ウィンドウおよびスライディング・ウィンドウ – IBM Documentation

これまでに挿入されたタプルをすべて保持するのではなく、有効期限が切れたタプルを排除するように構成されます。この点で、タンブリング・ウィンドウはバッチ形式で作動します。タンブリング・ウィンドウが満杯になると、ウィンドウ内のタプルはすべて排除されます。このプロセスは、ウィンドウのフラッシュと呼ばれます。
一方、スライディング・ウィンドウはインクリメンタル方式で作動します。スライディング・ウィンドウが満杯になり、その後にタプルが挿入された場合は、ウィンドウ内の最も古いタプルが排除されます。

タンブリング・ウィンドウ:
() -> (1) -> (2, 1) -> (3, 2, 1) -> (4, 3, 2, 1) -> () -> (5) -> (6, 5) -> ...

スライディング・ウィンドウ:
() -> (1) -> (2, 1) -> (3, 2, 1) -> (4, 3, 2, 1) -> (5, 4, 3, 2) -> (6, 5, 4, 3) -> ...