34
技術社區[雲棲]
時間序列數據的存儲和計算 - 概述
什麼是時間序列數據
什麼是時間序列（Time Series，以下簡稱時序）數據？從定義上來說，就是一串按時間維度索引的數據。用描述性的語言來解釋什麼是時序數據，簡單的說，就是這類數據描述了某個被測量的主體在一個時間範圍內的每個時間點上的測量值。
對時序數據進行建模的話，會包含三個重要部分，分別是：主體，時間點和測量值。套用這套模型，你會發現你在日常工作生活中，無時無刻不在接觸著這類數據。
- 如果你是一個股民，某隻股票的股價就是一類時序數據，其記錄著每個時間點該股票的股價。
- 如果你是一個運維人員，監控數據是一類時序數據，例如對於機器的CPU的監控數據，就是記錄著每個時間點機器上CPU的實際消耗值。
這個世界是由數據構成的，在這個世界上存在的每個物體，每時每刻都在產生著數據。而對這些數據的挖掘和利用，在這個時代，正在默默的改變人們的生活方式。例如通過可穿戴設備對個人健康的管理，就是通過設備不斷采集你的個人健康數據，例如心跳、體溫等等，收集完數據後套用模型計算來評估你的健康度。
如果你的視野和想象空間足夠大，你會發現你能夠挖掘並利用的數據充斥在你所生活的環境中。這些能夠產生數據的對象，會包括你的手機、汽車、空調、冰箱等等。當前比較火熱的物聯網的核心思想，其實就是構建一個可以讓所有物體生產數據並挖掘其價值的網絡。而通過這個網絡采集的數據，就是典型的時序數據。
時序數據用於描述一個物體在曆史的時間維度上的狀態變化信息，而對於時序數據的分析，就是嚐試掌握並把控其變化的規律的過程。隨著物聯網、大數據和人工智能技術的發展，時序數據也呈一個爆發式的增長。而為了更好的支持這類數據的存儲和分析，在市場上衍生出了多種多樣的新興的數據庫產品。這類數據庫產品的發明都是為了解決傳統關係型數據庫在時序數據存儲和分析上的不足和缺陷，這類產品被統一歸類為時序數據庫。
從DB-Engines的數據庫類別流行度趨勢榜上可以看到，時序數據庫（Time Series DB）的流行度在最近的兩年內，一直都是保持一個很高的增長趨勢。
接下來我會寫幾篇文章，分別來分析：
1. 時序數據的基本概念，包括模型、特性和基本的查詢和處理操作。
2. 幾個流行開源時序數據庫的底層實現分析
3. 阿裏雲表格存儲（TableStore）的時序數據存儲和計算解決方案
時間序列數據的特性
對於時序數據的特點的分析，會從數據的寫入、查詢和存儲這三個維度來闡述，通過對其特點的分析，來推演對時序數據庫的基本要求。
數據寫入的特點
- 寫入平穩、持續、高並發高吞吐：時序數據的寫入是比較平穩的，這點與應用數據不同，應用數據通常與應用的訪問量成正比，而應用的訪問量通常存在波峰波穀。時序數據的產生通常是以一個固定的時間頻率產生，不會受其他因素的製約，其數據生成的速度是相對比較平穩的。時序數據是由每個個體獨立生成，所以當個體數量眾多時，通常寫入的並發和吞吐量都是比較高的，特別是在物聯網場景下。寫入並發和吞吐量，可以簡單的通過個體數量和數據生成頻率來計算，例如若你有1000個個體以10秒的頻率產生數據，則你平均每秒產生的並發和寫入量就是100。
- 寫多讀少：時序數據上95%-99%的操作都是寫操作，是典型的寫多讀少的數據。這與其數據特性相關，例如監控數據，你的監控項可能很多，但是你真正去讀的可能比較少，通常隻會關心幾個特定的關鍵指標或者在特定的場景下才會去讀數據。
- 實時寫入最近生成的數據，無更新：時序數據的寫入是實時的，且每次寫入都是最近生成的數據，這與其數據生成的特點相關，因為其數據生成是隨著時間推進的，而新生成的數據會實時的進行寫入。數據寫入無更新，在時間這個維度上，隨著時間的推進，每次數據都是新數據，不會存在舊數據的更新，不過不排除人為的對數據做訂正。
數據查詢和分析的特點
- 按時間範圍讀取：通常來說，你不會去關心某個特定點的數據，而是一段時間的數據。所以時序數據的讀取，基本都是按時間範圍的讀取。
- 最近的數據被讀取的概率高：最近的數據越有可能被讀取，以監控數據為例，你通常隻會關心最近幾個小時或最近幾天的監控數據，而極少關心一個月或一年前的數據。
- 多精度查詢：按數據點的不同密集度來區分不同的精度，例如若相鄰數據點的間隔周期是10秒，則該時序數據的精度就是10秒，若相鄰數據點的時間間隔周期是30秒，則該時序數據的精度就是30秒。時間間隔越短，精度越高。精度越高的數據，能夠還原的曆史狀態更細致更準確，但其保存的數據點會越多。這個就好比相機的像素，像素越高，照片越清晰但是相片大小越大。時序數據的查詢，不需要都是高精度的，這是實際的需求，也是一種取舍，同樣也是成本的考慮。還是拿監控數據舉例，通常監控數據會以曲線圖的方式展現，由人的肉眼去識別。在這種情況下，單位長度下若展示的數據點過於密集，反而不利於觀察，這是實際的需求。而另外一種取舍是，若你查詢一個比較長的時間範圍，比如是一個月，若查詢10秒精度的數據需要返回259200個點，而若查詢60秒精度的數據則隻要返回43200個點，這是查詢效率上的一種取舍。而成本方麵的考慮，主要在存儲的數據量上，存儲高精度的數據需要的成本越高，通常對於曆史數據，可以不需要存儲很高精度的數據。總的來說，在查詢和處理方麵，會根據不同長度的時間範圍，來獲取不同精度的數據，而在存儲方麵，對於曆史的數據，會選擇降精度的數據存儲。
- 多維分析：時序數據產生自不同的個體，這些個體擁有不同的屬性，可能是同一維度的，也可能是不同維度的。還是舉個監控的例子，我有個對某個集群上每台機器的網絡流量的監控，此時可以查詢這個集群下某台機器的網絡流量，這是一個維度的查詢，而同時還需要查詢這個集群總的網絡流量，這是另外一個維度的查詢。
- 數據挖掘：隨著大數據和人工智能技術的發展，在存儲、計算能力以及雲計算發展的今天，數據的高附加值的挖掘已經不再有一個很高門檻。而時序數據蘊含著很高的價值，非常值得挖掘。
數據存儲的特點
- 數據量大：拿監控數據來舉例，如果我們采集的監控數據的時間間隔是1s，那一個監控項每天會產生86400個數據點，若有10000個監控項，則一天就會產生864000000個數據點。在物聯網場景下，這個數字會更大。整個數據的規模，是TB甚至是PB級的。
- 冷熱分明：時序數據有非常典型的冷熱特征，越是曆史的數據，被查詢和分析的概率越低。
- 具有時效性：時序數據具有時效性，數據通常會有一個保存周期，超過這個保存周期的數據可以認為是失效的，可以被回收。一方麵是因為越是曆史的數據，可利用的價值越低；另一方麵是為了節省存儲成本，低價值的數據可以被清理。
- 多精度數據存儲：在查詢的特點裏提到時序數據出於存儲成本和查詢效率的考慮，會需要一個多精度的查詢，同樣也需要一個多精度數據的存儲。
時序數據庫基本要求
綜合以上對於時序數據寫入、查詢和存儲的特點的分析，我們可以歸納總結下對於時序數據庫的基本要求：
- 能夠支撐高並發、高吞吐的寫入：如上所說，時序數據具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權衡的是寫的能力。由於其場景的特點，對於數據庫的高並發、高吞吐寫入能力有很高的要求。
- 交互級的聚合查詢：交互級的查詢延遲，並且是在數據基數（TB級）較大的情況下，也能夠達到很低的查詢延遲。
- 能夠支撐海量數據存儲：場景的特點決定了數據的量級，至少是TB的量級，甚至是PB級數據。
- 高可用：在線服務的場景下，對可用性要求也會很高。
- 分布式架構：寫入和存儲量的要求，底層若不是分布式架構基本達不到目標。
結合時序數據的特點和時序數據庫的基本要求的分析，使用基於LSM樹存儲引擎的NoSQL數據庫（例如HBase、Cassandra或阿裏雲表格存儲等）相比使用B+樹的RDBMS，具有顯著的優勢。LSM樹的基本原理不在這裏贅述，它是為優化寫性能而設計的，寫性能相比B+樹能提高一個數量級。但是讀性能會比B+樹差很多，所以極其適合寫多讀少的場景。目前開源的幾個比較著名的時序數據庫中，OpenTSDB底層使用HBase、BlueFlood和KairosDB底層使用Cassandra，InfluxDB底層是自研的與LSM類似的TSM存儲引擎，Prometheus是直接基於LevelDB存儲引擎。所以可以看到，主流的時序數據庫的實現，底層存儲基本都會采用LSM樹加上分布式架構，隻不過有的是直接使用已有的成熟數據庫，有的是自研或者基於LevelDB自己實現。
LSM樹加分布式架構能夠很好的滿足時序數據寫入能力的要求，但是在查詢上有很大的弱勢。如果是少量數據的聚合和多維度查詢，勉強能夠應付，但是若需要在海量數據上進行多維和聚合查詢，在缺乏索引的情況下會顯得比較無力。所以在開源界，也有其他的一些產品，會側重於解決查詢和分析的問題，例如Druid主要側重解決時序數據的OLAP需求，不需要預聚合也能夠提供在海量數據中的快速的查詢分析，以及支持任意維度的drill down。同樣的側重分析的場景下，社區也有基於Elastic Search的解決方案。
總之，百花齊放的時序數據庫產品，各有優劣，沒有最好的，隻有最合適的，全憑你自己對業務需求的判斷來做出選擇。
時間序列數據的模型
時序數據的數據模型主要有這麼幾個主要的部分組成：
- 主體: 被測量的主體，一個主體會擁有多個維度的屬性。以服務器狀態監控場景舉例，測量的主體是服務器，其擁有的屬性可能包括集群名、Hostname等。
- 測量值: 一個主體可能有一個或多個測量值，每個測量值對應一個具體的指標。還是拿服務器狀態監控場景舉例，測量的指標可能會有CPU使用率，IOPS等，CPU使用率對應的值可能是一個百分比，而IOPS對應的值是測量周期內發生的IO次數。
- 時間戳: 每次測量值的匯報，都會有一個時間戳屬性來表示其時間。
目前主流時序數據庫建模的方式會分為兩種，按數據源建模和按指標建模，以兩個例子來說明這兩種方式的不同。
按數據源建模
如圖所示為按數據源建模的例子，同一個數據源在某個時間點的所有指標的測量值會存儲在同一行。Druid和InfluxDB采用這種模式。
按指標建模
如圖所示為按指標建模的例子，其中每行數據代表某個數據源的某個指標在某個時間點的測量值。OpenTSDB和KairosDB采用這種模式。
這兩種模型的選擇沒有明確的優劣，如果底層是采用列式存儲且每個列上都有索引，則按數據源建模可能是一個比較幹淨的方式。如果底層是類似HBase或Cassandra這種的，將多個指標值存儲在同一行會影響對其中某個指標的查詢或過濾的效率，所以通常會選擇按指標建模。
時間序列數據的處理
這一小節會主要講解下對時序數據的處理操作，時序數據庫除了滿足基本的寫和存儲的需求外，最重要的就是查詢和分析的功能。對時序數據的處理可以簡單歸納為Filter(過濾), Aggregation(聚合)、GroupBy和Downsampling(降精度)。為了更好的支持GroupBy查詢，某些時序數據庫會對數據做pre-aggregation(預聚合)。Downsampling對應的操作是Rollup(匯總)，而為了支持更快更實時的Rollup，通常時序數據庫都會提供auto-rollup(自動匯總)。
Filter(過濾)
如圖所示就是一個簡單的Filter處理，簡單的說，就是根據給定的不同維度的條件，查找符合條件的所有數據。在時序數據分析的場景，通常先是從一個高維度入手，後通過提供更精細的維度條件，對數據做更細致的查詢和處理。
Aggregation(聚合)
聚合是時序數據查詢和分析的最基本的功能，時序數據記錄的是最原始的狀態變化信息，而查詢和分析通常需要的不是原始值，而是基於原始值的一些統計值。Aggregation就是提供了對數據做統計的一些基本的計算操作，比較常見的有SUM（總和）、AVG（平均值）、Max（最大值）、TopN等等。例如對服務器網絡流量的分析，你通常會關心流量的平均值、流量的總和或者流量的峰值。
GroupBy和Pre-aggregation(預聚合)
GroupBy就是將一個低維度的時序數據轉換為一個高維度的統計值的過程，如圖就是一個簡單的GroupBy的例子。GroupBy一般發生在查詢時，查詢到原始數據後做實時的計算來得到結果，這個過程有可能是很慢的，取決於其查詢的原始數據的基數。主流的時序數據庫提供pre-aggregation(預聚合)的功能來優化這一過程，數據實時寫入後就會經過預聚合的運算，生成按指定規則GroupBy之後的結果，在查詢時就可以直接查詢結果而不需要再次計算。
Downsampling(降精度)，Rollup(匯總)和Auto-rollup(自動匯總)
Downsampling就是將一個高精度的時序數據轉換為一個低精度的時序數據的過程，這個過程被稱作Rollup。它與GroupBy的過程比較類似，核心區別是GroupBy是基於相同的時間粒度，把同一時間層麵上的不同維度的數據做聚合，轉換後的結果還是相同時間粒度的數據，隻不過是更高的一個維度。而Downsampling是不同時間層麵上把相同維度的數據做聚合，抓換為更粗時間粒度的數據，但是還是擁有相同的維度。
如圖就是一個簡單的Downsampling的例子，將一個10秒精度的數據聚合成30秒精度的數據，統計平均值。
Downsampling分為存儲降精度和查詢降精度，存儲降精度的意義在於降低存儲成本，特別是針對曆史數據。查詢降精度主要是針對較大時間範圍的查詢，來減少返回的數據點。不管是存儲降精度還是查詢降精度，都需要auto-rollup。auto-rollup就是自動的對數據做rollup，而不是等待查詢時做rollup，過程與pre-aggregation類似，能有效的提高查詢效率，這也是目前主流時序數據庫已經提供或者正在規劃的功能。目前Druid、InfluxDB和KairosDB都提供auto-rollup，OpenTSDB不提供auto-rollup但是暴露了接口支持在外部做auto-rollup後的結果導入。
總結
本篇文章主要分析了時序數據的特性、模型和基本的查詢和處理操作，以及對時序數據庫的基本要求。在下一篇文章中，會對當前比較流行的幾個開源的時序數據庫的實現做分析。你會發現，雖然目前存在那麼多的時序數據庫，但是在基本功能上都是大同小異的。各個時序數據庫各有特色，實現方式也各不同，但是都是圍繞在對時序數據的寫入、存儲、查詢和分析這幾個維度的設計方案的權衡和取舍。沒有一個萬能的時序數據庫解決了所有的問題，在你選擇用何種時序數據庫的時候，需要從業務角度出發，選擇一款最合適的時序數據庫。
當然，如果你有興趣，也可以基於阿裏雲的表格存儲，研發你自己的時序數據庫。歡迎掃碼加入釘釘群與我交流！
最後更新：2017-06-15 23:32:01