每分鐘寫入6億條數(shù)據(jù)，攜程監(jiān)控系統(tǒng)Dashboard存儲升級實踐

作者：大偉 2022-08-25 18:23:07

近些年，隨著攜程監(jiān)控All-in-One產(chǎn)品的提出。對于內(nèi)部的Metrics存儲統(tǒng)一也提出了新的要求。由于Dashboard查詢目前存在的諸多問題以及Metrics統(tǒng)一的目標(biāo)，我們決定替換升級Dashboard現(xiàn)有的HBase存儲方案，并且在Metrics場景提供統(tǒng)一的查詢層API。

?作者｜大偉，攜程軟件技術(shù)專家，關(guān)注企業(yè)級監(jiān)控、日志、可觀測性領(lǐng)域。

一、背景概述

框架Dashboard是一款攜程內(nèi)部歷史悠久的自研監(jiān)控產(chǎn)品，其定位是企業(yè)級Metrics監(jiān)控場景，主要提供用戶自定義Metrics接入，并基于此提供實時數(shù)據(jù)分析和視圖展現(xiàn)的面板服務(wù)，提供可定制的基于時間序列的各類系統(tǒng)級性能數(shù)據(jù)和業(yè)務(wù)指標(biāo)數(shù)據(jù)的看板。還可以提供靈活的數(shù)據(jù)收集接口、分布式的大容量存儲和靈活的展現(xiàn)方式。

由于時間較早，那時候業(yè)界還沒有像樣的TSDB產(chǎn)品，類似Prometheus，InfluxDB都是后起之秀，所以Dashboard選型主要使用了HBase來存儲Metrics數(shù)據(jù)。并且基于HBase來實現(xiàn)了TSDB，解決了一些HBase熱點問題，同時將部分查詢聚合下放到HBase，目的是優(yōu)化其查詢性能，目前看來總體方案依賴HBase/HDFS還是有點重。

二、整體架構(gòu)

Dashboard產(chǎn)品主要分了6個組件，包括dashboard-engine，dashboard-gateway，dashboard-writer，dashboard-HBase存儲，dashboard-collector，dashboard-agent。目前實時寫入數(shù)據(jù)行數(shù)6億條/分鐘，架構(gòu)圖如下：

dashboard-engine是查詢引擎。?
dashboard-gateway是提供給用戶的查詢界面。
dashboard-writer是數(shù)據(jù)寫入HBase的組件。
dashboard-collector是基于Netty實現(xiàn)的Metrics數(shù)據(jù)收集的服務(wù)端。
dashboard-agent是用戶打點的客戶端，支持sum，avg，max，min這幾種聚合方式。
dashboard-HBase是基于HBase實現(xiàn)的Metrics存儲組件。

產(chǎn)品主要特性如下：?

支持存儲精確到分鐘級的基于時間序列的數(shù)據(jù)。
單個指標(biāo)數(shù)據(jù)可支持多個tag。
展現(xiàn)提供任意形式的視圖同時可靈活基于tag進(jìn)行分組。

三、目前的存在問題

基于HBase的Metrics存儲方案雖然具有良好的擴(kuò)展性，比較高的吞吐，但是隨著時間發(fā)展，已經(jīng)不是最優(yōu)的TSDB方案了，可以歸納總結(jié)為如下幾個痛點。?

在TSDB場景查詢慢，整體表現(xiàn)不如專業(yè)的TSDB。
HBase熱點問題，容易影響數(shù)據(jù)寫入。
HBase技術(shù)棧運維操作很重。
采用自研協(xié)議，不支持業(yè)界標(biāo)準(zhǔn)的Prometheus協(xié)議，無法和內(nèi)部All-in-one監(jiān)控產(chǎn)品較好的融合。

四、替換難點?

系統(tǒng)寫入數(shù)據(jù)量大，6億條/分鐘。
Dashboard數(shù)據(jù)缺乏治理，很多不合理高維的metrics數(shù)據(jù)，日志型數(shù)據(jù)，經(jīng)過統(tǒng)計，整體基數(shù)達(dá)上千億，這對TSDB不友好，這部分需要寫入程序做治理。如圖2所示是top20基數(shù)統(tǒng)計，有很多Metric基數(shù)已經(jīng)上億。
Dashboard系統(tǒng)存在時間久，內(nèi)部有很多程序調(diào)用，替換需要做到對用戶透明。

五、替換升級方案

從上面的架構(gòu)來看，目前我們替換的主要是dashboard-writer和dashboard-HBase這兩個最核心的組件。為了對用戶的平滑遷移，其他組件稍作改動，在dashboard-engine組件上對接新的查詢API即可替換升級成功。對于用戶側(cè)，查詢的界面dashboard-gateway和打點的客戶端dashboard-agent還是原有的模式不變，因此整個的替換方案對用戶透明。具體如下：

1.1 dashboard-HBase升級為dashboard-vm

存儲從HBase方案替換成VictoriaMetrics+ClickHouse 混合存儲方案：

VictoriaMetrics是兼容主流Prometheus協(xié)議的TSDB，在TSDB場景下查詢效果好，所以會接入絕大多數(shù)TSDB數(shù)據(jù)。

基于ClickHouse提供元數(shù)據(jù)服務(wù)，主要為界面的adhoc查詢服務(wù)，原來這部分元數(shù)據(jù)是存儲在HBase里面，新的方案采用ClickHouse來存儲。元數(shù)據(jù)主要存儲了measurement列表，measurement-tagKey列表，measurement-tagKey-tagValue列表這三種結(jié)構(gòu)，目前在ClickHouse創(chuàng)建了一張表來存這些元數(shù)據(jù)。

本地表結(jié)構(gòu)為：

CREATE TABLE hickwall.downsample_mtv
(`timestamp` DateTime,
`metricName` String,
`tagKey` String,
`tagValue` String,
`datasourceId` UInt8 DEFAULT 40)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/hickwall_cluster-{shard}/downsample_mtv', '{replica}')
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp, metricName, tagKey)
TTL timestamp + toIntervalDay(7)
SETTINGS index_granularity = 8192

分布式表結(jié)構(gòu)為：

CREATE TABLE hickwall.downsample_mtv__dt 
(`timestamp` DateTime,
 `metricName` String,
 `tagKey` String,
 `tagValue` String,
 `datasourceId` UInt8 DEFAULT 40) 
ENGINE = Distributed(hickwall_cluster, hickwall, downsample_mtv, rand())

ClickHouse存儲少量日志型的數(shù)據(jù)

由于長期缺乏一些治理，Dashboard還存儲了一些日志型數(shù)據(jù)，這類數(shù)據(jù)是一些基數(shù)很大但數(shù)據(jù)量少的數(shù)據(jù)，不適合存儲在VictoriaMetrics。為了實現(xiàn)所有數(shù)據(jù)透明遷移，這部分?jǐn)?shù)據(jù)經(jīng)過評估，通過白名單配置的方式接入ClickHouse來存儲，需要針對每一個接入的日志型指標(biāo)來創(chuàng)建表和字段。目前的做法是按照BU維度來建表，并且針對指標(biāo)tag來創(chuàng)建字段，考慮到接入的日志型指標(biāo)數(shù)量少，所以表的字段數(shù)量會相對可控。用機(jī)票FLT的表結(jié)構(gòu)舉例如下圖。

1.2 Dashboard-writer升級為Dashboard-vmwriter

Dashboard-collector會分流全量的數(shù)據(jù)到Kafka，Dashboard-vmwriter的工作流程大致是消費Kafka->數(shù)據(jù)處理->數(shù)據(jù)寫入存儲。Dashboard-vmwriter主要實現(xiàn)了以下幾個核心的功能：

Metrics元數(shù)據(jù)抽取功能，負(fù)責(zé)抽取出measurement，tagKey，tagValue寫入ClickHouse的mtv本地表。這塊元數(shù)據(jù)存儲主要依賴了Redis（用于實時寫入）和ClickHouse（用于查詢）。

指標(biāo)預(yù)聚合功能，用于加速查詢。對接公司內(nèi)部的配置中心來下發(fā)預(yù)聚合的配置，配置格式如下。

下面的配置會生成ClusterName和appid這兩個維度組合的credis預(yù)聚合指標(biāo)。

{
        "metricName": "credis.java.latency",
        "tagNames": [
            "ClusterName",
            "appid"
        ]
}

?配置下發(fā)后，Dashboard-vmwriter會自動聚合一份預(yù)聚合指標(biāo)存入VictoriaMetrics，指標(biāo)命名規(guī)則為hi_agg.{measurement}_{tag1}_{tag2}_{聚合field}。同樣的，查詢層API會讀取同樣的預(yù)聚合配置來決定查詢預(yù)聚合的指標(biāo)還是原始的指標(biāo)，默認(rèn)為所有的measurement維度都開啟了一份預(yù)聚合的配置，因為在TSDB實現(xiàn)中，查一個measurement的數(shù)據(jù)會掃描所有的timeseries，查詢開銷很大，所以這部分直接去查預(yù)聚合好的measurement比較合理。

數(shù)據(jù)治理：異常數(shù)據(jù)自動檢測及封禁，目前主要涉及以下兩方面：

（1）基于HyperLogLog的算法來統(tǒng)計measurement級別的基數(shù)，如果measurement的基數(shù)超級大，比如超過500萬，那么就會丟棄一些tag維度。

（2）基于Redis和內(nèi)存cache來統(tǒng)計measurement-tagKey-tagValue的基數(shù)，如果某個tagValue增長過快，那么就丟棄這個tag的維度，并且記錄下丟棄這種埋點。Redis主要使用了set集合，key的命名是{measurement}_{tagKey}，成員是[tagValue1，tagValue2，… , tagValueN]，主要是通過sismember來判斷成員是否存在，sadd來添加成員，scard判斷key的成員數(shù)量。

寫入程序會先在本地內(nèi)存Cache查找Key的成員是否存在，沒有的話會去Redis查找，對Redis的qps是可控的，本地Cache是基于LRU的淘汰策略，本地內(nèi)存可控。整個過程是在寫入的時候?qū)崟r進(jìn)行的，也能保證數(shù)據(jù)的及時性和高性能，寫入Redis的元數(shù)據(jù)也會實時增量同步到ClickHouse的mtv表，這樣用戶界面也能實時查詢到元數(shù)據(jù)。

（3）數(shù)據(jù)高性能寫入，整個消費的線程模型大概是一個進(jìn)程一個kafka消費線程n個數(shù)據(jù)處理線程m個數(shù)據(jù)寫入線程。線程之間通過隊列來通信，為了在同一個進(jìn)程內(nèi)方便數(shù)據(jù)做預(yù)聚合操作。假設(shè)配置了4個數(shù)據(jù)處理線程，那么就會按照measurement做hash，分到4個bucket里面處理，這樣同一個measurement的數(shù)據(jù)會在一個bucket里面處理，也方便后續(xù)的指標(biāo)預(yù)聚合處理。

private int computeMetricNameHash(byte[] metricName) {
int hash = Arrays.hashCode(metricName);
hash = (hash == Integer.MIN_VALUE ? 0 : hash);
return hash;
}
byte[] metricName = metricEvent.getName();
hash = computeMetricNameHash(metricName);
buckets[Math.abs(hash) % bucketCount].add(metricEvent);

?經(jīng)過程序埋點測算，正常情況下整體鏈路的數(shù)據(jù)寫入延遲控制在1s內(nèi)，大約在百毫秒級。

1.3 Metrics統(tǒng)一查詢層

契約上，兼容了Dashboard原來的查詢協(xié)議，也支持標(biāo)準(zhǔn)的prometheus協(xié)議。

實現(xiàn)上，封裝了VictoriaMetics+ClickHouse的統(tǒng)一查詢，支持元數(shù)據(jù)管理，預(yù)聚合管理，限流，rollup策略等。

查詢層主要提供了以下四個核心接口。?

Data接口：根據(jù)measurement，tagKey，tagValue返回時序數(shù)據(jù)，數(shù)據(jù)源是VictoriaMetrics。
Measurement接口：返回limit數(shù)量的measurement列表，數(shù)據(jù)源是ClickHouse。
Measurement-tagKey接口：返回指定measurement的tagKey列表，數(shù)據(jù)源是ClickHouse。
Measurement-tagKey-tagValue接口：返回指定measurement和tagkey的tagValue的列表，數(shù)據(jù)源是ClickHouse。

如下圖第一張所示是新的存儲架構(gòu)，第二張是VictoriaMetrics自身的架構(gòu)。

需要注意到，整個數(shù)據(jù)寫入層是單機(jī)房寫單機(jī)房的存儲集群，是完全的單元化結(jié)構(gòu)。最上層通過統(tǒng)一的數(shù)據(jù)查詢層匯總多個機(jī)房的數(shù)據(jù)進(jìn)行聚合輸出。在可用性方面，任何單一機(jī)房的故障僅會影響單機(jī)房的數(shù)據(jù)。

六、替換前后效果對比

（1）替換后的查詢耗時從MAX，AVG，STD提升近4倍。查詢耗時大多落在10-50ms之間。相比之前HBase經(jīng)常查詢超時，整體查詢的穩(wěn)定些也好了很多，見圖6，7。

（2）寫入穩(wěn)定性提升，徹底解決了因為HBase熱點引發(fā)的數(shù)據(jù)積壓。

（3）替換后支持了更多的優(yōu)秀的特性，可以基于promQL實現(xiàn)指標(biāo)的邏輯計算，同比環(huán)比，模糊匹配等。

七、未來規(guī)劃

（1）統(tǒng)一查詢層接入所有Metrics數(shù)據(jù)，除了Dashboard，目前內(nèi)部還有HickWall，Cat有大量Metrics數(shù)據(jù)沒有接入統(tǒng)一查詢層，目前采用的是直連openrestry+VictoriaMetrics的方式，openrestry上面做了一些簡單的查詢邏輯，這塊計劃后續(xù)接入統(tǒng)一查詢層，這樣內(nèi)部可以提供統(tǒng)一的元信息管理，預(yù)聚合策略等，達(dá)到Metrics架構(gòu)統(tǒng)一。

（2）提供統(tǒng)一寫入層，總體Metrics目前是近億級/秒，這塊寫入目前主要是基于Kafka消費進(jìn)存儲的方式，內(nèi)部這塊寫入是有多個應(yīng)用在處理，如果有統(tǒng)一的寫入層那么就能做到寫入邏輯統(tǒng)一，和查詢層的查詢策略也能做到聯(lián)動，減少重復(fù)建設(shè)。

（3）Metrics的存儲統(tǒng)一層提供了較好的典范，內(nèi)部的日志存儲層統(tǒng)一也在如火如荼的進(jìn)行中，也會往這樣的一個方向發(fā)展。-

責(zé)任編輯：未麗燕來源：攜程技術(shù)

攜程 HBase存儲 Metrics

每分鐘寫入6億條數(shù)據(jù)，攜程監(jiān)控系統(tǒng)Dashboard存儲升級實踐

一、 背景概述

二、 整體架構(gòu)

三、 目前的存在問題

四、 替換難點?

五、 替換升級方案