時間序列數據的處理

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

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

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

本次分享主要分爲如下幾個方面：

1. 時序數據庫的應用場景
2. 面向分析的時序數據存儲
3. 時序數據庫的時序計算
4. 時序數據庫的計算引擎
5. 時序數據庫展望

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

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

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

1. 成千上萬的設備
2. 數以百萬計的傳感器
3. 每秒產生百萬條數據
4. 24×7整年無休（區別於電商數據，電商數據存在高峯和低谷，所以能夠利用低谷的時間段進行數據庫維護，數據備份等工做）
5. 多維度查詢/聚合
6. 最新數據實時可查

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

1. 採樣
2. 傳輸
3. 存儲
4. 分析

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

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

現實中的應用案例事實上會更復雜。像風力發電機這樣的案例，它的設備和傳感器的數量，咱們能夠認爲是穩中有增的，不會發生特別劇烈的改變。它的數據採樣的週期也是嚴格的按期採樣。下圖是一個工業案例，以滴滴這樣的運營商爲例。因爲其業務特性，其車輛數量的增加和降低會出現暴漲暴跌。

整體而言，現實世界的複雜之處在於:

1. 未必是老是定時採樣。
2. 時間線多是高度發散。以互聯網廣告爲例，在對廣告進行採樣時，新廣告的增加和老廣告的下線速度很快，時間線就頗有可能時高度發散的。
3. 主鍵和schema修改。前面例子中提到的Tag，能夠對應數據庫的schema，在實際業務中可能會頻繁改動。如今通常的時序數據庫中，主鍵是會默認生成的，即全部tag的組合。所以，在新增tag時，主鍵就會改變，則變爲了另外一個對象。
4. 分佈式系統和片鍵。因爲數據量很大，所以須要對數據進行分片，片鍵的選擇也是一個難以抉擇的問題。
5. 數據類型。以剛纔提到的單值模型爲例。假設有一個三維的加速度傳感器，同一時間點上會產生三個關聯的數據，這時的數據類型就應該是一個維度爲3的矢量，即一個新的數據類型。
6. 須要對每一個數據點的值作過濾。假設每輛車上都裝有GPS傳感器，假設要統計某一時間段內，一千米內，出現了哪些車輛，分別由哪些廠商生產。此時須要對地理位置進行過濾。

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

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

1. 優點：

·倒排索引能夠很方便的篩選設備；

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

·方便的時間切片

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

1. 不足：

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

·值沒有索引，所以值過濾只能線性過濾

· Schema改動致使時間線變更

·廣播查限制了QPS

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

1. 引入了Adaptive schema，即若是未指定一個數據表的schema，則認爲寫入的第一條數據中包含的TagKV便是片鍵也是主鍵，用以肯定惟一性以及數據會被分片到哪個節點上。
2. 壓縮塊也再也不是按固定的時間切片了，引入了meta index，用以查詢每一個數據塊的開始和結束時間。在一個時間段內攢夠了足夠的數據後，把整個數據塊進行壓縮。
3. 參考列存的思路，值索引到壓縮塊。值索引再也不像傳統數據庫那樣索引到行。
4. 多值索引和空間切分。

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

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

1. 降採樣和插值：傳感器採樣出的點可能特別密集，在分析趨勢時，會但願進行過濾。經過降採樣能夠利用一段時間內的最小值/最大值/平均值來替代。

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

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

1. 聚合計算：因爲採樣是精確到每一個傳感器的，但有時須要的數據並不只是精確到某個傳感器的。好比，但願比較兩個不一樣廠商的發電機，哪一個在風場中產生了更多的電。那麼就須要對傳感器數據進行聚合。

·邏輯聚合：min/max

·算術聚合：sum/count/avg

·統計：histogram/percentile/Standard Deviation

1. 時間軸計算

·變化率：rate

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

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

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

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

·O: only consider object，找出不同凡響的對象。

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

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

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

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

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

1. 內置函數

·高壓縮比緩存直接做爲窗口緩存

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

·結果直接寫回

·定時調度 vs 數據觸發

1. 外置計算

·定時查詢 vs 流式讀取

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

·數據庫內置時間窗口

·數據流的觸發機制

針對時序數據，又能夠將計算分爲預計算和後計算。

預計算:事先將結果計算完並存儲。這是流計算中經常使用的方式。其特色以下：

·數據存儲量低

·查詢性能高

·須要手工編寫計算過程

·新的計算沒法當即查看結果

·靈活性差

·不保存原始數據

後計算：先存數據，須要時進行計算。這是數據庫中經常使用的方式。其特色以下：

·數據存儲量大

·查詢/聚合性能瓶頸

·任何查詢均可以隨時得到結果

·使用DSL進行查詢

·靈活性好

·保存原始數據

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

基於兩種計算的特色，在時序數據處理中，咱們使用的是一種混合架構。有數據進來時，有預聚合規則，若是符合規則就進行預聚合，把數據寫入數據庫中。在查詢時，若是符合預聚合規則，就能夠很快獲得結果。對於不知足預聚合規則的數據，會將其從數據庫中讀出，進行後聚合。中間的聚合引擎是一種相似流式計算的架構，數據庫或者數據源均可以做爲數據源。數據源的來源對於引擎是不可見的，它的功能是接收數據，計算併產生結果。所以，預計算和後計算均可以利用這一種邏輯進行，並放在同一個運行環境中。

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

使用相似於流的架構的好處是能夠將其很快的接入異構計算的環境中。正如你們熟知的，流計算能夠轉化爲一個DAG。結合前面提到的降採樣和聚合的例子。以一個加法爲例，能夠把數據切成三片放入不一樣的工做節點上計算，計算完後再進行一次聚合輸出數據。工做節點既多是CPU也多是GPU。接入異構計算的環境中，能夠加速數據的計算。

五，時序數據庫展望

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

1. 存儲層

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

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

1. 計算層

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

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

1. 索引

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

1. 大數據

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

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

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

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

原文連接