1、時序數據及時序數據庫概述一、什么是時間序列？這類數據描述了某個被測量的主體在一個時間范圍內的每個時間點上的測量值。對時序數據進行建模的話，會包含三個重要部分，分別是:主體，時間點和測量值。時間系列數據的特性二、時序數據寫入的特點寫入平穩、持續、高并發高吞吐：時序數據的寫入是比較平穩的，這點與應用數據不同，應用數據通常與應用的訪問量成正比，而應用的訪問量通常存在波峰波谷。時序數據的產生通常是以一個固定的時間頻率產生，不會受其他因素的制約，其數據生成的速度是相對比較平穩的。時序數據是由每個個體獨立生成，所以當個體數量眾多時，通常寫入的并發和吞吐量都是比較高的，特別是在物聯網場景下。寫入并發和吞吐量

2、，可以簡單的通過個體數量和數據生成頻率來計算，例如若你有1000個個體以10秒的頻率產生數據，則你平均每秒產生的并發和寫入量就是100。2.寫多讀少：時序數據上95%-99%的操作都是寫操作，是典型的寫多讀少的數據。這與其數據特性相關，例如監控數據，你的監控項可能很多，但是你真正去讀的可能比較少，通常只會關心幾個特定的關鍵指標或者在特定的場景下才會去讀數據。2.3.實時寫入最近生成的數據，無更新：時序數據的寫入是實時的，且每次寫入都是最近生成的數據，這與其數據生成的特點相關，因為其數據生成是隨著時間推進的，而新生成的數據會實時的進行寫入。數據寫入無更新，在時間這個維度上，隨著時間的推進，每次數

3、據都是新數據，不會存在舊數據的更新，不過不排除人為的對數據做訂正。3.數據查詢和分析的特點1.按時間范圍讀取：通常來說，你不會去關心某個特定點的1.按時間范圍讀取：通常來說，你不會去關心某個特定點的數據，而是一段時間的數據。所以時序數據的讀取，基本數據，而是一段時間的數據。所以時序數據的讀取，基本都是按時間范圍的讀取。2.最近的數據被讀取的概率高:最近的數據越有可能被讀2.最近的數據被讀取的概率高:最近的數據越有可能被讀取，以監控數據為例，你通常只會關心最近幾個小時或最近幾天的監控數據，而極少關心一個月或一年前的數據。3.多精度查詢：按數據點的不同密集度來區分不同的精度，例如若相鄰數據點的間隔

4、周期是10秒，則該時序數據的精度就是10秒，若相鄰數據點的時間間隔周期是30秒，則該時序數據的精度就是30秒。時間間隔越短，精度越高。精度越高的數據，能夠還原的歷史狀態更細致更準確，但其保存的數據點會越多。這個就好比相機的像素，像素越高，照片越清晰但是相片大小越大。時序數據的查詢，不需要都是高精度的，這是實際的需求，也是一種取舍，同樣也是成本的考慮。還是拿監控數據舉例，通常監控數據會以曲線圖的方式展現，由人的肉眼去識別。在這種情況下，單位長度下若展示的數據點過于密集，反而不利于觀察，這是實際的需求。而另外一種取舍是，若你查詢一個比較長的時間范圍，比如是一個月，若查詢10秒精度的數據需要返回25

5、9200個點，而若查詢60秒精度的數據則只要返回43200個點，這是查詢效率上的一種取舍。而成本方面的考慮，主要在存儲的數據量上，存儲高精度的數據需要的成本越高，通常對于歷史數據，可以不需要存儲很高精度的數據。總的來說，在查詢和處理方面，會根據不同長度的時間范圍，來獲取不同精度的數據，而在存儲方面，對于歷史的數據，會選擇降精度的數據存儲。3.多維分析：時序數據產生自不同的個體，這些個體擁有不同的屬性，可能是同一維度的，也可能是不同維度的。還是舉個監控的例子，我有個對某個集群上每臺機器的網絡流量的監控，此時可以查詢這個集群下某臺機器的網絡流量，這是一個維度的查詢，而同時還需要查詢這個集群總的網絡

6、流量，這是另外一個維度的查詢。5.數據挖掘：隨著大數據和人工智能技術的發展，在存儲、計算能力以及云計算發展的今天，數據的高附加值的挖掘已經不再有一個很高門檻。而時序數據蘊含著很高的價值，非常值得挖掘。5.四、數據存儲的特點1.數據量大：拿監控數據來舉例，如果我們采集的監控數據的時間間隔是1s，那一個監控項每天會產生86400個數據點，若有10000個監控項，則一天就會產生864000000個數據點。在物聯網場景下，這個數字會更大。整個數據的規模，是TB甚至是PB級的。1.2.冷熱分明：時序數據有非常典型的冷熱特征，越是歷史的數據，被查詢和分析的概率越低。2.3.具有時效性：時序數據具有時效性，

7、數據通常會有一個保存周期，超過這個保存周期的數據可以認為是失效的，可以被回收。一方面是因為越是歷史的數據，可利用的價值越低；另一方面是為了節省存儲成本，低價值的數據可以被清理。3.1.2.3.4.多精度數據存儲：在查詢的特點里提到時序數據出于存儲成本和查詢效率的考慮，會需要一個多精度的查詢，同樣也需要一個多精度數據的存儲。五、時序數據庫基本要求綜合以上對于時序數據寫入、查詢和存儲的特點的分析，我們可以歸納總結下對于時序數據庫的基本要求:能夠支撐高并發、高吞吐的寫入：如上所說，時序數據具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權衡的是寫的能力。由于其場景的特點，對于

8、數據庫的高并發、高吞吐寫入能力有很高的要求。交互級的聚合查詢：交互級的查詢延遲，并且是在數據基數（TB1.2.3.4.多精度數據存儲：在查詢的特點里提到時序數據出于存儲成本和查詢效率的考慮，會需要一個多精度的查詢，同樣也需要一個多精度數據的存儲。五、時序數據庫基本要求綜合以上對于時序數據寫入、查詢和存儲的特點的分析，我們可以歸納總結下對于時序數據庫的基本要求:能夠支撐高并發、高吞吐的寫入：如上所說，時序數據具有典型的寫多讀少特征，其中95%-99%的操作都是寫。在讀和寫上，首要權衡的是寫的能力。由于其場景的特點，對于數據庫的高并發、高吞吐寫入能力有很高的要求。交互級的聚合查詢：交互級的查詢延遲

9、，并且是在數據基數（TB級）較大的情況下，也能夠達到很低的查詢延遲。能夠支撐海量數據存儲：場景的特點決定了數據的量級，至少是18的量級，甚至是PB級數據。高可用：在線服務的場景下，對可用性要求也會很高。5.分布式架構：寫入和存儲量的要求，底層若不是分布式架構基本達不到目標。5.背景結合時序數據的特點和時序數據庫的基本要求的分析，使用基于LSM樹存儲引擎的NoSQL數據庫（例如HBase、Cassandra或阿里云表格存儲等）相比使用B+樹的RDBMS，具有顯著的優勢。LSM樹的基本原理不在這里贅述，它是為優化寫性能而設計的，寫性能相比B+樹能提高一個數量級。但是讀性能會比B+樹差很多，所以極其

10、適合寫多讀少的場景。目前開源的幾個比較著名的時序數據庫中，OpenTSDB底層使用HBase、BlueFlood和KairosDB底層使用Cassandra，InfluxDB底層是自研的與LSM類似的TSM存儲引擎，Prometheus是直接基于LevelDB存儲引擎。所以可以看到，主流的時序數據庫的實現，底層存儲基本都會采用1$乂樹加上分布式架構，只不過有的是直接使用已有的成熟數據庫，有的是自研或者基于LevelDB自己實LSM樹加分布式架構能夠很好的滿足時序數據寫入能力的要求，但是在查詢上有很大的弱勢。如果是少量數據的聚合和多維度查詢，勉強能夠應付，但是若需要在海量數據上進行多維和聚合查詢

11、，在缺乏索引的情況下會顯得比較無力。所以在開源界，也有其他的一些產品，會側重于解決查詢和分析的問題，例如Druid主要側重解決時序數據的OLAP需求，不需要預聚合也能夠提供在海量數據中的快速的查詢分析，以及支持任意維度的drilldown。同樣的側重分析的場景下，社區也有基于ElasticSearch的解決方案。總之，百花齊放的時序數據庫產品，各有優劣，沒有最好的，只有最合適的，全憑你自己對業務需求的判斷來做出選擇。六、時間序列數據的模型時序數據的數據模型主要有這么幾個主要的部分組成：1.主體：被測量的主體，一個主體會擁有多個維度的屬性。以服務器狀態監控場景舉例，測量的主體是服務器，其擁有的屬

12、性可能包括集群名、Hostname等。1.2.測量值：一個主體可能有一個或多個測量值，每個測量值對應一個具體的指標。還是拿服務器狀態監控場景舉例，測量的指標可能會有CPU使用率，IOPS等，CPU使用率對應的值可能是一個百分比，而IOPS對應的值是測量周期內發生的IO次數。2.3.時間戳：每次測量值的匯報，都會有一個時間戳屬性來表示其時間。3.目前主流時序數據庫建模的方式會分為兩種，按數據源建模和按指標建模，以兩個例子來說明這兩種方式的不同。按數據源建模如圖所示為按數據源建模的例子，同一個數據源在某個時間點的所有指標的測量值會存儲在同一行。Druid和InfluxDB采用這種模式。按指標建模m

13、etrictimestampclusterhostnamemetricvaluecpu2015-04-23717:50:002Cluster-Ahost-a10cpu2015-04-2&T17:50:10ZCluster-Ahost-b20cpu2015-04-28T17:50:202Cluster-Ahosba5iopS2015-04-23717:50:002Cluster-Ahost-a10iops2015-04-28T17:50:102Cluster-Aliost-b30iops2015-04-28T17:50:202Cluster-Ahosba8測量指標時向戳主體“維度測星值如圖所示為

14、按指標建模的例子，其中每行數據代表某個數據源的某個指標在某個時間點的測量值。OpenTSDB和KairosDB采用這種模式。這兩種模型的選擇沒有明確的優劣，如果底層是采用列式存儲且每個列上都有索引，則按數據源建模可能是一個比較干凈的方式。如果底層是類似HBase或Cassandra這種的，將多個指標值存儲在同一行會影響對其中某個指標的查詢或過濾的效率，所以通常會選擇按指標建模。七、時間序列數據的處理這一小節會主要講解下對時序數據的處理操作，時序數據庫除了滿足基本的寫和存儲的需求外，最重要的就是查詢和分析的功能。對時序數據的處理可以簡單歸納為Filter（過濾），Aggregation（聚合）、

15、GroupBy和Downsampling（降精度）。為了更好的支持GroupBy查詢，某些時序數據庫會對數據做pre-aggregation（預聚合）。Downsampling對應的操作是Rollup（匯總），而為了支持更快更實時的Rollup，通常時序數據庫都會提供auto-rollup（自動匯總）。Filter（過濾）metrictimestampclusterhostnamemetricvaluecpu2Q15-04-28T17:50:00ZCluster-Ahost-a10cpu2015-04-28T17:50:OOZCluster#host-b20cpu2O15-O4-28T17：5

16、O：1OZCluster-Aho$t*a6cpu2015-04-28T17:50:10ZCluster-Ahost-b10cpu20l5-04-23T17:50:20ZCluster-A30cpu2015-04-28T17:50:20ZCluster-Ahost-b8selectcpufromtablewhereclustef=Cluster-A,andhostname二力口st田metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17:50:00ZCluster-Ahost-a10cpu2015-04-28T17:50:10ZClus

17、ter-Ahost-a6cpu2015-04-28T1750:20ZCluster-Ahost-a30如圖所示就是一個簡單的Filter處理，簡單的說，就是根據給定的不同維度的條件，查找符合條件的所有數據。在時序數據分析的場景，通常先是從一個高維度入手，后通過提供更精細的維度條件，對數據做更細致的查詢和處理。Aggregation（聚合）聚合是時序數據查詢和分析的最基本的功能，時序數據記錄的是最原始的狀態變化信息，而查詢和分析通常需要的不是原始值，而是基于原始值的一些統計值。Aggregation就是提供了對數據做統計的一些基本的計算操作，比較常見的有SUM（總和）、AVG（平均值）、Max（

18、最大值）、TopN等等。例如對服務器網絡流量的分析，你通常會關心流量的平均值、流量的總和或者流量的峰值。GroupBy和Pre-aggregation(預聚合)metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17：50：DOZCluster-Ahost-a10cpu2015-D4-?8T17:50:OOZCluster-Ahost-b20cpu201504-28T17：50：10ZCluster-Ahost-a6cpu2015-04-28T17：50：10ZCluster-Ahost-b10cpu2015-04-28117:50:2

19、02Cluster-Ahost-a30cpu2015-04-28T17:50:20ZCluster-Ariost-b8selectayg(cpu)fromEablegroupbyClustermetrictimestampclustermetricvalue(avg)cpu2CH5-O4-28T17;5O;OOZCluster-A15cpu2CH5-O48T17;5O:1OZCluster-A8cpu2015-04-28T17:50:207Cluster-A19GroupBy就是將一個低維度的時序數據轉換為一個高維度的統計值的過程，如圖就是一個簡單的GroupBy的例子。GroupBy一般發生

20、在查詢時，查詢到原始數據后做實時的計算來得到結果，這個過程有可能是很慢的，取決于其查詢的原始數據的基數。主流的時序數據庫提供preaggregation（預聚合）的功能來優化這一過程，數據實時寫入后就會經過預聚合的運算，生成按指定規則GroupBy之后的結果，在查詢時就可以直接查詢結果而不需要再次計算。00小$111）8（降精度），Rollup（匯總）和Auto-rollup（自動匯總）Downsampling就是將一個高精度的時序數據轉換為一個低精度的時序數據的過程，這個過程被稱作Rollup。它與GroupBy的過程比較類似，核心區別是GroupBy是基于相同的時間粒度，把同一時間層面上的

21、不同維度的數據做聚合，轉換后的結果還是相同時間粒度的數據，只不過是更高的一個維度。而Downsampling是不同時間層面上把相同維度的數據做聚合，抓換為更粗時間粒度的數據，但是還是擁有相同的維度。metrictimestampclusterhostnamemetricvaluecpu2015-04-28T17:50:307Cluster-Anost-a10cpu2015-04-28T17:50：10ZCluster-Anost-a20cpu2015-04-28T17:50:20ZCluster-Ahost-a6cpu2015-04-28T17:50：30ZCluster-Ahost-a10c

22、pu2015-04-28T17:50：40ZCllister-Ahost-a30cpu201504-28T17:50：50ZCluster-Anost-a8downsamplingfromintferval(IO)tointerval(30),metrictimestampclusterhostnamemetricvalue(avg)cpu2015-04-28T17:5000ZCluster-Ahost-a12cpu2015-04-28T17；5030ZCluster-Ahost-a16如圖就是一個簡單的Downsampling的例子，將一個10秒精度的數據聚合成30秒精度的數據，統計平均值。

23、Downsampling分為存儲降精度和查詢降精度，存儲降精度的意義在于降低存儲成本，特別是針對歷史數據。查詢降精度主要是針對較大時間范圍的查詢，來減少返回的數據點。不管是存儲降精度還是查詢降精度，都需要auto-rollup。auto-rollup就是自動的對數據做rollup，而不是等待查詢時做rollup，過程與pre-aggregation類似，能有效的提高查詢效率，這也是目前主流時序數據庫已經提供或者正在規劃的功能。目前Druid、InfluxDB和KairosDB都提供auto-rollup，OpenTSDB不提供autorollup但是暴露了接口支持在外部做auto-rollup

24、后的結果導入。八、總結本篇文章主要分析了時序數據的特性、模型和基本的查詢和處理操作，以及對時序數據庫的基本要求。在下一篇文章中，會對當前比較流行的幾個開源的時序數據庫的實現做分析。你會發現，雖然目前存在那么多的時序數據庫，但是在基本功能上都是大同小異的。各個時序數據庫各有特色，實現方式也各不同，但是都是圍繞在對時序數據的寫入、存儲、查詢和分析這幾個維度的設計方案的權衡和取舍。沒有一個萬能的時序數據庫解決了所有的問題，在你選擇用何種時序數據庫的時候，需要從業務角度出發，選擇一款最合適的時序數據庫。數據的存儲數據的存儲可以分為兩個問題，單機上存儲和分布式存儲。單機存儲如果只是存儲起來，直接寫成日志

25、就行。但因為后續還要快速的查詢，所以需要考慮存儲的結構。傳統數據庫存儲采用的都是Btree，這是由于其在查詢和順序插入時有利于減少尋道次數的組織形式。我們知道磁盤尋道時間是非常慢的，一般在10ms左右。磁盤的隨機讀寫慢就慢在尋道上面。對于隨機寫入8tree會消耗大量的時間在磁盤尋道上，導致速度很慢。我們知道SSD具有更快的尋道時間，但并沒有從根本上解決這個問題。對于90%以上場景都是寫入的時序數據庫，Btree很明顯是不合適的。業界主流都是采用LSMtree替換Btree，比如Hbase,Cassandra等nosql中。這里我們詳細介紹一下。LSMtree包括內存里的數據結構和磁盤上的文件兩

26、部分。分別對應Hbase里的MemStore和HLog；對應Cassandra里的MemTable和sstable。LSMtree操作流程如下：數據寫入和更新時首先寫入位于內存里的數據結構。為了避免數據丟失也會先寫到WAL文件中。內存里的數據結構會定時或者達到固定大小會刷到磁盤。這些磁盤上的文件不會被修改。隨著磁盤上積累的文件越來越多，會定時的進行合并操作，消除冗余數據，減少文件數量。HbaseLSMtree結構介紹（注1）可以看到LSMtree核心思想就是通過內存寫和后續磁盤的順序寫入獲得更高的寫入性能，避免了隨機寫入。但同時也犧牲了讀取性能，因為同一個key的值可能存在于多個HFile中。

27、為了獲取更好的讀取性能，可以通過bloomfilter和compaction得到，這里限于篇幅就不詳細展開。分布式存儲時序數據庫面向的是海量數據的寫入存儲讀取，單機是無法解決問題的。所以需要采用多機存儲，也就是分布式存儲。分布式存儲首先要考慮的是如何將數據分布到多臺機器上面，也就是分片（sharding）問題。下面我們就時序數據庫分片問題展開介紹。分片問題由分片方法的選擇和分片的設計組成。分片方法時序數據庫的分片方法和其他分布式系統是相通的。哈希分片：這種方法實現簡單，均衡性較好，但是集群不易擴展。一致性哈希：這種方案均衡性好，集群擴展容易，只是實現復雜。代表有Amazon的DynamoDB和

28、開源的Cassandra。范圍劃分：通常配合全局有序，復雜度在于合并和分裂。代表有Hbase。分片設計分片設計簡單來說就是以什么做分片，這是非常有技巧的，會直接影響寫入讀取的性能。結合時序數據庫的特點，根據metric+tags分片是比較好的一種方式，因為往往會按照一個時間范圍查詢，這樣相同metric和tags的數據會分配到一臺機器上連續存放，順序的磁盤讀取是很快的。再結合上面講到的單機存儲內容，可以做到快速查詢。進一步我們考慮時序數據時間范圍很長的情況，需要根據時間范圍再將分成幾段，分別存儲到不同的機器上，這樣對于大范圍時序數據就可以支持并發查詢，優化查詢速度。如下圖，第一行和第三行都是同

29、樣的tag（sensor=95D8-7913；city二上海），所以分配到同樣的分片，而第五行雖然也是同樣的tag,但是根據時間范圍再分段，被分到了不同的分片。第二、四、六行屬于同樣的tag（sensor=F3CC-20F3;city=北京）也是一樣的道理。時序數據分片說明真實案例下面我以一批開源時序數據庫作為說明。InfluxDB非常優秀的時序數據庫，但只有單機版是免費開源的，集群版本是要收費的。從單機版本中可以一窺其存儲方案：在單機上InfluxDB采取類似于LSMtree的存儲結構TSM；而分片的方案InfluxDB先通過+（事實上還要加上retentionPolicy）確定ShardGroup，再通過+的hashcode確定到具體的Shard。這里timestamp默認情況下