安定性に関する推奨事項

このページでは、長期にわたって回復力と安定性を維持できるパイプラインを作成するための主な推奨事項を説明します。

すべての変更をバージョン管理する

データセットを生成するロジックは、すべてバージョン管理する必要があります。これにより、パイプラインで発生したリグレッションや変更を追跡しやすくなります。具体的には、次の点が重要です。

1. 本番運用レベルのパイプラインをセットアップする際は、Contour や Code Workbook の使用を避けます。これらのツールでは変更の追跡がより難しいためです。これらのツールは開発段階では非常に有用ですが、パイプラインが成熟するにつれて、機能を Transforms で書き直す必要があります。できれば Python または Java を使用します。
2. すべてのコードリポジトリで master ブランチがロックされ、すべての変更にプルリクエストとコードレビュアーの承認が必要になっていることを確認してください。
3. マージする際は、常にコミットをまとめてマージすることを推奨します。これにより、master のコミット履歴を整理された状態に保てます。

よくあるデータ品質エラーを隔離する

「影響を受けやすい」または「不安定な」データセットは、検証ステップを通じてパイプラインのほかの部分から隔離する必要があります。特に、Fusion で作成されたデータセット、手動のデータアップロード、およびその他の種類のアップロードは、パイプライン全体に影響を及ぼすデータ品質の問題が発生しやすくなります。

以下の例では、Fusion というデータセットでデータ品質の問題（スキーマの変更、パースエラー、不完全なデータなど）が頻繁に発生し、パイプラインのほかの部分に影響を及ぼしていると仮定します。

解決策は、検証ステップに合格した場合に Fusion からデータをコピーする Fusion Validated データセットを作成することです。

Fusion Sheets と手動アップロードに検証データセットを追加した Data Lineage グラフの例

Copied!
1
2
3
4
5
6
7
8
9
10
11
12
13
# 検証コードの例
@transform(
    input=Input("/MyProject/Fusion"),
    validated_input=Output("/MyProject/Fusion Validated"),
)
def validate(input, validated_input):
    found_dtypes = input.dataframe().dtypes

    assert len(found_dtypes) >= 8, "Schema break, column count too low"

    assert ("hours", "int") in found_dtypes, "'hours' has to be an int"

    validated_input.write_dataframe(input.dataframe())

Fusion が更新されるたびに Fusion Validated をビルドするイベントベースのスケジュールを作成します。

Fusion Validated をほかのパイプラインへの入力として扱います。ビルド対象からは除外し、関連するヘルスチェックを適用します。潜在的なエラーや問題を知らせるために Fusion の更新担当者へ連絡する必要がある場合があるため、ビルドステータスは重要です。

同じ考え方は、Manual Upload と Manual Upload Validated データセットにも当てはまります。

Apex 1 のビルドから除外されたデータセットを強調表示した Data Lineage グラフの例

Data Connection の同期は、オーケストレーションシステムによって常に最新と見なされるため、ビルドから明示的に除外する必要はありません。上のグラフで青色になっていることは、取り込みがトリガーされることを意味しません。

共有リソースを扱う

プロジェクト内の多くの異なるパイプラインに属するデータセットがある場合があります。ビルドのタイミングが完全に揃っていない場合、一部のパイプラインは、このデータセットのビルド待ちでブロックされることがあります。

この場合は、必要な頻度で共有データセットをビルドする新しいパイプラインを作成し、その共有データセットをほかのパイプラインへの入力にする（スケジュールのビルド対象から除外する）ことを検討する必要があります。ただし、このような操作は、パイプラインの設定を大幅に複雑にします。絶対に必要な場合を除き、実施しないことを推奨します。

この問題を回避するための、既存の構成への影響がより小さい別の方法は、共有リソースを1つのパイプラインまたはスケジュールでのみビルドし、ほかのすべてのパイプラインでは入力として扱うことです。たとえば、前の図では、Shared をパイプラインの1つへの入力として扱います（つまり、1つのスケジュールを除くすべてのスケジュールから除外します）。

部分的な実行を避ける

パイプラインの一部だけを実行したり、データセットに対して「フルビルド」を実行したりすることは避ける必要があります。

パイプラインは、最新であるか、最新でないかのいずれかです。パイプラインの一部だけを実行すると（たとえば、エクスポート段階だけ）、整合性のない状態になり、パイプラインが正常かどうかの判断が難しくなる可能性があります。末端のデータセットに対して「フルビルド」を実行すると、そのビルドには、パイプラインの実行時に使用する必要がある関連オプション（再試行、失敗時の戦略、除外設定など）がすべて欠けることになります。ビルドを手動で開始する必要がある場合は、必ずスケジュールの概要ページにある「今すぐスケジュールを実行」ボタンを使用し、スケジュールの設定に従ってビルドを実行してください。