[[226527]]

背景

HiTSDB時(shí)序數(shù)據(jù)庫(kù)引擎在服務(wù)于阿里巴巴集團(tuán)內(nèi)的客戶(hù)時(shí)，根據(jù)集團(tuán)業(yè)務(wù)特性做了很多針對(duì)性的優(yōu)化。 然而在HiTSDB云產(chǎn)品的打磨過(guò)程中逐漸發(fā)現(xiàn)，很多針對(duì)性的優(yōu)化很難在公有云上針對(duì)特定用戶(hù)去實(shí)施。

于此同時(shí)， 在公有云客戶(hù)使用HiTSDB的過(guò)程中，發(fā)現(xiàn)了越來(lái)越多由于聚合查詢(xún)導(dǎo)致的問(wèn)題，比如： 返回?cái)?shù)據(jù)點(diǎn)過(guò)多會(huì)出現(xiàn)棧溢出等錯(cuò)誤，聚合點(diǎn)過(guò)多導(dǎo)致OOM， 或者無(wú)法完成聚合，實(shí)例完全卡死等等問(wèn)題。這些問(wèn)題主要由于原始的聚合引擎架構(gòu)上的缺陷導(dǎo)致。

因此HiTSDB開(kāi)發(fā)團(tuán)隊(duì)評(píng)估后決定圍繞新的聚合引擎架構(gòu)對(duì)HiTSDB引擎進(jìn)行升級(jí)，包含： 存儲(chǔ)模型的改造，索引方式的升級(jí)，實(shí)現(xiàn)全新的流式聚合，數(shù)據(jù)遷移，性能評(píng)測(cè)。 本文主要圍繞這5個(gè)方面進(jìn)行梳理，重點(diǎn)在“全新的流式聚合部分”。

1. 時(shí)序數(shù)據(jù)存儲(chǔ)模型：

1.1 時(shí)序的數(shù)據(jù)存儲(chǔ)格式。

一個(gè)典型的時(shí)序數(shù)據(jù)由兩個(gè)維度來(lái)表示，一個(gè)維度表示時(shí)間軸，隨著時(shí)間的不斷流入，數(shù)據(jù)會(huì)不斷地追加。 另外一個(gè)維度是時(shí)間線(xiàn)，由指標(biāo)和數(shù)據(jù)源組成，數(shù)據(jù)源就是由一系列的標(biāo)簽標(biāo)示的唯一數(shù)據(jù)采集點(diǎn)。例如指標(biāo)cpu.usage的數(shù)據(jù)來(lái)自于機(jī)房，應(yīng)用，實(shí)例等維度組合成的采集點(diǎn)。 這樣大家邏輯上就可以抽象出來(lái)一個(gè)id+{timestamp, value}的時(shí)序數(shù)據(jù)模型。這種數(shù)據(jù)模型的存儲(chǔ)是如何呢。一般有兩種典型的數(shù)據(jù)存儲(chǔ)思路：

• 一種按照時(shí)間窗口維度劃分?jǐn)?shù)據(jù)塊，同一段自然時(shí)間窗口內(nèi)的連續(xù)數(shù)據(jù)放到相鄰的位置，比如{1:00, 2:00}->(id1, id2, id3, ... ... ,idN)。 采用這種方式的典型時(shí)序數(shù)據(jù)庫(kù)包含InfluxDB, Promethues等等TSMT結(jié)構(gòu)的數(shù)據(jù)庫(kù)。OpenTSDB有些特殊，因?yàn)镺penTSDB是單值模型，指標(biāo)這個(gè)維度在查詢(xún)的時(shí)候是必帶的。 所以可以先按照指標(biāo)做了一級(jí)劃分，再根據(jù)時(shí)間窗口做二級(jí)的劃分，本質(zhì)上還是同一時(shí)間窗口內(nèi)的連續(xù)數(shù)據(jù)。 按照時(shí)間窗口切分的方式，優(yōu)勢(shì)是寫(xiě)入的時(shí)候可以很天然的按照窗口去落盤(pán)，對(duì)于高緯度的標(biāo)簽查詢(xún)基本上是一些連續(xù)Scan. 這種方式有個(gè)比較難解的問(wèn)題就是"out of order"亂序問(wèn)題，對(duì)于時(shí)間窗口過(guò)期后再來(lái)的時(shí)間點(diǎn)，Promethues直接采用丟棄的方式，InfluxDB在這種情況下性能會(huì)有損耗。
• 另外一種按照時(shí)間線(xiàn)維度劃分?jǐn)?shù)據(jù)塊，同一時(shí)間線(xiàn)的數(shù)據(jù)放到相鄰的位置，比如(id1)->(1:00, 2:00, 3:00, ... ... , 23:00)。 HiTSDB采用時(shí)間線(xiàn)維度劃分的方式：目前落盤(pán)數(shù)據(jù)存儲(chǔ)于HBASE，底層Rowkey由指標(biāo)+標(biāo)簽+自然窗口的方式組合而成. Rowkey按照大小順序合并某個(gè)時(shí)間線(xiàn)的數(shù)據(jù)點(diǎn)是連續(xù)相鄰的。 因此對(duì)于一些低維的查詢(xún)效率是非常高效的。根據(jù)目前接觸的一些物聯(lián)網(wǎng)服務(wù)，更多的是一些低維的訪(fǎng)問(wèn)。對(duì)于中等維度的查詢(xún)采用流式scan。對(duì)于極高緯度標(biāo)簽的查詢(xún)HiTSDB采用預(yù)聚合的服務(wù)(不在本文討論范圍內(nèi))。

1.2 時(shí)序模型的熱點(diǎn)問(wèn)題處理

生產(chǎn)環(huán)境中業(yè)務(wù)方采集的指標(biāo)類(lèi)型多種多樣，對(duì)指標(biāo)的采集周期各不相同。比如cpu.usage這個(gè)指標(biāo)的變化頻率比較快，業(yè)務(wù)方關(guān)注度高，采集周期通常很短，1秒，5秒，10秒等等。 然而指標(biāo)disk.usage這個(gè)指標(biāo)變化趨勢(shì)相對(duì)平滑，采集周期通常為1分鐘，5分鐘， 10分鐘等。這種情況下，數(shù)據(jù)的存儲(chǔ)如果針對(duì)同一個(gè)指標(biāo)不做特殊處理，容易形成熱點(diǎn)問(wèn)題。 假設(shè)按照指標(biāo)類(lèi)型進(jìn)行存儲(chǔ)資源的分片，想象一下如果有20個(gè)業(yè)務(wù)，每個(gè)業(yè)務(wù)10個(gè)集群，每個(gè)集群500臺(tái)主機(jī)，采集周期是1秒的話(huà)，每秒就會(huì)有10萬(wàn)個(gè)cpu.usage的指標(biāo)數(shù)據(jù)點(diǎn)落到同一個(gè)存儲(chǔ)資源實(shí)例中， 而disk.usage采集周期為1分鐘，所以大約只有1666個(gè)指標(biāo)數(shù)據(jù)點(diǎn)落到另外一個(gè)存儲(chǔ)資源上，這樣數(shù)據(jù)傾斜的現(xiàn)象非常嚴(yán)重。

1.2.1 分桶

這類(lèi)問(wèn)題的經(jīng)典解法就是分桶。比如除了指標(biāo)類(lèi)型外，同時(shí)將業(yè)務(wù)名和主機(jī)名作為維度標(biāo)識(shí)tags，把指標(biāo)cpu.usage劃分到不同的桶里面。 寫(xiě)入時(shí)根據(jù)時(shí)間線(xiàn)哈希值分散寫(xiě)入到不同的桶里面。 OpenTSDB在處理熱點(diǎn)問(wèn)題也是采用了分桶模式，但是需要廣播讀取，根本原因在于查詢(xún)方式需要在某個(gè)時(shí)間窗口內(nèi)的全局掃描。 所以設(shè)置OpenTSDB的分桶數(shù)量需要一個(gè)平衡策略，如果數(shù)量太少，熱點(diǎn)還是有局部性的問(wèn)題，如果太多，查詢(xún)時(shí)廣播讀帶來(lái)的開(kāi)銷(xiāo)會(huì)非常大。 

與其相比較，HiTSDB避免了廣播讀，提高了查詢(xún)效率。由于HiTSDB在查詢(xún)時(shí)，下發(fā)到底層存儲(chǔ)掃描數(shù)據(jù)之前，首先會(huì)根據(jù)查詢(xún)語(yǔ)句得到精確命中的時(shí)間線(xiàn)。 有了具體的時(shí)間線(xiàn)就可以確定桶的位置，然后到相應(yīng)的塊區(qū)域取數(shù)據(jù)，不存在廣播讀。 關(guān)于HiTSDB如何在查詢(xún)數(shù)據(jù)的時(shí)候獲取命中的時(shí)間線(xiàn)，相信讀者這個(gè)疑問(wèn)會(huì)在讀取完倒排這一節(jié)的時(shí)候消釋。

1.2.2 Region Pre-Split

當(dāng)一個(gè)表剛被創(chuàng)建的時(shí)候，HBase默認(rèn)分配一個(gè)Region給新表。所有的讀寫(xiě)請(qǐng)求都會(huì)訪(fǎng)問(wèn)到同一個(gè)regionServer的同一個(gè)region中。 此時(shí)集群中的其他regionServer會(huì)處于比較空閑的狀態(tài)，這個(gè)時(shí)候就達(dá)不到負(fù)載均衡的效果了。 解決這個(gè)問(wèn)題使用pre-split,在創(chuàng)建新表的時(shí)候根據(jù)分桶個(gè)數(shù)采用自定義的pre-split的算法，生成多個(gè)region。 byte[][] splitKeys =new byte[bucketNumber-1][]; splitKeys[bucketIndex-1] = (bucketIndex&0xFF);

2. 倒排索引：

2.1 時(shí)序數(shù)據(jù)中的多維時(shí)間線(xiàn)

多維支持對(duì)于任何新一代時(shí)序數(shù)據(jù)庫(kù)都是極其重要的。 時(shí)序數(shù)據(jù)的類(lèi)型多種多樣,來(lái)源更是非常復(fù)雜,不止有單一維度上基于時(shí)間的有序數(shù)值，還有多維時(shí)間線(xiàn)相關(guān)的大量組合。 舉個(gè)簡(jiǎn)單例子，cpu的load可以有三個(gè)維度描述cpu core， host， app應(yīng)用，每個(gè)維度可以有百級(jí)別甚至萬(wàn)級(jí)別的標(biāo)簽值。 sys.cpu.load cpu=1 host=ipA app=hitsdb，各個(gè)維度組合后時(shí)間線(xiàn)可以輕松達(dá)到百萬(wàn)級(jí)別。 如何管理這些時(shí)間線(xiàn)，建立索引并且提供高效的查詢(xún)是時(shí)序數(shù)據(jù)庫(kù)里面需要解決的重要問(wèn)題。 目前時(shí)序領(lǐng)域比較主流的做法是采用倒排索引的方式。

2.2 倒排索引基本組合

基本的時(shí)間線(xiàn)在倒排中的組合思路如下：

時(shí)間線(xiàn)的原始輸入值：

倒排構(gòu)建后：

查詢(xún)時(shí)間線(xiàn) cpu=3 and host=ipB：

取交集后查詢(xún)結(jié)果為7：

2.3 倒排面臨的問(wèn)題以及優(yōu)化思路

倒排主要面臨的是內(nèi)存膨脹的問(wèn)題：

• posting list過(guò)長(zhǎng)， 對(duì)于高緯度的tag，比如“機(jī)房=杭州”，杭州可能會(huì)有千級(jí)別甚至萬(wàn)級(jí)別的機(jī)器，這就意味著posting list需要存儲(chǔ)成千上萬(wàn)個(gè)64-bit的id。 解決這個(gè)問(wèn)題的思路是采用壓縮posting list的方式， 在構(gòu)建posting list的時(shí)候?qū)?shù)組里面的id進(jìn)行排序，然后采用delta編碼的方式壓縮。
• 如果Tag鍵值對(duì)直接作為term使用，內(nèi)存占用取決于字符串的大小，采用字符串字典化，也可大大減少內(nèi)存開(kāi)銷(xiāo)。

3. 流式聚合引擎

3.1 HiTSDB聚合引擎的技術(shù)痛點(diǎn)

HiTSDB現(xiàn)有聚合引擎公有云公測(cè)以及集體內(nèi)部業(yè)務(wù)運(yùn)行中，暴露發(fā)現(xiàn)了以下問(wèn)題：

3.1.1 Materialization執(zhí)行模式造成Heap內(nèi)存易打爆

下圖顯示了原查詢(xún)引擎的架構(gòu)圖。HiTSDB以HBase作為存儲(chǔ)，原引擎通過(guò)Async HBase client 從HBase獲取時(shí)序數(shù)據(jù)。由于HBase的數(shù)據(jù)讀取是一個(gè)耗時(shí)的過(guò)程，通常的解法是采用異步HBase client的API，從而有效提高系統(tǒng)的并行性。但原聚合引擎采用了一種典型的materialization的執(zhí)行方式：1）啟動(dòng)多個(gè)異步HBase API啟HBase讀，2）只有當(dāng)查詢(xún)所涉及的全部時(shí)序數(shù)據(jù)讀入到內(nèi)存中后，聚合運(yùn)算才開(kāi)始啟動(dòng)。這種把HBase Scan結(jié)果先在內(nèi)存中materialized再聚合的方式使得HiTSDB容易發(fā)生Heap內(nèi)存打爆的現(xiàn)象。尤其當(dāng)用戶(hù)進(jìn)行大時(shí)間范圍查詢(xún)，或者查詢(xún)的時(shí)間線(xiàn)的數(shù)據(jù)非常多的時(shí)候，因?yàn)樯婕暗臅r(shí)序數(shù)據(jù)多，HiTSDB會(huì)發(fā)生Heap OOM而導(dǎo)致查詢(xún)失敗。

3.1.2 大查詢(xún)打爆HBase的問(wèn)題

兩個(gè)原因造成HiTSDB處理聚合查詢(xún)的時(shí)候，容易發(fā)生將底層HBase打爆。

• HBase 可能讀取多余時(shí)間線(xiàn)數(shù)據(jù)。HiTSDB的時(shí)間線(xiàn)采用指標(biāo)+時(shí)間窗口+標(biāo)簽的編碼方式存儲(chǔ)在HBase。典型的查詢(xún)是用戶(hù)指定一個(gè)指標(biāo)，時(shí)間范圍，以及空間維度上標(biāo)簽要尋找的匹配值?？臻g維度的標(biāo)簽查詢(xún)條件并不都是在標(biāo)簽編碼前綴。當(dāng)這種情況發(fā)生時(shí)，HiTSDB倒排索引不能根據(jù)空間維度的查詢(xún)條件，精確定位到具體的HBase的查詢(xún)條件，而是采用先讀取再過(guò)濾的方式。這意味著HBase有可能讀取很多冗余數(shù)據(jù)，從而加重HBase的負(fù)載。
• HiTSDB有可能在短時(shí)間內(nèi)下發(fā)太多HBase讀請(qǐng)求。一方面，HiTSDB在HBase采用分片存儲(chǔ)方式，對(duì)每一個(gè)分片，都至少啟動(dòng)一個(gè)讀請(qǐng)求，另一方面，因?yàn)樯厦嫣岬降膍aterialization的執(zhí)行方式，一個(gè)查詢(xún)涉及到的HBase讀請(qǐng)求同時(shí)異步提交，有可能在很短時(shí)間內(nèi)向HBase下發(fā)大量的讀請(qǐng)求。這樣，一個(gè)大查詢(xún)就有可能把底層的HBase打爆。

當(dāng)這種情況發(fā)生時(shí)，更糟糕的場(chǎng)景是HiTSDB無(wú)法處理時(shí)序數(shù)據(jù)的寫(xiě)入請(qǐng)求，造成后續(xù)新數(shù)據(jù)的丟失。

3.1.3 執(zhí)行架構(gòu)高度耦合，修改或增加功能困難

聚合引擎主要針對(duì)應(yīng)用場(chǎng)景是性能監(jiān)控，查詢(xún)模式固定，所以引擎架構(gòu)采用單一模式，把查詢(xún)，過(guò)濾，填值/插值，和聚合運(yùn)算的邏輯高度耦合在一起。這種引擎架構(gòu)對(duì)于監(jiān)控應(yīng)用的固定查詢(xún)沒(méi)有太多問(wèn)題，但HiTSDB目標(biāo)不僅僅是監(jiān)控場(chǎng)景下的簡(jiǎn)單查詢(xún)，而是著眼于更多應(yīng)用場(chǎng)景下的復(fù)雜查詢(xún)。

我們發(fā)現(xiàn)采用原有引擎的架構(gòu)，很難在原有基礎(chǔ)上進(jìn)行增加功能，或修改原來(lái)的實(shí)現(xiàn)。本質(zhì)上的原因在于原有聚合引擎沒(méi)有采用傳統(tǒng)數(shù)據(jù)庫(kù)所通常采用的執(zhí)行架構(gòu)，執(zhí)行層由可定制的多個(gè)執(zhí)行算子組成，查詢(xún)語(yǔ)義可以由不同的執(zhí)行算子組合而完成。這個(gè)問(wèn)題在產(chǎn)品開(kāi)發(fā)開(kāi)始階段并不感受很深，但確是嚴(yán)重影響HiTSDB拓寬應(yīng)用場(chǎng)景，增加新功能的一個(gè)重要因素。

3.1.4 聚合運(yùn)算效率有待提高

原有引擎在執(zhí)行聚合運(yùn)算的時(shí)候，也和傳統(tǒng)數(shù)據(jù)庫(kù)所通常采用的iterative執(zhí)行模式一樣，迭代執(zhí)行聚合運(yùn)算。問(wèn)題在于每次iteration執(zhí)行，返回的是一個(gè)時(shí)間點(diǎn)。Iterative 執(zhí)行每次返回一條時(shí)間點(diǎn)，或者一條記錄，常見(jiàn)于OLTP這樣的場(chǎng)景，因?yàn)镺LTP的查詢(xún)所需要訪(fǎng)問(wèn)的記錄數(shù)很小。但對(duì)HiTSDB查詢(xún)有可能需要訪(fǎng)問(wèn)大量時(shí)間線(xiàn)數(shù)據(jù)，這樣的執(zhí)行方式效率上并不可取。

原因1）每次處理一個(gè)時(shí)間點(diǎn)，都需要一系列的函數(shù)調(diào)用，性能上有影響，2）iterative循環(huán)迭代所涉及到的函數(shù)調(diào)用，無(wú)法利用新硬件所支持的SIMD并行執(zhí)行優(yōu)化，也無(wú)法將函數(shù)代碼通過(guò)inline等JVM常用的hotspot的優(yōu)化方式。在大數(shù)據(jù)量的場(chǎng)景下，目前流行的通用做法是引入Vectorization processing, 也就是每次iteration返回的不再是一條記錄，而是一個(gè)記錄集(batch of rows)，比如Google Spanner 用batch-at-a-time 代替了row-at-a-time, Spark SQL同樣也在其執(zhí)行層采用了Vectorization的執(zhí)行模式。

3.2 流式聚合引擎設(shè)計(jì)思路

針對(duì)HiTSDB原有聚合運(yùn)算引擎上的問(wèn)題，為了優(yōu)化HiTSDB,支持HiTSDB商業(yè)化運(yùn)營(yíng)，我們決定改造HiTSDB聚合運(yùn)算引擎。下圖給出了新聚合查詢(xún)引擎的基本架構(gòu)。

3.2.1 pipeline執(zhí)行模式

借鑒傳統(tǒng)數(shù)據(jù)庫(kù)執(zhí)行模式，引入pipeline的執(zhí)行模式（aka Volcano / Iterator 執(zhí)行模式）。Pipeline包含不同的執(zhí)行計(jì)算算子(operator), 一個(gè)查詢(xún)被物理計(jì)劃生成器解析分解成一個(gè)DAG或者operator tree， 由不同的執(zhí)行算子組成，DAG上的root operator負(fù)責(zé)驅(qū)動(dòng)查詢(xún)的執(zhí)行，并將查詢(xún)結(jié)果返回調(diào)用者。在執(zhí)行層面，采用的是top-down需求驅(qū)動(dòng) (demand-driven)的方式，從root operator驅(qū)動(dòng)下面operator的執(zhí)行。這樣的執(zhí)行引擎架構(gòu)具有優(yōu)點(diǎn)：

• 這種架構(gòu)方式被很多數(shù)據(jù)庫(kù)系統(tǒng)采用并證明是有效;
• 接口定義清晰，不同的執(zhí)行計(jì)算算子可以獨(dú)立優(yōu)化，而不影響其他算子;
• 易于擴(kuò)展：通過(guò)增加新的計(jì)算算子，很容易實(shí)現(xiàn)擴(kuò)展功能。比如目前查詢(xún)協(xié)議里只定義了tag上的查詢(xún)條件。如果要支持指標(biāo)值上的查詢(xún)條件(cpu.usage >= 70% and cpu.usage <=90%),可以通過(guò)增加一個(gè)新的FieldFilterOp來(lái)實(shí)現(xiàn)。

每個(gè)operator,實(shí)現(xiàn)如下接口：

• Open : 初始化并設(shè)置資源
• Next : 調(diào)用輸入operator的next()獲得一個(gè)batch of time series, 處理輸入，輸出batch of time series
• Close : 關(guān)閉并釋放資源

我們?cè)贖iTSDB中實(shí)現(xiàn)了以下算子：

• ScanOp: 用于從HBase異步讀取時(shí)間線(xiàn)數(shù)據(jù)
• DsAggOp: 用于進(jìn)行降采樣計(jì)算，并處理填值
• AggOp：用于進(jìn)行分組聚合運(yùn)算，分成PipeAggOp, MTAggOp
• RateOp: 用于計(jì)算時(shí)間線(xiàn)值的變化率

3.2.2 執(zhí)行計(jì)算算子一個(gè)batch的時(shí)間線(xiàn)數(shù)據(jù)為運(yùn)算單位

在計(jì)算算子之間以一個(gè)batch的時(shí)間線(xiàn)數(shù)據(jù)為單位，提高計(jì)算引擎的執(zhí)行性能。其思想借鑒于OLAP系統(tǒng)所采用的Vectorization的處理模式。這樣Operator在處理一個(gè)batch的多條時(shí)間線(xiàn)，以及每條時(shí)間線(xiàn)的多個(gè)時(shí)間點(diǎn)，能夠減少函數(shù)調(diào)用的代價(jià)，提高loop的執(zhí)行效率。

每個(gè)Operator以流式線(xiàn)的方式，從輸入獲得時(shí)間線(xiàn)batch, 經(jīng)過(guò)處理再輸出時(shí)間線(xiàn)batch, 不用存儲(chǔ)輸入的時(shí)間線(xiàn)batch，從而降低對(duì)內(nèi)存的要求。只有當(dāng)Operator的語(yǔ)義要求必須將輸入materialize，才進(jìn)行這樣的操作（參見(jiàn)下面提到的聚合算子的不同實(shí)現(xiàn)）。

3.2.3. 區(qū)分不同查詢(xún)場(chǎng)景，采用不同聚合算子分別優(yōu)化

HiTSDB原來(lái)的聚合引擎采用materialization的執(zhí)行模式，很重要的一個(gè)原因在于處理時(shí)序數(shù)據(jù)的插值運(yùn)算，這主要是因?yàn)闀r(shí)序數(shù)據(jù)的一個(gè)典型特點(diǎn)是時(shí)間線(xiàn)上不對(duì)齊：不同的時(shí)間線(xiàn)在不同的時(shí)間戳上有數(shù)據(jù)。HiTSDB兼容OpenTSDB的協(xié)議，引入了插值(interpolation)的概念，目的在于聚合運(yùn)算時(shí)通過(guò)指定的插值方式，在不對(duì)齊的時(shí)間戳上插入計(jì)算出來(lái)的值，從而將不對(duì)齊的時(shí)間線(xiàn)數(shù)據(jù)轉(zhuǎn)換成對(duì)齊的時(shí)間線(xiàn)。插值是在同一個(gè)group的所有時(shí)間線(xiàn)之間比較，來(lái)決定在哪個(gè)時(shí)間戳上需要進(jìn)行插值 （參見(jiàn)OpenTSDB 文檔）。

為了優(yōu)化聚合查詢(xún)的性能，我們引入了不同的聚合運(yùn)算算子。目的在于針對(duì)不同的查詢(xún)的語(yǔ)義，進(jìn)行不同的優(yōu)化。有些聚合查詢(xún)需要插值，而有些查詢(xún)并不要求插值；即使需要插值，只需要把同一聚合組的時(shí)間線(xiàn)數(shù)據(jù)讀入內(nèi)存，就可以進(jìn)行插值運(yùn)算。

• PipeAggOp: 當(dāng)聚合查詢(xún)滿(mǎn)足以下條件時(shí)，

1）不需要插值： 查詢(xún)使用了降采樣(downsample),并且降采樣的填值采用了非null/NaN的策略。這樣的查詢(xún)，經(jīng)過(guò)降采樣后，時(shí)間線(xiàn)的數(shù)據(jù)都是對(duì)齊補(bǔ)齊的，也就是聚合函數(shù)所用到的插值不再需要。

2）聚合函數(shù)可以支持漸進(jìn)式迭代計(jì)算模式 (Incremental iterative aggregation), 比如sum, count ,avg, min, max, zerosum, mimmim, mimmax，我們可以采用incremental聚合的方式，而不需要把全部輸入數(shù)據(jù)讀入內(nèi)存。這個(gè)執(zhí)行算子采用了流水線(xiàn)的方式，每次從輸入的operator獲得一系列時(shí)間線(xiàn)，計(jì)算分組并更新聚合函數(shù)的部分值，完成后可以清理輸入的時(shí)間線(xiàn)，其自身只用保留每個(gè)分組的聚合函數(shù)的值。

• MTAgOp: 需要插值，并且輸入算子無(wú)法幫助將時(shí)間線(xiàn)ID預(yù)先分組，這種方式回退到原來(lái)聚合引擎所采用的執(zhí)行模式。

對(duì)于MTAggOp, 我們可以引入分組聚合的方法進(jìn)行優(yōu)化：

• GroupedAggOp: 需要插值，但是輸入算子能夠保證已經(jīng)將時(shí)間線(xiàn)的ID根據(jù)標(biāo)識(shí)(tags)進(jìn)行排序分組，這樣在流水線(xiàn)處理中，只要materialize最多一個(gè)組的數(shù)據(jù)，這樣的算子比起內(nèi)存保留所有分組時(shí)間線(xiàn)，內(nèi)存要求要低，同時(shí)支持不同組之間的并行聚合運(yùn)算。

3.2.4 查詢(xún)優(yōu)化器和執(zhí)行器

引入執(zhí)行算子和pipeline執(zhí)行模式后，我們可以在HiTSDB分成兩大模塊，查詢(xún)優(yōu)化器和執(zhí)行器。優(yōu)化器根據(jù)查詢(xún)語(yǔ)義和執(zhí)行算子的不同特點(diǎn)，產(chǎn)生不同的執(zhí)行計(jì)劃，優(yōu)化查詢(xún)處理。例如HiTSDB可以利用上面討論的三個(gè)聚合運(yùn)算算子，在不同的場(chǎng)景下，使用不同的執(zhí)行算子，以降低查詢(xún)執(zhí)行時(shí)的內(nèi)存開(kāi)銷(xiāo)和提高執(zhí)行效率為目的。這樣的處理方式相比于原來(lái)聚合引擎單一的執(zhí)行模式，更加優(yōu)化。

4. 數(shù)據(jù)遷移

HiTSDB新的聚合引擎采用的底層存儲(chǔ)格式與以前的版本并不兼容。 公有云公測(cè)期間運(yùn)行在舊版本實(shí)例的數(shù)據(jù)，需要遷移至新的聚合引擎。 同時(shí)熱升級(jí)出現(xiàn)了問(wèn)題，數(shù)據(jù)遷移還應(yīng)回滾功能，將新版本的數(shù)據(jù)點(diǎn)轉(zhuǎn)換成舊的數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)版本回滾。 整體方案對(duì)于用戶(hù)的影響做到：寫(xiě)入無(wú)感知，升級(jí)過(guò)程中，歷史數(shù)據(jù)不可讀。

4.1 數(shù)據(jù)遷移架構(gòu)

• 并發(fā)轉(zhuǎn)換和遷移數(shù)據(jù): 原有的HiTSDB數(shù)據(jù)點(diǎn)已經(jīng)在寫(xiě)入的時(shí)候進(jìn)行了分片。默認(rèn)有20個(gè)Salts。數(shù)據(jù)遷移工具會(huì)對(duì)每個(gè)Salt的數(shù)據(jù)點(diǎn)進(jìn)行并發(fā)處理。 每個(gè)“Salt”都有一個(gè)Producer和一個(gè)Consumer。Producer負(fù)責(zé)開(kāi)啟HBase Scanner獲取數(shù)據(jù)點(diǎn)。 每個(gè)Scanner異步對(duì)HBase進(jìn)行掃描，每次獲取HBASE_MAX_SCAN_SIZE行數(shù)的數(shù)據(jù)點(diǎn)。然后將HBase的Row Key轉(zhuǎn)換成新的結(jié)構(gòu)。

最后將該Row放到所有的一個(gè)Queue上等待Consumer消費(fèi)。 Consumer每次會(huì)處理HBASE_PUT_BATCHSIZE或者HBASE_PUT_MIN_DATAPOINTS的數(shù)據(jù)量。 每次Consumer順利寫(xiě)入該Batch的時(shí)候，我們會(huì)在UID表中記錄對(duì)應(yīng)“Salt”的數(shù)據(jù)處理位置。 這樣便于故障重啟時(shí)Producer從最后一次成功的地方重新開(kāi)始獲取數(shù)據(jù)點(diǎn)進(jìn)行轉(zhuǎn)換。 數(shù)據(jù)遷移工具對(duì)HBase的操作都采用異步的讀寫(xiě)。當(dāng)掃描數(shù)據(jù)或者寫(xiě)入數(shù)據(jù)失敗的時(shí)候，我們會(huì)進(jìn)行有限制的嘗試。 如果超出嘗試次數(shù)，我們就終止該“Salt”的數(shù)據(jù)遷移工作，其他”Salt“的工作不受到任何影響。 當(dāng)下次工具自動(dòng)重啟時(shí)，我們會(huì)出現(xiàn)問(wèn)題的”Salt“數(shù)據(jù)繼續(xù)進(jìn)行遷移，直到所有數(shù)據(jù)全部順利轉(zhuǎn)換完成。

• 流控限制: 大部分情況下，Producer對(duì)HBase的掃描數(shù)據(jù)要快于Consumer對(duì)HBase的寫(xiě)入。 為了防止Queue的數(shù)據(jù)積壓對(duì)內(nèi)存造成壓力同時(shí)為了減少Producer掃描數(shù)據(jù)時(shí)對(duì)HBase的壓力，我們?cè)O(shè)置了流控。 當(dāng)Queue的大小達(dá)到HBASE_MAX_REQUEST_QUEUE_SIZE時(shí)候，Producer會(huì)暫時(shí)停止對(duì)HBase的數(shù)據(jù)掃描等待Consumer消費(fèi)。 當(dāng)Queue的大小減少到HBASE_RESUME_SCANNING_REQUEST_QUEUE_SIZE時(shí)候，Producer會(huì)重新恢復(fù)。
• Producer和Consumer進(jìn)程的退出

順利完成時(shí)候如何退出: 當(dāng)一切進(jìn)展順利時(shí)候，當(dāng)Producer完成數(shù)據(jù)掃描之后，會(huì)在Queue上放一個(gè)EOS（End of Scan），然后退出。 Consumer遇到EOS就會(huì)知道該Batch為最后一批，成功處理完該Batch之后就會(huì)自動(dòng)退出。

失敗后如何關(guān)閉: Consumer遇到問(wèn)題時(shí)：當(dāng)Consumer寫(xiě)入HBase失敗之后，consumer會(huì)設(shè)置一個(gè)Flag，然后退出線(xiàn)程。 每當(dāng)Producer準(zhǔn)備進(jìn)行下一個(gè)HBASE_MAX_SCAN_SIZE的掃描時(shí)候，他會(huì)先檢查該Flag。 如果被設(shè)置，他會(huì)知道對(duì)應(yīng)的Consumer線(xiàn)程已經(jīng)失敗并且退出。Producer也會(huì)停止掃描并且退出。 Producer遇到問(wèn)題時(shí)：當(dāng)Producer掃描數(shù)據(jù)失敗時(shí)，處理方式和順利完成時(shí)候類(lèi)似。都是通過(guò)往Queue上EOS來(lái)完成通知。 下次重啟時(shí)，Producer會(huì)從上次記錄的數(shù)據(jù)處理位置開(kāi)始重新掃描。

4.2 數(shù)據(jù)遷移的一致性

由于目前云上版本HiTSDB為雙節(jié)點(diǎn)，在結(jié)點(diǎn)升級(jí)結(jié)束后會(huì)自動(dòng)重啟HiTSDB。自動(dòng)啟動(dòng)腳本會(huì)自動(dòng)運(yùn)行數(shù)據(jù)遷移工具。 如果沒(méi)有任何預(yù)防措施，此時(shí)兩個(gè)HiTSDB節(jié)點(diǎn)會(huì)同時(shí)進(jìn)行數(shù)據(jù)遷移。雖然數(shù)據(jù)上不會(huì)造成任何丟失或者損壞， 但是會(huì)對(duì)HBase造成大量的寫(xiě)入和讀取壓力從而嚴(yán)重影響用戶(hù)的正常的寫(xiě)入和查詢(xún)性能。

為了防止這樣的事情發(fā)生，我們通過(guò)HBase的Zoo Keeper實(shí)現(xiàn)了類(lèi)似FileLock鎖，我們稱(chēng)為DataLock，的機(jī)制保證只有一個(gè)結(jié)點(diǎn)啟動(dòng)數(shù)據(jù)遷移進(jìn)程。 在數(shù)據(jù)遷移進(jìn)程啟動(dòng)時(shí)，他會(huì)通過(guò)類(lèi)似非阻塞的tryLock()的形式在Zoo Keeper的特定路徑創(chuàng)建一個(gè)暫時(shí)的節(jié)點(diǎn)。 如果成功創(chuàng)建節(jié)點(diǎn)則代表成果獲得DataLock。如果該節(jié)點(diǎn)已經(jīng)存在，即被另一個(gè)HiTSDB創(chuàng)建，我們會(huì)收到KeeperException。這樣代表未獲得鎖，馬上返回失敗。 如果未成功獲得DataLock，該節(jié)點(diǎn)上的數(shù)據(jù)遷移進(jìn)程就會(huì)自動(dòng)退出。成果獲得DataLock的節(jié)點(diǎn)則開(kāi)始進(jìn)行數(shù)據(jù)遷移。

4.3 數(shù)據(jù)遷移中的"執(zhí)行一次"

當(dāng)所有“Salt”的數(shù)據(jù)點(diǎn)全部順利完成遷移之后，我們會(huì)在HBase的舊表中插入一行新數(shù)據(jù)，data_conversion_completed。 此行代表了數(shù)據(jù)遷移工程全部順利完成。同時(shí)自動(dòng)腳本會(huì)每隔12個(gè)小時(shí)啟動(dòng)數(shù)據(jù)遷移工具，這樣是為了防止上次數(shù)據(jù)遷移沒(méi)有全部完成。 每次啟動(dòng)時(shí)，我們都會(huì)先檢查“data_conversion_completed”標(biāo)志。如果標(biāo)志存在，工具就會(huì)馬上退出。 此項(xiàng)操作只會(huì)進(jìn)行一次HBase的查詢(xún)，比正常的健康檢查成本還要低。所以周期性的啟動(dòng)數(shù)據(jù)遷移工具并不會(huì)對(duì)HiTSDB或者HBase產(chǎn)生影響。

4.4. 數(shù)據(jù)遷移的評(píng)測(cè)

效果：上線(xiàn)后無(wú)故障完成100+實(shí)例數(shù)據(jù)的遷移，熱升級(jí)。

5. 查詢(xún)性能評(píng)測(cè)

Case 1: 數(shù)據(jù)采集頻率5s, 查詢(xún)命中1000條，時(shí)間窗口3600s

總結(jié)： 新的查詢(xún)聚合引擎將查詢(xún)速度提高了10倍以上。

其他

本文介紹了高性能時(shí)間序列數(shù)據(jù)庫(kù)HiTSDB引擎在商業(yè)化運(yùn)營(yíng)之前進(jìn)行的優(yōu)化升級(jí)，目的是提高HiTSDB引擎的穩(wěn)定性，數(shù)據(jù)寫(xiě)入和查詢(xún)性能以及新功能的擴(kuò)展性。HiTSDB已經(jīng)在阿里云正式商業(yè)化運(yùn)營(yíng)，我們將根據(jù)用戶(hù)反饋，進(jìn)一步提高HiTSDB引擎，更好服務(wù)于HiTSDB的客戶(hù)。

【本文為51CTO專(zhuān)欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文