すべてのプロダクト
Search
ドキュメントセンター

DataWorks:バッチ同期におけるデータ品質関連の問題のトラブルシューティング

最終更新日:Mar 21, 2025

このトピックでは、データ品質の問題が発生する一般的なシナリオについて説明します。このトピックに記載されている手順を参照して、バッチ同期におけるデータ品質関連の問題を迅速にトラブルシューティングできます。

背景情報

このトピックでは、データ同期の原則とメカニズムについても説明し、データ同期プロセスを理解し、データ同期効果を判断するのに役立ちます。同期先へ同期されるデータ量や、同期先に同期されるデータレコード数などの項目に基づいて、データ同期効果を判断できます。

データ同期の原則

Data Integration のデータ同期ノードは、ジョブとして実行されます。データ同期効率を向上させるために、データ同期ノードの実行時に、システムはジョブを複数のタスクに分割します。システムは、単一スレッドまたは並列スレッドを使用してタスクを実行します。システムが並列スレッドを使用してタスクを実行する場合、各タスクは特定の範囲からデータを読み取ります。すべてのタスクがデータ同期プロセス全体を構成します。

説明

データのバッチ同期中は、リーダーを使用してデータを読み取り、ライターを使用してデータを書き込みます。

  • リーダーはソースからデータを読み取り、内部バッファキューに転送します。ライターは、内部バッファキューからデータを使用し、同期先にデータを書き込みます。

  • リーダーとライターは互いに連携して、データ同期プロセスを完了します。リーダーとライターは、データソースのデータ読み取りおよび書き込みプロトコルとルールに従います。データソースのデータ読み取りおよび書き込みルールには、データソースによってデータに課される制約が含まれます。したがって、データ同期効果は、データソースのデータ読み取りおよび書き込みプロトコルとルールによって影響を受けます。

同期先でのデータ整合性の確認

ライターは、ソースから読み取られたデータを同期先に書き込みます。Data Integration は、同期先のタイプごとにライターを提供します。ライターは、関連するデータ同期ノードに設定されている書き込みモードと競合処理ポリシーに基づいて、Java Database Connectivity(JDBC)接続を介して、または同期先の SDK を使用して、同期先にデータを書き込みます。

説明

同期先へのデータ書き込みの効果は、データコンテンツ、書き込みモード、および同期先テーブルの制約に関連しています。

データ同期ノードによって同期されるデータの品質がビジネス要件を満たしていない場合は、次の表に記載されている手順に基づいて、同期先の問題をトラブルシューティングできます。データ品質は、データレコード数とデータコンテンツという観点から評価できます。

原因

問題の説明

解決策

不適切な書き込みモードが設定されています。

ライターは、関連するデータ同期ノードに設定されている書き込みモードに基づいて、同期先でリプレイ操作を実行します。ソースデータと同期先テーブルのスキーマ間で制約の競合が発生した場合、特定の状況が発生する可能性があります。たとえば、ダーティデータが原因でソースデータを同期先テーブルに挿入できない、ソースデータが無視される、同期先テーブルの既存データがソースデータで置き換えられるなどです。

データ同期ノードに適切な書き込みモードを設定し、ソースデータと同期先テーブルのスキーマ間で制約の競合が発生するかどうか、および制約が合理的かどうかを確認します。リレーショナルデータベースへのデータ書き込みには、次の一般的な書き込みモードがサポートされています。書き込みモードは、同期先のタイプによって異なります。

insert into

この書き込みモードでは、INSERT INTO ステートメントを使用して同期先にデータを書き込むことができます。ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、ソースのデータはダーティデータと見なされ、同期先に書き込まれません。データ同期ノード用に生成されたログを表示して、データ同期中に生成されたダーティデータレコードの数とデータコンテンツを取得できます。

replace into

この書き込みモードでは、REPLACE INTO ステートメントを使用して同期先にデータを書き込むことができます。

  • ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、システムはソースデータを使用して同期先テーブルの既存データを置き換えます。同期先テーブルに複数のデータ制約が存在する場合、同期先テーブルの複数のデータレコードが置き換えられる可能性があります。

  • ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。この操作は、insert into 書き込みモードを使用した場合に実行される操作と同じです。

insert into on duplicate key update

この書き込みモードでは、INSERT INTO ON DUPLICATE KEY UPDATE ステートメントを使用して同期先にデータを書き込むことができます。

  • ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、システムはソースデータを使用して同期先テーブルの既存データを更新します。同期先テーブルに複数のデータ制約が存在する場合、データの更新が失敗し、ダーティデータが生成される可能性があります。

  • ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。この操作は、insert into 書き込みモードを使用した場合に実行される操作と同じです。

insert ignore into

この書き込みモードでは、INSERT IGNORE INTO ステートメントを使用して同期先にデータを書き込むことができます。

  • ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、システムはソースデータを無視し、同期先に書き込みません。データ書き込み操作のステータスは成功し、ダーティデータは生成されません。

  • ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。この操作は、insert into 書き込みモードを使用した場合に実行される操作と同じです。

insert on conflict do nothing

この書き込みモードは、PostgreSQL のプロトコルファミリでサポートされているモードであり、MySQL プロトコルでサポートされている insert ignore into 書き込みモードに似ています。

  • ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、システムはソースデータを無視し、同期先に書き込みません。データ書き込み操作のステータスは成功し、ダーティデータは生成されません。

  • ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。この操作は、insert into 書き込みモードを使用した場合に実行される操作と同じです。

insert on conflict do update

この書き込みモードは、PostgreSQL のプロトコルファミリでサポートされているモードであり、MySQL プロトコルでサポートされている insert into on duplicate key update 書き込みモードに似ています。

  • ソースのデータと同期先の既存データ間で、主キーの競合、一意キー制約、または外部キー制約などのデータ制約の競合が発生した場合、システムはソースデータを使用して同期先テーブルの既存データを更新します。同期先テーブルに複数のデータ制約が存在する場合、データの更新が失敗し、ダーティデータが生成される可能性があります。

  • ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。この操作は、insert into 書き込みモードを使用した場合に実行される操作と同じです。

copy on conflict do nothing

この書き込みモードは、PostgreSQL のプロトコルファミリでサポートされているモードです。この書き込みモードでは、COPY ステートメントを使用して同期先にデータを書き込むことができます。ソースのデータと同期先の既存データ間でデータ制約の競合が発生した場合、ソースデータは破棄され、ダーティデータは生成されません。ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。

copy on conflict do update

この書き込みモードは、PostgreSQL のプロトコルファミリでサポートされているモードです。この書き込みモードでは、COPY ステートメントを使用して同期先にデータを書き込むことができます。ソースのデータと同期先の既存データ間でデータ制約の競合が発生した場合、システムはソースデータを使用して同期先の既存データを置き換え、ダーティデータは生成されません。ソースのデータと同期先の既存データ間でデータ制約の競合が発生しない場合、システムはソースデータを同期先に挿入します。

merge into

この書き込みモードはサポートされていません。

データ同期中にダーティデータが生成されます。

ソースのデータが同期先に書き込まれず、ダーティデータが生成されます。その結果、同期先に同期されるデータレコードの数が、ソースのデータレコードの数と一致しません。

ダーティデータが生成される理由を特定し、ダーティデータの問題を解決します。

説明

データ同期ノードでダーティデータが生成されないようにするには、コードレス ユーザーインターフェース(UI)でノードの [チャネル制御ポリシー] を設定する際に、データ同期中に許可されるダーティデータレコードの最大数を 0 に変更できます。パラメータ設定の詳細については、「コードレス UI を使用したバッチ同期タスクの設定」をご参照ください。ダーティデータの詳細については、「用語」をご参照ください。

データ同期ノードの実行時にデータクエリが実行されます。

Hive Writer や MaxCompute Writer などの一部のタイプのライターでは、関連するデータ同期ノードの実行が完了する前に、同期先に同期されたデータにクエリを実行できます。MaxCompute Writer の場合、この機能を有効にするか無効にするかを指定できます。関連するデータ同期ノードの実行が完了する前にデータにクエリを実行すると、同期先のデータとソースのデータが一致しません。

データ同期ノードの実行が完了した後にデータにクエリを実行します。

ノード間のスケジューリング依存関係が設定されていません。

データ分析ノードは、データ同期ノードによって生成されたデータを使用する必要がありますが、2 つのノード間でスケジューリング依存関係が設定されていません。たとえば、データ分析ノードは、同期先が MaxCompute データソースであるデータ同期ノードによって生成されたデータを使用する必要がありますが、2 つのノード間でスケジューリング依存関係が設定されていません。データ分析ノードは、max_pt 関数を使用して、同期先の MaxCompute テーブルで最大量のデータを格納するパーティションを識別し、そのパーティションからデータを読み取ろうとします。ただし、データ同期ノードはまだそのパーティションにデータを書き込んでいません。その結果、データ分析ノードは必要なデータを取得できません。

max_pt などのメソッドを使用してノード間に弱いデータ依存関係を確立しないでください。代わりに、ノード間のスケジューリング依存関係を設定します。これにより、子孫ノードは先祖ノードから必要なデータを正常に取得できます。

複数のデータ同期ノードまたは同じデータ同期ノードの複数のインスタンスが、同じ同期先テーブルまたは同じパーティションにデータを書き込みます。

複数のデータ同期ノードまたは同じデータ同期ノードの複数のインスタンスが並列で実行されます。

  • 同じデータ同期ノードの複数のインスタンスが並列で実行されるために競合が発生する場合は、ノードの自己依存関係を設定することをお勧めします。詳細については、「前のサイクルで現在のノード用に生成されたインスタンスへの依存関係」をご参照ください。

  • たとえば、同期先が同じ MaxCompute データソースまたは同じ Hologres データソースである 2 つのデータ同期ノードが並列で実行され、同じパーティションにデータを同期し、データ同期前に既存のデータをクリアするために使用される SQL ステートメントがそれぞれノードに設定されているとします。この場合、最初のノードによってパーティションに書き込まれたデータは、2 番目のノードがパーティションにデータを書き込む前に、2 番目のノードによってクリアされる可能性があります。

  • リレーショナルデータベースからデータを同期するために使用される 2 つのデータ同期ノードが並列で実行され、同じテーブルまたはパーティションにデータを同期し、データ同期の前または後に実行する必要がある SQL ステートメントがノードのいずれかに設定されている場合、SQL ステートメントは、他のノードによってテーブルまたはパーティションに書き込まれたデータに影響を与える可能性があります。

データ同期ノードのデータ同期結果はべき等ではありません。

理論的には、データ同期ノードを複数回実行すると、データ同期の結果は同じになります。データ同期ノードの設定をべき等モードで実行できず、ノードが成功または失敗時に複数回再実行された場合、同期先に同期されるデータが重複したり、上書きされたりする可能性があります。

データ同期ノードを複数回実行しないでください。

説明

ビジネスシナリオでデータ同期ノードの再実行を許可しないが、ノードの出力の適時性を確保したい場合は、ノードの監視およびアラート設定を行うことをお勧めします。これにより、指定されたアラート受信者は、エラー発生後できるだけ早くアラート通知を受信し、効率的に問題をトラブルシューティングできます。ノードの監視およびアラート設定方法については、「タスク監視」をご参照ください。

スケジューリングパラメータが正しく設定されていないか、正しくない値に置き換えられています。

たとえば、パーティション分割された MaxCompute テーブルにデータを同期するためにスケジューリングパラメータが設定されているデータ同期ノードを実行する場合、$bizdate などのスケジューリングパラメータを使用して同期先パーティションを指定できます。この場合、次の問題が発生する可能性があります。

  • スケジューリングパラメータが正しい値に置き換えられません。その結果、20230118 などのデータタイムスタンプで示されるパーティションではなく、$bizdate という名前のパーティションにデータが書き込まれます。

  • データ同期ノードの子孫ノードに設定されている、スケジューリングパラメータを含むパーティションフィルタ式に割り当てられた値が正しくありません。その結果、子孫ノードの実行時に、ノードは正しくないパーティションからデータをクエリします。

設定されているスケジューリングパラメータがビジネス要件を満たしているかどうか、およびノードの実行中にスケジューリングパラメータが期待どおりに実際の値に置き換えられているかどうかを確認します。

同期先のデータ型、データ範囲、およびタイムゾーンがソースのデータ型、データ範囲、およびタイムゾーンと異なります。

  • 同期先のデータ型とデータ範囲がソースのデータ型とデータ範囲と異なります。その結果、データ同期中にデータが予期せず切り捨てられるか、ダーティデータが生成されます。

  • 同期先のタイムゾーンがソースのタイムゾーンと異なります。その結果、同期先に同期されるデータがソースのデータと異なります。

  • ソースと同期先のデータ型、データ範囲、およびタイムゾーンが異なるかどうかを確認します。

  • 同期先のタイムゾーンに関連するデータ型とパラメータ設定を変更する必要があるかどうかを確認します。データ型と設定を変更する必要がない場合は、元の設定を保持します。

同期先に同期されたデータが変更されています。

他のシステムプログラムが、同期先に同期されたデータにアクセスして更新する可能性があります。その結果、同期先のデータがソースのデータと異なります。

ほとんどの場合、この状況は予期されたとおりに発生し、処理する必要はありません。

ソースのデータ整合性の確認

リーダーはソースに接続し、ソースからデータを読み取ってから、ライターに転送します。Data Integration は、ソースのタイプごとにリーダーを提供します。リーダーは、関連するデータ同期ノードに設定されているデータ読み取り設定に基づいて、JDBC 接続を介して、またはソースの SDK を使用して、ソースからデータを読み取ります。データ読み取り設定には、データフィルタ条件、テーブル、パーティション、および列が含まれます。

説明

ソースからデータを読み取る効果は、データ同期メカニズム、ソースのデータ変更、ノード設定など、さまざまな要因によって異なります。

データ同期ノードによって同期されるデータの品質がビジネス要件を満たしていない場合は、次の表に記載されている手順に基づいて、ソースの問題をトラブルシューティングできます。データ品質は、データレコード数とデータコンテンツという観点から評価できます。

原因

問題の説明

解決策

ソースのデータが継続的に変更されています。

同期するソースデータが継続的に変更される可能性があります。その結果、同期先に同期されるデータが、ソースの最新データと一致しない可能性があります。本質的に、データ同期ノードは、ソースでデータクエリステートメントを実行することにより、ソースからデータを読み取ります。リレーショナルデータベースからデータを同期するために使用されるデータ同期ノードの最大並列スレッド数を指定すると、ノードはスレッドを実行して、複数のクエリステートメントを同時に実行することにより、ソースからデータを並列で読み取ります。リレーショナルデータベースのトランザクション整合性特性により、各クエリステートメントは、ステートメントの実行時に生成されたデータスナップショットのみを返します。クエリステートメントは、同じトランザクションのコンテキストに属していません。データクエリステートメントは、ステートメントの実行後に生成されたデータ変更を返すことができません。

ほとんどの場合、この問題はビジネスに影響を与えません。この問題が発生した場合は、データ同期ノードを複数回実行できます。実行ごとに同期されるデータレコードの数は異なる場合があります。

スケジューリングパラメータが正しく設定されていないか、正しくない値に置き換えられています。

  • MySQL データソースなどの特定のデータソースからデータを同期するために使用されるデータ同期ノードのフィルタ条件として、スケジューリングパラメータを含む WHERE 句を設定すると、ノードの実行時にスケジューリングパラメータが正しく置き換えられない可能性があります。たとえば、ソースから過去 2 日間のデータを抽出するために、ノードに gmt_modify >= ${bizdate} を設定します。ただし、ノードの実行時にスケジューリングパラメータが正しく置き換えられないため、過去 1 日間のデータのみが抽出されます。

  • MaxCompute データソースなどの特定のデータソースのパーティション分割されたテーブルからデータを読み取るために使用されるデータ同期ノードに設定されているパーティションフィルタ式でスケジューリングパラメータを使用して、データを読み取るパーティションを指定すると、スケジューリングパラメータがビジネス要件を満たさないか、ノードの実行時に正しく置き換えられない可能性があります。たとえば、pt=${bizdate} を設定すると、問題が発生する可能性があります。

設定されているスケジューリングパラメータがビジネス要件を満たしているかどうか、およびノードの実行中にスケジューリングパラメータが期待どおりに実際の値に置き換えられているかどうかを確認します。

データ同期中にダーティデータが生成されます。

ソースの一部のデータを読み取ることができません。読み取ることができないソースデータは、ダーティデータと見なされます。その結果、同期先に書き込まれるデータレコードの数が、ソースのデータレコードの数と一致しません。

  • ダーティデータが生成される理由を特定し、ダーティデータの問題を解決します。

  • ダーティデータを許可して無視できるかどうかを確認します。

説明

ソースではダーティデータはめったに生成されません。ほとんどの場合、Object Storage Service(OSS)、File Transfer Protocol(FTP)、Hadoop Distributed File System(HDFS)データソースなどの半構造化データソースがソースとして使用されている場合に、ソースでダーティデータが生成されます。

環境情報の確認

原因

解決策

データのクエリ元のデータソース、テーブル、またはパーティションが正しくないか、不完全です。

  • 標準モードの DataWorks ワークスペースは、開発環境のデータソースと本番環境のデータソースを分離します。データ同期ノードが開発環境で実行されると、開発環境のデータソースが使用されます。データ同期ノードが本番環境で実行されると、本番環境のデータソースが使用されます。データ同期の前後でデータレコードの数とデータコンテンツを比較する場合は、データのクエリ元のデータソースが正しいことを確認する必要があります。

  • 本番環境のビジネスシナリオでは、ステージング環境またはテスト環境でオンラインデータソースがよく使用されます。データ同期ノードは、ステージング環境またはテスト環境のデータソースではなく、本番環境のデータソースを使用します。本番環境のデータソースのデータとステージング環境またはテスト環境のデータソースのデータを比較して、データに違いがあるかどうかを確認する必要があります。

  • データ同期ノードのソースまたは同期先が半構造化データソースである場合、ノードは複数のファイルからデータを読み取るか、複数のファイルにデータを書き込む必要がある場合があります。データを読み取るファイルまたはデータを書き込むファイルが完全であるかどうかを確認する必要があります。

データ出力が生成されていません。

定期的に生成されるデータ(定期的にスケジュールされるデータ同期ノードによって生成されるデータ、または完全データと増分データを定期的にマージするために使用されるマージノードによって生成されるデータなど)にクエリを実行する場合は、関連するノードの実行が完了し、データが生成されているかどうかを確認する必要があります。

説明

データ同期ノードのデータ品質の問題をトラブルシューティングする場合は、ノードを複数回実行し、データ同期効果を比較できます。また、データ同期ノードのソースまたは同期先を変更したり、異なる同期先が使用されるシナリオでデータ同期効果を比較したりすることもできます。これにより、トラブルシューティングの範囲を絞り込み、トラブルシューティングを容易にすることができます。