張曉光：阿里巴巴雙十一實時監(jiān)控系統(tǒng)技術(shù)｜DataFunTalk

導(dǎo)讀：本次分享主要介紹以下四方面：

• 時序業(yè)務(wù)全景
• TSDB介紹
• 核心技術(shù)
• 總結(jié)展望

01

時序業(yè)務(wù)全景

從底層的機器監(jiān)控到直面用戶的應(yīng)用，都離不開時序性的業(yè)務(wù)場景，而時序性的數(shù)據(jù)一般都由專業(yè)的時序數(shù)據(jù)庫來存儲分析，下面主要介紹TSDB覆蓋的業(yè)務(wù)場景以及面臨的挑戰(zhàn)。

1. 時序數(shù)據(jù)庫覆蓋場景

• 基礎(chǔ)設(shè)施層：機柜、物理機、操作系統(tǒng)監(jiān)控日志
• 基礎(chǔ)運維：sunfire(集團統(tǒng)一監(jiān)控、采集、報警系統(tǒng))、阿里云監(jiān)控、GOC(阿里全球應(yīng)急調(diào)度指揮系統(tǒng))
• 資源調(diào)度：集團內(nèi)部調(diào)度系統(tǒng)、Kubernetes
• 集群管理：DBPaas(阿里所有數(shù)據(jù)庫實例的監(jiān)控和調(diào)度)
• 應(yīng)用層：APM場景下的各種應(yīng)用

2. 時序數(shù)據(jù)庫面臨的挑戰(zhàn)

由于面臨各個層級的不用場景，所以時序數(shù)據(jù)庫也面臨不同挑戰(zhàn)：

• 應(yīng)用層挑戰(zhàn)：由于直面客戶所以需要提供高頻率、低延遲的查詢
• olap數(shù)據(jù)庫本身特性：海量數(shù)據(jù)的聚合
• 時序數(shù)據(jù)庫特有的：發(fā)散時間線
• 雙十一大促：突然流量十倍以上增長

—

02

TSDB介紹

1.TSDB的發(fā)展及性能

TSDB于2016年開始服役,到目前為止參與了三次雙十一大促，相比于2017年讀寫吞吐翻倍增長,寫入TPS4000w，查詢2wQPS覆蓋集團130+業(yè)務(wù)線及存儲百億的時間線。

2.TSDB架構(gòu)介紹

如上圖，從左到右為數(shù)據(jù)的采集到展現(xiàn)的過程：

邊緣計算：輕量可靠的計算方案，主要負責數(shù)據(jù)的采集，與云端的TSDB打通，在OLAP場景或者資源不穩(wěn)定的場景下實現(xiàn)數(shù)據(jù)的穩(wěn)定采集、清洗等。

時序引擎：

時序索引：時間線的查詢；

儲存引擎：時序數(shù)據(jù)、海量數(shù)據(jù)存儲的解決方案；

流式數(shù)據(jù)聚合：在時序數(shù)據(jù)庫的海量數(shù)據(jù)里做高效的的聚合分析；

穩(wěn)定性管理：在云上穩(wěn)定安全的運行；

計算引擎、sql引擎、智能引擎：主要與時序引擎交互實現(xiàn)數(shù)據(jù)計算、sql解析、模型算法等功能，可以擴展時序引擎的能力，降低使用的門檻；

協(xié)議支持：主要面向用戶，為用戶提供一些可視化的查詢和分析支持。

—

03

核心技術(shù)

1.海量時序數(shù)據(jù)存儲

（1）數(shù)據(jù)壓縮

說起存儲就離不開壓縮,數(shù)據(jù)的壓縮方法和壓縮算法的選擇很大程度上支持了海量數(shù)據(jù)的儲存。

如上圖代表時間窗口為一小時的數(shù)據(jù)，0-3600代表過去一個小時內(nèi)的數(shù)據(jù)，采用key-value存儲格式,以秒值作為key，每秒的數(shù)據(jù)作為value存儲。

這里參考facebook grada思想引入了時序壓縮算法，通過列合并的方式把所有的時間戳和對應(yīng)的value聚合長兩個的大數(shù)據(jù)塊，然后對這個兩個大塊進行時序壓縮算法，然后再用通用的塊壓縮算法進行壓縮。

另外不同的數(shù)據(jù)類型采用不同的數(shù)據(jù)壓縮格式，如：

• 時間戳：delta- delta
• 浮點型：XOR編碼
• 整型：variable length encoding
• 字符串：LZ4，實現(xiàn)了存儲層亂序數(shù)據(jù)壓縮，保證壓縮數(shù)據(jù)的準確性,整理的壓縮率在15:1。

（2）數(shù)據(jù)壓縮效果

為什么要采用時序壓縮+塊壓縮，我們可以看一下這個圖。

首先時序壓縮針對不同類型的數(shù)據(jù)采用了不同的壓縮格式，所以整體的效果優(yōu)于塊壓縮算法，而在時序壓縮算法對數(shù)據(jù)壓縮后在采用通用的塊壓縮，不會影響到塊壓縮的壓縮效率，用時序壓縮+塊壓縮相比單獨的塊壓縮能有40%的壓縮率提升，這為海量數(shù)據(jù)的存儲提供了有力的幫助。

2.高頻、低延遲查詢

淘寶魔兔是阿里一款應(yīng)用無線端數(shù)據(jù)分析和監(jiān)控的產(chǎn)品，支持集團內(nèi)部500+的應(yīng)用，在雙十一大促是查詢峰值可達4000QPS，相較于平常查詢量有10倍的提升，,99%讀寫rt都要求在20ms以內(nèi)，那么TSDB是如何實現(xiàn)用戶端高頻、低延遲的查詢呢?

（1）分布式緩存存儲適配

參考Facebook Gorilla論文，基于java做了一套分布式的內(nèi)存緩存存儲，基于zookeeper實現(xiàn)分片及容量的調(diào)整，可以實現(xiàn)動態(tài)的擴容和縮容，在整個雙11過程中支持1000wTPS的寫入和4000的QPS的查詢。

（2）TsMem設(shè)計

如圖所示，TsMem基于Disruptor做一個RingBuffer，把用戶讀寫的請求都暫存在RingBuffer中，采用多個生產(chǎn)者和一個消費者模式，一個消費者的請求會打到多個worker線程中，每一個worker線程又是一個分片，所以其實就是基于RingBuffer做了一個內(nèi)存的分片，這樣一來就是一個線程對應(yīng)一個分片，這樣就不會產(chǎn)生共享資源,也就無需考慮鎖的實現(xiàn)。

把寫和讀都分配到一個鏈路上，一個worker同時處理讀和寫，提高讀寫性能

同時還利用了RingBuffer的batching特性，將用戶的讀寫請求都暫存在一個butching中，然后當達到一定閾值或時間worker將直接提交一個batching，這樣雖然會是請求有一定的延遲，但是大大提高了worker的吞吐量。

那么如何保證高效的內(nèi)存管理和極低毛刺的延遲呢？

對于數(shù)據(jù)塊基于引用計數(shù)的chunk池化管理，把所有的時序數(shù)據(jù)塊在內(nèi)存中做了池化，這樣就能減少讀取數(shù)據(jù)時臨時對象的創(chuàng)建，而且還能避免大塊時產(chǎn)生的抖動和延遲。

3.高緯聚合分析

（1）TSDB引擎核心模塊

TSDB和核心模塊主要包含兩部分，分別是時序索引和流式聚合引擎，當用戶的一個查詢請求過來時將會由時序查詢引擎返回對應(yīng)的時序索引構(gòu)建Pipeline時間線集合，然后再由流式聚合引擎計算出相應(yīng)的聚合結(jié)果。

（2）時序索引

時序索引是什么？

本質(zhì)是一個帶時間戳的倒排索引，對數(shù)據(jù)進行倒排索引，然后在加上時間戳，這樣當用戶的請求過來時就可以根據(jù)用戶的篩選條件獲取數(shù)據(jù)的位置，然后再用時間線和時間戳進行二次過濾，這樣提高了索引的命中率，同時也支持對時間線的TTL。

如何存儲？

時序索引是基于kv進行存儲，是一個無狀態(tài)的節(jié)點，可以支持水平擴展。

（3）時序索引優(yōu)化器

時序索引優(yōu)化器主要是為了幫助用戶在查詢倒排索引的時候提高效率，這里優(yōu)化器會對于用戶的請求有三個處理：

• HLL計數(shù)器：根據(jù)用戶的查詢規(guī)則匹配歷史的時間線數(shù)量,或者某個tag下的時間線數(shù)量；
• BloomFilter：根據(jù)布隆過濾器判斷某個時間線是否存在；
• 時序索引緩存：直接查詢緩存中是否已有相同的時間線內(nèi)容。

優(yōu)化器對于用戶查詢?nèi)绾卧u估優(yōu)化？

首先會根據(jù)用戶的查詢條件選取最小的集合進行計算，然后會判斷查詢的時間線是否存在，如果不存在直接返回，一些明確限定的條件優(yōu)先于模糊的條件，例如等于肯定優(yōu)先于包含。

（4）流式聚合引擎

流式聚合引擎采用輕量單進程實現(xiàn)，在用戶查詢的時候?qū)⒂脩舻膹?fù)雜查詢轉(zhuǎn)換為聚合算子組合，流式聚合引擎包含了10+核心的聚合算子、20+填充策略、10+插值算法。

由于是將復(fù)雜的查詢轉(zhuǎn)換為算子組合運算，所以在實現(xiàn)上是一個松耦合的結(jié)構(gòu)，擴展性很強而且每個算子的執(zhí)行都非常高效,快速，減少了對內(nèi)存的開銷以及底層存儲的壓力，另外聚合出和數(shù)據(jù)還可以與外部預(yù)聚合、降精度聚合的數(shù)據(jù)實現(xiàn)無縫銜接，提高了查詢結(jié)果的復(fù)用率。

4.穩(wěn)定性保障

（1）TSBD穩(wěn)定保障機制

TSDB不僅服務(wù)于專有云，更服務(wù)于公有云上的客戶，因此穩(wěn)定性是一個可以和內(nèi)核提到同等層次的問題，TSDB從三個方面實現(xiàn)了穩(wěn)定性的保障。

• 資源隔離

讀寫線程分離：保障了查詢有故障時不會影響寫入，寫入有故障時不會影響查詢；

慢查詢、大查詢的隔離：根據(jù)用戶的查詢條件生成一個指紋，在根據(jù)歷史記錄判斷這個指紋是不是一個慢查詢或者大查詢,如果是的話會將這個查詢放到一個單獨的隊列，這個隊列的資源是受限的，而正常的查詢會進入到正常的隊列，這樣一定程度上加速了整體查詢的速度；

查詢狀態(tài)管理和調(diào)度：查詢?nèi)蝿?wù)的狀態(tài)管理和監(jiān)控與任務(wù)的調(diào)度分離，這樣降低了任務(wù)管理和調(diào)度的耦合性，提高了任務(wù)運行的穩(wěn)定性。

• 基于時間線、時序數(shù)據(jù)的細粒度流控

每一份數(shù)據(jù)都通過倒排索引+時間戳的索引方式定位，保證用戶的查詢條件能更粒度的命中數(shù)據(jù)，減少不必須的資源消耗。

• 全面的監(jiān)控指標

TSDB對整體的吞吐量、查詢響應(yīng)時間、IO層關(guān)鍵指標、以及各個核心模塊都有詳細而全面的監(jiān)控,保證能實時的了解到TSDB內(nèi)部發(fā)生了什么問題，繼而快速的定位解決問題。

（2）TSDB工作負載管理

端到端的流控：在用戶的寫入接口會做資源的IO控制，兩個核心模塊時序索引、聚合引擎的入口層也會做一個IO流控，保證黨用戶的寫入量或多或者查詢量過大時，兩個核心模塊不收影響；

多維度的控制：從不同維度對TSDB的讀寫進行一些限制，例如查詢的時間線過長、訪問的數(shù)據(jù)點過多，讀取的字節(jié)數(shù)過大、整個查詢消耗的時間過長等等。

—

04

總結(jié)展望

前面已經(jīng)介紹了TSDB的發(fā)展歷程和解決的問題，下面將要介紹TSDB未來的發(fā)展方向及特性：

1. 冷熱數(shù)據(jù)異構(gòu)存儲

隨著時間的推移數(shù)據(jù)量會越來越龐大，為了降低用戶成本一些不必要或者低熱度的數(shù)據(jù)不需要按照現(xiàn)有的數(shù)據(jù)存儲方式來保存，可以換成一種更低成本的存儲方式。

2. 提高Serverless讀寫能力

• 提供能高頻率、低延遲的查詢
• OLAP系統(tǒng)長時間高緯度的分析
• 對于歷史數(shù)據(jù)分析或者冷數(shù)據(jù)的分析
• 降低計算和查詢的成本

3. 擁抱時序生態(tài)

將已有的時序引擎和計算引擎與業(yè)界很多成熟的時序生態(tài)，比如prometheus、kubernetes、openTSDB等結(jié)合，為用戶體用更好的解決方案。

4. 時序智能分析

為用戶提供更多穩(wěn)定、可靠的智能分析模型，深入行業(yè)內(nèi)部了解一些用戶的痛點，解決一些亟待解決的問題。