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

開始と停止

• タスクを開始したら、まずスキーマの準備が完了したことを確認し、次に完全初期化が開始され、進行しているかを確認し、最後に増分同期が継続的にデータを読み書きしていることを確認します。メッセージソースのタスクでは、コンシューマーオフセットとメッセージバックログも監視します。データベースログベースのタスクでは、Binlog、WAL、またはログ保持期間を監視します。

• タスクを停止する前に、ソースログまたはメッセージのログ保持期間がダウンタイムをカバーできるかを確認します。ダウンタイムが保持期間を超える場合、タスクは元のオフセットから再開できない可能性があります。この場合は通常、オフセットのリセット、履歴バックログのスキップ、または再初期化が必要です。これらの操作を行う前に、重複書き込みとデータ損失のリスクを評価してください。

設定の変更

単一テーブルのリアルタイムタスクにおける一般的な変更には、列マッピング、主キー、書き込みモード、パーティションルール、同時実行数、リソース、オフセット、ダーティデータ処理ポリシーの調整などがあります。

アラート設定

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

メッセージソースのタスクでは、ソーストピック、シャード、Logstore、またはコンシューマーグループのバックログも監視してください。データベースログベースのタスクでは、Binlog、WAL、アーカイブログ、またはレプリケーションスロットの保持状況を監視してください。タスク失敗のアラートのみを設定しても、タスクは実行中であるにもかかわらずレイテンシーが継続的に増加する、書き込みが徐々に遅くなる、またはオフセットが長時間進まないといった問題を検知できません。

タスクのデータ出力なし

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

トラブルシューティングの手順：

1. ソーステーブル、トピック、Logstore、またはログのオフセットに新しいデータがあるかを確認してください。

2. タスクが完全初期化、リアルタイム増分同期、またはフェールオーバーの状態であるかを確認してください。

3. 読み取りメトリクス、書き込みメトリクス、ビジネスレイテンシー、チェックポイントが正常に進行しているかを確認してください。

4. ターゲットテーブル、ターゲットパーティション、プライマリキー、書き込みモードが設定と一致しているかを確認してください。

5. ダーティデータ、カラムマッピングの失敗、またはターゲット権限の問題がないかを確認してください。

ランタイムの詳細にある DML/DDL 統計が短時間データなしを示していても、ログとターゲットへの書き込みが正常である場合は、メトリクス収集のレイテンシーや収集異常も確認してください。監視表示の問題を同期の中断と誤認しないようにしてください。

完全初期化の遅延または失敗

完全初期化が遅い場合は、まずボトルネックがソースの読み取り、ネットワーク、リソースグループ、ターゲットへの書き込み、またはデータ分割の偏りのどこにあるかを特定してください。

完全初期化フェーズでは、平均スループットだけを基準にしないでください。少数の大きなシャード、ワイドテーブル、大きなカラム、またはホットパーティションが、全体の完了時間を左右する場合があります。

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

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

次の順序でトラブルシューティングすることを推奨します：

1. タスクのランタイム詳細でウィンドウ待機時間を確認し、ボトルネックが主にリーダーとライターのどちらにあるかを判断してください。

2. レイテンシーが高い期間のタスクログを確認し、Error、Exception、OutOfMemory などのキーワードを検索してください。

3. フェールオーバーの記録を確認し、フェールオーバーの頻発、OutOfMemory、または外部サービス例外が発生していないかを確認してください。

4. ランタイムメトリクスとイベントを確認し、スループット、バックプレッシャー、チェックポイント、JVM メモリ、GC、DDL イベント、ダーティデータに重点を置いてください。

5. 次に、ソース、ターゲット、リソース、同時実行数、ネットワークを確認して原因を切り分けてください。ボトルネックを特定する前に、同時実行数やリソースを増やすことは推奨しません。

ウィンドウ待機時間は、一次指標として使用できます：

ボトルネックの箇所を特定したら、具体的な症状に応じて、さらに原因を切り分けてください：

• Kafka、DataHub、LogHub などのメッセージソースでは、パーティション数またはシャード数に注意してください。通常、単一のパーティションまたはシャードは 1 つの並行スレッドでしか消費できません。データが少数のパーティションに集中している場合、同時実行数全体を増やしても効果がないことがあります。ソースの監視と併せて各リーダースレッドの累積バイト数を確認し、パーティションまたはシャードのホットスポットがないかを判断してください。

• MySQL などのデータベースログベースのソースでは、大規模トランザクション、大量の DML、頻繁な DDL、Binlog の増加率に注意してください。同期速度が高くないにもかかわらずレイテンシーが増加し続ける場合は、ソースデータベースの監査ログ、CPU、I/O、接続数、Binlog の増加を確認し、ソースに負荷がかかっていないか、または未同期のデータベースやテーブルが大量の Binlog エントリを生成していないかを切り分けてください。

• MaxCompute に書き込む場合、ログに uploader map size has reached uploaderMapMaximumSize が出力されるときは、通常、単一のフラッシュ間隔内における動的パーティション値の数が多すぎることを示します。まずパーティションの粒度、または動的パーティションカラムを調整し、秒単位のタイムスタンプ、注文 ID、ユーザー ID などの高カーディナリティ列をパーティション値として使用しないようにしてください。そのうえで、同時実行数またはリソースの増加が必要かを評価してください。

DDL イベント処理エラー

DDL イベントの後に、タスクが失敗する、レイテンシーが増加する、またはターゲットスキーマの不整合が発生する場合は、まず現在のチャネルが該当の DDL タイプをサポートしているか、およびタスクの DDL 処理ポリシーが何であるかを確認してください。

トラブルシューティングの重点：

• ソースで発生した DDL 操作 (カラムの追加、カラムの削除、型の変更、リネーム、テーブルの作成、テーブルの削除、インデックスの変更など) を特定してください。

• ターゲットが同じ DDL、または同等のスキーマ変更をサポートしているかを確認してください。

• タスクのポリシーが、正常に処理、無視、アラート、停止のいずれに設定されているかを確認してください。

• ターゲットアカウントに ALTER TABLE 権限があるかを確認してください。

• DDL の前後で、カラムマッピング、プライマリキー、パーティションの一貫性が維持されているかを確認してください。

サポートされていない DDL 操作を直接無視することは推奨しません。DDL を無視するとタスクの実行を継続できる場合がありますが、その後の DML 書き込みが、カラムの不一致、プライマリキーの変更、またはターゲットスキーマの不整合により失敗し続ける可能性があります。

更新または削除で期待どおりの結果が得られない

更新または削除の操作後にターゲットデータが期待どおりにならない場合は、まずターゲットにレコードを特定できるプライマリキーまたは一意キーがあるか、およびソースとターゲットのプライマリキーのマッピングに一貫性があるかを確認してください。

主な原因は次のとおりです：

• ターゲットにプライマリキーまたは一意キーがないため、レコード単位で更新または削除できません。

• ソースのプライマリキーとターゲットのプライマリキーが一致していません。

• プライマリキーのカラムが変換されている、リネームされている、または NULL として書き込まれています。

• ターゲットの書き込みモードが更新または削除をサポートしていません。

• タスクが削除操作を無視するように設定されている、または特殊な書き込みポリシーを使用しています。

• 書き込み失敗がダーティデータとして記録されていますが、タスクは実行を継続しています。

切り分けでは、まず少数のサンプルレコードを使用して、ソースイベント、タスクのマッピング、ターゲットの結果を確認してください。そのうえで、プライマリキー、書き込みモードを調整するか、またはターゲットテーブルを再初期化するかを判断してください。

ダーティデータの増加

ダーティデータが増加する場合は、ダーティデータのしきい値を直接引き上げないでください。まず、ダーティデータがターゲット側でのデータ欠落、NULL カラム、カラムの切り捨て、プライマリキーの競合、またはパーティション異常の原因になっていないかを確認してください。

トラブルシューティングの重点：

• カラム型、長さ、精度、NOT NULL 制約が一致しているかを確認してください。

• ターゲットのプライマリキー、一意キー、またはパーティションカラムが要件を満たしているかを確認してください。

• ソース側で、過度に長い文字列、無効なエンコーディング、特殊な JSON、解析できないタイムスタンプ、またはサポートされていないデータ型が取り込まれていないかを確認してください。

• ターゲットでスロットリング、書き込み失敗、またはサーバー側フィルタリングが発生していないかを確認してください。

これらの異常レコードを破棄してもビジネス上問題ないことを確認できた場合に限り、ダーティデータのしきい値を一時的に引き上げることを検討してください。その後、ソースデータまたはターゲットスキーマを修正してください。

タスクの再起動またはデプロイにおける重複書き込み

• ターゲットテーブルにプライマリキーが定義されている場合、タスクを再起動またはデプロイしても重複データは発生しません。これは、再書き込みされたレコードがプライマリキーによって収束し、最終結果が一貫性を保つためです。

• ターゲットテーブルにプライマリキーが定義されていない場合、重複データが発生する可能性があります。再起動またはデプロイ後、保存されたオフセットから変更がリプレイされ再度書き込まれることで、重複レコードが生成される場合があるためです。

• 最も古いオフセットからタスクを開始する場合は、このリスクに特に注意してください。ソースで保持されているすべての過去の変更が再度消費され、プライマリキーのないターゲットテーブルには大量の重複が蓄積される可能性があるためです。開始する前に、下流システムがこれを許容できることを確認するか、重複排除とデータのクリーンアップを事前に計画してください。