ApsaraDB for ClickHouse:よくある質問

ApsaraDB for ClickHouse は、主にコミュニティ版の安定性のバグを修正します。また、ユーザーロールごとにリソース使用量の優先度を設定するための リソースキュー も提供しています。

以下の解決策をお試しください。

• ネットワーク接続を確認します。ping を使用してネットワーク到達可能性を確認し、telnet を使用してデータベースポート 3306 および 8123 が開いていることを確認します。

• ご利用の ClickHouse ホワイトリスト設定を確認します。ホワイトリストの設定。

• クライアントマシンのパブリック IP アドレスを確認します。オフィスネットワークでは、このアドレスが頻繁に変更される可能性があるため、IP ルックアップサービスを使用して正しいアドレスを確認してください。例として、whatsmyip を参照してください。

バージョン 20.3 および 20.8 では、外部テーブルを作成する際にシステムが自動的に接続を検証します。テーブル作成が成功すれば、ネットワーク接続が確立されていることを意味します。テーブル作成が失敗した場合、一般的な原因は以下のとおりです。

• ターゲットエンドポイントと ClickHouse が同じ VPC にないため、ネットワーク接続が確立できません。

• MySQL サーバーがホワイトリストを使用しています。ClickHouse を MySQL ホワイトリストに追加する必要があります。

接続失敗の一般的な原因とその解決策：

• 原因：ネットワーク環境が誤って設定されています。アプリケーションとインスタンスが同じ VPC 内にある場合にのみ、内部ネットワーク経由で接続できます。異なる VPC にある場合は、パブリックエンドポイントを有効にしてパブリックネットワーク経由で接続する必要があります。

  解決策：パブリックネットワークアクセスを有効にするには、「パブリック IP アドレスの申請と解放」をご参照ください。

• 原因：クライアントの IP アドレスがインスタンスのホワイトリストに含まれていません。

  解決策：ホワイトリストを設定するには、「ホワイトリストの設定」をご参照ください。

• 原因：ご利用の ECS インスタンスのセキュリティグループが、必要なポートのトラフィックをブロックしています。

  解決策：セキュリティグループを設定するには、「セキュリティグループ操作ガイド」をご参照ください。

• 原因：企業のファイアウォールが接続をブロックしています。

  解決策：ファイアウォールルールを変更して、インスタンスへのアウトバウンドトラフィックを許可してください。

• 原因：接続文字列のユーザー名またはパスワードに特殊文字（!@#$%^&*()_+= など）が含まれています。クライアントがこれらの文字を正しく解釈できないため、接続に失敗することがあります。

  解決策：接続文字列内の特殊文字を URL エンコードする必要があります。エンコードルールは次のとおりです。

  ! : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  たとえば、パスワードが ab@#c の場合、接続文字列内のエンコードされたパスワードは ab%40%23c にする必要があります。

• 原因：ApsaraDB for ClickHouse は、クラスター用に従量課金の Server Load Balancer (SLB) インスタンスを自動的にプロビジョニングします。Alibaba Cloud アカウントに支払い遅延がある場合、SLB インスタンスが一時停止され、ApsaraDB for ClickHouse インスタンスにアクセスできなくなる可能性があります。

  解決策：Alibaba Cloud アカウントの支払い遅延を確認してください。未払い残高がある場合は、支払ってサービスを復元してください。

この問題を解決するには、以下のいずれかを行ってください。

• OSS の大規模ファイルをインポート前に小規模ファイルに分割します。

• クラスターを垂直スケーリングしてメモリを増やします。Community Edition クラスターの垂直スケーリングと水平スケーリング。

一般的な原因と解決策：

• 原因 1：パラメーター設定が最適ではありません。ClickHouse は大規模な batch サイズと少ない concurrent operations 数で最高のパフォーマンスを発揮します。単一の batch には、平均行サイズに応じて、数十万行から数十万行を含めることができます。一般的なガイドラインとして、1 行あたり 100 バイトで見積もりますが、実際のデータ特性に基づいてこの値を調整する必要があります。

  解決策：concurrent operations 数を 10 以下に設定します。異なるパラメーター値を試して、ワークロードに最適な設定を見つけてください。

• 原因 2：DataWorks 専用リソースグループ のリソースが不十分です。専用リソースグループ の ECS インスタンスが小さすぎる可能性があります。CPU またはメモリが不十分だと、concurrent operations 数および利用可能な ネットワーク送信帯域幅 が制限されます。同様に、メモリが限られたマシンで大規模な batch サイズを設定すると、DataWorks プロセスで Java GC（ガベージコレクション）が頻繁に発生し、パフォーマンスが低下します。

  解決策：DataWorks 出力ログで ECS インスタンスの仕様を確認します。

• 原因 3：データソース にボトルネックがあります。

  解決策：DataWorks 出力ログで totalWaitReaderTime および totalWaitWriterTime メトリックを検索します。totalWaitReaderTime が totalWaitWriterTime よりも大幅に高い場合、ボトルネックは書き込み側ではなく読み取り側（データソース）にあります。

• 原因 4：パブリックネットワークエンドポイント を使用しています。パブリックネットワークエンドポイント は帯域幅が限られており、高性能なデータインポートまたはエクスポート操作には適していません。

  解決策：VPC ネットワーク エンドポイントに切り替えてください。

• 原因 5：ダーティデータ が存在します。通常、データは batch で書き込まれます。ただし、ダーティデータ に遭遇すると、現在の batch 書き込みが失敗します。その後、DataX は行単位の挿入モードにフォールバックします。このフォールバックにより、過剰な データパーツ が生成され、書き込みパフォーマンスが大幅に低下します。

  ダーティデータ を確認するには、次の 2 つの方法を使用できます。

  • エラーメッセージを確認します。ログに Cannot parse エラーが含まれている場合、これは ダーティデータ を示しています。

    次の SQL クエリを使用して例外を検索できます。

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • batch 行数を監視します。batch あたりの行数が 1 に低下した場合、DataX が ダーティデータ に遭遇して行単位モードに切り替わったことを強く示唆します。

    次の SQL クエリを使用して行数を確認できます。

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  解決策：データソース から ダーティデータ を特定して修正または削除します。

以下のチェックを実行してください。

1. インポート中にエラーが発生していないか、query_log システムテーブルを確認します。エラーが存在する場合、データ損失が発生している可能性があります。

2. テーブルエンジンが重複排除をサポートしているかどうかを確認します。たとえば、ReplacingMergeTree テーブルエンジンを使用している場合、このエンジンが重複を削除するため、ClickHouse の行数が Hive よりも少なくなる可能性があります。

3. Hive ソースの行数の正確性を確認します。ソースの初期カウントが不正確な可能性があります。

以下の項目を確認してください。

1. インポート中にエラーが発生していないか、query_log システムテーブルを確認します。エラーが存在する場合、データ損失が発生している可能性があります。

2. テーブルエンジンがデータ重複排除を実行しているかどうかを確認します。たとえば、ReplacingMergeTree エンジンは重複エントリを削除するため、ClickHouse の行数が Kafka よりも少なくなります。

3. Kafka 外部テーブル設定で kafka_skip_broken_messages パラメーターが有効になっているかどうかを確認します。有効になっている場合、ClickHouse は解析に失敗したメッセージをスキップするため、ClickHouse の行数が Kafka よりも少なくなります。

以下のいずれかの方法を使用します。

• ClickHouse クライアントを使用してファイルをエクスポートします。セルフマネージド ClickHouse インスタンスから ApsaraDB for ClickHouse Community Edition へのデータ移行。

• remote 関数を使用します。

  INSERT INTO <destination_table> SELECT * FROM remote('<connection_string>', '<database>', '<table>', '<username>', '<password>');

解決策：以下の手順に従って、MySQL データを再同期します。

1. 同期が停止したテーブルを削除します。

   DROP TABLE <table_name> ON cluster default;

   説明

   このコマンドでは、table_name は同期が停止したテーブルの名前です。テーブルが分散テーブルの場合、分散テーブルとそのローカルテーブルの両方を削除する必要があります。

2. 同期プロセスを再開します。

   ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   説明

   このコマンドでは、<database_name> は ApsaraDB for ClickHouse の同期データベースの名前です。

• 原因：高メモリ使用量。

  解決策：max_insert_threads パラメーターを調整してメモリ使用量を削減します。

• 原因：insert into select ステートメントを使用して ClickHouse クラスター間でデータをインポートしています。

  解決策：ファイルからデータをインポートすることでデータを移行します。セルフマネージド ClickHouse インスタンスから ApsaraDB for ClickHouse Community Edition へのデータ移行。

ClickHouse サーバーは、複数のレベルでメモリ使用量を追跡します。単一のクエリでは、メモリトラッカーがすべてのクエリスレッドのメモリ使用量を集約します。このトラッカーは、全体のメモリトラッカーに報告します。解決策は、発生するエラーに応じて異なります。

• Memory limit (for query) のエラーは、クエリがメモリを過剰に消費し、インスタンスメモリ容量の 70% の制限を超えたために失敗したことを意味します。これを解決するには、垂直アップグレードを実行してインスタンスメモリ容量を増やしてください。

• Memory limit (for total) のエラーは、インスタンス全体のメモリ使用量がインスタンスメモリ容量の 90% のシステム全体の制限を超えたことを意味します。このエラーは、クエリの同時実行数が高いことや、データ書き込み後に実行されるプライマリキーマージタスクなどのリソース集約型のバックグラウンド非同期タスクが原因で発生する可能性があります。まず、クエリの同時実行数を減らしてみてください。エラーが続く場合は、垂直アップグレードを実行してインスタンスメモリ容量を増やしてください。

サーバーのデフォルトの最大クエリ同時実行数は 100 です。この値はコンソールで変更できます。

1. ApsaraDB for ClickHouse コンソール にログインします。

2. クラスターリスト ページで、Community Edition インスタンスのリスト を選択し、対象のクラスター ID をクリックします。

3. 左側のナビゲーションウィンドウで、パラメーター設定 をクリックします。

4. パラメーター設定ページで、max_concurrent_queries パラメーターの パラメーター値の実行 列の編集アイコンをクリックします。

5. ダイアログボックスに新しい値を入力し、を決定 をクリックします。

6. パラメーターの送信 をクリックします。

7. を決定 をクリックします。

以下の解決策を検討してください。

• マルチノードクラスターを使用しているかどうかを確認します。マルチノードクラスターでは、分散テーブルを作成する必要があります。このテーブルに書き込みおよびクエリを実行することで、一貫した結果を得られます。これを行わないと、各クエリが異なるシャードにヒットする可能性があります。分散テーブルの作成。

• マスターレプリカクラスターを使用しているかどうかを確認します。マスターレプリカクラスターでは、レプリカ間でデータを同期するために Replicated シリーズのテーブルエンジンを使用するテーブルを作成する必要があります。これを行わないと、各クエリが異なるレプリカにヒットし、結果が一貫しなくなる可能性があります。Replicated シリーズのテーブルエンジンを使用したテーブルを作成するには、「テーブルエンジン」をご参照ください。

一般的な原因と解決策：

• 原因 1：テーブル作成プロセスが正しくありません。ClickHouse 分散クラスターには、ネイティブの分散 DDL セマンティクスがありません。セルフマネージド ClickHouse クラスターで create table ステートメントを使用すると、成功メッセージが返される場合がありますが、テーブルは現在接続しているサーバーにのみ作成されます。別のサーバーに接続すると、テーブルは表示されません。

  解決策：

  1. テーブルを作成する際は、create table <table_name> on cluster default ステートメントを使用します。on cluster default 句により、ステートメントがデフォルトクラスターのすべてのノードにブロードキャストされます。

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. test テーブルの上に分散テーブルエンジンを使用した別のテーブルを作成します。

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• 原因 2：ReplicatedMergeTree テーブルの設定が誤っています。ReplicatedMergeTree テーブルエンジンは、マスターレプリカ同期を提供する MergeTree テーブルエンジンの拡張版です。シングルレプリカインスタンスでは、MergeTree エンジンを使用したテーブルのみを作成できます。マスターレプリカインスタンスでは、ReplicatedMergeTree エンジンを使用したテーブルを作成する必要があります。

  解決策：マスターレプリカインスタンスでテーブルを作成する際は、ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') または ReplicatedMergeTree() を使用して、ReplicatedMergeTree テーブルエンジンを設定します。ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') の引数は固定テンプレートの一部であり、変更しないでください。

primary key merge が正しく機能するには、次の 2 つの前提条件を満たす必要があります。

• ORDER BY キーに ストレージテーブル の パーティションキー が含まれている必要があります。primary key merge は異なるパーティション間では実行されません。

• 分散テーブル の場合、ORDER BY キーに ハッシュアルゴリズム で決定されるシャーディングキーが含まれている必要があります。primary key merge は異なるノード間では実行されません。

次の表は、一般的な optimize コマンドとその動作を説明しています。

一般的な原因とその解決策を以下に示します。

• 原因 1：データ TTL のエビクションはプライマリキーマージフェーズ中に発生します。データパーツが長期間マージされない場合、その中に含まれる期限切れデータをシステムがエビクションできません。

  解決策：

  • optimize final または 特定のパーティションの optimize を実行して、マージタスクを手動でトリガーできます。

  • テーブル作成時に、期限切れデータを含むデータパーツをより頻繁にマージするための merge_with_ttl_timeout や ttl_only_drop_parts などのパラメーターを設定できます。

• 原因 2：テーブルの TTL が変更または追加された場合、既存のデータパーツに TTL 情報が欠落しているか、不正確である可能性があります。これにより、期限切れデータのエビクションが妨げられる可能性があります。

  解決策：

  • alter table materialize ttl を実行して、TTL 情報を再生成できます。

  • optimize partition を実行して、TTL 情報を更新できます。

ローカルテーブルを変更するには、DDL ステートメントを実行します。分散テーブルの場合は、テーブルにデータが書き込まれているかどうかによって手順が異なります。

• テーブルにデータが書き込まれていない場合、まずローカルテーブルを変更し、次に分散テーブルを変更します。

• テーブルにデータが書き込まれている場合、変更の種類によって手順が異なります。

  種類	操作
  NULL 許容カラムの追加	ローカルテーブルを変更します。 分散テーブルを変更します。
  カラムのデータ型の変更（変換可能な型）
  NULL 許容カラムの削除	分散テーブルを変更します。 ローカルテーブルを変更します。
  NULL 非許容カラムの追加	データ書き込みを停止します。 分散テーブルで SYSTEM FLUSH DISTRIBUTED を実行します。 ローカルテーブルを変更します。 分散テーブルを変更します。 データ書き込みを再開します。
  NULL 非許容カラムの削除
  カラム名の変更

以下の解決策をお試しください。

• 操作が完了するまで待ちます。

• コンソールでクエリを終了させてみてください。

• 原因 1：ClickHouse クライアントが構文を解析します。ただし、set global on cluster default はサーバー側の構文です。クライアントバージョンがサーバーと互換性がない場合、クライアントがこのステートメントをブロックします。

  解決策：

  • クライアント側の構文解析を行わないツールを使用します。例：DataGrip や DBeaver などの JDBC ベースのツール。

  • JDBC プログラムを記述してステートメントを実行します。

• 原因 2：set global on cluster default key = value; ステートメントで、value が文字列であるにもかかわらず、引用符で囲まれていません。

  解決策：文字列値を引用符で囲んでください。

各テーブルが使用しているディスク領域を表示するには、次のクエリを実行します。

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

次のクエリ例を示します。

SELECT * FROM system.disks;

次のクエリを使用します。

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

データパーティションをコールドストレージに移動するには、次のステートメントを実行します。

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

一般的な原因は以下のとおりです。

• OOM エラーをトリガーするクエリ。

• 設定変更によってトリガーされたインスタンスの再起動。

• アップグレードまたはスペックダウン後のインスタンスの再起動。

次の表は、一般的なシステムテーブルとその機能を説明しています。

ユーザーレベルのパラメーターは、users.xml ファイルの設定項目に対応しています。パラメーターを変更するには、次のステートメントを実行します。

SET global ON cluster default ${key}=${value};

実行ステートメントの settings にクォータパラメーターを指定します。

settings max_memory_usage = XXX;

デュアルレプリカ または シングルレプリカ のマルチノード クラスターでは、書き込みノード は大量の 書き込み操作 中に他の ノード よりも CPU 使用量 および メモリ使用量 が高くなります。データが同期されると、使用量はノード間で均等になります。

• 問題の説明：

  エラーのトラブルシューティングや潜在的な問題の特定のために、詳細なシステムログを表示する方法。

• 解決策：

  1. クラスターの text_log.level パラメーターを確認し、以下のいずれかを実行します。

     1. text_log.level が空の場合、テキストロギングは無効になっています。これを有効にするには、このパラメーターに値を設定します。

     2. text_log.level に値が設定されている場合、ログレベルが要件を満たしているかどうかを確認します。満たしていない場合は、パラメーターを目的のレベルに変更します。

     text_log.level パラメーターの表示および変更方法については、「config.xml パラメーターの設定」をご参照ください。

  2. 対象のデータベースに接続します。データベースへの接続。

  3. 次のステートメントを実行してログを表示および分析します。

     SELECT * FROM system.text_log;

送信先クラスターとデータソースが同じ VPC およびリージョン内にある場合は、それぞれの IP アドレスが相手のホワイトリストに含まれていることを確認します。

• ClickHouse でホワイトリストを設定するには、「ホワイトリストの設定」をご参照ください。

• 他のデータソースについては、それぞれのプロダクトドキュメントをご参照ください。

上記の条件を満たしていない場合は、まず適切なネットワークソリューションを使用して接続性を確立します。その後、それぞれの IP アドレスを相手のホワイトリストに追加します。

はい、ClickHouse Community Edition クラスターを Enterprise Edition クラスターに移行できます。

Enterprise Edition と Community Edition クラスター間でデータを移行するには、主に remote 関数を使用する方法と、データファイルをエクスポートおよびインポートする方法の 2 通りがあります。詳細な手順については、「セルフマネージド ClickHouse クラスターから Alibaba Cloud ClickHouse Community-Compatible Edition へのデータ移行」をご参照ください。

デフォルトでは、Enterprise Edition 24.5 以降のインスタンスは、クエリエンジンで新しいアナライザを使用します。この新しいアナライザはクエリパフォーマンスを向上させますが、一部のレガシー SQL ステートメントとの下位互換性がないため、解析エラーが発生する可能性があります。このエラーが発生した場合は、次のステートメントを実行してレガシーアナライザに戻します。詳細については、「新しいアナライザの詳細」をご参照ください。

SET allow_experimental_analyzer = 0;

一時停止機能は、Enterprise Edition クラスターでのみ利用できます。ClickHouse Community Edition クラスターは一時停止できません。Enterprise Edition クラスターを一時停止するには、[Enterprise Edition クラスターページ] に移動します。左上隅で対象のリージョンを選択します。クラスターリストで対象のクラスターを見つけ、> [一時停止] を 操作 列でクリックします。