深度解讀！時序數(shù)據(jù)庫HiTSDB：分布式流式聚合引擎
背景
HiTSDB時序數(shù)據(jù)庫引擎在服務(wù)于阿里巴巴集團內(nèi)的客戶時，根據(jù)集團業(yè)務(wù)特性做了很多針對性的優(yōu)化。 然而在HiTSDB云產(chǎn)品的打磨過程中逐漸發(fā)現(xiàn)，很多針對性的優(yōu)化很難在公有云上針對特定用戶去實施。
于此同時， 在公有云客戶使用HiTSDB的過程中，發(fā)現(xiàn)了越來越多由于聚合查詢導(dǎo)致的問題，比如： 返回數(shù)據(jù)點過多會出現(xiàn)棧溢出等錯誤，聚合點過多導(dǎo)致OOM， 或者無法完成聚合，實例完全卡死等等問題。這些問題主要由于原始的聚合引擎架構(gòu)上的缺陷導(dǎo)致。
因此HiTSDB開發(fā)團隊評估后決定圍繞新的聚合引擎架構(gòu)對HiTSDB引擎進行升級，包含： 存儲模型的改造，索引方式的升級，實現(xiàn)全新的流式聚合，數(shù)據(jù)遷移，性能評測。 本文主要圍繞這5個方面進行梳理，重點在“全新的流式聚合部分”。
1. 時序數(shù)據(jù)存儲模型：
1.1 時序的數(shù)據(jù)存儲格式。
一個典型的時序數(shù)據(jù)由兩個維度來表示，一個維度表示時間軸，隨著時間的不斷流入，數(shù)據(jù)會不斷地追加。 另外一個維度是時間線，由指標和數(shù)據(jù)源組成，數(shù)據(jù)源就是由一系列的標簽標示的唯一數(shù)據(jù)采集點。例如指標cpu.usage的數(shù)據(jù)來自于機房，應(yīng)用，實例等維度組合成的采集點。 這樣大家邏輯上就可以抽象出來一個id+{timestamp, value}的時序數(shù)據(jù)模型。這種數(shù)據(jù)模型的存儲是如何呢。一般有兩種典型的數(shù)據(jù)存儲思路：
- 一種按照時間窗口維度劃分數(shù)據(jù)塊，同一段自然時間窗口內(nèi)的連續(xù)數(shù)據(jù)放到相鄰的位置，比如{1:00, 2:00}->(id1, id2, id3, ... ... ,idN)。 采用這種方式的典型時序數(shù)據(jù)庫包含InfluxDB, Promethues等等TSMT結(jié)構(gòu)的數(shù)據(jù)庫。OpenTSDB有些特殊，因為OpenTSDB是單值模型，指標這個維度在查詢的時候是必帶的。 所以可以先按照指標做了一級劃分，再根據(jù)時間窗口做二級的劃分，本質(zhì)上還是同一時間窗口內(nèi)的連續(xù)數(shù)據(jù)。 按照時間窗口切分的方式，優(yōu)勢是寫入的時候可以很天然的按照窗口去落盤，對于高緯度的標簽查詢基本上是一些連續(xù)Scan. 這種方式有個比較難解的問題就是"out of order"亂序問題，對于時間窗口過期后再來的時間點，Promethues直接采用丟棄的方式，InfluxDB在這種情況下性能會有損耗。
- 另外一種按照時間線維度劃分數(shù)據(jù)塊，同一時間線的數(shù)據(jù)放到相鄰的位置，比如(id1)->(1:00, 2:00, 3:00, ... ... , 23:00)。 HiTSDB采用時間線維度劃分的方式：目前落盤數(shù)據(jù)存儲于HBASE，底層Rowkey由指標+標簽+自然窗口的方式組合而成. Rowkey按照大小順序合并某個時間線的數(shù)據(jù)點是連續(xù)相鄰的。 因此對于一些低維的查詢效率是非常高效的。根據(jù)目前接觸的一些物聯(lián)網(wǎng)服務(wù)，更多的是一些低維的訪問。對于中等維度的查詢采用流式scan。對于極高緯度標簽的查詢HiTSDB采用預(yù)聚合的服務(wù)(不在本文討論范圍內(nèi))。
1.2 時序模型的熱點問題處理
生產(chǎn)環(huán)境中業(yè)務(wù)方采集的指標類型多種多樣，對指標的采集周期各不相同。比如cpu.usage這個指標的變化頻率比較快，業(yè)務(wù)方關(guān)注度高，采集周期通常很短，1秒，5秒，10秒等等。 然而指標disk.usage這個指標變化趨勢相對平滑，采集周期通常為1分鐘，5分鐘， 10分鐘等。這種情況下，數(shù)據(jù)的存儲如果針對同一個指標不做特殊處理，容易形成熱點問題。 假設(shè)按照指標類型進行存儲資源的分片，想象一下如果有20個業(yè)務(wù)，每個業(yè)務(wù)10個集群，每個集群500臺主機，采集周期是1秒的話，每秒就會有10萬個cpu.usage的指標數(shù)據(jù)點落到同一個存儲資源實例中， 而disk.usage采集周期為1分鐘，所以大約只有1666個指標數(shù)據(jù)點落到另外一個存儲資源上，這樣數(shù)據(jù)傾斜的現(xiàn)象非常嚴重。
1.2.1 分桶
這類問題的經(jīng)典解法就是分桶。比如除了指標類型外，同時將業(yè)務(wù)名和主機名作為維度標識tags，把指標cpu.usage劃分到不同的桶里面。 寫入時根據(jù)時間線哈希值分散寫入到不同的桶里面。 OpenTSDB在處理熱點問題也是采用了分桶模式，但是需要廣播讀取，根本原因在于查詢方式需要在某個時間窗口內(nèi)的全局掃描。 所以設(shè)置OpenTSDB的分桶數(shù)量需要一個平衡策略，如果數(shù)量太少，熱點還是有局部性的問題，如果太多，查詢時廣播讀帶來的開銷會非常大。
與其相比較，HiTSDB避免了廣播讀，提高了查詢效率。由于HiTSDB在查詢時，下發(fā)到底層存儲掃描數(shù)據(jù)之前，首先會根據(jù)查詢語句得到精確命中的時間線。 有了具體的時間線就可以確定桶的位置，然后到相應(yīng)的塊區(qū)域取數(shù)據(jù)，不存在廣播讀。 關(guān)于HiTSDB如何在查詢數(shù)據(jù)的時候獲取命中的時間線，相信讀者這個疑問會在讀取完倒排這一節(jié)的時候消釋。
1.2.2 Region Pre-Split
當(dāng)一個表剛被創(chuàng)建的時候，HBase默認分配一個Region給新表。所有的讀寫請求都會訪問到同一個regionServer的同一個region中。 此時集群中的其他regionServer會處于比較空閑的狀態(tài)，這個時候就達不到負載均衡的效果了。 解決這個問題使用pre-split,在創(chuàng)建新表的時候根據(jù)分桶個數(shù)采用自定義的pre-split的算法，生成多個region。 byte[][] splitKeys =new byte[bucketNumber-1][]; splitKeys[bucketIndex-1] = (bucketIndex&0xFF);
2. 倒排索引：
2.1 時序數(shù)據(jù)中的多維時間線
多維支持對于任何新一代時序數(shù)據(jù)庫都是極其重要的。 時序數(shù)據(jù)的類型多種多樣,來源更是非常復(fù)雜,不止有單一維度上基于時間的有序數(shù)值，還有多維時間線相關(guān)的大量組合。 舉個簡單例子，cpu的load可以有三個維度描述cpu core， host， app應(yīng)用，每個維度可以有百級別甚至萬級別的標簽值。 sys.cpu.load cpu=1 host=ipA app=hitsdb，各個維度組合后時間線可以輕松達到百萬級別。 如何管理這些時間線，建立索引并且提供高效的查詢是時序數(shù)據(jù)庫里面需要解決的重要問題。 目前時序領(lǐng)域比較主流的做法是采用倒排索引的方式。
2.2 倒排索引基本組合
基本的時間線在倒排中的組合思路如下：
時間線的原始輸入值：
倒排構(gòu)建后：
查詢時間線 cpu=3 and host=ipB：
取交集后查詢結(jié)果為7：
2.3 倒排面臨的問題以及優(yōu)化思路
倒排主要面臨的是內(nèi)存膨脹的問題：
- posting list過長， 對于高緯度的tag，比如“機房=杭州”，杭州可能會有千級別甚至萬級別的機器，這就意味著posting list需要存儲成千上萬個64-bit的id。 解決這個問題的思路是采用壓縮posting list的方式， 在構(gòu)建posting list的時候?qū)?shù)組里面的id進行排序，然后采用delta編碼的方式壓縮。
- 如果Tag鍵值對直接作為term使用，內(nèi)存占用取決于字符串的大小，采用字符串字典化，也可大大減少內(nèi)存開銷。
3. 流式聚合引擎
3.1 HiTSDB聚合引擎的技術(shù)痛點
HiTSDB現(xiàn)有聚合引擎公有云公測以及集體內(nèi)部業(yè)務(wù)運行中，暴露發(fā)現(xiàn)了以下問題：
3.1.1 Materialization執(zhí)行模式造成Heap內(nèi)存易打爆
下圖顯示了原查詢引擎的架構(gòu)圖。HiTSDB以HBase作為存儲，原引擎通過Async HBase client 從HBase獲取時序數(shù)據(jù)。由于HBase的數(shù)據(jù)讀取是一個耗時的過程，通常的解法是采用異步HBase client的API，從而有效提高系統(tǒng)的并行性。但原聚合引擎采用了一種典型的materialization的執(zhí)行方式：1）啟動多個異步HBase API啟HBase讀，2）只有當(dāng)查詢所涉及的全部時序數(shù)據(jù)讀入到內(nèi)存中后，聚合運算才開始啟動。這種把HBase Scan結(jié)果先在內(nèi)存中materialized再聚合的方式使得HiTSDB容易發(fā)生Heap內(nèi)存打爆的現(xiàn)象。尤其當(dāng)用戶進行大時間范圍查詢，或者查詢的時間線的數(shù)據(jù)非常多的時候，因為涉及的時序數(shù)據(jù)多，HiTSDB會發(fā)生Heap OOM而導(dǎo)致查詢失敗。
3.1.2 大查詢打爆HBase的問題
兩個原因造成HiTSDB處理聚合查詢的時候，容易發(fā)生將底層HBase打爆。
- HBase 可能讀取多余時間線數(shù)據(jù)。HiTSDB的時間線采用指標+時間窗口+標簽的編碼方式存儲在HBase。典型的查詢是用戶指定一個指標，時間范圍，以及空間維度上標簽要尋找的匹配值。空間維度的標簽查詢條件并不都是在標簽編碼前綴。當(dāng)這種情況發(fā)生時，HiTSDB倒排索引不能根據(jù)空間維度的查詢條件，精確定位到具體的HBase的查詢條件，而是采用先讀取再過濾的方式。這意味著HBase有可能讀取很多冗余數(shù)據(jù)，從而加重HBase的負載。
- HiTSDB有可能在短時間內(nèi)下發(fā)太多HBase讀請求。一方面，HiTSDB在HBase采用分片存儲方式，對每一個分片，都至少啟動一個讀請求，另一方面，因為上面提到的materialization的執(zhí)行方式，一個查詢涉及到的HBase讀請求同時異步提交，有可能在很短時間內(nèi)向HBase下發(fā)大量的讀請求。這樣，一個大查詢就有可能把底層的HBase打爆。
當(dāng)這種情況發(fā)生時，更糟糕的場景是HiTSDB無法處理時序數(shù)據(jù)的寫入請求，造成后續(xù)新數(shù)據(jù)的丟失。
3.1.3 執(zhí)行架構(gòu)高度耦合，修改或增加功能困難
聚合引擎主要針對應(yīng)用場景是性能監(jiān)控，查詢模式固定，所以引擎架構(gòu)采用單一模式，把查詢，過濾，填值/插值，和聚合運算的邏輯高度耦合在一起。這種引擎架構(gòu)對于監(jiān)控應(yīng)用的固定查詢沒有太多問題，但HiTSDB目標不僅僅是監(jiān)控場景下的簡單查詢，而是著眼于更多應(yīng)用場景下的復(fù)雜查詢。
我們發(fā)現(xiàn)采用原有引擎的架構(gòu)，很難在原有基礎(chǔ)上進行增加功能，或修改原來的實現(xiàn)。本質(zhì)上的原因在于原有聚合引擎沒有采用傳統(tǒng)數(shù)據(jù)庫所通常采用的執(zhí)行架構(gòu)，執(zhí)行層由可定制的多個執(zhí)行算子組成，查詢語義可以由不同的執(zhí)行算子組合而完成。這個問題在產(chǎn)品開發(fā)開始階段并不感受很深，但確是嚴重影響HiTSDB拓寬應(yīng)用場景，增加新功能的一個重要因素。
3.1.4 聚合運算效率有待提高
原有引擎在執(zhí)行聚合運算的時候，也和傳統(tǒng)數(shù)據(jù)庫所通常采用的iterative執(zhí)行模式一樣，迭代執(zhí)行聚合運算。問題在于每次iteration執(zhí)行，返回的是一個時間點。Iterative 執(zhí)行每次返回一條時間點，或者一條記錄，常見于OLTP這樣的場景，因為OLTP的查詢所需要訪問的記錄數(shù)很小。但對HiTSDB查詢有可能需要訪問大量時間線數(shù)據(jù)，這樣的執(zhí)行方式效率上并不可取。
原因1）每次處理一個時間點，都需要一系列的函數(shù)調(diào)用，性能上有影響，2）iterative循環(huán)迭代所涉及到的函數(shù)調(diào)用，無法利用新硬件所支持的SIMD并行執(zhí)行優(yōu)化，也無法將函數(shù)代碼通過inline等JVM常用的hotspot的優(yōu)化方式。在大數(shù)據(jù)量的場景下，目前流行的通用做法是引入Vectorization processing, 也就是每次iteration返回的不再是一條記錄，而是一個記錄集(batch of rows)，比如Google Spanner 用batch-at-a-time 代替了row-at-a-time, Spark SQL同樣也在其執(zhí)行層采用了Vectorization的執(zhí)行模式。
3.2 流式聚合引擎設(shè)計思路
針對HiTSDB原有聚合運算引擎上的問題，為了優(yōu)化HiTSDB,支持HiTSDB商業(yè)化運營，我們決定改造HiTSDB聚合運算引擎。下圖給出了新聚合查詢引擎的基本架構(gòu)。
3.2.1 pipeline執(zhí)行模式
借鑒傳統(tǒng)數(shù)據(jù)庫執(zhí)行模式，引入pipeline的執(zhí)行模式（aka Volcano / Iterator 執(zhí)行模式）。Pipeline包含不同的執(zhí)行計算算子(operator), 一個查詢被物理計劃生成器解析分解成一個DAG或者operator tree， 由不同的執(zhí)行算子組成，DAG上的root operator負責(zé)驅(qū)動查詢的執(zhí)行，并將查詢結(jié)果返回調(diào)用者。在執(zhí)行層面，采用的是top-down需求驅(qū)動 (demand-driven)的方式，從root operator驅(qū)動下面operator的執(zhí)行。這樣的執(zhí)行引擎架構(gòu)具有優(yōu)點：
- 這種架構(gòu)方式被很多數(shù)據(jù)庫系統(tǒng)采用并證明是有效;
- 接口定義清晰，不同的執(zhí)行計算算子可以獨立優(yōu)化，而不影響其他算子;
- 易于擴展：通過增加新的計算算子，很容易實現(xiàn)擴展功能。比如目前查詢協(xié)議里只定義了tag上的查詢條件。如果要支持指標值上的查詢條件(cpu.usage >= 70% and cpu.usage <=90%),可以通過增加一個新的FieldFilterOp來實現(xiàn)。
每個operator,實現(xiàn)如下接口：
- Open : 初始化并設(shè)置資源
- Next : 調(diào)用輸入operator的next()獲得一個batch of time series, 處理輸入，輸出batch of time series
- Close : 關(guān)閉并釋放資源
我們在HiTSDB中實現(xiàn)了以下算子：
- ScanOp: 用于從HBase異步讀取時間線數(shù)據(jù)
- DsAggOp: 用于進行降采樣計算，并處理填值
- AggOp：用于進行分組聚合運算，分成PipeAggOp, MTAggOp
- RateOp: 用于計算時間線值的變化率
3.2.2 執(zhí)行計算算子一個batch的時間線數(shù)據(jù)為運算單位
在計算算子之間以一個batch的時間線數(shù)據(jù)為單位，提高計算引擎的執(zhí)行性能。其思想借鑒于OLAP系統(tǒng)所采用的Vectorization的處理模式。這樣Operator在處理一個batch的多條時間線，以及每條時間線的多個時間點，能夠減少函數(shù)調(diào)用的代價，提高loop的執(zhí)行效率。
每個Operator以流式線的方式，從輸入獲得時間線batch, 經(jīng)過處理再輸出時間線batch, 不用存儲輸入的時間線batch，從而降低對內(nèi)存的要求。只有當(dāng)Operator的語義要求必須將輸入materialize，才進行這樣的操作（參見下面提到的聚合算子的不同實現(xiàn)）。
3.2.3. 區(qū)分不同查詢場景，采用不同聚合算子分別優(yōu)化
HiTSDB原來的聚合引擎采用materialization的執(zhí)行模式，很重要的一個原因在于處理時序數(shù)據(jù)的插值運算，這主要是因為時序數(shù)據(jù)的一個典型特點是時間線上不對齊：不同的時間線在不同的時間戳上有數(shù)據(jù)。HiTSDB兼容OpenTSDB的協(xié)議，引入了插值(interpolation)的概念，目的在于聚合運算時通過指定的插值方式，在不對齊的時間戳上插入計算出來的值，從而將不對齊的時間線數(shù)據(jù)轉(zhuǎn)換成對齊的時間線。插值是在同一個group的所有時間線之間比較，來決定在哪個時間戳上需要進行插值 （參見OpenTSDB 文檔）。
為了優(yōu)化聚合查詢的性能，我們引入了不同的聚合運算算子。目的在于針對不同的查詢的語義，進行不同的優(yōu)化。有些聚合查詢需要插值，而有些查詢并不要求插值；即使需要插值，只需要把同一聚合組的時間線數(shù)據(jù)讀入內(nèi)存，就可以進行插值運算。
- PipeAggOp: 當(dāng)聚合查詢滿足以下條件時，
1）不需要插值： 查詢使用了降采樣(downsample),并且降采樣的填值采用了非null/NaN的策略。這樣的查詢，經(jīng)過降采樣后，時間線的數(shù)據(jù)都是對齊補齊的，也就是聚合函數(shù)所用到的插值不再需要。
2）聚合函數(shù)可以支持漸進式迭代計算模式 (Incremental iterative aggregation), 比如sum, count ,avg, min, max, zerosum, mimmim, mimmax，我們可以采用incremental聚合的方式，而不需要把全部輸入數(shù)據(jù)讀入內(nèi)存。這個執(zhí)行算子采用了流水線的方式，每次從輸入的operator獲得一系列時間線，計算分組并更新聚合函數(shù)的部分值，完成后可以清理輸入的時間線，其自身只用保留每個分組的聚合函數(shù)的值。
- MTAgOp: 需要插值，并且輸入算子無法幫助將時間線ID預(yù)先分組，這種方式回退到原來聚合引擎所采用的執(zhí)行模式。
對于MTAggOp, 我們可以引入分組聚合的方法進行優(yōu)化：
- GroupedAggOp: 需要插值，但是輸入算子能夠保證已經(jīng)將時間線的ID根據(jù)標識(tags)進行排序分組，這樣在流水線處理中，只要materialize最多一個組的數(shù)據(jù)，這樣的算子比起內(nèi)存保留所有分組時間線，內(nèi)存要求要低，同時支持不同組之間的并行聚合運算。
3.2.4 查詢優(yōu)化器和執(zhí)行器
引入執(zhí)行算子和pipeline執(zhí)行模式后，我們可以在HiTSDB分成兩大模塊，查詢優(yōu)化器和執(zhí)行器。優(yōu)化器根據(jù)查詢語義和執(zhí)行算子的不同特點，產(chǎn)生不同的執(zhí)行計劃，優(yōu)化查詢處理。例如HiTSDB可以利用上面討論的三個聚合運算算子，在不同的場景下，使用不同的執(zhí)行算子，以降低查詢執(zhí)行時的內(nèi)存開銷和提高執(zhí)行效率為目的。這樣的處理方式相比于原來聚合引擎單一的執(zhí)行模式，更加優(yōu)化。
4. 數(shù)據(jù)遷移
HiTSDB新的聚合引擎采用的底層存儲格式與以前的版本并不兼容。 公有云公測期間運行在舊版本實例的數(shù)據(jù)，需要遷移至新的聚合引擎。 同時熱升級出現(xiàn)了問題，數(shù)據(jù)遷移還應(yīng)回滾功能，將新版本的數(shù)據(jù)點轉(zhuǎn)換成舊的數(shù)據(jù)結(jié)構(gòu)，實現(xiàn)版本回滾。 整體方案對于用戶的影響做到：寫入無感知，升級過程中，歷史數(shù)據(jù)不可讀。
4.1 數(shù)據(jù)遷移架構(gòu)
- 并發(fā)轉(zhuǎn)換和遷移數(shù)據(jù): 原有的HiTSDB數(shù)據(jù)點已經(jīng)在寫入的時候進行了分片。默認有20個Salts。數(shù)據(jù)遷移工具會對每個Salt的數(shù)據(jù)點進行并發(fā)處理。 每個“Salt”都有一個Producer和一個Consumer。Producer負責(zé)開啟HBase Scanner獲取數(shù)據(jù)點。 每個Scanner異步對HBase進行掃描，每次獲取HBASE_MAX_SCAN_SIZE行數(shù)的數(shù)據(jù)點。然后將HBase的Row Key轉(zhuǎn)換成新的結(jié)構(gòu)。
最后將該Row放到所有的一個Queue上等待Consumer消費。 Consumer每次會處理HBASE_PUT_BATCHSIZE或者HBASE_PUT_MIN_DATAPOINTS的數(shù)據(jù)量。 每次Consumer順利寫入該Batch的時候，我們會在UID表中記錄對應(yīng)“Salt”的數(shù)據(jù)處理位置。 這樣便于故障重啟時Producer從最后一次成功的地方重新開始獲取數(shù)據(jù)點進行轉(zhuǎn)換。 數(shù)據(jù)遷移工具對HBase的操作都采用異步的讀寫。當(dāng)掃描數(shù)據(jù)或者寫入數(shù)據(jù)失敗的時候，我們會進行有限制的嘗試。 如果超出嘗試次數(shù)，我們就終止該“Salt”的數(shù)據(jù)遷移工作，其他”Salt“的工作不受到任何影響。 當(dāng)下次工具自動重啟時，我們會出現(xiàn)問題的”Salt“數(shù)據(jù)繼續(xù)進行遷移，直到所有數(shù)據(jù)全部順利轉(zhuǎn)換完成。
- 流控限制: 大部分情況下，Producer對HBase的掃描數(shù)據(jù)要快于Consumer對HBase的寫入。 為了防止Queue的數(shù)據(jù)積壓對內(nèi)存造成壓力同時為了減少Producer掃描數(shù)據(jù)時對HBase的壓力，我們設(shè)置了流控。 當(dāng)Queue的大小達到HBASE_MAX_REQUEST_QUEUE_SIZE時候，Producer會暫時停止對HBase的數(shù)據(jù)掃描等待Consumer消費。 當(dāng)Queue的大小減少到HBASE_RESUME_SCANNING_REQUEST_QUEUE_SIZE時候，Producer會重新恢復(fù)。
- Producer和Consumer進程的退出
順利完成時候如何退出: 當(dāng)一切進展順利時候，當(dāng)Producer完成數(shù)據(jù)掃描之后，會在Queue上放一個EOS（End of Scan），然后退出。 Consumer遇到EOS就會知道該Batch為最后一批，成功處理完該Batch之后就會自動退出。
失敗后如何關(guān)閉: Consumer遇到問題時：當(dāng)Consumer寫入HBase失敗之后，consumer會設(shè)置一個Flag，然后退出線程。 每當(dāng)Producer準備進行下一個HBASE_MAX_SCAN_SIZE的掃描時候，他會先檢查該Flag。 如果被設(shè)置，他會知道對應(yīng)的Consumer線程已經(jīng)失敗并且退出。Producer也會停止掃描并且退出。 Producer遇到問題時：當(dāng)Producer掃描數(shù)據(jù)失敗時，處理方式和順利完成時候類似。都是通過往Queue上EOS來完成通知。 下次重啟時，Producer會從上次記錄的數(shù)據(jù)處理位置開始重新掃描。
4.2 數(shù)據(jù)遷移的一致性
由于目前云上版本HiTSDB為雙節(jié)點，在結(jié)點升級結(jié)束后會自動重啟HiTSDB。自動啟動腳本會自動運行數(shù)據(jù)遷移工具。 如果沒有任何預(yù)防措施，此時兩個HiTSDB節(jié)點會同時進行數(shù)據(jù)遷移。雖然數(shù)據(jù)上不會造成任何丟失或者損壞， 但是會對HBase造成大量的寫入和讀取壓力從而嚴重影響用戶的正常的寫入和查詢性能。
為了防止這樣的事情發(fā)生，我們通過HBase的Zoo Keeper實現(xiàn)了類似FileLock鎖，我們稱為DataLock，的機制保證只有一個結(jié)點啟動數(shù)據(jù)遷移進程。 在數(shù)據(jù)遷移進程啟動時，他會通過類似非阻塞的tryLock()的形式在Zoo Keeper的特定路徑創(chuàng)建一個暫時的節(jié)點。 如果成功創(chuàng)建節(jié)點則代表成果獲得DataLock。如果該節(jié)點已經(jīng)存在，即被另一個HiTSDB創(chuàng)建，我們會收到KeeperException。這樣代表未獲得鎖，馬上返回失敗。 如果未成功獲得DataLock，該節(jié)點上的數(shù)據(jù)遷移進程就會自動退出。成果獲得DataLock的節(jié)點則開始進行數(shù)據(jù)遷移。
4.3 數(shù)據(jù)遷移中的"執(zhí)行一次"
當(dāng)所有“Salt”的數(shù)據(jù)點全部順利完成遷移之后，我們會在HBase的舊表中插入一行新數(shù)據(jù)，data_conversion_completed。 此行代表了數(shù)據(jù)遷移工程全部順利完成。同時自動腳本會每隔12個小時啟動數(shù)據(jù)遷移工具，這樣是為了防止上次數(shù)據(jù)遷移沒有全部完成。 每次啟動時，我們都會先檢查“data_conversion_completed”標志。如果標志存在，工具就會馬上退出。 此項操作只會進行一次HBase的查詢，比正常的健康檢查成本還要低。所以周期性的啟動數(shù)據(jù)遷移工具并不會對HiTSDB或者HBase產(chǎn)生影響。
4.4. 數(shù)據(jù)遷移的評測
效果：上線后無故障完成100+實例數(shù)據(jù)的遷移，熱升級。
5. 查詢性能評測
Case 1: 數(shù)據(jù)采集頻率5s, 查詢命中1000條，時間窗口3600s
總結(jié)： 新的查詢聚合引擎將查詢速度提高了10倍以上。
其他
本文介紹了高性能時間序列數(shù)據(jù)庫HiTSDB引擎在商業(yè)化運營之前進行的優(yōu)化升級，目的是提高HiTSDB引擎的穩(wěn)定性，數(shù)據(jù)寫入和查詢性能以及新功能的擴展性。HiTSDB已經(jīng)在阿里云正式商業(yè)化運營，我們將根據(jù)用戶反饋，進一步提高HiTSDB引擎，更好服務(wù)于HiTSDB的客戶。
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
