フル同期と増分同期タスクの管理 - DataWorks - Alibaba Cloud - DataWorks

全データベースの全量・増分同期タスクは、ソースデータベースのデータベースとテーブルのスキーマ、履歴データ、および進行中の変更を MaxCompute などの宛先に同期します。このトピックでは、これらのタスクに関する一般的な運用保守オペレーション、トラブルシューティング方法、チューニングの推奨事項、およびアラート設定について説明します。

適用範囲と境界

このトピックを適用する前に、タスクの形式とデータパスを評価してください。

チェック項目	適用範囲	適用されない場合
タスク形式	履歴フルデータ + リアルタイム増分 + スケジュールされた出力またはマージ	リアルタイムでのみデータを書き込むメッセージソースについては、「リアルタイム全データベース同期：運用とチューニング」をご参照ください。
データパス	データベースソース → MaxCompute、データレイク、またはスナップショットやパーティションを生成する宛先	このトピックの方法は、宛先がスケジュールされた出力またはマージをサポートしていない場合には適用されません。

このトピックの方法は、次のタスク機能に依存します：新しく追加されたテーブルのフルデータ初期化、全量ステージとリアルタイムステージ間のハンドオフ、テーブル追加時のチェックポイント保護、およびスケジュールされた出力またはマージノード。タスクがこれらの機能のいずれかをサポートしていない場合、ダウンストリームの結果が不完全になる可能性があります。

このトピックは、全データベースの全量・増分同期タスクにのみ適用されます。リアルタイム増分タスクについては、「リアルタイム全データベース同期：運用とチューニング」をご参照ください。スケジュールされたバッチでのみデータを同期するタスクについては、「オフラインデータベース同期の運用保守とチューニング」をご参照ください。

タスクのステージ

全量・増分同期タスクは、次のステージを経て実行されます：

ステージ	説明	運用保守の焦点
スキーマ移行	ソースデータベースとテーブルのスキーマを宛先に移行します	ソースメタデータの権限、宛先テーブルの作成権限、フィールドタイプのマッピング、およびテーブルマッピングルール
フルデータ初期化	ソースの履歴データを一度に宛先に書き込みます	分割キー、全量並列度、ソース接続、ソースのクエリパフォーマンス、および宛先の書き込み能力
リアルタイム増分	全量ステージの開始後に発生するソースの変更を継続的に消費します	チェックポイントの遅延、フェールオーバー、チェックポイント、DDL、およびソースログの保持
増分マージ	増分変更データを定期的に宛先スナップショットテーブルまたは宛先パーティションにマージします。一部のソリューションのみがこのステージを含みます。	増分マージのスケジューリング、アップストリームの増分データが追いついているかどうか、データタイムスタンプ、宛先パーティション、および SQL 実行時間

説明

フルデータ初期化中もソースはデータの書き込みを続けることがあります。全量ステージが終了した後、タスクはソースに追いつくまで増分データをリプレイします。全量ステージの完了は、タスク全体の完了を意味するものではありません。リアルタイム増分が追いついたことも確認する必要があります。

前提条件

全量・増分同期タスクを操作またはトラブルシューティングする前に、次の項目を確認してください：

DataWorks ワークスペースとデータ統合用のリソースグループ。
ソースと宛先のデータソース接続が設定されており、リソースグループと両エンドポイント間のネットワーク接続が確立されていること。
ソースアカウントに、データベースとテーブルのメタデータ、およびバイナリログまたは WAL を読み取る権限があること。
宛先アカウントに、テーブルの作成、テーブルの変更、およびデータの書き込み権限があること。
(タスクが増分マージを含む場合) スケジュールされた出力またはマージノードをサポートする宛先。MaxCompute の場合、宛先テーブルのスキーマがマージ SQL の実行をサポートしている必要があります。
(タスクを再実行する予定の場合) Hologres または MaxCompute の宛先。

タスクの検索と実行詳細の表示

[Data Integration] > [同期タスク] を選択して、同期タスクリストを開きます。タスクリストには、各タスクの基本情報と現在の実行ステータスが表示されます。タスク名、タスクのステータス、作成時刻、データソースタイプ、および宛先タイプでタスクをフィルタリングできます。

タスク名をクリックすると、タスクの実行詳細ページが開きます。このページは、日常的な運用や問題調査の際の主要な監視インターフェイスとして使用します。このページには、次の情報が表示されます：

現在のステージ (スキーマ移行、フルデータ初期化、リアルタイム増分、または増分マージ) を示すタスクの進捗バー。タスクがどのステージにあるかを特定するために使用します。
各ステージのサブタスクリスト。個々のサブタスクを確認し、どのサブタスクが失敗したか、または実行が遅いかを特定するために使用します。
チェックポイントの遅延やスループットを含むリアルタイム同期ステータス。これらのメトリクスを使用して、リアルタイム増分がソースの変更に追いついているかどうかを評価します。
より詳細な調査のためのタスクログと監視メトリクスへのリンク。

一般的な運用保守オペレーション

タスクリストの [操作] 列から次の操作を実行します。

タスクの開始と停止

タスクを開始するには、[送信して実行] をクリックします。タスクが開始されたら、まずスキーマ移行とフルデータ初期化が正常に実行されるかを確認し、次にリアルタイム増分が追いついているかを確認します。

タスクを停止するには、[操作] 列の [停止] をクリックします。タスクを停止する前に、現在のステージを確認してください：

フルデータ初期化中にタスクを停止すると、リカバリ後に一部の全量サブタスクを再実行する必要がある場合があります。
リアルタイム増分中にタスクを停止すると、リカバリはソースログの保持期間に依存します。
増分マージを含むタスクを停止する場合は、宛先パーティションにすでに出力の一部が含まれているかどうかを確認してください。

設定の変更と更新の適用

全データベースの全量・増分同期タスクに対する一般的な変更には、テーブルの追加、テーブルの削除、テーブルマッピングの調整、リソースの調整、および高度なパラメーターの変更が含まれます。タスクを変更するには、[操作] 列で [その他] > [設定の変更] を選択します。変更を行った後、タスクを送信して更新を適用します。変更は送信後にのみ有効になります。

次の表に、最も一般的な変更タイプのリスクポイントと推奨事項を示します。リソースとパラメーターのチューニングガイダンスについては、「チューニングの推奨事項」をご参照ください。

変更タイプ	リスクポイント	推奨事項
テーブルの追加	新しいテーブルはスキーマ移行とフルデータ初期化を必要とし、初期化完了後にリアルタイム増分に参加します	ビジネスのピーク時を避けてください。ソースログの保持期間が十分であることを確認してください。新しいテーブルに対して全量ステージと増分ステージの両方が完了したかどうかを確認してください。
テーブルの削除	既存のテーブルマッピング、リソースファイル、および宛先データに影響を与える可能性があります	削除する前に、ダウンストリームシステムがそのテーブルに依存しなくなったことを確認してください。既存のタスクを正常に送信できない場合は、新しいタスクを作成して引き継ぎます。
テーブルマッピングの変更	全量の書き込み、リアルタイムの書き込み、および増分マージの結果に影響を与える可能性があります	全量テーブル、増分テーブル、および最終的な宛先テーブルのマッピングを一緒に確認してください。
リソースの調整	ソースのクエリ、宛先の書き込み、およびリソースグループの消費に影響します	ステージごとにチューニングしてください。全量ステージとリアルタイムステージに同じ基準を適用しないでください。

高リスク操作のチェックリスト

再実行、データバックフィル、テーブルの大規模なバッチ追加、テーブル削除、または主要なパラメーター変更を実行する前に、次の項目を確認してください：

現在の問題がどのステージで発生しているか。
操作の範囲：データベース全体、特定のテーブル、特定のデータタイムスタンプ、または特定の宛先パーティション。
ソースのログ保持期間が十分か。
既存の宛先データが上書きまたは再書き込み可能か。
同じデータタイムスタンプまたは宛先パーティションのインスタンスを含め、増分マージインスタンスが実行中または実行予定か。
ダウンストリームシステムが、影響を受ける宛先テーブル、パーティション、またはデータタイムスタンプを読み取っているか、それに依存しているか、また操作完了後にダウンストリームノードを再実行する必要があるか。
ソースとデスティネーションが、追加の読み取りおよび書き込み負荷またはより高いコンカレンシーを処理できるかどうか。

タスクの再実行

宛先データが破損している場合、リアルタイムタスクが長期間失敗している場合、ソースログをリプレイできない場合、またはタスクを再初期化する必要がある場合に、再実行を検討してください。[操作] 列で [その他] > [再実行] を選択して、すべてのソーステーブルの全量および増分の再初期化を強制します。

強制再実行には、次の制限が適用されます：

Hologres と MaxCompute の宛先のみが強制再実行をサポートします。シャーディングされた全量・増分同期タスクは強制再実行をサポートしません。
強制再実行は、ソーステーブルの列を宛先テーブルに同期します。宛先テーブルにソーステーブルに存在する列が欠落している場合、欠落している列が追加されます。

再実行する前に、「高リスク操作のチェックリスト」のチェックを完了してください。

警告

増分マージを含むタスクでは、再実行とマージが同じデータタイムスタンプまたは同じ宛先パーティションを同時に処理してはなりません。同じデータタイムスタンプで同時に実行すると、パーティションデータまたはテーブルデータが上書きされる可能性があります。

競合の可能性がある場合は、次のいずれかの方法を使用してください：

再実行を一時停止し、競合する増分マージインスタンスが完了するのを待ってから、再実行を実行します。
今後実行される増分マージインスタンスを凍結し、再実行が完了するのを待ってから、インスタンスの凍結を解除します。

再実行が完了した後、増分マージインスタンスが自動実行を再開することを確認してください。翌日にデータが生成されない場合、または増分マージインスタンスが再開しない場合は、手動でインスタンスを確認し、再開してください。

全データバックフィル

一部のテーブル、一部のパーティション、または一部のデータタイムスタンプで宛先のデータが欠落している場合は、全データバックフィルを使用してデータを修復します。全データベースの全量・増分同期タスクのみが全データバックフィルをサポートします。[操作] 列の [全データバックフィル] をクリックし、パラメーターを設定します。

データバックフィルを実行する前に、「高リスク操作のチェックリスト」のチェックを完了し、次の操作固有の項目を確認してください：

リアルタイム増分が追いついているかどうか。

複数のデータタイムスタンプをバックフィルする場合は、バッチでバックフィルを実行し、次のバッチに進む前に各バッチを検証してください。これにより、バックフィルとリアルタイム増分、増分マージ、およびダウンストリームのスケジューリングとの間の干渉を防ぎます。

トラブルシューティング方法

タスクのステータスに加えて、メトリクスとログを組み合わせて、きめ細かいトラブルシューティングを行います。典型的なトラブルシューティング対象には、スキーマ移行、フルデータ初期化、リアルタイム増分、チェックポイント、スケジュールされたインスタンス、データタイムスタンプ、宛先パーティション、およびマージ SQL が含まれます。タスクの実行詳細ページで、タスクの進捗、サブタスクのステータス、チェックポイントの遅延、スループット、ログ、および監視メトリクスを表示できます。詳細については、「タスクの検索と実行詳細の表示」をご参照ください。

問題が属するステージを特定し、対応するセクションに進んでください：

症状	ステージ	セクション
権限、メタデータの読み取り、宛先テーブルの作成、フィールドタイプ、またはテーブルマッピングが原因でスキーマ移行が失敗する	スキーマ移行	スキーマ移行の失敗
フルデータ初期化がスタックする、開始しない、または実行が遅い	フルデータ初期化	フルデータ初期化の遅延またはスタック
リアルタイム増分のレイテンシーが増加する、または全量ステージ完了後にリアルタイム増分が追いつけない	リアルタイム増分	リアルタイム増分のレイテンシー
スケジュールされた出力または増分マージが生成されない、またはデータが不完全である	増分マージ	マージが生成されない、またはデータが不完全
テーブルの追加・削除後の予期しない結果、DDL エラー、ダーティデータ、再実行またはバックフィル後の競合など、その他の症状	複数のステージ	よくある質問

スキーマ移行の失敗

スキーマ移行の失敗は、通常、権限、メタデータの読み取り、宛先テーブルの作成、フィールドタイプ、およびテーブルマッピングに関連しています。次の項目を順番に確認してください：

ソースアカウントにデータベースとテーブルのメタデータを読み取る権限があるかどうかを確認します。
タスクリソースグループがソースと宛先に接続できるかどうかを確認します。
宛先アカウントにテーブルの作成、テーブルの変更、およびデータの書き込み権限があるかどうかを確認します。
宛先のデータベース、スキーマ、または名前空間が存在するかどうかを確認します。
テーブル名のマッピングが競合していないか、またフィールドタイプとパーティションフィールドに互換性があるかどうかを確認します。

フルデータ初期化の遅延またはスタック

フルデータ初期化の遅延またはスタックは、バッチサブタスクの問題として扱ってください。リアルタイムレイテンシーの方法でトラブルシューティングしないでください。まず、どのステージがスタックしているかを確認し、次に全量サブタスクが開始されているかを確認します。

チェック項目	判断方法	推奨事項
ソースのクエリパフォーマンス	ソースデータベースの CPU 使用率が高い、I/O が高い、SQL クエリが遅い、ロック待機がある、または接続数が多い	ソースのクエリを最適化し、ビジネスのピーク時を避け、必要に応じて並列度を下げてください。
分割キー	一部のスライスが他のスライスよりも著しく時間がかかる	より均一な分割キーを選択してください。適切な分割キーが存在しない場合は、並列度を上げないでください。
ソース接続またはクォータ	ログにクォータ不足または接続数が少なすぎることが示されている	ソースの接続またはデータソースのクォータを適宜増やし、ソースデータベースの負荷を監視してください。
全量並列度	ソースと宛先の両方に予備容量があるが、スループットが低い	並列度を徐々に上げてください。一度に高い値に上げないでください。
宛先の書き込み	宛先がレート制限されている、書き込みが遅い、またはパーティションが多すぎる	まず、宛先のリソース、レート制限、およびパーティション設計に対処してください。
リソース仕様	CPU、メモリ、またはネットワークがボトルネックになっている	リソース仕様またはコンピューティングユニットを増やし、ガベージコレクションと障害率を監視してください。

リアルタイム増分のレイテンシー

リアルタイム増分ステージをトラブルシューティングする際は、まずチェックポイントの遅延、読み取り/書き込みスループット、ウィンドウ待機時間を確認します。次に、ログ、フェールオーバーイベント、チェックポイント、JVM メトリクス、ガベージコレクション、バックプレッシャー、DDL イベントを確認します。

一般的な原因は次のとおりです：

ソースの大規模なトランザクション、またはバイナリログや WAL の急激な増加。
ソースのパーティションまたはシャードの偏り。
宛先の書き込みレート制限、不十分な接続、または遅いバッチコミット。
時間がかかりすぎる、または頻繁に失敗するチェックポイント。
DDL イベント処理の失敗。
タスクのメモリ不足エラーまたは頻繁なフェールオーバー。

フルデータ初期化の完了後、リアルタイム増分が長時間追いつけない場合、これは通常、全量ステージ中に蓄積された増分データが多すぎるか、宛先の書き込み能力が不十分であることを意味します。ソースが増分データを生成するレートと、宛先の書き込みスループットの両方を確認してください。

遅延が減少し続けているかどうかを確認してください。減少しない場合は、読み取り側のチェックポイント、書き込み側の待機、および宛先のレート制限を個別に確認してください。

マージが生成されない、またはデータが不完全

増分マージノードを含むタスクの場合、リアルタイムタスクが実行中であるかどうかだけを確認しないでください。正常に実行されているリアルタイムタスクは、宛先スナップショットテーブルまたは宛先パーティションが生成されることを保証するものではありません。次の項目を順番に確認してください：

増分マージのスケジュールされたインスタンスが生成され、実行され、成功したかどうかを確認します。
増分マージインスタンスのアップストリーム依存関係が完了しているかどうかを確認します。
リアルタイム増分が、増分マージインスタンスが必要とする時間範囲に追いついていることを確認します。
データタイムスタンプ、宛先パーティション、および SQL 実行時間を確認します。
最近、再実行またはデータバックフィルが実行された場合は、それが同じパーティションを処理したかどうかを確認します。

スケジュールされたインスタンス、宛先パーティションの出力、およびダウンストリームの消費を一緒に確認してください。

ソースのイベント時刻またはバイナリログの順序が乱れている場合、スケジュールされた時刻によってトリガーされる増分マージインスタンスは、遅延した一部の増分イベントが到着する前に実行される可能性があります。増分マージのスケジューリングには、たとえば 30 分の遅延など、安全バッファを設けて、ソースの最大順序乱れまたは遅延ウィンドウをカバーするようにしてください。

チューニングの推奨事項

全量ステージとリアルタイムステージでは、チューニングの目的が異なります。全量ステージは、履歴データの効率的な初期化を目指します。リアルタイムステージは、継続的な安定性と低レイテンシーを目指します。増分マージステージは、パーティション出力の適時性とデータ整合性に焦点を当てます。

チューニング項目	適用ステージ	推奨事項
全量並列度	フルデータ初期化	ソースの接続容量と宛先の書き込み能力に基づいて、並列度を徐々に上げてください。
ソースの最大接続数	フルデータ初期化	接続数が少なすぎると読み取り速度が制限され、多すぎるとソースデータベースの安定性に影響を与える可能性があります。接続を徐々に増やし、ソースデータベースの接続プール使用率を監視してください。
バッチリソース仕様またはコンピューティングユニット	フルデータ初期化	CPU、メモリ、またはネットワークがボトルネックになった場合に、リソース仕様またはコンピューティングユニットを増やします。ソースまたは宛先がレート制限されている場合、効果は限定的です。
リアルタイムリソース仕様またはコンピューティングユニット	リアルタイム増分	チェックポイントの遅延が 5 分を超える場合は、コンピューティングユニットを 1 または 2 増やすことを検討してください。さらに調整を行う前に、フェールオーバーの頻度、チェックポイントの状態、およびガベージコレクションを監視してください。
チェックポイントまたはフラッシュ間隔	リアルタイム増分	間隔を少し長くすると、頻繁なコミットは減りますが、新しいデータが宛先で見えるようになるまでの遅延が増加します。チェックポイントの遅延が大きい場合は、チェックポイント間隔が短すぎないか確認してください。
増分マージのスケジューリング時間	増分マージ	ソースの増分遅延と順序が乱れたイベントのためにバッファを設け、早すぎるマージを避けてください。30 分のバッファは、最も一般的な遅延シナリオをカバーします。

アラートとメトリクス

少なくともタスクのステータス、ビジネス遅延、およびフェールオーバーを監視してください。チャネルの能力とタスクの設定に基づいて、リソース使用率、書き込み例外、DDL 通知、メッセージバックログ、およびダーティデータのアラートも追加してください。スケジュールされた出力またはマージノードで設定されたタスクの場合、スケジュールされたインスタンスの失敗と宛先パーティションの出力も監視してください。

次のアラートメトリクスが利用可能です：

メトリクス	メトリクスID	説明
ビジネス遅延	`DELAY`	ソースデータの変更から宛先への書き込み完了までの時間差
ダーティデータ	`DIRTY_RECORD_COUNT`	データ品質の問題により検証または書き込みに失敗したレコードの数
フェールオーバー	`FAILOVER_COUNT`	タスクのエラーまたはリソースの障害によってトリガーされたフェールオーバーイベントの数
メッセージバックログ	`OFFSET_DELAY`	消費を待っている未処理のメッセージまたはログエントリの量
タスクステータス	`STATUS`	同期タスクの現在の実行ステータス
サポートされていないDDL	`UNSUPPORTED_DDL`	タスクが自動的に処理できない DDL 操作
DDL通知	`DDL_REPORT`	タスクが処理またはスキップした DDL イベントに関する通知
タスクリソース使用率	`RESOURCE_UTILIZATION`	タスクリソースの CPU、メモリ、およびネットワークの使用率

ステージ別の推奨メトリクス

各ステージで次のメトリクスに焦点を当ててください：

ステージ	注目するメトリクス
フルデータ初期化	残りのテーブル、処理済みテーブル、残りの分割、処理済み分割、および全量書き込み数
リアルタイム増分	チェックポイントの遅延、読み取り/書き込みスループット、DML および DDL 数、チェックポイント期間、およびフェールオーバー数
増分マージ	増分マージインスタンスのステータス、アップストリーム完了時間、データタイムスタンプ、宛先パーティション、および SQL 実行時間
リソース	CPU、メモリ、ガベージコレクション、ネットワーク、およびリソースグループの使用率

アラートへの対応

アラートがトリガーされた場合は、次のように対応してください：

アラート条件	推奨される対応
ビジネス遅延が 5 分を超える	チェックポイントの状態を確認し、ソースのログ保持期間を超えていないことを確認します。リアルタイム増分のスループットと宛先の書き込み能力を確認してください。
フェールオーバー数が増加する	各フェールオーバーの根本原因についてタスクのログを確認します。一般的な原因には、ソース接続の切断、宛先の書き込みエラー、およびメモリ不足状態が含まれます。
ダーティデータ数が増加する	ダーティデータのログを確認して、失敗しているフィールドまたは制約を特定します。ダーティデータがデータの欠落、フィールドの異常、または更新・削除の失敗を引き起こすかどうかを判断する前に、アラートのしきい値を上げないでください。
サポートされていない DDL アラート	DDL イベントタイプとタスクの DDL ポリシーを確認します。サポートされていない DDL 操作を無視しないでください。データ整合性への影響を確認し、必要に応じて手動でスキーマ変更を適用してください。
タスクのステータスが「失敗」に変わる	タスクの実行詳細ページで失敗したステージを確認し、「トラブルシューティング方法」のステージ別ガイダンスに従ってください。

よくある質問

次の表は、一般的な問題に対する簡単な回答をまとめたものです。ステージベースのトラブルシューティング方法については、「トラブルシューティング方法」をご参照ください。

問題	トラブルシューティングの焦点	推奨事項
テーブルを追加した後、後続の増分データのみが存在し、履歴データが存在しない	新しいテーブルが選択ルールに一致するかどうか。フルデータ初期化が有効になっているか、またはトリガーされたか。ソースのログ保持期間が全量ステージ中の変更をカバーしているか。	履歴データが必要な場合は、新しいテーブルがフルデータ初期化を完了したことを確認してください。初期化がサポートされていない、またはトリガーされなかった場合は、データバックフィルまたは別の全量同期パイプラインを通じてデータを補完します。
テーブルを追加した後、タスクは確認を求めるか、続行できない	タスクが以前に全量ステージを実行したことがあるか。新しいテーブルが存在するか。チェックポイントが生成されたか。タスクが全量ステージとリアルタイムステージが分離されていないモードで実行されているか。	タスクが安定して実行され、チェックポイントが生成されるまで待ってから、新しいテーブルを送信してください。チェックポイント保護がない状態で同期範囲を拡大しないでください。
フルデータ初期化がスタックする、または開始しない	スキーマ移行が完了しているかどうか	「フルデータ初期化の遅延またはスタック」をご参照ください。
フルデータ初期化が遅い	—	「フルデータ初期化の遅延またはスタック」をご参照ください。
全量ステージは完了したが、リアルタイム増分が追いつけない	—	「リアルタイム増分のレイテンシー」をご参照ください。
テーブルを削除した後、またはソーステーブルをドロップした後のデータ不整合	タスクのルールが削除されたテーブルにまだ一致するかどうか。DDL ポリシーが DROP TABLE をどのように処理するか。宛先およびダウンストリームシステムがまだそのテーブルに依存しているかどうか。	テーブルを削除する前に、ビジネスがそのテーブルに依存しなくなったことを確認してください。ソーステーブルをドロップしても、宛先は自動的にクリーンアップされません。ビジネス要件に基づいて、既存の宛先データを別途処理してください。
テーブルマッピングのバッチ更新がタイムアウトする	テーブルの数、フィールドの数、正規表現のマッチング範囲、および宛先メタデータの読み取り時間	更新範囲を絞り、テーブルマッピングをバッチで処理してください。大規模なバッチ更新の後、結果をサンプリングして、追加されたテーブル、削除されたテーブル、およびフィールドマッピングを確認します。
スケジュールされた出力または増分マージが生成されない、またはデータが不完全	—	「マージが生成されない、またはデータが不完全」をご参照ください。
データバックフィルまたは再実行後の重複データ、上書き、またはパーティションの競合	書き込みモード、既存の宛先データ、および同じパーティションに対してスケジュールされた出力または増分マージインスタンスが実行されているかどうか。	再実行またはデータバックフィルの前に、競合するインスタンスを一時停止またはずらして実行します。上書き、追加、およびクリーンアップの戦略を定義してから、リカバリを実行してください。
DDL 操作後のタスクの失敗またはレイテンシーの増加	現在の DDL タイプ、宛先のサポート、タスクの DDL ポリシー、および宛先の権限とフィールドのマッピング。	DDL イベントと宛先スキーマの変更結果を確認してください。サポートされていない DDL 操作を無視しないでください。まず、データ整合性への影響を判断してください。
UPDATE または DELETE の結果が期待どおりではない	ソースの主キー、宛先の主キーまたはユニークキー、主キーのマッピング、書き込みモード、およびダーティデータのログ。	まず、サンプルレコード、ソースイベント、タスクのマッピング、および宛先の結果を比較してください。主キーが行を特定できない場合、更新および削除が正しい宛先行に適用されない可能性があります。
MaxCompute または他の宛先への書き込みが遅い	パーティションフィールドの粒度、単一のチェックポイントに関与するパーティションの数、Tunnel またはコミットの期間、および宛先のレート制限。	まず、高カーディナリティフィールドでのパーティショニングによって引き起こされる書き込みの分散を減らし、次にリソース、バッチコミット、および宛先のクォータを調整します。
ダーティデータアラートの増加	フィールドタイプ、長さ、エンコーディング、主キー、非 NULL 制約、および宛先の書き込み制限。	単にしきい値を上げるだけでなく、まずダーティデータがデータの欠落、フィールドの異常、または更新・削除の失敗を引き起こすかどうかを判断してください。
ソースのログ保持期間が不十分	タスクの停止期間、ソースのバイナリログまたは WAL の保持ポリシー、および全量ステージと増分ステージ間のハンドオフ時間。	増分データをリプレイできない場合は、タスクを再度初期化するか、ビジネススコープごとにデータをバックフィルします。リカバリの前に、ソースのログがカバーする期間を確認してください。