RDD ベースのパターン

実装がより煩雑になっていますが、 RDD ベースのパターンを使用すると、結合、フィルタリング、マッピングなどの Spark 操作を利用する実際のビジネスロジックを自由に実装できます。 これらの操作によって、メタデータだけでなく、実際のデータも削減されます。

機能パターンでは、 Spark を使用して関数アプリケーションを並列化しますが、これらの関数は RDD を参照できません。 対照的に、 RDD ベースのパターンでは、実装するインターフェイスのパラメータおよび戻り値として RDD が使用されます。

ただし、重要な欠点が 1 つあります。コンパイラーの実装では、インクリメンタル・コンパイルをアクティブにサポートする必要があります。 つまり、このデータ プロセッシング ライブラリのキー機能は完全には透過的ではありません。コンパイラは、作業を完了してインクリメンタル処理を適切にサポートするために、各パターンによって要求された情報を含む追加の DDD を協力して返します。 この処理を行わなかった場合、またはパターンの指定内容に従わない RDD を返す場合、コンパイラーをインクリメンタルに実行すると無効なマップが作成されます。

関数が返す RDD の内容については、以下のセクションで詳しく説明します。

次の RDD ベースのパターンを使用できます。

• NonIncrementalCompiler
• DepCompiler および IncrementalDepCompiler

NonIncrementalCompiler

このパターンにより、開発者は最大限の自由を得ることができます。 Spark は、入力データ RDD から直接アクセスできます。 開発者は、任意の種類のコンパイルを実装して、公開する必要があるペイロードの RDD を返すことができます。 ただし、このパターンはインクリメンタル・コンパイルをサポートしていません。

これは最も一般的なコンパイルパターンであり、特定の適用性の制約はありません。

一般的な使用例

開発者が Spark 変換に関してコンパイラを自由に実装したい場合。

高レベルのインターフェイス

フロントエンドとバックエンドの区別はありません。 実装される機能は次のとおりです。

• Compile ( コンパイル : RDD[(InKey, InMeta)] )⇒ RDD[(OutKey, Option[Payload]]

ランタイム特性

コンパイラーはステートレスです。 このパターンでは、デザインによってインクリメンタル・コンパイルがサポートされていないため、状態が存在しません。

参照

• TaskBuilder: withNonIncrementalCompiler メソッド
• NonIncrementalCompiler: 実装するメインインターフェイス

DepCompiler および IncrementalDepCompiler

これらのコンパイル・パターンは、 reduce 関数が実際には何も削減せずに、同じキーで要素をグループ化する map-reduce コンパイルを実装します。 このパターンは、 MapGroup 機能コンパイラと同じです。

これらの 2 つのパターンは同等です。 IncrementalDeCompiler は DeCompiler を専門化したもので、より効率的なインクリメンタル・コンパイルのためのロジックを追加します。

このコンパイルパターンは、 MapGroupCompiler のすべてのケースで使用できます。

DepCompiler ロジック

IncrementalDepCompiler で追加のロジックが導入されました

一般的な使用例

このパターンは、次のような入力内容が変換で考慮される場合に使用します。

• 入力パーティションをデコードし、異なる出力パーティション間で、またはコンテンツの機能としてコンテンツを配信します。
• 入力データのサブセットを持つ出力レイヤーを作成しています。
• 入力レイヤーから出力レイヤーへのオブジェクトの分配、レベルの上下の移動、またはオブジェクトのプロパティの関数としての移動が可能です。
• 国やタイルなどでのコンテンツのインデックス付け。

高レベルのインターフェイス

T および C は、開発者が定義したタイプです。 依存関係グラフまたはそのサブセットの形式 RDD[(InKey, OutKey)]はです。

CompileIn ( 非インクリメンタルコンパイラフロントエンド ):

• compileIn (inData: RDD[(InKey, InMeta)] ⇒ 依存関係グラフと RDD[(OutKey, T)]

CompileIn ( フロントエンドを段階的に実行するための追加機能 ):

• updateDepGraph(inData: RDD[(InKey, InMeta)] 、 inChanges ： RDD[(InKey, InChange)], 前の依存関係のグラフ)⇒ 依存関係のグラフを更新し、次の呼び出しでは C を更新しました

compileIn (inData: RDD[(InKey, InMeta)] 、 依存関係グラフのサブセット、 前回の呼び出しからの C *)⇒ RDD[(OutKey, T)]

CompileOut ( コンパイラのバックエンド ):

• compileOut ( コンパイル : RDD[(OutKey, iterable[T])))⇒ RDD[(OutKey, Option[Payload]]]

ランタイム特性

どちらのバージョンもステートフルです。

DepCompiler では compileIn 、は常にインクリメンタルモードでも入力カタログのセット全体で実行 compileOut されます。は、ライブラリが再コンパイルの候補として検出した出力パーティションのサブセットで増分的に実行されます。

IncrementalDeCompiler では、 compileIn (1 ^番目のバージョン ) は、非インクリメンタルケースの入力カタログのセット全体で実行されます。 増分の場合は、代わりに updateDepGraph compileIn (2 ^番目のバージョン ) を実行します。 データ全体と変更の両方にアクセス権が付与されます。 compileOut前の例と同様に、は出力パーティションのサブセットでのみ実行されます。

参照

• TaskBuilder: withDepCompilerおよびwithIncrementalDepCompilerメソッド
• DepCompiler: 実装するメインインターフェイス ( 非インクリメンタルフロントエンド、増分バックエンド )
• IncrementalDepCompiler: 実装するメインインターフェイス ( インクリメンタルフロントエンドおよびバックエンド )