すべてのプロダクト
Search
ドキュメントセンター

DataWorks:サポートされているデータソースと同期ソリューション

最終更新日:Sep 19, 2025

DataWorks の Data Integration は、MySQL、MaxCompute、Hologres、Kafka などの複数のデータソース間でシームレスなデータ同期を可能にします。Data Integration は、バッチ ETL、秒レベルの待機時間でのリアルタイムデータレプリケーション、データベース全体の移行などのユースケース向けに、バッチ同期、リアルタイムデータ同期、およびデータベース全体の移行ソリューションを提供します。

同期ソリューション

ソリューション

ソース

宛先

待機時間

ユースケース

単一テーブル同期 (バッチ)

単一テーブル

単一テーブルまたはパーティション

日次バッチまたは定期的同期

定期的完全または増分同期

シャーディングされたデータベースとテーブルの同期 (バッチ)

同一のスキーマを共有する複数のテーブル

単一テーブルまたはパーティション

日次またはカスタム間隔

定期的完全、定期的増分

単一テーブル同期 (リアルタイム)

単一テーブル

単一テーブルまたはパーティション

数分または数秒

リアルタイム増分 (CDC)

シャーディングされたデータベースとテーブルの同期 (リアルタイム)

複数の論理テーブル (物理テーブルから集約)

1 つまたは複数のテーブル

数分または数秒

完全 + リアルタイム増分 (CDC)

データベース全体の同期 (バッチ)

データベース全体または複数のテーブル

複数のテーブルとそのパーティション

1 回限りまたは定期的

1 回限り/定期的完全、1 回限り/定期的増分、1 回限り完全 + 定期的増分

データベース全体の同期 (リアルタイム)

データベース全体または複数のテーブル

複数のテーブルとそのパーティション

数分または数秒

完全 + リアルタイム増分 (CDC)

データベース全体の完全および増分同期

(ニアリアルタイム)

データベース全体または複数のテーブル

複数のテーブルとそのパーティション

  • 初期ロード: 完全バッチ処理

  • 継続的な更新: 日次増分同期

完全 + リアルタイム増分 (CDC)

推奨される同期ソリューション

これらの主要な要因に基づいて、データ同期アプローチを選択してください:

  1. データの鮮度の要件: バッチまたはリアルタイム。

  2. データの規模と複雑さ: 同期するテーブルの数とその処理ロジック。

これらの要因に基づき、バッチとリアルタイムの 2 つの主要なカテゴリの同期ソリューションを推奨します。

1. バッチ同期ソリューション (日次バッチまたは定期的同期)

このソリューションは、データの適時性が高くない (たとえば、日次バッチ) ユースケースや、定期的なバッチ処理を伴うユースケースに適しています。

重要

増分同期には、タイムスタンプ列 (last_modified) や自動増分 ID など、データの変更を追跡するためのフィールドが必要です。このようなフィールドがない場合は、代わりに定期的に完全同期を実行してください。

a. 「単一テーブル同期 (バッチ)」を選択

限られた数の多様なデータソースに対するカスタム処理ロジックに最適です。

  • 主な利点: 柔軟な処理ロジック。

    • 高度な変換: 複雑なフィールドマッピング、フィルタリング、エンリッチメント、AI を活用した処理を可能にします。

    • 異種ソースの統合: API やログファイルなどの非標準データソースを処理するための最良の選択肢です。

  • 主な制限: スケールアップにコストがかかる。

    • 構成のオーバーヘッド: 大規模になると、個々のタスクの管理にコストがかかります。

    • 高いリソース消費: 各タスクは独立してスケジュールされます。100 個の独立したテーブルを同期するリソース消費は、1 つのデータベース全体のタスクのリソース消費よりもはるかに大きくなります。

関連情報: 単一テーブルのオフライン同期タスク
b. 「データベース全体の同期 (バッチ)」を選択

システム間で大量の同種テーブルを効率的に移行します。

  • 主な利点: 高い運用効率と低コスト。

    • 効率的: 自動オブジェクトマッチングにより、一度に数百のテーブルを構成でき、開発効率が大幅に向上します。

    • 費用対効果: 統合されたスケジューリングによりリソースが最適化され、非常に低いコストが実現します (たとえば、1 つのデータベース全体のタスクは 2 CU を消費するのに対し、同等の単一テーブルタスクは 100 CU を消費する場合があります)。

    • 典型的なシナリオ: データウェアハウスの ODS レイヤーの構築、定期的なデータベースバックアップ、データクラウド移行。

  • 主な制限: 単純な処理ロジック。

    • 主にレプリケーション用に設計されており、個々のテーブルの複雑な変換ロジックはサポートしていません。

推奨ソリューション: オフラインのデータベース全体の同期タスク。

2. リアルタイム同期ソリューション (サブミニットの待機時間)

リアルタイムソリューションは、ソースからのリアルタイムのデータ変更 (挿入、削除、更新) をキャプチャして、リアルタイム分析と迅速な意思決定をサポートする必要があるアプリケーションに適しています。

重要

ソースは Change Data Capture (CDC) をサポートしているか、メッセージキューである必要があります。たとえば、MySQL はバイナリロギング (Binlog) を必要とし、Kafka はネイティブのメッセージキューとして機能します。

「単一テーブルリアルタイム」または「データベース全体のリアルタイム」を選択
  • 単一テーブルリアルタイム: 単一テーブルからのリアルタイム変更ストリームの複雑な処理を必要とする場合に適しています。

  • データベース全体のリアルタイム: リアルタイムのデータウェアハウスとデータレイクを構築し、リアルタイムのデータベースディザスタリカバリを実装するための標準ソリューションです。効率と費用対効果の面で大きな利点があります。

推奨ソリューション:リアルタイム単一テーブル同期タスク; リアルタイムデータベース同期タスク

3. 特殊なケース: リアルタイムデータを追記専用テーブルに同期する

重要

リアルタイム同期は、挿入、更新、削除を含む CDC イベントをキャプチャします。物理的な Update および Delete 操作をネイティブにサポートしない MaxCompute の非 Delta テーブルのような追記専用ストレージシステムの場合、生の CDC ストリームを直接書き込むと、データの不整合が発生します (たとえば、削除操作は無視されます)。

  • DataWorks ソリューション: Base + Log テーブル

    • このソリューションは、宛先に Base table (完全スナップショット) と Log table (増分変更) を作成することで問題を解決します。

    • 書き込みメソッド: CDC データストリームをリアルタイムで Log table に書き込みます。毎日、システムは Log table からの変更を Base tableマージするタスクを自動的にスケジュールし、最新の完全スナップショットを生成します。このアプローチにより、変更が数分以内に増分テーブルに書き込まれ、毎日 Base テーブルにマージされることが保証されます。

推奨ソリューション: 完全および増分 (ニアリアルタイム) 同期タスク

データソースの読み取り/書き込み機能

データソース

単一テーブル同期 (バッチ)

単一テーブル同期 (リアルタイム)

データベース全体の同期 (バッチ)

データベース全体の同期 (リアルタイム)

データベース全体の完全および増分 (ニアリアルタイム)

Amazon S3 データソース

読み取り/書き込み

-

-

-

-

Amazon Redshift データソース

読み取り/書き込み

-

-

-

-

AnalyticDB for MySQL 2.0 データソース

読み取り/書き込み

-

-

-

-

AnalyticDB for MySQL 3.0 データソース

読み取り/書き込み

書き込み

読み取り

書き込み

-

AnalyticDB for PostgreSQL データソース

読み取り/書き込み

-

読み取り

-

-

ApsaraDB for OceanBase データソース

読み取り/書き込み

-

-

読み取り

読み取り

Azure Blob Storage データソース

読み取り

-

-

-

-

BigQuery データソース

読み取り

-

-

-

-

ClickHouse データソース

読み取り/書き込み

-

-

-

-

DataHub データソース

読み取り/書き込み

読み取り/書き込み

-

書き込み

-

DLF データソース

書き込み

書き込み

-

書き込み

-

Db2 データソース

読み取り/書き込み

-

読み取り

-

-

Doris データソース

読み取り/書き込み

書き込み

-

-

-

DM データソース

読み取り/書き込み

-

読み取り

-

-

DRDS (PolarDB-X 1.0) データソース

読み取り/書き込み

-

読み取り

-

-

Elasticsearch

読み取り/書き込み

書き込み

書き込み

書き込み

-

FTP データソース

読み取り/書き込み

-

-

-

-

GBase8a

読み取り/書き込み

-

-

-

-

HBase

  • HBase: 読み取り/書き込み

  • HBase 2.0.x SQL: 読み取り

  • HBase 1.1.x SQL: 書き込み

-

-

-

-

HDFS データソース

読み取り/書き込み

-

-

-

-

Hive

読み取り/書き込み

-

書き込み

-

-

Hologres データソース

読み取り/書き込み

読み取り/書き込み

読み取り/書き込み

書き込み

-

HttpFile データソース

読み取り

-

-

-

-

Kafka データソース

読み取り/書き込み

読み取り/書き込み

-

書き込み

-

KingbaseES データソース

読み取り/書き込み

-

-

-

-

Lindorm データソース

読み取り/書き込み

-

-

-

-

Simple Log Service データソース

読み取り/書き込み

読み取り

-

-

-

MaxCompute データソース

読み取り/書き込み

書き込み

書き込み

-

書き込み

MariaDB データソース

読み取り/書き込み

-

-

-

-

Maxgraph データソース

書き込み

-

-

-

-

Memcache データソース

書き込み

-

-

-

-

MetaQ データソース

読み取り

-

-

-

-

Milvus データソース

書き込み

-

-

-

-

MongoDB データソース

読み取り/書き込み

-

-

読み取り

-

MySQL データソース

読み取り/書き込み

読み取り

読み取り

読み取り

読み取り

OpenSearch データソース

書き込み

-

-

-

-

Oracle データソース

読み取り/書き込み

読み取り

読み取り

読み取り

読み取り

OSS データソース

読み取り/書き込み

書き込み

書き込み

-

-

OSS-HDFS データソース

読み取り/書き込み

書き込み

-

-

-

PolarDB データソース

読み取り/書き込み

読み取り

読み取り

読み取り

読み取り

PolarDB-X 2.0 データソース

読み取り/書き込み

-

読み取り

読み取り

-

PostgreSQL データソース

読み取り/書き込み

-

読み取り

読み取り

-

Redis データソース

書き込み

-

-

-

-

RestAPI (HTTP) データソース

読み取り/書き込み

-

-

-

-

Salesforce データソース

読み取り/書き込み

-

-

-

-

SAP HANA データソース

読み取り/書き込み

-

-

-

-

Sensors Data データソース

書き込み

-

-

-

-

StarRocks データソース

読み取り/書き込み

書き込み

書き込み

-

-

SQL Server データソース

読み取り/書き込み

-

読み取り

-

-

Tablestore データソース

読み取り/書き込み

書き込み

-

-

-

Tablestore Stream データソース

読み取り/書き込み

-

-

-

-

TiDB データソース

読み取り/書き込み

-

-

-

-

TSDB データソース

書き込み

-

-

-

-

Vertica

読み取り/書き込み

-

-

-

-

TOS データソース

読み取り

-

-

-

-

ユースケース

リファレンス

以下の Data Integration ドキュメントは、すぐに開始するのに役立ちます。