オフライン単一テーブル同期における Data Quality のトラブルシューティング - DataWorks

このトピックでは、Data Integration におけるデータ同期の仕組みについて説明します。このプロセスを理解することで、同期されたデータ量や宛先の最終的なレコード数など、同期タスクの結果を評価するのに役立ちます。このトピックでは、一般的な Data Quality シナリオについても説明し、関連する問題の特定と解決に役立てます。

同期の原則

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

並列実行モデル (Job と Task)

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

Job: 同期タスクの実行中のインスタンス。
Task: Job の最小実行単位。1 つの Job は複数の Task に分割されます。これらの Task は、1 つ以上のマシンで同時に実行できます。

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

プラグインベースのデータストリーム (Reader と Writer)

各 Task 内で、データストリームはメモリバッファーを介して Reader プラグインと Writer プラグインを接続します。

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

説明

Reader プラグインと Writer プラグインは、それぞれのデータソースのネイティブな読み取り/書き込みプロトコルとデータ制約に従います。これらの制約には、データの型やプライマリキーの制限が含まれる場合があります。最終的な同期結果とデータ整合性の動作は、ソースと宛先のデータソースの実装ルールに依存します。

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

Data Integration の Writer プラグインは、ソースから宛先にデータを書き込みます。各宛先データソースタイプには、対応する Writer プラグインがあります。Writer プラグインは、競合解決ポリシーを含む、構成された書き込みモードを使用します。Java Database Connectivity (JDBC) またはデータソースのソフトウェア開発キット (SDK) を使用して、宛先にデータを書き込みます。

説明

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

データ同期タスクの完了後に、レコード数やデータ内容の不一致などの Data Quality の問題が発生した場合は、次の一般的な Writer 側のシナリオを確認してください。

原因	説明	解決策
書き込みモードの不適切な構成	Writer プラグインは、選択された書き込みモードに基づいてソースデータを宛先に書き込みます。データ制約によりソースデータと宛先テーブルスキーマの間に競合が存在する場合、操作は挿入の失敗 (ダーティデータ)、挿入の無視、または挿入の置き換えにつながる可能性があります。	ビジネスニーズに基づいて正しい書き込みモードを選択してください。詳細については、「付録: リレーショナルデータベースの書き込みモード」をご参照ください。
ダーティデータのしきい値に到達	データの型の不一致やコンテンツのサイズ超過などの問題によって発生するダーティデータの量が、構成されたしきい値を超えています。これによりタスクが失敗し、結果として一部のデータが宛先に書き込まれません。	ダーティデータの原因を特定し、問題を解決してください。または、ダーティデータを許容して無視できる場合は、しきい値を増やすこともできます。説明タスクがダーティデータを許容できない場合は、[タスク設定] > [チャネル設定] でしきい値を変更できます。ダーティデータのしきい値の設定方法の詳細については、「コードレス UI 設定」をご参照ください。ダーティデータと見なされるものの詳細については、「用語」をご参照ください。
データのクエリが早すぎる	同期タスクが完了する前にデータをクエリしています。Hive や MaxCompute (構成可能) などの一部のデータソースでは、タスクが終了する前にデータが部分的または完全に見えなくなる場合があります。	同期タスクインスタンスが正常に実行されたことを確認した後、必ず宛先テーブルをクエリして検証してください。
ノードの依存関係の欠落	下流の分析タスクと上流の同期タスクの間に依存関係が構成されていません。これにより、データ同期が完了する前に下流のタスクが開始され、結果として下流のタスクが不完全なデータを読み取ることになります。	DataStudio で、上流と下流のタスクの親子ノード依存関係を構成します。`max_pt` などの弱い依存関係の使用は避けてください。
複数の同期タスクが同じテーブルまたはパーティションに同時に書き込み、干渉を引き起こす	同期タスクの不適切な同時実行。 MaxCompute または Hologres では、2 つのタスクが同じデータパーティションに書き込み、同期前にパーティションを切り捨てるように構成されています。最初のタスクによって書き込まれたデータは、2 番目のタスクによってクリアされる可能性があります。リレーショナルデータベースの場合、pre-SQL または post-SQL 文が構成されていると、最初のタスクによって書き込まれたデータが、2 番目のタスクの pre-SQL または post-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 プラグインがあります。Reader プラグインは、フィルター条件、テーブル、パーティション、列を含む、構成されたデータ抽出モードを使用します。JDBC またはデータソースの SDK を使用してデータを抽出します。

説明

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

データ同期タスクの完了後に、レコード数やデータ内容の不一致などの Data Quality の問題が発生した場合は、次の一般的な Reader 側のシナリオを確認してください。

問題	説明	解決策
ソースデータの同時変更	データ読み取り中に、外部アプリケーションがまだソースデータを変更している可能性があります。同期タスクは、読み取りの瞬間のデータスナップショットをキャプチャするため、絶対的な最新データではありません。並列読み取りを実現するために、同期 Job は複数の Task に分割されます。これらは独立したデータベースクエリです。データベースのトランザクション隔離のため、各 Task は異なる時点のデータスナップショットを取得します。これは、すべての Task が開始された後に発生するデータ変更をタスクがキャプチャできないことを意味します。	高スループットのデータ同期では、この動作を正常なものとして受け入れてください。ソースデータのリアルタイムの変更により、タスクを複数回実行すると異なる結果が生成される場合があります。
不正なクエリ条件	たとえば、MySQL では、`WHERE` 句を構成して抽出データをフィルターできます。`WHERE` 句に `gmt_modify >= ${bizdate}` などのスケジューリングパラメーター変数が含まれている場合、一般的なエラーはスケジューリングパラメーターが正しく置き換えられないことです。たとえば、過去 2 日間のデータが必要なのに、1 日分のデータしかフィルターしていない場合があります。たとえば、MaxCompute でパーティションテーブルを読み取る場合、パーティションパラメーターに `pt=${bizdate}` などの変数式を構成することがよくあります。この場合も、パーティションパラメーターを誤って構成したり、置き換えに失敗したりしやすいです。	データ同期タスクのスケジューリング変数式を確認します。スケジューリングパラメーターの構成が期待どおりであり、スケジューリング中にパラメーターが期待される値に置き換えられることを確認します。
Reader 側のダーティデータ	ソースデータの読み取り時に解析が失敗します。これは構造化データベースではまれです。ただし、OSS や Hadoop 分散ファイルシステム (HDFS) の CSV や JSON ファイルなどの半構造化データソースでは、フォーマットエラーにより一部のデータが読み取れないことがあります。	タスク実行ログで解析エラーやフォーマット例外を確認し、ソースデータファイルを修正します。ダーティデータの許容構成を調整します。

環境コンテキストのトラブルシューティング

問題	解決策
クエリ用に選択されたデータソース、テーブル、またはパーティションが正しくない	標準モードの DataWorks ワークスペースでは、データソースは開発環境と本番環境の間で隔離されています。オフラインの単一テーブル同期タスクは、開発環境で実行される場合は開発データソースを使用します。本番環境で実行される場合は本番データソースを使用します。データの量と内容を比較する際は、開発クエリと本番クエリの間の不一致を避けるために、使用しているデータソース環境を確認してください。本番環境では、オンラインストアには対応するプレリリース環境やテスト環境があることがよくあります。同期タスクで使用される本番データベースは、プレリリースまたはテストデータベースとは異なります。データを比較する際は、環境の違いを確認してください。半構造化データを同期する場合、複数のファイルが関与することがよくあります。読み取りと書き込みのためのファイルのコレクションが完全であることを確認してください。
依存する出力の準備ができていない	データが定期的に生成される場合、たとえば、定期的なデータ同期タスクや定期的な完全/増分データマージタスクによって生成される場合、依存するデータ生成タスクが実行され、正常に完了したことを確認してください。

説明

Data Quality の問題が発生した場合の一般的なトラブルシューティングとして、タスクを複数回実行して同期結果を観察および比較することができます。また、比較テストのためにソースまたは宛先のデータソースを切り替えることもできます。複数の比較テストを実行することで、問題の範囲を絞り込むのに役立ちます。