?一、背景

唯品會日志系統(tǒng)dragonfly 1.0是基于EFK構(gòu)建，于2014年服務(wù)至今已長達7年，支持物理機日志采集，容器日志采集，特殊分類日志綜合采集等，大大方便了全公司日志的存儲和查詢。

隨著公司的業(yè)務(wù)發(fā)展，日志應(yīng)用場景逐漸遇到了一些瓶頸，主要表現(xiàn)在應(yīng)用數(shù)量和打印的日志越來越多，開發(fā)需要打印更多日志，定位業(yè)務(wù)問題，做出運營數(shù)據(jù)分析；另外外部攻擊問題和審計要求，需要更多安全相關(guān)的日志數(shù)據(jù)要上報并且能夠提供半年以上的保存時長，以應(yīng)對潛在的攻擊和攻擊發(fā)生時調(diào)查原因和受影響面。ELK的架構(gòu)的缺點顯現(xiàn)，ES集群規(guī)模達260臺機器，需要的硬件和維護成本高達千萬，如果通過擴容的方法去滿足上述業(yè)務(wù)場景，ES集群會太大會變動不穩(wěn)定，創(chuàng)建獨立集群，也需要更高成本，兩者都會使得成本和維護工作量劇增。

鑒于這些問題，去年六月份我們開始探索新的日志系統(tǒng)架構(gòu)，以徹底解決上面的問題。

二、日志系統(tǒng)演進之路

1、標準日志格式

規(guī)范標準日志格式，有利于正確的識別出日志關(guān)鍵元信息，以滿足查詢，告警和聚合計算的需求。從以上格式日志，通過filebeat轉(zhuǎn)換后的結(jié)果如下：

時間戳，日志級別，線程名，類名，eventName，和自定義字段將被日志采集Agent解析后和其他元數(shù)據(jù)如域名，容器名或主機名一起以JSON格式上報。

自定義字段是開發(fā)人員根據(jù)業(yè)務(wù)需要打印到日志，主要支持功能:

• 查詢時支持各種聚合分析場景.

• 根據(jù)自定義字段進行聚合函數(shù)告警。

2、ES存儲方案問題

1）ES日志存儲模型

EFK日志存儲在elasticsearch，每個域的日志以天粒度在ES創(chuàng)建一個索引，索引大小是根據(jù)前幾日數(shù)據(jù)大小計算得出，每個索引分片大小不超過30G，日志量越多的域分片越多。如果一個域的日志量寫入過大或超長，將會占用ES節(jié)點大量CPU來做解析和segment合并，這會影響其他域日志的正常寫入，導(dǎo)致整體寫入吞吐下降。

排查是哪個域的哪個分片日志過大通常較為困難，在面對這種熱點問題時經(jīng)常要花很長時間。我們ES版本使用的是5.5，還不支持索引自動刪除和冷熱遷移，有幾個腳本每日定時執(zhí)行，完成刪除索引，關(guān)閉索引，移動冷索引，創(chuàng)建新索引的任務(wù)，其中移動索引和創(chuàng)建新索引都是耗時非常長的操作。

整個生命周期每天循環(huán)執(zhí)行，如果突然一天某個步驟執(zhí)行失敗，或者執(zhí)行時間太長，會導(dǎo)致整個生命周期拉長甚至無法完成，第二天的新數(shù)據(jù)寫入將受到嚴重影響，甚至無法寫入。另外ES的倒排索引需要對日志進行分詞，產(chǎn)生的索引文件較大，占用了大量磁盤空間。

不過ES也有其優(yōu)點，基于倒排索引的特性使得ES查詢時，1個分片只需要一個核即可完成查詢，因為查詢速度通常較快，QPS較高。下面是在大規(guī)模(或海量)日志存儲場景下ES的主要存儲優(yōu)點和缺點：

3、日志系統(tǒng)2.0方案

1）選擇clickhouse的原因

2019年我們嘗試了另外一種HDFS存儲方案，把每個域的數(shù)據(jù)按照域名+toYYDDMMHH(timestamp)+host作為鍵在客戶端緩存，當大小或過期時間到了之后，提交到HDFS生成一個獨立的文件，存儲路徑包含了域，主機和時間信息，搜索時即可根據(jù)這幾個標簽過濾，這種存儲方式有點類似loki，它的缺點顯而易見，優(yōu)點是吞吐和壓縮率都非常高，可以解決我們吞吐和壓縮率不足的問題。

如果基于此方案繼續(xù)增強功能，如添加標簽，簡單的跳數(shù)索引，查詢函數(shù)，多節(jié)點并發(fā)查詢，多字段存儲，需要開發(fā)的工作量和難度都非常大。我們對比了業(yè)界前沿使用的一些存儲方案，最終選擇了clickhouse，他的批量寫入和列式存儲方案完全滿足我們的要求(基于HDFS存儲)，另外還提供了占用磁盤空間非常小的主鍵索引和跳數(shù)索引，相比ES的全文索引，優(yōu)勢明顯。

將近26G的應(yīng)用日志分別使用clickhouse的lz4，zstd和ES的lz4壓縮算法對比：

實際生產(chǎn)環(huán)境中zstd的日志壓縮比更高，這和應(yīng)用日志的相似度有關(guān)，最大達到15.8。

Clickhouse壓縮率這么高，但沒有索引，其查詢速度如何？雖然沒有索引，但其向量執(zhí)行和SIMD配合多核CPU，可以大大緩解沒有全文索引的缺點。經(jīng)過多次測試對比后，其查詢速度在絕大多數(shù)場景下和ES不相上下，在部分場景下甚至比ES還要快。

下圖是實際生產(chǎn)環(huán)境的數(shù)千個應(yīng)用真實運行數(shù)據(jù)，查詢24小時時間范圍內(nèi)日志和24小時以上時間范圍日志的耗時對比。

通過對日志的應(yīng)用場景分析，我們發(fā)現(xiàn)萬億級別的日志，真正能被查詢的日志數(shù)量是非常非常少的，這意味著ES對所有日志的分詞索引，大多數(shù)是無效的，日志越多，這個分詞消耗的資源越浪費。相對比clickhouse的MergeTree引擎專一的多，主要資源消耗是日志排序壓縮和存儲。

另外Clickhouse的MPP架構(gòu)使得集群非常穩(wěn)定，幾乎不要太多運維工作。下面以一幅圖綜合對比ES和Clickhouse的優(yōu)缺點，說明為什么我們選擇將clickhouse作為下一代日志存儲數(shù)據(jù)庫。

三、技術(shù)詳解

EFK架構(gòu)發(fā)展這么多年體系要成熟得多，ES默認參數(shù)和倒排索引使得你不需要對ES有太多了解即可輕松使用，開源kibana又提供豐富的查詢界面和圖形面板，對于日志量不大的場景來講，EFK架構(gòu)仍然是首選。Clickhouse是近幾年OLAP領(lǐng)域比較熱門的數(shù)據(jù)庫，其成熟度和生態(tài)仍在快速發(fā)展中，用來存儲日志的開源方案不是很多，要用好它不但需要對Clickhouse有深入的了解，還需要做很多開發(fā)工作。

1、日志攝入 - vfilebeat

起初dragonfly使用logstash來做日志采集，但logstash的配置較復(fù)雜并且無法支持配置文件下發(fā)，不便于容器環(huán)境下的日志采集，當時另一個使用GO語言開發(fā)的采集工具vfilebeat在性能和擴展性方面較好，我們在此基礎(chǔ)上做了定制開發(fā)自己的日志采集組件vfilebeat。

vfilebeat運行在宿主機上，啟動時可以通過參數(shù)指定采集的宿主機日志所屬的域，如果沒有指定，則讀取安裝時CMDB配置文件的域名和主機名，宿主機采集的每條日志均帶上域名和主機名作為標簽。

容器環(huán)境下vfilebeat還會監(jiān)聽容器的創(chuàng)建和銷毀，當容器創(chuàng)建時，讀取容器的POD信息獲取到域名和主機名，然后從ETCD拉取到域的日志采集路徑等配置參數(shù)，按照域名和POD名稱生成容器所屬目錄的日志文件采集路徑，并在本地生成新的配置文件，vfilebeat重新加載配置文件，即可滾動采集。

現(xiàn)在我們環(huán)境絕大部分應(yīng)用均使用vfilebeat采集，少部分場景保留使用logstash采集。vfilebeat將采集到的日志附帶上應(yīng)用和系統(tǒng)環(huán)境等標簽，序列化配置的數(shù)據(jù)格式，上報到kafka集群，應(yīng)用日志是JSON，Accesslog為文本行。

2、日志解析 - flink writer

采集到kafka的日志將被一個flink writer任務(wù)實施消費后再寫入到clickhouse集群。

writer把從kafka消費的數(shù)據(jù)先轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)，vfilebeat上報的時候可能會上報一些日期較久的數(shù)據(jù)，太久的數(shù)據(jù)，報上來意義不大，并且會導(dǎo)致產(chǎn)生比較多的小part，消耗clickhosue cpu資源，這一步把這些過期超過三天的日期丟掉，無法解析的數(shù)據(jù)或者缺少必須字段的日志也會丟掉。經(jīng)解析過濾后的數(shù)據(jù)再經(jīng)過轉(zhuǎn)換步驟，轉(zhuǎn)換為clickhouse的表字段和類型。

轉(zhuǎn)換操作從schema和metadata表讀取域日志存儲的元信息，schema定義了clickhouse本地表和全局表名，字段信息，以及默認的日志字段和表字段的映射關(guān)系。metadata定義了域日志具體使用的schema信息，日志存儲的時長，域分區(qū)字段值，域自定義字段映射到的表字段，通過這些域級別的配置信息，我們做到可以指定域存儲的表，存儲的時長，超大日志域獨立分區(qū)存儲，降低日志合并的CPU消耗。自定義字段默認是按照數(shù)組存儲，有些域打印的自定義日志字段較多，在日志量大的情況下，速度較慢，配置了自定義映射物理字段存儲，可以提供比數(shù)組更快的查詢速度和壓縮率。

1）clickhouse表schema信息

2）域自定義存儲元數(shù)據(jù)信息

經(jīng)過轉(zhuǎn)換后的數(shù)據(jù)，攜帶了存儲到CK表所需要的所有信息，將臨時存儲在本地的一個隊列內(nèi)，本地隊列可能混合存儲了多個域多張表的日志，達到指定的長度或時間后，再被提交到一個進程級的全局隊列內(nèi)。

因為writer進程是多線程消費多個kafka分區(qū)，全局隊列將同一個表多個線程的數(shù)據(jù)合并到一起，使得單次提交的批次更大，全局線程短暫緩沖，當滿足寫入條數(shù)，大小或超時后，數(shù)據(jù)將被作為一次寫入，提交到submit worker線程。submit worker負責數(shù)據(jù)的寫入，高可用，負載均衡，容錯和重試等邏輯。

submit收到提交的批量數(shù)據(jù)后，隨機尋找一個可用的clickhosue分片，提交寫入到分片節(jié)點。clickhouse集群配置是雙副本，當一個副本節(jié)點失敗時，將嘗試切換寫入到另一個節(jié)點上，如果兩個都失敗，則暫時剔除分片，重新尋找一個健康的分片寫入。

寫入數(shù)據(jù)到Clickhouse我們使用的是clickhouse-jdbc，起初寫入時消耗內(nèi)存和CPU都較大，對jdbc源碼進行分析后，我們發(fā)現(xiàn)jdbc寫入數(shù)據(jù)時，先把所有數(shù)據(jù)轉(zhuǎn)換成一個List對象，這個list對象相當于提交數(shù)據(jù)的byte[]副本格式，為了降低這個占用，在數(shù)據(jù)轉(zhuǎn)換步驟我們進行優(yōu)化，每條日志數(shù)據(jù)直接轉(zhuǎn)換為jdbc可以直接使用的List數(shù)據(jù)，這樣jdbc在構(gòu)造生成SQL的時候，拿到的數(shù)據(jù)其實是List的一個引用，這個優(yōu)化降低了約三分之一內(nèi)存消耗。

另外對writer進程做火焰圖分析時，我們發(fā)現(xiàn)jdbc在生成SQL時，會把提交數(shù)據(jù)的每個字符進行判定，識別出特殊字符如'\', '\n', '\b'等做轉(zhuǎn)義，這個轉(zhuǎn)義操作使用的是map函數(shù)，在數(shù)據(jù)量大時，消耗了約17%的CPU，我們對此做了優(yōu)化，使用swtich后，內(nèi)存大幅降低，節(jié)約了13%的CPU消耗。

clickhouse的弱集群概念保證了單節(jié)點宕機時，整個集群幾乎不受影響，submit高可用保證了當節(jié)點異常時，數(shù)據(jù)仍然可以正常寫入到健康節(jié)點，從而使得整個日志寫入非常穩(wěn)定，幾乎沒有因為節(jié)點宕機導(dǎo)致的延遲情況。

關(guān)于日志攝入Clickhouse的方式，石墨開源了另一種攝入方式，創(chuàng)建KafkaEngine表直接消費clickhouse，再將數(shù)據(jù)導(dǎo)入到物化視圖內(nèi)，通過物化視圖最終導(dǎo)入到本地表。這種方式好處是節(jié)省了一個writer的組件，上報到kafka的數(shù)據(jù)直接就可以存儲到clickhouse，但缺點非常多：

• 每個topic都需要創(chuàng)建獨立的KafkaEngine，如果需要切換表，增加topic，都要變更DDL，并且無法支持一個topic不同域存儲到不同表。

• 另外解析kafka數(shù)據(jù)和物化視圖都要消耗節(jié)點CPU資源，而clickhouse合并和查詢都是非常依賴cpu資源的操作，這會加重clickhouse的負載，從而限制了clickhosue整體吞吐，影響了查詢性能，需要擴容更多的節(jié)點來緩解此問題，clickhouse的單臺服務(wù)器需要更多核數(shù)，SSD和大磁盤存儲，因此擴容成本很高。 

選擇了將解析寫入組件獨立出來，可解決上面提到的很多問題，也為后期很多擴展功能提供了很大靈活性，好處很多，不再一一列舉。

3、存儲 - Clickhouse

1）高吞吐寫入

提交到Clickhouse的數(shù)據(jù)以二維表的形式存儲，二維表我們使用的是Clickhouse最常用的MergeTree引擎，關(guān)于MergeTree更詳細的描述可以參考網(wǎng)上這篇文章《MergeTree的存儲結(jié)構(gòu)》。

https://developer.aliyun.com/article/761931spm=a2c6h.12873639.0.0.2ab34011q7pMZK

• 數(shù)據(jù)在磁盤的邏輯存儲示意圖

MergeTree采用類似LSM-Tree數(shù)據(jù)結(jié)構(gòu)存儲，每次提交的批量數(shù)據(jù)，按照表的分區(qū)鍵，分別保存到不同的part目錄內(nèi)，一個part內(nèi)的行數(shù)據(jù)按照排序鍵進行排序后，再按列壓縮存儲到不同的文件內(nèi)，Clickhouse后臺任務(wù)會持續(xù)對這些每個小型的part進行合并，生成更大的part。

MergeTree雖然沒有ES的倒排索引，但有更輕量級的分區(qū)鍵，主鍵索引和跳數(shù)索引。

• 分區(qū)鍵可以確保查找的時候快速過濾掉很多part，例如按照時間搜索時，只命中時間范圍的part。

• 主鍵索引和關(guān)系型數(shù)據(jù)庫的主鍵不同，是用來對排序數(shù)據(jù)塊進行快速查找的輕量級索引。

• 跳數(shù)索引則根據(jù)索引類型對字段值進行索引，例如minmax索引指定字段的最大值和最小值，set存儲了字段的唯一值進行索引，tokenbf_v1則對字段進行切分，創(chuàng)建bloomfilter索引，查詢的時候可以直接根據(jù)關(guān)鍵字計算日志是否在對應(yīng)數(shù)據(jù)塊內(nèi).

一個part的數(shù)據(jù)會被按照排序鍵進行排序，然后按照大小切分成一個個較小的塊(index_granularity)，塊默認有8192行，同時主鍵索引對每個塊的邊界進行索引，跳數(shù)索引則根據(jù)索引的字段生成索引文件，通常這三者生成的索引文件都非常小，可緩存在內(nèi)存中加速查詢。

了解了MergeTree的實現(xiàn)原理，我們可以發(fā)現(xiàn)，影響Clickhouse寫入的一個關(guān)鍵因素是part的數(shù)量，每次寫入都會產(chǎn)生一個part，part越多，那么后臺合并任務(wù)也將越繁忙。除了這個因素外，part的生成和合并均需要消耗CPU和磁盤IO。

所以總結(jié)一下，三個影響寫入的因素：

• part數(shù)量 - 少

• CPU核數(shù) - 多

• 磁盤IO - 高

要提高寫入吞吐，就需要從這三個因素入手，降低part數(shù)量，提高CPU核數(shù)，提高磁盤IO。

將圖中的方法按照實現(xiàn)手段進行分類：

• 硬件

CPU核數(shù)越多越好，我們生產(chǎn)環(huán)境40+，磁盤SSD是標配，由于SSD價格貴容量小，采用SSD+HDD冷熱分離模式

• 表結(jié)構(gòu)

長日志量又大的域使用bloomfilter索引加速查詢，其他域則使用普通跳數(shù)索引即可，我們測試觀察能節(jié)約近一半的CPU。

• 數(shù)據(jù)寫入

Writer提交的數(shù)據(jù)，按照分區(qū)鍵進行分批提交，或者部分分區(qū)字段都可，也即單次提交的分區(qū)鍵基數(shù)盡可能小，最理想為1，此方法可大大降低小part數(shù)量。分區(qū)鍵的選擇上，可根據(jù)應(yīng)用日志的數(shù)量選擇獨立分區(qū)鍵，存儲大日志量域，大日志量應(yīng)用通常會達到條數(shù)閾值提交，可使得合并的part都是較大part，效率高；或者混合分區(qū)鍵，將小應(yīng)用混合在一個分區(qū)提交。

2）高速查詢

很多次，我和別人解釋為什么日志系統(tǒng)沒有(全文索引)仍然這么快的原因時，我都直接丟出這張圖，圖源自商用產(chǎn)品Humio公司的網(wǎng)站，也是我們老板多次推薦我們學習參考的一個產(chǎn)品，2021年初已被CrowdStrike以4億美元收購。

1PB的數(shù)據(jù)存儲，沒有了全文索引的情況，直接暴力檢索一個關(guān)鍵字，肯定是超時的，如果先經(jīng)過時間，標簽以及bloomfilter進行過濾篩選后，再執(zhí)行暴力搜索，則需要檢索的數(shù)據(jù)量會小的多。MergeTree引擎是列式存儲，壓縮率很高，高壓縮率有很多優(yōu)勢，從磁盤讀取的數(shù)據(jù)量少，頁面緩存需要的內(nèi)存少，更多的文件可以緩存在高速內(nèi)存中，Clickhouse有和Humio一樣的向量化執(zhí)行和SIMD，在查詢時，這些內(nèi)存中的壓縮數(shù)據(jù)塊會被CPU批量的執(zhí)行SIMD指令，由于塊足夠小，通常為壓縮前1M，這樣函數(shù)向量執(zhí)行和SIMD計算的數(shù)據(jù)足夠全部放在cpu緩存內(nèi)，不僅減少了函數(shù)調(diào)用次數(shù)，并且cpu cache的miss率大大降低。查詢速度相比沒有向量執(zhí)行和SIMD有數(shù)倍提升。

4、應(yīng)用維度日志TTL

起初我們計劃使用表級別的TTL來管理日志，將不同存儲時長的日志放入不同的表內(nèi)，但這樣會導(dǎo)致表和物化視圖變得非常多，不方便管理，后來使用了一個改進方案，將TTL放在表分區(qū)字段內(nèi)，開發(fā)一個簡單的定時任務(wù)，每天掃描刪除所有超過TTL日期的part，這樣做到了一張表支持不同TTL的日志存儲，靈活性非常高，應(yīng)用可以通過界面很方便查看和調(diào)整存儲的時長。

5、自定義字段存儲方案

標準格式日志內(nèi)的自定義字段名稱由業(yè)務(wù)輸出，基數(shù)是不確定的，我們第一版方案是創(chuàng)建數(shù)百個字符串，整數(shù)和浮點數(shù)的擴展字段，由開發(fā)自行配置這個自定義映射，后來發(fā)現(xiàn)這個方案存在嚴重缺陷：

• 開發(fā)需要將日志的每一個字段均手動配置到映射上去，隨著日志的變更，這樣的字段越來越多，隨著數(shù)量膨脹將難以維護，

• Clickhouse需要創(chuàng)建大量的列來保存這些字段，由于所有應(yīng)用混合在一起存儲，對于大多數(shù)應(yīng)用，太多列不但浪費，并且降低了存儲速度，占用了大量的文件系統(tǒng)INODE節(jié)點

后來借鑒了Uber日志存儲的方案，每種數(shù)據(jù)類型的字段，分別創(chuàng)建兩個數(shù)組，一個保存字段名稱，另一個保存字段值，名字和值按順序一一對應(yīng)，查詢時，使用clickhouse的數(shù)組檢索函數(shù)來檢索字段，這種用法支持所有的Clickhouse函數(shù)計算。

[type]_names和[type]_values分別存儲對應(yīng)數(shù)據(jù)類型字段的名稱和值。

1）插入

多層嵌套的json字段將被打平存儲，例如{"json": {"name": "tom"}}將轉(zhuǎn)換為 json_name="tom"字段。

不再支持數(shù)組的存儲，數(shù)組字段值將被轉(zhuǎn)換為字符串存儲，例如：{"json": [{"name": "tom", "age": 18}]}，轉(zhuǎn)換為json="[{\"name\": \"tom\", \"age\": 18}]"。

2）查詢

原來的映射自定義字段目前仍然保留10個，如果不夠，可以隨時添加，可以支持一些域的固定自定義字段，或者一些特殊類型的日志，例如審計日志，系統(tǒng)日志等，這些字段在查詢的時候用戶可以使用原來的名稱，訪問Clickhouse之前會被替換為表字段名稱

自定義字段的另一個方案是存儲在map內(nèi)，可以節(jié)約兩個字段，查詢也更簡單，但經(jīng)過我們測試，查詢性能沒有數(shù)組好：

• 數(shù)組存儲壓縮率相比比Map略好。

• 數(shù)組查詢速度比Map快1.7倍以上。

• Map的查詢語法比數(shù)組簡單，在前端簡化了數(shù)組的查詢語法情況下，這個優(yōu)勢可忽略。

四、前端日志查詢系統(tǒng)

日志系統(tǒng)第一版是基于kibana開發(fā)的，版本較老。2.0系統(tǒng)我們直接拋棄舊版，自研了一套查詢系統(tǒng)，效果如下：

新版查詢會自動對用戶輸入的查詢語句進行分析，添加上查詢的應(yīng)用域名和時間范圍等，降低用戶操作難度，支持多租戶隔離。

自定義字段的查詢是非常繁瑣的，我們也做了一個簡化操作：

• string_values[indexOf(string_names, 'name')] 簡化為：str.name

• number_values[indexOf(number_names, 'height')] 簡化為：num.height

Clickhouse一次執(zhí)行一條語句，日志查詢時柱狀圖和TOP示例日志是兩條語句，會使得查詢時間范圍翻倍，參考攜程的優(yōu)化方法，查詢詳情時，我們會根據(jù)柱狀圖的結(jié)果，將時間范圍縮小至TOP條記錄所在的時間區(qū)間。

豐富查詢用法

Clickhouse豐富的查詢語法，讓我們新日志系統(tǒng)的查詢分析功能非常強大，從海量日志提取關(guān)鍵字，非常容易，下面列舉兩個查詢用法:

• 從文本和JSON混合的日志數(shù)據(jù)中提取JSON字段

• 從日志計算分位數(shù)

五、正確使用姿勢

• 打印日志不要太長，不超過10K。

• 查詢條件帶上有跳數(shù)索引的標簽，或者其他非日志詳情的字段，召回日志數(shù)越小，查詢速度越快。

OLAP數(shù)據(jù)庫Clickhouse是處理大規(guī)模數(shù)據(jù)密集型場景的利器，非常適合海量日志存儲和查詢分析，構(gòu)建了一個低成本，無單點，高吞吐，高速查詢的下一代日志系統(tǒng)。?