Apache Beam 用語集

集計

複数の入力要素から値を計算するための Transform パターン。集計は、MapReduce モデルの reduce 操作に似ています。集計 Transform には、Combine（集計内のすべての要素にユーザー定義関数を適用）、Count（集計内のすべての要素の数を計算）、Max（集計内の最大要素を計算）、Sum（集計内のすべての要素の合計を計算）などがあります。

組み込みの集計 Transform の一覧については、以下を参照してください。

詳細については、以下を参照してください。

適用 (Apply)

入力 PCollection (または PCollection のセット) に Transform を適用して、1 つ以上の出力 PCollection を生成する方法。apply メソッドは、PCollection (または値) にアタッチされます。複数の Beam Transform を呼び出すことは、メソッドチェインに似ていますが、違いがあります。Transform を入力 PCollection に適用し、Transform 自体を引数として渡すと、操作は出力 PCollection を返します。Beam の遅延実行モデルのため、Transform を適用しても、その Transform がすぐに実行されるわけではありません。

詳細については、以下を参照してください。

バッチ処理

有限または境界付きのデータセットを扱うためのデータ処理パラダイム。境界付き PCollection は、既知の固定サイズのデータセットを表します。ファイルやデータベースなどのバッチデータソースからの読み取りは、境界付き PCollection を作成します。バッチ処理ジョブは最終的に終了しますが、ストリーミングジョブはキャンセルされるまで実行されます。

詳細については、以下を参照してください。

境界付きデータ

既知の固定サイズのデータセット（または、時間とともに増加しないデータセット）。PCollection は、それが表すデータのソースに応じて、境界付きまたは境界なしにすることができます。ファイルやデータベースなどのバッチデータソースからの読み取りは、境界付き PCollection を作成します。Beam は、境界なしソースから境界付きの量のデータを読み取ることもサポートしています。

詳細については、以下を参照してください。

バンドル

PCollection 内の要素の処理およびコミット/再試行の単位。Beam は、PCollection 内のすべての要素を同時に処理するのではなく、バンドル内の要素を処理します。ランナーはコレクションのバンドルへの分割を処理し、その際にユースケースに合わせてバンドルサイズを最適化する場合があります。たとえば、ストリーミングランナーは、バッチランナーよりも小さいバンドルを処理する場合があります。

詳細については、以下を参照してください。

Coder

PCollection の要素をエンコードおよびデコードする方法を記述するコンポーネント。分散処理とクロス言語移植性をサポートするために、Beam は PCollection の各要素をバイトとしてエンコードできる必要があります。Beam SDK は、一般的な型と、PCollection のエンコーディングを指定するための言語固有のメカニズムに対して、組み込みの Coder を提供します。

詳細については、以下を参照してください。

CoGroupByKey

2 つ以上の PCollection を受け取り、キーによって要素を集計する PTransform。事実上、CoGroupByKey は、同じキータイプを持つ 2 つ以上のキー/値 PCollection のリレーショナル結合を実行します。GroupByKey は単一の入力コレクションに対してこの操作を実行しますが、CoGroupByKey は複数の入力コレクションに対して動作します。

詳細については、以下を参照してください。

コレクション

PCollection を参照してください。

Combine

PCollection のすべての要素またはキーに関連付けられたすべての値を結合するための PTransform。Combine Transform を適用する場合は、要素または値を結合するためのロジックを含むユーザー定義関数（UDF）を提供する必要があります。結合関数は、可換および結合的である必要があります。関数は、特定のキーを持つすべての値に対して正確に一度呼び出されるとは限らないためです。

詳細については、以下を参照してください。

複合 Transform

多数の PTransform に展開される PTransform です。複合変換は、複雑な変換が 1 つ以上のより単純な変換を適用するネスト構造を持っています。これらのより単純な変換は、ParDo、Combine、GroupByKey のような既存の Beam 操作である場合もあれば、他の複合変換である場合もあります。1 つの複合変換の中に複数の変換をネストすると、パイプラインをよりモジュール化し、理解しやすくすることができます。多くの組み込み変換は複合変換です。

詳細については、以下を参照してください。

カウンター（メトリクス）

単一の long 値を報告し、インクリメントできるメトリクスです。Beam モデルでは、メトリクスはパイプラインの状態に関する洞察を提供し、パイプラインの実行中にも可能です。

詳細については、以下を参照してください。

クロス言語 Transform

Beam SDK 間で共有できる変換です。クロスランゲージ変換を使用すると、別の SDK 言語で記述されたパイプラインで、サポートされている任意の SDK 言語 (現在、Java と Python) で記述された変換を使用できます。たとえば、Python ストリーミングパイプラインで Java SDK の Apache Kafka コネクタを使用できます。クロスランゲージ変換により、異なる SDK で同時に新しい機能を提供することが可能になります。

詳細については、以下を参照してください。

遅延実行

Beam 実行モデルの機能です。Beam 操作は遅延されます。つまり、特定の操作の結果は制御フローに使用できない場合があります。遅延実行により、Beam API はデータの並列処理をサポートし、パイプラインレベルの最適化を実行できます。

分布（メトリクス）

報告された値の分布に関する情報を報告するメトリクスです。Beam モデルでは、メトリクスはパイプラインの状態に関する洞察を提供し、パイプラインの実行中にも可能です。

詳細については、以下を参照してください。

DoFn

ParDo (または他の変換) が PCollection の要素を処理するために使用する関数オブジェクトです。多くの場合、出力 PCollection 用の要素を生成します。DoFn はユーザー定義関数であり、パイプライン内のデータ処理タスクを定義するカスタムコードが含まれています。Beam システムは DoFn を 1 回以上呼び出して、要素の任意のバンドルを処理しますが、Beam は正確な呼び出し回数を保証しません。

詳細については、以下を参照してください。

ドライバー

すべての入力、変換、および出力を含むパイプラインを定義するプログラムです。Beam を使用するには、Beam SDK のいずれかからクラスを使用してドライバプログラムを作成する必要があります。ドライバプログラムはパイプラインを作成し、パイプラインをどこでどのように実行するかを指示する実行オプションを指定します。これらのオプションには、パイプラインを実行するバックエンドを決定するランナーが含まれます。

詳細については、以下を参照してください。

要素

PCollection のデータ単位です。PCollection の要素は任意の型にすることができますが、すべて同じ型である必要があります。これにより、並列計算がコレクション全体で均一に動作できます。一部の要素型には、イントロスペクトできる構造 (たとえば、JSON、Protocol Buffer、Avro、およびデータベースレコード) があります。

詳細については、以下を参照してください。

要素ごと

入力 PCollection の各要素を独立して処理する変換の種類です。要素単位は、MapReduce モデルのマッピング操作に似ています。要素単位の変換は、入力要素ごとに 0、1、または複数の値を出力する場合があります。これは、複数の入力要素から単一の値を計算する集計変換とは対照的です。要素単位の操作には、Filter、FlatMap、ParDo などがあります。

要素単位の変換の完全なリストについては、以下を参照してください。

エンジン

Dataflow、Spark、Flink などのデータ処理システム。エンジンの Beam ランナーは、そのエンジンで Beam パイプラインを実行します。

イベント時間

要素のタイムスタンプによって決定されるデータイベントが発生する時間です。これは、パイプラインで要素が処理されるときの処理時間とは対照的です。イベントは、たとえば、ユーザーインタラクションやエラーログへの書き込みである可能性があります。イベントがイベント時間順にパイプラインに表示される保証はありませんが、ウィンドウ処理とタイマーを使用すると、イベント時間について正しく推論できます。

詳細については、以下を参照してください。

拡張サービス

他の SDK で定義されたクロスランゲージ変換をパイプラインが適用 (展開) できるようにするサービスです。たとえば、Java 拡張サービスに接続することにより、Python SDK は Java で実装された変換を適用できます。現在、SDK は通常、拡張サービスをローカルプロセスとして起動しますが、将来的には Beam が長時間の拡張サービスをサポートする可能性があります。拡張サービスの開発は、マルチランゲージパイプラインをサポートするための継続的な取り組みの一部です。

Flatten

コア PTransform の 1 つです。Flatten は複数の PCollection を単一の論理 PCollection にマージします。

詳細については、以下を参照してください。

Fn API

ランナーが SDK 固有のユーザー定義関数を呼び出すことができるインターフェイスです。Fn API は、Runner API とともに、SDK とランナーを組み合わせて使用する機能をサポートします。Fn および Runner API を一緒に使用すると、新しい SDK をすべてのランナーで実行でき、新しいランナーですべての SDK からパイプラインを実行できます。

フュージョン

Beam ランナーがパイプラインを実行する前に適用できる最適化です。ある変換が別の変換によって消費される PCollection を出力する場合、または 2 つ以上の変換が同じ PCollection を入力として受け取る場合、ランナーは変換を 1 つの処理ユニット (Dataflow ではステージ) に融合できる場合があります。消費する DoFn は、中間 PCollection 全体が計算されるのを待つのではなく、生成する DoFn によって出力されるときに要素を処理します。融合により、I/O 操作を防ぐことでパイプライン実行をより効率的にすることができます。

ゲージ（メトリクス）

報告された値の中から最新の値を報告するメトリクスです。Beam モデルでは、メトリクスはパイプラインの状態に関する洞察を提供し、パイプラインの実行中にも可能です。メトリクスは多くのワーカーから収集されるため、ゲージ値は絶対的な最後の値ではない可能性がありますが、ワーカーのいずれかによって生成された最新の値の 1 つになります。

詳細については、以下を参照してください。

GroupByKey

キー/値ペアのコレクションを処理するための PTransform です。GroupByKey は、マップ/シャッフル/リデュースアルゴリズムのシャッフルに似た並列削減操作です。GroupByKey への入力は、複数のペアが同じキーを持ちながら異なる値を持つキー/値ペアのコレクション (つまり、マルチマップ) です。GroupByKey を使用して、一意の各キーに関連付けられたすべての値を収集できます。

詳細については、以下を参照してください。

I/O コネクタ

外部データストレージシステムを操作するための PTransform のセットです。パイプラインを作成する場合、多くの場合、ファイルやデータベースなどの外部データシステムからの読み取りまたは書き込みが必要になります。Beam は、一般的なデータストレージタイプに対して、読み取りおよび書き込み変換を提供します。

詳細については、以下を参照してください。

Map

PCollection の各要素にユーザー定義関数 (UDF) を適用する要素単位の PTransform です。Map を使用すると、個々の各要素を新しい要素に変換できますが、要素数を変更することはできません。

詳細については、以下を参照してください。

メトリクス

パイプラインの状態に関するデータであり、パイプラインの実行中にも可能です。組み込みの Beam メトリクスを使用して、パイプラインの機能に関する洞察を得ることができます。たとえば、Beam メトリクスを使用して、エラー、バックエンドサービスへの呼び出し、または処理された要素数を追跡する場合があります。Beam は現在、Counter、Distribution、および Gauge の 3 種類のメトリクスをサポートしています。

詳細については、以下を参照してください。

多言語パイプライン

クロスランゲージ変換を使用するパイプラインです。サポートされている任意の SDK 言語 (現在、Java と Python) で記述された変換を組み合わせて、1 つのマルチランゲージパイプラインで使用できます。

詳細については、以下を参照してください。

ParDo

最下位レベルの要素単位 PTransform です。入力 PCollection の各要素に対して、ParDo は関数を適用し、出力 PCollection に 0 個、1 個、または複数の要素を出力します。「ParDo」は「Parallel Do」の略です。MapReduce アルゴリズムのマッピング操作と、GroupByKey に続くリデュース操作に似ています。ParDo は、DataFrame の apply メソッドや SQL の UPDATE キーワードとも比較できます。

詳細については、以下を参照してください。

Partition

単一の PCollection を固定数のより小さい、互いに素な PCollection に分割する要素単位の PTransform です。Partition には、入力コレクションの要素を結果の出力コレクションに分割する方法を決定するユーザー定義関数 (UDF) が必要です。パーティションの数はグラフの構築時に決定する必要があり、実行中のパイプラインで計算されたデータを使用してパーティションの数を決定することはできません。

詳細については、以下を参照してください。

PCollection

潜在的に分散した、均質なデータセットまたはデータストリーム。PCollection は Beam パイプラインのデータを表し、Beam 変換 (PTransform) は入力と出力として PCollection オブジェクトを使用します。PCollection は不変であるように意図されています。つまり、PCollection が作成されると、個々の要素を追加、削除、または変更することはできません。「P」は「並列」を表します。

詳細については、以下を参照してください。

パイプ演算子 (|)

Python パイプラインのステップを区切ります。例: [最終出力 PCollection] = ([初期入力 PCollection] | [最初の変換] | [2 番目の変換] | [3 番目の変換])。各変換の出力は、左から右に、次の変換への入力として渡されます。Python のパイプ演算子は Java の apply メソッドと同等です (言い換えれば、パイプは PCollection に変換を適用します)。使用法はシェルスクリプトのパイプ演算子に似ており、これにより、あるプログラムの出力を別のプログラムの入力に渡すことができます。

詳細については、以下を参照してください。

パイプライン

入力データをソースから読み取り、そのデータを変換し、出力データをシンクに書き込むことを含む、データ処理タスク全体をカプセル化したものです。パイプラインは、PTransform を使用して PCollection を処理する Beam プログラムとして考えることができます。(または、入力も出力もない、実行可能な単一の複合 PTransform として考えることもできます。) パイプライン内の変換は、有向非巡回グラフ (DAG) として表現できます。すべての Beam ドライバプログラムはパイプラインを作成する必要があります。

詳細については、以下を参照してください。

処理時間

パイプラインのステージで要素が処理される実際の時間。処理時間は、データイベントが発生する時間であるイベント時間とは異なります。処理時間は、要素を処理するシステムのクロックによって決定されます。要素がイベント時間順に処理される保証はありません。

詳細については、以下を参照してください。

PTransform

パイプライン内のデータ処理操作またはステップ。PTransform は入力として 0 個以上の PCollection を受け取り、その PCollection の要素に処理関数を適用し、0 個以上の出力 PCollection を生成します。一部の PTransform は、カスタムロジックを適用するユーザー定義関数を受け入れます。「P」は「並列」を表します。

詳細については、以下を参照してください。

リソースヒント

パイプラインの計算リソース要件に関する情報をランナーに提供できる Beam 機能です。リソースヒントを使用して、特定の変換またはパイプライン全体に対する要件を定義できます。たとえば、リソースヒントを使用して、ワーカーに割り当てる最小メモリ量を指定できます。ランナーはリソースヒントを解釈する責任があり、ランナーはサポートされていないヒントを無視できます。

詳細については、以下を参照してください。

ランナー

ランナーは、特定のプラットフォーム上でパイプラインを実行します。ほとんどのランナーは、大規模並列ビッグデータ処理システムへのトランスレータまたはアダプタです。ローカルテストやデバッグ用のランナーも存在します。サポートされているランナーには、Google Cloud Dataflow、Apache Spark、Apache Samza、Apache Flink、インタラクティブランナー、およびダイレクトランナーがあります。

詳細については、以下を参照してください。

スキーマ

PCollectionの要素に対する言語に依存しない型定義。PCollectionのスキーマは、そのPCollectionの要素を名前付きフィールドの順序付きリストとして定義します。各フィールドには、名前、型、および場合によってはユーザーオプションのセットがあります。スキーマは、異なるプログラミング言語API間で型について推論する方法を提供します。また、データの変換をより簡潔かつ高レベルで記述することができます。

詳細については、以下を参照してください。

セッション

データイベントをグループ化するための時間間隔。セッションは、イベント間の最小ギャップ期間によって定義されます。たとえば、ユーザーのマウス操作を表すデータストリームには、クリックが集中している期間と、操作がない期間がある場合があります。セッションは、操作がないことで区切られたこのような操作のパターンを表すことができます。

詳細については、以下を参照してください。

Side Input

PTransformへの追加の入力であり、要素ごとにではなく、全体が提供されます。サイド入力は、メインの入力PCollectionに加えて提供する入力です。DoFnは、PCollection内の要素を処理するたびにサイド入力にアクセスできます。

詳細については、以下を参照してください。

シンク

ファイルやデータベースなどの外部データストレージシステムに書き込む変換。

詳細については、以下を参照してください。

ソース

外部ストレージシステムから読み込む変換。パイプラインは通常、ソースから入力データを読み込みます。ソースにはタイプがあり、シンクタイプとは異なる場合があるため、パイプラインを移動するにつれてデータの形式を変更できます。

詳細については、以下を参照してください。

分割可能な DoFn

複雑でモジュール化されたI/Oコネクタを簡単に作成できるようにするDoFnの一般化。分割可能なDoFn（SDF）は、モノリシックではない方法で要素を処理できます。つまり、処理をより小さなタスクに分解できます。SDFを使用すると、要素の処理をチェックポイントし、残りの作業を分割して並列処理を追加できます。SDFは、新しいI/Oコネクタを構築するのに推奨されます。

詳細については、以下を参照してください。

ステージ

パイプラインにおける融合された変換の単位。ランナーは、パイプラインの実行をより効率的にするために融合最適化を実行できます。Dataflowでは、パイプラインは融合されたステージのグラフとして概念化されます。

状態

PTransformがアクセスできる永続的な値。state APIを使用すると、（ParDoやMapなどの）要素ごとの操作を可変ステートで拡張できます。state APIを使用すると、PCollectionの各要素を処理する際にステートから読み取り、ステートに書き込むことができます。state APIをタイマーAPIと一緒に使用して、ワークフローをきめ細かく制御できる処理タスクを作成できます。ステートは常にキーとウィンドウに対してローカルです。

詳細については、以下を参照してください。

ストリーミング

無限またはアンバウンドのデータセットを扱うためのデータ処理パラダイム。Pub/SubやKafkaなどのストリーミングデータソースから読み取ると、アンバウンドのPCollectionが作成されます。アンバウンドのPCollectionは、コレクション全体を一度に処理できないため、継続的に実行されるジョブを使用して処理する必要があります。

詳細については、以下を参照してください。

タイマー

state APIを使用して保存されたデータの遅延処理を可能にするBeam機能。タイマーAPIを使用すると、イベント時間または処理時間のタイムスタンプでコールバックするタイマーを設定できます。タイマーAPIをステートAPIと一緒に使用して、ワークフローをきめ細かく制御できる処理タスクを作成できます。

詳細については、以下を参照してください。

タイムスタンプ

PCollectionの要素に関連付けられ、要素にウィンドウを割り当てるために使用されるイベント時間のポイント。PCollectionを作成するソースは、各要素に初期タイムスタンプを割り当てます。これは、多くの場合、要素が読み取られたり追加されたりした時間に対応します。ただし、タイムスタンプを手動で割り当てることもできます。これは、要素に固有のタイムスタンプがあるものの、タイムスタンプが要素自体の構造のどこかにある場合（たとえば、サーバーログエントリのタイムフィールド）に役立ちます。

詳細については、以下を参照してください。

Transform

PTransformを参照してください。

トリガー

ウィンドウからの集計結果データをいつ出力するかを決定します。トリガーを使用すると、パイプラインのウィンドウ化戦略を洗練させることができます。デフォルトのウィンドウ化構成とデフォルトのトリガーを使用すると、Beamは、ウィンドウのすべてのデータが到着したと推定されるときに集計結果を出力し、そのウィンドウの後続のすべてのデータを破棄します。ただし、トリガーを使用すると、特定のウィンドウのすべてのデータが到着する前に早期結果を出力したり、イベント時間のウォーターマークがウィンドウの終わりに到達した後でトリガーすることにより、遅延データを処理したりすることもできます。

詳細については、以下を参照してください。

境界なしデータ

時間の経過とともに増加し、要素が到着したときに処理されるデータセット。PCollectionは、それが表すデータのソースに応じて、バウンドまたはアンバウンドにすることができます。Pub/SubやKafkaなどのストリーミングまたは継続的に更新されるデータソースから読み取ると、通常、アンバウンドのPCollectionが作成されます。

詳細については、以下を参照してください。

ユーザー定義関数

PTransformがデータに適用するカスタムロジック。一部のPTransformは、変換を構成する方法としてユーザー定義関数（UDF）を受け入れます。たとえば、ParDoはDoFnオブジェクトの形式でユーザーコードを期待します。各言語SDKには、ユーザー定義関数を表現するための独自の方法がありますが、シリアライズ可能性やスレッド互換性など、いくつかの共通要件があります。

詳細については、以下を参照してください。

ウォーターマーク

パイプラインのこの時点で（将来）表示されるタイムスタンプの下限の見積もり。ウォーターマークは、入力データの完全性を推定する方法を提供します。すべてのPCollectionには、関連付けられたウォーターマークがあります。ウォーターマークがウィンドウの終わりを過ぎると、そのウィンドウにタイムスタンプが到着したすべての要素は遅延データと見なされます。

詳細については、以下を参照してください。

ウィンドウ処理

個々の要素のタイムスタンプによってグループ化されたバウンドサブセットへのPCollectionの分割。Beamモデルでは、アンバウンドのPCollectionを含むすべてのPCollectionを、論理ウィンドウに細分化できます。PCollection内の各要素は、PCollectionのウィンドウ化関数に従って1つ以上のウィンドウに割り当てられ、個々のウィンドウには有限数の要素が含まれます。GroupByKeyやCombineなどの複数の要素を集計する変換は、ウィンドウ単位で暗黙的に機能します。

詳細については、以下を参照してください。

ワーカー

パイプラインの並列処理の一部を処理するコンテナ、プロセス、または仮想マシン（VM）。各ワーカーノードには、独自の独立したステートのコピーがあります。Beamランナーは、通信目的や永続化などの他の理由で、マシン間で要素をシリアル化する場合があります。

詳細については、以下を参照してください。