RDS for MySQL から ApsaraDB for ClickHouse クラスターへのデータ同期 - ApsaraDB for ClickHouse

ApsaraDB for ClickHouse は、RDS for MySQL インスタンスから ApsaraDB for ClickHouse クラスターにデータを同期するためのゼロ ETL 機能を提供します。この機能により、データ同期パイプラインの作成、維持、または支払いが不要になり、データ転送と運用保守 (O&M) のコストが削減されます。

概要

ビッグデータの時代において、企業はさまざまなシステムやプラットフォームに分散した大量の業務データを効率的に管理・活用するために、抽出・変換・書き出し (ETL) ツールを使用する必要があります。

ETL は、上流の業務システムからデータを抽出し、データを変換・クレンジングした後、データウェアハウスに書き出すプロセスです。このプロセスにより、分散した上流のデータがターゲットのデータウェアハウスに統合され、さらなる計算と分析を通じて効果的なビジネス上の意思決定を行うことができます。

従来の ETL プロセスでは、しばしば以下の課題に直面します。

リソースコストの増加：データソースごとに異なる ETL ツールが必要になる場合があり、ETL パイプラインの構築には追加のリソースコストが発生します。
システム複雑性の増大：ETL ツールを維持する必要があるため、O&M の複雑性が増し、ビジネスアプリケーション開発に集中できなくなります。
データ鮮度の低下：一部の ETL プロセスでは定期的な一括更新が行われます。ほぼリアルタイムのデータが要求されるシナリオでは、分析結果を迅速に生成できません。

これらの課題に対処するため、Alibaba Cloud ApsaraDB はゼロ ETL 機能を提供します。この機能は、オンライントランザクション処理 (TP) データベースを使用する業務システムと、オンライン分析処理 (OLAP) データベースを使用するデータウェアハウスとの間に、データ同期パイプラインを迅速に構築するのに役立ちます。この機能は、業務システムからデータウェアハウスへのデータの抽出、変換、クレンジング、書き出しを自動的に行います。これにより、単一のソリューションでデータ同期を管理し、トランザクション処理とデータ分析を統合して、データ分析業務に集中できるようになります。

メリット

シンプルで使いやすい： ETL 操作のために複雑なデータパイプラインを作成したり維持したりする必要はありません。ソースインスタンスとターゲットクラスターを選択するだけで、リアルタイムのデータ同期パイプラインが自動的に作成されます。これにより、データパイプラインの構築と管理の課題が軽減され、アプリケーション開発に集中できます。
ゼロコスト： ゼロ ETL パイプラインは無料です。追加費用なしで、データウェアハウス内の上流データを分析できます。
マルチソース集約： ゼロ ETL パイプラインを使用して、複数のインスタンスから単一の ApsaraDB for ClickHouse クラスターにリアルタイムでデータを同期できます。これにより、グローバルな分析視点を構築するのに役立ちます。
説明
複数のインスタンスから単一の ApsaraDB for ClickHouse クラスターにデータを同期する場合、異なるタスクの同期オブジェクトが重複しないようにしてください。

サポートされるパイプライン

RDS for MySQL から ClickHouse へ

課金

ゼロ ETL 同期パイプラインは無料です。

前提条件

ApsaraDB for ClickHouse クラスターと RDS for MySQL インスタンスが同じリージョンに存在すること。
ソースの RDS for MySQL インスタンスとターゲットクラスター用にデータベースアカウントが作成されていること。詳細については、「ApsaraDB RDS for MySQL インスタンスのアカウント作成」および「ApsaraDB for ClickHouse クラスターのアカウント作成」をご参照ください。

制限事項

タイプ	説明
RDS for MySQL の制限事項	プライマリキーのないテーブルは同期できません。 RENAME TABLE 操作はサポートされていません。テーブルレベルでデータを同期し、マッピングテーブル名や列名などのオブジェクトを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクを送信した後にエラーが報告されます。この場合、テーブルを複数のタスクに分割するか、データベース全体を同期するようにタスクを構成してください。バイナリログ： RDS for MySQL インスタンスでは、バイナリログはデフォルトで有効になっています。`binlog_row_image` パラメーターを `full` に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ同期タスクを開始できません。インスタンスパラメーターの設定方法の詳細については、「インスタンスパラメーターの設定」をご参照ください。重要ソースインスタンスが自己管理型 MySQL データベースの場合、バイナリログを有効にし、`binlog_format` パラメーターを `row` に、`binlog_row_image` パラメーターを `full` に設定する必要があります。ソースの自己管理型 MySQL データベースが、2 つのデータベースが互いにプライマリとセカンダリであるプライマリ/プライマリクラスターである場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。詳細については、「自己管理型 MySQL データベースのデータベースアカウント作成とバイナリログの設定」をご参照ください。 RDS for MySQL インスタンスのバイナリログを少なくとも 3 日間保持してください。7 日間の保持期間を推奨します。自己管理型 MySQL データベースの場合、バイナリログを少なくとも 7 日間保持してください。保持期間が短いと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合には、データの不整合やデータ損失が発生する可能性があります。必要な期間より短いバイナリログ保持期間に起因する問題は、DTS のサービスレベル契約 (SLA) の対象外です。説明 RDS for MySQL インスタンスのバイナリログの [保持期間] の設定方法の詳細については、「ローカルログの自動削除」をご参照ください。初期スキーマ同期および初期完全データ同期中は、データベースまたはテーブルのスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。説明初期完全データ同期中、DTS はソースデータベースにクエリを実行します。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。同期インスタンスの実行中に、物理バックアップからのデータ復元やカスケード操作によって生成されたデータなど、バイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに同期されません。説明これが発生した場合、ビジネス上許容されるのであれば、データを含むデータベースまたはテーブルを同期オブジェクトから削除し、再度追加することができます。詳細については、「同期オブジェクトの変更」をご参照ください。ソースデータベースがバージョン 8.0.23 以降の MySQL データベースで、同期するデータに不可視列が含まれている場合、これらの列のデータが取得できないため、データ損失が発生する可能性があります。説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「不可視列」をご参照ください。プライマリキーのないテーブルは、自動的に不可視のプライマリキーを生成します。この不可視のプライマリキーも可視にする必要があります。詳細については、「生成された不可視のプライマリキー」をご参照ください。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ同期はサポートされません。説明透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスでは、スキーマ同期、完全データ同期、および増分データ同期がサポートされます。読み取り専用の RDS for MySQL 5.6 インスタンスなど、トランザクションログを記録しない RDS for MySQL インスタンスは、ソースデータベースとして使用できません。ゼロ ETL タスクは、バイナリログのオフセットを進めるために、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` 文をスケジュール通りに実行します。
その他の制限事項	ApsaraDB for ClickHouse の時間型データには範囲制限があります。RDS MySQL の時間データがこの範囲外の場合、ApsaraDB for ClickHouse に同期される時間は不正確になります。範囲制限の詳細については、「時間情報」をご参照ください。

注意事項

ゼロ ETL パイプライン作成時の注意事項
ApsaraDB for ClickHouse クラスターに対して作成されたゼロ ETL タスクの数が上限に達した場合、新しいゼロ ETL タスクを作成することはできません。DTS コンソールで追加のデータ同期タスクを作成するか、不要になったゼロ ETL タスクを削除することができます。ApsaraDB for ClickHouse クラスターで作成できるゼロ ETL タスクの最大数は、次のように決定されます。
- Enterprise Edition クラスターの場合、作成できるゼロ ETL タスクの最大数は、数式 (クラスターの ClickHouse コンピュートユニット (CCU) の下限 / 8) を使用して計算されます。結果は最も近い整数に切り上げられます。たとえば、クラスターの CCU の下限が 22、上限が 36 の場合、計算は 22 / 8 = 2.75 となります。この結果は 3 に切り上げられます。したがって、最大 3 つのゼロ ETL タスクを作成できます。
- Community Edition クラスターの場合、作成できるゼロ ETL タスクの最大数は、数式 (クラスターの総コア数 / 8) を使用して計算され、結果は最も近い整数に切り上げられます。たとえば、クラスターに 2 つのノードがあり、各ノードに 8 コアと 32 GB のメモリがある場合、CPU コアの総数は 8 * 2 = 16 です。計算結果は 16 / 8 = 2 となります。したがって、最大 2 つのゼロ ETL タスクを作成できます。
同期タスクに関する注意事項
- ソースの RDS MySQL インスタンスの DDL 文が標準の MySQL 構文に従っていない場合、同期タスクが失敗したり、データが失われたりする可能性があります。
- 同期するデータベースの数が ApsaraDB for ClickHouse の制限である 256 を超えないこと。
- 同期するデータベース、テーブル、および列の名前が ApsaraDB for ClickHouse の命名規則に準拠していること。規則の詳細については、「オブジェクトの命名規則」をご参照ください。
- データベース全体ではなく 1 つ以上のテーブルを同期する場合、pt-online-schema-change のようなツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期は失敗します。
- データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ同期はオフピーク時に実行することを推奨します。そうしないと、初期完全データ同期がソースデータベースとターゲットデータベースの読み書きリソースを消費し、データベースの負荷が増加する可能性があります。
- スキーマ同期中、ゼロ ETL 機能はターゲットテーブルに _sign、_is_deleted、および _version フィールドを追加します。
- ターゲットデータベースが ApsaraDB for ClickHouse の Community-Compatible Edition クラスターである場合、ゼロ ETL タスクはターゲットデータベースにローカルテーブルと分散テーブルを作成します。
  - 分散テーブルの名前は、ソーステーブルの名前と同じです。
  - ローカルテーブルの名前は <分散テーブル名>+_local です。

データ型のマッピング

MySQL と ApsaraDB for ClickHouse クラスターは異なるデータ型をサポートしているため、1 対 1 のマッピングは不可能です。DTS が初期スキーマ同期を実行する際、ターゲットデータベースでサポートされている型に基づいてデータ型をマッピングします。詳細については、「初期スキーマ同期のデータ型マッピング」をご参照ください。

事前準備

サービスリンクロールを作成し、Resource Access Management (RAM) ユーザーに必要な管理権限を付与します。

AliyunServiceRoleForClickHouseZeroETL サービスリンクロールを作成します。
説明
タスクの作成と構成中に [データベースインスタンス ID] ドロップダウンリストの項目をクリックすると、サービスリンクロール AliyunServiceRoleForClickHouseZeroETL を作成するように促すポップアップエラーメッセージが表示されます。このロールはシステムが自動的に作成するため、手動で作成する必要はありません。
RAM ユーザーに管理権限を付与します。
RAM ユーザーがゼロ ETL タスクを作成できるようにするには、RAM ユーザーに以下の権限を付与する必要があります。詳細については、「RAM ユーザーへの権限付与」をご参照ください。
- ソース RDS for MySQL インスタンスに対する権限：AliyunRDSFullAccess
- ターゲット ClickHouse インスタンスに対する権限：AliyunClickHouseFullAccess
- DTS の権限：DTS のカスタムポリシーのスクリプトは以下の通りです。カスタムポリシーの作成方法の詳細については、「カスタム権限ポリシーの作成」をご参照ください。
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": "dts:*",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ram:PassRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:Service": "dts.aliyuncs.com"
                }
            }
        }
    ]
}
```

データ同期

ステップ 1：ゼロ ETL ページへの移動

ApsaraDB for ClickHouse コンソールにログインします。
ページの左上隅で、ターゲットクラスターのリージョンを選択します。
[クラスターリスト] ページで、[Community Edition インスタンスのリスト] を選択し、ターゲットクラスター ID をクリックします。
[クラスター情報] ページの左側のナビゲーションウィンドウで、[ゼロ ETL (シームレス統合)] をクリックして、ゼロ ETL ページに移動します。

ステップ 2：ゼロ ETL タスクの作成と開始

ゼロ ETL ページで、[ゼロ ETL タスクの作成] をクリックして、[ゼロ ETL タスクの作成] ページに移動します。

[タスク名] を入力し、以下の構成を完了します。

ソースデータベースとターゲットデータベースの構成

以下のパラメーターに基づいてソースデータベースとターゲットデータベースを構成します。構成が完了したら、[接続をテストして続行] をクリックします。

ソースデータベース

パラメーター	説明
データベースタイプ	RDS for MySQL のみがサポートされています。
アクセス方法	[Alibaba Cloud インスタンス] のみがサポートされています。
インスタンスリージョン	ソースインスタンスのリージョンを選択します。
RDS インスタンス ID	RDS for MySQL インスタンスの ID。
データベースアカウント	RDS for MySQL インスタンスのデータベースアカウント。
データベースパスワード	RDS for MySQL インスタンスのデータベースアカウントのパスワード。
[暗号化]	要件に応じて [非暗号化] または [SSL 暗号化] を選択します。[SSL 暗号化] を選択した場合、まず RDS for MySQL インスタンスの SSL 暗号化機能を有効にする必要があります。詳細については、「クラウド証明書を使用した SSL リンク暗号化の迅速な有効化」をご参照ください。

ターゲットデータベース

パラメーター	説明
データベースタイプ	ClickHouse
接続タイプ	[クラウドインスタンス] のみがサポートされています。
インスタンスリージョン	ターゲットクラスターのリージョン。
[クラスター ID]	ターゲットクラスターの ID。
クラスタータイプ	クラスタータイプ。有効な値は Community Edition と Enterprise Edition です。
[データベースアカウント]	ターゲットクラスターのデータベースアカウント。
[データベースパスワード]	ターゲットクラスターのデータベースアカウントのパスワード。

ゼロ ETL タスクの構成
[ソースオブジェクト] セクションで、同期したいオブジェクトを選択し、アイコンをクリックしてオブジェクトを [選択したオブジェクト] セクションに移動し、[次へ：データベースとテーブルフィールドの構成] をクリックします。
データベースとテーブルフィールドの構成。
[データベース、テーブル、列の構成] ページで、ターゲットデータベースに同期するテーブルの [タイプ]、[プライマリキー列]、[ソートキー]、[分散キー]、および [パーティションキー] を構成します。
説明
- デフォルトでは、未定義のテーブルの情報のみが表示されます。[定義ステータス] を [すべて] に設定してから変更を行うことができます。
- [プライマリキー列] と [ソートキー] は複合キーにすることができます。これにより、[プライマリキー列] または [ソートキー] の対応するドロップダウンリストから複数のフィールドを選択できます。[パーティションキー] として使用するために、[プライマリキー列] から 1 つ以上の列を選択する必要があります。[分散キー] には 1 つのフィールドしか選択できません。プライマリキー列、ソートキー、およびパーティションキーの詳細については、「CREATE TABLE」をご参照ください。
- [パーティションキー] はオプションです。ただし、設定する場合は、空でないフィールドを選択する必要があります。そうしないと、同期タスクは失敗します。
タスクの保存
データベースとテーブルフィールドを構成した後、[次へ：タスク設定を保存して事前チェック] をクリックします。
説明
この操作の後、事前チェックが成功したかどうかに関わらず、タスクは保存されます。
事前チェックとタスクの開始
[成功率] が [100%] になったら、[開始] をクリックしてゼロ ETL タスクを開始します。
ゼロ ETL ページでは、ターゲットのゼロ ETL タスクの [ID/名前]、[ソース/ターゲット]、および [ステータス] を表示できます。
事前チェックが失敗した場合は、失敗情報に基づいてソースデータベースとターゲットデータベースを調整します。ゼロ ETL ページでタスクを見つけ、変更して、再度事前チェックを実行します。事前チェックが成功したら、タスクを開始します。

ゼロ ETL タスクの監視

以下のいずれかの方法でゼロ ETL タスクを監視できます。タスク情報を迅速に取得するために、アラートを設定するか、イベントをサブスクライブすることを推奨します。タスクが異常な場合、これらの方法と能動的な表示を組み合わせてタスクのトラブルシューティングを行うことができます。

監視方法	利点	欠点	操作
能動的な表示	同期性能、同期詳細、タスクログなど、タスクステータスのあらゆる側面を表示できます。	ゼロ ETL タスクが異常な場合に問題を処理するための自動通知は受信されません。	ClickHouse コンソールでのゼロ ETL タスクの監視
アラートとモニタリング	アラートルールに基づき、監視システムが自動的にアラート通知を送信します。これにより、異常なモニタリングデータを迅速に受信し、迅速に処理できます。	ゼロ ETL タスクの同期遅延 (ミリ秒) のみを監視できます。	CloudMonitor コンソールでのゼロ ETL タスクの同期遅延アラートの設定
イベントサブスクリプション	ゼロ ETL タスクのシステムイベントがアラート条件を満たすと、CloudMonitor は自動的にアラート通知を送信します。これにより、タスクの異常および回復ステータスを迅速に把握し、適切な措置を講じることができます。	ゼロ ETL タスクの失敗と回復のみを監視できます。	Cloud Monitor コンソールでのゼロ ETL タスク関連イベントのサブスクライブ

ApsaraDB for ClickHouse コンソールでのタスクの監視

ApsaraDB for ClickHouse コンソールにログインします。
ページの左上隅で、ターゲットクラスターのリージョンを選択します。
[クラスターリスト] ページで、[Community Edition インスタンスのリスト] タブをクリックし、管理したいクラスターの ID をクリックします。
左側のナビゲーションウィンドウで、[ゼロ ETL (シームレス統合)] をクリックします。
ゼロ ETL ページで、ターゲットタスクの [操作] 列にある [タスク詳細] をクリックします。
タスク詳細ページでは、タスクに関するすべての情報を表示および監視できます。

CloudMonitor での同期遅延アラートの監視

CloudMonitor を使用して、ゼロ ETL の遅延を監視するためのアラートルールを作成できます。監視対象のメトリックがアラート条件を満たすと、監視システムは自動的にアラート通知を送信します。これにより、異常なモニタリングデータを迅速に受信し、迅速に処理できます。

ステップ 1：同期遅延アラートの作成

ゼロ ETL タスクの遅延アラートの作成方法の詳細については、「アラートルールの作成」をご参照ください。アラートを作成する際は、以下のパラメーターを正しく指定してください。

パラメーター	説明
製品	これを Clickhouse - ZeroETL Latency に設定します。
監視メトリクス	これを [同期遅延] に設定します。

ステップ 2：クラスターの遅延の表示

CloudMonitor コンソールにログインします。
[ClickHouse - ZeroETL Latency] リストで、ターゲットクラスターの [操作] 列にある [モニタリングチャート] をクリックして、クラスターの同期遅延を表示します。

CloudMonitor でのゼロ ETL タスク関連イベントのサブスクライブ

ゼロ ETL タスクの回復と失敗を監視し、タイムリーに通知を受け取るには、関連するイベントをサブスクライブします。

[ゼロ ETL] イベントのサブスクライブ方法の詳細については、「イベントサブスクリプションの管理」をご参照ください。イベントサブスクリプションポリシーを作成する際は、以下のパラメーターを適切に指定してください。

サブスクライブするイベント	パラメーター	説明
ゼロ ETL タスクの失敗	サブスクリプションタイプ	これを [システムイベント] に設定します。
	プロダクト	これを ApsaraDB Clickhouse に設定します。
	イベントタイプ	これを [異常] に設定します。
	イベント名	常に ZeroETL task abnormal を選択します。
ゼロ ETL タスクの回復	サブスクリプションタイプ	これを [システムイベント] に設定します。
	製品	これを ApsaraDB Clickhouse に設定します。
	イベントの種類	これを [回復] に設定します。
	イベント名	これを ZeroETLTaskRestore に設定します。

よくある質問

Q：ゼロ ETL 機能を使用して ApsaraDB for ClickHouse にデータを同期した後、ターゲットデータベースのデータサイズがソースデータベースよりも大きくなるのはなぜですか？

原因：ソースデータベースで `UPDATE` または `DELETE` 操作を実行すると、ClickHouse はターゲットデータベースに新しいレコードを書き込みます。これらの操作は `_sign`、`_is_deleted`、および `_version` フィールドを使用してマークされます。そのため、ターゲットデータベースのデータボリュームはソースデータベースよりも大きくなります。

解決策：クエリを実行する際、`_sign` または `is_deleted` 条件を使用して削除されたデータをフィルタリングし (バージョンによる)、テーブル名の後に `final` を追加して重複を削除します。詳細については、「フィールド情報」をご参照ください。

Q：ゼロ ETL を使用して ApsaraDB for ClickHouse にデータを同期した後、ターゲットデータベースに `_local` を含む名前のテーブルが表示されるのはなぜですか？

ターゲットデータベースが ApsaraDB for ClickHouse の Community-Compatible Edition クラスターである場合、ゼロ ETL タスクはターゲットデータベースにローカルテーブルと分散テーブルを作成します。

分散テーブルの名前は、ソーステーブルの名前と同じです。
ローカルテーブルの名前は <分散テーブル名>+_local です。

概要