ApsaraDB RDS for MySQL を ApsaraDB for ClickHouse クラスターに同期する - ApsaraDB for ClickHouse

ApsaraDB for ClickHouse は、データ同期パイプラインを構築・保守することなく、RDS MySQL から ApsaraDB for ClickHouse へデータを同期するゼロ ETL データ統合機能を提供します。この機能は無料で利用でき、データ転送および運用管理 (O&M) コストを削減します。

概要

企業は多くの場合、さまざまなシステムに分散した業務データを管理しています。

ETL（Extract、Transform、Load）は、上流の業務システムからデータを収集し、分析用にデータウェアハウスに統合します。

従来の ETL ワークフローには、次のような課題があります。

リソースコストが高い：異なるデータソースには通常、異なる ETL ツールが必要であり、これらのパイプラインを構築すると追加コストが発生します。
システムの複雑性が高い：ETL ツールの保守により運用が複雑化し、アプリケーション開発から注意がそれてしまいます。
データ遅延：ETL で一般的な定期的なバッチ更新では、ニアリアルタイムのシナリオでの分析が遅延することがあります。

これらの課題に対処するため、Alibaba Cloud はオンライントランザクション処理（OLTP）システムとオンライン分析処理（OLAP）データウェアハウス間のデータパイプラインを自動的に構築するゼロ ETL 機能を提供します。この機能により、抽出、変換、ロードが自動的に行われ、トランザクション処理とデータ分析を統合したワンストップソリューションが実現され、ユーザーは分析に集中できます。

メリット

使いやすい：ソースデータと宛先インスタンスを選択すると、システムがリアルタイムデータパイプラインを自動的に作成します。複雑な ETL パイプラインを構築・保守する必要がないため、アプリケーション開発に集中できます。
コストゼロ：ゼロ ETL パイプラインは無料です。データウェアハウスで上流データを追加コストなしで分析できます。
マルチソース集約：複数のインスタンスから単一の ApsaraDB for ClickHouse インスタンスへリアルタイムでデータを同期し、包括的な分析ビューを構築できます。

説明
複数のインスタンスから単一の ApsaraDB for ClickHouse インスタンスにデータを同期する場合、異なるタスクの同期オブジェクトが重複してはいけません。

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

ApsaraDB RDS for MySQL から ApsaraDB for ClickHouse へ

課金

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

前提条件

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

制限事項

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

注意事項

ゼロ ETL パイプライン作成時の注意点

ApsaraDB for ClickHouse クラスターのゼロ ETL リンク数が上限に達している場合、新しいリンクを作成できません。DTS を使用して同期リンクを作成するか、未使用のゼロ ETL リンクを削除してください。上限は次のとおりです。
- Enterprise Edition クラスターの最大リンク数は、数式 [クラスター CCU の下限 / 8] で計算し、結果を切り上げます。たとえば、クラスターの CCU 下限が 22、上限が 36 の場合、下限値 22 を使用して計算します。結果は 22 / 8 = 2.75 となり、切り上げて 3 になります。つまり、最大 3 つのゼロ ETL リンクを作成できます。
- Community Edition クラスターの最大リンク数：[クラスターコア総数 / 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 クラスターの場合、シームレスな統合により、宛先にローカルテーブルと分散テーブルが作成されます。
  - 分散テーブルの名前は、ソーステーブルの名前と同じになります。
  - ローカルテーブルの名前は、<distributed_table_name> + _local になります。

データ型のマッピング

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

事前準備

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

AliyunServiceRoleForClickHouseZeroETL サービスリンクロールを作成します。

説明
AliyunServiceRoleForClickHouseZeroETL サービスリンクロールは、システムによって自動的に作成されます。構成中にこのロールを手動で作成するようダイアログボックスが表示された場合は、無視しても問題ありません。
RAM ユーザーに権限を付与します。

ゼロ ETL パイプラインを作成するには、RAM ユーザーに以下の 3 つの権限が必要です。RAM ユーザーへの権限付与方法については、「RAM ユーザー権限の管理」をご参照ください。
- ソース ApsaraDB RDS for MySQL インスタンスに対する権限：AliyunRDSFullAccess
- 宛先 ApsaraDB for 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 をクリックします。
左側のナビゲーションバーで、センスレス統合 (Zero-ETL) をクリックします。

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

Zero-ETL タスクの作成 をクリックして、Zero-ETL タスクの作成 ページを開きます。

タスク名 を入力し、以下の設定を完了します。

ソースおよび宛先データベースの構成

以下のパラメーターを使用してソースおよび宛先データベースを構成し、接続をテストして続行をクリックします。

ソースデータベース

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

宛先データベース

パラメーター	説明
データベースタイプ	ClickHouse
アクセス方法	Alibaba Cloud インスタンスのみサポートされています。
インスタンスのリージョン	宛先クラスターのリージョンです。
クラスター ID	宛先クラスターの ID です。
クラスタータイプ	クラスタータイプです。有効値：Community-Compatible Edition および Enterprise Edition。
データベースアカウント	宛先クラスターのデータベースアカウントです。
データベースのパスワード	宛先クラスターのデータベースアカウントのパスワードです。

ゼロ ETL の構成

ソースオブジェクト ボックスで同期するオブジェクトを選択し、をクリックして 選択中のオブジェクト ボックスに移動させます。次：データベースおよびテーブルのフィールド設定 をクリックします。
データベースおよびテーブルフィールドの構成。

Zero-ETL の設定 ページで、宛先データベースに同期するテーブルの タイプ、プライマリキー列の追加、ソートキー、配布キー、および パーティションキー を構成します。
説明
- デフォルトでは、定義されていないテーブルに関する情報がページに表示されます。定義ステータス を すべて に設定した後で修正できます。
- プライマリキー列の追加 および ソートキー は複合キーにできます。つまり、プライマリキー列の追加 または ソートキー の対応するドロップダウンリストから複数のフィールドを選択できます。プライマリキー列の追加 から 1 つ以上の列を選択して パーティションキー として使用する必要があります。配布キー には 1 つのフィールドのみ選択できます。プライマリキー列、ソートキー、パーティションキーの詳細については、「CREATE TABLE」をご参照ください。
- パーティションキー は省略可能ですが、NULL 許容フィールドであってはなりません。そうでない場合、同期タスクが失敗します。
タスクの保存

データベーステーブルフィールドを構成したら、次：タスク設定の保存と事前チェック をクリックします。

説明
この操作により、事前チェックの結果に関係なくタスクが保存されます。
事前チェックとタスクの開始

成功率 が 100% になったら、開始をクリックしてゼロ ETL タスクを開始します。

ゼロ ETL ページでは、対象のゼロ ETL タスクの ID/名前、移行元/移行先、および ステータス を確認できます。

事前チェックが失敗した場合は、失敗情報に基づいてソースおよび宛先データベースを調整します。その後、ゼロ ETL ページでタスクを見つけ、修正して再度事前チェックを実行します。事前チェックが成功したら、タスクを開始できます。

ゼロ ETL タスクのモニタリング

以下の方法でゼロ ETL タスクをモニタリングできます。アラートまたはイベントサブスクリプションを構成して、タスクステータスの最新情報をタイムリーに受け取ります。タスクに異常が発生した場合は、アクティブなモニタリングを使用して問題をトラブルシューティングします。

モニタリング方法	メリット	制限事項	操作
アクティブモニタリング	同期パフォーマンス、詳細、ログなど、タスクステータスの包括的なビューを提供します。	ゼロ ETL タスクに異常が発生しても、アクティブに通知しません。	ApsaraDB for ClickHouse コンソールでタスクをモニタリングする
アラートモニタリング	CloudMonitor はアラートルールに基づいて自動的にアラート通知を送信し、異常なモニタリングデータを迅速に識別・対処するのに役立ちます。	ゼロ ETL タスクの同期遅延（ミリ秒単位）のみをモニタリングします。	CloudMonitor アラートによる同期遅延のモニタリング
イベントサブスクリプション	ゼロ ETL タスクのシステムイベントがアラート条件を満たすと、CloudMonitor は自動的にアラート通知を送信し、タスクの障害および復旧について最新情報を提供します。	ゼロ ETL タスクの障害および復旧のみをモニタリングします。	CloudMonitor でのゼロ ETL タスクイベントのサブスクリプション

コンソールでのモニタリング

ApsaraDB for ClickHouse コンソールにログインします。左上隅で、宛先クラスターが配置されているリージョンを選択します。
クラスターリスト ページで、Community Edition インスタンスのリスト を選択し、対象クラスター ID をクリックします。
左側のナビゲーションバーで、センスレス統合 (Zero-ETL) をクリックします。
対象タスクの操作列で、タスクの詳細 をクリックします。

タスク詳細ページでは、包括的な情報を表示してタスクをモニタリングできます。

CloudMonitor 遅延アラート

CloudMonitor でアラートルールを作成して、ゼロ ETL 遅延をモニタリングします。メトリックがアラート条件を満たすと、CloudMonitor は自動的にアラート通知を送信します。

ステップ 1：ゼロ ETL 遅延アラートの作成

ゼロ ETL 遅延アラートの作成方法については、「CloudMonitor コンソールの使用」をご参照ください。アラートを作成する際は、以下のパラメーターを必ず設定してください。

パラメーター	説明
製品	Clickhouse - ZeroETL Latency を選択します。
メトリック	Synchronization Latency を選択します。

ステップ 2：クラスター遅延の確認

CloudMonitor にログインします。
Clickhouse - ZeroETL Latency リストで、対象クラスターの操作列の モニタリングチャート をクリックして、クラスター同期遅延を確認します。

CloudMonitor イベントサブスクリプション

ゼロ ETL タスクの復旧および障害をモニタリングし、タイムリーに通知を受け取るには、関連イベントをサブスクライブしてください。

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

イベント	パラメーター	説明
ゼロ ETL タスク障害	サブスクリプションタイプ	システムイベントを選択します。
	製品	ApsaraDB for ClickHouse を選択します。
	イベントタイプ	異常を選択します。
	イベント名	ZeroETL task abnormal を選択します。
ゼロ ETL タスク復旧	サブスクリプションタイプ	システムイベントを選択します。
	製品	ApsaraDB for ClickHouse を選択します。
	イベントタイプ	復旧を選択します。
	イベント名	ZeroETLTaskRestore を選択します。

よくある質問

Q：ゼロ ETL を使用してデータを ApsaraDB for ClickHouse に同期した後、なぜ宛先データベースのデータ量がソースデータベースよりも大きくなるのですか？

原因：ソースで UPDATE または DELETE 操作を実行すると、ApsaraDB for ClickHouse は新しい行を書き込み、_sign、_is_deleted、_version フィールドを使用してこれらの操作をマークします。その結果、宛先データベースの行数がソースデータベースよりも多くなります。

解決策：クエリ時に、バージョンに基づいて削除されたデータをフィルターするために _sign または _is_deleted 条件を使用します。また、レコードの重複排除のためにテーブル名の後に FINAL を追加します。フィールド識別子の詳細については、「フィールド情報」をご参照ください。

Q：ゼロ ETL を使用してデータを ApsaraDB for ClickHouse に同期した後、なぜ宛先データベースにローカルテーブルが表示されるのですか？

宛先が ApsaraDB for ClickHouse Community-Compatible Edition クラスターの場合、シームレスな統合により、宛先にローカルテーブルと分散テーブルが作成されます。

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