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