本文將從以下五部分切入，講述日志系統(tǒng)的演進(jìn)之路：攜程日志的背景和現(xiàn)狀、如何搭建一套日志系統(tǒng)、從 ElasticSearch 到 Clickhouse 存儲(chǔ)演進(jìn)、日志3.0重構(gòu)及未來計(jì)劃。

【資料圖】

一、日志背景及現(xiàn)狀

圖1

2012年以前，攜程的各個(gè)部門日志自行收集治理（如圖1）。這樣的方式缺乏統(tǒng)一標(biāo)準(zhǔn)，不便治理管控，也更加消耗人力和物力。

從2012年開始，攜程技術(shù)中心推出基于 ElasticSearch 的日志系統(tǒng)，統(tǒng)一了日志的接入、ETL、存儲(chǔ)和查詢標(biāo)準(zhǔn)。隨著業(yè)務(wù)量的增長(zhǎng)，數(shù)據(jù)量膨脹到 4PB 級(jí)別，給原來的 ElasticSearch 存儲(chǔ)方案帶來不少挑戰(zhàn)，如 OOM、數(shù)據(jù)延遲及負(fù)載不均等。此外，隨著集群規(guī)模的擴(kuò)大，成本問題日趨敏感，如何節(jié)省成本也成為一個(gè)新的難題。

2020年初，我們提出用 Clickhouse 作為主要存儲(chǔ)引擎來替換 ElasticSearch 的方案，該方案極大地解決了 ElasticSearch 集群遇到的性能問題，并且將成本節(jié)省為原來的48%。2021年底，日志平臺(tái)已經(jīng)累積了20+PB 的數(shù)據(jù)量，集群也達(dá)到了數(shù)十個(gè)規(guī)模（如圖2）。

2022年開始，我們提出日志統(tǒng)一戰(zhàn)略，將公司的 CLOG 及 UBT 業(yè)務(wù)統(tǒng)一到這套日志系統(tǒng)，預(yù)期數(shù)據(jù)規(guī)模將達(dá)到 30+PB。同時(shí)，經(jīng)過兩年多的大規(guī)模應(yīng)用，日志集群累積了各種各樣的運(yùn)維難題，如集群數(shù)量激增、數(shù)據(jù)遷移不便及表變更異常等。因此，日志3.0應(yīng)運(yùn)而生。該方案落地了類分庫分表設(shè)計(jì)、Clickhouse on Kubernetes、統(tǒng)一查詢治理層等，聚焦解決了架構(gòu)和運(yùn)維上的難題，并實(shí)現(xiàn)了攜程 CLOG 與 ESLOG 日志平臺(tái)統(tǒng)一。

圖2

二、如何搭建日志系統(tǒng)2.1架構(gòu)圖

從架構(gòu)圖來看（如圖3），整個(gè)日志系統(tǒng)可以分為：數(shù)據(jù)接入、數(shù)據(jù) ETL、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)查詢展示、元數(shù)據(jù)管理系統(tǒng)和集群管理系統(tǒng)。

圖3

2.2 數(shù)據(jù)接入

數(shù)據(jù)接入主要有兩種方式：

第一種是使用公司框架 TripLog 接入到消息中間件 Kafka（Hermes協(xié)議）（如圖4）。

圖4

第二種是用戶使用 Filebeat/Logagent/Logstash 或者寫程序自行上報(bào)數(shù)據(jù)到 Kafka（如圖5），再通過 GoHangout 寫入到存儲(chǔ)引擎中。

圖5

2.3 數(shù)據(jù)傳輸ETL（GoHangout）

GoHangout 是仿照Logstash 做的一個(gè)開源應(yīng)用（??Github鏈接??），用于把數(shù)據(jù)從 Kafka 消費(fèi)并進(jìn)行 ETL，最終輸出到不同的存儲(chǔ)介質(zhì)（Clickhouse、ElasticSearch）。其中數(shù)據(jù)處理 Filter 模塊包含了常見的 Json 處理、Grok 正則匹配和時(shí)間轉(zhuǎn)換等一系列的數(shù)據(jù)清理功能（如圖6）。GoHangout 會(huì)將數(shù)據(jù) Message 字段中的 num 數(shù)據(jù)用正則匹配的方式提取成單獨(dú)字段。

圖6

2.4ElasticSearch 數(shù)據(jù)存儲(chǔ)

早期2012年第一版，我們使用 ElasticSearch 作為存儲(chǔ)引擎。ElasticSearch 存儲(chǔ)主要由 Master Node、Coordinator Node、Data Node 組成（如圖7）。Master 節(jié)點(diǎn)主要負(fù)責(zé)創(chuàng)建或刪除索引，跟蹤哪些節(jié)點(diǎn)是集群的一部分，并決定哪些分片分配給相關(guān)的節(jié)點(diǎn)；Coordinator 節(jié)點(diǎn)主要用于處理請(qǐng)求，負(fù)責(zé)路由請(qǐng)求到正確的節(jié)點(diǎn)，如創(chuàng)建索引的請(qǐng)求需要路由到 Master 節(jié)點(diǎn)；Data 節(jié)點(diǎn)主要用于存儲(chǔ)大量的索引數(shù)據(jù)，并進(jìn)行增刪改查，一般對(duì)機(jī)器的配置要求比較高。

圖7

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

數(shù)據(jù)展示方面我們使用了 Elastic Stack 家族的 Kibana（如圖8）。Kibana 是一款適合于 ElasticSearch 的數(shù)據(jù)可視化和管理工具，提供實(shí)時(shí)的直方圖、線形圖、餅狀圖和表格等，極大地方便日志數(shù)據(jù)的展示。

圖8

2.6 表元數(shù)據(jù)管理平臺(tái)

表元數(shù)據(jù)管理平臺(tái)是用戶接入日志系統(tǒng)的入口，我們將每個(gè) Index/ Table 都定義為一個(gè)Scenario（如圖9）。我們通過平臺(tái)配置并管理 Scenario 的一些基礎(chǔ)信息，如：TTL、歸屬、權(quán)限、ETL 規(guī)則和監(jiān)控日志等。

圖9

三、 從Elasticsearch到Clickhouse

我們將會(huì)從背景、Clickhouse 簡(jiǎn)介、ElasticSearch 對(duì)比和解決方案四方面介紹日志從 ElasticSearch 到 Clickhouse 的演進(jìn)過程。2020年初，隨著業(yè)務(wù)量的增長(zhǎng)，給 ElasticSearch 集群帶來了不少難題，主要體現(xiàn)在穩(wěn)定性、性能和成本三個(gè)方面。

（1）穩(wěn)定性上：

ElasticSearch 集群負(fù)載高，導(dǎo)致較多的請(qǐng)求 Reject、寫入延遲和慢查詢。每天 200TB 的數(shù)據(jù)從熱節(jié)點(diǎn)搬遷到冷節(jié)點(diǎn)，也有不少的性能損耗。節(jié)點(diǎn)間負(fù)載不均衡，部分節(jié)點(diǎn)單負(fù)載過高，影響集群穩(wěn)定性。大查詢導(dǎo)致 ElasticSearch 節(jié)點(diǎn) OOM。

（2）性能上：

ElasticSearch的吞吐量也達(dá)到瓶頸。查詢速度受到整體集群的負(fù)載影響。

（3）成本上：

倒排索引導(dǎo)致數(shù)據(jù)壓縮率不高。大文本場(chǎng)景性價(jià)比低，無法保存長(zhǎng)時(shí)間數(shù)據(jù)。3.1 Clickhouse 簡(jiǎn)介與 Elasticsearch 對(duì)比

Clickhouse 是一個(gè)用于聯(lián)機(jī)分析（OLAP）的列式數(shù)據(jù)庫管理系統(tǒng)（DBMS）。Yandex 在2016年開源，使用 C++ 語法開發(fā)，是一款PB級(jí)別的交互式分析數(shù)據(jù)庫。包含了以下主要特效：列式存儲(chǔ)、Vector、Code Generation、分布式、DBMS、實(shí)時(shí)OLAP、高壓縮率、高吞吐、豐富的分析函數(shù)和 Shared Nothin g架構(gòu)等。

圖10

Clickhouse采用的是 SQL 的交互方式，非常方便上手。接下來，我們將簡(jiǎn)單介紹一下 Clickhouse 的類 LSM、排序鍵、分區(qū)鍵特效，了解 Clickhouse 的主要原理。

首先，用戶每批寫入的數(shù)據(jù)會(huì)根據(jù)其排序鍵進(jìn)行排序，并寫入一個(gè)新的文件夾（如201905_1_1_0），我們稱為 Part C0（如圖10）。隨后，Clickhouse 會(huì)定期在后臺(tái)將這些 Part 通過歸并排序的方式進(jìn)行合并排序，使得最終數(shù)據(jù)生成一個(gè)個(gè)數(shù)據(jù)順序且空間占用較大的 Part。這樣的方式從磁盤讀寫層面上看，能充分地把原先磁盤的隨機(jī)讀寫巧妙地轉(zhuǎn)化為順序讀寫，大大提升系統(tǒng)的吞吐量和查詢效率，同時(shí)列式存儲(chǔ)+順序數(shù)據(jù)的存儲(chǔ)方式也為數(shù)據(jù)壓縮率提供了便利。201905_1_1_0與201905_3_3_0合并為201905_1_3_1就是一個(gè)經(jīng)典的例子。

另外，Clickhouse 會(huì)根據(jù)分區(qū)鍵（如按月分區(qū)）對(duì)數(shù)據(jù)進(jìn)行按月分區(qū)。05、06月的數(shù)據(jù)被分為了不同的文件夾，方便快速索引和管理數(shù)據(jù)。

圖11

我們看中了 Clickhouse 的列式存儲(chǔ)、向量化、高壓縮率和高吞吐等特效（如圖11），很好地滿足了我們當(dāng)下日志集群對(duì)性能穩(wěn)定性和成本的訴求。于是，我們決定用Clickhouse來替代原本 ElasticSearch 存儲(chǔ)引擎的位置。

3.2 解決方案

有了存儲(chǔ)引擎后，我們需要實(shí)現(xiàn)對(duì)用戶無感知的存儲(chǔ)遷移。這主要涉及了以下的工作內(nèi)容（如圖12）：自動(dòng)化建表、GoHangout 修改、Clickhouse 架構(gòu)設(shè)計(jì)部署和 Kibana 改造。

圖12

（1）庫表設(shè)計(jì)

圖13

我們對(duì)ck在日志場(chǎng)景落地做了很多細(xì)節(jié)的優(yōu)化（如圖13），主要體現(xiàn)在庫表設(shè)計(jì)：

我們采用雙 list 的方式來存儲(chǔ)動(dòng)態(tài)變化的 tags（當(dāng)然最新的版本22.8，也可以用map和新特性的 json 方式）。按天分區(qū)和時(shí)間排序，用于快速定位日志數(shù)據(jù)。Tokenbf_v1 布隆過濾用于優(yōu)化 term 查詢、模糊查詢。_log_increment_id 全局唯一遞增 id，用于滾動(dòng)翻頁和明細(xì)數(shù)據(jù)定位。ZSTD 的數(shù)據(jù)壓縮方式，節(jié)省了40%以上的存儲(chǔ)成本。

（2）Clickhouse存儲(chǔ)設(shè)計(jì)

Clickhouse 集群主要由查詢集群、多個(gè)數(shù)據(jù)集群和 Zookeeper 集群組成（如圖14）。查詢集群由相互獨(dú)立的節(jié)點(diǎn)組成，節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)是無狀態(tài)的。數(shù)據(jù)集群則由Shard組成，每個(gè) Shard 又涵蓋了多個(gè)副本 Replica。副本之間是主主的關(guān)系（不同于常見的主從關(guān)系），兩個(gè)副本都可以用于數(shù)據(jù)寫入，互相同步數(shù)據(jù)。而副本之間的元數(shù)據(jù)一致性則有 Zookeeper 集群負(fù)責(zé)管理。

圖14

（3）數(shù)據(jù)展示

為了實(shí)現(xiàn)用戶無感知的存儲(chǔ)切換，我們專門實(shí)現(xiàn)了 Kibana 對(duì) Clickhouse 數(shù)據(jù)源的適配并開發(fā)了不同的數(shù)據(jù) panel（如圖15），包括：chhistogram、chhits、chpercentiles、chranges、chstats、chtable、chterms 和 chuniq。通過 Dashboard 腳本批量生產(chǎn)替代的方式，我們快速地實(shí)現(xiàn)了原先 ElasticSearch 的 Dashboard 的遷移，其自動(dòng)化程度達(dá)到95%。同時(shí)，我們也支持了使用 Grafana 的方式直接配置 SQL 來生成日志看板。

圖15

（4）集群管理平臺(tái)

為了更好地管理 Clickhouse 集群，我們也做了一整套界面化的 Clickhouse 運(yùn)維管理平臺(tái)。該平臺(tái)覆蓋了日常的 shard 管理、節(jié)點(diǎn)生成、綁定/解綁、權(quán)重修改、DDL 管理和監(jiān)控告警等治理工具（如圖16）。

圖16

3.3 成果遷移過程自動(dòng)化程度超過95%，基本實(shí)現(xiàn)對(duì)用戶透明。存儲(chǔ)空間節(jié)約50+%（如圖17），用原有ElasticSearch的服務(wù)器支撐了4倍業(yè)務(wù)量的增長(zhǎng)。查詢速度比ElasticSearch快4~30倍，查詢P90小于300ms，P99小于1.5s。

圖17

四、 日志3.0構(gòu)建

時(shí)間來到2022年，公司日志規(guī)模再進(jìn)一步增加到 20+PB。同時(shí)，我們提出日志統(tǒng)一戰(zhàn)略，將公司的 CLOG 及 UBT 業(yè)務(wù)統(tǒng)一到這套日志系統(tǒng)，預(yù)期數(shù)據(jù)規(guī)模將達(dá)到 30+PB。另外，經(jīng)過兩年多的大規(guī)模應(yīng)用，日志系統(tǒng)也面臨了各種各樣的運(yùn)維難題。

(1) 性能與功能痛點(diǎn)

單集群規(guī)模太大，Zookeeper 性能達(dá)到瓶頸，導(dǎo)致 DDL 超時(shí)異常。當(dāng)表數(shù)據(jù)規(guī)模較大時(shí)，刪除字段，容易超時(shí)導(dǎo)致元數(shù)據(jù)不一致。用戶索引設(shè)置不佳導(dǎo)致查詢慢時(shí)，重建排序鍵需要?jiǎng)h除歷史數(shù)據(jù)，重新建表。查詢層缺少限流、防呆和自動(dòng)優(yōu)化等功能，導(dǎo)致查詢不穩(wěn)定。

(2) 運(yùn)維痛點(diǎn)

表與集群嚴(yán)格綁定，集群磁盤滿后，只能通過雙寫遷移。集群搭建依賴 Ansible，部署周期長(zhǎng)（數(shù)小時(shí)）。Clickhouse 版本與社區(qū)版本脫節(jié)，目前集群的部署模式不便版本更新。

面對(duì)這樣的難題，我們?cè)?022年推出了日志3.0改造，落地了集群 Clickhouse on Kubernetes、類分庫分表設(shè)計(jì)和統(tǒng)一查詢治理層等方案，聚焦解決了架構(gòu)和運(yùn)維上的難題。最終，實(shí)現(xiàn)了統(tǒng)一攜程 CLOG 與 ESLOG 兩套日志系統(tǒng)。

4.1 ck on k8s

我們使用 Statefulset、反親和、Configmap 等技術(shù)實(shí)現(xiàn)了 Clickhouse 和 Zookeeper 集群的 Kubernetes 化部署，使得單集群交付時(shí)間從2天優(yōu)化到5分鐘。同時(shí)，我們統(tǒng)一了部署架構(gòu)，將海內(nèi)外多環(huán)境部署流程標(biāo)準(zhǔn)化。這種方式顯著地降低了運(yùn)維成本并釋放人力。更便利的部署方式有益于單個(gè)大集群的切割，我們將大集群劃分為多個(gè)小集群，解決了單集群規(guī)模過大導(dǎo)致 Zookeeper 性能瓶頸的問題。

4.2 類分庫分表設(shè)計(jì)

圖18

（1）數(shù)據(jù)跨如何跨集群

假設(shè)我們有三個(gè)數(shù)據(jù)集群1、2、3和三個(gè)表A、B、C（如圖18）。在改造之前，我們單張表（如A）只能坐落在一個(gè)數(shù)據(jù)集群1中。這樣的設(shè)計(jì)方式，導(dǎo)致了當(dāng)集群1磁盤滿了之后，我們沒有辦法快速地將表A數(shù)據(jù)搬遷到磁盤相對(duì)空閑的集群2中。我們只能用雙寫的方式將表A同時(shí)寫入到集群1和集群2中，等到集群2的數(shù)據(jù)經(jīng)過了TTL時(shí)間（如7天）后，才能將表A從數(shù)據(jù)集群1中刪除。這樣，對(duì)我們的集群運(yùn)維管理帶來了極大的不方便和慢響應(yīng)，非常耗費(fèi)人力。

于是，我們?cè)O(shè)計(jì)一套類分庫分表的架構(gòu)，來實(shí)現(xiàn)表A在多個(gè)集群1、2、3之間來回穿梭。我們可以看到右邊改造后，表A以時(shí)間節(jié)點(diǎn)作為分庫分表的切換點(diǎn)（這個(gè)時(shí)間可以是精確到秒，為了好理解，我們這里以月來舉例）。我們將6月份的數(shù)據(jù)寫入到集群1、7月寫到集群2、8月寫到集群3。當(dāng)查詢語句命中6月份數(shù)據(jù)時(shí)，我們只查詢集群1的數(shù)據(jù)；當(dāng)查詢語句命中7月和8月的數(shù)據(jù)，我們就同時(shí)查詢集群2和集群3的數(shù)據(jù)。

我們通過建立不同分布式表的方式實(shí)現(xiàn)了這個(gè)能力（如：分布式表tableA_06/tableA_07/tableA_08/tableA_0708，分布式表上的邏輯集群則是是集群1、2、3的組合）。這樣，我們便解決了表跨集群的問題，不同集群間的磁盤使用率也會(huì)趨于平衡。

（2）如何修改排序鍵不刪除歷史數(shù)據(jù)

非常巧妙的是，這種方式不僅能解決磁盤問題。Clickhouse 分布式表的設(shè)計(jì)只關(guān)心列的名稱，并不關(guān)心本地?cái)?shù)據(jù)表的排序鍵設(shè)置?；谶@種特性，我們?cè)O(shè)計(jì)表A在集群2和集群3使用不一樣的排序鍵。這樣的方式也能夠有效解決初期表A在集群2排序鍵設(shè)計(jì)不合理的問題。我們通過在集群3上重新建立正確的排序鍵，讓其對(duì)新數(shù)據(jù)生效。同時(shí)，表A也保留了舊的7月份數(shù)據(jù)。舊數(shù)據(jù)會(huì)在時(shí)間的推移一下被TTL清除，最終數(shù)據(jù)都使用了正確的排序鍵。

（3）如何解決刪除大表字段導(dǎo)致元數(shù)據(jù)不一致

更美妙的是，Clickhouse 的分布式表設(shè)計(jì)并不要求表A在7月和8月的元數(shù)據(jù)字段完全一致，只需要有公共部分就可以滿足要求。比如表A有在7月有11個(gè)字段，8月份想要?jiǎng)h除一個(gè)棄用的字段，那么只需在集群3上建10個(gè)字段的本地表A，而分布式表 tableA_0708 配置兩個(gè)表共同擁有的10個(gè)字段即可（這樣查分布式表只要不查被刪除的字段就不會(huì)報(bào)錯(cuò)）。通過這種方式，我們也巧妙地解決了在數(shù)據(jù)規(guī)模特別大的情況下（單表百TB），刪除字段導(dǎo)致常見的元數(shù)據(jù)不一致問題。

（4）集群升級(jí)

同時(shí)，這種多版本集群的方式，也能方便地實(shí)現(xiàn)集群升級(jí)迭代，如直接新建一個(gè)集群4來存儲(chǔ)所有的09月的表數(shù)據(jù)。集群4可以是社區(qū)最新版本，通過這種迭代的方式逐步實(shí)現(xiàn)全部集群的升級(jí)。

4.3 元數(shù)據(jù)管理

為了實(shí)現(xiàn)上述的功能，我們需要維護(hù)好一套完整的元數(shù)據(jù)信息，來管理表的創(chuàng)建、寫入和 DDL（如圖19）。該元數(shù)據(jù)包含每個(gè)表的版本定義、每個(gè)版本數(shù)據(jù)的數(shù)據(jù)歸屬集群和時(shí)間范圍等。

圖19

4.4 統(tǒng)一查詢治理層

（1）Antlr4 的 SQL 解析

在查詢層，我們基于 Antlr4 技術(shù)，將用戶的查詢 SQL 解析成 AST 樹。通過 AST 樹，我們能夠快速地獲得 SQL 的表名、過濾條件、聚合維度等（如圖20）。我們拿到這些信息后，能夠非常方便地對(duì) SQL 實(shí)時(shí)針對(duì)性的策略，如：數(shù)據(jù)統(tǒng)計(jì)、優(yōu)化改寫和治理限流等。

圖20

（2）查詢代理層

圖21

我們對(duì)所有用戶的SQL查詢做了一層統(tǒng)一的查詢網(wǎng)關(guān)代理（如圖21）。該程序會(huì)根據(jù)元數(shù)據(jù)信息和策略對(duì)用戶的 SQL 進(jìn)行改寫，實(shí)現(xiàn)了精準(zhǔn)路由和性能優(yōu)化等功能。同時(shí)，該程序會(huì)記錄每次查詢的明細(xì)上下文，用于對(duì)集群的查詢做統(tǒng)一化治理，如：QPS 限制、大表掃描限制和時(shí)間限制等拒絕策略，來提高系統(tǒng)的穩(wěn)定性。

五、未來計(jì)劃

通過日志3.0的構(gòu)建，我們重構(gòu)了日志系統(tǒng)的整體架構(gòu)，實(shí)現(xiàn)集群 Kubernetes 化管理，并成功地解決了歷史遺留的 DDL 異常、數(shù)據(jù)跨集群讀寫、索引重構(gòu)優(yōu)、磁盤治理和集群升級(jí)等運(yùn)維難題。2022年，日志系統(tǒng)成果地支撐了公司 CLOG 與 UBT 業(yè)務(wù)的數(shù)據(jù)接入，集群數(shù)據(jù)規(guī)模達(dá)到了30+PB。

當(dāng)然，攜程的日志系統(tǒng)演進(jìn)也不會(huì)到此為止，我們的系統(tǒng)在功能、性能和治理多方面還有不少改善的空間。在未來，我們將進(jìn)一步完善日志統(tǒng)一查詢治理層，精細(xì)化地管理集群查詢與負(fù)載；推出日志預(yù)聚合功能，對(duì)大數(shù)據(jù)量的查詢場(chǎng)景做加速，并支持 AI智能告警；充分地運(yùn)用云上能力，實(shí)現(xiàn)彈性混合云，低成本支撐節(jié)假日高峰；推到日志產(chǎn)品在攜程系各個(gè)公司的使用覆蓋等。讓我們一起期待下一次的日志升級(jí)。

關(guān)鍵詞： 數(shù)據(jù)管理 歷史數(shù)據(jù) 刪除字段