一、背景

日志記錄了一個(gè)系統(tǒng)的行為，對于了解系統(tǒng)、診斷問題、輔助審計(jì)等都有極其重要的作用。通常最近一段時(shí)間的日志訪問頻率是最高的，我們通過聚合日志，分析日志、匯總數(shù)據(jù)，幫助開發(fā)、運(yùn)維、DBA了解業(yè)務(wù)的狀態(tài)和行為。這次實(shí)踐是針對MySQL的抓包日志進(jìn)行分析，當(dāng)前系統(tǒng)不足以支持新的需求，需要重構(gòu)一套日志分析系統(tǒng)。

現(xiàn)有抓包系統(tǒng)是將 MySQL 請求的所有 SQL 語句抓取并分析之后寫入到 Clickhouse 中，數(shù)據(jù)可以用來分析數(shù)據(jù)庫的操作。 可以查找當(dāng)前實(shí)例、庫、表有多少 AppCode 在訪問、數(shù)據(jù)庫資源是否可以回收、輔助審計(jì)等功能。

Sniffer 抓包之后將數(shù)據(jù)寫入到 Kafka 中，Clickhouse 直接消費(fèi) Kafka 的隊(duì)列中數(shù)據(jù)，并將數(shù)據(jù) merge 到 Clickhouse 中。由 Server 程序按照天級別定時(shí)讀取 Clickhouse 中的數(shù)據(jù)，分析、匯總數(shù)據(jù)，并解析請求 IP 對應(yīng)的服務(wù)信息等，最后將結(jié)果寫入到 MySQL 中。

當(dāng)前數(shù)據(jù)為日志數(shù)據(jù)，允許少部分丟失或重復(fù)，Kafka 隊(duì)列中的數(shù)據(jù)約有 133w/s (單個(gè)隊(duì)列最多 33W )，MySQL 中存儲(chǔ)的結(jié)果數(shù)據(jù)規(guī)模大約在 4.6T 左右。

二、名詞解釋

• AppCode

服務(wù)的名稱，是一個(gè)服務(wù)的基本屬性。

• Clickhouse

一個(gè)用于聯(lián)機(jī)分析(OLAP)的列式數(shù)據(jù)庫。

• Kafka

一個(gè)高性能的分布式隊(duì)列服務(wù)。

• Zookeeper

一個(gè)分布式的開源協(xié)調(diào)服務(wù)。

• 擴(kuò)展性

在業(yè)務(wù)量上漲時(shí)，服務(wù)通過較低的代價(jià)就可以滿足對業(yè)務(wù)量上漲的需求。

• 聚合比

將 N 條數(shù)據(jù)按照同一緯度聚合為 M 條數(shù)據(jù)，M 一定小于等于 N。聚合比 = 聚合之后的數(shù)據(jù)條數(shù)/聚合之前的數(shù)據(jù)條數(shù)。

三、現(xiàn)狀分析

1、消費(fèi)能力不足導(dǎo)致數(shù)據(jù)丟失

Clickhouse 消費(fèi) Kafka 隊(duì)列中的數(shù)據(jù)能力不足，延遲較高。并且 Kafka 中的數(shù)據(jù)只保留 3 個(gè)小時(shí)，根據(jù)測試四個(gè)節(jié)點(diǎn) Clickhouse 消費(fèi)的 Kafka 隊(duì)列中的數(shù)據(jù)，約有 80% 的數(shù)據(jù)丟失，導(dǎo)致數(shù)據(jù)不完整。

2、服務(wù)信息計(jì)算不準(zhǔn)確

Server 是天級別計(jì)算請求的服務(wù)信息。由于服務(wù)已經(jīng)上云部署，單個(gè)服務(wù)的 IP 變動(dòng)非常頻繁，導(dǎo)致 Server 獲取到服務(wù)信息有延遲(最高延遲 24 小時(shí))，甚至很多計(jì)算的結(jié)果是錯(cuò)誤的。這導(dǎo)致部分場景下分析出來的數(shù)據(jù)完全不可信。

3、匯總數(shù)據(jù)較少

當(dāng)前只匯總了四個(gè)維度的請求數(shù)據(jù)，并且只有天級別的數(shù)據(jù)，粒度較大，無法下鉆查詢具體信息，展示的維度和明細(xì)信息較少。

4、服務(wù)監(jiān)控&可用性

Server 節(jié)點(diǎn)目前只有一個(gè)，缺乏可用性并沒有詳細(xì)的監(jiān)控信息。

四、需求

針對當(dāng)前服務(wù)的不足，設(shè)計(jì)一套服務(wù)需要滿足當(dāng)前日志計(jì)算性能和業(yè)務(wù)需求，并且具備較好的擴(kuò)展性。

五、目標(biāo)

1、高性能、高擴(kuò)展性、高可用

服務(wù)需要具備以下特性：

1）高性能

在有限資源的情況下，盡可能提高數(shù)據(jù)消費(fèi)、聚合能力，降低數(shù)據(jù)丟失的概率，降低數(shù)據(jù)入庫的延遲。

2）高可用

單個(gè)或多個(gè)節(jié)點(diǎn)出現(xiàn)問題時(shí)，不影響服務(wù)整體的可用性。

3）高擴(kuò)展

在未來業(yè)務(wù)日志體量進(jìn)一步增長時(shí)，僅通過增加部署節(jié)點(diǎn)或者修改配置，就可以滿足增長的需求，無需額外的工作。

2、降低計(jì)算請求業(yè)務(wù)信息的延遲

從請求 IP 到獲取服務(wù)信息的延遲降低在 1min 以內(nèi)，確保 99.9% 的準(zhǔn)確性。

3、更多維度匯總數(shù)據(jù)和下鉆查詢

支持更多維度的匯總信息查詢，以及支持部分場景下的下鉆查詢。

4、監(jiān)控

提供多種監(jiān)控?cái)?shù)據(jù)，方便展示服務(wù)情況，根據(jù)監(jiān)控即可以方便定位到問題。

六、分析

當(dāng)前 Clickhouse 消費(fèi)能力不足可以通過擴(kuò)展節(jié)點(diǎn)和調(diào)優(yōu)參數(shù)進(jìn)一步解決，但是服務(wù)信息計(jì)算是 Clickhouse 做不到的，并且 OLAP 類型的數(shù)據(jù)庫對數(shù)據(jù)更新并不是太友好，尤其是大規(guī)模的更新。如果要解決【降低計(jì)算請求業(yè)務(wù)信息的延遲】這個(gè)問題可以有兩個(gè)解決方案：

如果采用方案一，會(huì)增加 Sniffer 端的不可控性，這與我們之前設(shè)計(jì)的盡可能減少 Sniffer 端資源消耗的初衷相違背，所以我們選擇方案二。

七、設(shè)計(jì)

1、整體流程

整體流程設(shè)計(jì)如下所示：

2、模塊劃分

所有模塊的目標(biāo)： 高性能、高可用、高擴(kuò)展。

3、dubaiMeta

1）說明

由于基礎(chǔ)服務(wù)不能提供高性能的 IP-AppCode 映射信息的接口，需要自行實(shí)現(xiàn)這一功能。對接基礎(chǔ)服務(wù)的 IP-AppCode 映射信息提供的接口，實(shí)時(shí)從 Kafka-OPS 隊(duì)列中獲取 IP-AppCode 映射變更的信息流，Merge 到當(dāng)前數(shù)據(jù)，并提供 IP-AppCode 信息的接口；

2）設(shè)計(jì)

由于 dubaiMeta 是提供基礎(chǔ)信息的接口，訪問量比較大，需要提供高性能、高可用、高擴(kuò)展性，故 dubaiMeta 需要盡可能設(shè)計(jì)成為無狀態(tài)的服務(wù)。

將所有的 IP-AppCode 映射數(shù)據(jù)存儲(chǔ)在 MySQL，映射為最新版本。所有的 IP-AppCode 變更歷史也都會(huì)存儲(chǔ)在 MySQL。通過版本信息持續(xù)將 IP-AppCode 變更信息 Merge 到最新版本。目前 IP-AppCode 數(shù)據(jù)整體體量不大，可以在服務(wù)內(nèi)部緩存，不使用其他緩存。這樣既可以減少網(wǎng)絡(luò)和緩存的請求，降低請求耗時(shí)，也會(huì)避免因?qū)彺娴囊蕾嚩鴮?dǎo)致的性能和可用性問題。這樣 dubaiMeta 就可能成為一個(gè)接近無狀態(tài)的服務(wù)。

單個(gè)請求如果不能命中緩存則會(huì)請求基礎(chǔ)服務(wù)的 IP-AppCode 接口，并將變更數(shù)據(jù) Merge 到緩存。但是單個(gè) dubaiMeta 節(jié)點(diǎn)數(shù)據(jù)變更之后如何與其他 dubaiMeta 節(jié)點(diǎn)通訊最后達(dá)到所有節(jié)點(diǎn)數(shù)據(jù)一致？

有兩種方案：

盡可能保證單個(gè)節(jié)點(diǎn)的高性能的，并檢測單個(gè)節(jié)點(diǎn)的數(shù)據(jù)一致性延遲，將有問題的服務(wù)及時(shí)下掉，通過這個(gè)方法可以盡可能減低數(shù)據(jù)不一致帶來的問題。故選擇【變更通知】的方式；

3）啟動(dòng)流程

服務(wù)啟動(dòng)時(shí)首先從 Kafka-OPS 持續(xù)訂閱信息流，所有變更信息 Merge 到內(nèi)部緩存，然后再從 Self-Kafka-OPS 中持續(xù)訂閱變更信息流，所有變更信息 Merge 到內(nèi)部緩存，最后從 MySQL 中獲取全量的數(shù)據(jù)信息，將所有數(shù)據(jù) Merge 到緩存，組合成全量的數(shù)據(jù)。等到所有數(shù)據(jù) Merge 完成，并且兩個(gè) Kafka 隊(duì)列無堆積時(shí)，再提供服務(wù)。

4）性能分析

目前基礎(chǔ)信息的數(shù)據(jù)量不大，可以在服務(wù)內(nèi)部緩存，不使用其他緩存。既可以減少網(wǎng)絡(luò)和訪問緩存的耗時(shí)，大幅度降低請求的耗時(shí)，又可以避免因?qū)彺娴囊蕾嚩鴮?dǎo)致的性能和可用性問題。

單節(jié)點(diǎn) IP-AppCode 映射變更會(huì)發(fā)起變更通知，異步通知其他節(jié)點(diǎn)，無需感知其他節(jié)點(diǎn)存在，故性能可以得到保證。

5）可用性分析

dubaiMeta 目前所有數(shù)據(jù)存儲(chǔ)在本地緩存，在 MySQL 中存儲(chǔ)一份副本和變更信息流。

由于 dubaiMeta 是接近無狀態(tài)的，部署多個(gè)節(jié)點(diǎn)，通過負(fù)載均衡服務(wù)下發(fā)到不同的節(jié)點(diǎn)就可以保證整體服務(wù)的可用性。

MySQL 通過平臺(tái)已有的 HA，保證可用性；

6）擴(kuò)展性分析

由于 dubaiMeta 是接近無狀態(tài)的，故可以橫向擴(kuò)展，不對其他節(jié)點(diǎn)產(chǎn)生影響，只需要在負(fù)載均衡器上添加節(jié)點(diǎn)即可。

4、SnifferServer

1）說明

從 Kafka-Sniffer 隊(duì)列獲取日志數(shù)據(jù)，在日志中補(bǔ)充各種業(yè)務(wù)信息，并聚合數(shù)據(jù)。最后將聚合之后的結(jié)果批量寫入到 Clickhouse 中。

由于隊(duì)列中的數(shù)據(jù)量比較大，無法全量存儲(chǔ)所有數(shù)據(jù)，需要按照一定的維度聚合數(shù)據(jù)。通過降低聚合比(聚合之后的數(shù)據(jù)條數(shù)/聚合之前的數(shù)據(jù)條數(shù))可以降低總體數(shù)據(jù)量，在保證性能的前提下盡可能縮短入庫的時(shí)間。

由于 Clickhouse 是 OLAP 分析類型的列式數(shù)據(jù)庫，更推薦批量寫入的方式提高數(shù)據(jù)庫的寫入性能(每次不少于 1000 條)。

2）設(shè)計(jì)

針對單個(gè)隊(duì)列，可以使用多個(gè) SnifferServer 使用同一個(gè) consumerGroup 消費(fèi)數(shù)據(jù)，保證消費(fèi)者的性能、可用性，同時(shí) SnifferServer 也具備了一定的擴(kuò)展性。

SnifferServer 是內(nèi)存消耗和 cpu 消耗類型的服務(wù)。為了減少 gc 和內(nèi)存消耗，通過復(fù)用對象，確保單個(gè)服務(wù)內(nèi)部對象的數(shù)量不會(huì)有較大波動(dòng)，可以大幅度降低 gc 以及內(nèi)存的使用量，提高性能。

按照功能，將 SnifferServer 拆分成三個(gè)模塊：consumer 模塊、aggregator 模塊、writer 模塊。

consumer 模塊消費(fèi)隊(duì)列中的數(shù)據(jù)，將數(shù)據(jù)傳遞給 aggregator 模塊；aggregator 模塊填充業(yè)務(wù)信息并聚合數(shù)據(jù)，將聚合之后的數(shù)據(jù)傳遞給 writer 模塊；writer 模塊將數(shù)據(jù)批量寫入到 Clickhouse 中。

① consumer 模塊

• 功能

從 Kafka-Sniffer 隊(duì)列中獲取數(shù)據(jù)，將數(shù)據(jù)組合之后批量傳輸給 aggregator 模塊。

• 分析

針對單個(gè) Kafka 隊(duì)列，提升消費(fèi)的速度途徑有：

經(jīng)測試，在當(dāng)前場景配置下，單個(gè) SnifferServer 消費(fèi)隊(duì)列速度可以達(dá)到 20W/s+。 通過對 consumer 的調(diào)優(yōu)已經(jīng)能夠完全達(dá)到 33w/s （兩個(gè) SnifferServer）的消費(fèi)速度，已完全滿足業(yè)務(wù)的需求。

② aggregator 模塊

• 功能

從 consumer 接受數(shù)據(jù)，并獲取 IP-AppCode 映射信息和業(yè)務(wù)信息，將信息補(bǔ)充到日志數(shù)據(jù)中。等到一定數(shù)量的數(shù)據(jù)或者超時(shí)之后，將這一批次的數(shù)據(jù)按照指定的維度聚合。最后將聚合之后的結(jié)果傳輸給 writer 模塊

• 分析
• 如果每條數(shù)據(jù)都需要通過接口獲取 IP-AppCode 映射和業(yè)務(wù)信息，那樣會(huì)大大降低聚合的效率，故本地需要緩存 IP-AppCode 和業(yè)務(wù)信息。aggregator 模塊同樣也需要訂閱 Kafka-OPS 和 Self-Kafka-OPS 變更，Merge IP-AppCode 變更信息到本地緩存。
• 通過增加 aggregator 線程數(shù)量提升并發(fā)數(shù)，可以有效的提升聚合的效率。但線程數(shù)越多會(huì)在不同程度上提高聚合比(和業(yè)務(wù)行為相關(guān))，通過增加單個(gè)批次的數(shù)量可以降低聚合比，兩個(gè)指標(biāo)需要根據(jù)需要測試調(diào)優(yōu)；

經(jīng)測試：針對同一個(gè)隊(duì)列中的數(shù)據(jù)，單個(gè) SnifferServer 的聚合比約為 10%-20% 左右，兩個(gè) SnifferServer 的平均聚合比約為 15%-30% 左右，三個(gè) SnifferServer 的平均聚合比約為 30% 以上，故在同等配置的情況下增加 SnifferServer 則會(huì)增加聚合比，存儲(chǔ)端將增加數(shù)據(jù)量。

③ writer 模塊

• 功能

從 aggregator 模塊接受數(shù)據(jù)，緩存在內(nèi)存中。當(dāng)緩存數(shù)據(jù)超過 N 條或者緩存時(shí)間超過 M 秒之后再將緩存數(shù)據(jù)批量寫入到 Clickhouse 中；

• 分析

每個(gè)批次應(yīng)該盡可能緩存足夠的的數(shù)據(jù)量再寫入數(shù)據(jù)，提升寫入的效率，降低寫入的次數(shù)，預(yù)設(shè)單個(gè)批次為 1w(最少，可配置)條數(shù)據(jù)；

3）分析

每個(gè)模塊均可以設(shè)置緩存大小和并行的線程數(shù)，通過設(shè)置緩存大小和并行的線程數(shù)可以提高效率。但是需要注意的是，緩存大小和并行線程越多，占用的資源也就越多。并且如果程序意外終止，那么丟失的數(shù)據(jù)也會(huì)變多，需要酌情考慮各個(gè)參數(shù)的配置。

對于各個(gè)模塊的啟動(dòng)和關(guān)閉順序需要額外關(guān)注。

① 模塊啟動(dòng)順序

先啟動(dòng) writer 模塊，初始化 writer 模塊的緩存和線程，再啟動(dòng) aggregator 模塊，初始化 aggregator 的緩存和線程，最后啟動(dòng) consumer 模塊，初始化 consumer 模塊的線程和緩存。

② 模塊關(guān)閉順序

為了減少數(shù)據(jù)丟失，在正常情況下關(guān)閉服務(wù)時(shí)需要按照以下順序關(guān)閉模塊

• 關(guān)閉所有的Kafka的連接；
• 將 consumer 模塊中所有緩存數(shù)據(jù)發(fā)送到 aggregator 模塊之后，再關(guān)閉所有 consumer 模塊的線程；
• 將 aggregator 中的緩存數(shù)據(jù)立即聚合（所有日志數(shù)據(jù)補(bǔ)完業(yè)務(wù)信息，并聚合完成）。聚合完成的數(shù)據(jù)全部發(fā)送給 writer 模塊之后，再關(guān)閉所有 aggregator 模塊的線程；
• 將 writer 模塊中的數(shù)據(jù)分批次，全部寫入到 Clickhouse 中，最后關(guān)閉所有 writer 模塊的線程。

4）擴(kuò)展性分析

由于 SnifferServer 是偏計(jì)算類型的服務(wù)，并且從 Kafka 到 SnifferServer 到 Clickhouse，需要大量的數(shù)據(jù)傳輸，需要較好的 cpu 和網(wǎng)卡才可以充分發(fā)揮 SnifferServer 的性能；

① SnifferServer 內(nèi)部擴(kuò)展性

SnifferServer 的每個(gè)模塊都可以通過設(shè)置線程數(shù)和緩存大小提高性能；

② SnifferServer 級別的擴(kuò)展性

對于單個(gè)隊(duì)列，受限于 Kafka 的 partition 數(shù)量，最多有于 partition 數(shù)量相等的 SnifferServer 運(yùn)行，超過 partition 數(shù)量時(shí)節(jié)點(diǎn)不再參與隊(duì)列消費(fèi)；

③ Kafka 的 Partition

單個(gè) Kafka 集群的 partition 理論上沒有限制，受限于服務(wù)器資源、Zookeeper 和運(yùn)維的方便性等，需要設(shè)置上限；

④ 整個(gè)服務(wù)

可以規(guī)劃針對不同的 IDC，向不同的 Kafka 寫入日志數(shù)據(jù)，這樣日志數(shù)據(jù)將被分區(qū)；

5）可用性分析

SnifferServer 之間通過 consumerGroup 消費(fèi) Kafka 隊(duì)列中的數(shù)據(jù)。對于單個(gè)隊(duì)列通過冗余 SnifferServer，即使單個(gè) SnifferServer 掛掉，不會(huì)影響整體服務(wù)。

5、SnifferAnalyze

1）說明

按照天級別定時(shí)從 Clickhouse 中獲取聚合數(shù)據(jù)，分析、匯總，存儲(chǔ)分析之后的結(jié)果并提供接口和頁面展示結(jié)果。

2）設(shè)計(jì)

分析匯總之后的結(jié)果大概分為兩類數(shù)據(jù)，第一類是初步聚合的粗粒度數(shù)據(jù)，數(shù)據(jù)量比較大。數(shù)據(jù)一旦產(chǎn)生不會(huì)修改，只有大范圍的刪除，一般是溯源、分析、下鉆查詢使用，使用的頻率不是很高；第二類是匯總的報(bào)告數(shù)據(jù)。部分?jǐn)?shù)據(jù)會(huì)存在大范圍的修改，較多的并發(fā)查詢。整體數(shù)據(jù)量相對于第一類數(shù)據(jù)量較少，一般是展示結(jié)果、接口查詢較多；

Clickhouse 在大規(guī)模存儲(chǔ)上的單表查詢和寫入效率較高，壓縮效率較高但不擅長做并發(fā)查詢和頻繁的修改數(shù)據(jù)，官網(wǎng)建議每秒最多查詢 100 次。相比較而言，MySQL 適合存儲(chǔ)小體量數(shù)據(jù)，以及數(shù)據(jù)的增刪改查，并擅長高并發(fā)查詢。

綜合考慮節(jié)省存儲(chǔ)成本以及各個(gè)存儲(chǔ)的特性，第一類數(shù)據(jù)適合存儲(chǔ)到 Clickhouse 中，第二類數(shù)據(jù)適合存儲(chǔ)到 MySQL 中。針對原始日志數(shù)據(jù)設(shè)置合適的過期時(shí)間，超過指定時(shí)間的數(shù)據(jù)都予以刪除，而匯總數(shù)據(jù)相較于原始數(shù)據(jù)量已經(jīng)大幅度減少，可以保留較長的過期時(shí)間。

依托 Clickhouse 的分析能力，對于第一類數(shù)據(jù)直接將 Clickhouse 中的數(shù)據(jù)分析出來直接寫入到 Clickhouse 中，避免中間轉(zhuǎn)儲(chǔ)。第二類數(shù)據(jù)需要從 Clickhouse 中獲取出來，分析、計(jì)算、匯總之后再寫入到 MySQL 中。

每個(gè)任務(wù)執(zhí)行前都需要獲取鎖，只有成功獲取到鎖的任務(wù)才可以執(zhí)行該任務(wù)。SnifferAnalyze 多個(gè)節(jié)點(diǎn)在執(zhí)行任務(wù)前會(huì)通過搶占的方式獲取任務(wù)鎖，僅當(dāng)成功獲取了鎖的節(jié)點(diǎn)會(huì)執(zhí)行任務(wù)，保證了單個(gè)節(jié)點(diǎn)掛掉不影響分析任務(wù)的執(zhí)行。但是如果任務(wù)執(zhí)行過成中被終端，目前需要人為介入處理。

3）擴(kuò)展性分析

目前分析類型的任務(wù)節(jié)點(diǎn)擴(kuò)展能力有限。

4）可用性分析

由于分析類型的任務(wù)擴(kuò)展能力有限，故只能在節(jié)點(diǎn)之間保證高可用。并且一旦任務(wù)執(zhí)行中斷需要人為介入處理。

6、Clickhouse

1）說明

Clickhouse 架構(gòu)圖

例如圖示 Clickhouse 有兩個(gè)分片(A 和 B)，每個(gè)分片有兩個(gè)副本([A1,A2],[B1,B2])，集群與三節(jié)點(diǎn)的 Zookeeper 通訊。

① 同步

Clickhouse 集群 Replication 引擎的副本是通過 Zookeeper 實(shí)現(xiàn)的，Zookeeper 存儲(chǔ)數(shù)據(jù)塊的元數(shù)據(jù)信息。分片 A 有 A1 和 A2 兩個(gè)節(jié)點(diǎn)，A1 和 A2 共同監(jiān)聽 Zookeeper 執(zhí)行目錄下節(jié)點(diǎn)的數(shù)據(jù)。當(dāng) A1 節(jié)點(diǎn)寫入數(shù)據(jù)塊之后，A1 在 Zookeeper 上變更元數(shù)據(jù)信息。A2 收到 Zookeeper 的元數(shù)據(jù)變更之后，向 A1 發(fā)起拉取指定數(shù)據(jù)塊的通知，A1 將指定的數(shù)據(jù)塊發(fā)送給 A2，完成數(shù)據(jù)傳輸。同理 A2 也可以寫入數(shù)據(jù)，通知 Zookeeper 變更數(shù)據(jù)，并向 A1 傳輸數(shù)據(jù)。數(shù)據(jù)同步是異步的，傳輸數(shù)據(jù)塊時(shí)會(huì)去重。更多副本相關(guān)的信息請見官網(wǎng)說明。

② 分片

分片依靠 Distribute 引擎實(shí)現(xiàn)。Distribute 引擎不存儲(chǔ)任何數(shù)據(jù)，Clickhouse 有 Distribute 引擎支持將數(shù)據(jù)按照指定的規(guī)則(random,hash,range,自定義)將數(shù)據(jù)分發(fā)到各個(gè)分片。

數(shù)據(jù)寫入 Distribute 引擎時(shí)，數(shù)據(jù)在本地寫入完成后立即返回。Clickhouse 會(huì)周期性的按照規(guī)則將數(shù)據(jù)分發(fā)的其他節(jié)點(diǎn)上。

③ 查詢

通過 Distribute 引擎查詢時(shí)，無論分片規(guī)則是什么樣的，Distribute 都會(huì)將 SQL 分發(fā)到所有的分片上查詢，并在當(dāng)前節(jié)點(diǎn)匯總數(shù)據(jù)，最后返回給客戶端。如果查詢 Replication 引擎的表，那么只查詢本地?cái)?shù)據(jù)。

2）可用性分析

Clickhouse 的 Replication 引擎和 Zookeeper 實(shí)現(xiàn)數(shù)據(jù)副本，保證了每個(gè)分片內(nèi)可以允許一個(gè)副本宕機(jī)。Distribute 引擎可以保證在 Clickhouse 所有節(jié)點(diǎn)上都可以寫入和讀取。

但是通過數(shù)據(jù)同步是異步的。如果節(jié)點(diǎn)寫入成功并在數(shù)據(jù)尚未完成傳輸之前宕機(jī)，無法恢復(fù)，則尚未同步的數(shù)據(jù)塊將會(huì)丟失。

3）擴(kuò)展性分析

由于 Distribute 查詢的時(shí)候會(huì)將 SQL 分發(fā)到所有的分片上，無論分片的數(shù)據(jù)狀態(tài)如何，故新增的節(jié)點(diǎn)可以直接加入到 Clickhouse 集群中，而無需擔(dān)心舊數(shù)據(jù)遷移的問題。但是需要考慮數(shù)據(jù)傾斜問題，通過提高新加入節(jié)點(diǎn)權(quán)重可以將新寫入的數(shù)據(jù)更多的發(fā)送到新加入分片上。

向 Distribute 引擎寫入數(shù)據(jù)時(shí)，Distribute 引擎首先會(huì)寫入本地，再依次轉(zhuǎn)發(fā)給其他節(jié)點(diǎn)，可能會(huì)導(dǎo)致本地網(wǎng)絡(luò)流量增加、服務(wù) merge 數(shù)據(jù)塊時(shí)產(chǎn)生額外的 cpu 以及 IO 使用的問題。可以通過只寫入本地表，而不寫入 Distribute 表解決這個(gè)問題。但是需要通過一定的策略(比如輪詢)寫入不同的 Clickhouse 節(jié)點(diǎn)，解決數(shù)據(jù)傾斜的問題。

7、監(jiān)控

1）說明

當(dāng)前監(jiān)控只是用于查看各個(gè)節(jié)點(diǎn)的狀態(tài)情況，展示性能問題，并未提供高級別的功能。監(jiān)控告警接入公司現(xiàn)有的監(jiān)控系統(tǒng)。

八、效果

1、SnifferServer

所有 SnifferServer 節(jié)點(diǎn)平均內(nèi)存占用約為 12G 左右，最大 gc 平均約為 21ms，75 分位的 gc 平均約為 0.6ms。

兩節(jié)點(diǎn) SnifferServer 合計(jì) CPU(32核)利用率峰值約 70%，網(wǎng)卡峰值 上行約 330Mb/s  下行  400Mb/s。

單個(gè)隊(duì)列數(shù)據(jù)生成速度峰值約為 30w/s，平均堆積約 20k，消費(fèi)者速度要快于生產(chǎn)者。

aggregator 平均每秒聚合 1.2 次，數(shù)據(jù)聚合比約為 40%，writer 每秒約寫入 6 次，業(yè)務(wù)信息和 appCode 命中率幾乎 100%。

2、頁面展示

展示某個(gè)業(yè)務(wù)的平均響應(yīng)時(shí)間和查詢次數(shù)

展示某個(gè)慢查詢的平均響應(yīng)時(shí)間和查詢次數(shù)

九、總結(jié)

SnifferServer 將隊(duì)列中的日志數(shù)據(jù)補(bǔ)全業(yè)務(wù)信息、聚合數(shù)據(jù)、將結(jié)果寫入到 Clickhouse 中，SnifferAnalyze 定期分析數(shù)據(jù)，將結(jié)果寫入到 Clickhouse 和 MySQL。整個(gè)系統(tǒng)具備高性能、高可用性、高擴(kuò)展性的優(yōu)點(diǎn)，內(nèi)存和 CPU 使用率比較穩(wěn)定。日志分析系統(tǒng)呈現(xiàn)出來的結(jié)果可以幫助開發(fā)更好的了解業(yè)務(wù)的行為，發(fā)現(xiàn)潛在的問題，評估業(yè)務(wù)在數(shù)據(jù)庫方面的風(fēng)險(xiǎn)。結(jié)合慢查詢風(fēng)險(xiǎn)指數(shù)系統(tǒng)可以更精確的評估慢查詢的風(fēng)險(xiǎn)。