DataWorks Data Integration は、MySQL、MaxCompute、Hologres、Kafka などのソース間でデータを同期します。バッチ、リアルタイム、データベース全体の同期をサポートし、T+1 ETL から秒レベルのリアルタイムレプリケーションまでのシナリオに対応します。
同期ソリューション
タイプ | ソースの粒度 | ターゲットの粒度 | 適時性 | 同期シナリオ |
単一テーブルバッチ | 単一テーブル | 単一テーブルまたはパーティション | T+1 または定期的 | 定期的フル、定期的インクリメンタル |
シャードデータベース/テーブルバッチ | 同一構造の複数テーブル | 単一テーブルまたはパーティション | T+1 または定期的 | 定期的フル、定期的インクリメンタル |
単一テーブルリアルタイム | 単一テーブル | 単一テーブルまたはパーティション | 数秒から数分 | リアルタイムインクリメンタル (CDC) |
データベース全体のバッチ | データベース全体または複数テーブル | 対応する複数テーブルとそのパーティション | 1回限りまたは定期的 | 1回限り/定期的フル、1回限り/定期的インクリメンタル、1回限りフル + 定期的インクリメンタル |
データベース全体のリアルタイム | データベース全体または複数テーブル | 対応する複数テーブルとそのパーティション | 数秒から数分 | フル + リアルタイムインクリメンタル (CDC) |
データベース全体のフル + インクリメンタル | データベース全体または複数テーブル | 対応する複数テーブルとそのパーティション | 初回フルロード：バッチ処理 以降の増分：T+1 | フル + 定期的インクリメンタル |
推奨同期ソリューション
データ同期ソリューションを選択する際は、次の 2 つの重要な点を考慮してください。
適時性の要件：業務でデータを同期する頻度 — 1 日 1 回 (バッチ) か、秒単位または分単位のリアルタイム更新 (リアルタイム) か。
同期の規模と複雑さ：同期が必要なテーブルの数と、テーブル間で処理ロジックが統一されているか (単一テーブルかデータベース全体か)。
これらの考慮事項に基づき、Data Integration ではバッチとリアルタイムの 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 インスタンスである必要もあります。
単一テーブルリアルタイムまたはデータベース全体リアルタイムの選択
選択ロジックはバッチソリューションと同様です。
単一テーブルリアルタイム：単一のコアのテーブルからのリアルタイム変更ストリームの複雑な処理が必要なシナリオに適しています。
データベース全体のリアルタイム：リアルタイムデータウェアハウスの構築、リアルタイムデータベースディザスタリカバリ、リアルタイムデータレイクへの取り込みに最適な選択肢です。効率とコストの面でも大きな利点があります。
リアルタイムソリューション： 単一テーブルリアルタイム同期タスクの設定、データベース全体のリアルタイム同期タスクの設定
3. 特殊なシナリオ：追記専用ターゲットテーブルへのリアルタイム CDC データの書き込み
背景：リアルタイム同期によってキャプチャされる CDC データには、Insert、Update、Delete の 3 種類の操作が含まれます。MaxCompute の非 Delta Table タイプなど、物理レベルで Update/Delete 操作をネイティブにサポートしない追記専用ストレージシステムの場合、CDC ストリームを直接書き込むと、データ状態の不整合が発生します (たとえば、削除操作が反映されません)。
DataWorks ソリューション：ベース + ログモード
このソリューションでは、データベース全体の全量 + 増分タスクを使用し、ターゲットに
ベーステーブル(フルスナップショット) とログテーブル(増分ログ) を作成することで、この問題を解決します。仕組み: CDC データストリームは、リアルタイムで
Log tableに書き込まれます。次に、T+1 ベースで、システムはタスクを自動的にスケジュールし、Log tableからBase tableに変更をマージして、最新の完全なスナップショットを生成します。このソリューションのタイムリネスは、「増分データが数分以内に Log テーブルに書き込まれ、最終状態は T+1 でマージされて表示可能になる」というものです。このソリューションは、オフラインデータウェアハウス向けのリアルタイムデータキャプチャと結果整合性のバランスを取ります。
推奨ソリューション： データベース全体の完全・増分同期タスクの設定
データソースの読み取り/書き込み機能
データソース | 単一テーブルバッチ | 単一テーブルリアルタイム | データベース全体のバッチ | データベース全体のリアルタイム | データベース全体のフル + 増分 |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 読み取り/書き込み | 読み取り | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
Elasticsearch | 読み取り/書き込み | 書き込み | 書き込み | 書き込み | - |
読み取り/書き込み | - | - | - | - | |
GBase8a | 読み取り/書き込み | - | - | - | - |
HBase | hbase 読み取り/書き込み HBase 読み取り/書き込み HBase 11xsql 書き込み | - | - | - | - |
読み取り/書き込み | - | - | - | - | |
Hive | 読み取り/書き込み | - | 読み取り/書き込み | - | - |
読み取り/書き込み | 読み取り/書き込み | 読み取り/書き込み | 書き込み | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | - | 書き込み | - | |
読み取り/書き込み | 読み取り | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | 書き込み | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
書き込み | - | - | - | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
- | - | 書き込み | - | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
Vertica | 読み取り/書き込み | - | - | - | - |
読み取り | - | - | - | - |
関連ドキュメント
Data Integration の使用を開始するには、以下のドキュメントをご参照ください。
データソースの設定については、「データソースの設定」をご参照ください。
同期タスクの設定については、以下をご参照ください：
より実践的なシナリオについては、以下をご参照ください：
データ同期に関するよくある問題については、「データ同期に関するよくある質問」をご参照ください。