概述

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

2018雙十一資料

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

場景

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

核心技術解析

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

一、時序引擎

問題挑戰

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

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+ ；並且這個改進很好的支援了集團魔兔業務的需求和發展。

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的能力。

二、 時序計算引擎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時序計算引擎支撐的幾個典型業務場景:

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

三、分散式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]

四、 時空資料庫

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加速，智慧壓縮，冷熱分離，高效時空索引，分散式時空計算等等；

五、邊緣計算

今年，為了進一步支援外部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倍。

六、智慧引擎

背景

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

能力

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

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

八、其他

時序洞察

時序標準

我們在今年8月份也是參與國家的時間序列標準的制定，並且在與其他廠商的競爭中取得優異的成績。

結束語

2018年，是阿里雲TSDB產品成長最快的一年；上文中提到的需要技術和能力目前只是應用在阿里巴巴集團內部的場景；未來，我們會逐步把這些能力開發給外部使用者，讓外部客戶也能享受到阿里巴巴強大的技術實力帶來的價值。
最終，我們的目標是把TSDB打造成業內領先的“智聯網資料庫”！