全部產品
Search
文件中心

ApsaraDB for ClickHouse:常見問題

更新時間:Nov 14, 2024

本文匯總了雲資料庫ClickHouse的常見問題及解決方案。

雲資料庫ClickHouse和官方版本對比多了哪些功能和特性?

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

購買雲資料庫ClickHouse執行個體時,推薦選擇哪一個版本?

雲資料庫ClickHouse根據開源社區公開的LTS核心穩定版提供服務,通常在版本推出3個月相對穩定後啟動雲端服務售賣。當前建議購買21.8及以上版本。更多版本功能對比,請參見版本功能對比

單雙副本執行個體各有什麼特點?

  • 單副本執行個體每一個Shard節點無副本節點,無高可用服務保障。資料安全性雲端式盤多副本儲存,性價比高。

  • 雙副本執行個體每一個Shard節點對應一個副本服務節點,在主節點故障不能提供服務時副本節點可提供容災服務支援。

購買鏈路資源時顯示“目前範圍資源不足”,應該如何處理?

解決方案:您可以選擇同地區的其他地區購買。VPC網路支援相同地區不同可用性區域之間打通,同地區網路延遲無感知。

水平擴縮容耗時受什麼影響?

水平擴縮容過程涉及資料搬遷,執行個體裡面資料越多搬得越多,耗時時間越長。

擴縮容期間對執行個體有什麼影響?

為保證擴縮容中資料搬遷後的資料一致性,擴縮容期間執行個體處於可讀不可寫狀態。

水平擴縮容升級有什麼建議?

水平擴縮容耗時較長,當叢集效能不滿足時,請優先選擇垂直升配。如何進行垂直升配,請參見社區相容版叢集垂直變更配置和水平擴縮容

每個連接埠的含義是什嗎?

協議

連接埠號碼

適用情境

TCP

3306

使用clickhouse-client工具串連雲資料庫ClickHouse時配置,詳細操作請參見通過命令列工具串連ClickHouse

HTTP

8123

使用JDBC方式串連雲資料庫ClickHouse時配置進行應用開發,詳細操作請參見通過JDBC方式串連ClickHouse

HTTPS

8443

使用HTTPS協議訪問雲資料庫ClickHouse時配置,詳細操作請參見通過HTTPS協議串連ClickHouse

每種開發語言通過SDK串連雲資料庫ClickHouse對應的連接埠是什嗎?

開發語言

HTTP協議

TCP協議

Java

8123

3306

Python

Go

Go、Python語言對應推薦什麼SDK?

詳情請參見第三方開發庫

如何處理用戶端工具串連叢集時報錯:connect timed out?

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

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

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

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

為什麼MySQL、HDFS、Kafka等外表無法連通?

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

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

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

對於Kafka外表,表建立成功,但查詢沒有結果。常見原因是Kafka中資料通過表結構給出的欄位和格式解析失敗,報錯資訊會給出解析失敗的具體位置。

為什麼程式無法串連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無法訪問。

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

如何處理ClickHouse逾時問題?

雲資料庫ClickHouse核心中有很多逾時相關的參數設定,並且提供了多種協議進行互動,例如您可以設定HTTP協議和TCP協議的相關參數處理雲資料庫ClickHouse逾時問題。

HTTP協議

HTTP協議是雲資料庫ClickHouse在生產環境中最常使用的互動方式,包括官方提供的jdbc driver、阿里雲DMS、DataGrip,後台使用的都是HTTP協議。HTTP協議常用的連接埠號碼為8123。

  • 如何處理distributed_ddl_task_timeout逾時問題

    • 分布式DDL查詢(帶有 on cluster)的執行等待時間,系統預設是180s。您可以在DMS上執行以下命令來設定全域參數,設定後需要重啟叢集。

      set global on cluster default distributed_ddl_task_timeout = 1800;

      由於分布式DDL是基於ZooKeeper構建任務隊列非同步執行,執行等待逾時並不代表查詢失敗,只表示之前發送還在排隊等待執行,使用者不需要重複發送任務。

  • 如何處理max_execution_time逾時問題

    • 一般查詢的執行逾時時間,DMS平台上預設設定是7200s,jdbc driver、DataGrip上預設是30s。逾時限制觸發之後查詢會自動取消。使用者可以進行查詢層級更改,例如select * from system.numbers settings max_execution_time = 3600,也可以在DMS上執行以下命令來設定全域參數。

      set global on cluster default max_execution_time = 3600;
  • 如何處理socket_timeout逾時問題

    • HTTP協議在監聽socket返回結果時的等待時間,DMS平台上預設設定是7200s,jdbc driver、DataGrip上預設是30s。該參數不是Clickhouse系統內的參數,它屬於jdbc在HTTP協議上的參數,但它是會影響到前面的max_execution_time參數設定效果,因為它決定了用戶端在等待結果返回上的時間限制。所以一般使用者在調整max_execution_time參數的時候也需要配套調整socket_timeout參數,略微高於max_execution_time即可。使用者佈建參數時需要在jdbc連結串上添加socket_timeout這個property,單位是毫秒,例如:'jdbc:clickhouse://127.0.0.1:8123/default?socket_timeout=3600000'。

  • 如何處理使用SLB連結時的異常斷鏈

    • 阿里雲上的SLB連結在長時間內沒有資料報文發送時會自動取消連結,用戶端收到”read timeout“錯誤,查詢無法追蹤。對於這種情況您可以在DMS上執行以下命令來設定全域參數,設定後需要重啟叢集。

      set global on cluster default send_progress_in_http_headers = 1; 
      set global on cluster default http_headers_progress_interval_ms = 60000; 

      對於20.8最新版本您需要使用如下命令,設定失敗時可以先申請小版本升版。

      set global on cluster default http_server_enable_tcp_keep_alive = 1;
      set global on cluster default tcp_keep_alive_timeout = 60;

      開啟send_progress_in_http_headers後,ClickHouse服務端會不斷髮送包含查詢進度的HTTP-Header報文給用戶端,這樣就會一直有資料報文流通,避免連結斷開。

      因為各種原因用戶端失聯後,HTTP協議發送的查詢仍然會繼續執行。使用者可以在系統資料表追蹤到查詢是否成功執行。

      • 查詢叢集中所有執行個體當前正在running的查詢:

        SELECT * FROM remote(default, system, processes) WHERE query LIKE 'XXX'
      • 查詢當天的歷史查詢結果,包括是否成功、已經失敗的錯誤資訊:

        SELECT * FROM remote(default, system, query_log) WHERE event_date = toDate(now()) AND query LIKE 'XXX'
  • 使用ClickHouse服務端IP直接連結時的Client異常hang住

    • 阿里雲上的ECS在跨安全性群組連結時,有可能陷入靜默連結錯誤。具體原因是jdbc用戶端所在ECS機器的安全性群組白名單並沒有開放給ClickHouse服務端機器。當用戶端的請求經過超長時間才得到查詢結果時,返回的報文可能因為路由表不通無法發送到用戶端。此時用戶端就陷入了異常hang住狀態。

      該問題的處理辦法和SLB連結異常斷鏈問題一樣,開啟send_progress_in_http_headers可以解決大部分問題。在極少數情況下,開啟send_progress_in_http_headers仍不能解決問題的,您可以嘗試配置jdbc用戶端所在ECS機器的安全性群組白名單,把ClickHouse服務端地址加入到白名單中。

TCP協議

TCP協議最常使用的情境是ClickHouse內建的命令列工具進行互動分析時,社區相容版叢集常見連接埠號碼為3306。因為TCP協議裡有連結定時探活報文,所以它不會出現socket層面的逾時問題。您只需關注distributed_ddl_task_timeoutmax_execution_time參數的逾時,設定方法和HTTP協議一致。

為什麼OSS外表匯入ORC、PARQUET等格式的資料,出現記憶體報錯或OOM掛掉?

常見原因:記憶體使用量率比較高。

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

如何處理匯入資料報錯:too many parts?

ClickHouse每次寫入都會產生一個data part,如果每次寫入一條或者少量的資料,那會造成ClickHouse內部有大量的data part(會給merge和查詢造成很大的負擔)。為了防止出現大量的data part,ClickHouse內部做了很多限制,這就是too many parts報錯的內在原因。出現該錯誤,請增加寫入的批量大小。如果無法調整批量大小,可以在控制台修改參數:merge_tree.parts_to_throw_insert,將參數的取值設定的大一些。

為什麼DataX匯入速度慢?

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

  • 常見原因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;

    解決方案:您需要在資料來源刪除或修改髒資料。

為什麼Hive匯入後其資料行數跟ClickHouse對不上?

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

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

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

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

為什麼Kafka匯入後其資料行數跟ClickHouse對不上?

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

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

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

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

如何使用Spark、Flink匯入資料?

如何從現有ClickHouse匯入資料到雲資料庫ClickHouse?

您可以採取如下方案。

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

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

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

使用MaterializeMySQL引擎同步MySQL資料時,為什麼出現如下報錯:The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires

常見原因:MaterializeMySQL引擎停止同步的時間太久,導致MySQL Binlog日誌到期被清理掉。

解決方案:刪除報錯的資料庫,重新在雲資料庫ClickHouse中建立同步的資料庫。

使用MaterializeMySQL引擎同步MySQL資料時,為什麼出現錶停止同步?為什麼系統資料表system.materialize_mysql中sync_failed_tables欄位不為空白?

常見原因:同步過程中使用了雲資料庫ClickHouse不支援的MySQL DDL語句。

解決方案:重新同步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中同步的資料庫。

如何處理報錯:“Too many partitions for single INSERT block (more than 100)”?

常見原因:單個INSERT操作中超過了max_partitions_per_insert_block(最大分區插入塊,預設值為100)。ClickHouse每次寫入都會產生一個data part(資料部分),一個分區可能包含一個或多個data part,如果單個INSERT操作中插入了太多分區的資料,那會造成ClickHouse內部有大量的data part(會給合并和查詢造成很大的負擔)。為了防止出現大量的data part,ClickHouse內部做了限制。

解決方案:請執行以下操作,調整分區數或者max_partitions_per_insert_block參數。

  • 調整表結構,調整分區方式,或避免單次插入的不同分區數超過限制。

  • 避免單次插入的不同分區數超過限制,可根據資料量適當修改max_partitions_per_insert_block參數,放大單個插入的不同分區數限制,修改文法如下:

    單節點執行個體

    SET GLOBAL max_partitions_per_insert_block = XXX;

    多節點執行個體

    SET GLOBAL ON cluster DEFAULT max_partitions_per_insert_block = XXX;
    說明

    ClickHouse社區推薦預設值為100,分區數不要設定得過大,否則可能對效能產生影響。在大量匯入資料後可修改值為預設值。

如何處理insert into select XXX記憶體超限報錯?

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

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

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

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

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

如何查詢CPU使用量和記憶體使用量量?

您可以在system.query_log系統資料表裡自助查看CPU和MEM在查詢時的使用日誌,裡面有每個查詢的CPU使用量和記憶體使用量量統計。更多資訊請參見system.query_log

如何處理查詢時記憶體超出限制?

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. 單擊提交參數

  7. 單擊確定

在資料停止寫入時,同一個查詢語句每次查詢的結果不一致,應該如何處理?

問題詳細描述:通過select count(*) 查詢資料時只有整體資料的大概一半,或者資料一直在跳變。

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

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

  • 檢查是否是多複本集群。多複本集群需要建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}')為固定配置,無需修改。

如何處理往表裡寫入時間戳記資料後查詢出來的結果與實際資料不同?

SELECT timezone()語句,查看時區是否為當地時區,如果不是修改timezone配置項的值為當地時區。如何修改請參見修改配置項運行參數值

如何處理建表後查詢表不存在?

常見原因:DDL語句只在一個節點上執行。

解決方案:檢查DDL語句是否有on cluster關鍵字。更多資訊,請參見建表文法

為什麼Kafka外表建表後資料不增加?

您可以先對Kafka外表進行select * from的查詢,如果查詢報錯,那可以根據報錯資訊確定原因(一般是資料解析失敗)。如果查詢正常返回結果,那需要進一步查看目的表(Kafka外表的具體儲存表)和Kafka源表(Kafka外表)的欄位是否匹配。如果資料寫入失敗,那說明欄位是匹配不上的。樣本語句如下。

insert into <目的表> as select * from <kafka外表>;

為什麼用戶端看到的時間結果和時區顯示的不一樣?

用戶端設定了use_client_time_zone,並設定在了錯誤時區上。

為什麼資料寫入後不可見?

一般原因是分布式表和本地表的表結構不一致造成的。您可以通過查詢系統資料表system.distribution_queue來查看寫入分布式表的時候是否發生錯誤。

為什麼optimize任務很慢?

optimize任務非常佔用CPU和磁碟吞吐,查詢和optimize任務都會相互影響,在機器節點負載壓力較大的時候就會表現出optimize很慢問題,目前沒有特殊最佳化方法。

為什麼optimize後資料仍未主鍵合并?

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

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

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

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

命令

說明

optimize table test;

嘗試選取MergeTree的data parts進行合并,有可能沒有執行任務就返回。執行了也並不保證全表的記錄都完成了主鍵合并,一般不會使用。

optimize table test partition tuple();

指定某個分區,選取分區中所有的data parts進行合并,有可能沒有執行任務就返回。任務執行後代表某個分區下的資料都合并到了同一個data part,單分區下已經完成主鍵合并。但是在任務執行期間寫入的資料不會參與合并,若是分區下只有一個data part也不會重複執行任務。

說明

對於沒有分區鍵的表,其預設分區就是partition tuple()。

optimize table test final;

對全表所有分區強制進行合并,即使分區下只有一個data part也會進行重新合并,可以用於強制移除TTL到期的記錄。任務執行代價最高,但也有可能沒有執行合并任務就返回。

對於上面三種命令,您可以設定參數optimize_throw_if_noop通過異常報錯感知是否執行任務。

為什麼optimize後資料TTL仍未生效?

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

  • 常見原因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資訊。

為什麼optimize後更新刪除操作沒有生效?

雲資料庫ClickHouse中的更新刪除都是非同步執行的,目前沒有機制可以幹預其進度。您可以通過system.mutations系統資料表查看進度。

如何進行DDL增加列、刪除列、修改列操作?

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

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

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

    類型

    操作步驟

    增加Nullable的列

    1. 修改本地表。

    2. 修改分布式表。

    修改列的資料類型(類型可以相互轉換)

    刪除Nullable列

    1. 修改分布式表。

    2. 修改本地表。

    增加非Nullable的列

    1. 停止資料的寫入。

    2. 執行SYSTEM FLUSH DISTRIBUTED分布式表。

    3. 修改本地表。

    4. 修改分布式表。

    5. 重新進行資料的寫入。

    刪除非Nullable的列

    修改列的名稱

為什麼DDL執行慢,經常卡住?

常見原因:DDL全域的執行是串列執行,複雜查詢會導致死結。

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

  • 等待運行結束。

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

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

    說明

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

如何處理分布式DDL報錯:longer than distributed_ddl_task_timeout (=xxx) seconds?

您可以通過使用set global on cluster default distributed_ddl_task_timeout=xxx命令修改預設逾時時間,xxx為自訂逾時時間,單位為秒。全域參數修改請參見叢集參數修改

如何處理文法報錯:set global on cluster default?

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

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

    解決方案:

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

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

  • 常見原因2:set global on cluster default key = value; 中value是字串,但是漏寫了引號。

    解決方案:在字串類型的value兩側加上引號。

有什麼BI工具推薦?

Quick BI。

有什麼資料查詢IDE工具推薦?

DataGrip、DBEaver。

雲資料庫ClickHouse支援向量檢索嗎?

雲資料庫ClickHouse支援向量檢索。更多詳情,參見以下文檔:

如何查看每張表所佔的磁碟空間?

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

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。

  • 修改配置觸發重啟。

  • 升降配後的執行個體重啟。

20.8後的版本是否支援平滑升級,不需要遷移資料?

20.8後的版本支援平滑升級,需要遷移資料。

常用系統資料表有哪些?

常用系統資料表及作用如下。

名稱

作用

system.processes

查詢正在執行的SQL。

system.query_log

查詢歷史執行過的SQL。

system.merges

查詢叢集上的merge資訊。

system.mutations

查詢叢集上的mutation資訊。

如何修改系統層級的參數?是否要重啟,有什麼影響?

系統層級的參數對應config.xml內的部分配置項,具體修改步驟如下。

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

  2. 叢集列表頁面,選擇社區版執行個體列表,單擊目的地組群ID。

  3. 單擊左側導覽列的參數配置

  4. 在參數配置頁面,單擊max_concurrent_queries參數的運行參數值後面的編輯按鈕。

  5. 在懸浮框中填寫目標值,單擊確定修改參數

  6. 單擊提交參數

  7. 單擊確定

單擊確定後,自動重啟clickhouse-server,重啟會造成約1min閃斷。

如何修改使用者層級的參數?

使用者層級的參數對應users.xml內的部分配置項,你需要執行如下樣本語句。

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

無特殊說明的參數執行成功後即可生效。

如何修改Quota?

您可以在執行語句的settings裡增加,範例程式碼如下。

settings max_memory_usage = XXX;

如何解決目的地組群與資料來源網路互連問題?

如果目的地組群與資料來源使用相同的VPC並位於同一地區。您需檢查二者是否將IP地址添加到了對方的白名單中。如果沒有,請添加白名單。

  • ClickHouse中如何添加白名單,請參見設定白名單

  • 其他資料來源如何添加白名單,請參見自身產品文檔。

如果目的地組群與資料來源不屬於上述情況,選擇合適的網路解決方案,解決網路問題後再將彼此IP地址添加到對方的白名單中。

情境

解決方案

雲上雲下互連

使用雲企業網實現同地區雲上雲下網路互連(企業版)

跨地區跨帳號VPC互連

使用雲企業網實現跨地區跨帳號VPC互連(企業版)

同地區不通VPC互連

使用雲企業網實現同地區VPC互連(基礎版)

跨地區跨帳號VPC互連

使用雲企業網實現跨地區跨帳號VPC互連(基礎版)