摘要：隨著云計算和IoT的發(fā)展，時間序列數(shù)據(jù)的數(shù)據(jù)量急劇膨脹，高效的分析時間序列數(shù)據(jù)，使之產(chǎn)生業(yè)務價值成為一個熱門話題谬盐。阿里巴巴數(shù)據(jù)庫事業(yè)部的HiTSDB團隊為您分享時間序列數(shù)據(jù)的計算分析的一般方法以及優(yōu)化手段。
演講嘉賓簡介：鐘宇（悠你） 阿里巴巴 數(shù)據(jù)庫高級專家诚些，時間序列數(shù)據(jù)庫HiTSDB的研發(fā)負責人飞傀。在數(shù)據(jù)庫、操作系統(tǒng)诬烹、函數(shù)式編程等方面有豐富的經(jīng)驗砸烦。
本次分享主要分為以下幾個方面：
1.?????時序數(shù)據(jù)庫的應用場景
2.?????面向分析的時序數(shù)據(jù)存儲
3.?????時序數(shù)據(jù)庫的時序計算
4.?????時序數(shù)據(jù)庫的計算引擎
5.?????時序數(shù)據(jù)庫展望
一幢痘，時序數(shù)據(jù)庫的應用場景
時序數(shù)據(jù)就是在時間上分布的一系列數(shù)值。生活中常見的時序數(shù)據(jù)包括家破，股票價格颜说、廣告數(shù)據(jù)购岗、氣溫變化、網(wǎng)站的PV/UV门粪、個人健康數(shù)據(jù)喊积、工業(yè)傳感器數(shù)據(jù)、服務器系統(tǒng)監(jiān)控數(shù)據(jù)（比如CPU和內存占用率）玄妈、車聯(lián)網(wǎng)等乾吻。
下面介紹IoT領域中的時間序列數(shù)據(jù)案例。IoT給時序數(shù)據(jù)處理帶來了很大的挑戰(zhàn)措近。這是由于IoT領域帶來了海量的時間序列數(shù)據(jù)：
1. 成千上萬的設備
2. 數(shù)以百萬計的傳感器
3. 每秒產(chǎn)生百萬條數(shù)據(jù)
4. 24×7全年無休（區(qū)別于電商數(shù)據(jù)溶弟，電商數(shù)據(jù)存在高峰和低谷女淑，因此可以利用低谷的時間段進行數(shù)據(jù)庫維護瞭郑，數(shù)據(jù)備份等工作）
5. 多維度查詢/聚合
6. 最新數(shù)據(jù)實時可查
IoT中的時間序列數(shù)據(jù)處理主要包括以下四步：
?1. 采樣
?2. 傳輸
?3. 存儲
4. 分析
二，面向分析的時序數(shù)據(jù)存儲
下面介紹時間序列數(shù)據(jù)的一個例子鸭你。這是一個新能源風力發(fā)電機的例子屈张。每個風力發(fā)電機上有兩個傳感器，一個是功率袱巨，一個是風速阁谆，并定時進行采樣。三個設備愉老，一共會產(chǎn)生六個時間序列场绿。每個發(fā)電機都有多種標簽，這就會產(chǎn)生多個數(shù)據(jù)維度嫉入。比如焰盗，基于生產(chǎn)廠商這個維度，對功率做聚合咒林“揪埽或基于風場，對風速做聚合等〉婢海現(xiàn)在的時序數(shù)據(jù)庫底層存儲一般用的是單值模型澎粟。因為多值模型也可以一對一的映射到單值模型，但這個過程可能會導致性能損失欢瞪。但是活烙，在對外提供服務時，單值模型和多值模型都有應用遣鼓。比如啸盏，OpenTSDB就是用單值模型對外提供服務的，而influxDB則是多值模型譬正。但這兩種數(shù)據(jù)庫的底層存儲用的都是單值模型宫补。
現(xiàn)實中的應用案例事實上會更復雜檬姥。像風力發(fā)電機這樣的案例甚淡，它的設備和傳感器的數(shù)量雷恃，我們可以認為是穩(wěn)中有增的，不會發(fā)生特別劇烈的改變胎撇。它的數(shù)據(jù)采樣的周期也是嚴格的定期采樣贫贝。下圖是一個工業(yè)案例秉犹，以滴滴這樣的運營商為例。由于其業(yè)務特性稚晚，其車輛數(shù)量的增長和下降會出現(xiàn)暴漲暴跌崇堵。
總體而言，現(xiàn)實世界的復雜之處在于:
1. 未必是總是定時采樣客燕。
2. 時間線可能是高度發(fā)散鸳劳。以互聯(lián)網(wǎng)廣告為例，在對廣告進行采樣時也搓，新廣告的增長和老廣告的下線速度很快赏廓，時間線就很有可能時高度發(fā)散的。
3. 主鍵和schema修改傍妒。前面例子中提到的Tag幔摸，可以對應數(shù)據(jù)庫的schema，在實際業(yè)務中可能會頻繁改動〔罚現(xiàn)在一般的時序數(shù)據(jù)庫中既忆，主鍵是會默認生成的，即所有tag的組合嗦玖。因此患雇，在新增tag時，主鍵就會改變踏揣，則變?yōu)榱肆硪粋€對象庆亡。
4. 分布式系統(tǒng)和片鍵。由于數(shù)據(jù)量很大捞稿，因此需要對數(shù)據(jù)進行分片又谋，片鍵的選擇也是一個難以抉擇的問題。
5. 數(shù)據(jù)類型娱局。以剛才提到的單值模型為例彰亥。假設有一個三維的加速度傳感器，同一時間點上會產(chǎn)生三個關聯(lián)的數(shù)據(jù)衰齐，這時的數(shù)據(jù)類型就應該是一個維度為3的矢量任斋，即一個新的數(shù)據(jù)類型。
6. 需要對每個數(shù)據(jù)點的值做過濾耻涛。假設每輛車上都裝有GPS傳感器废酷，假設要統(tǒng)計某一時間段內瘟檩，一公里內，出現(xiàn)了哪些車輛澈蟆，分別由哪些廠商生產(chǎn)墨辛。此時需要對地理位置進行過濾。
下圖是過去提出利用HiTSDB對時序問題的解決方案趴俘。在這種方案中睹簇，未解決發(fā)散問題，較高維數(shù)據(jù)和值過濾問題寥闪。用倒排索引來存儲設備信息太惠，并把時間點上的數(shù)據(jù)存在高壓縮比緩存中。這兩者結合疲憋，實際上將邏輯上的一個表分成了兩個表凿渊，用以解決多維度查詢和聚合的問題。但使用這種方案依然有很多問題無法解決柜某。
下面是HiTSDB的一些優(yōu)勢和不足：
1. 優(yōu)勢：
倒排索引可以很方便的篩選設備嗽元；
高壓縮比緩存具有很高的寫入和讀取能力
方便的時間切片
無schema，靈活方便支持各種數(shù)據(jù)模型
2.???不足：
在非定時采樣場景下可能導致數(shù)據(jù)稀疏
值沒有索引喂击，因此值過濾只能線性過濾
Schema改動導致時間線變動
廣播查限制了QPS
在此基礎上，進行了演進淤翔，如下圖翰绊。
1. 引入了Adaptive schema，即如果未指定一個數(shù)據(jù)表的schema旁壮，則認為寫入的第一條數(shù)據(jù)中包含的TagKV即是片鍵也是主鍵监嗜，用以確定唯一性以及數(shù)據(jù)會被分片到哪一個節(jié)點上。
2. 壓縮塊也不再是按固定的時間切片了抡谐，引入了meta index裁奇，用以查詢每個數(shù)據(jù)塊的開始和結束時間。在一個時間段內攢夠了足夠的數(shù)據(jù)后麦撵，把整個數(shù)據(jù)塊進行壓縮刽肠。
3. 參考列存的思路，值索引到壓縮塊免胃。值索引不再像傳統(tǒng)數(shù)據(jù)庫那樣索引到行音五。
4. 多值索引和空間切分。
三羔沙，時序數(shù)據(jù)庫的時序算法
上面所述的存儲結構主要是為了方便進行時序數(shù)據(jù)的加工和分析躺涝。時序有一些特殊算法。
1.?????降采樣和插值：傳感器采樣出的點可能特別密集扼雏，在分析趨勢時坚嗜，會希望進行過濾夯膀。通過降采樣可以利用一段時間內的最小值/最大值/平均值來替代。
降采樣算法：min/max/avg苍蔬。
插值算法：補零/線性/貝塞爾曲線
2.?????聚合計算：由于采樣是精確到每個傳感器的棍郎，但有時需要的數(shù)據(jù)并不僅是精確到某個傳感器的。比如银室，希望比較兩個不同廠商的發(fā)電機涂佃，哪個在風場中產(chǎn)生了更多的電。那么就需要對傳感器數(shù)據(jù)進行聚合蜈敢。
邏輯聚合：min/max
算術聚合：sum/count/avg
統(tǒng)計：histogram/percentile/Standard Deviation
3.?????時間軸計算
變化率：rate
對時序數(shù)據(jù)進行加工的分析的重要目的是發(fā)現(xiàn)異常辜荠。下面介紹在異常檢測中如何定義問題。從異常檢測的角度來看時間序列數(shù)據(jù)抓狭，分為三個維度：time, object, metric伯病。
1.?????固定兩個維度，只考慮一個維度的數(shù)據(jù)否过。
·T: only consider time dim午笛，單一對象單一metric即單個時間序列）：spikes & dips、趨勢變化苗桂、范圍變化药磺。
·M: only consider metric，找出不符合metric之間相互關系的數(shù)據(jù)煤伟。
·O: only consider object癌佩，找出與眾不同的對象。
2.?????固定一個維度便锨，只考慮兩個維度的數(shù)據(jù)围辙。
·MT：固定對象，考慮多個時間序列（每個對應一個metric)放案，并找出其相互變化方式不同的作為異常姚建。
·MO：不考慮時間特性，考慮多個對象且每個對象都可以用多個metric表示吱殉，如何從中找出不同的對象掸冤。
·TO：多個對象單一metric，找出變化趨勢不同的對象考婴。
在異常檢測中贩虾，面向問題有如下計算方法：
1.?????內置函數(shù)
·高壓縮比緩存直接作為窗口緩存
·對于滿足數(shù)據(jù)局部性的問題，直接在高壓縮比緩存上運行
·結果直接寫回
·定時調度 vs 數(shù)據(jù)觸發(fā)
2.?????外置計算
·定時查詢 vs 流式讀取
·使用同樣的查詢語言執(zhí)行查詢或定義數(shù)據(jù)源
·數(shù)據(jù)庫內置時間窗口
·數(shù)據(jù)流的觸發(fā)機制
針對時序數(shù)據(jù)沥阱，又可以將計算分為預計算和后計算缎罢。
預計算:事先將結果計算完并存儲。這是流計算中常用的方式。其特點如下：
·數(shù)據(jù)存儲量低
·查詢性能高
·需要手工編寫計算過程
·新的計算無法立即查看結果
·靈活性差
·不保存原始數(shù)據(jù)
后計算：先存數(shù)據(jù)策精，需要時進行計算舰始。這是數(shù)據(jù)庫中常用的方式。其特點如下：
·數(shù)據(jù)存儲量大
·查詢/聚合性能瓶頸
·任何查詢都可以隨時獲得結果
·使用DSL進行查詢
·靈活性好
·保存原始數(shù)據(jù)
四咽袜，時序數(shù)據(jù)庫的計算引擎
基于兩種計算的特點丸卷，在時序數(shù)據(jù)處理中，我們使用的是一種混合架構询刹。有數(shù)據(jù)進來時谜嫉，有預聚合規(guī)則，如果符合規(guī)則就進行預聚合凹联，把數(shù)據(jù)寫入數(shù)據(jù)庫中沐兰。在查詢時，如果符合預聚合規(guī)則蔽挠，就可以很快得到結果住闯。對于不滿足預聚合規(guī)則的數(shù)據(jù)，會將其從數(shù)據(jù)庫中讀出澳淑，進行后聚合比原。中間的聚合引擎是一種類似流式計算的架構，數(shù)據(jù)庫或者數(shù)據(jù)源都可以作為數(shù)據(jù)源杠巡。數(shù)據(jù)源的來源對于引擎是不可見的量窘，它的功能是接收數(shù)據(jù)，計算并產(chǎn)生結果忽孽。因此绑改，預計算和后計算都可以利用這一種邏輯進行，并放在同一個運行環(huán)境中兄一。
在邏輯上，上圖是可行的识腿。但實際上出革，如果要用這種方式進行流計算，由于數(shù)據(jù)源可能出現(xiàn)亂序等問題渡讼，就必須要利用窗口函數(shù)骂束，將數(shù)據(jù)放入時間窗口中整理好，但這種緩存的效率其實并不高成箫，實際情況下展箱，是按照下圖這種邏輯進行的。數(shù)據(jù)會被寫進數(shù)據(jù)庫蹬昌，由于數(shù)據(jù)庫有高壓縮比緩存混驰，是專門針對時序數(shù)據(jù)的。當一個時間窗口結束時，利用持續(xù)查詢來進行預計算栖榨。它會將高壓縮比緩存中的數(shù)據(jù)拿一部分出來做預聚合再寫回數(shù)據(jù)庫中昆汹。這樣，這個緩存機制就替代了原來的時間窗口婴栽，節(jié)省了很多內存满粗，降低了很多計算開銷。
使用類似于流的架構的好處是可以將其很快的接入異構計算的環(huán)境中愚争。正如大家熟知的映皆，流計算可以轉化為一個DAG。結合前面提到的降采樣和聚合的例子轰枝。以一個加法為例捅彻，可以把數(shù)據(jù)切成三片放入不同的工作節(jié)點上計算，計算完后再進行一次聚合輸出數(shù)據(jù)狸膏。工作節(jié)點既可能是CPU也可能是GPU沟饥。接入異構計算的環(huán)境中，可以加速數(shù)據(jù)的計算湾戳。
五贤旷，時序數(shù)據(jù)庫展望
下圖是對未來架構的展望。
1.?????存儲層
·類似lambda架構砾脑，基于一系列不可修改的文件
·針對不同的場景提供不同的存儲格式
2.?????計算層
·流式架構幼驶，基于內存的異構計算，自動填充熱數(shù)據(jù)
·數(shù)據(jù)分片韧衣，支持高QPS讀取
3.?????索引
·全局的索引 vs 文件局部索引
4.?????大數(shù)據(jù)
·可以直接在大量的文件上跑MR盅藻，也可以通過高壓縮比緩存以流的方式訂閱數(shù)據(jù)
未來，這個數(shù)據(jù)庫將會演化成時序數(shù)據(jù)平臺畅铭。它可以兼容SQL生態(tài)氏淑，一系列大數(shù)據(jù)平臺，以及融合邊緣計算硕噩。在部署時可以在云和邊緣部署一整套的管理架構假残，同時把用SQL描述的規(guī)則下放到云板和邊緣板上，形成一整套數(shù)據(jù)處理方案炉擅。
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
云數(shù)據(jù)庫RDS PPAS 版 :https://www.aliyun.com/product/rds/ppas?spm=5176.54432.765261.351.6e1e28f5UFqADw
