概述

最近，Amazon新推出了完全托管的時間序列數(shù)據(jù)庫Timestream，可見，各大廠商對未來時間序列數(shù)據(jù)庫的重視與日俱增。
阿里云TSDB是阿里巴巴集團數(shù)據(jù)庫事業(yè)部研發(fā)的一款高性能分布式時序時空數(shù)據(jù)庫，在即將過去的2018年，我們對TSDB進行了多次的系統(tǒng)架構(gòu)改進，引入了倒排索引、無限時間線支持、時序數(shù)據(jù)高壓縮比算法、內(nèi)存緩存、數(shù)據(jù)預(yù)處理、分布式并行聚合、GPU加速等多項核心技術(shù)，并且引入了新的計算引擎層和分布式SQL層，使得引擎核心能力有了質(zhì)的提升，也基本上統(tǒng)一了集團內(nèi)部的監(jiān)控存儲業(yè)務(wù)。2018年雙11當天，TSDB穩(wěn)定運行，0故障，支撐雙十一核心業(yè)務(wù)系統(tǒng)，毫秒級采集能力，具備雙十一峰值寫入不降級，創(chuàng)造了集群TPS 4000萬、QPS 2萬的新紀錄。同時，面向IOT賽道，推出了時空數(shù)據(jù)庫和邊緣計算版本，還會引入面向時序時空場景的智能引擎，未來我們的目標是把TSDB打造成一款業(yè)內(nèi)領(lǐng)先的“智聯(lián)網(wǎng)數(shù)據(jù)庫”。

2018雙十一數(shù)據(jù)

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

場景

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

核心技術(shù)解析

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

一、時序引擎

問題挑戰(zhàn)

穩(wěn)定性、流量翻倍、不降級、低延遲、無限時間線

1. 復(fù)雜時間線索引、無限制時間線支持:

問題

為了支持多維查詢和聚合查詢，TSDB使用了倒排索引以快速定位到某條時間線。在TSDB現(xiàn)有的實現(xiàn)里，倒排索引是全部存放在內(nèi)存中的。該方案的好處是根據(jù)某個Tag或者Metric查找時間線時會非常高效，但是缺點也非常明顯：受限于內(nèi)存大小，TSDB無法支持大規(guī)模的時間線。隨著TSDB的客戶越來越多，這個問題也越來越突出：某直播業(yè)務(wù)要求TSDB能夠支撐20億時間線的規(guī)模；某監(jiān)控業(yè)務(wù)雖然初始時間線只有上千萬，但是每天會新增幾十萬條時間線，而且時間線規(guī)模沒有上限。

方案

TSDB在之前全內(nèi)存倒排索引的基礎(chǔ)上，將倒排索引持久化到硬盤，賦予了TSDB支撐無限時間線的能力。同時，通過給予倒排索引時間的概念，我們將查詢的時間過濾算子下推到了索引查詢階段，進一步優(yōu)化了查詢性能。而通過創(chuàng)建時間線索引的BloomFilter，TSDB保證了海量時間線規(guī)模下的低延遲索引查詢。

效果

拿集團內(nèi)業(yè)務(wù)舉例，原來64G內(nèi)存的機器只能支持到不到500萬的時間線，采用了上面的技術(shù)方案后，64G內(nèi)存的機器就可以支持業(yè)務(wù)將近7000萬以上的時間線，而且時間線數(shù)量在原有機器的基礎(chǔ)上還可以繼續(xù)增加。

2. 高效列式內(nèi)存緩存、時間線內(nèi)存分片：

為了加速數(shù)據(jù)的寫入和查詢能力，今年我們?yōu)門SDB設(shè)計了全內(nèi)存的分布式高效緩存，具體架構(gòu)圖如下：

效果

最終我們測試效果是：在單個docker下，單機TPS從原來的50W提升到100W+，QPS從原來的1K提升到2K+ ；并且這個改進很好的支持了集團魔兔業(yè)務(wù)的需求和發(fā)展。

3. 工作負載管理：

為了更好的解決數(shù)據(jù)量大的情況下的負載均衡的問題，我們做了許多工作，主要包括：

• 通過讀寫分離機制進一步提升寫入和查詢性能；

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

• 自動限流保護，無需業(yè)務(wù)方降級，無懼雙十一洪峰。

效果

雙十一結(jié)果證明，新的負載管理策略幫助業(yè)務(wù)方非常平滑的度過了流量洪峰。

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

這里需要提到的另外一點是，TSDB時序最新架構(gòu)采用了Lindorm作為存儲引擎，能夠以更少的機器成本提供更高的吞吐、更低的延遲。下圖為采用Lindorm存儲引擎前后的TSDB寫入延遲。

5. 聚合器

豐富的流式聚合算子:15+聚合，10+填充策略，支撐大量的adhoc操作：groupby, in，not_literal_or, topN, limit等等;支持不規(guī)則時間序列數(shù)據(jù)的處理，TSDB提供的填值策略，可以很輕松地將不規(guī)則的時間序列轉(zhuǎn)換為常規(guī)時間序列進行處理;支持top-bottom等聚合方式。

6. 混合存儲記錄塊

時序數(shù)據(jù)存儲的記錄塊方式是其查詢性能的基石。TSDB既支持基于時間線的存儲方式，
同時支持基于窗口的數(shù)據(jù)記錄切分，復(fù)用同一套流式聚合，滿足不同業(yè)務(wù)場景性能需求。

7. 服務(wù)化

TSDB服務(wù)目前已經(jīng)在阿里云上出售，目前提供小規(guī)格版本以及標準規(guī)格版本，滿足了很多用戶的需求，但依然有一些用戶希望提供更小規(guī)格的TSDB服務(wù)。為了更好滿足用戶的需求，TSDB提供服務(wù)化功能。服務(wù)化功能是通過多個用戶共享一個TSDB集群的方式來提供更小規(guī)格的TSDB服務(wù)

• 數(shù)據(jù)安全：HTTPS支持，用戶認證

• 并發(fā)管理：寫入并發(fā)管理，查詢并發(fā)管理

• 性能管理：寫入性能管理，查詢性能管理

• 使用量管理：數(shù)據(jù)點管理，時間線管理

時序引擎接下來會繼續(xù)突破核心技術(shù)，包括：自驅(qū)動索引TPI，多值數(shù)據(jù)模型，時序算法，內(nèi)存計算等等。從功能，性能，成本，生態(tài)方面進一步發(fā)力，打通K8S指標存儲體系，具備兼容Prometheus的能力。

二、 時序計算引擎TSCE

業(yè)務(wù)接入量快速突破的過程中, 也帶來了數(shù)據(jù)存儲量級與查詢復(fù)雜度的快速增長, 單TSDB實例 在存儲與計算方面的技術(shù)挑戰(zhàn)也面臨跳躍式提升. 為了避免查詢性能逐漸偏離用戶設(shè)定的目標, TSDB的架構(gòu)演進過程也引入相關(guān)的創(chuàng)新機制, 并最終延伸出時序產(chǎn)品體系中的新成員 - 時序計算引擎(TimeSeries Computing Engine, TSCE).

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

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

TSCE的產(chǎn)品形態(tài)如下:

時序計算引擎(TSCE)作為獨立組件進行部署, 用戶需要在TSDB實例的基礎(chǔ)上根據(jù)成本與應(yīng)用需求選擇是否開啟TSCE時序計算處理. 在這種產(chǎn)品形態(tài)下, 用戶可以獨立調(diào)整TSDB的存儲規(guī)格 ?和 ?TSCE的計算容量, 做到根據(jù)應(yīng)用特點彈性調(diào)整各自組件的實例規(guī)模. 在滿足應(yīng)用要求的情況下將TSDB/TSCE實例部署成本控制在合理區(qū)間.

TSDB與TSCE結(jié)合之后, TSDB引擎會在數(shù)據(jù)入庫過程中同時讓TSCE引擎感知數(shù)據(jù)流動, TSCE會基于配置的時序計算能力或業(yè)務(wù)規(guī)則對數(shù)據(jù)流進行計算與分析, 計算后的結(jié)果支持三種反饋形式: ?1.直接反饋至TSDB存儲層,供TSDB查詢. ?2.作為視圖以API或者SQL方式訪問. ?3.通過Reactive機制投遞給其他事件處理渠道.

時序計算引擎TSCE 支持通過 ?TS-API 或者 Web控制臺 ?進行時序計算能力/自定義規(guī)則的配置.

（1） 時序計算

TSDB與TSCE協(xié)作工作時, 針對核心的時序計算能力, TSCE會與TSDB的進行無縫集成. 此時核心的時序計算處理對于TSDB終端用戶而言是透明,無感知的執(zhí)行過程. 用戶開啟并配置TSCE處理后, 原來的數(shù)據(jù)查詢方式與查詢格式不變, 整個計算的處理完全在后臺自動執(zhí)行.

在查詢層面上,?通過TSCE提供的時序計算處理,?TSDB會在盡可能的情況下將查詢經(jīng)過TSCE處理的計算結(jié)果.即使是在海量數(shù)據(jù)場景下, ?也能提供時序數(shù)據(jù)的秒級分析查詢與時間維度鉆取查詢.

而在數(shù)據(jù)存儲層面上, 隨著時間線的流逝,?TSCE會對原生歷史數(shù)據(jù)進行降維計算,?將細粒度的時間點逐步轉(zhuǎn)化為粗粒度的時間點歸檔存儲(例如秒級數(shù)據(jù)點轉(zhuǎn)化為分鐘級數(shù)據(jù)點), 進一步控制TSDB中存儲空間與資源的使用量, ?使得TSDB的穩(wěn)定性與性能波動處于可控范圍. ?通過TSDB與TSCE結(jié)合, TSDB中管理的數(shù)據(jù)體量可以控制在合理水平, ?提升資源占用率的同時進一步節(jié)省產(chǎn)品使用成本.

• 數(shù)據(jù)流預(yù)聚合
  諸如max/min/avg/count/sum等常見的 可累加式 狀態(tài)值, TSCE可以在數(shù)據(jù)流動過程中即完成相關(guān)數(shù)據(jù)的統(tǒng)計與計算.

• 時間線計算

針對時間線(TimeSeries)的窗口粒度,數(shù)值分布等特征關(guān)系, 對時間線進行特征值轉(zhuǎn)換的計算過程. 例如降采樣(Dowmsampling)運算可以將秒級時間線轉(zhuǎn)化為分鐘級時間線, 經(jīng)過轉(zhuǎn)化后的時間線可以在查詢流程上支持時間維度上下鉆的即席查詢; 而在存儲流程上, 可以支持時間線歸檔存儲, 將原始細粒度時間線轉(zhuǎn)化為粗粒度時間線后,清除原始的數(shù)據(jù)點,釋放相關(guān)資源.

（2） 時序流處理

針對應(yīng)用特定的應(yīng)用型時序計算場景, TSCE通過引入自定義計算規(guī)則與函數(shù), 來滿足各類應(yīng)用自身的特定業(yè)務(wù)計算需求. 用戶在經(jīng)過簡單的規(guī)則配置后, TSCE引擎會負責底層的數(shù)據(jù)流打通, 流計算拓撲映射, 分布式節(jié)點間的Shuffle與結(jié)果歸并, 計算后結(jié)果集的存儲與投遞等一系列動作細節(jié).

與General-purpose的流計算處理相比, TSCE的時序流處理除了實現(xiàn)降低技術(shù)門檻之外,做到底層流計算能力的彈性擴展之外, 也提供幾個核心能力:

• 時序數(shù)據(jù)庫的緊密集成: 因為TSCE與TSDB部署在相同的內(nèi)部環(huán)境內(nèi),TSCE可以在非常低的成本下做到與TSDB做數(shù)據(jù)交換,并且可以直接訪問到TSDB后端的數(shù)據(jù)存儲層. 與常規(guī)應(yīng)用方案中 需要先經(jīng)過流處理再寫入時序存儲產(chǎn)品的架構(gòu)相比, 引擎間的緊密集成可以做到效率,成本,性能的成倍提升.

• Reactive查詢視圖: 流處理后的結(jié)果集除了寫回TSDB中存儲之外, TSCE也支持將數(shù)據(jù)流轉(zhuǎn)儲為Reactive查詢視圖. Reactive查詢視圖除了可以支持以SQL/API方式查詢結(jié)果之外, 也可以通過指定Subscriber訂閱相關(guān)數(shù)據(jù)流更新, 當結(jié)果集在視圖中產(chǎn)生變動時, TSCE會投遞數(shù)據(jù)變更事件至相關(guān)Subscriber指定的渠道中(適合監(jiān)控告警以及自動化處理等業(yè)務(wù)).

時序流處理規(guī)則

定義一個流處理規(guī)則包含了3個元素: 1.數(shù)據(jù)源(TSDB中的時間線), 2.自定義計算規(guī)則, 3.計算結(jié)果的輸出源；其中數(shù)據(jù)源來自于TSDB數(shù)據(jù)庫, 業(yè)務(wù)方可以通過規(guī)則匹配1條或多條時間線作為數(shù)據(jù)輸入源. 而計算結(jié)果的輸出源可以是寫會TSDB, 或者轉(zhuǎn)儲為Reactive視圖.

此外用戶也可以通過lambda自定義與業(yè)務(wù)邏輯處理相關(guān)的函數(shù), 加入到整體的規(guī)則處理鏈中.

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

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

時序分析

簡單的時序流復(fù)雜事件處理(CEP): 提供時間線上數(shù)據(jù)點之間的關(guān)系偵測,模式匹配等.

智能引擎

TSCE支持與時序智能引擎進行聯(lián)通,讓用戶具備針對時序數(shù)據(jù)流進行時序異常探測,故障root-cause分析,流式模型訓練等相關(guān)高級能力. 技術(shù)實現(xiàn)上TSCE以Function,DSL等形式進行智能引擎的規(guī)則定義與轉(zhuǎn)換,?TSCE在數(shù)據(jù)流的計算過程中會基于內(nèi)存間數(shù)據(jù)共享/RPC等方式完成與智能引擎的聯(lián)動與交互

4. ?應(yīng)用場景

雙十一期間, ?TSCE時序計算引擎支撐的幾個典型業(yè)務(wù)場景:

• 海量數(shù)據(jù)下的時間線降維度,預(yù)聚合查詢

• 基于閾值的簡單事件告警

• 時序數(shù)據(jù)的降維歸檔存儲

• 驗證初期的時序分析能力(與智能引擎結(jié)合)

三、分布式MPP SQL引擎：

1. 需求

今年我們決定在TSDB上設(shè)計開發(fā)一個分布式的SQL查詢引擎，為什么要這么做呢？主要有以下幾個原因：

• 從簡單時序監(jiān)控到復(fù)雜時序分析
  TSDB引擎所支持的查詢主要是簡單的降采樣和分組聚合，隨著越來越多業(yè)務(wù)把時序數(shù)據(jù)存儲到TSDB，我們需要提供一個基于SQL的分布式查詢引擎，支持更復(fù)雜的時序計算(聚合，時序Join, SQL Window function， UDF), 從而推廣TSDB到更廣泛的業(yè)務(wù)中。

• 擴展時序數(shù)據(jù)庫的生態(tài)系統(tǒng)
  生態(tài)系統(tǒng)是一個產(chǎn)品是否成功的關(guān)鍵因素。通過時序SQL查詢引擎，TSDB數(shù)據(jù)庫可以和現(xiàn)有的BI tool實現(xiàn)無縫對接。在集團內(nèi)部，我們正在和阿里云的QuickBI和IDB等團隊合作，把TSDB演進成一個支撐重要BI數(shù)據(jù)分析的數(shù)據(jù)庫產(chǎn)品。未來，通過時序SQL查詢引擎，可以對接市場上常見的BI tool, 比如Tableau, Qlik, Power BI等眾多工具。

• 支持多種異構(gòu)數(shù)據(jù)源的聯(lián)合分析
  通常，業(yè)務(wù)把時序相關(guān)的數(shù)據(jù)存儲在TSDB，非時序數(shù)據(jù)存儲在其他系統(tǒng)中，比如維度信息存儲在MySQL等。業(yè)務(wù)需要在多種數(shù)據(jù)中進行Join。時序SQL查詢引擎支持業(yè)務(wù)在多種數(shù)據(jù)源之間直接進行查詢分析，避免業(yè)務(wù)方復(fù)制異構(gòu)數(shù)據(jù)源再進行聯(lián)合分析。

• 對標業(yè)界主要競爭產(chǎn)品
  時序數(shù)據(jù)庫在國外最主要的競爭產(chǎn)品包括TimeScaleDB, InfluxDB， KDB+，Prometheus。TimeScaleDB作為Postgres的一個擴展，提供了標準SQL的支持，而InfluxDB/KDB+提供了類似于SQL (SQL-like)的查詢支持。我們TSDB系統(tǒng)通過時序SQL查詢引擎，更好地對標國外主要時序競爭產(chǎn)品。

2. SQL引擎的挑戰(zhàn)

除了海量時序數(shù)據(jù)帶來的挑戰(zhàn)外，時序SQL查詢引擎還面臨和時序場景相關(guān)的挑戰(zhàn)：

• 數(shù)據(jù)table Schema的管理

  • 時序metric數(shù)目海量：Sunfire等集團內(nèi)部業(yè)務(wù)有上億規(guī)模的時間線，而盒馬業(yè)務(wù)中將tag編碼進metric, 時間線數(shù)目巨大，這和一般數(shù)據(jù)庫中數(shù)千或數(shù)萬的table是巨大的區(qū)別;

  • 時序metric schema動態(tài)變化：業(yè)務(wù)方隨著應(yīng)用的變化，經(jīng)常需要增加或減少一個tag。這意味著metric所對應(yīng)的schema也在不斷變化之中。海量時間線+動態(tài)變化對查詢引擎獲取metric的schema 是一個挑戰(zhàn)。

• 數(shù)據(jù)schema-on-write對查詢引擎的影響

大多數(shù)的數(shù)據(jù)庫在用戶寫入數(shù)據(jù)或查詢之前，必須先通過DDL創(chuàng)建table schema，這些table schema等元數(shù)據(jù)又被存放在一個catalog或meta data store, 供數(shù)據(jù)寫入或查詢時使用。而時序數(shù)據(jù)庫的業(yè)務(wù)中，大部分的數(shù)據(jù)源來自于監(jiān)控設(shè)備的一個agent, 或者IOT物聯(lián)網(wǎng)的一個sensor, 要求先定義DDL再寫入數(shù)據(jù)會嚴重影響可用性; 同時，時序metric所對應(yīng)的tag集合在應(yīng)用演進過程中，變化很常見。針對這一的應(yīng)用特點，時序數(shù)據(jù)庫TSDB，InfluxDB， Prometheus都采用了一種'Schema-on-write'的機制，應(yīng)用直接寫入數(shù)據(jù)，table schema是隱含在數(shù)據(jù)中。在'Schema-on-write'的機制下，需要解決沒有DDL的情況下SQL查詢引擎如何從海量時間線中獲取table schema等元數(shù)據(jù)的問題。

• 時序功能擴展

在現(xiàn)有以關(guān)系運算為基礎(chǔ)的SQL查詢引擎中。為支持時序功能擴展，我們需要一個易于擴展功能的架構(gòu)，能支持開發(fā)時序相關(guān)的功能，比如時序Join, 時序相關(guān)的用戶自定義函數(shù)(UDF)。

• 時序查詢優(yōu)化

一個SQL查詢引擎，優(yōu)化器是性能優(yōu)劣的關(guān)鍵。需要在通用的SQL查詢引擎中，引入時序數(shù)據(jù)統(tǒng)計信息，作為輸入提供給優(yōu)化器；同時，在優(yōu)化器中，引入時序相關(guān)的優(yōu)化Rule, 比如FilterPushDown/ProjectPushDown規(guī)則，這些都是時序SQL查詢引擎需要解決的問題。

3. SQL引擎

SQL查詢引擎是一個分布式的系統(tǒng)，其特點：

• 每個計算節(jié)點在系統(tǒng)中是對等的，并沒有主從關(guān)系，

• 任何一個節(jié)點都可以成為Foreman, 負責SQL查詢計劃的生成，而其他節(jié)點成為worker nodes

• 無狀態(tài)，一個節(jié)點失效后，可以快速啟動備用節(jié)點。

4. ?應(yīng)用場景

• 盒馬零售業(yè)績時序數(shù)據(jù)查詢: 業(yè)務(wù)方需要通過SQL查詢TSDB的時序數(shù)據(jù)，接入業(yè)務(wù)方的分析圖表大屏。此外，業(yè)務(wù)方需要支持簡單的SQL簡單查詢外，還包括異構(gòu)多種數(shù)據(jù)源的join的支持。![image]

• 云監(jiān)控：通過提高SQL查詢支持，業(yè)務(wù)方能統(tǒng)一數(shù)據(jù)訪問方式![image]

四、 時空數(shù)據(jù)庫

1. 需求

隨著TSDB的業(yè)務(wù)發(fā)展，時序數(shù)據(jù)庫TSDB漸漸走出APM與監(jiān)控領(lǐng)域，在IoT領(lǐng)域也獲得廣泛應(yīng)用。 而由于IoT領(lǐng)域的特性，其中采集到的很多數(shù)據(jù)不光有時間信息，還有空間信息與之關(guān)聯(lián)。因此時序數(shù)據(jù)庫也需要能夠識別和處理空間信息，以便于更好地服務(wù)IoT場景。

對于傳統(tǒng)的時間序列數(shù)據(jù)庫，比如說OpenTSDB，如果用戶想要存儲和查詢地理坐標信息，往往需要將經(jīng)度和緯度分開存儲，生成獨立的時間線。但是使用時想要將兩者重新關(guān)聯(lián)起來需要用戶做額外處理。另外一種方式則是需要用戶自己將地理位置信息進行編碼，常見有的GeoHash或者Google S2。然后將編碼信息作為時間線信息進行存儲。即使這樣，用戶依舊需要開發(fā)時空過濾功能等等。

2. 方案

在IoT場景中，對于地理坐標信息的采集十分普遍。因此在時序數(shù)據(jù)庫的基礎(chǔ)上，我們添加了對空間信息的存儲和處理能力，使之成為時序時空數(shù)據(jù)庫。TSDB的時空引擎讓地理位置信息和時序信息完美結(jié)合起來，力爭解決著一切關(guān)于時序和時空相關(guān)的查詢分析。

3. 時空處理能力

最新版本的阿里云TSDB支持地理坐標位置信息的直接寫入。用戶只需要通過新版本的SDK以及Http Restful APIs可以將地理空間信息（地理經(jīng)緯度）寫入，并且可以對經(jīng)緯度信息進行讀取。下面兩個通過Http Restful API接口TSDB多值寫入和單純的軌跡查詢示例：（注意：Coordinate是一個關(guān)鍵字，表示地理坐標點寫入，不可用于其他監(jiān)控指標名稱(metric)。）

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

對于寫入的地理坐標數(shù)據(jù)點，TSDB將自動生成時空索引提高查詢和分析效率。TSDB的時空索引基于傳統(tǒng)空間索引（Google S2和GeoHash都是支持）結(jié)合時序數(shù)據(jù)特征創(chuàng)建的時空索引格式。同時為了提高，用戶可以根據(jù)自己需求在開始使用時空功能之前提前配置時空索引按照時間分片。偏實時的業(yè)務(wù)，可以將按照小時或者半小時對時空索引進行分片。對于偏分析的場景，可以按照天進行分片。

時空索引為TSDB提供時空過濾分析功能提供了便捷和提高效率，現(xiàn)在最新版本的TSDB支持一些常用的時空過濾功能，比如BBOX查詢和DISTANCE_WITHIN查詢。

目前TSDB時空功能已經(jīng)在云上推出了公測版本，大家在官網(wǎng)就可以看到我們時空功能。

4. 下一代時空數(shù)據(jù)庫核心技術(shù)全力研發(fā)中

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

五、邊緣計算

今年，為了進一步支持外部IoT市場的需求，我們在TSDB云版的基礎(chǔ)上，開發(fā)了邊緣計算版本（在廣州云棲大會工業(yè)物聯(lián)網(wǎng)專場，正式發(fā)布阿里云工業(yè)物聯(lián)網(wǎng)邊緣計算平臺存儲類產(chǎn)品 TSDB Edge，TSDB Edge 主要提供物聯(lián)網(wǎng)邊緣端設(shè)備相關(guān)數(shù)據(jù)的本地存儲，本地分析，數(shù)據(jù)清洗和云端數(shù)據(jù)同步能力。）；

1. 兩節(jié)點HA

• 兩節(jié)點HA通過兩個TSDB節(jié)點實現(xiàn)HA。兩個TSDB節(jié)點沒有主從的區(qū)別，二者都可以接受讀寫請求，也都可以響應(yīng)讀寫服務(wù)（不需要轉(zhuǎn)發(fā)讀寫請求）。兩個TSDB節(jié)點能夠同時接受寫請求，兩個TSDB通過同步WAL日志的方式實現(xiàn)數(shù)據(jù)同步，保障數(shù)據(jù)的最終一致性。同時，兩節(jié)點HA通過WAL與云端同步數(shù)據(jù)。

• 兩節(jié)點HA提供了在邊緣設(shè)備端TSDB的高可用性，當一個節(jié)點發(fā)生宕機，另外一個節(jié)點能夠繼續(xù)提供服務(wù)，宕機節(jié)點恢復(fù)以后，通過數(shù)據(jù)同步功能，數(shù)據(jù)能夠在兩個節(jié)點上迅速實現(xiàn)同步，不會引起非硬盤故障下的數(shù)據(jù)丟失。

2. WAL日志管理器

• 實現(xiàn)本地的WAL日志管理，通過WAL日志保證寫入的數(shù)據(jù)不丟失。同時WAL日志管理器，自動判斷并刪除過期日志文件，減少硬盤空間占用，減輕運維工作。

3. 內(nèi)存管理器

• 管理大對象的內(nèi)存使用情況，通過監(jiān)控實時內(nèi)存使用情況，自動判斷是否將內(nèi)存中的數(shù)據(jù)寫入文件系統(tǒng)以減少內(nèi)存使用。內(nèi)存管理器根據(jù)內(nèi)存使用情況，自動設(shè)置保留的chunks數(shù)量，可以減少/杜絕OutOfMemoryError錯誤的發(fā)生。

4. HAServer/HAClient數(shù)據(jù)同步器

• HAClient通過自有的協(xié)議，采用PUSH的方式傳輸WAL。HAServer收到WAL以后，直接通過WAL replay數(shù)據(jù)插入操作，從而實現(xiàn)數(shù)據(jù)同步。HAServer/HAClient通過保存讀取偏移量的方式，實現(xiàn)斷點續(xù)傳。

• CloudSynchronizer云同步器

• 通過讀取WAL，并調(diào)用TSDB云版客戶端實現(xiàn)向云端同步數(shù)據(jù)的功能。該同步器對云端透明，同時實現(xiàn)了斷點續(xù)傳。

5. 新型壓縮算法

• 邊緣計算提出自研的新型壓縮算法，該壓縮算法，采用流式壓縮方式，支持數(shù)據(jù)通過append的方式加入，同時在內(nèi)部采用整字節(jié)的方式進行編碼，提高壓縮/解壓性能。

經(jīng)測試，該新型壓縮算法的壓縮率為3-40倍。與Facebook Gorilla算法相比，該算法壓縮率提高約20%-50%，壓縮性能提高3-5倍，解壓性能提高4-6倍。

6. GPU硬件加速

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

通過測試，使用GPU以后，查詢性能可以達到原來的50倍。

六、智能引擎

背景

TSDB 提供了強大的數(shù)據(jù)存儲、處理和查詢能力。在這個堅實的基礎(chǔ)之上，越來越多的業(yè)務(wù)場景需要通過挖掘海量數(shù)據(jù)驅(qū)動業(yè)務(wù)價值的提升，TSDB 智能引擎就是在這個大趨勢之下應(yīng)運而生的。

能力

TSDB智能引擎專注于時序時空數(shù)據(jù)的分析、檢測、挖掘、預(yù)測能力，著力打造從數(shù)據(jù)到知識再到商業(yè)價值的高效引擎，爭取達到價值鏈與數(shù)據(jù)能力的兩個全覆蓋。
市場上現(xiàn)有的商業(yè)智能與數(shù)據(jù)科學工具往往只利用數(shù)據(jù)庫的存儲查詢功能，進行數(shù)據(jù)挖掘和分析之前需要從數(shù)據(jù)庫中提數(shù)，之后的流程也脫離數(shù)據(jù)庫環(huán)境進行。TSDB 智能引擎從架構(gòu)上與數(shù)據(jù)庫存儲查詢引擎進行深度整合，高效的利用數(shù)據(jù)庫現(xiàn)有關(guān)系代數(shù)能力，并適當引入線性代數(shù)計算能力，自然的形成數(shù)據(jù)閉環(huán)，提供一站式的數(shù)據(jù)科學能力。相信隨著不斷地努力打造與突破，智能引擎也會逐步沉淀行業(yè)數(shù)據(jù)模型與智能定制算法，并最終形成端到端的行業(yè)智能分析解決方案。

限于篇幅，這里就不詳細描述了。

八、其他

時序洞察

時序標準

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

結(jié)束語

2018年，是阿里云TSDB產(chǎn)品成長最快的一年；上文中提到的需要技術(shù)和能力目前只是應(yīng)用在阿里巴巴集團內(nèi)部的場景；未來，我們會逐步把這些能力開發(fā)給外部用戶，讓外部客戶也能享受到阿里巴巴強大的技術(shù)實力帶來的價值。
最終，我們的目標是把TSDB打造成業(yè)內(nèi)領(lǐng)先的“智聯(lián)網(wǎng)數(shù)據(jù)庫”！