ApsaraDB for ClickHouse:よくある質問

安定性を確保するために、ApsaraDB for ClickHouseでオープンソースのClickHouseの複数のバグが修正されました。 ApsaraDB for ClickHouseは、ユーザーにバインドされているリソースキューに優先順位を割り当てるためのリソースキュー機能を提供します。

この問題を解決するには、次の操作を実行します。

• ネットワーク接続が確立されているかどうかを確認します。 pingコマンドを実行して、ネットワーク接続のステータスを確認できます。 telnetコマンドを実行して、ApsaraDB for ClickHouseクラスターのポート3306とポート8123が有効になっているかどうかを確認することもできます。

• 接続先のApsaraDB for ClickHouseクラスターにホワイトリストが設定されているかどうかを確認します。 ApsaraDB For ClickHouseクラスターのホワイトリストを設定する方法の詳細については、「ホワイトリストの設定」をご参照ください。

• クライアントの実際のIPアドレスが使用されているかどうかを確認します。 企業の内部ネットワークを介して接続されているマシンのIPアドレスは頻繁に変更されます。 このように、取得するクライアントIPアドレスは、クライアントの実際のIPアドレスではない可能性があります。 WhatsMyIPなどのIPアドレスチェックツールを使用して、クライアントの実際のIPアドレスを取得できます。 詳細については、「WhatsMyIP」をご参照ください。

V20.3またはV20.8のApsaraDB for ClickHouseクラスターに外部テーブルを作成すると、システムはApsaraDB for ClickHouseクラスターと外部プラットフォーム間のネットワーク接続を自動的に検証します。 外部テーブルが作成されると、ネットワーク接続が確立されます。 次のいずれかの原因により、外部テーブルの作成に失敗することがあります。

• 接続するテーブルは、ApsaraDB for ClickHouseクラスターと同じVPCにないクラスターにデプロイされています。 この場合、ネットワーク接続が確立されない。

• 接続先のMySQLインスタンスにホワイトリストが設定されています。 ApsaraDB for ClickHouseクラスターが接続されているVPCのCIDRブロックはホワイトリストに含まれていません。 この場合、CIDRブロックをホワイトリストに追加します。

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: VPC設定またはインターネットアクセス設定が不適切です。 アプリケーションとクラスターが同じVPCにデプロイされている場合、内部ネットワークを介してアプリケーションをクラスターに接続できます。 アプリケーションとクラスターが異なるVPCにデプロイされている場合は、クラスターのパブリックエンドポイントを申請します。

  解決策: アプリケーションとクラスターが異なるVPCにデプロイされている場合は、クラスターのパブリックエンドポイントを申請します。 詳細については、「パブリックエンドポイントの申請とリリース」をご参照ください。

• 原因2: アプリケーションのIPアドレスがクラスターのホワイトリストに追加されていません。

  解決策: アプリケーションのIPアドレスをクラスターのホワイトリストに追加します。 詳細は、ホワイトリストの構成をご参照ください。

• 原因3: クラスターが実行されているElastic Compute Service (ECS) インスタンスのセキュリティグループがアクセストラフィックを拒否します。

  解決策: クラスターが実行されるElastic Compute Service (ECS) インスタンスのセキュリティグループを有効にして、アクセストラフィックを許可します。 詳細については、「セキュリティグループの操作」をご参照ください。

• 原因4: 企業がネットワークファイアウォールを使用しています。

  解決策: ファイアウォールのルールを変更します。

• 原因5: 接続文字列のアカウントパスワードには、!@#$%^& *()_+= のいずれかの特殊文字が含まれています。 これらの特殊文字は接続中に認識できません。 その結果、アプリケーションはApsaraDB for ClickHouseクラスターへの接続に失敗します。

  解決策: 次のエスケープルールを使用して、接続文字列内の特殊文字をエスケープします。

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

  たとえば、パスワードがab @#cの場合、パスワードのエスケープ文字は接続文字列のab % 40% 23cです。

• 原因6: ApsaraDB for ClickHouseクラスターは、デフォルトでClassic Load Balancer (CLB) インスタンスにアタッチされています。 CLBインスタンスは、従量課金で課金されます。 Alibaba Cloudアカウントに料金滞納がある場合、ApsaraDB for ClickHouseクラスターにアクセスできない可能性があります。

  解決策: Alibaba Cloudアカウントに料金滞納があるかどうかを確認します。 延滞支払いが存在する場合は、できるだけ早い機会に延滞支払いを返済してください。

この問題を解決するには、次の操作を実行します。

• OSSオブジェクトを複数のオブジェクトに分割します。 次に、これらのオブジェクトからApsaraDB for ClickHouseクラスターの外部テーブルにデータをインポートします。

• ApsaraDB for ClickHouseクラスターのメモリ容量をスケールアップします。 詳細については、「ApsaraDB For ClickHouse Community互換Editionクラスターの設定の変更」をご参照ください。

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: 指定されたパラメーター値がシナリオに適していません。 ApsaraDB for ClickHouseでは、複数のバッチでデータを書き込むことを推奨します。 各バッチに大量のデータが含まれていること、および少数の同時データ書き込みタスクが同時に実行されることを確認します。 ほとんどの場合、データのバッチには数万行、さらには数十万行が含まれる可能性があります。 これは、単一の行のサイズに依存します。 ほとんどの場合、行の推定サイズは100バイトです。 行サイズを見積もり、行サイズに基づいて行数を計算する必要があります。

  解決策: 同時書き込み要求の最大数を10に設定します。 パラメータの設定を変更して、もう一度試すことができます。

• 原因2: DataWorksで作成された排他的リソースグループでは、ECSインスタンスの仕様が低くなっています。 排他的リソースグループでは、CPUコアまたはメモリの仕様が低いため、要求の同時実行性またはアウトバウンド帯域幅に制限が課される可能性があります。 バッチサイズを大きく指定してもメモリ容量が不足している場合、DataWorks Javaプロセスでガベージコレクションが発生する可能性があります。

  解決策: DataWorksの出力ログに基づいて、ECSインスタンスの仕様を確認します。

• 原因3: データソースで読み取り操作を実行するのに長い時間が必要です。

  解決策: DataWorksの出力ログでtotalWaitReaderTimeとtotalWaitWriterTimeを検索します。 totalWaitReaderTimeの値がtotalWaitWriterTimeの値よりもはるかに大きい場合、読み出し動作を実行するためには、書き込み動作を実行するために必要な時間よりも長い時間が必要とされる。

• 原因4: パブリックエンドポイントが使用されています。 パブリックエンドポイントの帯域幅は限られており、高パフォーマンスのデータのインポートまたはエクスポートを保証できません。

  解決策: パブリックエンドポイントをVPCエンドポイントに置き換えます。

• 原因5: データソースにダーティデータが含まれています。 通常、データはバッチで書き込まれます。 ダーティデータがデータソースから読み取られた場合、書き込まれているデータのバッチは失敗し、データの行が毎回書き込まれます。 また、多数のデータ部が生成される。 これにより、書き込み動作が遅くなる。

  ダーティデータが書き込まれているかどうかは、次の方法で確認できます。

  • データを照会し、返されたエラーメッセージを確認します。 メッセージに「解析できません」が含まれている場合、ダーティデータが書き込まれます。

    次のサンプルコードを実行できます。

    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;

  • データのバッチが書き込まれた後、行数を確認します。 行数が1の場合、ダーティデータが書き込まれます。

    次のサンプルコードを実行できます。

    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を使用している場合、ApsaraDB for ClickHouseクラスターの外部テーブルは、Hiveインスタンスのテーブルと比較して行数が少ない場合があります。

3. Hiveインスタンスに格納されているテーブルの行数が正しいかどうかを確認します。

表間の行数の不整合の原因を特定するには、次の手順を実行します。

1. query_logという名前のシステムテーブルに基づいて、データ同期中にエラーが報告されているかどうかを確認します。 エラーが報告されると、データ損失が発生する可能性があります。

2. 使用するテーブルエンジンで重複を削除できるかどうかを確認します。 ReplacingMergeTreeを使用する場合、ApsaraDB for ClickHouseクラスターの外部テーブルは、Kafkaインスタンスのテーブルと比較して行数が少ない場合があります。

3. 外部テーブルにkafka_skip_broken_messagesパラメーターが設定されているかどうかを確認します。 このパラメーターが設定されている場合、ApsaraDB for ClickHouseは、解析に失敗したKafkaメッセージをスキップする可能性があります。 その結果、ApsaraDB for ClickHouseクラスターの外部テーブルは、Kafkaインスタンスのテーブルよりも行数が少ない場合があります。

この問題を解決するには、次の操作を実行します。

• clickhouse-clientを使用して、ファイルをエクスポートしてデータを移行します。 詳細については、「セルフマネージドClickHouseクラスターからApsaraDB For ClickHouseクラスターへのデータの移行」をご参照ください。

• 次の文を実行して, リモート関数でデータを移行します。

  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でMaterializeMySQLエンジンを使用するデータベースの名前を指定します。

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: メモリ使用量が多い。

  解決策: max_insert_threadsパラメーターの設定を変更して、メモリ使用量を減らします。

• 原因2: INSERT INTO SELECTステートメントを実行して、あるApsaraDB for ClickHouseクラスターから別のクラスターにデータをインポートしました。

  解決策: ファイルをターゲットクラスターにインポートしてデータを移行します。 詳細については、「セルフマネージドClickHouseクラスターからApsaraDB For ClickHouseクラスターへのデータの移行」をご参照ください。

ApsaraDB for ClickHouseサーバーは、各クエリスレッドにメモリトラッカーを提供します。 各クエリのすべてのスレッドのメモリトラッカーは、クエリ用のメモリトラッカーと呼ばれるメモリトラッカーにメモリ使用量を報告します。 次に、クエリ用のメモリトラッカは、取得した情報を、合計でメモリトラッカと名付けられた上位層のメモリトラッカに報告する。 この問題を解決するには、シナリオに基づいて次の操作を実行します。

• 「Memory limit (for query) 」メッセージが返された場合、クラスタメモリの70% 以上がクエリによって消費されます。 メモリ仕様をスケールアップすることを推奨します。

• 「メモリ制限 (合計) 」メッセージが返された場合、クラスタメモリの90% 以上が消費されます。 同時クエリの数を減らすことを推奨します。 この操作を実行しても問題が解決しない場合は、バックグラウンドで非同期タスクによって大量のメモリが消費される可能性があります。 ほとんどの場合、データが書き込まれた後に同じプライマリキー値を含むレコードの重複排除は、大量のメモリを消費します。 メモリ仕様をスケールアップすることを推奨します。

デフォルトでは、ApsaraDB for ClickHouseサーバーでの同時クエリの最大数は100です。 ApsaraDB for ClickHouseコンソールで値を変更できます。 同時クエリの最大数を変更するには、次の手順を実行します。

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

2. [クラスター] ページで、[デフォルトインスタンス] タブをクリックし、管理するクラスターのIDをクリックします。

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

4. max_concurrent_queriesパラメーターの値を変更します。 有効な値を入力し、[OK] をクリックします。

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

6. [OK] をクリックします。

この問題を解決するには、次の操作を実行します。

• ApsaraDB for ClickHouseクラスターがマルチノードクラスターであるかどうかを確認します。 ApsaraDB for ClickHouseクラスターに複数のノードがある場合、ノードに分散テーブルを作成する必要があります。 次に、分散テーブルにデータを書き込み、分散テーブルからデータをクエリできます。 これにより、文を実行して分散テーブルからデータをクエリするたびに、同じクエリ結果が返されます。 分散テーブルを使用しない場合、ステートメントを実行するたびに異なるシャードのデータが照会される可能性があります。 その結果、同じステートメントに対して異なるクエリ結果が返されます。 分散テーブルの作成方法の詳細については、「テーブルの作成」をご参照ください。

• ApsaraDB for ClickHouseクラスターがDouble-replica Editionであるかどうかを確認します。 Double-replica EditionのApsaraDB for ClickHouseクラスターを使用する場合は、ノードにレプリケートされたテーブルを作成します。 これにより、ノードのレプリカ間でデータの一貫性が確保されます。 レプリケートされたテーブルを作成しない場合、クエリ結果は、クエリされるレプリカによって異なる場合があります。 レプリケートされたテーブルを作成する方法の詳細については、「テーブルエンジン」をご参照ください。

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: 無効なDDLステートメントを使用して、ApsaraDB for ClickHouseクラスターにテーブルが作成されます。 分散ApsaraDB for ClickHouseクラスターにテーブルを作成するには、create tableステートメントにON clusterデフォルト句を含める必要があります。 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という名前のテーブルに分散テーブルエンジンを作成します。 次のステートメントを実行して、test_disという名前の分散テーブルを作成できます。

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

• 原因2: ReplicatedMergeTreeテーブルの設定が正しくありません。 ReplicatedMergeTreeテーブルエンジンは、MergeTreeテーブルエンジンに基づいて開発され、レプリケートされたテーブル間でデータを同期するために使用できます。 シングルレプリカエディションのApsaraDB for ClickHouseクラスターで作成できるのは、MergeTreeテーブルエンジンのみです。 Double-replica EditionのApsaraDB for ClickHouseクラスターで作成できるのは、ReplicatedMergeTreeテーブルエンジンのみです。

  解決策: Double-replica EditionのApsaraDB for ClickHouseクラスターでテーブルを作成する場合、ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') またはReplicatedMergeTree() を使用して、ReplicatedMergeTreeテーブルエンジンを設定します。 ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') は固定構成であり、変更する必要はありません。

OPTIMIZEステートメントを実行する前に、次の条件が満たされていることを確認してください。 これにより、同じ主キー値を含むレコードの重複排除に使用されるロジックが有効になります。

• データを格納するテーブルを定義する場合、PARTITION BY句で指定されたフィールドは、order by句で指定されたフィールドに含まれている必要があります。 異なるパーティション内の2つのレコードが同じ主キー値を含む場合、レコードは重複排除されません。

• 分散テーブルを定義する場合、ハッシュするフィールドは、order by句で指定されたフィールドに含まれている必要があります。 異なるノード上の2つのレコードが同じ主キー値を含む場合、レコードは重複排除されません。

次の表に、一般的なOPTIMIZEステートメントを示します。

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: 同じ主キー値を含むレコードが重複排除されている場合、指定されたTTL値に基づいて立ち退きが発生します。 データ部分で同じ主キー値を含むレコードが長期間重複排除されない場合、期限切れのレコードは削除できません。

  解決策：

  • FINAL句またはPARTITION句を使用してOPTIMIZE TABLEステートメントを実行し、同じ主キー値を含むレコードの重複排除タスクをトリガーできます。

  • テーブルを作成するときに、merge_with_ttl_timeoutやttl_only_drop_partsなどのパラメーターを設定して、期限切れデータを含むデータ部分で同じプライマリキー値を含むレコードの重複排除の頻度を増やすことができます。

• 原因2: テーブルのTTLが指定または変更されています。 その結果、既存のデータ部分でTTL情報が不完全または正しくない場合があり、期限切れのデータを削除できない場合があります。

  解決策：

  • ALTER TABLE materialize ttlステートメントを実行して、TTLを再構成できます。

  • OPTIMIZE TABLE test PARTITION tuple(); ステートメントを実行して、TTLを更新できます。

ローカルテーブルの場合、DDLステートメントを実行して、列を作成、削除、または変更できます。 分散テーブルの場合、次のいずれかの方法を使用して、さまざまなシナリオで列を作成、削除、または変更できます。

• 分散テーブルにデータが書き込まれていない場合は、ローカルテーブルと分散テーブルの列を作成、削除、または変更できます。

• 分散テーブルにデータを書き込む場合は、次のいずれかの手順で別の操作を実行できます。

  タイプ	API 操作
  null許容列を作成します。	ローカルテーブルで列を作成または変更します。 分散テーブルの列を作成または変更します。
  データ型変換がサポートされている場合は、列のデータ型を変更します。
  null許容列を削除します。	分散テーブルの列を作成または変更します。 ローカルテーブルで列を作成または変更します。
  null非許容列を作成します。	データの書き込みを停止します。 SYSTEM FLUSH DISTRIBUTEDステートメントを実行します。 ローカルテーブルで列を作成または変更します。 分散テーブルの列を作成または変更します。 分散テーブルへのデータの書き込みを再開します。
  null設定できない列を削除します。
  列の名前を変更します。

この問題を解決するには、次の操作を実行します。

• すべてのDDL文が実行されるまで待ちます。

• ApsaraDB for ClickHouseコンソールでのDDLステートメントの実行を停止します。

• ApsaraDB for ClickHouseコンソールで、クラスターの詳細ページに移動します。 左側のナビゲーションウィンドウで、[パラメーター設定] をクリックします。 表示されるページで、パラメーターの値を変更し、パラメーターの前の値を保持します。 次に、[パラメーターの送信] をクリックします。

  説明

  パラメーターの値を変更する方法の詳細については、同時クエリの数が上限を超えた場合はどうすればよいですか?

この問題については、次のセクションで一般的な原因と解決策を説明します。

• 原因1: ApsaraDB for ClickHouseクライアントがステートメントの構文を解析します。 ただし、SET GLOBAL ON CLUSTER defaultステートメントは、ApsaraDB for ClickHouseサーバーでのみ有効です。 クライアントのバージョンがサーバーのバージョンと一致しない場合、SET GLOBAL ON CLUSTERの既定のステートメントを実行すると、クライアントは構文エラーを報告します。

  解決策：

  • クライアントのステートメントの構文を解析しないツールを使用します。 たとえば、DataGripまたはDBeaverをJDBCドライバーで使用できます。

  • SET GLOBAL ON CLUSTERの既定のステートメントを実行するJDBCプログラムを作成することもできます。

• 原因2: SET GLOBAL ON CLUSTER defaultステートメントで単一引用符 (') で囲まれていない文字列値を指定しました。

  解決策: SET GLOBAL ON CLUSTERのデフォルトステートメントの文字列値を単一引用符 ('') で囲みます。

各テーブルで使用されているディスク容量を確認するには、次のサンプル文を実行します。

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;

宛先クラスターとデータソースが同じリージョンにデプロイされ、同じVPCを使用している場合は、宛先クラスターのIPアドレスがデータソースのホワイトリストに追加されているかどうか、およびデータソースのIPアドレスが宛先クラスターのホワイトリストに追加されているかどうかを確認します。 IPアドレスがホワイトリストに追加されていない場合は、ホワイトリストを設定します。

• ApsaraDB For ClickHouseクラスターのホワイトリストを設定する方法の詳細については、「ホワイトリストの設定」をご参照ください。

• データソースのホワイトリストを設定する方法の詳細については、対応するサービスドキュメントをご参照ください。

それ以外の場合は、適切なネットワークソリューションを選択してネットワーク接続の問題を解決し、IPアドレスをホワイトリストに追加します。