DataWorks Data Integration は、MySQL、MaxCompute、Hologres、Kafka など複数のデータソース間でデータを同期します。T+1 バッチ抽出・変換・書き出し（ETL）、秒単位の遅延によるリアルタイムデータ同期、完全データベース移行など、さまざまなシナリオ向けのソリューションを提供します。
同期ソリューション
同期タイプ | ソース粒度 | ターゲット粒度 | タイムリネス | シナリオ |
単一テーブルバッチ | 単一テーブル | 単一テーブル／パーティション | T+1 または定期的 | 定期的な完全読み込み、定期的な増分読み込み |
シャード化データベースおよびテーブルバッチ | シャード化テーブル | 単一テーブル／パーティション | T+1 または定期的 | 定期的な完全読み込み、定期的な増分読み込み |
単一テーブルリアルタイム | 単一テーブル | 単一テーブル／パーティション | 秒～分単位 | Change Data Capture (CDC) |
完全データベースバッチ | 完全データベースまたは複数テーブル | 対応する複数テーブルおよびそのパーティション | 一度きりまたは定期的 | 一度きりまたは定期的な完全読み込み、一度きりまたは定期的な増分読み込み、または一度きりの完全読み込みに続いて定期的な増分読み込み |
完全データベースリアルタイム | 完全データベースまたは複数テーブル | 対応する複数テーブルおよびそのパーティション | 秒～分単位 | 完全読み込み + Change Data Capture (CDC) |
完全データベース完全および増分 | 完全データベースまたは複数テーブル | 対応する複数テーブルおよびそのパーティション | 初期完全読み込み：バッチ 継続的な増分読み込み：T+1 | 初期完全読み込みと定期的な増分読み込み |
推奨される同期ソリューション
データ同期ソリューションを選択する際は、次の 2 つの主要な要素を考慮してください。
データのタイミング要件：ビジネスでデータ同期がどの頻度で必要ですか？日次バッチ更新が必要ですか、それとも秒単位または分単位のリアルタイム更新が必要ですか？
同期範囲と複雑さ：同期する必要のあるテーブルはいくつありますか？これらのテーブルに対する処理ロジックは一貫していますか？これにより、単一テーブルソリューションと完全データベースソリューションのどちらが必要かが決まります。
これらの要素に基づき、バッチ同期とリアルタイム同期の 2 種類の同期ソリューションを推奨します。
1. バッチ同期（T+1 または定期的）
バッチソリューションは、T+1 定期バッチ処理などのように、データのタイミング要件が厳しくないユースケースに最適です。
前提条件：増分バッチ同期を実行するには、ソーステーブルに gmt_modified のようなタイムスタンプや自動インクリメント ID など、増分を追跡するためのフィールドが含まれている必要があります。このようなフィールドが存在しない場合は、定期的な完全同期のみを実行できます。
1. 単一テーブルバッチ
このアプローチは、少数のコアとなる異種データテーブルに対して詳細な処理を行う必要があるシナリオに最も適しています。
主なメリット：柔軟な処理ロジック。
詳細な変換：複雑なフィールドマッピング、データフィルタリング、定数値の割り当て、関数ベースの変換、さらには AI を活用した処理をサポートします。
異種ソース統合：API やログファイルなどの非標準ソースからのデータ処理に最適です。
主な制限：スケール時のコストが高くなること。
構成オーバーヘッドが高い：多数のテーブルに対して個別のタスクを構成および保守するには、多大な労力が必要です。
リソース消費量が多い：各タスクは個別にスケジュールされます。100 個の単一テーブルタスクのリソース消費量は、1 個の完全データベースタスクよりもはるかに大きくなります。
推奨ソリューション：単一テーブルのバッチ同期タスク
2. 完全データベースバッチ
多数の均質なテーブルをある場所から別の場所へ効率的に移行する必要がある場合に、このアプローチを使用します。
主なメリット：運用効率が高く、コストが低いこと。
高効率：数百のテーブルを一度に構成でき、オブジェクトの自動マッチングにより開発効率が大幅に向上します。
コスト効率が高い：リソーススケジューリングが最適化されているため、コストが非常に低くなります。たとえば、1 個の完全データベースタスクのリソース消費量は 2 CU であるのに対し、100 個の単一テーブルタスクでは 100 CU になります。
代表的なユースケース：データウェアハウスの ODS レイヤーの構築、定期的なデータベースバックアップの実行、クラウドへのデータ移行。
主な制限：処理ロジックが限定されること。
主にレプリケーション向けに設計されており、テーブル固有の複雑な変換ロジックはサポートしていません。
推奨ソリューション：完全データベースのバッチ同期タスク。
2. リアルタイム同期（秒単位または分単位）
リアルタイムソリューションは、ソースからのデータ変更（挿入、更新、削除）をキャプチャして、リアルタイム分析やビジネスへの即時対応をサポートする必要があるユースケースに最適です。
前提条件：ソースが Change Data Capture (CDC) をサポートしているか、メッセージキューである必要があります。たとえば、MySQL データベースではバイナリログを有効にする必要があります。また、ソースが Kafka インスタンスである場合も該当します。
単一テーブルリアルタイムまたは完全データベースリアルタイム
選択ロジックはバッチソリューションと同様です。
単一テーブルリアルタイム：コアとなる単一テーブルからのリアルタイム変更ストリームに対して複雑な処理を行う必要があるシナリオに最適です。
完全データベースリアルタイム：リアルタイムデータウェアハウスの構築、リアルタイムデータベースディザスタリカバリの実装、リアルタイムデータレイクの作成における主流の選択肢です。効率性とコスト効率の面でも大きなメリットがあります。
推奨ソリューション単一テーブルのリアルタイム同期タスク、完全データベースのリアルタイム同期タスク
3. 特殊なユースケース：CDC を追加専用ターゲットに適用
背景：リアルタイム同期によってキャプチャされた CDC データには、Insert、Update、Delete の 3 種類の操作が含まれます。MaxCompute の非 Delta テーブルなど、物理的な Update や Delete 操作をネイティブにサポートしていない追加専用ストレージシステムの場合、CDC ストリームを直接書き込むとデータの不整合が発生する可能性があります。たとえば、削除操作はターゲットテーブルに反映されません。
DataWorks のソリューション：Base + Log パターン
このソリューションは、完全データベース完全および増分（ニアリアルタイム）タスクとして実装されます。ターゲット側に
Baseテーブル（完全スナップショット）とLogテーブル（増分ログ）を作成します。仕組み：CDC データストリームはリアルタイムで
Logテーブルに書き込まれます。その後、T+1 でシステムが自動的にタスクをスケジュールし、Logテーブルからの変更をBaseテーブルにマージして、更新された完全スナップショットを生成します。このアプローチでは、増分テーブルへの書き込みは分単位の遅延で行われます。最終的な一貫性のある状態は、T+1 マージ後に確認できます。これにより、リアルタイムデータキャプチャとバッチデータウェアハウスに必要な結果整合性（Eventual Consistency）のバランスが取られます。
推奨ソリューション：完全データベース完全および増分（ニアリアルタイム）タスク。
データソースの機能
データソース | 単一テーブルバッチ | 単一テーブルリアルタイム | 完全データベースバッチ | 完全データベースリアルタイム | 完全データベース完全および増分 |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | - | 読み取り | 読み取り | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
Elasticsearch | 読み取り/書き込み | 書き込み | 書き込み | 書き込み | - |
読み取り/書き込み | - | - | - | - | |
GBase8a | 読み取り/書き込み | - | - | - | - |
HBase | HBase： 読み取り/書き込み HBase 2.x SQL：読み取り HBase 1.1.x SQL：書き込み | - | - | - | - |
読み取り/書き込み | - | - | - | - | |
Hive | 読み取り/書き込み | - | 読み取り/書き込み | - | - |
読み取り/書き込み | 読み取り/書き込み | 読み取り/書き込み | 書き込み | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | - | 書き込み | - | |
読み取り/書き込み | 読み取り | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | 書き込み | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | 読み取り | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
書き込み | - | - | - | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
Vertica | 読み取り/書き込み | - | - | - | - |
読み取り | - | - | - | - |
ユースケース
参考文献
Data Integration の利用を開始するには、次の記事をご参照ください。
データソースの構成については、「データソース管理」をご参照ください。
同期タスクの構成については、次の記事をご参照ください。
データ同期に関するよくある質問については、「Data Integration FAQ」をご参照ください。