深入淺出時序數據庫之分布式計算

物聯網領域近期如火如荼，互聯網和傳統公司爭相布局物聯網。作為物聯網領域數據存儲的首選，時序數據庫也越來越多進入人們的視野，而早在2016年7月，百度云在其天工物聯網平臺上發布了國內首個多租戶的分布式時序數據庫產品TSDB，成為支持其發展制造，交通，能源，智慧城市等產業領域的核心產品，同時也成為百度戰略發展產業物聯網的標志性事件。

前文提到數據查詢特別是大數據量的聚合分析查詢是時序數據庫需要解決的一個主要問題，之前的文章介紹了通過預處理數據的方法，用空間換時間的思路，降低了大數據量聚合分析的延時。

本文將從分布式計算方向思考，從并發的角度介紹時序數據庫如何降低數據查詢的延時。

1. 單機時序數據的聚合計算

我們先來看看單機是如何支持單聚合函數的計算。單機聚合計算非常簡單，用戶查詢數據時，計算節點查詢獲取時間范圍內的所有時序數據，節點按照時序使用聚合函數對數據進行計算，生成計算結果。

分析查詢也經常會使用嵌套聚合，嵌套聚合函數使用不同的時間窗口，內部函數通常使用小時間窗口，外部使用更大的時間窗口。那嵌套聚合查詢在單機如何計算呢？和單一聚合函數類似，嵌套聚合函數的計算是在內部聚合函數計算的結果之上，根據時間再次計算，獲取結果。如下圖查詢月平均氣溫最低的一周以及平均氣溫。總體來說，單機時序數據的嵌套和非嵌套聚合函數的實現過程簡單直接，很容易理解。

(點擊放大圖像)

單機計算有什么特征呢？從單機的計算過程，我們可以看到單機需要查詢獲取所有原始時序數據，原始數據查詢的IO成本和計算成本非常高，整個查詢的延時會很高，但是聚合運算后的結果往往數據量很少。

2. 分布式聚合計算

分布式計算是一種計算方法，與之相對的是集中式計算，是通過使用多個計算資源在分布式的環境中并發執行計算的方法。在時序數據庫領域，隨著數據的增長，時序數據會越來越多，單機的存儲、查詢和聚合分析IO時間成本非常高，雖然使用更加高效的硬件也能夠緩解，但是有處理上限，基于成本等因素的考慮，分布式聚合查詢仍然是時序數據庫自然而然的選擇。

當時序數據庫存儲的數據越來越多時，聚合查詢不可避免，這也是OLAP分析查詢中最常見操作之一，使用預處理可以提高查詢性能，但是不夠靈活。分布式聚合計算則是能夠使用分布式的特性，通過多個計算資源并行計算，再對結果進行合并返回，通過并發提高聚合查詢性能。

3. 分布式時序數據聚合計算

時序數據的分布式聚合計算需要多個節點并行計算，邏輯上也是一個Map/Reduce的過程，Map過程需要對原始時序數據進行分片，分別聚合計算。Reduce過程則是對多個分片計算結果的合并。往往聚合運算的結果和原始數據有著明顯數據量的差距，其次分布式計算可以更多的考慮數據的本地化，因此使用分布式聚合計算顯然能夠有效提高查詢性能。

時序數據要進行分布式計算需要解決兩個基本問題：時序數據計算分片以及計算結果的合并。

3.1 時序數據計算分片

時序數據聚合計算的分片可以分為幾個維度考慮：存儲分片、聚合函數時間窗口以及查詢條件。

首先，時序數據聚合查詢包含多種條件，對時序數據進行分組聚合查詢也是一種常用查詢，不同的分組原始時序數據不同，因此可以通過查詢分組對時序數據計算進行分片，不同的分組使用不同節點并發計算。

其次，時序數據聚合查詢函數通常都包含時間窗口，相同時間窗口的原始數據聚合計算為一個數據點，不同的時間窗口用于計算的時序原始數據不同，因此也同樣可以通過時間窗口對時序數據計算進行時間維度的分片，不同的節點計算不同時間窗口的數據。

第三，按照存儲分片進行計算。我們先來回憶一下前文說描述的時序數據的存儲，時序數據由于存儲的數據量很大，單機并不能滿足需求，因此需要對時序數據進行分片存儲，分片(shard)通常使用metric+tags的方式進行，不同的分片存儲在不同的存儲節點，分片存儲著原始時序數據，使用存儲分片進行分片計算，也是一種自然而然的選擇。如下圖先對shard進行分片計算查詢，最后對結果進行合并。

(點擊放大圖像)

使用存儲分片來分片計算有著什么優勢呢？顯然，數據查詢和計算在存儲分片的節點上進行，能夠最大的保證數據本地化，能夠有效減少網絡通訊帶來的延時，使得本地數據計算更加高效。

分布式聚合查詢在實現時，往往多種計算分片方式同時使用，聚合計算盡量保證本地化、 盡量多的并發執行。

3.2 時序數據計算結果的合并

時序數據聚合計算結果的合并和計算分片的方式有相關性，不同分片方式結果的合并方式也不同。

首先，對于分組聚合查詢結果的合并來說，不同的分組查詢結果屬于不同的分組，按照分組聚合查詢條件合并結果，就能形成計算結果。

其次，對于聚合函數時間窗口分片查詢的合并來說，不同的時間窗口的計算結果雖然屬于同一個分組，但是結果在時間是上有序的，因此只需要對分片計算結果按照時序排序合并，就能獲取最終計算結果。

第三，對于存儲分片進行分片計算結果的合并來說，合并相對復雜，因為在同一個時間窗口內，可能會包含多個分片，多個分片上同一時間窗口需要聚合運算為一個數據點。聚合運算結果的合并就需要分析聚合函數的特性來進行，例如在A和B兩個存儲分片的同一時間窗口內SUM聚合函數，顯然計算結果可以直接累加SUM(A U B) = SUM(A) + SUM(B)，但是并不是所有的聚合函數都滿足這一特性，需要根據聚合函數的特性做一一的分類。

當使用多種分片方式進行聚合查詢時，相應結果的合并也同樣更為復雜。

3.3 時序數據嵌套聚合運算

嵌套聚合查詢也是數據分析的常用方式，嵌套聚合運算往往多個聚合函數嵌套而成，每個聚合函數的計算屬性并不完全相同。在考慮計算分片時，可以考慮將外部嵌套函數和內部嵌套函數分開計算，選擇更加有利的分片方式。例如考慮 DIFF(SUM(A, 1day)) 嵌套聚合函數（DIFF聚合函數是計算前后時間序列結果的差值），既可以使用按照時間窗口的方式分片計算，也同樣可以考慮將 DIFF的計算和SUM的計算拆分開來，先使用存儲分片的方式聚合計算SUM(A, 1day)的結果，結果合并時計算DIFF嵌套聚合函數的結果，存儲分片的分布式計算能夠充分利用數據本地化的特性，因此使用后者顯然更加高效。嵌套聚合函數的數據如何分片計算，需要根據聚合函數特性以及場景具體分析，這仍然是一個需要深入考慮的問題。

3.4 計算任務的調度和優化

時序數據分布式計算除了計算分片和數據合并問題以外，同樣需要處理任務調度和SQL查詢優化的問題，現有的很多開源框架Spark、Presto、 Mongodb 、 Hive 都有相應的解決方案，這里就不做深入討論了。

4. 時序數據聚合查詢的難題

時序數據分布式聚合計算仍然有很多難題，例如COUNT(DISTINCT FIELD)，這類聚合函數的特點是在計算結果時內部需要保存大量的中間數據用于計算,需要消耗大量計算和存儲資源。雖然很多大數據領域分布式查詢引擎等通過算法都嘗試做了部分優化，但是仍然未能完全解決所有問題。

5. 總結

在時序數據庫大數據量聚合分析查詢中，聚合運算直接影響著查詢性能，使用分布式計算的方法，能夠有效的提高查詢性能,相比較于預處理查詢更加的靈活。本文主要從分片以及如何并發的角度做了討論，但是一些特殊嵌套聚合場景的優化仍舊是需要深入思考課題。

 

來自：http://www.infoq.com/cn/articles/distributed-computation-of-sequential-databases