Clickhouse替代ES後，日誌查詢速度提高了38倍！

​做者介紹

Gavin Zhu，攜程軟件技術專家，負責監控系統運維開發、ES系統運維及Clickhouse技術應用推廣及運維工做。

 

ElasticSearch是一種基於Lucene的分佈式全文搜索引擎，攜程用ES處理日誌，目前服務器規模500+，日均日誌接入量大約200TB。隨着日誌量不斷增長，一些問題逐漸暴露出來：一方面ES服務器愈來愈多，投入的成本愈來愈高；另外一方面用戶的滿意度不高，日誌寫入延遲、查詢慢甚至查不出來的問題一直困擾着用戶；而從運維人員的角度看，ES的運維成本較高，運維的壓力愈來愈大。

 

1、爲何選擇ClickHouse

 

ClickHouse是一款高性能列式分佈式數據庫管理系統，咱們對ClickHouse進行了測試，發現有下列優點：

 

ClickHouse寫入吞吐量大，單服務器日誌寫入量在50MB到200MB/s，每秒寫入超過60w記錄數，是ES的5倍以上。在ES中比較常見的寫Rejected致使數據丟失、寫入延遲等問題，在ClickHouse中不容易發生。

 

查詢速度快，官方宣稱數據在pagecache中，單服務器查詢速率大約在2-30GB/s；沒在pagecache的狀況下，查詢速度取決於磁盤的讀取速率和數據的壓縮率。經測試ClickHouse的查詢速度比ES快5-30倍以上。

 

ClickHouse比ES服務器成本更低。一方面ClickHouse的數據壓縮比比ES高，相同數據佔用的磁盤空間只有ES的1/3到1/30，節省了磁盤空間的同時，也能有效的減小磁盤IO，這也是ClickHouse查詢效率更高的緣由之一；另外一方面ClickHouse比ES佔用更少的內存，消耗更少的CPU資源。咱們預估用ClickHouse處理日誌能夠將服務器成本下降一半。

 

相比ES，ClickHouse穩定性更高，運維成本更低。

 

ES中不一樣的Group負載不均衡，有的Group負載高，會致使寫Rejected等問題，須要人工遷移索引；在ClickHouse中經過集羣和Shard策略，採用輪詢寫的方法，可讓數據比較均衡的分佈到全部節點。

 

ES中一個大查詢可能致使OOM的問題；ClickHouse經過預設的查詢限制，會查詢失敗，不影響總體的穩定性。

 

ES須要進行冷熱數據分離，天天200T的數據搬遷，稍有不慎就會致使搬遷過程發生問題，一旦搬遷失敗，熱節點可能很快就會被撐爆，致使一大堆人工維護恢復的工做；ClickHouse按天分partition，通常不須要考慮冷熱分離，特殊場景用戶確實須要冷熱分離的，數據量也會小不少，ClickHouse自帶的冷熱分離機制就能夠很好的解決。

 

ClickHouse採用SQL語法，比ES的DSL更加簡單，學習成本更低。

 

結合攜程的日誌分析場景，日誌進入ES前已經格式化成JSON，同一類日誌有統一的Schema，符合ClickHouse Table的模式；日誌查詢的時候，通常按照某一維度統計數量、總量、均值等，符合ClickHouse面向列式存儲的使用場景。

 

偶爾有少許的場景須要對字符串進行模糊查詢，也是先通過一些條件過濾掉大量數據後，再對少許數據進行模糊匹配，ClickHouse也能很好的勝任。另外咱們發現90%以上的日誌沒有使用ES的全文索引特性，所以咱們決定嘗試用ClickHouse來處理日誌。

 

2、用ClickHouse處理日誌

 

ClickHouse高可用部署方案  

 

1）容災部署與集羣規劃

 

咱們採用多Shards、2 Replicas的方式，經過Zookeeper進行服務器間互相備份，容許一個shard一臺服務器down機數據不丟失。爲了接入不一樣規模的日誌，咱們將集羣分紅6臺、20臺兩種規模的多個集羣。

 

 

2） 跨IDC部署

 

藉助於ClickHouse分佈式表的特性，咱們實現了跨集羣搜索。攜程有多個IDC，日誌分佈在不一樣的IDC，爲了不跨IDC搬遷日誌，咱們在每一個IDC都部署一套ClickHouse，而後配置ClickHouse的跨IDC的Cluster，建立分佈式表，實現跨多個IDC數據搜索，以下圖所示：

 

 

3）幾個重要的參數說明

 

• max_threads：32  # 用於控制一個用戶的查詢線程數；

• max_memory_usage：10000000000  #單個查詢最多可以使用內存大小9.31G；

• max_execution_time：30  #單個查詢最大執行時間；

• skip_unavailable_shards：1  # 在經過分佈式表查詢的時候，當某一個shard沒法訪問時，其餘shard的數據仍然能夠查詢。

 

4） 踩過的坑

 

咱們以前將Cluster的配置放在config.d的目錄下，當ClickHouse意外重啓後，發現查詢分佈式表時部分shard訪問不到的問題，所以咱們如今再也不使用config.d配置方式，Cluster配置放在metrika.xml中。

 

消費數據到ClickHouse  

 

 

咱們使用gohangout消費數據到ClickHouse，關於數據寫入的幾點建議：

 

• 採用輪詢的方式寫ClickHouse集羣的全部服務器，保證數據基本均勻分佈；

• 大批次低頻率的寫入，減小parts數量，減小服務器merge，避免Too many parts異常。經過兩個閾值控制數據的寫入量和頻次，超過10w記錄寫一次或者30s寫一次；

• 寫本地表，不要寫分佈式表，由於分佈式表接收到數據後會將數據拆分紅多個parts，並轉發數據到其它服務器，會引發服務器間網絡流量增長、服務器merge的工做量增長，致使寫入速度變慢，而且增長了Too many parts的可能性；

• 建表時考慮partition的設置，以前遇到過有人將partition設置爲timestamp，致使插入數據一直報Too many parts的異常。咱們通常按天分partition；

• 主鍵和索引的設置、數據的亂序等也會致使寫入變慢。

 

數據展現  

 

咱們調研了像Supperset、Metabase、Grafana等幾個工具，最終仍是決定採用在Kibana3上開發支持ClickHouse實現圖表展現。主要緣由是Kibana3這種強大的數據過濾功能，不少系統都不具有，另外也考慮到遷移到其餘系統成本較高，用戶短時間內難以適應。

 

目前K3上幾種經常使用的圖表（terms、histogram、percentiles、ranges、table），咱們都開發了對應的ClickHouse版本，用戶體驗與原版基本保持一直，查詢效率通過優化大幅提高。

 

查詢優化  

 

Kibana中的Table Panel用於顯示日誌的明細數據，通常查詢最近1小時全部字段的數據，最終只展現前500條記錄。這種場景對於ClickHouse來講很是不友好。

 

針對這個問題，咱們將table Panel的查詢分兩次進行：第一次查詢單位時間間隔的數據量，根據最終顯示的數據量計算出合理查詢的時間範圍；第二次根據修正後的時間範圍，結合Table Panel中配置的默認顯示的Column查詢明細數據。

 

通過這些優化，查詢的時間能夠縮短到原來的1/60，查詢的列能夠減小50%，最終查詢數據量減小到原來的1/120；ClickHouse提供了多種近似計算的方法，用於提供相對較高準確性的同時減小計算量；使用MATERIALIZED VIEW或者MATERIALIZED COLUMN將計算量放在日常完成，也能有效下降查詢的數據量和計算量。

 

Dashboard遷移  

 

由於Kibana3上的Dashboard不少，咱們開發了一個Dashboard遷移工具，經過修改kibana-init-*索引中Dashboard的配置來進行Dashboard遷移。

 

3、接入ClickHouse的效果

 

目前咱們一個集羣的日誌量100T左右（壓縮前600T左右），ClickHouse服務器主要監控指標以下：

 

 

ClickHouse相對ES佔用更少的內存。ES爲了提升查詢效率會將不少數據放在內存中，如：segment的索引數據、filter cache、field data cache、indexing buffer等；ES內存的使用量與索引量、數據量、寫入量、查詢量等成正比。刪除（下線）索引、遷移索引或者擴容是應對ES內存問題的經常使用手段。可是刪除（下線）索引致使用戶但願保存更長時間數據的需求沒法知足，而服務器擴容致使又了成本上升。

 

ClickHouse的內存消耗主要包括內存型的engine，數據索引，加載到內存中待計算的數據，搜索的結果等。在ClickHouse中日誌的數據量和保存時間主要和磁盤有關。

 

相比ES，ClickHouse後至少能夠節省60%的磁盤空間。以下圖所示，Netflow 的日誌佔用的磁盤空間ClickHouse是ES的32%，CDN日誌佔用磁盤空間ClickHouse是ES的18%，Dblog的日誌ClickHouse是ES的22.5%。

 

 

比較查詢速度提高，ClickHouse比ES提高了4.4倍到38倍不等，原來ES上查詢不出來的問題基本獲得瞭解決，查詢慢的問題有了很大的提高。

 

Netflow因爲數據量很是大，致使ES沒法查詢，ClickHouse中通過優化，查詢耗時29.5s，CDN的查詢CK和ES快38倍，dbLog的查詢CK比ES快 4.4倍；關於查詢速度的對比，由於在生產環境，沒法保證ES和ClickHouse的環境同樣，ES使用的是40核256G的服務器，一臺服務器部署一個ES實例，單服務器數據量3T左右。ClickHouse採用的是32核128G的服務器,單服務器數據量大約18T左右，一臺服務器部署一個ClickHouse實例。

 

 

用ClickHouse處理日誌查詢速度獲得了很大的提高，基本解決了數據保存時間短的問題，用戶使用體驗也獲得了提高。咱們預估使用如今ES日誌集羣50%的服務器資源就能就可以完成現有ES日誌的處理，並能提供比如今更好的用戶體驗。

 

4、ClickHouse基本運維

 

整體來講ClickHouse的運維比ES簡單，主要包括如下幾個方面的工做：

 

1)新日誌的接入、性能優化；

 

2) 過時日誌的清理，咱們經過一個定時任務天天刪除過時日誌的partition；

 

3) ClickHouse的監控，使用ClickHouse-exporter+VictoriaMetrics+Grafana的實現；

 

4) 數據遷移，經過ClickHouse分佈式表的特性咱們通常不搬遷歷史數據，只要將新的數據接入新集羣，而後經過分佈式表跨集羣查詢。隨着時間的推移，歷史數據會被清理下線，當老集羣數據所有下線後，新老集羣的遷移就完成了。確實須要遷移數據時，採用ClickHouse_copier或者複製數據的方式實現。

 

5) 常見問題處理：

 

慢查詢，經過kill query終止慢查詢的執行，並經過前面提到的優化方案進行優化。

 

Too many parts異常：Too many parts異常是因爲寫入的part過多part的merge速度跟不上產生的速度，致使part過多的緣由主要包括幾個方面：

 

• 設置不合理 ；

• 小批量、高頻次寫ClickHouse；

• 寫的是ClickHouse的分佈式表；

• ClickHouse設置的merge線程數太少了。

 

沒法啓動：以前遇到過ClickHouse沒法啓動的問題，主要包括兩個方面：

 

• 文件系統損壞，經過修復文件系統能夠解決；

• 某一個表的數據異常致使ClickHouse加載失敗，能夠刪除異常數據後啓動，也能夠把異常的文件搬到detached目錄，等ClickHouse起來後再attach文件恢復數據。

 

5、總結

 

將日誌從ES遷移到ClickHouse能夠節省更多的服務器資源，整體運維成本更低，並且提高了查詢速度，特別是當用戶在緊急排障的時候，這種查詢速度的成倍提高，對用戶的使用體驗有明顯的改善。

 

咱們將繼續致力於將ES的日誌遷移到ClickHouse，並優化日誌查詢性能，讓ClickHouse在日誌分析領域爲用戶提供更大的價值。

 

可是ClickHouse畢竟不是ES，在不少業務場景中ES仍然不可替代；ClickHouse也不只只能處理日誌，進一步深刻研究ClickHouse，讓ClickHouse在更多領域發揮更大的價值，是咱們一直努力的方向。  

 

做者丨Gavin Zhu 來源丨攜程技術（ID:ctriptech) dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： editor@dbaplus.cn