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

DataWorks:完全および増分同期タスクの設定

最終更新日:Mar 11, 2026

Data Integration を使用すると、ApsaraDB for OceanBase、MySQL、Oracle、PolarDB などのソースから MaxCompute へ、データベース全体の完全および増分同期を実行できます。このプロセスは、初回の完全なデータ移行と、継続的な増分データのリアルタイム同期を組み合わせたものです。増分データは、翌日 (T+1) に送信先にマージされます。このトピックでは、MySQL から MaxCompute への同期を例に、完全および増分同期タスクの作成方法を説明します。

仕組み

完全および増分同期タスクは、統一されたプロセスを使用して、初回の既存データの完全ロードと、その後の増分データの継続的な同期を実行します。タスクが開始されると、システムは自動的にオフラインおよびリアルタイムのサブタスクを作成・調整し、データを送信先のテーブル (ベーステーブル) にマージします。

主要なプロセスは、次の 3 つのフェーズで構成されます。

  1. 初回の完全ロード:タスクが開始されると、まずバッチ同期タスクが実行されます。このタスクは、ソースデータベース内のすべてのテーブルのテーブル構造と既存データを、MaxCompute の送信先ベーステーブルに移行します。初回の完全ロードが完了すると、このバッチ同期タスクは一時停止します。

  2. 増分データの同期:完全移行後、システムはリアルタイム同期タスクを開始します。このタスクは、ソースデータベース (例えば MySQL のバイナリログ (binlog)) からの増分データ変更 (Insert、Update、Delete 操作) を継続的にキャプチャします。その後、これらの変更をほぼリアルタイムで MaxCompute の一時的なログテーブルに書き込みます。

  3. 定期的なマージ:システムは毎日 (T+1) 自動的にマージタスクを実行します。このタスクは、前日 (T) にログテーブルに蓄積された増分データを、ベーステーブルの完全データとマージします。このプロセスにより、T 日のデータの最新の完全スナップショットが生成され、ベーステーブルの新しいパーティションに書き込まれます。マージタスクは 1 日に 1 回実行されます。

次の図は、パーティションテーブルへの書き込み時のデータフローを示しています。

image

このタスクには、次の特徴があります。

  • 多対多または多対一のテーブルマッピング:複数のソーステーブルを、対応する複数の送信先テーブルに同期できます。また、マッピングルールを使用して、複数のソーステーブルから単一の送信先テーブルにデータをマージすることもできます。

  • タスクの構成:完全および増分同期タスクは、初回の完全ロード用のバッチ同期サブタスク、増分データ用のリアルタイム同期サブタスク、およびデータ統合用のマージタスクで構成されます。

  • 送信先テーブルのサポート:MaxCompute のパーティションテーブルと非パーティション化テーブルの両方にデータを書き込むことができます。

制限事項

  • リソース要件:このタスクには Serverless リソースグループ が必要です。インスタンスベースの同期の場合、最小リソース仕様は、Data Integration 専用リソースグループが 8 コア 16 GB、Serverless リソースグループが 2 CU です。

  • ネットワーク接続:Data Integration リソースグループと、ソース (例:MySQL) および送信先 (例:MaxCompute) の両方のデータソースとの間にネットワーク接続が確保されていることを確認してください。詳細については、「ネットワーク接続ソリューション」をご参照ください。

  • リージョンの制限:同期は、現在の DataWorks ワークスペースと同じリージョンにある、ユーザーが作成した MaxCompute データソースに対してのみサポートされます。ユーザーが作成した MaxCompute データソースを使用する場合でも、DataWorks ワークスペースのデータ開発セクションで MaxCompute 計算リソースをバインドする必要があります。そうしないと、MaxCompute SQL ノードを作成できず、完全同期の 'done' ノードの作成も失敗します。

  • スケジューリングリソースグループの制限:タスクは、設定された Serverless リソースグループ をスケジューリングリソースグループとして使用します。

  • 送信先テーブルタイプの制限:MaxCompute 外部テーブルにデータを同期することはできません。

注意事項

  • プライマリキーの要件:プライマリキーのないテーブルは同期できません。プライマリキーがないテーブルについては、設定時に Specify Primary Key オプションを使用して、1 つ以上の列をビジネスプライマリキーとして手動で指定する必要があります。

  • データ可視性の遅延:MaxCompute への完全および増分同期タスクを設定した後、同日にクエリできるのは既存データのみです。増分データは、翌日にマージタスクが完了した後にのみ MaxCompute でクエリ可能になります。詳細については、「仕組み」セクションの定期的なマージの説明をご参照ください。

  • ストレージとライフサイクル:完全および増分同期タスクは、毎日新しい完全パーティションを作成します。過剰なストレージ使用量を防ぐため、同期タスクが自動的に作成する MaxCompute テーブルのデフォルトのライフサイクルは 30 日です。この期間がビジネス要件を満たさない場合は、タスク設定時に対応する MaxCompute テーブル名をクリックしてライフサイクルを変更できます。詳細については、「送信先テーブル構造の編集 (オプション)」をご参照ください。

  • SLA:Data Integration は、データのアップロードとダウンロードに MaxCompute データチャネルを使用します。同期データチャネルのサービスレベルアグリーメント (SLA) の詳細については、「データ転送サービス (アップロード) のシナリオとツール」をご参照ください。MaxCompute データチャネルの SLA に基づいて、技術的な選択を評価してください。

  • binlog 保持ポリシー:リアルタイム同期は、ソース MySQL データベースのバイナリログ (binlog) に依存します。同期の失敗を防ぐために、binlog の保持期間が十分であることを確認してください。タスクが長時間一時停止されたり、失敗後に再試行されたりすると、必要な binlog が消去されている場合に開始位置を見つけられずに失敗することがあります。

課金

  • 完全および増分同期タスクには、完全ロードフェーズのバッチ同期タスク、増分フェーズのリアルタイム同期タスク、および定期マージフェーズの定期タスクが含まれます。これら 3 つのタスクは個別に課金されます。3 つのフェーズすべてで、リソースグループの CU が消費されます。課金の詳細については、「Serverless リソースグループの課金」をご参照ください。定期タスクには、スケジューリング料金も発生します。詳細については、「スケジューリングインスタンス料金」をご参照ください。

  • さらに、MaxCompute への同期プロセスでは、完全データと増分データの定期的なマージが必要であり、これにより MaxCompute 計算リソースが消費されます。これらの料金は MaxCompute によって直接請求され、完全データセットのサイズとマージ頻度に比例します。詳細については、「課金項目と料金」をご参照ください。

操作手順

ステップ 1: 同期タスクの種類の選択

  1. Data Integration ページに移動します。

    DataWorks コンソールにログインします。上部のナビゲーションバーで、目的のリージョンを選択します。左側のナビゲーションウィンドウで、[データ統合] > [データ統合] を選択します。表示されたページで、ドロップダウンリストから目的のワークスペースを選択し、[データ統合へ] をクリックします。

  2. 左側のナビゲーションウィンドウで、Synchronization Task をクリックします。ページの上部で Create Synchronization Task をクリックし、次のパラメーターを設定します。

    • Source TypeMySQL

    • Destination TypeMaxCompute

    • Specific Type: データベース全体の完全および増分

    • Sync ProcedureSchema MigrationIncremental SyncFull Synchronization定期的マージ

ステップ 2: データソースとリソースグループの設定

  1. Source InformationMySQL データソースを選択します。DestinationMaxCompute データソースを選択します。

  2. Running Resources セクションで、同期タスクの Resource Group を選択し、CUResource Group を割り当てます。完全同期と増分同期に別々の CU を設定することで、リソースを正確に制御し、無駄を防ぐことができます。

    説明

    DataWorks は、スケジューリングリソースグループを介して、バッチ同期タスクを Data Integration 実行リソースグループに送信します。その結果、オフラインタスクは実行リソースグループとスケジューリングリソースグループの両方のリソースを消費し、後者にはスケジューリング料金が発生します。

  3. ソースと送信先の両方のデータソースが 接続チェック に合格することを確認します。

ステップ 3: ソーステーブルの選択

[ソーステーブル] エリアで、ソースデータソースから同期するテーブルを選択します。image アイコンをクリックして、テーブルを [選択したテーブル] リストに移動します。

image

テーブルの数が多い場合は、Database FilteringSearch for Tables を使用するか、正規表現を設定して必要なテーブルを選択できます。

ステップ 4: タスク設定の構成

  • ログテーブルの時間範囲:このパラメーターは、送信先パーティションにマージするためにログテーブルからデータをクエリする時間範囲を定義します。

    データ遅延による日をまたぐパーティションエラーを防ぐために、この範囲を少し広げてください。これにより、パーティションのすべてのデータが正しくマージされるようになります。

  • マージタスクのスケジューリング:毎日のマージタスクのスケジュールを設定します。スケジューリングの設定方法の詳細については、「スケジューリング設定」をご参照ください。

  • 定期スケジューリングパラメーター:後でパーティションに値を割り当てるために使用できるスケジューリングパラメーターを設定します。これにより、日付に基づいてパーティションを自動的に作成できます。

  • テーブルパーティション設定:送信先テーブルのパーティションを設定します。パーティション列名や値の割り当て方法などの主要なパラメーターを設定できます。割り当て列には、スケジューリングパラメーターを使用して、日付に基づいてパーティションを自動的に生成できます。

ステップ 5: 送信先テーブルマッピングの設定

このステップでは、ソーステーブルと送信先テーブル間のマッピングルールを定義します。また、プライマリキー、動的パーティション、および DDL/DML 設定のルールを指定して、データの書き込み方法を決定します。

操作

説明

Refresh

システムは選択したソーステーブルを自動的にリストアップします。ただし、送信先テーブルのプロパティを有効にするには、マッピングを更新する必要があります。

  • 一括で同期するテーブルを選択し、[マッピング結果の更新] をクリックします。

  • 送信先テーブル名:送信先テーブル名は、Customize Mapping Rules for Destination Table Names のルールに基づいて自動的に生成されます。デフォルトのフォーマットは ${SourceDatabaseName}_${TableName} です。この名前のテーブルが送信先に存在しない場合、システムは自動的に作成します。

Customize Mapping Rules for Destination Table Names (オプション)

システムにはデフォルトのテーブル命名ルールがあります:${SourceDatabaseName}_${TableName}Customize Mapping Rules for Destination Table Names 列の Edit ボタンをクリックして、カスタムルールを追加できます。

  • ルール名:ルールの名前を定義します。ビジネス目的が明確にわかる名前を使用してください。

  • 送信先テーブル名:image アイコンをクリックし、Manual InputBuilt-in Variable のオプションを組み合わせて、送信先テーブル名を構築できます。変数には、ソースデータソース名、ソースデータベース名、ソーステーブル名が含まれます。

  • 組み込み変数の編集:組み込み変数に文字列変換を適用できます。

この機能は、次のシナリオをサポートします。

  1. 名前にプレフィックスまたはサフィックスを追加する:ソーステーブル名に定数のプレフィックスまたはサフィックスを追加します。

    ルール設定

    結果

    image

    image

  2. 一様な文字列置換を実行する:すべてのソーステーブル名に含まれる文字列 dev_prd_ に置き換えます。

    ルール設定

    結果

    image

    image

  3. 複数のテーブルから単一のテーブルにデータを書き込む。

    ルール設定

    結果

    image

    image

フィールドデータ型のマッピングを編集 (オプション)

システムは、ソースと送信先のフィールドデータ型間にデフォルトのマッピングを提供します。テーブルの右上隅にある Edit Mapping of Field Data Types をクリックして、マッピングをカスタマイズできます。設定後、Apply and Refresh Mapping をクリックします。

データ型のマッピングを編集する際は、変換ルールが正しいことを確認してください。不正なルールは、型変換の失敗、ダーティデータの生成、タスク実行の中断を引き起こす可能性があります。

送信先テーブル構造の編集 (オプション)

システムは、カスタムテーブル名マッピングルールに基づいて、送信先テーブルが存在しない場合は自動的に作成し、同じ名前の既存テーブルがある場合はそれを使用します。

DataWorks は、ソーステーブルの構造に基づいて送信先テーブルの構造を自動的に生成します。ほとんどの場合、手動での介入は不要です。また、次の方法でテーブル構造を変更することもできます。

  • 単一テーブルにフィールドを追加するには、Destination Table Name 列の image.png アイコンをクリックします。

  • フィールドを一括で追加する:同期したいすべてのテーブルを選択し、リストの下部にある Batch Modify > Destination Table Schema - Batch Modify and Add Field を選択します。

  • 列の名前を変更することはできません。

既存のテーブルについては、フィールドの追加のみが可能です。新しいテーブルについては、フィールド、パーティションフィールドの追加、およびテーブルタイプやプロパティの設定ができます。詳細については、UI の編集可能なセクションをご参照ください。

Value assignment

ネイティブフィールドは、ソーステーブルと送信先テーブル間で一致するフィールド名に基づいて自動的にマッピングされます。前のステップで追加した新規フィールドには、手動で値を割り当てる必要があります。これを行うには:

  • 単一テーブルに値を割り当てる:Value assignment 列の Configuration ボタンをクリックして、送信先テーブルのフィールドに値を割り当てます。

  • 一括で値を割り当てる:リストの下部で Batch Modify > Value assignment を選択して、複数の送信先テーブルの同じフィールドに値を割り当てます。

定数または変数を割り当てることができます。Value Type ドロップダウンリストでタイプを切り替えます。次のメソッドがサポートされています。

  • テーブルフィールド

    • 手動割り当てabc${bizdate} のような定数値またはスケジューリングパラメーターを入力します。

    • 変数の選択:システムが提供する変数を選択してフィールド値とします。変数の種類については、UI の説明をご参照ください。

    • ソースフィールド:ソーステーブルのフィールドの値を使用します。フィールド値または時間値のいずれかを使用することを選択できます。

      • フィールド値:ソースフィールドが時間ベースの型でない場合、その値を直接送信先フィールドに書き込むことができます。

      • 時間値:ソースフィールドに時間関連の値が含まれている場合、そのフォーマットに基づいて処理し、Destination Format を指定して出力値をフォーマットできます。

        • 時間文字列:2018-10-23 02:13:562021/05/18 のような時間を表す文字列。ソースと送信先の時間フォーマットを指定することで、これらの文字列を時間値にシリアル化できます。上記の例では、yyyy-MM-dd HH:mm:ssyyyy/MM/dd のようなフォーマットを使用できます。

        • 時間オブジェクト:ソース値が既に DateDatetime のような時間ベースのデータ型である場合は、このタイプを選択します。

        • Unix タイムスタンプ (秒):1610529203"1610529203" のような 10 桁の秒単位のタイムスタンプ。

        • Unix タイムスタンプ (ミリ秒):1610529203002"1610529203002" のような 13 桁のミリ秒単位のタイムスタンプ。

    • 関数:関数を使用して、ソースフィールド値に簡単な変換を適用してから、送信先フィールドに割り当てます。詳細については、「関数式を使用して送信先テーブルのフィールドに値を割り当てる」をご参照ください。

  • パーティションフィールド:列挙値またはソースフィールドのイベント時間に基づいて動的にパーティションを作成できます。

    • 手動割り当てConfigure Scheduling Parameters for Periodical Scheduling 設定で既に設定した定数値またはスケジューリングパラメーターを入力できます。例:abc または ${bizdate}

[ソース分割 PK]

[ソース分割 PK] ドロップダウンリストから、ソーステーブルのフィールドを選択するか、Not Split を選択できます。同期タスクが実行されると、このフィールドに基づいてタスクが複数のサブタスクに分割され、データを同時に読み取ります。

プライマリキーなど、データが均等に分散しているフィールドを分割列として使用してください。文字列、浮動小数点、日付型はサポートされていません。

現在、ソース分割 PK 機能は、ソースが MySQL の場合にのみサポートされています。

[完全同期の実行]

ステップ 3 で完全データ同期を設定した場合、このオプションをクリアすることで、特定のテーブルの完全データ同期をスキップできます。これは、別の方法で既に完全データセットを送信先に同期している場合に便利です。

Full condition

完全ロードフェーズ中にソースにフィルター条件を適用します。WHERE キーワードなしで、WHERE 句の内容のみを入力します。

Configure DML Rule

DML メッセージ処理を使用して、キャプチャされたデータ変更 (InsertUpdateDelete) を送信先に書き込む前にフィルタリングおよび制御します。このルールは、増分同期フェーズ中にのみ適用されます。

完全データマージサイクル

現在、日次マージのみがサポートされています。[マージ時間のカスタマイズ] 設定で、マージタスクの特定のスケジューリング時間を設定できます。

プライマリキーのマージ

テーブルから 1 つ以上の列を選択して、プライマリキーを定義できます。

  • 単一列のプライマリキー:id のように一意の値を持つ単一の列をプライマリキーとして選択します。

  • 複合プライマリキー:一意の単一列が存在しない場合、複数の列を選択して複合キーを形成できます。これらの列の値の組み合わせは、各行を一意に識別し、データの整合性を確保し、データの上書きを防ぐ必要があります。

ステップ 6: 詳細設定の構成

詳細パラメーター設定

タスクを微調整し、カスタムの同期ニーズを満たすには、Advanced Parameters タブに移動して詳細パラメーターを変更します。

  1. ページの右上隅にある [詳細設定] をクリックして、詳細パラメーター設定ページに移動します。

  2. ツールチップに基づいてパラメーター値を変更します。各パラメーターの説明は、その名前の横に表示されます。

  3. AI を活用した設定も使用できます。タスクの同時実行数の調整など、自然言語でコマンドを入力すると、AI モデルが推奨パラメーター値を生成します。その後、AI が生成したパラメーターを受け入れるかどうかを選択できます。

    image

重要

これらのパラメーターは、その目的を完全に理解している場合にのみ変更してください。誤った変更は、タスクの遅延、他のタスクをブロックする過剰なリソース消費、またはデータ損失などの予期しない問題につながる可能性があります。

DDL 機能設定

一部のリアルタイム同期パイプラインは、ソーステーブル構造のメタデータ変更を検出し、送信先に通知できます。送信先はそれに応じて更新するか、アラートの送信、変更の無視、タスクの終了などの他のアクションを実行できます。

ページの右上隅にある Configure DDL Capability をクリックして、各変更タイプに対する処理ポリシーを設定します。サポートされているポリシーは、チャネルによって異なります。

  • 通常:送信先はソースからの DDL 変更を処理します。

  • 無視:変更メッセージは無視され、送信先は変更されません。

  • エラー:データベース全体のリアルタイム同期タスクが終了し、そのステータスが [エラー] に設定されます。

  • アラート:ソースでこのタイプの変更が発生したときにユーザーにアラートが送信されます。Configure Alert Rule で DDL 通知ルールを設定する必要があります。

説明

ソースで新しい列が追加され、DDL 同期を介して送信先でも作成された場合、システムは送信先テーブルの既存の行に対してデータをバックフィルしません。

ステップ 7: 同期タスクの実行

  1. 同期タスクの設定が完了したら、ページ下部の [完了] をクリックします。

  2. [データ統合] ページの [同期タスク] セクションで、作成した同期タスクを見つけ、Operation 列の Deploy をクリックします。[デプロイ後すぐに開始] を選択した場合、[確認] をクリックするとタスクはすぐに実行されます。それ以外の場合は、手動で開始する必要があります。

    説明

    Data Integration タスクは、実行するために本番環境にデプロイする必要があります。そのため、新しく作成または編集されたタスクは、デプロイ後にのみ有効になります。

  3. Tasks セクションの同期タスクの Name/ID をクリックし、同期タスクの詳細な実行プロセスを表示します。

次のステップ

タスクを設定した後、タスクの管理、テーブルの追加または削除、モニタリングとアラートの設定、主要な運用メトリックの表示ができます。詳細については、「完全および増分同期タスクの O&M」をご参照ください。

よくある質問

Q: ベーステーブルのデータが期待どおりに更新されないのはなぜですか?

A: これにはいくつかの理由が考えられます。一般的な原因と解決策については、以下の表をご参照ください。

image

症状

原因

解決策

増分ログテーブルの T-1 パーティションのデータ出力チェックが失敗しました。

リアルタイム同期タスクの失敗により、増分ログテーブルの T-1 パーティションのデータが生成されませんでした。

  • リアルタイム同期タスクが失敗した原因を調査し、障害点からタスクを再開します。

    説明

    RDS のバイナリログ (binlog) の保持期間は限られています。必要な時点の binlog が消去されている場合、リアルタイム同期タスクは失敗し、「開始位置が見つかりません」というエラーを報告します。

  • リアルタイム同期サブタスクのモニタリングとアラートを設定します。

送信先ベーステーブルの T-2 パーティションのデータ出力チェックが失敗します。

  1. 前日のマージタスクが失敗しました。

  2. ベーステーブルの前日のパーティションが削除されました。

  • マージタスクの実行ステータスのモニタリングを設定します。詳細については、「ルール管理」をご参照ください。

  • ベーステーブルの T-2 パーティションが誤って削除された場合は、データバックフィル機能を使用して復元します。データが復元された後、マージタスクを再実行します。詳細については、「バックフィルインスタンスの O&M」をご参照ください。