天天看點

時間序列資料的處理

演講嘉賓簡介:

鐘宇(悠你) 阿裡巴巴 資料庫進階專家,時間序列資料庫HiTSDB的研發負責人。在資料庫、作業系統、函數式程式設計等方面有豐富的經驗。

本次直播視訊PPT,戳這裡! https://yq.aliyun.com/download/2663 本次分享主要分為以下幾個方面:

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. 多值索引和空間切分。

三,

時序資料庫的時序算法

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

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

·

降采樣算法: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/product/polardb?spm=5176.8142029.388261.347.62136d3etcPz5x

HBASE

https://www.aliyun.com/product/hbase?spm=5176.155538.765261.355.57227e0dLAlXGl

雲資料庫RDS PPAS 版

https://www.aliyun.com/product/rds/ppas?spm=5176.54432.765261.351.6e1e28f5UFqADw

本文由雲栖志願小組馬JY整理