特定 worker 數量 ner 流計算 可控 數據挖掘 記錄 軌跡

概述
最近，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]
   四、 時空數據庫
5. 需求
   隨著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打造成業內領先的“智聯網數據庫”！

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