Apache Beam TypeScript SDK

Apache Beam 用の Typescript SDK は、バッチおよびストリーミングデータ処理パイプラインを構築するためのシンプルで強力な API を提供します。

TypeScript SDK を使い始める

開発環境を設定し、Beam SDK for Typescript を入手し、パイプラインの例を実行するには、Beam Typescript SDK クイックスタートを参照してください。次に、Beam のすべての SDK に適用される基本的な概念を学ぶには、Beam プログラミングガイドをお読みください。

概要

一般的に、Beam API の概念を TypeScript の慣用的な方法で適用しようとしています。さらに、従来の SDK とはいくつかの注目すべき点が異なります。

• 私たちは、「リレーショナル基盤」アプローチを採用しており、スキーマ化されたデータがデータとやり取りする主な方法であり、従来の GroupByKey よりも柔軟なフィールドまたは式を命名するアプローチを優先して、キーと値が必要な変換を一般的に避けます。たとえば、従来の GroupByKey よりも柔軟な GroupBy PTransform を優先します。 JavaScript のネイティブオブジェクトは行タイプとして使用されます。

• スキーマファーストであることの一環として、SDK のファーストクラスの概念として Coders を重視せず、相互運用に使用される高度な機能に降格させます。個々の要素からスキーマを推測できますが、構築時に型システムや関数イントロスペクションを利用してスキーマを定期的に推測できるかどうかを判断することはまだ TBD です。十分な型情報がない場合は、BSON エンコーディングを使用するフォールバックコーダーが使用されます。

• PCollection オブジェクトに、apply のみを許可するのではなく、map や flatmap などの追加のメソッドを追加しました。さらに、apply は、PTransform のサブクラスだけでなく、関数引数 (PCollection) => ... を受け入れることができます。これは、この呼び出し可能を PTransform の expand であるかのように扱います。

• 反対に、API から問題のある Pipeline オブジェクトを削除し、代わりにパイプラインが構築される Root PValue を提供し、Runner で run() を呼び出します。パイプラインが完全に終了した場合にのみ終了する、エラーが発生しにくい Runner.run と、実行中のパイプラインへのハンドルを返す Runner.runAsync を提供しています。

• PCollectionTuple、PCollectionList などを導入する代わりに、PValue を、変換が消費または生成できるPValue 値を持つ配列またはオブジェクトにします。これらは、P 演算子でラップすることで適用されます。例：P([pc1, pc2, pc3]).apply(new Flatten())。

• Python と同様に、flatMap および ParDo.process は、渡されたコールバックを呼び出すのではなく、ジェネレーターからそれらを生成することによって複数の要素を返します。現在、要素のプロパティに基づいて PCollection を複数の PCollection に分割する操作があり、サイド出力にコールバックの使用を検討する場合があります。

• map、flatMap、および ParDo.process メソッドは、Python で使用されるキーワード引数と同様の追加の（オプションの）コンテキスト引数を取ります。これらは、メンバーが（そのまま渡される）定数、またはランタイム時に要素固有の情報（現在のタイムスタンプ、ウィンドウ、またはサイド入力など）へのゲッターを提供する特別な DoFnParam オブジェクトである JavaScript オブジェクトです。

• map/do 操作自体に複数出力の複雑さを導入するのではなく、複数出力の生成は、PCollection<{a?: AType, b: BType, ... }> を受け取り、オブジェクト {a: PCollection<AType>, b: PCollection<BType>, ...} を生成する新しい Split プリミティブに従うことで行われます。

• JavaScript は、多くのライブラリで async/await パラダイムの使用が必要な、非同期プログラミングモデルをサポート（および推奨）しています。（設計上）非同期スタイルから同期スタイルに戻る方法がないため、API を設計する際にはこれを考慮する必要があります。現在、PValue.apply(...) の非同期バリアント（連鎖しやすいので同期バリアントに加えて）を提供し、Runner.run を非同期にしています。すべてユーザーコールバックに対してこれを行うのは TBD です。

パイプラインの例は wordcount.ts にあり、詳細なドキュメントはbeam プログラミングガイドにあります。

パイプライン I/O

現在利用可能な I/O 変換の一覧については、Beam 提供の I/O 変換のページを参照してください。

サポートされている機能

TypeScript SDK はまだ開発中ですが、バッチとストリーミングの両方で、現在 Beam モデルでサポートされている機能の多く（すべてではありません）をすでにサポートしています。また、TypeScript パイプラインからより高度な機能を利用するために活用できるクロス言語変換も幅広くサポートしています。

シリアライズ

Beam は分散環境で実行するように設計されているため、すべての関数とデータはシリアライズ可能である必要があります。

デフォルトでは、データは BSON エンコーディングを使用してシリアライズされますが、これは PCollection に withRowCoder または withCoderInternal 変換を適用することでカスタマイズできます。

クロージャーとそのキャプチャされたデータを含む、変換（map など）で使用される関数は、ts-serialize-closures を介してシリアライズされます。これによりほとんどの場合うまく処理されますが、それでも制限があり、参照されるオブジェクトの推移的閉包をたどると、シリアライズするのではなくインポートする方が適切なオブジェクトをキャプチャする可能性があります。これらの制限を回避するには、次のように requireForSerialization 関数で参照を明示的に登録できます。

// in module my_package/module_to_be_required
import { requireForSerialization } from "apache-beam/serialization";

// define or import various objects_to_register here

requireForSerialization(
    "my_package/module_to_be_required", { objects_to_register });

スタータープロジェクトにはそのような例があります。