零距離接觸阿里雲時序時空數據庫TSDB

時間 2019-12-04

原文原文鏈接

概述

最近，Amazon新推出了徹底託管的時間序列數據庫Timestream，可見，各大廠商對將來時間序列數據庫的重視與日俱增。
阿里雲TSDB是阿里巴巴集團數據庫事業部研發的一款高性能分佈式時序時空數據庫，在即將過去的2018年，咱們對TSDB進行了屢次的系統架構改進，引入了倒排索引、無限時間線支持、時序數據高壓縮比算法、內存緩存、數據預處理、分佈式並行聚合、GPU加速等多項核心技術，而且引入了新的計算引擎層和分佈式SQL層，使得引擎核心能力有了質的提高，也基本上統一了集團內部的監控存儲業務。2018年雙11當天，TSDB穩定運行，0故障，支撐雙十一核心業務系統，毫秒級採集能力，具有雙十一峯值寫入不降級，創造了集羣TPS 4000萬、QPS 2萬的新紀錄。同時，面向IOT賽道，推出了時空數據庫和邊緣計算版本，還會引入面向時序時空場景的智能引擎，將來咱們的目標是把TSDB打形成一款業內領先的「智聯網數據庫」。node

2018雙十一數據

首先，咱們來看一下TSDB在2018年雙十一的答卷：TSDB承受了4000萬/秒的峯值寫入，2萬/秒的峯值查詢，與2017年雙十一相比均翻倍增加；而寫入均值也達到了2600萬/秒，查詢均值達到了8000次/秒。算法

場景

下面幾頁Slide是咱們在外部的一些場景和客戶案例：docker

核心技術解析

爲了更好的支持業務的需求，今年咱們在覈心引擎層面作了很是多的優化和改進，咱們還引入了新的計算引擎層，分佈式SQL引擎，時空引擎以及面向IoT市場的邊緣計算版本，極大的提升了TSDB的計算能力和場景。下圖就是TSDB的主要架構圖，接下來的篇章我會分時序引擎，計算引擎，SQL引擎，時空引擎，邊緣計算這5大部分來詳細的介紹咱們的核心技術能力。數據庫

1、時序引擎

問題挑戰

穩定性、流量翻倍、不降級、低延遲、無限時間線後端

1. 複雜時間線索引、無限制時間線支持:

問題

爲了支持多維查詢和聚合查詢，TSDB使用了倒排索引以快速定位到某條時間線。在TSDB現有的實現裏，倒排索引是所有存放在內存中的。該方案的好處是根據某個Tag或者Metric查找時間線時會很是高效，可是缺點也很是明顯：受限於內存大小，TSDB沒法支持大規模的時間線。隨着TSDB的客戶愈來愈多，這個問題也愈來愈突出：某直播業務要求TSDB可以支撐20億時間線的規模；某監控業務雖然初始時間線只有上千萬，可是天天會新增幾十萬條時間線，並且時間線規模沒有上限。緩存

方案

TSDB在以前全內存倒排索引的基礎上，將倒排索引持久化到硬盤，賦予了TSDB支撐無限時間線的能力。同時，經過給予倒排索引時間的概念，咱們將查詢的時間過濾算子下推到了索引查詢階段，進一步優化了查詢性能。而經過建立時間線索引的BloomFilter，TSDB保證了海量時間線規模下的低延遲索引查詢。安全

效果

拿集團內業務舉例，原來64G內存的機器只能支持到不到500萬的時間線，採用了上面的技術方案後，64G內存的機器就能夠支持業務將近7000萬以上的時間線，並且時間線數量在原有機器的基礎上還能夠繼續增長。架構

2. 高效列式內存緩存、時間線內存分片：

爲了加速數據的寫入和查詢能力，今年咱們爲TSDB設計了全內存的分佈式高效緩存，具體架構圖以下：併發

效果

最終咱們測試效果是：在單個docker下，單機TPS從原來的50W提高到100W+，QPS從原來的1K提高到2K+ ；而且這個改進很好的支持了集團魔兔業務的需求和發展。app

3. 工做負載管理：

爲了更好的解決數據量大的狀況下的負載均衡的問題，咱們作了許多工做，主要包括：

經過讀寫分離機制進一步提高寫入和查詢性能；

快慢查詢自動分級，讓慢查詢再也不拖累其餘查詢；

自動限流保護，無需業務方降級，無懼雙十一洪峯。

效果

雙十一結果證實，新的負載管理策略幫助業務方很是平滑的度過了流量洪峯。

4. 時序全新存儲引擎——Lindorm：

這裏須要提到的另一點是，TSDB時序最新架構採用了Lindorm做爲存儲引擎，可以以更少的機器成本提供更高的吞吐、更低的延遲。下圖爲採用Lindorm存儲引擎先後的TSDB寫入延遲。

5. 聚合器

豐富的流式聚合算子:15+聚合，10+填充策略，支撐大量的adhoc操做：groupby, in，not_literal_or, topN, limit等等;支持不規則時間序列數據的處理，TSDB提供的填值策略，能夠很輕鬆地將不規則的時間序列轉換爲常規時間序列進行處理;支持top-bottom等聚合方式。

6. 混合存儲記錄塊

時序數據存儲的記錄塊方式是其查詢性能的基石。TSDB既支持基於時間線的存儲方式，
同時支持基於窗口的數據記錄切分，複用同一套流式聚合，知足不一樣業務場景性能需求。

7. 服務化

TSDB服務目前已經在阿里雲上出售，目前提供小規格版本以及標準規格版本，知足了不少用戶的需求，但依然有一些用戶但願提供更小規格的TSDB服務。爲了更好知足用戶的需求，TSDB提供服務化功能。服務化功能是經過多個用戶共享一個TSDB集羣的方式來提供更小規格的TSDB服務

數據安全：HTTPS支持，用戶認證
併發管理：寫入併發管理，查詢併發管理
性能管理：寫入性能管理，查詢性能管理
使用量管理：數據點管理，時間線管理

時序引擎接下來會繼續突破核心技術，包括：自驅動索引TPI，多值數據模型，時序算法，內存計算等等。從功能，性能，成本，生態方面進一步發力，打通K8S指標存儲體系，具有兼容Prometheus的能力。

2、時序計算引擎TSCE

業務接入量快速突破的過程當中, 也帶來了數據存儲量級與查詢複雜度的快速增加, 單TSDB實例在存儲與計算方面的技術挑戰也面臨跳躍式提高. 爲了不查詢性能逐漸偏離用戶設定的目標, TSDB的架構演進過程也引入相關的創新機制, 並最終延伸出時序產品體系中的新成員 - 時序計算引擎(TimeSeries Computing Engine, TSCE).

時序計算引擎(TSCE) 定位爲對TSDB中原生數據進行流式計算的獨立組件, 在時序產品體系中與時序數據庫(TSDB)緊密結合, 提供諸如時序數據降採樣(DownSample), 時間維度預聚合, 時間線降維歸檔等涵蓋時序數據查詢與存儲相關的核心計算能力.

同時, 針對應用特定的應用型時序計算場景, 時序計算引擎(TSCE) 亦支持自定義計算規則與函數, 知足各種應用自身的特定業務需求. 常見的應用型時序計算場類型: 時序事件告警, 事件模式匹配, 時序異常分析與檢測等.

TSCE的產品形態以下:

時序計算引擎(TSCE)做爲獨立組件進行部署, 用戶須要在TSDB實例的基礎上根據成本與應用需求選擇是否開啓TSCE時序計算處理. 在這種產品形態下, 用戶能夠獨立調整TSDB的存儲規格和 TSCE的計算容量, 作到根據應用特色彈性調整各自組件的實例規模. 在知足應用要求的狀況下將TSDB/TSCE實例部署成本控制在合理區間.

TSDB與TSCE結合以後, TSDB引擎會在數據入庫過程當中同時讓TSCE引擎感知數據流動, TSCE會基於配置的時序計算能力或業務規則對數據流進行計算與分析, 計算後的結果支持三種反饋形式: 1.直接反饋至TSDB存儲層,供TSDB查詢. 2.做爲視圖以API或者SQL方式訪問. 3.經過Reactive機制投遞給其餘事件處理渠道.

時序計算引擎TSCE 支持經過 TS-API 或者 Web控制檯進行時序計算能力/自定義規則的配置.

（1）時序計算

TSDB與TSCE協做工做時, 針對核心的時序計算能力, TSCE會與TSDB的進行無縫集成. 此時核心的時序計算處理對於TSDB終端用戶而言是透明,無感知的執行過程. 用戶開啓並配置TSCE處理後, 原來的數據查詢方式與查詢格式不變, 整個計算的處理徹底在後臺自動執行.

在查詢層面上, 經過TSCE提供的時序計算處理, TSDB會在儘量的狀況下將查詢通過TSCE處理的計算結果.即便是在海量數據場景下, 也能提供時序數據的秒級分析查詢與時間維度鑽取查詢.

而在數據存儲層面上, 隨着時間線的流逝, TSCE會對原生歷史數據進行降維計算, 將細粒度的時間點逐步轉化爲粗粒度的時間點歸檔存儲(例如秒級數據點轉化爲分鐘級數據點), 進一步控制TSDB中存儲空間與資源的使用量, 使得TSDB的穩定性與性能波動處於可控範圍. 經過TSDB與TSCE結合, TSDB中管理的數據體量能夠控制在合理水平, 提高資源佔用率的同時進一步節省產品使用成本.

數據流預聚合
諸如max/min/avg/count/sum等常見的可累加式狀態值, TSCE能夠在數據流動過程當中即完成相關數據的統計與計算.

時間線計算

針對時間線(TimeSeries)的窗口粒度,數值分佈等特徵關係, 對時間線進行特徵值轉換的計算過程. 例如降採樣(Dowmsampling)運算能夠將秒級時間線轉化爲分鐘級時間線, 通過轉化後的時間線能夠在查詢流程上支持時間維度上下鑽的即席查詢; 而在存儲流程上, 能夠支持時間線歸檔存儲, 將原始細粒度時間線轉化爲粗粒度時間線後,清除原始的數據點,釋放相關資源.

（2）時序流處理

針對應用特定的應用型時序計算場景, TSCE經過引入自定義計算規則與函數, 來知足各種應用自身的特定業務計算需求. 用戶在通過簡單的規則配置後, TSCE引擎會負責底層的數據流打通, 流計算拓撲映射, 分佈式節點間的Shuffle與結果歸併, 計算後結果集的存儲與投遞等一系列動做細節.

與General-purpose的流計算處理相比, TSCE的時序流處理除了實現下降技術門檻以外,作到底層流計算能力的彈性擴展以外, 也提供幾個核心能力:

時序數據庫的緊密集成: 由於TSCE與TSDB部署在相同的內部環境內,TSCE能夠在很是低的成本下作到與TSDB作數據交換,而且能夠直接訪問到TSDB後端的數據存儲層. 與常規應用方案中須要先通過流處理再寫入時序存儲產品的架構相比, 引擎間的緊密集成能夠作到效率,成本,性能的成倍提高.
Reactive查詢視圖: 流處理後的結果集除了寫回TSDB中存儲以外, TSCE也支持將數據流轉儲爲Reactive查詢視圖. Reactive查詢視圖除了能夠支持以SQL/API方式查詢結果以外, 也能夠經過指定Subscriber訂閱相關數據流更新, 當結果集在視圖中產生變更時, TSCE會投遞數據變動事件至相關Subscriber指定的渠道中(適合監控告警以及自動化處理等業務).

時序流處理規則

定義一個流處理規則包含了3個元素: 1.數據源(TSDB中的時間線), 2.自定義計算規則, 3.計算結果的輸出源；其中數據源來自於TSDB數據庫, 業務方能夠經過規則匹配1條或多條時間線做爲數據輸入源. 而計算結果的輸出源能夠是寫會TSDB, 或者轉儲爲Reactive視圖.

此外用戶也能夠經過lambda自定義與業務邏輯處理相關的函數, 加入到總體的規則處理鏈中.

（3）時序分析與智能引擎

除了配置TSCE的時序計算能力與自定義時序流處理以外, TSCE也提供一些常見的時序分析與智能處理能力:

時序分析

簡單的時序流復瑣事件處理(CEP): 提供時間線上數據點之間的關係偵測,模式匹配等.

智能引擎

TSCE支持與時序智能引擎進行聯通,讓用戶具有針對時序數據流進行時序異常探測,故障root-cause分析,流式模型訓練等相關高級能力. 技術實現上TSCE以Function,DSL等形式進行智能引擎的規則定義與轉換, TSCE在數據流的計算過程當中會基於內存間數據共享/RPC等方式完成與智能引擎的聯動與交互

4. 應用場景

雙十一期間, TSCE時序計算引擎支撐的幾個典型業務場景:

海量數據下的時間線降維度,預聚合查詢
基於閾值的簡單事件告警
時序數據的降維歸檔存儲
驗證初期的時序分析能力(與智能引擎結合)

3、分佈式MPP SQL引擎：

1. 需求

今年咱們決定在TSDB上設計開發一個分佈式的SQL查詢引擎，爲何要這麼作呢？主要有如下幾個緣由：

從簡單時序監控到複雜時序分析
TSDB引擎所支持的查詢主要是簡單的降採樣和分組聚合，隨着愈來愈多業務把時序數據存儲到TSDB，咱們須要提供一個基於SQL的分佈式查詢引擎，支持更復雜的時序計算(聚合，時序Join, SQL Window function， UDF), 從而推廣TSDB到更普遍的業務中。
擴展時序數據庫的生態系統
生態系統是一個產品是否成功的關鍵因素。經過時序SQL查詢引擎，TSDB數據庫能夠和現有的BI tool實現無縫對接。在集團內部，咱們正在和阿里雲的QuickBI和IDB等團隊合做，把TSDB演進成一個支撐重要BI數據分析的數據庫產品。將來，經過時序SQL查詢引擎，能夠對接市場上常見的BI tool, 好比Tableau, Qlik, Power BI等衆多工具。
支持多種異構數據源的聯合分析
一般，業務把時序相關的數據存儲在TSDB，非時序數據存儲在其餘系統中，好比維度信息存儲在MySQL等。業務須要在多種數據中進行Join。時序SQL查詢引擎支持業務在多種數據源之間直接進行查詢分析，避免業務方複製異構數據源再進行聯合分析。
對標業界主要競爭產品
時序數據庫在國外最主要的競爭產品包括TimeScaleDB, InfluxDB， KDB+，Prometheus。TimeScaleDB做爲Postgres的一個擴展，提供了標準SQL的支持，而InfluxDB/KDB+提供了相似於SQL (SQL-like)的查詢支持。咱們TSDB系統經過時序SQL查詢引擎，更好地對標國外主要時序競爭產品。

2. SQL引擎的挑戰

除了海量時序數據帶來的挑戰外，時序SQL查詢引擎還面臨和時序場景相關的挑戰：

數據table Schema的管理
- 時序metric數目海量：Sunfire等集團內部業務有上億規模的時間線，而盒馬業務中將tag編碼進metric, 時間線數目巨大，這和通常數據庫中數千或數萬的table是巨大的區別;
- 時序metric schema動態變化：業務方隨着應用的變化，常常須要增長或減小一個tag。這意味着metric所對應的schema也在不斷變化之中。海量時間線+動態變化對查詢引擎獲取metric的schema 是一個挑戰。
數據schema-on-write對查詢引擎的影響

大多數的數據庫在用戶寫入數據或查詢以前，必須先經過DDL建立table schema，這些table schema等元數據又被存放在一個catalog或meta data store, 供數據寫入或查詢時使用。而時序數據庫的業務中，大部分的數據源來自於監控設備的一個agent, 或者IOT物聯網的一個sensor, 要求先定義DDL再寫入數據會嚴重影響可用性; 同時，時序metric所對應的tag集合在應用演進過程當中，變化很常見。針對這一的應用特色，時序數據庫TSDB，InfluxDB， Prometheus都採用了一種'Schema-on-write'的機制，應用直接寫入數據，table schema是隱含在數據中。在'Schema-on-write'的機制下，須要解決沒有DDL的狀況下SQL查詢引擎如何從海量時間線中獲取table schema等元數據的問題。

時序功能擴展

在現有以關係運算爲基礎的SQL查詢引擎中。爲支持時序功能擴展，咱們須要一個易於擴展功能的架構，能支持開發時序相關的功能，好比時序Join, 時序相關的用戶自定義函數(UDF)。

時序查詢優化

一個SQL查詢引擎，優化器是性能優劣的關鍵。須要在通用的SQL查詢引擎中，引入時序數據統計信息，做爲輸入提供給優化器；同時，在優化器中，引入時序相關的優化Rule, 好比FilterPushDown/ProjectPushDown規則，這些都是時序SQL查詢引擎須要解決的問題。

3. SQL引擎

SQL查詢引擎是一個分佈式的系統，其特色：

每一個計算節點在系統中是對等的，並無主從關係，
任何一個節點均可以成爲Foreman, 負責SQL查詢計劃的生成，而其餘節點成爲worker nodes
無狀態，一個節點失效後，能夠快速啓動備用節點。

4. 應用場景

盒馬零售業績時序數據查詢: 業務方須要經過SQL查詢TSDB的時序數據，接入業務方的分析圖表大屏。此外，業務方須要支持簡單的SQL簡單查詢外，還包括異構多種數據源的join的支持。![image]
雲監控：經過提升SQL查詢支持，業務方能統一數據訪問方式![image]

4、時空數據庫

1. 需求

隨着TSDB的業務發展，時序數據庫TSDB漸漸走出APM與監控領域，在IoT領域也得到普遍應用。而因爲IoT領域的特性，其中採集到的不少數據不光有時間信息，還有空間信息與之關聯。所以時序數據庫也須要可以識別和處理空間信息，以便於更好地服務IoT場景。

對於傳統的時間序列數據庫，好比說OpenTSDB，若是用戶想要存儲和查詢地理座標信息，每每須要將經度和緯度分開存儲，生成獨立的時間線。可是使用時想要將二者從新關聯起來須要用戶作額外處理。另一種方式則是須要用戶本身將地理位置信息進行編碼，常見有的GeoHash或者Google S2。而後將編碼信息做爲時間線信息進行存儲。即便這樣，用戶依舊須要開發時空過濾功能等等。

2. 方案

在IoT場景中，對於地理座標信息的採集十分廣泛。所以在時序數據庫的基礎上，咱們添加了對空間信息的存儲和處理能力，使之成爲時序時空數據庫。TSDB的時空引擎讓地理位置信息和時序信息完美結合起來，力爭解決着一切關於時序和時空相關的查詢分析。

3. 時空處理能力

最新版本的阿里雲TSDB支持地理座標位置信息的直接寫入。用戶只須要經過新版本的SDK以及Http Restful APIs能夠將地理空間信息（地理經緯度）寫入，而且能夠對經緯度信息進行讀取。下面兩個經過Http Restful API接口TSDB多值寫入和單純的軌跡查詢示例：（注意：Coordinate是一個關鍵字，表示地理座標點寫入，不可用於其餘監控指標名稱(metric)。）

說完TSDB對於地理座標信息最基本的存儲和查詢功能，咱們來看一下TSDB所提供的經常使用時空分析功能。

對於寫入的地理座標數據點，TSDB將自動生成時空索引提升查詢和分析效率。TSDB的時空索引基於傳統空間索引（Google S2和GeoHash都是支持）結合時序數據特徵建立的時空索引格式。同時爲了提升，用戶能夠根據本身需求在開始使用時空功能以前提早配置時空索引按照時間分片。偏實時的業務，能夠將按照小時或者半小時對時空索引進行分片。對於偏分析的場景，能夠按照天進行分片。

時空索引爲TSDB提供時空過濾分析功能提供了便捷和提升效率，如今最新版本的TSDB支持一些經常使用的時空過濾功能，好比BBOX查詢和DISTANCE_WITHIN查詢。

目前TSDB時空功能已經在雲上推出了公測版本，你們在官網就能夠看到咱們時空功能。

4. 下一代時空數據庫核心技術全力研發中

針對萬億級，EB級別的時空數據，全團隊在全力研發下一代時空數據庫，包括新型分佈式列式存儲引擎，GPU加速，智能壓縮，冷熱分離，高效時空索引，分佈式時空計算等等；

5、邊緣計算

今年，爲了進一步支持外部IoT市場的需求，咱們在TSDB雲版的基礎上，開發了邊緣計算版本（在廣州雲棲大會工業物聯網專場，正式發佈阿里雲工業物聯網邊緣計算平臺存儲類產品 TSDB Edge，TSDB Edge 主要提供物聯網邊緣端設備相關數據的本地存儲，本地分析，數據清洗和雲端數據同步能力。）；

1. 兩節點HA

兩節點HA經過兩個TSDB節點實現HA。兩個TSDB節點沒有主從的區別，兩者均可以接受讀寫請求，也均可以響應讀寫服務（不須要轉發讀寫請求）。兩個TSDB節點可以同時接受寫請求，兩個TSDB經過同步WAL日誌的方式實現數據同步，保障數據的最終一致性。同時，兩節點HA經過WAL與雲端同步數據。
兩節點HA提供了在邊緣設備端TSDB的高可用性，當一個節點發生宕機，另一個節點可以繼續提供服務，宕機節點恢復之後，經過數據同步功能，數據可以在兩個節點上迅速實現同步，不會引發非硬盤故障下的數據丟失。

2. WAL日誌管理器

實現本地的WAL日誌管理，經過WAL日誌保證寫入的數據不丟失。同時WAL日誌管理器，自動判斷並刪除過時日誌文件，減小硬盤空間佔用，減輕運維工做。

3. 內存管理器

管理大對象的內存使用狀況，經過監控實時內存使用狀況，自動判斷是否將內存中的數據寫入文件系統以減小內存使用。內存管理器根據內存使用狀況，自動設置保留的chunks數量，能夠減小/杜絕OutOfMemoryError錯誤的發生。

4. HAServer/HAClient數據同步器

HAClient經過自有的協議，採用PUSH的方式傳輸WAL。HAServer收到WAL之後，直接經過WAL replay數據插入操做，從而實現數據同步。HAServer/HAClient經過保存讀取偏移量的方式，實現斷點續傳。
CloudSynchronizer雲同步器
經過讀取WAL，並調用TSDB雲版客戶端實現向雲端同步數據的功能。該同步器對雲端透明，同時實現了斷點續傳。

5. 新型壓縮算法

邊緣計算提出自研的新型壓縮算法，該壓縮算法，採用流式壓縮方式，支持數據經過append的方式加入，同時在內部採用整字節的方式進行編碼，提升壓縮/解壓性能。

經測試，該新型壓縮算法的壓縮率爲3-40倍。與Facebook Gorilla算法相比，該算法壓縮率提升約20%-50%，壓縮性能提升3-5倍，解壓性能提升4-6倍。

6. GPU硬件加速

邊緣計算還在探索與GPU等新型硬件集成。TSDB邊緣版使用GPU進行解壓，降採樣以及聚合操做；

經過測試，使用GPU之後，查詢性能能夠達到原來的50倍。

6、智能引擎

背景

TSDB 提供了強大的數據存儲、處理和查詢能力。在這個堅實的基礎之上，愈來愈多的業務場景須要經過挖掘海量數據驅動業務價值的提高，TSDB 智能引擎就是在這個大趨勢之下應運而生的。

能力

TSDB智能引擎專一於時序時空數據的分析、檢測、挖掘、預測能力，着力打造從數據到知識再到商業價值的高效引擎，爭取達到價值鏈與數據能力的兩個全覆蓋。
市場上現有的商業智能與數據科學工具每每只利用數據庫的存儲查詢功能，進行數據挖掘和分析以前須要從數據庫中提數，以後的流程也脫離數據庫環境進行。TSDB 智能引擎從架構上與數據庫存儲查詢引擎進行深度整合，高效的利用數據庫現有關係代數能力，並適當引入線性代數計算能力，天然的造成數據閉環，提供一站式的數據科學能力。相信隨着不斷地努力打造與突破，智能引擎也會逐步沉澱行業數據模型與智能定製算法，並最終造成端到端的行業智能分析解決方案。

限於篇幅，這裏就不詳細描述了。