オプションのデータ永続化

ワークブック内の各変換について、ユーザーは結果をデータセットとして保存するかどうかを選択できます。

データセットとして保存するかどうかを選択

デフォルトでは、新しい変換はデータセットとして保存されません。それらを保存するには、ロジックペインのトグルを使用してください。

これらのスクリーンショットでは、NYC Taxi & Limousine Commission のオープンソースデータを使用しています。

複数の変換の永続化を一度に変更するには、左側のバルクエディタを使用してください。

保存された変換は、水平な青いバーで示されます。

実行モデル

ノードを実行すると、そのノードの上流にあるすべての非永続化ノードのロジックも実行されます。以下の図では、Saved Transform C を実行すると、Unsaved Transform A のロジックも実行されます。

Unsaved Transform A のコードを変更しても実行しないまま、Saved Transform C を実行すると、Saved Transform C の結果はロジックの変更が反映されます。

Unsaved Transform D を実行すると、Saved Transform C が Foundry のデータセットから読み込まれ、Unsaved Transform B のロジックが実行されます。

Saved Transform C のトグルを切り替えて、データセットとして保存されないようにすると、Unsaved Transform D を実行すると、上流の3つの変換のロジックがすべて実行されます。

この場合、この一連の変換を実行する際に、最終的な目標が Unsaved Transform D の結果を表示する場合、上流の3つの未保存の変換をプレビューする必要はありません。Unsaved Transform D を実行することで、4つの変換すべての最新のロジックと、インポートされたデータセットの最新のトランザクションが使用されます。

よくある質問

いつ変換をデータセットとして保存すべきですか？

変換が非常に計算量が多く、他の多くの変換の上流で使用される場合は、パフォーマンスが低下しないように、データセットとして保存することをお勧めします。

ワークブックの外で変換の結果を使用したい場合（例えば、別の Code Workbook や Contour 分析で使用する場合）、変換の結果をデータセットとして保存する必要があります。

変換が関数を非決定的に計算する場合（例えば、row_number 関数や現在の時間を呼び出す関数を使用する場合）、データセットを Foundry に永続化する必要があります。これにより、下流の変換がデータセットに書き込まれた正確な結果を使用することが保証されます。

いつノードをプレビューすべきですか？

一般的に、プレビュー機能は、変換の一連の処理を作成し、その正確性と結果をプレビューするために使用する必要があります。変換の一連の処理が確立されると、プレビュー機能を使用する理由が減少します。

なぜ未保存の変換が Data Lineage に表示されないのですか？

Code Workbook の未保存の変換は、プロジェクトのリソースではなく、ロジカルブロックです。 Data Lineage を探索すると、データセットは実行するすべてのコードを表示します。これには、保存された変換の上流にある未保存の変換のコードも含まれます。

例えば、このワークブックには1つの未保存の変換と1つの保存済みの変換が含まれています。

Data Lineage を探索すると、以下のように表示されます。selection 変換のコードが limiting 変換のコードの前に追加されていることに注意してください。

オプションのデータ永続化は、パフォーマンスとリソース使用にどのような影響を与えますか？

Code Workbook はもともと、各変換が Foundry データセットとして保存される実行モデルを使用していました。現在の実行モデルでは、ユーザーが変換をデータセットとして保存するかどうかを選択できますが、パフォーマンスとリソース使用に影響があります。

スケジュールされたビルド

以前の実行モデルで実行されるスケジュールされたビルドがあったとしましょう。新しい実行モデルでは、すべての変換が永続化されたままの場合、パフォーマンスは以前と同じままです。

中間変換の一部が Foundry データセットとして保存する必要がないと判断し、それらを非永続化することを選択した場合、パイプラインの速度に厳密なパフォーマンスの向上があります。これは、これらのノードの中間結果を Foundry に書き込まなくなるためであり、場合によっては、Spark クエリプランナが下流の計算をさらに最適化できるようになります。

インタラクティブな使用

インタラクティブなケースでは、古い実行モデルではプレビュー結果と書き込み結果の両方が計算されていました。オプションの永続化では、非永続化ノードはプレビューのみを計算し、永続化ノードは書き込みのみを計算します。したがって、重複する作業は行われず、同一のワークブックを実行すると、新しい実行モデルでは以前の実行モデルよりもリソースが少なくなります。

オプションの永続化がインタラクティブなケースでのパフォーマンスに与える影響はより繊細です。非常に計算量の多い変換があるワークフローの場合（例えば、大規模な結合など）、下流の変換を実行するたびに大規模な結合を再計算しないように、結合を永続化することが望ましいかもしれません。

すべての場合で、変換を非永続化にすることを決定すると、Foundry に書き込まないことでストレージスペースが節約されます。