時序資料庫（TSDB）－為萬物互聯插上一雙翅膀

時序資料庫（TSDB）是一種特定類型的資料庫，主要用來存儲時序數據。隨著5G技術的不斷成熟，物聯網技術將會使得萬物互聯。物聯網時代之前只有手機、電腦可以聯網，以後所有設備都會聯網，這些設備每時每刻都會吐出大量的按照時間組織的數據，需要存儲下來進行查詢、統計和分析。時序數據和普通的業務數據在各個方面都有很大的不同，本文將會試圖帶大家進入TSDB的世界。

TSDB應用場景：哪些場景會用到TSDB？

TSDB目前最大的應用場景是監控業務（哨兵），以哨兵為例，哨兵會在業務伺服器上部署各種腳本客戶端用來採集伺服器指標數據（IO指標、CPU指標、帶寬內存指標等等），業務相關數據（方法調用異常次數、響應延遲、JVM GC相關數據等等）、資料庫相關數據（讀取延遲、寫入延遲等等），很顯然，這些數據都是時間序列相關的，客戶端採集之後會發送給哨兵伺服器，哨兵伺服器會將這些數據進行存儲，並提供頁面給用戶進行查詢。如下圖所示，用戶可以登錄哨兵系統查看某台伺服器的負載，負載曲線就是按照時間進行繪製的，帶有明顯的時序特徵：

實際上，TSDB的潛力還沒有爆發，至少在現在還沒有。在可預知的未來3~5年，隨著物聯網以及工業4.0的到來，所有設備都會攜帶感測器並聯網，感測器收集的時序數據將嚴重依賴TSDB的實時分析能力、存儲能力以及查詢統計能力。

上圖是一個智慧工廠示意圖，工廠中所有設備都會攜帶感測設備，這些感測設備會實時採集設備溫度、壓力等基本信息，並發送給伺服器端進行實時分析、存儲以及後期的查詢統計。除此之外，比如現在比較流行的各種穿戴設備，以後都可以聯網，穿戴設備上採集的心跳信息、血流信息、體感信息等等也都會實時傳輸給伺服器進行實時分析、存儲以及查詢統計。

TSDB數據示例：什麼是時序數據？

介紹了TSDB的主要應用場景，再來看看時序數據到底是什麼樣的數據。下圖是一份典型的時序數據：

整個圖表徵廣告業務實時行為數據，包括廣告實時瀏覽量、實時點擊量以及實時利潤收入等。圖中分了三個區域，表示時序數據由3個部分構成，分別為維度列、數值列以及時間列。維度列是最左邊的部分，表徵廣告的基本信息，類似於物體標籤，比如廣告平台、廣告主、廣告面向對象以及廣告面向國家等。數值列是中間的部分，表示採集的數值有廣告瀏覽量（impressions）、點擊量（clicks）以及利潤（revenue）。時間列就是一系列的時間點信息。將上圖翻譯成表結構等價於：

TSDB基本特點：時序業務有哪些特點？

時序業務和普通業務在很多方面都有巨大的區別，歸納起來主要有如下幾個方面：

1. 持續產生海量數據，沒有波峰波谷。舉幾個簡單的例子，比如類似哨兵的監控系統，假如現在系統監控1w台伺服器的各類指標，每台伺服器每秒採集100種metrics，這樣每秒鐘將會有100w的TPS。再比如說，現在比較流行的運動手環，假如當前有100w人佩戴，每個手環一秒只採集3種metrcis（心跳、脈搏、步數），這樣每秒鐘也會產生300w的TPS。
2. 數據都是插入操作，基本沒有更新刪除操作。時序業務產生的數據很少有更新刪除的操作，基於這樣的事實，在時序資料庫架構設計上會有很大的簡化。
3. 近期數據關注度更高，未來會更關注流式處理這個環節，時間久遠的數據極少被訪問，甚至可以丟棄。這個很容易理解，哨兵系統我們通常最關心最近一小時的數據，最多看看最近3天的數據，很少去看3天以前的數據。隨著流式計算的到來，時序數據在以後的發展中必然會更關注即時數據的價值，這部分數據的價值毫無疑問也是最大的。數據產生之後就可以根據某些規則進行報警是一個非常常見並重要的場景，報警時效性越高，對業務越有利。
4. 數據存在多個維度的標籤，往往需要多維度聯合查詢以及統計查詢。時序數據另一個非常重要的功能是多維度聚合統計查詢，比如業務需要統計最近一小時廣告主google發布在USA地區的廣告點擊率和總收入分別是多少，這是一個典型的多維度聚合統計查詢需求。這個需求通常對實效性要求不高，但對查詢聚合性能有比較高的要求。

TSDB市場發展：現在都有哪些TSDB產品？

在最近的一年時間裡，隨著物聯網技術的不斷成熟，很多創業者都希望能藉助這個風口得到更多創業機會。試想當年移動互聯網剛興起的時候，也是誕生了一批規模龐大的創業者，而現在，要想在移動互聯網創業，難度已經非常之大，基本可以認為現在移動互聯網創業都是在玩資本、拼乾爹。而物聯網這個市場的競爭力還是非常之小，非常純潔，創業的機會也非常之多。看清楚這樣的事實，很多廠商尤其是公有雲提供商都不約而同的將目光投到這個領域，他們的目標就是籠絡這些小的創業公司。下圖是最近一年各個雲廠商在TSDB的動作，搞個大動作是可以預見的了：

TSDB核心特性：TSDB關注的核心技術點在哪裡？

說了這麼多，是應該看看TSDB到底在技術層面關注哪些核心點了，基於時序業務的基本特點，總結起來TSDB需要關注的技術點主要有這麼幾個：

1. 高吞吐量寫入能力。這是針對時序業務持續產生海量數據這麼一個特點量身定做的，當前要實現系統高吞吐量寫入，必須要滿足兩個基本技術點要求：系統具有水平擴展性和單機LSM體系結構。系統具有水平擴展性很容易理解，單機肯定是扛不住的，系統必須是集群式的，而且要容易加節點擴展，說到底，就是擴容的時候對業務無感知，目前Hadoop生態系統基本上都可以做到這一點；而LSM體系結構是用來保證單台機器的高吞吐量寫入，LSM結構下數據寫入只需要寫入內存以及追加寫入日誌，這樣就不再需要隨機將數據寫入磁碟，HBase、Kudu以及Druid等對寫入性能有要求的系統目前都採用的這種結構。
2. 數據分級存儲/TTL。這是針對時序數據冷熱性質定製的技術特性。數據分級存儲要求能夠將最近小時級別的數據放到內存中，將最近天級別的數據放到SSD，更久遠的數據放到更加廉價的HDD或者直接使用TTL過期淘汰掉。
3. 高壓縮率。提供高壓縮率有兩個方面的考慮，一方面是節省成本，這很容易理解，將1T數據壓縮到100G就可以減少900G的硬碟開銷，這對業務來說是有很大的誘惑的。另一個方面是壓縮後的數據可以更容易保證存儲到內存中，比如最近3小時的數據是1T，我現在只有100G的內存，如果不壓縮，就會有900G的數據被迫放到硬碟上，這樣的話查詢開銷會非常之大，而使用壓縮會將這1T數據都放入內存，查詢性能會非常之好。
4. 多維度查詢能力。時序數據通常會有多個維度的標籤來刻畫一條數據，就是上文中提到的維度列。如何根據隨機幾個維度進行高效查詢就是必須要解決的一個問題，這個問題通常需要考慮點陣圖索引或者倒排索引技術。
5. 高效聚合能力。時序業務一個通用的需求是聚合統計報表查詢，比如哨兵系統中需要查看最近一天某個介面出現異常的總次數，或者某個介面執行的最大耗時時間。這樣的聚合實際上就是簡單的count以及max，問題是如何能高效的在那麼大的數據量的基礎上將滿足條件的原始數據查詢出來並聚合，要知道統計的原始值可能因為時間比較久遠而不在內存中哈，因此這可能是一個非常耗時的操作。目前業界比較成熟的方案是使用預聚合，就是在數據寫進來的時候就完成基本的聚合操作。
6. 未來技術點：異常實時檢測、未來預測等等。

TSDB總結

TSDB將是未來一個非常具有市場性、挑戰性的資料庫，現在雖然已經有這樣那樣的服務，但大多都有這樣那樣的問題，現在很難談得上成熟。為了在物聯網時代、工業4.0時代中佔有一定地位，TSDB是必須要拓展的技術。本文從時序場景、時序業務特點、TSDB市場以及TSDB核心技術點這幾個方面對TSDB進行了介紹，希望看官能基本了解TSDB。後續筆者將會推出針對TSDB的系列專題文章，深入分析TSDB本身所要面對的各種技術問題以及解決方案。

本文為網易工程師心血之作，未經許可請勿轉載！

作者：范欣欣

原文鏈接：時序資料庫－為萬物互聯插上一雙翅膀（本文有刪節）