Cloud Dataflowは、Googleが2014年に発表し2015年に一般提供を開始した、フルマネージドのデータ処理サービスである。バッチとストリームを同じプログラミングモデルで扱える点が特徴で、開発APIはのちにApache Beamとしてオープンソース化された。Beamで記述したパイプラインは、Googleクラウド上ではDataflow、自前環境ではFlinkやSparkといった他のランナーに切り替えて実行できる柔軟性を持つ。本記事ではDataflowの位置付け、Apache Beamとの関係、そしてバッチとストリームの統合という設計思想を整理する。
この記事の目次
- MillWheelとFlumeJavaが起点
- ParDoとPCollectionで考えるパイプライン
- バッチとストリームの統合実装
- 他ETLサービスとの位置取り
- まとめ
MillWheelとFlumeJavaが起点
Dataflowの起源は、Googleが社内で発表してきた2つの論文に遡る。ひとつは2010年の「FlumeJava」で、巨大なデータパイプラインを「PCollection」「ParDo」「GroupByKey」といった抽象で表現する高水準APIの設計が示された。もうひとつは2013年の「MillWheel」で、低遅延ストリーム処理のフォールトトレラント実装が記述されていた。
これらを統合し「バッチもストリームも同じAPIで書ける」プロダクトとして2014年6月のGoogle I/Oで発表されたのがCloud Dataflowである。翌2015年のGA後、開発モデル部分は2016年にApache Software Foundationに寄贈され「Apache Beam」となった。Beam公開以降、Dataflowは「Beamの公式マネージドランナー」という位置付けで進化を続けている。
ParDoとPCollectionで考えるパイプライン
Beam／Dataflowのプログラミングは、PCollectionと呼ばれる分散データ集合に、ParDoやGroupByKey、CombineといったPTransformを適用する形で書き進める。ParDoは一件ずつ要素を処理するMap風の操作、GroupByKeyはキーで集約する操作と理解すれば良い。JavaやPythonのSDKがあり、PCollectionに対して関数を連ねていく宣言的なコードでパイプラインを表現する。
ストリーミング処理を扱うときに肝になるのが「Windowing」と「Watermark」である。固定時間窓・スライディング窓・セッション窓といったウインドウ定義により、終わりのない無限ストリームを区切って集計でき、Watermarkで「どこまでのイベントが揃ったか」を表現する。この概念はその後のFlinkやSparkにも影響を与え、ストリーミング処理の標準語彙となった。
バッチとストリームの統合実装
Dataflowの実行基盤は、登場以来段階的にマネージド色を強めてきた。ストリーミング処理向けには「Streaming Engine」が用意され、ジョブの状態管理（State）やシャッフルをサービス側に逃がすことで、ワーカVMの再配置を高速化している。バッチ向けには「Dataflow Shuffle」が同様に、巨大シャッフルをワーカディスクから分離し、ジョブ全体の安定性を底上げした。
オートスケールにより、データ量や遅延状況に応じてワーカ数が自動調整される。コスト最適化重視のバッチでは「FlexRS」を使うことでSpot系の安価リソースを活用できる。「Templates」という機構を使えば、よく使うパイプライン（Pub/Sub→BigQuery、GCS→BigQueryなど）をパラメータ付きで起動できるため、運用チームが毎回コードを書かなくても済むのも実用上のポイントだ。
他ETLサービスとの位置取り
Google CloudにはDataflowのほかに、Spark/Hadoopをマネージド提供する「Dataproc」、BigQuery内で実行する「Dataform」「BigQuery DTS」など複数のデータ処理サービスがある。Dataprocは既存のSpark資産を移行したいとき、DataformはBigQuery内のSQL変換パイプラインを管理したいときに向く。Dataflowは「コードでパイプラインを書きたい」「バッチとストリームを統合したい」「Pub/Sub＋BigQueryの典型構成を高品質に運用したい」というシナリオに最適化されている。
ETL/ELT領域では、FivetranやAirbyteのようなSaaS型コネクタ群、Talendのような伝統的ノーコードツールも依然として強い。「コード資産を抱え、ストリーミングを含む細やかな制御を求める」場合はDataflow、「カタログからコネクタを選んで運用したい」場合はSaaS型、というのが現代的な棲み分けの目安と言える。
まとめ
Cloud DataflowはFlumeJavaとMillWheelという2つの社内研究の系譜を引き継いで2014年に登場し、その開発モデルをApache Beamとして外部開放した稀有なサービスである。バッチとストリームを同じコードで書ける統一API、Streaming EngineやShuffleによる高度なマネージド実行、Pub/Sub・BigQueryとの密接な連携が組み合わさり、GCPにおけるデータパイプライン処理の中核を担っている。Beamという共通言語を抑えれば他ランナーへの移植も視野に入るため、ベンダーロックインを気にしつつ高機能ETLを使いたい組織にとって有力な選択肢である。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント