Spark を介した Data API とのインターフェイス

この処理ライブラリを使用する場合は、InputLayersとOutputLayersの特性をCompilers実装して混合します。 これらのインターフェイスは、カタログおよびレイヤー ID のデータ構造を定義します。 これらのインターフェイスを実装することで、各コンパイラが必要とする入力カタログおよび入力レイヤーを処理ライブラリに通知できます。 処理中のライブラリは、入力カタログを適宜照会し、コンパイラーにメタデータを提供します。 さらに、処理ライブラリでは、各コンパイラーが生成する出力レイヤーを指定する必要があります。

データ プロセッシング ライブラリは、この情報を使用して、を介したインクリメンタル公開を実装し Publisherます。この場合、各コンパイラーで指定された出力レイヤーが公開前に照会され、次のものを検出します。

• どのパーティションに新しいペイロードが含まれているか
• 変更されていないパーティション
• 削除するパーティション

出力カタログは 1 つだけなので、または application.conf アプリケーションを実行するときに、識別子を指定する必要はありません。 ただし、パーティションキーには識別さ Default.OutCatalogId れたカタログが含まれているため、コンパイラーがキーを出力するときにこの値を使用する必要があります。

入力レイヤーおよびカタログは、複数 DriverTaskの間で共有できます。処理ライブラリは、 Data API を 1 回のみ照会することで、このレイヤーおよびカタログを最適化します。 ただし、出力カタログの各レイヤーは 1 つのタスクでのみ作成できます。 インクリメンタルパブリッシングを実装するには、この操作が必要 Publisher です。は、比較、条件付きアップロード、およびマルチパートコミットを適切に実行するために、 1 つの場所にパブリッシュされるレイヤー候補のすべてのメタデータを収集します。

2 つ以上のタスクで同じ出力レイヤーが指定されていると、 2 番目のタスクによってレイヤーが完全に上書きされ、無効な出力になるため、誤りがあります。

次の項では、CatalogおよびPublisherの重要な内部構造について説明します。これらの内部構造は、Driverによって動作します。 これらの内部構造を直接操作する必要はありませんが、この情報は、入力カタログへのアクセス方法およびペイロードが出力カタログにプッシュされる方法を理解するために必要です。

カタログを照会します

com.here.platform.data.processing.catalog パッケージには、 Spark RDDを介してカタログにアクセスするための API が含まれています

Catalog この特性を使用すると、 Spark 経由で Data API カタログに簡単にアクセスできます。

データ クライアント ライブラリを介して、次の操作がサポートされます。

• スナップショットクエリ : 特定のバージョンのカタログのすべてのメタデータの RDD を作成し、最終的には一連のレイヤーに限定します。
• 変更クエリ : 2 つのバージョン間で変更されたメタデータの RDD を作成します。最終的には一連のレイヤーに制限されます。
• コミット : coalesceメタデータ (RDD) の Spark を一定数のパーツに再グループ化 ( 更新 ) し、並列でアップロードして、複数パーツのコミットを実行します。
• 設定 : カタログ設定に簡単にアクセスできます。

ほとんどのクエリは、最新バージョンの設定とクエリを除き、 Spark ワーカーノードによって並行して実行されます。 これにより、メタデータがに集中せ Driverず、スケーラビリティを妨げるボトルネックを回避できます。

カタログをパブリッシュしてコミットします

com.here.platform.data.processing.publisher このパッケージには、データ処理の終了時に出力ペイロードをパブリッシュして結果をコミットするための高レベルの機能があります。 このPublisherクラスには、コンパイルの出力をパブリッシュする ための 2 つの方法があります。フルスナップショットのパブリッシュとインクリメンタルパブリッシュです。 いずれの場合も、で Publisher は次の入力が必要です。

• 公開する候補となる出力キーおよびペイロードの RDD
• 出力カタログのメタデータの RDD 。すでに公開されているものが含まれています

は Publisher 、次の手順を実行します。

1. キー（パーティション + レイヤー）を介してペイロードを結合します。キーは、メタデータがすでに公開されている状態で公開される候補です。
2. ペイロードのハッシュを計算します。
3. ハッシュがすでにパブリッシュされているものに対応する場合は、すべてのペイロードを廃棄します。変更されていない出力データはすべて廃棄されます。
4. によって実際に新しいすべてのペイロードがアップロード Uploaderされ、新しいメタデータエントリが生成されます。
5. にコミットするメタデータの RDD を返し Catalogます。

ただし、この 2 つの公開方法は、次の点で異なります。

• フルスナップショット公開 では、入力で明示的に指定されていない出力カタログの各エントリが削除され、結果としてコミットされます。
• インクリメンタル公開 では、出力カタログで提供されていないパーティションは変更されません。

新しい Publisherパーティションコンテンツまたは 削除 リクエストのいずれかによってに提供された変更は、既存のパーティションの上に適用されます。

発行元は、ハッシュの違いに基づいてインクリメンタル発行を実行するだけで、インクリメンタルコンパイラではありません。

いずれの場合も、次の手順を

• 新たに導入されたキーのペイロードがアップロードされ、新しいメタデータとしてコミットされます。
• 出力にすでに存在するキーのペイロードは、変更されていない場合は廃棄され、変更されたメタデータとしてアップロードおよびコミットされます。
• 出力にすでに存在するキーの空のペイロードがメタデータから削除されます。

この処理はすべて、ハッシュの計算と比較、最終的なアップロード、コミットするメタデータの生成など、 Spark ワーカーノードで行われることに注意してください。 結果のメタデータが含まれている RDD は Catalog 、実際のコミットのためににに渡すことができます。

状態レイヤー

ライブラリでは、内部で使用するために、出力カタログに汎用パーティション分割方式で設定された追加のレイヤーが必要です。 アプリケーションはこのレイヤーにデータを公開できません。 レイヤー ID は設定可能ですが、デフォルトの名前は state :layer です。

state このレイヤーは、ステートフルコンパイルパターンによって使用され、一部の RDD を永続化して、次の実行時にそれらを取得します。

通常、これらの DDs 内では、入力出力の依存関係グラフが永続化されます。 このグラフでは、どの入力パーティションがどの出力パーティションに影響するかを指定します。 この情報はごとDriverTask に保存され、再コンパイルおよび再公開の候補となる出力パーティションを特定するために、インクリメンタルコンパイルで必要になります。

また Fingerprints、増分実行の正確性を保証するために必要なも、このレイヤーに保存されます。