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

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

創(chuàng)新互聯(lián)建站自2013年創(chuàng)立以來，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元淮安做網(wǎng)站,已為上家服務(wù),為淮安各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

為什么選擇 ClickHouse

ClickHouse 是一款高性能列式分布式數(shù)據(jù)庫管理系統(tǒng)，我們對 ClickHouse 進(jìn)行了測試，發(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é)省了磁盤空間的同時(shí)，也能有效的減少磁盤 IO，這也是 ClickHouse 查詢效率更高的原因之一。

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

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

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

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

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

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

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

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

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

偶爾有少量的場景需要對字符串進(jìn)行模糊查詢，也是先經(jīng)過一些條件過濾掉大量數(shù)據(jù)后，再對少量數(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 一臺服務(wù)器 Down  機(jī)數(shù)據(jù)不丟失。

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

②跨 IDC 部署

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

為了避免跨 IDC 搬遷日志，我們在每個(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ù)后會將數(shù)據(jù)拆分成多個(gè) parts，并轉(zhuǎn)發(fā)數(shù)據(jù)到其它服務(wù)器，會引起服務(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ù)的亂序等也會導(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ā)了對應(yīng)的 ClickHouse  版本，用戶體驗(yàn)與原版基本保持一直，查詢效率經(jīng)過優(yōu)化大幅提升。

查詢優(yōu)化

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

針對這個(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ì)算的方法，用于提供相對較高準(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 相對 ES 占用更少的內(nèi)存。ES 為了提高查詢效率會將很多數(shù)據(jù)放在內(nèi)存中，如：segment 的索引數(shù)據(jù)、filter  cache、field data cache、indexing buffer 等。

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

但是刪除(下線)索引導(dǎo)致用戶希望保存更長時(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)于查詢速度的對比，因?yàn)樵谏a(chǎn)環(huán)境，無法保證 ES 和 ClickHouse 的環(huán)境一樣，ES 使用的是 40 核 256G 的服務(wù)器，一臺服務(wù)器部署一個(gè)  ES 實(shí)例，單服務(wù)器數(shù)據(jù)量 3T 左右。

ClickHouse 采用的是 32 核 128G 的服務(wù)器，單服務(wù)器數(shù)據(jù)量大約 18T 左右，一臺服務(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 簡單，主要包括以下幾個(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ù)會被清理下線，當(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ù)太少了。

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

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

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

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

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

文章標(biāo)題：從ES遷移到ClickHouse的原因有哪些
文章分享：http://bm7419.com/article34/igdhse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站收錄、App設(shè)計(jì)、Google、用戶體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)