時間序列資料的處理

貓耳發表於2018-05-30

摘要：隨著雲端計算和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，靈活方便支援各種資料模型

2. 不足：

在非定時取樣場景下可能導致資料稀疏

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

Schema改動導致時間線變動

廣播查限制了QPS

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

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

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

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

4. 多值索引和空間切分。

三，時序資料庫的時序演算法

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

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

降取樣演算法：min/max/avg。

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

2. 聚合計算：由於取樣是精確到每個感測器的，但有時需要的資料並不僅是精確到某個感測器的。比如，希望比較兩個不同廠商的發電機，哪個在風場中產生了更多的電。那麼就需要對感測器資料進行聚合。

邏輯聚合：min/max

算術聚合：sum/count/avg

統計：histogram/percentile/Standard Deviation

3. 時間軸計算

變化率：rate

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

1. 固定兩個維度，只考慮一個維度的資料。

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

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

·O: only consider object，找出與眾不同的物件。

2. 固定一個維度，只考慮兩個維度的資料。

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

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

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

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

1. 內建函式

·高壓縮比快取直接作為視窗快取

·對於滿足資料區域性性的問題，直接在高壓縮比快取上執行

·結果直接寫回

·定時排程 vs 資料觸發

2. 外接計算

·定時查詢 vs 流式讀取

·使用同樣的查詢語言執行查詢或定義資料來源

·資料庫內建時間視窗

·資料流的觸發機制

針對時序資料，又可以將計算分為預計算和後計算。

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

·資料儲存量低

·查詢效能高

·需要手工編寫計算過程

·新的計算無法立即檢視結果

·靈活性差

·不儲存原始資料

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

·資料儲存量大

·查詢/聚合效能瓶頸

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

·使用DSL進行查詢

·靈活性好

·儲存原始資料

四，時序資料庫的計算引擎

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

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

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