從ES遷移到ClickHouse的原因有哪些

這篇文章主要講解了“從ES遷移到ClickHouse的原因有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“從ES遷移到ClickHouse的原因有哪些”吧！

為什么選擇 ClickHouse

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

①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)測試 ClickHouse 的查詢速度比 ES 快 5-30 倍以上。

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

• 一方面 ClickHouse 的數(shù)據(jù)壓縮比比 ES 高，相同數(shù)據(jù)占用的磁盤空間只有 ES 的 1/3 到  1/30，節(jié)省了磁盤空間的同時，也能有效的減少磁盤 IO，這也是 ClickHouse 查詢效率更高的原因之一。

• 另一方面 ClickHouse 比 ES 占用更少的內(nèi)存，消耗更少的 CPU 資源。我們預(yù)估用 ClickHouse  處理日志可以將服務(wù)器成本降低一半。

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

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

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

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

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

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

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

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

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

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

用 ClickHouse 處理日志

ClickHouse 高可用部署方案

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

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

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

②跨 IDC 部署

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

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

如下圖所示：

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

如下所示：

• max_threads：32 #用于控制一個用戶的查詢線程數(shù)。

• max_memory_usage：10000000000 #單個查詢最多能夠使用內(nèi)存大小 9.31G。

• max_execution_time：30 #單個查詢最大執(zhí)行時間。

• skip_unavailable_shards：1 #在通過分布式表查詢的時候，當某一個 Shard 無法訪問時，其他 Shard  的數(shù)據(jù)仍然可以查詢。

④踩過的坑

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

消費數(shù)據(jù)到 ClickHouse

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

• 采用輪詢的方式寫 ClickHouse 集群的所有服務(wù)器，保證數(shù)據(jù)基本均勻分布。

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

• 寫本地表，不要寫分布式表，因為分布式表接收到數(shù)據(jù)后會將數(shù)據(jù)拆分成多個 parts，并轉(zhuǎn)發(fā)數(shù)據(jù)到其它服務(wù)器，會引起服務(wù)器間網(wǎng)絡(luò)流量增加、服務(wù)器 merge  的工作量增加，導(dǎo)致寫入速度變慢，并且增加了 Too many parts 的可能性。

• 建表時考慮 partition 的設(shè)置，之前遇到過有人將 partition 設(shè)置為 timestamp，導(dǎo)致插入數(shù)據(jù)一直報 Too many parts  的異常。我們一般按天分 partition。

• 主鍵和索引的設(shè)置、數(shù)據(jù)的亂序等也會導(dǎo)致寫入變慢。

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

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

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

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

查詢優(yōu)化

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

針對這個問題，我們將 table Panel 的查詢分兩次進行：

• 第一次查詢單位時間間隔的數(shù)據(jù)量，根據(jù)最終顯示的數(shù)據(jù)量計算出合理查詢的時間范圍。

• 第二次根據(jù)修正后的時間范圍，結(jié)合 Table Panel 中配置的默認顯示的 Column 查詢明細數(shù)據(jù)。

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

ClickHouse 提供了多種近似計算的方法，用于提供相對較高準確性的同時減少計算量。

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

Dashboard 遷移

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

接入 ClickHouse 的效果

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

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

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

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

ClickHouse 的內(nèi)存消耗主要包括內(nèi)存型的 engine，數(shù)據(jù)索引，加載到內(nèi)存中待計算的數(shù)據(jù)，搜索的結(jié)果等。在 ClickHouse  中日志的數(shù)據(jù)量和保存時間主要和磁盤有關(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)化，查詢耗時 29.5s，CDN 的查詢 CK 和 ES 快 38  倍，dbLog 的查詢 CK 比 ES 快 4.4 倍。

關(guān)于查詢速度的對比，因為在生產(chǎn)環(huán)境，無法保證 ES 和 ClickHouse 的環(huán)境一樣，ES 使用的是 40 核 256G 的服務(wù)器，一臺服務(wù)器部署一個  ES 實例，單服務(wù)器數(shù)據(jù)量 3T 左右。

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

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

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

ClickHouse 基本運維

總體來說 ClickHouse 的運維比 ES 簡單，主要包括以下幾個方面的工作：

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

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

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

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

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

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

⑤常見問題處理：

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

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

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

• 設(shè)置不合。

• 小批量、高頻次寫 ClickHouse。

• 寫的是 ClickHouse 的分布式表。

• ClickHouse 設(shè)置的 merge 線程數(shù)太少了。

無法啟動：之前遇到過 ClickHouse 無法啟動的問題。

主要包括兩個方面：

• 文件系統(tǒng)損壞，通過修復(fù)文件系統(tǒng)可以解決。

• 某一個表的數(shù)據(jù)異常導(dǎo)致 ClickHouse 加載失敗，可以刪除異常數(shù)據(jù)后啟動，也可以把異常的文件搬到 detached 目錄，等 ClickHouse  起來后再 attach 文件恢復(fù)數(shù)據(jù)。

感謝各位的閱讀，以上就是“從ES遷移到ClickHouse的原因有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對從ES遷移到ClickHouse的原因有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！