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

Data Management:タスクオーケストレーション

最終更新日:Mar 29, 2026

Data Management (DMS) のタスクオーケストレーション機能を使用して、既存データを自動的にアーカイブする、スケジュールされた複数ステップのタスクフローを構築します。このチュートリアルを完了すると、以下のタスクフローが動作するようになります。

  • 6ヶ月以上前のレコードに対して月次アーカイブテーブルを作成します。

  • ソーステーブルから条件を満たす行をアーカイブテーブルにコピーします。

  • ソーステーブルから移行された行を削除します。

  • 毎月1日の01:00に自動的に実行されます。

このチュートリアルの手順:

  1. タスクフローの作成

  2. 時間変数の設定

  3. ノードの作成と構成

  4. ノードの接続とスケジューリングの設定

  5. タスクフローの実行と結果の確認

前提条件

開始する前に、以下を確認してください。

  • DMS に登録済みのデータベースインスタンス。詳細については、「Alibaba Cloud データベースインスタンスの登録」をご参照ください。

  • 正常ステータスのインスタンス。確認するには、DMS コンソールホームページに移動し、左側のナビゲーションウィンドウでインスタンスにカーソルを合わせ、ステータスツールチップを読み取ります。

  • インスタンスコントロールモードが 柔軟な管理 または 安定的な変更 の場合、タスクフローへの所有者アクセスが必要です。この要件は、[セキュリティコラボレーション] モードのインスタンスには適用されません。詳細については、「概要」をご参照ください。

サポートされているデータベース

タスクオーケストレーションは、以下のデータベースタイプをサポートしています。

リレーショナルデータベース

  • MySQL: ApsaraDB RDS for MySQL、PolarDB for MySQL、ApsaraDB MyBase for MySQL、PolarDB for Xscale、および他のソースからのMySQLデータベース

  • SQL Server: ApsaraDB RDS for SQL Server、ApsaraDB MyBase for SQL Server、および他のソースからのSQL Serverデータベース

  • PostgreSQL: ApsaraDB RDS for PostgreSQL、PolarDB for PostgreSQL、ApsaraDB MyBase for PostgreSQL、および他のソースからのPostgreSQLデータベース

  • OceanBase: MySQL モードのApsaraDB for OceanBase、Oracle モードのApsaraDB for OceanBase、およびセルフマネージド OceanBase データベース

  • PolarDB for PostgreSQL (Compatible with Oracle)

  • Oracle

  • Dameng (DM)

  • Db2

NoSQL データベース: Lindorm

データウェアハウス: AnalyticDB for MySQL、AnalyticDB for PostgreSQL、Data Lake Analytics (DLA)、MaxCompute、Hologres

オブジェクトストレージ: Object Storage Service (OSS)

ソーステーブルのセットアップ

このチュートリアルでは、test という名前のソーステーブルを使用します。テーブルを作成し、サンプルデータを挿入するには、次のステートメントを実行します。

-- ソーステーブルの作成
CREATE TABLE test (
    `id` bigint(20) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT COMMENT '主キー',
    `gmt_create` DATETIME NOT NULL COMMENT '作成時間',
    `gmt_modified` DATETIME NOT NULL COMMENT '変更時間',
    `content` TEXT COMMENT 'テストデータ'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT 'タスクオーケストレーションテスト用のテーブル';

-- サンプルデータの挿入
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-01-01 01:00:00', '2020-01-01 01:00:00', 'value1');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-02-01 01:00:00', '2020-02-01 01:00:00', 'value2');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-03-01 01:00:00', '2020-03-01 01:00:00', 'value3');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-04-01 01:00:00', '2020-04-01 01:00:00', 'value4');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-05-01 01:00:00', '2020-05-01 01:00:00', 'value5');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-06-01 01:00:00', '2020-06-01 01:00:00', 'value6');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-07-01 01:00:00', '2020-07-01 01:00:00', 'value7');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-08-01 01:00:00', '2020-08-01 01:00:00', 'value8');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-09-01 01:00:00', '2020-09-01 01:00:00', 'value9');
INSERT INTO test(`gmt_create`, `gmt_modified`, `content`) VALUES ('2020-10-01 01:00:00', '2020-10-01 01:00:00', 'value10');

これらの文は、DMS の SQLConsole タブ上、またはデータ変更チケットを提出することで実行できます。詳細については、「SQLConsole タブでデータベースを管理する」および「通常のデータ変更」をご参照ください。

ステップ1: タスクフローの作成

  1. DMS コンソール V5.0 にログインします。

  2. トップナビゲーションバーで、[すべての機能] > [データ + AI] > [データ開発] > [タスクオーケストレーション] を選択します。

    DMS コンソールの通常モードを使用している場合、左上隅のアイコンにマウスを合わせて、[データ + AI] > [データ開発] > [タスクオーケストレーション] を選択します。
  3. [タスクフローの作成]をクリックします。

  4. [新規タスクフロー] ダイアログボックスで、[タスクフロー名][説明]を入力し、[OK] をクリックします。

ステップ2: 時間変数の設定

タスクフローは、アーカイブウィンドウが現在の日付を基準に自動的に6ヶ月遡るように、SQL フィルター条件として2つの時間変数を使用します。タスクフロー内のすべてのノードは、構文 ${variable_name} を使用してこれらの変数を参照できます。

ページの下部の[変数設定]タブで、左側のペインの[タスクフロー変数]をクリックし、以下の 2 つの変数を作成します:

変数時間形式オフセット説明例 (本日が2023年6月27日の場合)
yearmonth6_nameyyyy-MM-, 6, Month6ヶ月前の月、月単位で正確2022-12
yearmonth6_dateyyyy-MM-01-, 6, Month6ヶ月前の月の初日、日単位で正確2022-12-01
  • yearmonth6_name は、アーカイブテーブル名のサフィックスとして使用されます (例: test_2022-12)。

  • yearmonth6_date は、両方の SQL ノードの WHERE 句におけるカットオフ日付として使用されます。

変数の完全な構文とオプションについては、「変数」をご参照ください。

ステップ3: ノードの作成と構成

タスクフローには、2つの単一インスタンス SQL ノードが必要です。1つはデータをアーカイブテーブルに移行するため、もう1つはソーステーブルから移行された行を削除するためです。

データ移行ノードの作成

このノードは、月次アーカイブテーブルを作成し (まだ存在しない場合)、test から6ヶ月以上前のすべてのレコードをそのテーブルにコピーします。

  1. キャンバスの左側にある[タスクタイプ] パネルから、[シングルインスタンス SQL] ノードをキャンバスにドラッグします。

  2. ノードを右クリックし、[名前の変更] を選択します。ノード名として [データ移行] を入力します。

  3. ノードをダブルクリックして SQL エディターを開きます。

  4. データベース検索ボックスでデータベースを選択し、次の SQL を入力します。

    CREATE TABLE IF NOT EXISTS `test_${yearmonth6_name}` LIKE test;
    INSERT INTO `test_${yearmonth6_name}`
    SELECT * FROM `test`
    WHERE gmt_create < '${yearmonth6_date}';

    最初のステートメントは、test と同じスキーマで test_${yearmonth6_name} を作成し、テーブルが既に存在する場合は作成をスキップします。2番目のステートメントは、6ヶ月のカットオフより前の gmt_create 日付を持つすべての行をアーカイブテーブルにコピーします。

  5. [プレビュー] をクリックして SQL ステートメントを検証します。

履歴データクリアノードの作成

このノードは、test からアーカイブテーブルにコピーされたすべての行を削除します。

  1. もう 1 つ[Single Instance SQL]ノードをキャンバス上にドラッグしてください。

  2. ノードを右クリックして、[名前を変更] を選択します。ノード名として [履歴データをクリア] を入力します。

  3. ノードをダブルクリックして SQL エディターを開きます。

  4. データベース検索ボックスでデータベースを選択し、次の SQL を入力します。

    警告

    DELETE ステートメントはオフピーク時間中に実行してください。大量のデータを削除すると、テーブルロックが長期間保持され、他の操作が中断される可能性があります。

    DELETE FROM `test` WHERE gmt_create < '${yearmonth6_date}';

    このステートメントは、アーカイブテーブルに既にコピーされたすべての行を削除し、test に6ヶ月以上前のレコードがない状態を維持します。

  5. [プレビュー] をクリックして、SQL ステートメントを検証します。

ステップ4: ノードの接続とスケジューリングの設定

ノードの接続

キャンバスで、[Migrate Data] ノードにカーソルを合わせ、右側の中抜き円をクリックし、接続線を [Clear Historical Data] ノードにドラッグします。これにより、実行順序が定義されます。[Migrate Data] が最初に実行され、次に [Clear Historical Data] が実行されます。

スケジューリングの設定

  1. ページの下部で、[タスクフロー情報] タブをクリックします。

  2. [スケジュール設定]」セクションで、以下のパラメーターを設定します。

    パラメーター
    スケジューリングを有効化オンにする
    スケジューリングタイプ時間指定スケジューリング/周期スケジューリング
    有効時間1970-01-01 – 9999-01-01 (デフォルト。スケジュールは無期限に実行)
    スケジューリングサイクル
    指定時間毎月1日
    特定の時点01:00
    タイムゾーンご希望のタイムゾーン
    Cron式上記の設定に基づいて自動生成

    この例では、タスクフローを毎月1日の01:00に実行するようにスケジュールします。要件に合わせて設定を調整してください。その他のオプションについては、「概要」をご参照ください。

ステップ5: タスクフローの実行と結果の確認

テスト実行

キャンバスの左上隅にある [試行実行] をクリックします。ログ出力を確認します:

  • 最終行に status SUCCEEDED: テスト実行が正常に完了しました。

  • 最終行に status FAILED: テスト実行が失敗しました。どのノードが失敗したか、その理由を特定するためにログを確認し、構成を修正して再試行してください。

結果の検証

SQLConsole タブでクエリを実行し、以下を確認します。

  • 6ヶ月のカットオフより前の gmt_create を持つレコードが、アーカイブテーブル test_${yearmonth6_name} にコピーされていること。

  • これらのレコードが test テーブルに存在しないこと。

データクエリの詳細については、「SQLConsole タブでのデータベース管理」をご参照ください。

次のステップ

リファレンス