微服務治理實戰:Hadoop和Spark,都不及Clickhouse香

語言: CN / TW / HK

一、微服務治理暴露出的資料儲存問題

隨著微服務架構在好大夫的推進,帶來了諸多便利,同時服務間呼叫越來越複雜,也面臨了一系列難題:

  • 如何離線分析識別出不合理的服務依賴?

  • 基於鏈路分析如何快速定位問題?

  • 如何控制成本儲存億級日誌資料?

  • 如何從億級資料裡提煉分析出有價值的指標?

  • 如何實時分析億級資料及時觸發告警?

  • 針對長期指標如何選儲存引擎?

  • 如何聚攏不同的資料來源打造友好的視覺化介面?

  • ...

運營好微服務離不開三種資料分析:Metrics,Tracing,Logging。

首先 Tracing 日誌反映微服務間的鏈路拓撲,分析服務效能,追蹤定位鏈路問題。也就是常說的 APM (Application Performance Management) 即應用效能管理分析。好大夫 APM 分析,是基於自研的 TraceLog 模型。

另外一類日誌是服務執行時產生的 log,如 nginx,tomcat,服務自定義的日誌等,好大夫服務執行時產生的日誌 LocalLog 也有自己的一套規範。

Metrics 主要用於監控告警,大部分指標提煉於 Tracing 和 Logging。好大夫早期日誌儲存分析基於 ELK 體系,服務執行監控告警也是實時從 ES 資料來源讀取。APM 則是離線分析後進行資料展示。

隨著業務的發展,日誌在不斷增加,Elasticsearch 儲存壓力越來越大,磁碟 IO 瓶頸逐漸顯現。

另外告警項的增加,對時效性要求也越來越高,ES 實時查詢壓力驟增。

APM 部分場景需要實時查詢,聚合,計算同比、環比等,原先的 spark 體系按不同維度離線分析的模式不再靈活,離線還帶來了儲存成本的驟增,分析後的資料比原始資料還要大,聚合的時間維度比較粗。不太滿足實時異常定位分析。

再加上雲原生的推進,產生的日誌事件,傳統的模式對雲原生資源監控更加力不從心,從而引入了 Prometheus 體系。而 Prometheus 生態對長期持久化指標不太友好。

針對以上問題,一種主流的方案會選擇擁抱大資料生態,Hadoop、Hiv、Storm、Spark、Flink 等。

二、十字路口的抉擇

基於成本和應用場景考慮,我們否定了 Hadoop/Spark 解決方案!

世間沒有銀彈,Hadoop 體系也不例外。Hadoop/Spark 體系高度整合化,在提供了巨大的方便同時,也帶來了臃腫和複雜,各種元件強強組合,有時候顯得過於笨重,也帶來了巨大成本。

機器資源成本 + 運維成本 + 人力成本。

Hbase/Hiv 儲存基於物理機,再加上計算節點需要十多臺物理機。整體部署的成本和運維成本都比較高。

再者系統架構組內成員趨向 Golang 開發,而大資料生態偏向 Java。

同時大資料部門和系統架構部分屬兩個不同的組織架構,根據“康威定律”,這將帶來的巨大的無形溝通成本。

那有沒有不依賴 Hadoop 生態體系的解決方案呢?

回到原點

其實我們更多的使用場景是:

  • 實時性: 實時查詢服務 QPS/P99

  • 按不同維度聚合資料生成相應的指標: 服務介面維度指標,QPS/P99/錯誤率

  • 長期儲存資料支援降準稀疏: 服務長期趨勢指標,QPM/P99/服務拓撲關係

  • 高頻大批量寫入,低頻查詢: 億級 TPS 日誌寫入,分鐘級別讀取

  • 多維度列式查詢:不同維度的下鑽,上卷,切面,切塊,旋轉

  • 資料壓縮比高:吃住原先由 Elasticsearch/Prometheus 每日生成 TB 級別的日誌

  • 豐富的函式庫,豐富的資料型別: 統計函式/分位數/陣列函式等

  • 原生支援分散式叢集,多副本,多分割槽,高效的索引,豐富的引擎: 查詢秒級響應

先看一下資料庫全景圖,資料儲存種類比較豐富,關係型資料庫 OLTP/OLAP,非關係型 NoSQL。有支援列式儲存,有支援時序性儲存等等,針對不同的應用場景,精細劃分。

經過調研我們的應用場景是一種典型的 OLAP 模式,隨著調研的深入 Clickhouse 進入視野,它高效的效能讓我們感到驚歎。

在單個節點的情況下,對一張擁有 133 個欄位的資料表分別在 1000 萬、1 億和 10 億三種資料體量下執行基準測試,基準測試的範圍涵蓋 43 項 SQL 查詢。在 1 億資料集體量的情況下,ClickHouse 的平均響應速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的 429 倍以及 Greenplum 的 10 倍。不同型別的資料庫對比參考附錄,這裡給一個 ClickHouse 與 MySQL 效能對比圖。

最終基於功能、效能、成本考慮,我們選擇了 Clickhouse。

三、OLAP 領域的黑馬

Clickhouse 是俄羅斯 yandex 公司於 2016 年開源的一個列式資料庫管理系統,在 OLAP 領域像一匹黑馬一樣,以其超高的效能受到業界的青睞。

1、Clickhouse 為何這麼優秀

  • 完備的 DBMS 功能(Database Management System,資料庫管理系統)

  • 支援 DDL/DML/許可權控制/備份恢復/分散式管理等等

  • 列式儲存與資料壓縮

  • 同一列的資料往往有更高的共性,這意味著能有更高的壓縮比。在 Yandex.Metrica 的生產環境中,資料總體的壓縮比可以達到 8:1(未壓縮前 17PB,壓縮後 2PB)。列式儲存除了降低 IO 和儲存的壓力之外,還為向量化執行做好了鋪墊。

  • 向量化引擎與 SIMD 提高了 CPU 利用率,多核多節點並行化大查詢。

為了實現向量化執行,需要利用 CPU 的 SIMD 指令。SIMD 的全稱是 Single Instruction Multiple Data,即用單條指令操作多條資料。現代計算機系統概念中,它是通過資料並行以提高效能的一種實現方式(其他的還有指令級並行和執行緒級並行),它的原理是在 CPU 暫存器層面實現資料的並行操作。

1)多樣化的表引擎

ClickHouse 共擁有合併樹、記憶體、檔案、介面和其他 6 大類 20 多種表引,根據不同的場景選擇不同的引擎,而不是開發一種引擎適配多種場景。

2)多執行緒與分散式

由於 SIMD 不適合用於帶有較多分支判斷的場景,ClickHouse 也大量使用了多執行緒技術以實現提速,以此和向量化執行形成互補。

3)多主架構

ClickHouse 採用 Multi-Master 多主架構,叢集中的每個節點角色對等,天然規避了單點故障的問題,非常適合用於多資料中心、異地多活的場景。

4)資料分片與分散式查詢

資料分片是將資料進行橫向切分,這是一種在面對海量資料的場景下,解決儲存和查詢瓶頸的有效手段。ClickHouse 提供了本地表(Local Table)與分散式表(Distributed Table)的概念。藉助分散式表,能夠代理訪問多個數據分片,從而實現分散式查詢。

2、不足

  • 不支援事務、非同步刪除與更新

  • 不適用高併發場景

3、應用場景

ClickHouse 更適用於作為一個數據分析的資料庫,它非常擅長針對於乾淨的,結構化的,不變的日誌/事件資料進行分析。例如下述場景:

  • 網頁及 APP 分析(Web and App analytics)

  • 廣告網路以及廣告投放(Advertising networks and RTB)

  • 通訊領域(Telecommunications)

  • 線上電商以及金融(E-commerce and finance)