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 回 (バッチ) か、秒単位または分単位のリアルタイム更新 (リアルタイム) か。
同期の規模と複雑さ： 同期する必要があるテーブルの数と、テーブル間で処理ロジックが統一されているかどうか (単一テーブル vs. データベース全体) 。
これらの考慮事項に基づき、Data Integration はバッチとリアルタイムの 2 つのカテゴリの同期ソリューションを提供します。
1. バッチ同期ソリューションの選択 (T+1/定期的)
バッチソリューションは、T+1 の定期的処理など、適時性の要件が低いシナリオに適しています。
重要な前提条件: バッチ増分同期を実装するには、ソーステーブルに、gmt_modified のようなタイムスタンプや自動インクリメント ID など、増分データを識別できる列が含まれている必要があります。このような列が利用できない場合、定期的な完全同期を行うしかありません。
1. 単一テーブルバッチの選択
少数の主要な異種データソースをきめ細かく処理する必要がある場合に使用します。
主な利点： 柔軟な処理ロジック。
きめ細かい変換： 複雑なカラムマッピング、データフィルタリング、定数割り当て、関数ベースの変換、さらには AI 支援処理をサポートします。
異種ソースの統合： API やログファイルなどの非標準データソースに最適です。
主な制限事項： 大規模な場合の高コスト。
高い設定のオーバーヘッド： 多数のテーブルを同期する場合、タスクを 1 つずつ設定および維持するには、多大な労力がかかります。
高いリソース消費： 各タスクは独立してスケジュールされます。100 個の単一テーブルタスクのリソース消費は、1 つのデータベース全体のタスクのリソース消費をはるかに上回ります。
単一テーブルバッチソリューション： 単一テーブルバッチ同期タスクの設定
2. データベース全体のバッチの選択
多数の同種テーブルをある場所から別の場所に効率的に移行する必要がある場合に使用します。
主な利点： 高い運用保守効率と低コスト。
高効率： 自動オブジェクトマッチングにより、一度に数百のテーブルを設定でき、開発効率が大幅に向上します。
コスト効率： リソースは全体的にスケジュールおよび最適化され、非常に低コストです。たとえば、1 つのデータベース全体のタスクと 100 個の単一テーブルタスクを比較すると、消費する CU は 2 CU 対 100 CU となる場合があります。
典型的なシナリオ： データウェアハウスの ODS レイヤーの構築、定期的なデータベースバックアップ、クラウドへのデータ移行。
主な制限事項： 限られた処理ロジック。
主にデータレプリケーション用に設計されており、個々のテーブルに対する複雑な変換ロジックはサポートしていません。
データベース全体のバッチソリューション： データベース全体のバッチ同期タスクの設定。
2. リアルタイム同期ソリューションの選択 (秒から分)
リアルタイムソリューションは、ソース側でのデータ変更 (Insert、Update、Delete) をキャプチャして、リアルタイムの分析とビジネス上の意思決定をサポートします。
重要な前提条件： ソースは変更データキャプチャ (CDC) をサポートしているか、メッセージキューである必要があります。たとえば、MySQL では Binlog を有効にする必要があるか、ソースが Kafka インスタンスである必要があります。
単一テーブルリアルタイムまたはデータベース全体のリアルタイムの選択
選択ロジックはバッチソリューションのロジックと似ています。
単一テーブルリアルタイム： 単一の主要テーブルからのリアルタイム変更ストリームの複雑な処理を必要とするシナリオに適しています。
データベース全体のリアルタイム： リアルタイムデータウェアハウスの構築、リアルタイムのデータベース災害復旧、リアルタイムのデータレイクへの取り込みに最適な選択肢です。また、効率とコストの面でも大きな利点があります。
リアルタイムソリューション： 単一テーブルリアルタイム同期タスクの設定、データベース全体のリアルタイム同期タスクの設定
3. 特殊なシナリオ： リアルタイム CDC データの追記専用ターゲットテーブルへの書き込み
背景: リアルタイム同期によってキャプチャされた CDC データには、Insert、Update、Delete の 3 種類の操作が含まれます。MaxCompute の Delta テーブル以外のタイプのように、物理レベルで Update/Delete 操作をネイティブにサポートしていない追記専用ストレージシステムに CDC ストリームを直接書き込むと、データ状態の不整合 (たとえば、削除操作を反映できないなど) が発生します。
DataWorks ソリューション： Base + Log モード
このソリューションは、データベース全体の完全および増分タスクを使用し、ターゲットに
Base table（完全スナップショット）とLog table（増分ログ）を作成することで、この問題を解決します。仕組み: CDC データストリームは、
Log tableにリアルタイムで書き込まれます。次に、システムは T+1 ベースでタスクを自動的にスケジュールします。このタスクは、Log tableからの変更をBase tableに マージ して、最新の完全なスナップショットを生成します。このソリューションのタイムリネスは、増分データが数分以内にログテーブルに書き込まれ、T+1 の時点で最終状態がマージされて表示可能になるという点にあります。これにより、オフラインデータウェアハウス向けに、リアルタイムのデータキャプチャと結果整合性のバランスが取られます。
推奨ソリューション： データベース全体のフル + 増分同期タスクの設定。
データソースの読み取り/書き込み機能
データソース | 単一テーブルバッチ | 単一テーブルリアルタイム | データベース全体のバッチ | データベース全体のリアルタイム | データベース全体のフル+増分 |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 読み取り/書き込み | 読み取り | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
Elasticsearch | 読み取り/書き込み | 書き込み | 書き込み | 書き込み | - |
読み取り/書き込み | - | - | - | - | |
GBase8a | 読み取り/書き込み | - | - | - | - |
HBase | HBase 読み取り/書き込み HBase 20xsql 読み取り HBase 11xsql 書き込み | - | - | - | - |
読み取り/書き込み | - | - | - | - | |
Hive | 読み取り/書き込み | - | 読み取り/書き込み | - | - |
読み取り/書き込み | 読み取り/書き込み | 読み取り/書き込み | 書き込み | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | - | 書き込み | - | |
読み取り/書き込み | 読み取り | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | 書き込み | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
書き込み | - | - | - | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
- | - | 書き込み | - | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | - | - | - | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
Vertica | 読み取り/書き込み | - | - | - | - |
読み取り | - | - | - | - |
関連ドキュメント
以下の Data Integration ドキュメントを参照して開始してください。
データソースの設定については、データソースの設定をご参照ください。
同期タスクの設定については、以下をご参照ください。
より実践的なシナリオについては、以下をご参照ください。
データ同期に関する一般的な問題については、データ同期に関するよくある質問をご参照ください。