微服務治理實戰：Hadoop和Spark，都不及Clickhouse香

語言: CN / TW / HK
時間 2022-01-28 07:44:40

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

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

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

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

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

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

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

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

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

  • ...

運營好微服務離不開三種資料分析：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)

「」
「」