リアルタイム同期ノードの監視とトラブルシューティング - DataWorks - Alibaba Cloud - DataWorks

DataStudio でタスクを開発して本番環境にデプロイした後、オペレーションセンターに移動してリアルタイム同期タスクを実行できます。オペレーションセンターでは、タスクステータスの監視やランタイムメトリクスの表示なども行うことができます。本ガイドでは、リアルタイム同期タスクの一般的な運用保守 (O&M) 手順について説明します。

前提条件

リアルタイム同期タスクが作成され、公開済みである必要があります。詳細については、「単一テーブルのリアルタイム同期タスクの設定」をご参照ください。

DataWorks Data Integration では、単一テーブルのリアルタイム同期タスクは、単一のソーステーブル、トピック、 Logstore 、または同等の粒度のデータオブジェクトからデスティネーションにデータを同期するパイプラインです。日常の運用では、タスクの異常を迅速に特定し、パフォーマンスパラメータを調整し、データ整合性を確保する必要があります。このトピックでは、前提条件、各ステージの運用保守の重点、パフォーマンスチューニング方法、代表的なトラブルシューティングシナリオについて説明することで、包括的な運用保守とチューニングのフレームワークを確立できるよう支援します。

前提条件

次の前提条件を満たしていることを確認してください。

カテゴリ	要件	検証方法
ソース権限	ソースからメタデータを読み取る権限があり、ソーステーブルの完全なフィールド情報を取得できることを確認してください。	設定済みのアカウントを使用してソースにアクセスし、テーブル構造とフィールド情報を読み取れることを確認してください。
宛先権限	宛先にテーブルを作成するか、データを書き込む権限があることを確認してください。	設定済みのアカウントを使用して、宛先にテーブルを作成するか、データを書き込んでテストを実行してください。
リソースグループ	リソースグループの仕様が、完全初期化フェーズにおけるコンピューティングとネットワークの要件を満たしている必要があります。	リソースグループが利用可能で、その仕様が同期タスクの要件を満たしていることを確認してください。
ネットワーク接続	ソースからチャネル、そして宛先へのネットワーク接続を確保してください。	ネットワークテストツールを使用して、すべてのノード間の接続を確認してください。

単一テーブルのリアルタイム同期：運用保守とチューニング

単一テーブルのリアルタイム同期を個別に説明するのは、一部のソース、ターゲット、またはチャネルの機能がデータベース全体の同期に適していなかったり、特定のデータオブジェクトのみを同期する必要があったりするためです。ソースとチャネルの機能が対応している場合は、データベース全体のリアルタイムタスクを使用し、テーブルを 1 つだけ選択して単一テーブルの同期を実行することを推奨します。この方法では、スキーマ移行、完全初期化、増分データの取り込み、および将来のテーブルのスケーリングにおいて、データベース全体の同期機能を活用できます。使用するタスクタイプに関わらず、本トピックでは単一テーブルのリアルタイムパイプラインの運用保守のみに焦点を当て、複数テーブルのバッチ管理、データベース全体のオフライン同期、またはデータベース全体のフルおよび増分のリアルタイム同期については説明しません。

適用可能なチャネルと境界

まず、タスクの形式、チャネルの機能、主要なトラブルシューティング領域に基づいてタスクを評価します。

項目	範囲	対象外 / 重点事項
タスクの形式	単一のテーブル、トピック、Logstore、または同様の粒度のデータストリーム	データベース全体のテーブル検出、テーブルの一括追加、または廃止は処理しません。
代表的なチャネル	Kafka / DataHub / SLS / LogHub → Hologres / MaxCompute / Kafka / Doris / StarRocks / Lindorm / DLF / OSS	ソースがデータベース全体の同期をサポートするデータベースの場合、単一テーブルであってもそのタスクタイプを使用することを推奨します。
トラブルシューティングの重点	オフセット、ログの保持、プライマリキー、DDL、メッセージバックログ、メッセージ形式、フィールドの解析、ダーティデータ、宛先のスロットリング	データベース全体の同期におけるテーブルの追加または削除の手法は適用しないでください。

Hologres は、単一テーブルのリアルタイム同期のソースとしても機能します。Hologres から Hologres、Hologres から MaxCompute、Hologres から Doris などのテーブルレベルのリアルタイムパイプラインは、単一テーブルタスクとしてトラブルシューティングしてください。ソーステーブルの権限、Binlog / 変更データキャプチャ (CDC)、プライマリキー、フィールドマッピング、宛先の書き込みセマンティクスに焦点を当ててください。

コアとなる境界：単一テーブルのリアルタイム同期は、データベース全体の同期の簡略版ではありません。ソースの権限、メッセージモデル、データ形式、または宛先の書き込みセマンティクスがデータベース全体の同期と互換性がないシナリオに適しています。Hologres がソースの場合は、テーブルレベルのリアルタイムパイプラインとしてトラブルシューティングしてください。

タスクフェーズ

フェーズ	説明	運用保守の重点
スキーマ準備	ソースのフィールド、プライマリキー、パーティション、またはメッセージ形式を読み取り、宛先のスキーマを作成または確認します。	ソースのメタデータ権限、宛先のテーブル作成権限または書き込み権限、フィールドタイプ、プライマリキー、パーティション、マッピングルール。
完全初期化	既存の履歴データを宛先に書き込みます。このフェーズが含まれるかどうかは、タスクの設定とチャネルの機能によって決まります。	分割キー、完全初期化の並列度、ソース接続数、リソース仕様、宛先の書き込みキャパシティ。
増分同期	Binlog、WAL、ログ、メッセージ、または変更イベントを継続的に読み取り、宛先に書き込みます。	オフセット、ビジネスレイテンシー、スループット、チェックポイント、フェールオーバー、DDL、ダーティデータ、宛先の書き込みキャパシティ。

単一テーブルのリアルタイムタスクにおけるリスクは、通常 2 つのカテゴリに分類されます。1 つ目は、オフセットとログ保持に関連します。タスクが長時間停止すると、元のオフセットから再開できなくなる可能性があります。2 つ目は、宛先の書き込みセマンティクスに関連します。プライマリキー、書き込みモード、パーティション、またはフィールドマッピングに一貫性がない場合、UPDATE、DELETE、またはべき等な書き込みが期待どおりに動作しない可能性があります。

運用保守オペレーション

タスクの開始と停止

タスクを開始した後、まずスキーマの準備が完了したことを確認します。次に、完全初期化が開始され、進行しているかどうかを監視します。最後に、増分同期が継続的にデータの読み書きを行っていることを確認します。メッセージソースのタスクについては、消費オフセットとメッセージバックログも監視します。データベースログベースのタスクについては、Binlog、WAL、またはその他のログの保持期間に注意してください。
タスクを停止する前に、ソースログまたはメッセージの保持期間がダウンタイムの期間をカバーできることを確認してください。ダウンタイムが保持期間を超えた場合、タスクは元のオフセットから再開できない可能性があります。この場合、オフセットのリセット、過去のバックログのスキップ、またはタスクの再初期化が必要になることがよくあります。これらのアクションを実行する前に、重複書き込みとデータ損失のリスクを評価してください。

設定変更

単一テーブルのリアルタイムタスクの一般的な変更には、フィールドマッピング、プライマリキー、書き込みモード、パーティショニングルール、並列度、リソース、オフセット、およびダーティデータポリシーの調整が含まれます。

変更タイプ	リスク	推奨事項
フィールドマッピングの変更	フィールドの欠落、型変換の失敗、またはデスティネーションへの書き込みエラーを引き起こす可能性があります。	送信する前に、ソースフィールド、デスティネーションフィールド、フィールドタイプ、およびデフォルト値を確認してください。
プライマリキーまたは書き込みモードの変更	UPDATE、DELETE、べき等な書き込み、および重複排除の結果に影響を与える可能性があります。	まず、デスティネーションが対応する書き込みセマンティクスをサポートしているかどうかを確認してください。次に、履歴データを再同期する必要があるかどうかを評価してください。
パーティショニングルールの変更	データが新しいパーティションや不正なパーティションに書き込まれたり、多数の小さなパーティションが生成されたりする可能性があります。	送信する前に、パーティションフィールドの粒度、パーティション式、およびデスティネーションのパーティション制限を確認してください。
並列度とリソースの調整	ソース、デスティネーション、またはリソースグループの負荷を増加させる可能性があります。	段階的に調整を行ってください。変更のたびに、レイテンシー、スループット、チェックポイント、およびフェールオーバーを監視してください。
オフセットのリセット	重複消費やデータのスキップを引き起こす可能性があります。	まず、業務で許容できる復旧ポイントを決定してください。次に、リセット前後の時間とオフセットを記録してください。
ダーティデータポリシーの調整	エラーを引き起こすレコードを破棄しながら、タスクの実行を継続させてしまう可能性があります。	問題を回避するために単にしきい値を増やすことはしないでください。まず、ダーティデータが業務結果に影響を与えるかどうかを判断してください。

アラート設定

単一テーブルのリアルタイムタスクでは、少なくともタスクステータス、業務レイテンシー、およびフェールオーバーイベントを監視してください。チャネルの機能とタスクの設定に応じて、リソース使用率、書き込みエラー、DDL 通知、およびメッセージバックログサイズに対するアラートを追加することもできます。

メッセージソースのタスクについては、ソースのトピック、シャード、Logstore、またはコンシューマーグループのバックログも監視する必要があります。データベースログベースのタスクについては、Binlog、WAL、アーカイブログ、またはレプリケーションスロットの保持を監視する必要があります。タスクの失敗に対してのみアラートを設定するだけでは不十分です。タスクが実行中であっても、継続的に増加するレイテンシー、書き込み速度の低下、または進まないオフセットなどの問題を検出できないためです。

トラブルシューティング

データが出力されない

タスクが実行中と表示されているにもかかわらず、送信先に新しいデータが表示されない場合は、まずソースで新しいデータが生成されているかどうかを確認してください。次に、リーダーがデータを消費していないのか、パイプラインがデータを処理できていないのか、またはライターがデータをコミットできていないのかを切り分けます。

次の手順でトラブルシューティングを行います。

ソーステーブル、トピック、Logstore、またはログのオフセットに新しいデータが存在するかどうかを確認します。
タスクがフルロード、増分同期、またはフェイルオーバーの状態にあるかどうかを確認します。
読み取りメトリクス、書き込みメトリクス、ビジネスレイテンシー、およびチェックポイントが正常に進んでいるかどうかを確認します。
送信先テーブル、送信先パーティション、プライマリキー、および書き込みモードが設定と一致しているかどうかを確認します。
ダーティデータ、フィールドマッピングの失敗、または送信先権限の問題がないかどうかを確認します。

ランタイムの詳細にある DML/DDL 統計で短時間、データが表示されない一方で、ログと送信先への書き込みが正常に見える場合は、メトリクス収集の遅延またはエラーの可能性も確認してください。これにより、モニタリング表示の問題を同期中断と誤診することを防げます。

フルロードの低速化または失敗

フルロードが遅い場合は、まずボトルネックがソースの読み取り、ネットワーク、リソースグループ、送信先の書き込み、またはデータ分割の偏りのいずれにあるかを特定します。

症状	考えられる原因	推奨される対処
フルロードタスクが長時間開始されない。	リソースのキューイング、ソースまたは送信先の接続問題、または送信先テーブルの作成失敗。	リソースグループのステータス、データソースの接続性、および送信先権限を確認します。
フルロードの読み取りが遅い。	不適切な分割キー、インデックスを使用していないソース SQL クエリ、ソースのロードが高い、または接続が不足している。	分布がより均一で、インデックスを持つ分割キーを選択します。並列度を適切に調整します。ソースのロードが高い場合は、レート制限を適用するか、オフピーク時間帯にタスクを実行します。
フルロードの書き込みが遅い。	スロットリング、パーティション数が多すぎる、またはバッチコミットのレイテンシーが高い。	送信先の書き込みキャパシティ、パーティション数、バッチ書き込みパラメータ、およびリソース仕様を確認します。
フルロードフェーズが失敗する。	フィールド型の非互換、プライマリキーの競合、送信先の制約、またはダーティデータのしきい値超過。	まず、失敗しているフィールドと送信先エラーを特定します。次に、マッピングを調整する、データをクレンジングする、または送信先スキーマを変更します。

フルロードフェーズでは、平均スループットだけに頼らないでください。少数の大きな分割、ワイドテーブル、大きなフィールド、またはホットパーティションによって、全体の完了時間が左右される場合があります。

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

リアルタイムレイテンシーが増加した場合は、まずレイテンシーが継続的に減少しているかどうかを確認してください。タスクがフルロードを完了した直後であれば、リアルタイムパイプラインがフルロード中に蓄積されたデータに追いついている可能性があります。レイテンシーが増加し続ける場合は、ボトルネックがリーダー、ライター、リソース、ネットワーク、または外部システムのいずれにあるかを特定します。

次の順序でトラブルシューティングを行います。

タスクのランタイムの詳細でウィンドウ待機時間を確認し、ボトルネックが主にリーダー側かライター側かを判断します。
レイテンシーが高かった期間のタスクログを確認します。Error、Exception、OutOfMemory などのキーワードを検索します。
フェイルオーバー記録を確認し、フェイルオーバーイベントの頻発、メモリ不足 (OOM) エラー、または外部サービス例外がないかを確認します。
実行中のメトリクスとイベントを確認し、スループット、バックプレッシャー、チェックポイント、JVM メモリ、GC、DDL イベント、およびダーティデータに重点を置きます。
ソース、送信先、リソース、並列度、およびネットワークを確認して、さらに切り分けます。ボトルネックを特定するまでは、並列度やリソースを追加しないでください。

ウィンドウ待機時間は、一次診断として使用できます。

診断結果	考えられる原因	次の手順
リーダー待機時間が高い	ソースの読み取りが遅い、パーティションまたはシャードの偏り、ソースのスロットリング、変更量の急増、またはログバックログ。	ソースのモニタリング、パーティションまたはシャードの分布、バイナリログ/先行書き込みログ (WAL)/メッセージバックログ、およびリーダーのデータ量の順に確認します。
ライター待機時間が高い	送信先の書き込みが遅い、送信先のスロットリング、動的パーティションが多すぎる、バッチコミットが遅い、またはネットワーク帯域幅が不足している。	送信先のリソース、書き込み QPS、シンクのログ、バッチコミットのレイテンシー、および動的パーティションの順に確認します。
リーダー側とライター側の両方で待機時間が高い	タスクのリソース不足、バックプレッシャー、チェックポイントの遅延、フェイルオーバーの頻発、または外部システムのジッター。	フェイルオーバー記録、JVM/GC、チェックポイント、リソースグループ仕様、およびタスクの並列度の順に確認します。

ボトルネックを特定した後は、症状に応じてさらに切り分けます。

症状	考えられる原因	推奨される対処
レイテンシーが増加し続ける。	ソースの生成レートが消費レートを上回っている、ネットワーク帯域幅が不足している、または送信先の書き込みが遅い。	ソースの生成レート、読み取りレート、書き込みレート、および送信先のスロットリングをそれぞれ確認します。
リーダー待機時間またはバックプレッシャーが大きい。	大規模トランザクション、ログバックログ、メッセージパーティションのホットスポット、またはソースのスロットリング。	ソース書き込みのスパイク、ログの増加、およびパーティションまたはシャードの分布を確認します。
ライター待機時間が高い。	送信先の書き込みが遅い、バッチコミットが小さすぎる、接続が不足している、またはパーティション数が多すぎる。	送信先のリソースと書き込み制限を優先して確認し、その後にバッチ、フラッシュ、コミット、または接続プールのパラメータを調整します。
チェックポイントが遅い、または失敗する。	ライターのコミットが遅い、状態サイズが大きい、外部サービスのジッター、またはリソース不足。	チェックポイントの所要時間、失敗回数、状態サイズ、およびログを使用して原因を特定します。
フェイルオーバーが頻発する。	メモリ不足、外部サービス例外、フィールドマッピングの失敗、または DDL 処理エラー。	フェイルオーバーの前後で、例外スタック、ダーティデータ、および DDL イベントを確認します。
ログに `OutOfMemory` が表示される。	タスクのメモリ不足、または単一の並列インスタンスに処理負荷が集中している。	CU またはメモリを適度に増やし、JVM、GC、チェックポイント、およびフェイルオーバーのパフォーマンスが改善するかどうかを確認します。

Kafka、DataHub、LogHub などのメッセージソースでは、パーティション数またはシャード数に重点を置きます。通常、1 つのパーティションまたはシャードは 1 つの並列インスタンスでしか消費できません。データが少数のパーティションに集中している場合、総並列度を単純に増やしても効果がないことがあります。異なるリーダースレッドの累積バイト数とソースのモニタリングデータを組み合わせて、ホットパーティションまたはホットシャードがないかを確認します。
MySQL などのデータベースログベースのソースでは、大規模トランザクション、DML 量の増加、DDL の頻発、およびバイナリログの増加率に重点を置きます。同期速度が遅い一方でレイテンシーが増加し続ける場合は、ソース監査ログ、CPU、I/O、接続数、およびバイナリログの増加を確認し、ソースデータベースへのロードや、未同期テーブルが原因で大量のバイナリログが発生していないかを確認します。
MaxCompute に書き込む場合、ログにエラー uploader map size has reached uploaderMapMaximumSize が表示される場合、これは通常、単一のフラッシュ間隔内に動的パーティション値が過剰に生成されていることを示しています。パーティションの粒度または動的パーティションフィールドの調整を優先してください。秒単位のタイムスタンプ、注文 ID、ユーザー ID などの高カーディナリティフィールドをパーティション値として使用しないでください。その後、並列度またはリソースを増やすかどうかを評価します。

DDL 処理の問題

タスクが失敗する、レイテンシーが増加する、または DDL 操作後に送信先スキーマの不整合が発生した場合は、まず現在のチャネルが該当の DDL タイプをサポートしているかどうか、およびタスクがその DDL に対してどの処理戦略を採用しているかを確認してください。

確認すべき主な項目：

列の追加、列の削除、型変換、リネーム、テーブルの作成、テーブルの削除、インデックスの変更など、ソースで発生した DDL 操作。
送信先が同じ DDL、または同等のスキーマ変更をサポートしているかどうか。
タスクの戦略が、DDL を適用する、無視する、アラートを出す、または停止するのいずれであるか。
送信先アカウントにテーブルを変更する権限があるかどうか。
DDL 後もフィールドマッピング、プライマリキー、およびパーティションの整合性が保たれているかどうか。

サポートされていない DDL を単純に無視しないでください。DDL を無視するとタスクを継続して実行できる場合がありますが、その後の DML 書き込みが、フィールド不一致、プライマリキーの変更、または送信先スキーマの不整合によって失敗する可能性があります。

UPDATE または DELETE の問題

UPDATE または DELETE 操作後に送信先のデータが想定どおりにならない場合は、まず送信先にレコードを特定できるプライマリキーまたは一意キーがあるかどうかを確認し、ソースと送信先のプライマリキーのマッピングが一致していることを確認してください。

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

送信先テーブルにプライマリキーまたは一意キーがなく、レコード単位の更新または削除ができない。
ソースのプライマリキーと送信先のプライマリキーが一致していない。
プライマリキーフィールドが変換されている、リネームされている、または NULL として書き込まれている。
送信先の書き込みモードが更新または削除をサポートしていない。
タスクが DELETE 操作を無視するように設定されている、または特別な書き込みポリシーが設定されている。
書き込み失敗がダーティデータとして記録されているが、タスクは継続して実行されている。

この問題を解決するには、まず少数のサンプルレコードを使用して、ソースイベント、タスクのマッピング、および送信先の結果を確認します。次に、プライマリキーを調整する、書き込みモードを変更する、または送信先テーブルを再初期化するかどうかを判断します。

ダーティデータの増加

ダーティデータが増加した場合は、ダーティデータのしきい値を単純に引き上げないでください。まず、ダーティデータによって、送信先でデータ欠落、NULL フィールド、フィールドの切り捨て、プライマリキーの競合、またはパーティションエラーが発生しないかを確認してください。

確認すべき主な項目：

フィールド型、長さ、精度、および NOT NULL 制約が一致しているかどうか。
送信先のプライマリキー、一意キー、またはパーティションフィールドが要件を満たしているかどうか。
ソース側で、過大な文字列、無効なエンコーディング、特殊な JSON、解析できないタイムスタンプ、またはサポートされていないデータ型が混入していないかどうか。
送信先でスロットリング、書き込み失敗、またはサーバー側フィルタリングが発生していないかどうか。

これらのエラーレコードを破棄することが業務上許容される場合に限り、ダーティデータのしきい値を一時的に増やすことを検討してください。後でソースデータまたは送信先スキーマを修正する計画を立ててください。

チューニング

チューニング項目	ユースケース	推奨事項
リソース仕様 / CU (コンピューティングユニット)	CPU、メモリ、ネットワーク、またはリソースグループの使用率が高いです。	リソースを段階的に増やし、レイテンシー、フェイルオーバー、およびチェックポイントのパフォーマンスが改善されるか観察してください。
リアルタイム並列度	ソースとデスティネーションの両方が並列度の増加に対応できます。	並列度を増やす前に、まず単一パーティション、単一シャード、または単一テーブルのホットスポットがないことを確認してください。
全量初期化の並列度と分割キー	全量初期化が遅いです。	均等に分散され、インデックスが付けられており、サポートされているデータ型を持つ分割キーを選択してください。
チェックポイント / フラッシュ間隔	ライターのコミットが頻繁であるか、コミットのオーバーヘッドが高いです。	少しずつ調整し、スループット、データ可視性レイテンシー、および障害率を観察してください。一度に大きく調整しないでください。
バッチ書き込みパラメータ	ライターの待機時間が高いです。	デスティネーションの制限に基づいて、バッチ、フラッシュ、コミット、およびコネクションプールのパラメータを調整してください。
パーティション粒度	デスティネーションのパーティションが多すぎる、またはコミットのレイテンシーが高いです。	秒レベルのタイムスタンプ、注文 ID、またはユーザー ID などの高カーディナリティフィールドを動的パーティショニングに使用しないでください。
メッセージソースパーティション	Kafka、DataHub、または LogHub などのソースでレイテンシーが高いです。	ホットパーティションと消費並列度の制限を確認してください。必要に応じて、ソースのパーティション設計を調整してください。
トランスフォーマーロジック	複雑な JSON 解析、フィールド処理、または多数のフィルタリングルールが存在します。	不要な複雑な変換を減らすか、リソースを追加して CPU とレイテンシーの変化を観察してください。

チェックポイントまたはフラッシュ間隔を調整する場合は、たとえば 5 秒から 10 秒または 30 秒へと、少しずつ増やしてください。その後、書き込みスループット、チェックポイント期間、エンドツーエンドレイテンシー、およびデスティネーションの負荷を 10 ～ 30 分間監視してください。レイテンシーが減少してもデータの可視性が業務要件を満たさない場合は、より短い間隔に戻す必要があります。

説明

チューニング後は、タスクを安定した期間監視してください。再起動後の短期的なスループットは、特にデータバックログ、デスティネーションのスロットリング、またはチェックポイントのジッターがある場合、長期的なパフォーマンスを反映しているとは限りません。

よくある質問

質問	確認すべき主な項目	推奨される対処
タスクは実行中ですが、デスティネーションにデータが表示されません。	ソースに新しいデータがありますか。オフセットは進んでいますか。デスティネーションに書き込まれていますか。メトリクス収集は正常ですか。	ソースデータ、タスクログ、DML メトリクス、およびデスティネーションの結果を同時に確認してください。診断に単一のメトリクスやページだけを使用しないでください。
停止後に元のオフセットから再開できません。	Binlog、WAL、ログ、またはメッセージの保持期間を超過していませんか。	オフセットをリセットする、または再初期化する前に、重複消費、データスキップ、およびダウンストリームシステムへの影響を評価してください。
Kafka などのメッセージソースのレイテンシーが高いように見えます。	メッセージタイムスタンプは過去のものですか。消費オフセットは遅れていますか。ホットパーティションはありますか。	過去のメッセージタイムスタンプによって報告上レイテンシーが高く見えているのか、実際に消費能力が不足しているのかを切り分けてください。
DataHub の書き込みレイテンシーまたは消費レイテンシーが高いです。	トラフィック制限がトリガーされていませんか。バッチサイズが小さすぎませんか。バックプレッシャーは発生していますか。	ソースのスロットリング、タスクのバックプレッシャー、およびライタースループットに基づいて、パラメータまたはクォータを調整してください。
MaxCompute などのデスティネーションへの書き込みが遅いです。	パーティション数、トンネルセッション、チェックポイントのコミット時間。	単一のチェックポイントに含まれるパーティション数を減らすことを優先し、その後にバッチコミットパラメータとリソースを調整してください。
Hologres の書き込みレイテンシーが高いです。	デスティネーションテーブルのプライマリキー、セグメントキー、テーブルタイプ、書き込みモード、および Holo インスタンス負荷。	まず、デスティネーションテーブルがリアルタイム書き込み向けに設計されていることを確認し、その後にタスクリソースとバッチ書き込みパラメータを調整してください。
UPDATE または DELETE がデスティネーションに反映されません。	デスティネーションのプライマリキー、書き込みモード、フィールドマッピング、およびダーティデータログ。	サンプルレコードを使用して、ソースイベント、デスティネーションのプライマリキー、および実際の書き込み結果を確認することを優先してください。
DDL 操作後にタスクが失敗します。	DDL タイプ、デスティネーションの対応状況、DDL 戦略、およびデスティネーション権限。	DDL イベントと失敗ログを確認してください。タスクを再開する前に、デスティネーションのテーブルスキーマを手動で調整する必要があるかどうかを判断してください。

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

オフセットのリセット、タスクの再起動、プライマリキーまたは書き込みモードの変更、パラメーターの大幅な調整、完全な初期化の再実行、宛先テーブルのクリアなどの高リスク操作を実行する前に、次の項目を確認してください。

ソースログまたはメッセージの保持期間は十分ですか。
現在のオフセット、ビジネスタイムスタンプ、および宛先の最新データを記録しましたか。
この操作により、宛先で重複書き込み、データスキップ、またはデータの上書きが発生しますか。
ダウンストリームシステムはすでに宛先テーブルのデータを消費していますか。
未処理の DDL イベント、ダーティデータ、またはフェールオーバーイベントの頻発はありませんか。
アラートの対象に、タスクステータス、ビジネスレイテンシー、フェールオーバーイベント、書き込みエラー、およびダーティデータは含まれていますか。