ジョブ スケジュールのアンチパターンの特定
- バッチデータレイクの取得
- プロファイルのバッチインジェスト
- バッチセグメント化
- バッチ宛先のアクティベーション
ジョブスケジュール のタイムラインビューは、データパイプラインのパフォーマンスと信頼性に悪影響を与える可能性のある一般的な設定問題を特定するのに役立ちます。 こうしたアンチパターンは、しばしばジョブの失敗、データの不整合、システムパフォーマンスの低下につながります。 これらのパターンを早期に発見することで、ビジネスに影響を与える前に問題を回避するために、ジョブを再構成できます。
前提条件 prerequisites
アンチパターンを特定する前に、次のことをおこなう必要があります。
- Job Schedules View Job Schedules アクセス制御権限でにアクセスできます。
- ジョブスケジュールのインターフェイス と、タイムラインビューの読み取り方法について説明します。
- 基本的な バッチ取り込み、 セグメント化、 プロファイル処理の概念について説明します。
クイックリファレンス anti-pattern-quick-reference
スケジュール重複 schedule-overlap-pattern
影響の重要度：高| プライマリの問題：リソースの競合
探すべきこと：複数のジョブが同時に実行または連続して実行するようにスケジュールされています。特に、リソースを多く消費するジョブが重複している場合に注意してください。
一般的な例としては、スケジュールされたセグメンテーションジョブと同時にバッチ取り込みジョブが実行されます。 これにより、両方の操作に大きな処理能力とメモリが必要なため、リソースの競合が発生します。
問題がある理由:
- リソース競合：複数のリソース集約型ジョブを同時に実行すると、システムリソース（CPU、メモリ、I/O）を競合して、すべてのジョブの実行が遅くなります。
- 予測不可能なパフォーマンス：ジョブの期間に一貫性がなくなり、信頼性の高いスケジュールを計画することが困難になります。
- カスケーディング遅延：ジョブが予想よりも時間がかかる場合、下流の依存ジョブが遅延し、パイプライン全体に波及効果が生じる可能性があります。
- エラーのリスクが高まります: リソースの使い果たしにより、ジョブがタイムアウトしたり、完全に失敗したりする可能性があります。
解決方法:
- ジョブスケジュールを時間差にする: リソース集約的な操作を同時に実行するのではなく、順次実行します。
- バッファー時間を追加：処理のバリエーションを考慮して、ジョブ間に十分な間隔を空けます。
- 依存関係を確認：他のユーザーが安全に開始する前に完了する必要があるジョブを特定します。
スケジュールされた作業密度 scheduled-density
影響の重要度：高| プライマリの問題: パイプラインのボトルネック
検索対象：複数のバッチが同じ時間内にスケジュールされたデータセットが多すぎます。特に、これらのバッチが近くに積み重ねられ、セグメント化の開始時間などの重要な処理ウィンドウの近くでスケジュールされている場合に注意してください。
このパターンには、通常、次のものが含まれます。
- 1日に複数のバッチを実行する複数のデータセット
- ETL ジョブ（データレイクの取り込みとプロファイルの取り込み）が同じ時間内にクラスター化されます
- スケジュールされたセグメンテーションウィンドウの直前またはスケジュールされたバッチ取り込み
問題がある理由:
- パイプラインのボトルネック：異なるデータセットからの多数のバッチが短い時間内に積み重なると、取り込みパイプラインを圧倒する処理のボトルネックが生じます。
- プロファイルの可用性の遅延: セグメント化の開始時間に近すぎて実行されるプロファイル取り込みジョブが時間内に完了しない可能性があり、その結果、オーディエンスの評価が不完全または陳腐化する可能性があります。
- 予測不可能なセグメンテーション: セグメンテーションの開始時にアップストリーム取り込みジョブが引き続き実行されている場合、不完全なデータに対してオーディエンスを評価するリスクがあり、オーディエンスメンバーシップが正しくありません。
- カスケーディングエラー：重なり合ったスケジュール内の1つの遅延バッチがドミノ効果を引き起こす可能性があり、その後のすべてのバッチとダウンストリームプロセスが遅延します。
- リソースひずみ：処理中の取り込みジョブが多すぎると、システムが十分なリソースの割り当てに苦慮し、処理時間が遅くなったり、エラーが発生したりする可能性があります。
解決方法:
- バッチの統合：複数の小さいバッチを、データセットごとに少ない大きいバッチにまとめて、バッチの頻度を減らします。
- 均等に配布：取り込みジョブを特定の時間にクラスタリングするのではなく、1日を通して分散させます。
- バッファー時間を追加: プロファイルの取り込みの完了からセグメント化の開始までの間に、最低1～2時間のバッファーを確保します。
- 要件を確認：すべてのデータセットが本当に複数の日次バッチを必要とするかどうかを評価します。 多くのユースケースでは、更新の頻度を減らすことができます。
データセットあたりの過剰なバッチ excessive-batches-per-dataset
影響の重要度: Medium | プライマリの問題：非効率的な処理
何を探すべきか:1日を通してスケジュールされた個別のバッチジョブの数が多すぎる単一のデータセットで、タイムライン上に縦のジョブスタックが長く作成されます。
このパターンでは、多数の個々のバッチ取り込みジョブを頻繁に、1日に何十回ものバッチでスケジュールした単一のデータセットが必要です。
問題がある理由:
- 非効率的な処理：各バッチジョブには、オーバーヘッドのコスト （初期化、検証、メタデータの更新）があります。 多数の小さいバッチの処理は、多数の大きいバッチの処理よりも大幅に効率が低くなります。
- エラーの増加：ジョブが増えることで、エラーの機会が増えます。 失敗した各バッチには、調査と潜在的な再処理が必要です。
- 不要なシステム読み込み：頻繁に発生する小さなバッチにより、実際のデータ処理ではなくオーバーヘッドのタスクでシステムが常にビジー状態になり、全体的なスループットが低下します。
- データの可用性の遅延：逆説的に、多数の小さいバッチを実行すると、統合されたバッチと比較して、下流プロセスでデータが利用可能になるときに遅延する可能性があります。
- 困難な検査: データセットごとに数十のバッチジョブの成功とパフォーマンスを追跡すると、操作が複雑になり、時間がかかります。
- プロファイル処理の遅延：各プロファイル取り込みバッチトリガープロファイル処理。 小規模なバッチが頻繁に実行されると、プロファイル処理がほぼ継続的に実行され、効率的なバッチ最適化が妨げられる可能性があります。
解決方法:
- バッチ頻度を減らす：ほとんどのユースケースで、データセットごとに1日あたりのバッチ数を減らします。
- バッチサイズを増やす：すぐに取り込むよりも取り込みをトリガーする前に、より多くのデータを蓄積します。
- ビジネスニーズに合わせる：毎時間の更新が本当に必要かどうか、または毎日/2回の毎日の更新で十分かどうかを確認します。
- リアルタイムにストリーミングを使用：頻繁なバッチを使用してストリーミングをシミュレートするのではなく、リアルタイム要件を満たすストリーミング取り込みに切り替えます。
次の手順 next-steps
ジョブスケジュールのアンチパターンを特定した後：
- ジョブの詳細を表示して、特定のデータセットと問題の原因となる可能性のあるジョブ実行を調査します。
- ジョブスケジュールの概要を確認して、インターフェイスとインスペクション機能について確認します。
- データ読み込みスケジュールを最適化するための バッチ取り込みについて説明します。
- オーディエンス評価の適切なタイミングを確保するために、 セグメント化スケジュール について理解します。
- エンドツーエンドのパイプラインを可視化するために、宛先データフローの監視を確認します。