Dataflow の仕組み: Dataflow と他のツールとの比較

※この投稿は米国時間 2020 年 8 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 本記事は Dataflow の開発に至った Google 内部の歴史と、Google Cloud サービスとしての Dataflow の機能、市場における他社製品との比較対照について掘り下げる 3 回シリーズのブログの第 3 回です。

Google Cloud のストリームとバッチ処理ツールである Dataflow をより大きなエコシステムに配置するために、他のデータ処理システムと比較していきます。ここで取り上げる各システムには、それぞれに最適化された独自の強みと活用方法があります。もちろん、私たちの見方には偏りがありますが、Dataflow は特にニーズのバランスが取れていると考えています。

Apache Kafka は、メッセージ配信とサブスクリプション向けの非常に人気のあるシステムであり、その多様性と能力を高める拡張機能を提供しています。ここでは、Kafka の主なエクスペリエンスについて具体的に説明します。Kafka はメッセージ配信システムであるため、集約やタイマーのステート ストレージを直接サポートしていません。これらの機能は、Kafka Streams のような抽象化を通じて上に重ねることができます。Kafka は、トランザクション セマンティクスをサポートする 2 つのシステム間で 1 度限りの通信を提供するために、2 つのトピック間のトランザクション インタラクションをサポートします。ウォーターマーク セマンティクス（Kafka Streams を介してサポート可能）や自動スケーリングをネイティブにサポートしていないため、ユーザーは、システムのスケールアップまたはスケールダウンするためにアプリケーションを再シャーディングする必要があります。

Apache Spark は、Google Flume や Dataflow と多くの目的を同じくして開発された（現在も開発中）データ処理エンジンであり、基盤となるインフラストラクチャがユーザーからは見えない、より高いレベルの抽象化を提供します。Spark には、ML ワークロード用の多数のツールを含む豊富なエコシステムがあります。また、1 度限りのネイティブ サポートと、イベント時間処理のサポートが備わっています。Spark には遅延データを処理する機能に関して制限がいくつかあります。これは Spark のイベント処理機能（したがってガベージ コレクション）がウォーターマークではなく静的しきい値に基づいているためです。Spark のステート管理は、大まかな永続性メカニズムを提供する MillWheel の独自概念に似ており、Spark クラスタのスケールアップとスケールダウンは手動で行う必要があります。このような構造化ストリーミングの主な制限の一つは、現在、単一のパイプライン内でマルチステージの集約を処理できないことです。

Apache Flink は、MillWheel ストリーミングの概念の多くを組み込んだデータ処理エンジンです。1 度限りの処理とイベント時間をネイティブでサポートし、定期的なチェックポイントを通じて保持される大まかなステートを提供します。これがステート永続性の費用に与える影響は不明瞭です。ほとんどの Flink のデプロイは、今でもローカルの RocksDB インスタンスに頻繁に書き込み、定期的にこれを外部ファイル システムにチェックポイントします。そのため、チェックポイントの頻度によっては、計算を繰り返す必要がある場合に回復に時間がかかることがあります。Flink はユーザーによる手動スケーリングも必要とします。一部のベンダーは Flink の自動スケーリングに取り組んでいますが、それでも新しいベンダーのプラットフォームの詳細を調べておく必要があります。

最後に、Dataflow の SDK である Apache Beam について簡単に説明します。Google Cloud の幅広いオープンソース コミットメント（Cloud Composer、Cloud Dataproc、Cloud Data Fusion はすべてマネージド OSS サービス）について考えるとき、Dataflow が Beam のマネージドサービスであるという想定により、Beam は実行エンジンと混同されることがよくあります。しかし、そうではありません。Dataflow ジョブは Beam で作成され、Dataflow が実行エンジンとして機能します。Apache Beam のメリットは、オープンソースの開発とポータビリティにあります。ジョブはさまざまな言語で Beam に書き込むことができ、そのジョブは Dataflow、Apache Flink、Apache Spark、その他の実行エンジンで実行できます。つまり、Google Cloud に縛られることはありません。

これで、Dataflow について説明する全 3 回の「Dataflow の仕組み」は終了です。第 1 回と第 2 回もご覧ください。私たちは、Dataflow の現状とデータ処理業界全体の状況について嬉しく思っています。絶え間なく続くイノベーションを、これからの数か月から数年のうちにお客様に提供できることを楽しみにしています。

-プリンシパル エンジニア Sam McVeety 

-プロダクト マネージャー Ryan Lippert