云數(shù)據(jù)庫ClickHouse主要對社區(qū)版本進(jìn)行穩(wěn)定性Bug修復(fù)，同時提供資源隊列進(jìn)行用戶角色級別的資源使用優(yōu)先級配置。

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

• 檢查網(wǎng)絡(luò)是否暢通。通過ping命令檢查網(wǎng)絡(luò)是否通暢，通過telnet命令探測數(shù)據(jù)庫3306和8123端口是否開放。

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

• 檢查客戶端機(jī)器IP是否正確。通常公司辦公網(wǎng)內(nèi)的機(jī)器IP經(jīng)常變動，用戶看到的不是正確的IP地址。通過訪問專業(yè)IP探查服務(wù)確定真實IP，示例請參見whatsmyip。

目前20.3和20.8版本在創(chuàng)建相關(guān)外表時程序內(nèi)會自動進(jìn)行驗證，如果創(chuàng)建表成功，那說明網(wǎng)絡(luò)是通的。如果無法創(chuàng)建成功，常見原因如下。

• 目標(biāo)端和ClickHouse不在同一個VPC內(nèi)，網(wǎng)絡(luò)無法連通。

• MySQL端存在白名單相關(guān)設(shè)置，需要在MySQL端添加ClickHouse的白名單。

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

• 常見原因1：參數(shù)設(shè)置不合理。ClickHouse適合使用大batch、少數(shù)幾個并發(fā)進(jìn)行寫入。多數(shù)情況下batch可以高達(dá)幾萬甚至幾十萬（取決于您的單行RowSize大小，一般按照每行100Byte進(jìn)行評估，您需要根據(jù)實際數(shù)據(jù)特征進(jìn)行估算）。

  解決方案：并發(fā)數(shù)建議不超過10個。您可以調(diào)整不同參數(shù)進(jìn)行嘗試。

• 常見原因2：DataWorks獨享資源組的ECS規(guī)格太小。比如獨享資源的CPU、Memory太小，導(dǎo)致并發(fā)數(shù)、網(wǎng)絡(luò)出口帶寬受限；或者是batch設(shè)置太大而Memory太小，引起DataWorks進(jìn)程Java GC等。

  解決方案：您可以通過DataWorks的輸出日志對ECS規(guī)格大小進(jìn)行確認(rèn)。

• 常見原因3：從數(shù)據(jù)源中讀取慢。

  解決方案：您可以在DataWorks輸出日志中搜索totalWaitReaderTime、totalWaitWriterTime，如果發(fā)現(xiàn)totalWaitReaderTime明顯大于totalWaitWriterTime，則表明主要耗時在讀取端，而不是寫入端。

• 常見原因4：使用了公網(wǎng)Endpoint。公網(wǎng)Endpoint的帶寬非常有限，無法承載高性能的數(shù)據(jù)導(dǎo)入導(dǎo)出。

  解決方案：您需要替換為VPC網(wǎng)絡(luò)的Endpoint。

• 常見原因5：有臟數(shù)據(jù)。在沒有臟數(shù)據(jù)的情況下，數(shù)據(jù)以batch方式寫入。但是遇到了臟數(shù)據(jù)，正在寫入的batch就會失敗，并回退到逐行寫入，生成大量的data part，大幅度降低了寫入速度。

  您可以參考如下兩種方式判斷是否有臟數(shù)據(jù)。

  • 查看報錯信息，如果返回信息包含Cannot parse，則存在臟數(shù)據(jù)。

    代碼如下。

    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行數(shù)，如果batch行數(shù)變?yōu)?，則存在臟數(shù)據(jù)。

    代碼如下。

    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;

  解決方案：您需要在數(shù)據(jù)源刪除或修改臟數(shù)據(jù)。

您可以通過以下手段進(jìn)行排查。

1. 首先通過系統(tǒng)表query_log來查看導(dǎo)入的過程中是否有報錯，如果有報錯，那很有可能出現(xiàn)數(shù)據(jù)丟失的情況。

2. 確定使用的表引擎是否可以去重，比如使用ReplacingMergeTree，那很可能出現(xiàn)ClickHouse中的Count小于Hive中的情況。

3. 重新確認(rèn)Hive中數(shù)據(jù)行數(shù)的正確性，很有可能出現(xiàn)源頭的行數(shù)確定錯誤的情況。

您可以通過以下手段進(jìn)行排查。

1. 首先通過系統(tǒng)表query_log來查看導(dǎo)入的過程中是否有報錯，如果有報錯，那很有可能出現(xiàn)數(shù)據(jù)丟失的情況。

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

3. 查看Kafka外表的配置是否有kafka_skip_broken_messages參數(shù)的配置，如果有該參數(shù)，那可能會跳過解析失敗的Kafka消息，導(dǎo)致ClickHouse總的行數(shù)是小于Kafka中的。

您可以采取如下方案。

• 通過ClickHouse Client以導(dǎo)出文件的形式進(jìn)行數(shù)據(jù)遷移，詳情請參見將自建ClickHouse數(shù)據(jù)遷移到云ClickHouse中。

• 通過Remote函數(shù)進(jìn)行數(shù)據(jù)的遷移。

  INSERT INTO <目的表> SELECT * FROM remote('<連接串>', '<庫>', '<表>', '<username>', '<password>');

解決方案：重新同步MySQL數(shù)據(jù)，具體步驟如下。

1. 刪除停止同步的表。

   DROP TABLE <table_name> ON cluster default;

   說明

   table_name為停止同步的表名。如果停止同步的表有分布式表，那么本地表和分布式表都需要刪除。

2. 重啟同步進(jìn)程。

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

   說明

   <database_name>為云數(shù)據(jù)庫ClickHouse中同步的數(shù)據(jù)庫。

默認(rèn)Server查詢最大并發(fā)數(shù)為100，您可以在控制臺上進(jìn)行修改。修改運(yùn)行參數(shù)值具體操作步驟如下。

1. 登錄云數(shù)據(jù)庫ClickHouse控制臺。

2. 在集群列表頁面，選擇社區(qū)版實例列表，單擊目標(biāo)集群ID。

3. 單擊左側(cè)導(dǎo)航欄的參數(shù)配置。

4. 在參數(shù)配置頁面，單擊max_concurrent_queries參數(shù)的運(yùn)行參數(shù)值后面的編輯按鈕。

5. 在懸浮框中填寫目標(biāo)值，單擊確定。

6. 單擊提交參數(shù)。

7. 單擊確定。

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

• 檢查是否是多節(jié)點集群。多節(jié)點集群需要創(chuàng)建分布式表，往分布式表里寫入數(shù)據(jù)并查詢，每次查詢結(jié)果一致。否則每次查詢到不同分片的數(shù)據(jù)，結(jié)果不一致。如何創(chuàng)建分布式表請參見創(chuàng)建分布式表。

• 檢查是否是多副本集群。多副本集群需要建Replicated系列表引擎的表，才能實現(xiàn)副本間數(shù)據(jù)同步。否則每次查到不同副本，結(jié)果不一致。如何創(chuàng)建Replicated系列表引擎的表請參見表引擎。

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

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

  解決方案：

  1. 建表時，請使用create table <table_name> on cluster default語句，on cluster default聲明會把這條語句廣播給default集群的所有節(jié)點進(jìn)行執(zhí)行。示例代碼如下。

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

  2. 在test表上再創(chuàng)建一個分布式表引擎，建表語句如下。

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

• 常見原因2：ReplicatedMergeTree存儲表配置有問題。ReplicatedMergeTree表引擎是對應(yīng)MergeTree表引擎的主備同步增強(qiáng)版，在單副本實例上限定只能創(chuàng)建MergeTree表引擎，在雙副本實例上只能創(chuàng)建ReplicatedMergeTree表引擎。

  解決方案：在雙副本實例上建表時，請使用ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')或ReplicatedMergeTree()配置ReplicatedMergeTree表引擎。其中，ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')為固定配置，無需修改。

首先為了讓數(shù)據(jù)有正確的主鍵合并邏輯，需要保證以下兩個前提條件。

• 存儲表里的partition by定義字段必須是包含在order by里的，不同分區(qū)的數(shù)據(jù)不會主鍵合并。

• 分布式表里定義的Hash算法字段必須是包含在order by里的，不同節(jié)點的數(shù)據(jù)不會主鍵合并。

optimize常用命令及相關(guān)說明如下。

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

• 常見原因1：數(shù)據(jù)的TTL淘汰是在主鍵合并階段執(zhí)行的，如果data part遲遲沒有進(jìn)行主鍵合并，那過期的數(shù)據(jù)就無法淘汰。

  解決方案：

  • 您可以通過手動optimize final或者optimize 指定分區(qū)的方式觸發(fā)合并任務(wù)。

  • 您可以在建表時設(shè)置merge_with_ttl_timeout、ttl_only_drop_parts等參數(shù)，提高含有過期數(shù)據(jù)data parts的合并頻率。

• 常見原因2：表的TTL經(jīng)過修改或者添加，存量的data part里缺少TTL信息或者不正確，這樣也可能導(dǎo)致過期數(shù)據(jù)淘汰不掉。

  解決方案：

  • 您可以通過alter table materialize ttl命令重新生成TTL信息。

  • 您可以通過optimize 分區(qū)更新TTL信息。

本地表的修改直接執(zhí)行即可。如果要對分布式表進(jìn)行修改，需分如下情況進(jìn)行。

• 如果沒有數(shù)據(jù)寫入，您可以先修改本地表，然后修改分布式表。

• 如果數(shù)據(jù)正在寫入，您需要區(qū)分不同的類型進(jìn)行操作。

  類型	操作步驟
  增加Nullable的列	修改本地表。 修改分布式表。
  修改列的數(shù)據(jù)類型（類型可以相互轉(zhuǎn)換）
  刪除Nullable列	修改分布式表。 修改本地表。
  增加非Nullable的列	停止數(shù)據(jù)的寫入。 執(zhí)行SYSTEM FLUSH DISTRIBUTED分布式表。 修改本地表。 修改分布式表。 重新進(jìn)行數(shù)據(jù)的寫入。
  刪除非Nullable的列
  修改列的名稱

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

• 等待運(yùn)行結(jié)束。

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

您可以通過如下代碼查看每張表所占的磁盤空間。

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;

您可以在執(zhí)行語句的settings里增加，示例代碼如下。

settings max_memory_usage = XXX;

如果目標(biāo)集群與數(shù)據(jù)源使用相同的VPC并位于同一地域。您需檢查二者是否將IP地址添加到了對方的白名單中。如果沒有，請?zhí)砑影酌麊巍?/p>

• ClickHouse中如何添加白名單，請參見設(shè)置白名單。

• 其他數(shù)據(jù)源如何添加白名單，請參見自身產(chǎn)品文檔。

如果目標(biāo)集群與數(shù)據(jù)源不屬于上述情況，選擇合適的網(wǎng)絡(luò)解決方案，解決網(wǎng)絡(luò)問題后再將彼此IP地址添加到對方的白名單中。

ClickHouse社區(qū)版集群支持遷移至企業(yè)版集群。

企業(yè)版集群與社區(qū)版集群相互遷移數(shù)據(jù)的主要方式有兩種，通過remote函數(shù)和通過文件導(dǎo)出導(dǎo)入方式。具體操作，請參見將自建ClickHouse數(shù)據(jù)遷移到云ClickHouse中。

新建的企業(yè)版24.5及以后的版本實例，其查詢引擎默認(rèn)使用新analyzer。新analyzer具有更好的查詢性能，但可能與部分舊版SQL不兼容，從而導(dǎo)致解析錯誤。如遇該錯誤，您可執(zhí)行以下語句，將新analyzer回退至舊analyzer。更多新analyzer詳情，請參見進(jìn)一步了解全新analyzer。

SET allow_experimental_analyzer = 0;

ClickHouse社區(qū)版集群暫不支持暫停功能，企業(yè)版集群支持此功能。如果您需要暫停企業(yè)版集群，您可前往企業(yè)版集群列表，在集群列表頁面左上角，選中目標(biāo)地域，在集群列表找到目標(biāo)集群，單擊目標(biāo)集群操作列的>暫停。