単一テーブルのバッチ同期におけるデータ品質問題のトラブルシューティング方法 - DataWorks

仕組み

DataWorks の Data Integration は、並列処理とプラグインベースのアーキテクチャを使用して、効率的で安定したデータ同期を実現します。

並列実行モデル (ジョブとタスク)

データスループットを最大化するために、同期タスクは 2 段階の実行構造を使用します：

ジョブ：同期タスクの実行中のインスタンス。
タスク：ジョブの最小実行単位。ジョブは、1 つ以上のマシンで同時に実行できる複数のタスクに分割されます。

各タスクは、独立したデータシャードの処理を担当します。この並列処理メカニズムにより、データ同期全体の効率が大幅に向上します。

プラグインベースのデータフロー (Reader と Writer)

各タスク内では、データフローはインメモリバッファーによって接続された Reader プラグインと Writer プラグインによって構成されます：

Reader プラグイン：ソースデータストアに接続し、データを読み取り、内部バッファーにプッシュします。
Writer プラグイン：バッファーからデータを消費し、送信先データストアに書き込みます。

説明

Reader プラグインと Writer プラグインは、それぞれのデータソースのネイティブプロトコル、データ型、プライマリキーといった制約に厳密に従います。したがって、最終的な同期の動作とデータ整合性は、ソースシステムとターゲットシステムの実装に依存します。

Writer 側のデータ整合性のトラブルシューティング

Data Integration の Writer プラグインは、ソースから送信先へデータを書き込みます。送信先のデータソースタイプごとに、対応する Writer プラグインが存在します。Writer プラグインは、競合解決戦略を含む、設定された書き込みモードに基づいて、JDBC またはデータソースの SDK を使用して送信先にデータを送信します。

説明

送信先での実際の書き込み結果とデータ内容は、書き込みモードと送信先テーブルの制約に依存します。

データ同期タスクの完了後、レコード数やデータ内容などのデータ品質に問題が発生した場合は、以下の Writer 側でよくある問題を確認してください。

原因	説明	解決策
書き込みモードの不適切な設定	Writer プラグインは、選択された書き込みモードを使用してソースデータを送信先に書き込みます。ソースデータが送信先テーブルの制約と競合する場合、挿入の失敗 (ダーティデータ)、サイレントな破棄、またはレコードの置換が発生する可能性があります。	ユースケースに適した書き込みモードを選択してください。詳細については、「付録：リレーショナルデータベースの書き込みモード」をご参照ください。
ダーティデータのしきい値に到達	データ型の不一致やコンテンツのサイズ超過などの問題によって発生したダーティデータの量が、設定されたしきい値を超えると、タスクが失敗し、一部のデータが書き込まれなくなります。	ダーティデータの原因を特定し、問題を解決してください。または、ダーティデータを許容し、無視できるかどうかを判断してください。説明タスクでダーティデータが許容されない場合は、タスク設定 > [チャネル設定] でダーティデータのしきい値を変更できます。ダーティデータのしきい値の設定方法の詳細については、「コードレス UI 設定」をご参照ください。ダーティデータの定義については、「Data Integration」をご参照ください。
データクエリが早すぎる	同期タスクが完了する前にデータがクエリされます。Hive や MaxCompute (設定可能) などの一部のデータソースでは、タスクが終了するまでデータが部分的または完全に利用できない場合があります。	同期タスクインスタンスが正常に実行されたことを確認した後、必ず送信先テーブルのデータを検証してください。
ノード依存関係の欠落	下流の分析タスクと上流の同期タスクの間に明示的な有向非巡回グラフ (DAG) 依存関係が設定されていない場合、下流のタスクが早期に開始され、不完全なデータを読み取る可能性があります。	DataStudio で、上流タスクと下流タスクの間に明示的な親子ノード依存関係を設定してください。`max_pt` のような弱い依存関係の使用は避けてください。
複数の同期タスクが同じテーブルまたはパーティションに同時に書き込み、干渉を引き起こしている。	同期タスクの安全でない同時実行。 MaxCompute と Hologres の場合、2 つのタスクが同じパーティションに書き込み、書き込み前にパーティションを切り捨てるように設定されていると、2 番目のタスクが最初のタスクによって書き込まれたデータをクリアする可能性があります。リレーショナルデータベースの場合、Pre-SQL または Post-SQL ステートメントが設定されていると、2 番目のタスクからの SQL ステートメントが最初のタスクによって書き込まれたデータに干渉する可能性があります。	競合が同じノードの複数の定期実行インスタンスによって引き起こされる場合は、自己依存を設定して、次のインスタンスが前のインスタンスの完了後にのみ開始されるようにすることができます。同じ送信先に同時に書き込むタスクの設計は避けてください。
タスクがべき等になるように設定されていない	タスクがべき等ではありません。つまり、複数回実行すると異なる結果が生成されます。タスクを再実行すると、重複データが挿入されたり、データが誤って上書きされたりする可能性があります。	1. 可能な限り、タスクがべき等になるように設計してください。たとえば、`REPLACE INTO` モードを使用します。 2. タスクをべき等にできない場合は、再実行する際に注意し、不要な再試行を防ぐために成功アラートを設定してください。
パーティション式が正しくない	MaxCompute では、ほとんどのデータテーブルはパーティション化されており、パーティション値は多くの場合、$bizdate のような DataWorks のスケジューリングパラメーターです。よくあるエラーは次のとおりです：スケジューリングパラメーターが正しく置換されません。その結果、データは ds=20230118 のような実際の業務日付ではなく、ds=$bizdate のようなリテラル名のパーティションに書き込まれます。下流のクエリが正しく評価されないパーティション式を使用しているため、クエリが間違ったパーティションからデータを読み取ってしまいます。	データ同期タスクの変数式を確認してください。スケジューリングパラメーターの設定が正しいこと、およびタスクインスタンスのランタイムパラメーターが期待どおりの値に解決されることを確認してください。
データ型またはタイムゾーンの不一致	ソースと送信先の間でデータ型またはタイムゾーンの設定が一致しないと、データが切り捨てられたり、誤って変換されたり、比較時に不一致が生じたりする可能性があります。	ソースと送信先の間のデータ型とタイムゾーンの違いを確認してください。現在の状態を受け入れるか、送信先でデータ型とタイムゾーンのパラメーターを変更するかを決定してください。
他のプロセスによって送信先データが変更された	他のアプリケーションが送信先データソースを同時に変更すると、その内容がソースデータと一致しなくなる可能性があります。	同期ウィンドウ中に他のプロセスが送信先テーブルに書き込まないようにしてください。同時書き込みが期待される動作である場合は、結果として生じるデータの不一致を受け入れる必要があります。

付録：リレーショナルデータベースの書き込みモード

プロトコルタイプ	書き込みモード	競合時の動作	競合がない場合の動作	使用場面
一般/MySQL プロトコル	`insert into`	挿入に失敗し、ダーティデータが生成されます。	新しいデータを挿入します。	既存のレコードを上書きまたは変更せずに、完全同期または増分同期のためにデータを追加します。
	`replace into`	古い行をまず削除し、次に新しい行を挿入することで、古い行を置き換えます。	新しいデータを挿入します。	古いレコードを最新のデータで完全に上書きします。
	`insert into ... on duplicate key update`	指定されたフィールドのみを新しいデータで更新することで、古い行を更新します。	新しいデータを挿入します。	作成タイムスタンプなど、他のフィールドを保持しながら、レコード内の特定のフィールドを更新します。
	`insert ignore into`	新しい行を書き込んだりエラーを生成したりせずに無視します。	新しいデータを挿入します。	まだ存在しないデータのみを挿入し、既存のレコードには何もしません。
PostgreSQL	`insert on conflict do nothing`	新しい行を書き込んだりエラーを生成したりせずに無視します。	新しいデータを挿入します。	まだ存在しないデータのみを挿入し、既存のレコードには何もしません。
	`insert on conflict do update`	競合する行の指定されたフィールドを新しいデータで更新することにより、古い行を更新します。	新しいデータを挿入します。	作成タイムスタンプなど、他のフィールドを保持しながら、レコード内の特定のフィールドを更新します。
	`copy on conflict do nothing`	競合する行を破棄します。高性能な `COPY` プロトコルを使用し、競合時にダーティデータを生成せずに新しいデータを無視します。	新しいデータを一括で挿入します。	重複レコードをスキップできるようにしながら、大量のデータを効率的に追加します。
	`copy on conflict do update`	競合する行を更新します。`COPY` プロトコルを使用し、競合時に古いデータを新しいデータで上書きします。	新しいデータを一括で挿入します。	大量のデータを効率的に同期し、古いレコードを最新のデータで上書きします。
-	`merge into`	サポートされていません。

Reader 側のデータ整合性のトラブルシューティング

Data Integration の Reader プラグインは、ソースデータストアに接続し、データを抽出し、Writer プラグインに配信します。ソースデータソースタイプごとに、対応する Reader プラグインが存在します。プラグインは、フィルター、テーブル、パーティション、列など、設定された抽出モードに基づいて、JDBC またはデータソースの SDK を使用してデータを抽出します。

説明

実際の読み取り結果は、データ同期メカニズム、ソースデータの変更、およびタスク構成に依存します。

データ同期タスクの完了後、レコード数やデータ内容などのデータ品質に問題が発生した場合は、以下の Reader 側でよくある問題を確認してください。

原因	説明	解決策
ソースデータの同時変更	読み取り操作中に外部アプリケーションがソースデータを変更している可能性があります。したがって、同期タスクはデータの絶対的な最新状態ではなく、読み取り時点のデータスナップショットをキャプチャします。並列読み取りを可能にするために、同期ジョブは複数のタスクに分割され、それぞれが独立したデータベースクエリを発行します。データベースのトランザクション分離のため、各タスクは異なる時点のデータスナップショットを取得します。その結果、ジョブはすべてのタスクが開始された後に発生したデータ変更をキャプチャできません。	この動作を、高スループットのデータ同期の仕様通りの動作として受け入れてください。ソースデータのリアルタイムの変更により、タスクを再実行すると異なる結果が生じる場合があります。
フィルター条件が正しくない	MySQL では、`WHERE` 句を設定して抽出データをフィルタリングできます。句に `gmt_modify >= ${bizdate}` のようにスケジューリングパラメーターが含まれている場合、よくあるエラーはパラメーターの置換が正しくないことです。たとえば、2 日分のデータが必要な場合に、タスクが 1 日分のデータしかフィルタリングしないことがあります。 MaxCompute では、パーティションテーブルからデータを読み取る際に、`pt=${bizdate}` のようなパーティションパラメーターに変数式が設定されることがよくあります。これらのパラメーターは、設定を間違えたり、置換に失敗したりしやすいです。	データ同期タスクのスケジューリング変数式を確認してください。スケジューリングパラメーターの設定が正しいこと、およびパラメーター値が実行時に期待どおりに置換されることを確認してください。
Reader 側のダーティデータ	ソースデータの読み取り時に解析エラーが発生します。これは構造化データベースでは稀ですが、OSS 内の CSV や JSON ファイルなどの半構造化データソースで発生する可能性があります。フォーマットエラーにより、一部のレコードがスキップされることがあります。	タスクの実行ログで解析エラーやフォーマット例外を確認し、ソースデータファイルを修正してください。ダーティデータの許容設定を調整してください。

環境問題のトラブルシューティング

原因	解決策
間違ったデータソース、テーブル、またはパーティションをクエリしている	標準モードの DataWorks ワークスペースでは、開発環境と本番環境の分離が強制されます。単一テーブルのバッチ同期タスクは、開発環境では開発データソースを、本番環境では本番データソースを使用します。データ量と内容を比較する際は、不一致を避けるために、どのデータソース環境をクエリしているかを確認してください。本番環境では、オンラインデータソースには対応するステージング環境やテスト環境があることがよくあります。同期タスクが使用するデータベースは、ステージングデータベースやテストデータベースとは異なる場合があります。データを検証する際は、これらの環境の違いを確認してください。半構造化データを同期する場合、複数のファイルが関与することがよくあります。ファイルの完全なセットから読み取り、書き込みを行っていることを確認してください。
アップストリームの依存関係が満たされていない	データが定期的に生成される場合 (定期実行のデータ同期タスクやマージタスクなど)、このデータを生成する上流タスクが実行され、正常に完了していることを確認してください。

説明

一般的なトラブルシューティング手順として、タスクを複数回実行して同期結果を観察・比較することができます。また、比較テストのためにソースまたは送信先のデータソースを切り替えてみることもできます。これらのテストは、問題の絞り込みに役立ちます。