ElasticSearch 是一種基于 Lucene 的分布式全文搜索引擎，攜程用 ES 處理日志，目前服務(wù)器規(guī)模 500+，日均日志接入量大約 200TB。

[[345865]]

 

圖片來自 Pexels

隨著日志量不斷增加，一些問題逐漸暴露出來：

• 一方面 ES 服務(wù)器越來越多，投入的成本越來越高。
• 另一方面用戶的滿意度不高，日志寫入延遲、查詢慢甚至查不出來的問題一直困擾著用戶。

而從運(yùn)維人員的角度看，ES 的運(yùn)維成本較高，運(yùn)維的壓力越來越大。

為什么選擇 ClickHouse

ClickHouse 是一款高性能列式分布式數(shù)據(jù)庫管理系統(tǒng)，我們對(duì) ClickHouse 進(jìn)行了測(cè)試，發(fā)現(xiàn)有下列優(yōu)勢(shì)：

①ClickHouse 寫入吞吐量大，單服務(wù)器日志寫入量在 50MB 到 200MB/s，每秒寫入超過 60w 記錄數(shù)，是 ES 的 5 倍以上。

②在 ES 中比較常見的寫 Rejected 導(dǎo)致數(shù)據(jù)丟失、寫入延遲等問題，在 ClickHouse 中不容易發(fā)生。

③查詢速度快，官方宣稱數(shù)據(jù)在 pagecache 中，單服務(wù)器查詢速率大約在 2-30GB/s;沒在 pagecache 的情況下，查詢速度取決于磁盤的讀取速率和數(shù)據(jù)的壓縮率。經(jīng)測(cè)試 ClickHouse 的查詢速度比 ES 快 5-30 倍以上。

ClickHouse 比 ES 服務(wù)器成本更低：

• 一方面 ClickHouse 的數(shù)據(jù)壓縮比比 ES 高，相同數(shù)據(jù)占用的磁盤空間只有 ES 的 1/3 到 1/30，節(jié)省了磁盤空間的同時(shí)，也能有效的減少磁盤 IO，這也是 ClickHouse 查詢效率更高的原因之一。
• 另一方面 ClickHouse 比 ES 占用更少的內(nèi)存，消耗更少的 CPU 資源。我們預(yù)估用 ClickHouse 處理日志可以將服務(wù)器成本降低一半。

④相比 ES，ClickHouse 穩(wěn)定性更高，運(yùn)維成本更低。

⑤ES 中不同的 Group 負(fù)載不均衡，有的 Group 負(fù)載高，會(huì)導(dǎo)致寫 Rejected 等問題，需要人工遷移索引;在 ClickHouse 中通過集群和 Shard 策略，采用輪詢寫的方法，可以讓數(shù)據(jù)比較均衡的分布到所有節(jié)點(diǎn)。

⑥ES 中一個(gè)大查詢可能導(dǎo)致 OOM 的問題;ClickHouse 通過預(yù)設(shè)的查詢限制，會(huì)查詢失敗，不影響整體的穩(wěn)定性。

⑦ES 需要進(jìn)行冷熱數(shù)據(jù)分離，每天 200T 的數(shù)據(jù)搬遷，稍有不慎就會(huì)導(dǎo)致搬遷過程發(fā)生問題，一旦搬遷失敗，熱節(jié)點(diǎn)可能很快就會(huì)被撐爆，導(dǎo)致一大堆人工維護(hù)恢復(fù)的工作。

⑧ClickHouse 按天分 Partition，一般不需要考慮冷熱分離，特殊場(chǎng)景用戶確實(shí)需要冷熱分離的，數(shù)據(jù)量也會(huì)小很多，ClickHouse 自帶的冷熱分離機(jī)制就可以很好的解決。

⑨ClickHouse 采用 SQL 語法，比 ES 的 DSL 更加簡(jiǎn)單，學(xué)習(xí)成本更低。

結(jié)合攜程的日志分析場(chǎng)景，日志進(jìn)入 ES 前已經(jīng)格式化成 JSON，同一類日志有統(tǒng)一的 Schema，符合 ClickHouse Table 的模式。

日志查詢的時(shí)候，一般按照某一維度統(tǒng)計(jì)數(shù)量、總量、均值等，符合 ClickHouse 面向列式存儲(chǔ)的使用場(chǎng)景。

偶爾有少量的場(chǎng)景需要對(duì)字符串進(jìn)行模糊查詢，也是先經(jīng)過一些條件過濾掉大量數(shù)據(jù)后，再對(duì)少量數(shù)據(jù)進(jìn)行模糊匹配，ClickHouse 也能很好的勝任。

另外我們發(fā)現(xiàn) 90% 以上的日志沒有使用 ES 的全文索引特性，因此我們決定嘗試用 ClickHouse 來處理日志。

用 ClickHouse 處理日志

ClickHouse 高可用部署方案

①容災(zāi)部署與集群規(guī)劃

我們采用多 Shards、2 Replicas 的方式，通過 Zookeeper 進(jìn)行服務(wù)器間互相備份，允許一個(gè) Shard 一臺(tái)服務(wù)器 Down 機(jī)數(shù)據(jù)不丟失。

為了接入不同規(guī)模的日志，我們將集群分成 6 臺(tái)、20 臺(tái)兩種規(guī)模的多個(gè)集群。

 

②跨 IDC 部署

借助于 ClickHouse 分布式表的特性，我們實(shí)現(xiàn)了跨集群搜索。攜程有多個(gè) IDC，日志分布在不同的 IDC。

為了避免跨 IDC 搬遷日志，我們?cè)诿總€(gè) IDC 都部署一套 ClickHouse，然后配置 ClickHouse 的跨 IDC 的 Cluster，創(chuàng)建分布式表，實(shí)現(xiàn)跨多個(gè) IDC 數(shù)據(jù)搜索。

如下圖所示：

 

③幾個(gè)重要的參數(shù)說明

如下所示：

• max_threads：32 #用于控制一個(gè)用戶的查詢線程數(shù)。
• max_memory_usage：10000000000 #單個(gè)查詢最多能夠使用內(nèi)存大小 9.31G。
• max_execution_time：30 #單個(gè)查詢最大執(zhí)行時(shí)間。
• skip_unavailable_shards：1 #在通過分布式表查詢的時(shí)候，當(dāng)某一個(gè) Shard 無法訪問時(shí)，其他 Shard 的數(shù)據(jù)仍然可以查詢。

④踩過的坑

我們之前將 Cluster 的配置放在 config.d 的目錄下，當(dāng) ClickHouse 意外重啟后，發(fā)現(xiàn)查詢分布式表時(shí)部分 Shard 訪問不到的問題，因此我們現(xiàn)在不再使用 config.d 配置方式，Cluster 配置放在 metrika.xml 中。

消費(fèi)數(shù)據(jù)到 ClickHouse

 

我們使用 gohangout 消費(fèi)數(shù)據(jù)到 ClickHouse，關(guān)于數(shù)據(jù)寫入的幾點(diǎn)建議：

• 采用輪詢的方式寫 ClickHouse 集群的所有服務(wù)器，保證數(shù)據(jù)基本均勻分布。
• 大批次低頻率的寫入，減少 parts 數(shù)量，減少服務(wù)器 merge，避免 Too many parts 異常。通過兩個(gè)閾值控制數(shù)據(jù)的寫入量和頻次，超過 10w 記錄寫一次或者 30s 寫一次。
• 寫本地表，不要寫分布式表，因?yàn)榉植际奖斫邮盏綌?shù)據(jù)后會(huì)將數(shù)據(jù)拆分成多個(gè) parts，并轉(zhuǎn)發(fā)數(shù)據(jù)到其它服務(wù)器，會(huì)引起服務(wù)器間網(wǎng)絡(luò)流量增加、服務(wù)器 merge 的工作量增加，導(dǎo)致寫入速度變慢，并且增加了 Too many parts 的可能性。
• 建表時(shí)考慮 partition 的設(shè)置，之前遇到過有人將 partition 設(shè)置為 timestamp，導(dǎo)致插入數(shù)據(jù)一直報(bào) Too many parts 的異常。我們一般按天分 partition。
• 主鍵和索引的設(shè)置、數(shù)據(jù)的亂序等也會(huì)導(dǎo)致寫入變慢。

數(shù)據(jù)展示

我們調(diào)研了像 Supperset、Metabase、Grafana 等幾個(gè)工具，最終還是決定采用在 Kibana3 上開發(fā)支持 ClickHouse 實(shí)現(xiàn)圖表展示。

主要原因是 Kibana3 這種強(qiáng)大的數(shù)據(jù)過濾功能，很多系統(tǒng)都不具備，另外也考慮到遷移到其他系統(tǒng)成本較高，用戶短期內(nèi)難以適應(yīng)。

目前 K3 上幾種常用的圖表(terms、histogram、percentiles、ranges、table)，我們都開發(fā)了對(duì)應(yīng)的 ClickHouse 版本，用戶體驗(yàn)與原版基本保持一直，查詢效率經(jīng)過優(yōu)化大幅提升。

查詢優(yōu)化

Kibana 中的 Table Panel 用于顯示日志的明細(xì)數(shù)據(jù)，一般查詢最近 1 小時(shí)所有字段的數(shù)據(jù)，最終只展示前 500 條記錄。這種場(chǎng)景對(duì)于 ClickHouse 來說非常不友好。

針對(duì)這個(gè)問題，我們將 table Panel 的查詢分兩次進(jìn)行：

• 第一次查詢單位時(shí)間間隔的數(shù)據(jù)量，根據(jù)最終顯示的數(shù)據(jù)量計(jì)算出合理查詢的時(shí)間范圍。
• 第二次根據(jù)修正后的時(shí)間范圍，結(jié)合 Table Panel 中配置的默認(rèn)顯示的 Column 查詢明細(xì)數(shù)據(jù)。

經(jīng)過這些優(yōu)化，查詢的時(shí)間可以縮短到原來的 1/60，查詢的列可以減少 50%，最終查詢數(shù)據(jù)量減少到原來的 1/120。

ClickHouse 提供了多種近似計(jì)算的方法，用于提供相對(duì)較高準(zhǔn)確性的同時(shí)減少計(jì)算量。

使用 MATERIALIZED VIEW 或者 MATERIALIZED COLUMN 將計(jì)算量放在平常完成，也能有效降低查詢的數(shù)據(jù)量和計(jì)算量。

Dashboard 遷移

因?yàn)?Kibana3 上的 Dashboard 很多，我們開發(fā)了一個(gè) Dashboard 遷移工具，通過修改 kibana-init-* 索引中 Dashboard 的配置來進(jìn)行 Dashboard 遷移。

接入 ClickHouse 的效果

目前我們一個(gè)集群的日志量 100T 左右(壓縮前 600T 左右)，ClickHouse 服務(wù)器主要監(jiān)控指標(biāo)如下：

 

ClickHouse 相對(duì) ES 占用更少的內(nèi)存。ES 為了提高查詢效率會(huì)將很多數(shù)據(jù)放在內(nèi)存中，如：segment 的索引數(shù)據(jù)、filter cache、field data cache、indexing buffer 等。

ES 內(nèi)存的使用量與索引量、數(shù)據(jù)量、寫入量、查詢量等成正比。刪除(下線)索引、遷移索引或者擴(kuò)容是應(yīng)對(duì) ES 內(nèi)存問題的常用手段。

但是刪除(下線)索引導(dǎo)致用戶希望保存更長(zhǎng)時(shí)間數(shù)據(jù)的需求無法滿足，而服務(wù)器擴(kuò)容導(dǎo)致又了成本上升。

ClickHouse 的內(nèi)存消耗主要包括內(nèi)存型的 engine，數(shù)據(jù)索引，加載到內(nèi)存中待計(jì)算的數(shù)據(jù)，搜索的結(jié)果等。在 ClickHouse 中日志的數(shù)據(jù)量和保存時(shí)間主要和磁盤有關(guān)。

相比 ES，ClickHouse 后至少可以節(jié)省 60% 的磁盤空間。

 

如上圖所示，Netflow 的日志占用的磁盤空間 ClickHouse 是 ES 的 32%，CDN 日志占用磁盤空間 ClickHouse 是 ES 的 18%，Dblog 的日志 ClickHouse 是 ES 的 22.5%。

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

Netflow 由于數(shù)據(jù)量非常大，導(dǎo)致 ES 無法查詢，ClickHouse 中經(jīng)過優(yōu)化，查詢耗時(shí) 29.5s，CDN 的查詢 CK 和 ES 快 38 倍，dbLog 的查詢 CK 比 ES 快 4.4 倍。

關(guān)于查詢速度的對(duì)比，因?yàn)樵谏a(chǎn)環(huán)境，無法保證 ES 和 ClickHouse 的環(huán)境一樣，ES 使用的是 40 核 256G 的服務(wù)器，一臺(tái)服務(wù)器部署一個(gè) ES 實(shí)例，單服務(wù)器數(shù)據(jù)量 3T 左右。

ClickHouse 采用的是 32 核 128G 的服務(wù)器，單服務(wù)器數(shù)據(jù)量大約 18T 左右，一臺(tái)服務(wù)器部署一個(gè) ClickHouse 實(shí)例。

 

用 ClickHouse 處理日志查詢速度得到了很大的提升，基本解決了數(shù)據(jù)保存時(shí)間短的問題，用戶使用體驗(yàn)也得到了提升。

我們預(yù)估使用現(xiàn)在 ES 日志集群 50% 的服務(wù)器資源就能就能夠完成現(xiàn)有 ES 日志的處理，并能提供比現(xiàn)在更好的用戶體驗(yàn)。

ClickHouse 基本運(yùn)維

總體來說 ClickHouse 的運(yùn)維比 ES 簡(jiǎn)單，主要包括以下幾個(gè)方面的工作：

①新日志的接入、性能優(yōu)化。

②過期日志的清理，我們通過一個(gè)定時(shí)任務(wù)每天刪除過期日志的 partition。

③ClickHouse 的監(jiān)控，使用 ClickHouse-exporter+VictoriaMetrics+Grafana 的實(shí)現(xiàn)。

④數(shù)據(jù)遷移，通過 ClickHouse 分布式表的特性我們一般不搬遷歷史數(shù)據(jù)，只要將新的數(shù)據(jù)接入新集群，然后通過分布式表跨集群查詢。

隨著時(shí)間的推移，歷史數(shù)據(jù)會(huì)被清理下線，當(dāng)老集群數(shù)據(jù)全部下線后，新老集群的遷移就完成了。

確實(shí)需要遷移數(shù)據(jù)時(shí)，采用 ClickHouse_copier 或者復(fù)制數(shù)據(jù)的方式實(shí)現(xiàn)。

⑤常見問題處理：

慢查詢：通過 kill query 終止慢查詢的執(zhí)行，并通過前面提到的優(yōu)化方案進(jìn)行優(yōu)化。

Too many parts 異常：Too many parts 異常是由于寫入的 part 過多 part 的 merge 速度跟不上產(chǎn)生的速度。

導(dǎo)致 part 過多的原因主要包括幾個(gè)方面：

• 設(shè)置不合。
• 小批量、高頻次寫 ClickHouse。
• 寫的是 ClickHouse 的分布式表。
• ClickHouse 設(shè)置的 merge 線程數(shù)太少了。

無法啟動(dòng)：之前遇到過 ClickHouse 無法啟動(dòng)的問題。

主要包括兩個(gè)方面：

• 文件系統(tǒng)損壞，通過修復(fù)文件系統(tǒng)可以解決。
• 某一個(gè)表的數(shù)據(jù)異常導(dǎo)致 ClickHouse 加載失敗，可以刪除異常數(shù)據(jù)后啟動(dòng)，也可以把異常的文件搬到 detached 目錄，等 ClickHouse 起來后再 attach 文件恢復(fù)數(shù)據(jù)。

總結(jié)

將日志從 ES 遷移到 ClickHouse 可以節(jié)省更多的服務(wù)器資源，總體運(yùn)維成本更低，而且提升了查詢速度，特別是當(dāng)用戶在緊急排障的時(shí)候，這種查詢速度的成倍提升，對(duì)用戶的使用體驗(yàn)有明顯的改善。

我們將繼續(xù)致力于將 ES 的日志遷移到 ClickHouse，并優(yōu)化日志查詢性能，讓 ClickHouse 在日志分析領(lǐng)域?yàn)橛脩籼峁└蟮膬r(jià)值。

但是 ClickHouse 畢竟不是 ES，在很多業(yè)務(wù)場(chǎng)景中 ES 仍然不可替代，ClickHouse 也不僅只能處理日志，進(jìn)一步深入研究 ClickHouse，讓 ClickHouse 在更多領(lǐng)域發(fā)揮更大的價(jià)值，是我們一直努力的方向。

 

作者：Gavin Zhu

簡(jiǎn)介：攜程軟件技術(shù)專家，負(fù)責(zé)監(jiān)控系統(tǒng)運(yùn)維開發(fā)、ES 系統(tǒng)運(yùn)維及 Clickhouse 技術(shù)應(yīng)用推廣及運(yùn)維工作。

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號(hào)攜程技術(shù)(ID：ctriptech)