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