ApsaraDB for ClickHouse：常見問題

雲資料庫ClickHouse主要對社區版本進行穩定性Bug修複，同時提供資源隊列進行使用者角色層級的資源使用優先順序配置。

您可以採取如下解決方案。

• 檢查網路是否暢通。通過ping命令檢查網路是否通暢，通過telnet命令探測資料庫3306和8123連接埠是否開放。

• 檢查是否配置了ClickHouse白名單，配置方法請參見 設定白名單。

• 檢查用戶端機器IP是否正確。通常公司辦公網內的機器IP經常變動，使用者看到的不是正確的IP地址。通過訪問專業IP探查服務確定真實IP，樣本請參見whatsmyip。

目前20.3和20.8版本在建立相關外表時程式內會自動進行驗證，如果建立表成功，那說明網路是通的。如果無法建立成功，常見原因如下。

• 目標端和ClickHouse不在同一個VPC內，網路無法連通。

• MySQL端存在白名單相關設定，需要在MySQL端添加ClickHouse的白名單。

常見原因及解決方案如下。

• 常見原因1：VPC網路、公網網路環境不對。同一VPC內可用內網串連，不在同一VPC內需開設公網後串連。

  解決方案：開通公網詳情請參見申請和釋放外網地址。

• 常見原因2：白名單未配置。

  解決方案：設定白名單詳情請參見設定白名單。

• 常見原因3：ECS安全性群組未放開。

  解決方案：開放安全性群組詳情請參見安全性群組操作指引。

• 常見原因4：公司設定了網路防火牆。

  解決方案：修改防火牆規則。

• 常見原因5：串連串中的帳號密碼包含特殊字元!@#$%^&*()_+=，這些特殊字元在串連時無法被識別，導致執行個體串連失敗。

  解決辦法：您需要在串連串中對特殊字元進行轉義處理，轉義規則如下。

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

  樣本：密碼為ab@#c時，在串連串中對特殊字元進行轉義處理，密碼對應為ab%40%23c。

• 常見原因6：雲資料庫ClickHouse會預設為您掛載CLB。CLB為隨用隨付，如果您的帳號欠費可能會導致您的雲資料庫ClickHouse無法訪問。

  解決辦法：查詢阿里雲帳號是否欠費。如果欠費請及時進行繳費。

您可以採取如下解決方案。

• 把OSS上的檔案拆分為一個一個的小檔案，然後再進行匯入。

• 進行記憶體的升配。如何升配，請參見社區相容版叢集垂直變更配置和水平擴縮容。

常見原因及解決方案如下。

• 常見原因1：參數設定不合理。ClickHouse適合使用大batch、少數幾個並發進行寫入。多數情況下batch可以高達幾萬甚至幾十萬（取決於您的單行RowSize大小，一般按照每行100Byte進行評估，您需要根據實際資料特徵進行估算）。

  解決方案：並發數建議不超過10個。您可以調整不同參數進行嘗試。

• 常見原因2：DataWorks獨享資源群組的ECS規格太小。比如獨享資源的CPU、Memory太小，導致並發數、網路出口頻寬受限；或者是batch設定太大而Memory太小，引起DataWorks進程Java GC等。

  解決方案：您可以通過DataWorks的輸出日誌對ECS規格大小進行確認。

• 常見原因3：從資料來源中讀取慢。

  解決方案：您可以在DataWorks輸出日誌中搜尋totalWaitReaderTime、totalWaitWriterTime，如果發現totalWaitReaderTime明顯大於totalWaitWriterTime，則表明主要耗時在讀取端，而不是寫入端。

• 常見原因4：使用了公網Endpoint。公網Endpoint的頻寬非常有限，無法承載高效能的資料匯入匯出。

  解決方案：您需要替換為VPC網路的Endpoint。

• 常見原因5：有髒資料。在沒有髒資料的情況下，資料以batch方式寫入。但是遇到了髒資料，正在寫入的batch就會失敗，並回退到逐行寫入，產生大量的data part，大幅度降低了寫入速度。

  您可以參考如下兩種方式判斷是否有髒資料。

  • 查看報錯資訊，如果返回資訊包含Cannot parse，則存在髒資料。

    代碼如下。

    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，則存在髒資料。

    代碼如下。

    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中的Count小於Hive中的情況。

3. 重新確認Hive中資料行數的正確性，很有可能出現源頭的行數確定錯誤的情況。

您可以通過以下手段進行排查。

1. 首先通過系統資料表query_log來查看匯入的過程中是否有報錯，如果有報錯，那很有可能出現資料丟失的情況。

2. 確定使用的表引擎是否可以去重，比如使用ReplacingMergeTree，那很可能出現ClickHouse中的Count小於Kafka中的情況。

3. 查看Kafka外表的配置是否有kafka_skip_broken_messages參數的配置，如果有該參數，那可能會跳過解析失敗的Kafka訊息，導致ClickHouse總的行數是小於Kafka中的。

您可以採取如下方案。

• 通過ClickHouse Client以匯出檔案的形式進行資料移轉，詳情請參見將自建ClickHouse資料移轉到雲ClickHouse中。

• 通過Remote函數進行資料的遷移。

  INSERT INTO <目的表> SELECT * FROM remote('<串連串>', '<庫>', '<表>', '<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>為雲資料庫ClickHouse中同步的資料庫。

常見原因及解決方案如下。

• 常見原因1：記憶體使用量率比較高。

  解決方案：調整參數max_insert_threads，減少可能的記憶體使用量量。

• 常見原因2：當前是通過insert into select把資料從一個ClickHouse叢集匯入到另外一個叢集。

  解決方案：通過匯入檔案的方式來遷移資料，更多資訊請參見將自建ClickHouse資料移轉到雲ClickHouse中。

ClickHouse服務端對所有查詢線程都配有memory tracker，同一個查詢下的所有線程tracker會彙報給一個memory tracker for query，再上層還是memory tracker for total。您可以根據情況採取如下解決方案。

• 遇到Memory limit (for query)超限報錯說明是查詢記憶體佔用過多（執行個體總記憶體的70%）導致失敗，這種情況下您需要垂直升配提高執行個體記憶體規模。

• 遇到Memory limit (for total)超限報錯說明是執行個體總記憶體使用量超限（執行個體總記憶體的90%），這種情況下您可以嘗試降低查詢並發，如果仍然不行則可能是後台非同步任務佔用了比較大的記憶體（常常是寫入後主鍵合并任務），您需要垂直升配提高執行個體記憶體規模。

預設Server查詢最大並發數為100，您可以在控制台上進行修改。修改運行參數值具體操作步驟如下。

1. 登入雲資料庫ClickHouse控制台。

2. 在叢集列表頁面，選擇預設執行個體列表，單擊目的地組群ID。

3. 在叢集資訊頁面單擊導覽列左側的參數配置。

4. 修改max_concurrent_queries參數的運行參數值，輸入修改值並單擊確定。

5. 單擊提交參數。

6. 單擊確定。

您可以採取如下解決方案。

• 檢查是否是多節點叢集。多節點叢集需要建立分布式表，往分布式表裡寫入資料並查詢，每次查詢結果一致。否則每次查詢到不同分區的資料，結果不一致。如何建立分布式表請參見建立分布式表。

• 檢查是否是多複本集群。多複本集群需要建Replicated系列表引擎的表，才能實現副本間資料同步。否則每次查到不同副本，結果不一致。如何建立Replicated系列表引擎的表請參見表引擎。

常見原因及解決方案如下。

• 常見原因1：建表流程存在問題。ClickHouse的分布式叢集搭建並沒有原生的分布式DDL語義。如果您在自建ClickHouse叢集時使用create table建立表，查詢雖然返回了成功，但實際這個表只在當前串連的Server上建立了。下次串連重設換一個Server，您就看不到這個表了。

  解決方案：

  1. 建表時，請使用create table <table_name> on cluster default語句，on cluster default聲明會把這條語句廣播給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}')為固定配置，無需修改。

首先為了讓資料有正確的主鍵合并邏輯，需要保證以下兩個前提條件。

• 儲存表裡的partition by定義欄位必須是包含在order by裡的，不同分區的資料不會主鍵合并。

• 分布式表裡定義的Hash演算法欄位必須是包含在order by裡的，不同節點的資料不會主鍵合并。

optimize常用命令及相關說明如下。

常見原因及解決方案如下。

• 常見原因1：資料的TTL淘汰是在主鍵合并階段執行的，如果data part遲遲沒有進行主鍵合并，那到期的資料就無法淘汰。

  解決方案：

  • 您可以通過手動optimize final或者optimize 指定分區的方式觸發合并任務。

  • 您可以在建表時設定merge_with_ttl_timeout、ttl_only_drop_parts等參數，提高含有到期資料data parts的合并頻率。

• 常見原因2：表的TTL經過修改或者添加，存量的data part裡缺少TTL資訊或者不正確，這樣也可能導致到期資料淘汰不掉。

  解決方案：

  • 您可以通過alter table materialize ttl命令重建TTL資訊。

  • 您可以通過optimize 分區更新TTL資訊。

本地表的修改直接執行即可。如果要對分布式表進行修改，需分如下情況進行。

• 如果沒有資料寫入，您可以先修改本地表，然後修改分布式表。

• 如果資料正在寫入，您需要區分不同的類型進行操作。

  類型	操作步驟
  增加Nullable的列	修改本地表。 修改分布式表。
  修改列的資料類型（類型可以相互轉換）
  刪除Nullable列	修改分布式表。 修改本地表。
  增加非Nullable的列	停止資料的寫入。 執行SYSTEM FLUSH DISTRIBUTED分布式表。 修改本地表。 修改分布式表。 重新進行資料的寫入。
  刪除非Nullable的列
  修改列的名稱

您可以採取如下解決方案。

• 等待運行結束。

• 在控制台嘗試終止查詢。

• 在雲資料庫ClickHouse控制台的參數配置頁面，對任一參數的參數值進行編輯不修改原來的值，單擊提交參數。

  說明

  如何進行參數值修改請參見修改參數運行值。

常見原因及解決方案如下。

• 常見原因1：ClickHouse用戶端會進行文法解析，而set global on cluster default是服務端增加的文法。在用戶端尚未更新到與服務端對齊的版本時，該文法會被用戶端攔截。

  解決方案：

  • 使用JDBC Driver等不會在用戶端解析文法的工具，比如DataGrip、DBeaver。

  • 編寫JDBC程式來執行該語句。

• 常見原因2：set global on cluster default key = value; 中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;