なぜ Apache Beam なのか : Dataflow のライバル参入を促す理由
2016年5月16日月曜日
* この投稿は米国時間 5 月 3 日、Staff Software Engineer & Apache Beam PPMC である Tyler Akidau によって投稿されたもの（投稿はこちら）の抄訳です。
data Artisans や Cloudera、Talend、その他数社のパートナーと共同で、Google Cloud Dataflow SDK とランナーを Apache Beam Incubator プロジェクトに移行すると決めたとき、私たち Google の頭の中には、ある目標が浮かんでいました。
それは、ストリーミングとバッチの両モードに対応する、使いやすくて強力なデータ並列処理モデルを、さまざまなプラットフォームを通じポータブルな形で世界に提供することです。
最初のコードをめぐるドタバタも収まった今、それまではデータ処理に関する OSS の世界に直接かかわってこなかった Google にとって、この目標が意味を持つのはなぜでしょうか。Google はどのようにして、ここにたどり着いたのでしょうか。こうした点について簡単にお話ししておきたいと思います。
とはいえ、ライバルとなる他のランナーにもプラットフォームをオープンにするという戦略はわかりにくいかもしれません。しかし、本当はまったく逆なのです。これには、さまざまなメリットがあります。
これらのメリットは、Google だけでなく、Apache Beam にかかわるすべてのプレイヤーが享受できることに注目してください。
データ処理パイプライン構築のためのポータブルな抽象レイヤがあれば、今までよりもはるかに簡単に新しいランナーが参入でき、パフォーマンスや信頼性、運用管理などの面でより優れたものを提供し、技術イノベーションを競えるようになります。
言い換えれば、API ロックインを取り除くと実行エンジンの自由市場が生まれます。すると、競争が激しくなり、最終的には業界全体の底上げにつながります。
これには理由があります。
これがなぜ重要なのかは、先ごろ公開された Apache Beam 機能マトリクスを見れば明らかでしょう。このマトリクスは、個々のランナーが現在どこまで Beam Model をサポートできているかを広い視野でとらえています。言い換えれば、異なるランナーで実行したときに、Apache Beam パイプラインにどの程度のポータビリティを期待できるかが大まかに描かれているのです。
このマトリクスでは、関連する機能をグループとしてまとめるため、What / Where / When / How の疑問文と機能との対応を 4 つの表に分けて示してあります（これらの疑問文を目にしたことがなく、なぜ重要なのかがわからない方は、Streaming 102 を参照してください）。
2016 年 4 月時点で、Apache Beam ランナーがサポートする機能をさまざまな角度からまとめた Apache Beam 機能マトリクス
パイプラインのポータビリティという目標を Apache Beam が達成するためには、オンプレミスや Google 以外のクラウドで実行され、Cloud Dataflow の強力なライバルになるようなランナーが少なくとも 1 つは必要です。
マトリクスを見ればわかるように、現在この要件を満たすランナーは Apache Flink です。Flink があってこそ、Beam は本当の意味で、この産業において欠かすことのできない魅力的なプラットフォームになりうるのです。
Flink が現在の姿まで発展してきたのは、パワーとシンプルさを兼ね備えた Beam Model のおかげです。Flink を支えてきた data Artisans の CEOである Kostas Tzoumas 氏は、次のように語っています。
Storm 1.0 は先ごろ、基本的なイベントタイム サポートを追加しました。また、Spark 2.0 は Structured Streaming のセマンティクスに Beam Model のサブセットを組み込もうとしています（Spark はウォーターマークと非整列ウィンドウを持たず、マイクロバッチ ハートビートに合わせてトリガをハードコードしているようです）。
これらはどちらも限られたユースケースでは優れた選択肢になります。開発者にとっては、それぞれのランナー実装において足りない機能を補い、より包括的なセマンティクス スイートを提供する方向も選べます。最近登場した Gearpump なども、Beam ランナーとしてとても期待できる存在です。
幸いなことに、データ処理実行エンジンの自由市場では、パフォーマンスやレイテンシ、スケーラビリティ、運用保守のしやすさなどの面で（そして基本的にまだ解決されていない分野で）、まだまだイノベーションや差別化を生む余地が十分に残されています。
近い将来、API をロックインして市場の独占を目指す競争ではなく、ユーザーの満足を獲得するための競争がランナーの間で起きるでしょう。これは、業界全体のためには歓迎すべきことです。
前出の機能マトリクスからも明らかなように、現時点で最も優れたランナーは、GCP では Google Cloud Dataflow、オンプレミスと Google 以外のクラウドでは Apache Flink です。しかし、他のランナーもこれらに追いつこうとしていますし、業界全体として Beam Model のセマンティクスをサポートする方向にシフトしつつあります。Beam ユーザーにとっては良いことずくめでしょう。
ストリーミングとバッチの未来は Apache Beam にあります。あなたが考えなければならないのは、どのランナーを選ぶかです。
- Posted by Tyler Akidau, Staff Software Engineer & Apache Beam PPMC
data Artisans や Cloudera、Talend、その他数社のパートナーと共同で、Google Cloud Dataflow SDK とランナーを Apache Beam Incubator プロジェクトに移行すると決めたとき、私たち Google の頭の中には、ある目標が浮かんでいました。
それは、ストリーミングとバッチの両モードに対応する、使いやすくて強力なデータ並列処理モデルを、さまざまなプラットフォームを通じポータブルな形で世界に提供することです。
最初のコードをめぐるドタバタも収まった今、それまではデータ処理に関する OSS の世界に直接かかわってこなかった Google にとって、この目標が意味を持つのはなぜでしょうか。Google はどのようにして、ここにたどり着いたのでしょうか。こうした点について簡単にお話ししておきたいと思います。
なぜ Google にとって意味をなすことなのか？
Google は営利企業ですので、Apache Beam への移行がビジネス上の動機に基づいていても不思議ではないでしょう。ひとえに、できるだけ多くの Apache Beam パイプラインを Cloud Dataflow の上で実行できるようにしたいということです。とはいえ、ライバルとなる他のランナーにもプラットフォームをオープンにするという戦略はわかりにくいかもしれません。しかし、本当はまったく逆なのです。これには、さまざまなメリットがあります。
- Apache Beam をサポートするランナーが増えれば増えるほど、Apache Beam のプラットフォームとしての魅力は高まります。
- Apache Beam を採用するユーザーが増えれば増えるほど、Google Cloud Platform（GCP）の上で Apache Beam を実行したいと思うユーザーは増えます。
- Apache Beam の開発に携わる人間が増えれば増えるほど、データ処理の最先端を先鋭化させることができます。
これらのメリットは、Google だけでなく、Apache Beam にかかわるすべてのプレイヤーが享受できることに注目してください。
データ処理パイプライン構築のためのポータブルな抽象レイヤがあれば、今までよりもはるかに簡単に新しいランナーが参入でき、パフォーマンスや信頼性、運用管理などの面でより優れたものを提供し、技術イノベーションを競えるようになります。
言い換えれば、API ロックインを取り除くと実行エンジンの自由市場が生まれます。すると、競争が激しくなり、最終的には業界全体の底上げにつながります。
どのようにして進めるのか？
これまで Google は、OSS コミュニティとの間でイノベーションを共有することに関して冷淡な態度をとってきました。その方針を転換し、データ処理用のオープンソース コードを通じてイノベーションを共有する方向に舵を切ったのは、Apache Beam を共同で立ち上げたときからです。なぜ今なのでしょうか。これには理由があります。
- 従来、Google は主として社内だけでビジネスを進めてきましたが、クラウドの顧客らとの交流を通じて OSS の価値を知るようになったのです。Hadoop コミュニティの成功が良い例です。こうしたことから Apache Beam のような動きが可能になりました。
- これは Beam 固有の事情ですが、Beam への移行が意味を持つのは、Beam Model（従来の Dataflow モデル）を高度にサポートし、オンプレミスや Google 以外のクラウド シナリオできわめて魅力的なオプションを提供する OSS のランナーがすでに存在する場合に限られます。
これがなぜ重要なのかは、先ごろ公開された Apache Beam 機能マトリクスを見れば明らかでしょう。このマトリクスは、個々のランナーが現在どこまで Beam Model をサポートできているかを広い視野でとらえています。言い換えれば、異なるランナーで実行したときに、Apache Beam パイプラインにどの程度のポータビリティを期待できるかが大まかに描かれているのです。
このマトリクスでは、関連する機能をグループとしてまとめるため、What / Where / When / How の疑問文と機能との対応を 4 つの表に分けて示してあります（これらの疑問文を目にしたことがなく、なぜ重要なのかがわからない方は、Streaming 102 を参照してください）。
2016 年 4 月時点で、Apache Beam ランナーがサポートする機能をさまざまな角度からまとめた Apache Beam 機能マトリクス
パイプラインのポータビリティという目標を Apache Beam が達成するためには、オンプレミスや Google 以外のクラウドで実行され、Cloud Dataflow の強力なライバルになるようなランナーが少なくとも 1 つは必要です。
マトリクスを見ればわかるように、現在この要件を満たすランナーは Apache Flink です。Flink があってこそ、Beam は本当の意味で、この産業において欠かすことのできない魅力的なプラットフォームになりうるのです。
Flink が現在の姿まで発展してきたのは、パワーとシンプルさを兼ね備えた Beam Model のおかげです。Flink を支えてきた data Artisans の CEOである Kostas Tzoumas 氏は、次のように語っています。
「私たちは非常に早い時期から Beam にかかわっています。（中略）Dataflow モデルがストリームおよびバッチのデータ処理の正しいモデルだということは、私たちの中ですぐに明らかになりました。
1 つのプラットフォームのもとで、リアルタイム アナリティクスとヒストリカル アナリティクスを統一するという Google のビジョンを、私たちは全面的に支持しました。（中略）私たちは、この基礎的な仕事からヒントを得て、Dataflow のホワイトペーパーに書かれていた概念の多くを組み込むために Flink の DataStream API を書き換えました。
Dataflow SDK とランナーが Apache Beam として Apache Incubator に移行することが決まったとき、私たちは Beam のコードベースに Flink ランナーを加えてほしいという要請を Google から受けました。（中略）Beam Model こそ、ストリームおよびバッチの両モードでデータ アプリケーションを作るときのリファレンス プログラミング モデルに相応しいと信じていたので、このチャンスに全力を注ぐことにしたのです。
1 つ疑問があるとすれば、Flink のネイティブ API（DataStream）と Beam API の関係はどうなっているのかということです。（中略）2 つの API の間の違いは主として構文（そして趣味の問題）であり、私たちは Beam と Flink の両 API をソース互換にすることを最終的な目標として、Google との間で API 統一の作業を進めています」
将来はどうなるのか?
現在は Flink が最先端かもしれませんが、他のランナーが Flink に追いつけないというわけではありません。業界には面白い選択肢が多数存在します。もちろん、私たち Google もできる限り多くのランナーを Beam でサポートするつもりですし（実行エンジンの自由市場はこのようにして機能していくのです）、それらすべてのランナーがモデルの多くの部分をサポートすることを望んでいます（ポータビリティはこのようにして実現されるのです）。Storm 1.0 は先ごろ、基本的なイベントタイム サポートを追加しました。また、Spark 2.0 は Structured Streaming のセマンティクスに Beam Model のサブセットを組み込もうとしています（Spark はウォーターマークと非整列ウィンドウを持たず、マイクロバッチ ハートビートに合わせてトリガをハードコードしているようです）。
これらはどちらも限られたユースケースでは優れた選択肢になります。開発者にとっては、それぞれのランナー実装において足りない機能を補い、より包括的なセマンティクス スイートを提供する方向も選べます。最近登場した Gearpump なども、Beam ランナーとしてとても期待できる存在です。
幸いなことに、データ処理実行エンジンの自由市場では、パフォーマンスやレイテンシ、スケーラビリティ、運用保守のしやすさなどの面で（そして基本的にまだ解決されていない分野で）、まだまだイノベーションや差別化を生む余地が十分に残されています。
近い将来、API をロックインして市場の独占を目指す競争ではなく、ユーザーの満足を獲得するための競争がランナーの間で起きるでしょう。これは、業界全体のためには歓迎すべきことです。
まとめ
ストリーミングとバッチの両面でデータ処理の未来を担うのは Apache Beam であると、私たち Google は固く信じています。API ロックインによるシェア拡大を競うのではなく、ユーザーを喜ばせるために競う洗練されたランナーによる健全なエコシステムが、Apache Beam の周りに育ってくれることを期待しています。前出の機能マトリクスからも明らかなように、現時点で最も優れたランナーは、GCP では Google Cloud Dataflow、オンプレミスと Google 以外のクラウドでは Apache Flink です。しかし、他のランナーもこれらに追いつこうとしていますし、業界全体として Beam Model のセマンティクスをサポートする方向にシフトしつつあります。Beam ユーザーにとっては良いことずくめでしょう。
ストリーミングとバッチの未来は Apache Beam にあります。あなたが考えなければならないのは、どのランナーを選ぶかです。
- Posted by Tyler Akidau, Staff Software Engineer & Apache Beam PPMC
0 件のコメント :
コメントを投稿