MejíaHadoopと関連エコシステムの登場によって、膨大なデータを処理するオープンソースツールとフレームワークが急速に進化し、カンブリア爆発さながらに多様化を極めました。早くからビッグデータに投資した企業は、いくつかの課題を経験しました。エンジニアには、分散システムやデータ処理だけでなく、Javaや関連するJVM言語/ツールの専門知識も求められました。1つの問題は、メモリ内処理と連続データ処理(ストリーミング)をサポートする新しいシステムの出現により、当時のシステムの制約が常に変わり続けたことでした。状況は現在もあまり変わっていません。プロジェクトにおいて、新機能を利用するために新しいビッグデータ実行エンジンが導入されると、既存システムはほとんど再利用されなくなります。多くの場合APIが異なり互換性を持たない「ノブ」(ハイパラメーター)が数多く存在するため、移植や再利用が困難になっています。コンピューティングとストレージのコストが低下し、クラウドの利用が拡大したことで、大量データを保存し、分析することが一般的に広まりました。さまざまなスキルレベルを持つ人々が、より簡単かつ分かりやすい方法でデータを処理したいと考えるようになりました。ほとんどのプロジェクトはSQL等の言語でのサポートを追加しましたが、データサイエンティストなどの高度なデータユーザーは、好んで使用する言語、ライブラリ、ツール(必ずしもJava/Scalaの環境と同じではありません)のサポートを要求しました。Pythonはデータサイエンスにおける共通語として確立されており、TensorflowやKerasといった機械学習の最新フレームワークのターゲット言語となっています。Beamは、効率と移植性の高いデータ処理パイプラインを提供するために設計された統一プログラミングモデルです。Beamモデルは豊富なセマンティクスを持ち、統合APIによりバッチとストリーミングの両方に対応します。Dataflowなどの複数のシステムで、ランナーによる変換が可能です。Beamは、言語レベルでの移植性の問題にも取り組んでいます。この機能は以下のような新たな設計課題を含んでいます。APIとよばれる一連のAPIセットを使用するアーキテクチャーを作成しました。これらのAPIにより、言語に依存しないデータ処理パイプラインを表現できます。そのために、プロトコルバッファーを使用し、またgRPCを介してさまざまな言語から定義/使用できる一連のサービスを使用します。移植性アーキテクチャー(図2)において、パイプライン構成は実際の実行環境自体から切り離されています。ユーザーは、それぞれの言語でSDKを使用してデータパイプラインを定義します。この表現はプロトコルバッファーバージョンに変換され、ランナーを使用してパイプラインをネイティブジョブに変換するジョブサーバーに送信されます。ジョブは、ユーザーコードを使用するDockerコンテナーイメージとSDKハーネスの組み合わせによって、ネイティブシステムで実行されます。APIと呼ばれる一連のサービスとのやりとりを担います。APIは、ユーザー定義関数の実行と、ネイティブシステムとコンテナー間のデータ転送を制御するためのさまざまなプレーン、および状態管理とロギングを提供します。移植性アーキテクチャーには、コンテナーによってユーザーコードが分離され、この種のジョブで負担となる依存関係の競合を回避できるという優れた効果もあります。最終的に、異なる言語での変換を含むパイプラインを定義できます。Javaのパイプラインの場合は、Pythonで記述された機械学習固有の変換を使用することでメリットがあります。Pythonのパイプラインの場合は、すでにJavaで記述されている既存のIO(Input/Output)コネクターを再利用できます。これは、ビッグデータ分野における画期的な新しい進歩です。最新のRPCとデータシリアライゼーションのフレームワークやコンテナーを既存のデータ処理エンジンと共に使用することで、多言語のデータ処理を実現できます。Beamコミュニティで作業が行われています。このアプローチに基づき、Goのような新しい言語のサポートが進められています。これらのアイデアに関心があり、その進捗を確認したい場合や活動に関与したい場合は、Beamコミュニティにご参加ください。移植性フレームワークに関するWebページもご覧ください。