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. データベース全体バッチの選択
多数の同種テーブルを効率的に移行する必要がある場合に使用します。
主な利点：高い O&M 効率と低コスト。
高い効率：自動オブジェクトマッチングにより、一度に数百のテーブルを設定でき、開発効率を大幅に向上させます。
高いコスト効率：リソースは全体としてスケジュール・最適化されるため、非常に低コストです。たとえば、1 つのデータベース全体タスクと 100 の単一テーブルタスクを比較した場合、リソース消費は 2 CU 対 100 CU となることがあります。
典型的なシナリオ：データウェアハウスの ODS 層の構築、定期的なデータベースバックアップ、クラウドへのデータ移行。
主な制限事項：限られた処理ロジック。
主にデータレプリケーション用に設計されており、個々のテーブルに対する複雑な変換ロジックはサポートしていません。
データベース全体バッチソリューション：データベース全体バッチ同期タスクの設定。
2. リアルタイム同期ソリューションの選択 (秒〜分レベル)
リアルタイムソリューションは、ソースでのデータ変更 (挿入、更新、削除) をキャプチャし、リアルタイムの分析とビジネス上の意思決定をサポートします。
重要な前提条件：ソースが変更データキャプチャ (CDC) をサポートしているか、メッセージキューである必要があります。たとえば、MySQL で Binlog を有効にしたり、ソースが Kafka インスタンスであったりする必要があります。
単一テーブルリアルタイムまたはデータベース全体リアルタイムの選択
選択ロジックはバッチソリューションの場合と似ています。
単一テーブルリアルタイム：単一の主要テーブルからのリアルタイム変更ストリームの複雑な処理を必要とするシナリオに適しています。
データベース全体リアルタイム：リアルタイムのデータウェアハウスの構築、リアルタイムのデータベースディザスタリカバリ、リアルタイムのデータレイク取り込みに推奨される選択肢です。また、効率とコストの面でも大きな利点があります。
リアルタイムソリューション： 単一テーブルリアルタイム同期タスクの設定、データベース全体リアルタイム同期タスクの設定
3. 特殊なシナリオ：リアルタイム CDC データの追記専用ターゲットテーブルへの書き込み
背景：リアルタイム同期によってキャプチャされた CDC データには、挿入、更新、削除 の 3 種類の操作が含まれます。MaxCompute の Delta Table 以外のテーブルタイプなど、物理レベルで 更新/削除 操作をネイティブにサポートしていない追記専用ストレージシステムの場合、CDC ストリームを直接書き込むとデータ状態の不整合が発生します (たとえば、削除操作が反映されないなど)。
DataWorks ソリューション：Base + Log モード
このソリューションは、データベース全体の全量 + 増分タスクを使用し、ターゲットに
ベーステーブル(全量スナップショット) とログテーブル(増分ログ) を作成することで、この問題を解決します。仕組み：CDC データストリームは、リアルタイムで
Log tableに書き込まれます。その後、システムは T+1 ベースでタスクを自動的にスケジュールし、Log tableからの変更をBase tableに マージ して最新の完全なスナップショットを生成します。このソリューションのタイムリネスは、「増分データが数分以内に Log table に書き込まれ、最終的な状態が T+1 でマージされて表示可能になる」というものです。これにより、リアルタイムのデータキャプチャと、オフラインデータウェアハウスの結果整合性のバランスが取れています。
推奨ソリューション：データベース全体の全量 + 増分タスクの設定。
データソースの読み取り/書き込み機能
データソース | 単一テーブルバッチ | 単一テーブルリアルタイム | 全データベースバッチ | 全データベースリアルタイム | 全データベース (全量 + 増分) |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | 読み取り/書き込み | 読み取り | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | - | 読み取り | - | - | |
Elasticsearch | 読み取り/書き込み | 書き込み | 書き込み | 書き込み | - |
読み取り/書き込み | - | - | - | - | |
GBase8a | 読み取り/書き込み | - | - | - | - |
HBase | hbase 読み取り/書き込み HBase 20xsql 読み取り HBase 11xsql 書き込み | - | - | - | - |
読み取り/書き込み | - | - | - | - | |
Hive | 読み取り/書き込み | - | 読み取り/書き込み | - | - |
読み取り/書き込み | 読み取り/書き込み | 読み取り/書き込み | 書き込み | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | 読み取り/書き込み | - | 書き込み | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | - | 書き込み | - | |
読み取り/書き込み | 読み取り | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | 書き込み | |
読み取り/書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
書き込み | - | - | - | - | |
読み取り | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
書き込み | - | - | - | - | |
読み取り/書き込み | 読み取り | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 書き込み | 書き込み | - | |
- | - | 書き込み | - | - | |
読み取り/書き込み | - | 読み取り | 読み取り | 読み取り | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
読み取り/書き込み | - | 読み取り | 読み取り | - | |
書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | - | - | - | - | |
読み取り/書き込み | 書き込み | 書き込み | 書き込み | - | |
読み取り/書き込み | - | 読み取り | - | - | |
読み取り/書き込み | 書き込み | - | - | - | |
読み取り | - | - | - | - | |
書き込み | - | - | - | - | |
Vertica | 読み取り/書き込み | - | - | - | - |
読み取り | - | - | - | - |
参考資料
Data Integration の利用を開始するには、次のドキュメントをご参照ください。
データソースの設定については、「データソースを設定する」をご参照ください。
同期タスクの設定については、次をご参照ください：
より実践的なシナリオについては、次をご参照ください：
データ同期に関するよくある問題については、「データ同期に関するよくある質問」をご参照ください。