Apache Beamでデータ集約型処理の効率と移植性を向上

Apache Beamでデータ集約型処理の効率と移植性を向上

  • Ismaël Mejía
    Ismaël Mejía is a software engineer with more than ten years of experience designing and developing information systems for financial groups, telecom companies and startups. Focused on Big Data and Cloud architectures (aka Distributed Systems). He works at Talend France as an Open Source Software Engineer. He is an Apache Beam committer and PMC member and an enthusiastic contributor to multiple open source projects.

Hadoopと関連エコシステムの登場によって、膨大なデータを処理するオープンソースツールとフレームワークが急速に進化し、カンブリア爆発さながらに多様化を極めました。 しかし、早くからビッグデータに投資した企業は、いくつかの課題を経験しました。 たとえば、エンジニアには、分散システムやデータ処理だけでなく、Javaや関連するJVM言語/ツールの専門知識も求められました。 もう1つの問題は、メモリ内処理と連続データ処理(ストリーミング)をサポートする新しいシステムの出現により、当時のシステムの制約が常に変わり続けたことでした。

状況は現在もあまり変わっていません。 プロジェクトにおいて、新機能を利用するために新しいビッグデータ実行エンジンが導入されると、既存システムはほとんど再利用されなくなります。 多くの場合APIが異なり互換性を持たない「ノブ」(ハイパラメーター)が数多く存在するため、移植や再利用が困難になっています。

コンピューティングとストレージのコストが低下し、クラウドの利用が拡大したことで、大量データを保存し、分析することが一般的に広まりました。 さまざまなスキルレベルを持つ人々が、より簡単かつ分かりやすい方法でデータを処理したいと考えるようになりました。 ほとんどのプロジェクトはSQL等の言語でのサポートを追加しましたが、データサイエンティストなどの高度なデータユーザーは、好んで使用する言語、ライブラリ、ツール(必ずしもJava/Scalaの環境と同じではありません)のサポートを要求しました。たとえば、Pythonはデータサイエンスにおける共通語として確立されており、TensorflowやKerasといった機械学習の最新フレームワークのターゲット言語となっています。

Apache Beamは、効率と移植性の高いデータ処理パイプラインを提供するために設計された統一プログラミングモデルです。 Apache Beamモデルは豊富なセマンティクスを持ち、統合APIによりバッチとストリーミングの両方に対応します。Apache Spark、Apache Flink、Google Dataflowなどの複数のシステムで、ランナーによる変換が可能です。

Fig 1. Apache Beamのビジョン。 (Tyler Akidau氏とFrances Perry氏による画像を、許可を得て使用しています。)

Apache Beamは、言語レベルでの移植性の問題にも取り組んでいます。 しかし、この機能は以下のような新たな設計課題を含んでいます。

  • Beamモデル(SDK)の言語固有バージョンを、それぞれの言語に固有の方法で定義する
  • 言語に依存せずにデータとデータ変換を表現する
  • 異なるデータ変換の個別の実行を保証する
  • さまざまな言語のコードに対して、ジョブの実行を制御/トレース/追跡して信頼性を保証する
  • これらすべての効率的な実現方法

設計に関するこれらすべての問題に対処するため、Apache BeamはPortability APIとよばれる一連のAPIセットを使用するアーキテクチャーを作成しました。 これらのAPIにより、言語に依存しないデータ処理パイプラインを表現できます。そのために、プロトコルバッファーを使用し、またgRPCを介してさまざまな言語から定義/使用できる一連のサービスを使用します。

https://developers.google.com/protocol-buffers/

図2:Apache Beamの移植性アーキテクチャーの概略。

移植性アーキテクチャー(図2)において、パイプライン構成は実際の実行環境自体から切り離されています。 ユーザーは、それぞれの言語でSDKを使用してデータパイプラインを定義します。 この表現はプロトコルバッファーバージョンに変換され、ランナーを使用してパイプラインをネイティブジョブに変換するジョブサーバーに送信されます。 ジョブは、ユーザーコードを使用するDockerコンテナーイメージとSDKハーネスの組み合わせによって、ネイティブシステムで実行されます。SDKハーネスは、ユーザーコードの実行と、Fn APIと呼ばれる一連のサービスとのやりとりを担います。このFn APIは、ユーザー定義関数の実行と、ネイティブシステムとコンテナー間のデータ転送を制御するためのさまざまなプレーン、および状態管理とロギングを提供します。

移植性アーキテクチャーには、コンテナーによってユーザーコードが分離され、この種のジョブで負担となる依存関係の競合を回避できるという優れた効果もあります。 最終的に、異なる言語での変換を含むパイプラインを定義できます。たとえば、Javaのパイプラインの場合は、Pythonで記述された機械学習固有の変換を使用することでメリットがあります。また、Pythonのパイプラインの場合は、すでにJavaで記述されている既存のIO(Input/Output)コネクターを再利用できます。

これは、ビッグデータ分野における画期的な新しい進歩です。最新のRPCとデータシリアライゼーションのフレームワークやコンテナーを既存のデータ処理エンジンと共に使用することで、多言語のデータ処理を実現できます。 これらはまだ初期の段階であり、Apache Beamコミュニティで作業が行われています。 このアプローチに基づき、Goのような新しい言語のサポートが進められています。 これらのアイデアに関心があり、その進捗を確認したい場合や活動に関与したい場合は、Beamコミュニティにご参加ください。移植性フレームワークに関するWebページもご覧ください。

ディスカッションに参加

0 Comments

コメントを残す

Your email address will not be published. Required fields are marked *