DataWorks Data Integration は、MySQL、MaxCompute、Hologres、Kafka などの複数のデータソース間でのデータ同期をサポートしています。Data Integration では、バッチ処理、リアルタイムデータ同期、データベース全体の移行といったソリューションを提供しています。これらのソリューションは、T+1 バッチ ETL（抽出・変換・書き出し）、秒単位の遅延でリアルタイムデータレプリケーションを行う、データベース全体の移行などのシナリオにご利用いただけます。
同期ソリューション
タイプ | ソース粒度 | ターゲット粒度 | 適時性 | 同期シナリオ |
単一テーブルバッチ | 単一テーブル | 単一テーブルまたはパーティション | T+1 または定期的 | 定期的な完全同期、定期的な増分同期 |
シャード化されたデータベースおよびテーブルのバッチ | 同一構造を持つ複数のテーブル | 単一テーブルまたはパーティション | T+1 または定期的 | 定期的な完全同期、定期的な増分同期 |
単一テーブルリアルタイム | 単一テーブル | 単一テーブルまたはパーティション | 秒～分単位 | リアルタイム増分同期（CDC） |
データベース全体バッチ | データベース全体または複数のテーブル | 対応する複数のテーブルおよびそのパーティション | 一回限りまたは定期的 | 一回限り／定期的な完全同期、一回限り／定期的な増分同期、一回限りの完全同期＋定期的な増分同期 |
データベース全体リアルタイム | データベース全体または複数のテーブル | 対応する複数のテーブルおよびそのパーティション | 秒～分単位 | 完全同期＋リアルタイム増分同期（CDC） |
データベース全体完全＋増分同期 | データベース全体または複数のテーブル | 対応する複数のテーブルおよびそのパーティション | 初期完全ロード：バッチ処理 その後の増分同期：T+1 | 完全同期＋リアルタイム増分同期（CDC） |
推奨される同期ソリューション
データ同期ソリューションを選択する際には、以下の 2 つの重要なポイントを考慮してください。
適時性要件：ビジネスで必要なデータ同期頻度は、1 日 1 回（バッチ）ですか、それとも秒単位または分単位のリアルタイム更新（リアルタイム）ですか。
同期規模と複雑さ：同期が必要なテーブル数はどれくらいで、テーブル間で処理ロジックが統一されているか（単一テーブル vs. データベース全体）。
これらの観点に基づき、バッチ同期ソリューションとリアルタイム同期ソリューションの 2 カテゴリに分けてソリューションを推奨します。
1. バッチ同期ソリューション（T+1／定期的）の選択
バッチソリューションは、データの適時性要件が高くなく（例：T+1）、定期的なバッチ処理が必要なシナリオに適しています。
重要な前提条件：バッチ増分同期を実装するには、ソーステーブルに増分データを識別できるカラム（gmt_modified などのタイムスタンプや自動採番 ID など）が含まれている必要があります。このようなカラムが利用できない場合は、定期的な完全同期にフォールバックするしかありません。
1. 単一テーブルバッチを選択
少数のコアとなる異種データソースに対して詳細な処理が必要な場合に使用します。
主なメリット：柔軟な処理ロジック。
詳細な変換：複雑なカラムマッピング、データフィルタリング、定数の割り当て、関数ベースの変換、さらには AI を活用した処理をサポートします。
異種ソースの統合：API やログファイルなどの非標準データソースに最適です。
主な制限事項：大規模化時のコストが高い。
構成オーバーヘッドが大きい：多数のテーブルを同期する場合、タスクを 1 つずつ構成・保守する手間がかかります。
リソース消費量が多い：各タスクは個別にスケジュールされます。100 個の単一テーブルタスクのリソース消費量は、1 個のデータベース全体タスクと比べて非常に大きくなります。
単一テーブルバッチソリューション：単一テーブルバッチ同期タスクの構成
2. データベース全体バッチを選択
多数の同種テーブルをある場所から別の場所へ効率的に移行する必要がある場合に使用します。
主なメリット：運用保守効率が高く、コスト効率に優れる。
高効率：数百のテーブルを一度に構成でき、オブジェクトの自動マッチングにより開発効率が大幅に向上します。
コスト効率：リソースは全体としてスケジュールおよび最適化され、コストを非常に抑えることができます。たとえば、1 個のデータベース全体タスクと 100 個の単一テーブルタスクでは、それぞれ 2 CU と 100 CU を消費する可能性があります。
代表的なユースケース：データウェアハウスの ODS レイヤー構築、定期的なデータベースバックアップ、クラウドへのデータ移行。
主な制限事項：処理ロジックが限定的。
主にデータレプリケーション向けであり、個々のテーブルに対する複雑な変換ロジックはサポートしていません。
データベース全体バッチソリューション：データベース全体バッチ同期タスクの構成。
2. リアルタイム同期ソリューション（秒～分単位）の選択
リアルタイムソリューションは、リアルタイム分析やビジネス応答をサポートするために、ソース側でリアルタイムのデータ変更（挿入、更新、削除）をキャプチャする必要があるシナリオに適しています。
重要な前提条件：ソースが変更データキャプチャ（CDC）をサポートしているか、メッセージキューである必要があります。たとえば、MySQL の場合は Binlog を有効にする必要があります。または、ソースが Kafka インスタンスである必要があります。
単一テーブルリアルタイムまたはデータベース全体リアルタイムを選択
選択ロジックはバッチソリューションと同様です。
単一テーブルリアルタイム：1 つのコアテーブルからのリアルタイム変更ストリームに対して複雑な処理が必要なシナリオに適しています。
データベース全体リアルタイム：リアルタイムデータウェアハウスの構築、リアルタイムデータベースディザスタリカバリの実装、リアルタイムデータレイクとの接続などに主流の選択肢です。このオプションは、効率性とコスト効率の面でも大きなメリットがあります。
リアルタイムソリューション： 単一テーブルリアルタイム同期タスクの構成、データベース全体リアルタイム同期タスクの構成
3. 特殊なシナリオ：リアルタイム CDC データを追記専用のターゲットテーブルに書き込む
背景情報：リアルタイム同期によってキャプチャされた CDC データには、Insert、Update、Delete の 3 種類の操作が含まれます。MaxCompute の Delta Table 以外のタイプなど、物理レベルで Update/Delete 操作をネイティブにサポートしない追記専用ストレージシステムの場合、CDC ストリームを直接書き込むとデータ状態に不整合が生じます（たとえば、削除操作が反映されません）。
DataWorks のソリューション：Base + Log モード
このソリューションでは、データベース全体完全＋増分同期タスクを使用し、ターゲット側に
Base テーブル（完全スナップショット）とLog テーブル（増分ログ）を作成することでこの問題を解決します。仕組み：CDC データストリームはリアルタイムで
Log テーブルに書き込まれます。その後、T+1 でシステムが自動的にタスクをスケジュールし、Log テーブルの変更内容をBase テーブルに マージ して最新の完全スナップショットを生成します。このソリューションの適時性は「増分データは数分以内にログテーブルに書き込まれ、最終状態は T+1 でマージされて確認可能」となります。これにより、リアルタイムデータキャプチャとオフラインデータウェアハウス向けの結果整合性を両立しています。
推奨ソリューション：データベース全体完全＋増分同期タスクの構成。
データソースの読み書き機能
データソース | 単一テーブルバッチ | 単一テーブルリアルタイム | データベース全体バッチ | データベース全体リアルタイム | データベース全体完全＋増分同期 |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 読み取り/書き込み | 読み取り | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
Elasticsearch | 読み取り/書き込み | 書き込み | 書き込み | 書き込み | - |
読み取り/書き込み | - | - | - | - | |
GBase8a | 読み取り/書き込み | - | - | - | - |
HBase | hbase 読み取り/書き込み HBase 20xsql 読み取り HBase 11xsql 書き込み | - | - | - | - |
読み取り/書き込み | - | - | - | - | |
Hive | 読み取り/書き込み | - | 読み取り/書き込み | - | - |
読み取り/書き込み | 読み取り/書き込み | 読み取り/書き込み | 書き込み | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | - | 書き込み | - | |
読み取り/書き込み | 読み取り | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | 書き込み | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
書き込み | - | - | - | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
Vertica | 読み取り/書き込み | - | - | - | - |
読み取り | - | - | - | - |
参考資料
以下は、Data Integration の基本的なドキュメントのリストです。すぐに始めることができます。
データソースの構成については、「データソースの構成」をご参照ください。
同期タスクの構成については、以下をご参照ください。
より実践的なシナリオについては、以下をご参照ください。
データ同期に関する一般的な問題については、「データ同期に関するよくある質問」をご参照ください。