摘要：現在的時序數據庫底層存儲一般用的是單值模型。現在一般的時序數據庫中，主鍵是會默認生成的，即所有的組合。

摘要： 隨著云計算和IoT的發展，時間序列數據的數據量急劇膨脹，高效的分析時間序列數據，使之產生業務價值成為一個熱門話題。阿里巴巴數據庫事業部的HiTSDB團隊為您分享時間序列數據的計算分析的一般方法以及優化手段。

演講嘉賓簡介：鐘宇（悠你） 阿里巴巴 數據庫高級專家，時間序列數據庫HiTSDB的研發負責人。在數據庫、操作系統、函數式編程等方面有豐富的經驗。

本次直播視頻PPT，戳這里！

本次分享主要分為以下幾個方面：

時序數據庫的應用場景

面向分析的時序數據存儲

時序數據庫的時序計算

時序數據庫的計算引擎

時序數據庫展望

一，時序數據庫的應用場景

時序數據就是在時間上分布的一系列數值。生活中常見的時序數據包括，股票價格、廣告數據、氣溫變化、網站的PV/UV、個人健康數據、工業傳感器數據、服務器系統監控數據（比如CPU和內存占用率）、車聯網等。

下面介紹IoT領域中的時間序列數據案例。IoT給時序數據處理帶來了很大的挑戰。這是由于IoT領域帶來了海量的時間序列數據：

成千上萬的設備

數以百萬計的傳感器

每秒產生百萬條數據

24×7全年無休（區別于電商數據，電商數據存在高峰和低谷，因此可以利用低谷的時間段進行數據庫維護，數據備份等工作）

多維度查詢/聚合

最新數據實時可查

IoT中的時間序列數據處理主要包括以下四步：

采樣

傳輸

存儲

分析

二，面向分析的時序數據存儲

下面介紹時間序列數據的一個例子。這是一個新能源風力發電機的例子。每個風力發電機上有兩個傳感器，一個是功率，一個是風速，并定時進行采樣。三個設備，一共會產生六個時間序列。每個發電機都有多種標簽，這就會產生多個數據維度。比如，基于生產廠商這個維度，對功率做聚合。或基于風場，對風速做聚合等。現在的時序數據庫底層存儲一般用的是單值模型。因為多值模型也可以一對一的映射到單值模型，但這個過程可能會導致性能損失。但是，在對外提供服務時，單值模型和多值模型都有應用。比如，OpenTSDB就是用單值模型對外提供服務的，而influxDB則是多值模型。但這兩種數據庫的底層存儲用的都是單值模型。

現實中的應用案例事實上會更復雜。像風力發電機這樣的案例，它的設備和傳感器的數量，我們可以認為是穩中有增的，不會發生特別劇烈的改變。它的數據采樣的周期也是嚴格的定期采樣。下圖是一個工業案例，以滴滴這樣的運營商為例。由于其業務特性，其車輛數量的增長和下降會出現暴漲暴跌。

總體而言，現實世界的復雜之處在于:

未必是總是定時采樣。

時間線可能是高度發散。以互聯網廣告為例，在對廣告進行采樣時，新廣告的增長和老廣告的下線速度很快，時間線就很有可能時高度發散的。

主鍵和schema修改。前面例子中提到的Tag，可以對應數據庫的schema，在實際業務中可能會頻繁改動。現在一般的時序數據庫中，主鍵是會默認生成的，即所有tag的組合。因此，在新增tag時，主鍵就會改變，則變為了另一個對象。

分布式系統和片鍵。由于數據量很大，因此需要對數據進行分片，片鍵的選擇也是一個難以抉擇的問題。

數據類型。以剛才提到的單值模型為例。假設有一個三維的加速度傳感器，同一時間點上會產生三個關聯的數據，這時的數據類型就應該是一個維度為3的矢量，即一個新的數據類型。

需要對每個數據點的值做過濾。假設每輛車上都裝有GPS傳感器，假設要統計某一時間段內，一公里內，出現了哪些車輛，分別由哪些廠商生產。此時需要對地理位置進行過濾。

下圖是過去提出利用HiTSDB對時序問題的解決方案。在這種方案中，未解決發散問題，較高維數據和值過濾問題。用倒排索引來存儲設備信息，并把時間點上的數據存在高壓縮比緩存中。這兩者結合，實際上將邏輯上的一個表分成了兩個表，用以解決多維度查詢和聚合的問題。但使用這種方案依然有很多問題無法解決。

下面是HiTSDB的一些優勢和不足：

優勢：

·倒排索引可以很方便的篩選設備；

·高壓縮比緩存具有很高的寫入和讀取能力

·方便的時間切片

·無schema，靈活方便支持各種數據模型

不足：

·在非定時采樣場景下可能導致數據稀疏

·值沒有索引，因此值過濾只能線性過濾

· Schema改動導致時間線變動

·廣播查限制了QPS

在此基礎上，進行了演進，如下圖。

引入了Adaptive schema，即如果未指定一個數據表的schema，則認為寫入的第一條數據中包含的TagKV即是片鍵也是主鍵，用以確定唯一性以及數據會被分片到哪一個節點上。

壓縮塊也不再是按固定的時間切片了，引入了meta index，用以查詢每個數據塊的開始和結束時間。在一個時間段內攢夠了足夠的數據后，把整個數據塊進行壓縮。

參考列存的思路，值索引到壓縮塊。值索引不再像傳統數據庫那樣索引到行。

多值索引和空間切分。

三，時序數據庫的時序算法

上面所述的存儲結構主要是為了方便進行時序數據的加工和分析。時序有一些特殊算法。

降采樣和插值：傳感器采樣出的點可能特別密集，在分析趨勢時，會希望進行過濾。通過降采樣可以利用一段時間內的最小值/最大值/平均值來替代。

·降采樣算法：min/max/avg。

·插值算法：補零/線性/貝塞爾曲線

聚合計算：由于采樣是精確到每個傳感器的，但有時需要的數據并不僅是精確到某個傳感器的。比如，希望比較兩個不同廠商的發電機，哪個在風場中產生了更多的電。那么就需要對傳感器數據進行聚合。

·邏輯聚合：min/max

·算術聚合：sum/count/avg

·統計：histogram/percentile/Standard Deviation

時間軸計算

·變化率：rate

對時序數據進行加工的分析的重要目的是發現異常。下面介紹在異常檢測中如何定義問題。從異常檢測的角度來看時間序列數據，分為三個維度：time, object, metric。

固定兩個維度，只考慮一個維度的數據。

·T: only consider time dim，單一對象單一metric即單個時間序列）：spikes & dips、趨勢變化、范圍變化。

·M: only consider metric，找出不符合metric之間相互關系的數據。

·O: only consider object，找出與眾不同的對象。

固定一個維度，只考慮兩個維度的數據。

·MT：固定對象，考慮多個時間序列（每個對應一個metric)，并找出其相互變化方式不同的作為異常。

·MO：不考慮時間特性，考慮多個對象且每個對象都可以用多個metric表示，如何從中找出不同的對象。

·TO：多個對象單一metric，找出變化趨勢不同的對象。

在異常檢測中，面向問題有如下計算方法：

內置函數

·高壓縮比緩存直接作為窗口緩存

·對于滿足數據局部性的問題，直接在高壓縮比緩存上運行

·結果直接寫回

·定時調度 vs 數據觸發

外置計算

·定時查詢 vs 流式讀取

·使用同樣的查詢語言執行查詢或定義數據源

·數據庫內置時間窗口

·數據流的觸發機制

針對時序數據，又可以將計算分為預計算和后計算。

預計算:事先將結果計算完并存儲。這是流計算中常用的方式。其特點如下：

·數據存儲量低

·查詢性能高

·需要手工編寫計算過程

·新的計算無法立即查看結果

·靈活性差

·不保存原始數據

后計算：先存數據，需要時進行計算。這是數據庫中常用的方式。其特點如下：

·數據存儲量大

·查詢/聚合性能瓶頸

·任何查詢都可以隨時獲得結果

·使用DSL進行查詢

·靈活性好

·保存原始數據

四，時序數據庫的計算引擎

基于兩種計算的特點，在時序數據處理中，我們使用的是一種混合架構。有數據進來時，有預聚合規則，如果符合規則就進行預聚合，把數據寫入數據庫中。在查詢時，如果符合預聚合規則，就可以很快得到結果。對于不滿足預聚合規則的數據，會將其從數據庫中讀出，進行后聚合。中間的聚合引擎是一種類似流式計算的架構，數據庫或者數據源都可以作為數據源。數據源的來源對于引擎是不可見的，它的功能是接收數據，計算并產生結果。因此，預計算和后計算都可以利用這一種邏輯進行，并放在同一個運行環境中。

在邏輯上，上圖是可行的。但實際上，如果要用這種方式進行流計算，由于數據源可能出現亂序等問題，就必須要利用窗口函數，將數據放入時間窗口中整理好，但這種緩存的效率其實并不高，實際情況下，是按照下圖這種邏輯進行的。數據會被寫進數據庫，由于數據庫有高壓縮比緩存，是專門針對時序數據的。當一個時間窗口結束時，利用持續查詢來進行預計算。它會將高壓縮比緩存中的數據拿一部分出來做預聚合再寫回數據庫中。這樣，這個緩存機制就替代了原來的時間窗口，節省了很多內存，降低了很多計算開銷。

使用類似于流的架構的好處是可以將其很快的接入異構計算的環境中。正如大家熟知的，流計算可以轉化為一個DAG。結合前面提到的降采樣和聚合的例子。以一個加法為例，可以把數據切成三片放入不同的工作節點上計算，計算完后再進行一次聚合輸出數據。工作節點既可能是CPU也可能是GPU。接入異構計算的環境中，可以加速數據的計算。

五，時序數據庫展望

下圖是對未來架構的展望。

存儲層

·類似lambda架構，基于一系列不可修改的文件

·針對不同的場景提供不同的存儲格式

計算層

·流式架構，基于內存的異構計算，自動填充熱數據

·數據分片，支持高QPS讀取

索引

·全局的索引 vs 文件局部索引

大數據

·可以直接在大量的文件上跑MR，也可以通過高壓縮比緩存以流的方式訂閱數據

未來，這個數據庫將會演化成時序數據平臺。它可以兼容SQL生態，一系列大數據平臺，以及融合邊緣計算。在部署時可以在云和邊緣部署一整套的管理架構，同時把用SQL描述的規則下放到云板和邊緣板上，形成一整套數據處理方案。

POLARDB ：https://www.aliyun.com/produc...
HBASE： https://www.aliyun.com/produc...

云數據庫RDS PPAS 版： https://www.aliyun.com/produc...

原文鏈接