本次分享主要介紹以下四方面：
- 時序業務全景
- TSDB介紹
- 核心技術
- 總結展望
時序業務全景
從底層的機器監控到直面用戶的應用，都離不開時序性的業務場景，而時序性的數據一般都由專業的時序數據庫來存儲分析，下面主要介紹TSDB覆蓋的業務場景以及面臨的挑戰。
1.1 時序數據庫覆蓋場景
基礎設施層：機櫃、物理機、操作系統監控日誌
基礎運維：sunfire(集團統一監控、採集、報警系統)、阿里雲監控、GOC(阿里全球應急調度指揮系統)
資源調度：集團內部調度系統、Kubernetes
集羣管理：DBPaas(阿里所有數據庫實例的監控和調度)
應用層：APM場景下的各種應用
1.2 時序數據庫面臨的挑戰
由於面臨各個層級的不用場景，所以時序數據庫也面臨不同挑戰：
- 應用層挑戰：由於直面客戶所以需要提供高頻率、低延遲的查詢
- olap數據庫本身特性：海量數據的聚合
- 時序數據庫特有的：發散時間線
- 雙十一大促：突然流量十倍以上增長
TSDB介紹
2.1 TSDB的發展及性能
TSDB於2016年開始服役,到目前爲止參與了三次雙十一大促，相比於2017年讀寫吞吐翻倍增長,寫入TPS4000w，查詢2wQPS覆蓋集團130+業務線及存儲百億的時間線。
2.2 TSDB架構介紹
如上圖，從左到右爲數據的採集到展現的過程：
邊緣計算：輕量可靠的計算方案，主要負責數據的採集，與雲端的TSDB打通，在OLAP場景或者資源不穩定的場景下實現數據的穩定採集、清洗等。
時序引擎：
時序索引：時間線的查詢；
儲存引擎：時序數據、海量數據存儲的解決方案；
流式數據聚合：在時序數據庫的海量數據裏做高效的的聚合分析；
穩定性管理：在雲上穩定安全的運行；
計算引擎、sql引擎、智能引擎：主要與時序引擎交互實現數據計算、sql解析、模型算法等功能，可以擴展時序引擎的能力，降低使用的門檻；
協議支持：主要面向用戶，爲用戶提供一些可視化的查詢和分析支持。
核心技術
3.1 海量時序數據存儲
3.1.1 數據壓縮
說起存儲就離不開壓縮,數據的壓縮方法和壓縮算法的選擇很大程度上支持了海量數據的儲存。
如上圖代表時間窗口爲一小時的數據，0-3600代表過去一個小時內的數據，採用key-value存儲格式,以秒值作爲key，每秒的數據作爲value存儲。
這裏參考facebook grada思想引入了時序壓縮算法，通過列合併的方式把所有的時間戳和對應的value聚合長兩個的大數據塊，然後對這個兩個大塊進行時序壓縮算法，然後再用通用的塊壓縮算法進行壓縮。
另外不同的數據類型採用不同的數據壓縮格式，如：
時間戳：delta- delta
浮點型：XOR編碼
整型：variable length encoding
字符串：LZ4，實現了存儲層亂序數據壓縮，保證壓縮數據的準確性,整理的壓縮率在15:1。
3.1.2 數據壓縮效果
爲什麼要採用時序壓縮+塊壓縮，我們可以看一下這個圖。
首先時序壓縮針對不同類型的數據採用了不同的壓縮格式，所以整體的效果優於塊壓縮算法，而在時序壓縮算法對數據壓縮後在採用通用的塊壓縮，不會影響到塊壓縮的壓縮效率，用時序壓縮+塊壓縮相比單獨的塊壓縮能有40%的壓縮率提升，這爲海量數據的存儲提供了有力的幫助。
3.2 高頻、低延遲查詢
淘寶魔兔是阿里一款應用無線端數據分析和監控的產品，支持集團內部500+的應用，在雙十一大促是查詢峯值可達4000QPS，相較於平常查詢量有10倍的提升，,99%讀寫rt都要求在20ms以內，那麼TSDB是如何實現用戶端高頻、低延遲的查詢呢?
3.2.1 分佈式緩存存儲適配
參考Facebook Gorilla論文，基於java做了一套分佈式的內存緩存存儲，基於zookeeper實現分片及容量的調整，可以實現動態的擴容和縮容，在整個雙11過程中支持1000wTPS的寫入和4000的QPS的查詢。
3.2.2 TsMem設計
如圖所示，TsMem基於Disruptor做一個RingBuffer，把用戶讀寫的請求都暫存在RingBuffer中，採用多個生產者和一個消費者模式，一個消費者的請求會打到多個worker線程中，每一個worker線程又是一個分片，所以其實就是基於RingBuffer做了一個內存的分片，這樣一來就是一個線程對應一個分片，這樣就不會產生共享資源,也就無需考慮鎖的實現。
把寫和讀都分配到一個鏈路上，一個worker同時處理讀和寫，提高讀寫性能
同時還利用了RingBuffer的batching特性，將用戶的讀寫請求都暫存在一個butching中，然後當達到一定閾值或時間worker將直接提交一個batching，這樣雖然會是請求有一定的延遲，但是大大提高了worker的吞吐量。
那麼如何保證高效的內存管理和極低毛刺的延遲呢？
對於數據塊基於引用計數的chunk池化管理，把所有的時序數據塊在內存中做了池化，這樣就能減少讀取數據時臨時對象的創建，而且還能避免大塊時產生的抖動和延遲。
3.3 高緯聚合分析
3.3.1 TSDB引擎核心模塊
TSDB和核心模塊主要包含兩部分，分別是時序索引和流式聚合引擎，當用戶的一個查詢請求過來時將會由時序查詢引擎返回對應的時序索引構建Pipeline時間線集合，然後再由流式聚合引擎計算出相應的聚合結果。
3.3.2 時序索引
時序索引是什麼？
本質是一個帶時間戳的倒排索引，對數據進行倒排索引，然後在加上時間戳，這樣當用戶的請求過來時就可以根據用戶的篩選條件獲取數據的位置，然後再用時間線和時間戳進行二次過濾，這樣提高了索引的命中率，同時也支持對時間線的TTL。
如何存儲？
時序索引是基於kv進行存儲，是一個無狀態的節點，可以支持水平擴展。
3.3.3 時序索引優化器
時序索引優化器主要是爲了幫助用戶在查詢倒排索引的時候提高效率，這裏優化器會對於用戶的請求有三個處理：
- HLL計數器：根據用戶的查詢規則匹配歷史的時間線數量,或者某個tag下的時間線數量；
- BloomFilter：根據布隆過濾器判斷某個時間線是否存在；
- 時序索引緩存：直接查詢緩存中是否已有相同的時間線內容。
優化器對於用戶查詢如何評估優化？
首先會根據用戶的查詢條件選取最小的集合進行計算，然後會判斷查詢的時間線是否存在，如果不存在直接返回，一些明確限定的條件優先於模糊的條件，例如等於肯定優先於包含。
3.3.4 流式聚合引擎
流式聚合引擎採用輕量單進程實現，在用戶查詢的時候將用戶的複雜查詢轉換爲聚合算子組合，流式聚合引擎包含了10+核心的聚合算子、20+填充策略、10+插值算法。
由於是將複雜的查詢轉換爲算子組合運算，所以在實現上是一個鬆耦合的結構，擴展性很強而且每個算子的執行都非常高效,快速，減少了對內存的開銷以及底層存儲的壓力，另外聚合出和數據還可以與外部預聚合、降精度聚合的數據實現無縫銜接，提高了查詢結果的複用率。
3.4 穩定性保障
3.4.1 TSBD穩定保障機制
TSDB不僅服務於專有云，更服務於公有云上的客戶，因此穩定性是一個可以和內核提到同等層次的問題，TSDB從三個方面實現了穩定性的保障。
資源隔離
讀寫線程分離：保障了查詢有故障時不會影響寫入，寫入有故障時不會影響查詢；
慢查詢、大查詢的隔離：根據用戶的查詢條件生成一個指紋，在根據歷史記錄判斷這個指紋是不是一個慢查詢或者大查詢,如果是的話會將這個查詢放到一個單獨的隊列，這個隊列的資源是受限的，而正常的查詢會進入到正常的隊列，這樣一定程度上加速了整體查詢的速度；
查詢狀態管理和調度：查詢任務的狀態管理和監控與任務的調度分離，這樣降低了任務管理和調度的耦合性，提高了任務運行的穩定性。
基於時間線、時序數據的細粒度流控
每一份數據都通過倒排索引+時間戳的索引方式定位，保證用戶的查詢條件能更粒度的命中數據，減少不必須的資源消耗。
全面的監控指標
TSDB對整體的吞吐量、查詢響應時間、IO層關鍵指標、以及各個核心模塊都有詳細而全面的監控,保證能實時的瞭解到TSDB內部發生了什麼問題，繼而快速的定位解決問題。
3.4.2 TSDB工作負載管理
端到端的流控：在用戶的寫入接口會做資源的IO控制，兩個核心模塊時序索引、聚合引擎的入口層也會做一個IO流控，保證黨用戶的寫入量或多或者查詢量過大時，兩個核心模塊不收影響；
多維度的控制：從不同維度對TSDB的讀寫進行一些限制，例如查詢的時間線過長、訪問的數據點過多，讀取的字節數過大、整個查詢消耗的時間過長等等。
總結展望
前面已經介紹了TSDB的發展歷程和解決的問題，下面將要介紹TSDB未來的發展方向及特性：
- 冷熱數據異構存儲
隨着時間的推移數據量會越來越龐大，爲了降低用戶成本一些不必要或者低熱度的數據不需要按照現有的數據存儲方式來保存，可以換成一種更低成本的存儲方式。
- 提高Serverless讀寫能力
- 提供能高頻率、低延遲的查詢
- OLAP系統長時間高緯度的分析
- 對於歷史數據分析或者冷數據的分析
- 降低計算和查詢的成本
- 擁抱時序生態
將已有的時序引擎和計算引擎與業界很多成熟的時序生態，比如prometheus、kubernetes、openTSDB等結合，爲用戶體用更好的解決方案。
- 時序智能分析
爲用戶提供更多穩定、可靠的智能分析模型，深入行業內部瞭解一些用戶的痛點，解決一些亟待解決的問題。
作者介紹
張曉光，花名柴武，阿里巴巴高級開發工程師，有多年 APM SaaS 產品研發經驗，曾經使用過多款業界主流時序數據庫產品，包括 Druid、ClickHouse、InfluxDB 等，對時序數據庫領域有多年經驗，目前負責阿里巴巴 TSDB 核心引擎開發。
本文來自張曉光在 DataFun 社區的演講，由 DataFun 編輯整理。