摘要：為大家帶來當下時序數據模型的主流TSDB分析及雲廠商在時序數據模型方面的最新動態。
本文分享自華為雲社區《【萬字干貨】OpenMetric與時序數據庫存儲模型分析（下）》，作者：敏捷的小智 。
在上篇《【萬字干貨】OpenMetric與時序數據庫存儲模型分析（上）》文章中，我們了解了時序數據模型的相關知識內容，接下來為大家分析當下主流TSDB及雲廠商在書序數據模型方面的最新動態。
主流TSDB分析
InfluxDB
InfluxDB[9]是一個一站式的時序工具箱，包括了時序平台所需的一切：多租戶時序數據庫、UI和儀表板工具、后台處理和監控數據采集器。如下圖9所示。
圖9
InfluxDB支持動態shcema，也就是在寫入數據之前，不需要做schema定義。因此，用戶可以隨意添加measurement、tag和field，可以是任意數量的列。
InfluxDB底層的存儲引擎經歷了從LevelDB到BlotDB，再到自研TSM的歷程。從v1.3起，采用的是基於自研的WAL + TSMFile + TSIFile方案，即所謂的TSM（Time-Structured Merge Tree）引擎。其思想類似LSM，針對時序數據的特性做了一些特殊優化。TSM的設計目標一是解決LevelDB的文件句柄過多問題，二是解決BoltDB的寫入性能問題。
Cache: TSM的Cache與LSM的MemoryTable類似，其內部的數據為WAL中未持久化到TSM File的數據。若進程故障failover，則緩存中的數據會根據WAL中的數據進行重建。
WAL (Write Ahead Log) : 時序數據寫入內存之后按照SeriesKey進行組織。數據會先寫入WAL，再寫入memory-index和cache，最后刷盤，以保證數據完整性和可用性。基本流程包括：根據Measurement和TagKV拼接出乎series key；檢查該series key是否存在；如果存在，就直接將時序數據寫入WAL、時序數據寫緩存；如果不存在，就會在Index WAL中寫入一組entry；依據series key所包含的要素在內存中構建倒排索引、接着把時序數據寫入WAL和緩存。
TSM Files: TSM File與LSM的SSTable類似。在文件系統層面，每一個TSMFile對應了一個 Shard，單個最大2GB。一個TSM File中，有存放時序數據（i.e Timestamp + Field value）的數據區，有存放Serieskey和Field Name信息的索引區。基於 Serieskey + Fieldkey構建的形似B+tree的文件內索引，通過它就能快速定位到時序數據所在的數據塊。在TSMFile中，索引塊是按照 Serieskey + Fieldkey 排序 后組織在一起的。
TSI Files：用戶如果沒有按預期根據Series key來指定查詢條件，比如指定了更加復雜的查詢條件，技術手段上通常是采用倒排索引來確保它的查詢性能的。由於用戶的時間線規模會變得很大，會造成倒排索引消耗過多的內存。對此InfluxDB引入了TSIfiles。TSIFile的整體存儲機制與TSMFile相似，也是以 Shard 為單位生成一個TSIFile。
在InfluxDB中有一個對標傳統RDB的Database概念。邏輯上每個Database下面可以有多個measurement。在單機版中每個Database實際對應了一個文件系統的目錄。
InfluxDB作為時序數據庫，必然包括時序數據存儲和一個用於度量、標記和字段元數據的倒排索引，以提供更快速的多維查詢。InfluxDB在TSMFile上按照下面的步驟掃描數據，以獲得高性能查詢效果：
• 根據用戶指定的時間線（Serieskey）和FieldKey在索引區找到Serieskey+FieldKey所在的 索引數據塊。
• 根據用戶指定的時間戳范圍在索引數據塊中查找數據對應在哪個或哪幾個索引條目
• 把檢索出的索引條目所對應的時序數據塊加載到內存中進一步掃描獲得結果
和 Prometheus 一樣，InfluxDB 數據模型有鍵值對作為標簽，稱為標簽。InfluxDB 支持分辨率高達納秒的時間戳，以及 float64、int64、bool 和 string 數據類型。相比之下，Prometheus 支持 float64 數據類型，但對字符串和毫秒分辨率時間戳的支持有限。InfluxDB 使用日志結構合並樹的變體來存儲帶有預寫日志，按時間分片。這比 Prometheus 的每個時間序列的僅附加文件方法更適合事件記錄。
Prometheus
下圖是Prometheus官方架構圖[10]，包括了一部分生態組件，它們大多是可選項。其中最核心的是Prometheus 服務器，它負責抓取和存儲時間序列數據，並對這些數據應用規則，從而聚合出新的時間序列或生成警報，並記錄存儲它們。
圖10
TSDB是Prometheus的關鍵內核引擎。最新的V3引擎[7]相當於面向TSDB場景優化后的LSM（Log Structured Merge Tree，結構化合並樹）。LSM樹核心思想的核心就是放棄部分讀能力，換取寫入的最大化能力；其假設前提就是內存足夠大。通常LSM-tree適用於索引插入比檢索更頻繁的應用系統。V3存儲引擎也采用了Gorilla論文思想。它包括了下面幾個TSDB組件：塊頭（Head Block）、預寫日志WAL及檢查點、磁盤上Chunk頭的內存映射、持久化block及其索引和查詢模塊。下圖11是Prometheus的磁盤目錄結構。
圖11
在V3引擎中一個chunk內會包含很多的時間線（Time series）。Chunk目錄下的樣本數據分組為一個或者多個段（segment），每個缺省不超過512MB。index是這個block下的chunk目錄中的時間線按照指標名稱和標簽進行索引，從而支持根據某個label快速定位到時間線以及數據所在的chunk。meta.json是一個簡單的關於block數據和狀態的一個描述文件。Chunks_head負責對chunk索引，uint64索引值由文件內偏移量（下4個字節）和段序列號（上4個字節）組成。
Prometheus將數據按時間維度切分為多個block。只有最近的一個block允許接收新數據。最新的block要寫入數據，會先寫到一個內存結構中，為了保證數據不丟失，會先寫一份預寫日志文件WAL，按段（大小128MB ）存儲在目錄中。它們是未壓縮的原始數據，因此文件大小明顯大於常規塊文件。Prometheus 將保留三個或者多個WAL文件，以便保留至少兩個小時的原始數據。
V3引擎將2個小時作為塊（block）的默認塊持續時間；也就是塊按2h跨度來分割（這是個經驗值）。V3也是采用了LSM一樣的compaction策略來做查詢優化，把小的block合並為大的block。對於最新的還在寫數據的block，V3引擎則會把所有的索引全部hold在內存，維護一個內存結構，等到該block關閉再持久化到文件。針對內存熱數據查詢，效率非常高。
Prometheus官方再三強調了它的本地存儲並不是為了持久的長期存儲；外部解決方案提供延長的保留時間和數據持久性。社區有多種集成方式嘗試解決這個問題。比如Cassandra、DynamoDB等。
通過指標實現應用的可觀察性（observability）是IT監控運維系統的第一步。指標提供匯總視圖，再結合日志提供的有關每個請求或事件的明細信息。這樣更容易幫助問題的發現與診斷。
Prometheus 服務器彼此獨立運行，僅依賴其本地存儲來實現其核心功能：抓取、規則處理和警報。也就是說，它不是面向分布式集群的；或者說當前它的分布式集群能力是不夠強大的。社區的Cortex、Thanos等開源項目就是針對Prometheus的不足而涌現出來的成功解決方案。
Druid
Druid[11]是有名的實時OLAP分析引擎。Druid的架構設計比較簡潔（如下圖12）。集群中節點分3類：Master節點、Query節點和Data節點。
圖12
Druid數據存儲在datasource中，類似於傳統RDBMS中的表（table）。每個datasource都按時間（其他屬性也可以）分區（partition）。每個時間范圍稱為一個“塊（Chunk）”（例如，一天，如果您的數據源按天分區）。在一個Chunk內，數據被分成一個或多個 “段（Segment）”。每個段都是一個文件，通常包含多達幾百萬行數據。如下圖13所示。
圖13
Segment的目的在於生成緊湊且支持快速查詢的數據文件。這些數據在實時節點MiddleManager上產生，而且可變的且未提交的。在這個階段，主要包括了列式存儲、bitmap索引、各種算法進行壓縮等。這些Segment（熱數據）會被定期提交和發布；然后被寫入到DeepStorage（可以是本地磁盤、AWS的S3，華為雲的OBS等）中。Druid與HBase類似也采用了LSM結構，數據先寫入內存再flush到數據文件。Druid編碼是局部編碼，是文件級別的。這樣可以有效減小大數據集合對內存的巨大壓力。這些Segment數據一方面被MiddleManager節點刪除，一方面被歷史節點（Historical）加載。與此同時，這些Segment的條目也被寫入元數據（Metadata）存儲。Segment的自描述元數據包括了段的架構、其大小及其在深度存儲中的位置等內容。這些元數據被協調器（Coordinator）用來進行查詢路由的。
Druid 將其索引存儲在按時間分區的Segment文件中。Segment文件大小推薦在 300MB-700MB 范圍內。Segment文件的內部結構，它本質上是列存的：每一列的數據被布置在單獨的數據結構中。通過單獨存儲每一列，Druid 可以通過僅掃描查詢實際需要的那些列來減少查詢延遲。共有三種基本列類型：時間戳列、維度列和指標列，如下圖14所示：
圖14
維度（Dimension）列需要支持過濾和分組操作，所以每個維度都需要以下三種數據結構：
1) 將值（始終被視為字符串）映射到整數 ID 的字典，
2) 列值的列表，使用 1 中的字典編碼。 【服務於group by和TopN查詢】
3) 對於列中的每個不同值，一個指示哪些行包含該值的位圖（本質就是倒排索引，inverted index）。【服務於快速過濾，方便AND和OR運算】
Druid中每列存儲包括兩部分：Jackson 序列化的 ColumnDescriptor和該列的其余二進制文件。 Druid強烈推薦默認使用LZ4壓縮字符串、long、float 和 double 列的值塊，使用Roaring壓縮字符串列和數字空值的位圖。尤其在高基數列場景中匹配大量值的過濾器上Roaring 壓縮算法要快得多（對比CONCISE 壓縮算法）。
值得一提的是Druid支持Kafka Indexing Service插件（extension），實現實時攝入（ingestion）任務，那么此時可以立即查詢該segment，盡管該segment並沒有發布（publish）。這更能滿足對數據的產生到可查詢可聚合分析的實時性要求。
Druid另外一個重要特性就是在數據寫入的時候，可以開啟rollup功能，將選定的所有dimensions 按照你指定的最小時間間隔粒度（比如1分鍾，或者5分鍾等）進行聚合。這樣可以極大的減少需要存儲的數據大小，缺點是原始的每條數據就被丟棄了，不能進行明細查詢了。
Druid為了讓查詢更高效，有如下設計考慮。
• Broker修剪每個查詢訪問哪些Segment：它是 Druid 限制每個查詢必須掃描的數據量的重要方式。首先查詢先進入Broker，Broker 將識別哪些段具有可能與該查詢有關的數據。然后，Broker 將識別哪些Historian和 MiddleManager正在為這些段提供服務，並向這些進程中的每一個發送重寫的子查詢。Historical/MiddleManager 進程將接收查詢、處理它們並返回結果。Broker 接收結果並將它們合並在一起以獲得最終答案，並將其返回給原始調用者。
• Segment內利用索引過濾：每個Segment內的索引結構允許 Druid 在查看任何數據行之前確定哪些（如果有）行與過濾器集匹配。
• Segment內只讀取特定關聯的行和列：一旦 Druid 知道哪些行與特定查詢匹配，它只會訪問該查詢所需的特定列。在這些列中，Druid可以從一行跳到另一行，避免讀取與查詢過濾器不匹配的數據。
時間戳也是Druid數據模型的必備項。盡管Druid不是時序數據庫，但它也是存儲時序數據的自然選擇。Druid數據模型可以支持在同一個datasource中，可以同時存放時序數據和非時序數據。因此，Druid不認為數據點是“時間序列”的一部分，而是將每個點單獨處理以進行攝入和聚合。比如正統的TSDB支持的時序數據插值計算，在Druid中就不復存在的必要了。這會給一些業務場景的處理帶來很大的便利性。
IoTDB
Apache IoTDB[12] 始於清華大學軟件學院，2020年9月為 Apache 孵化器項目。IoTDB 是一個用於管理大量時間序列數據的數據庫，它采用了列式存儲、數據編碼、預計算和索引技術，具有類 SQL 的接口，可支持每秒每節點寫入數百萬數據點，可以秒級獲得超過數萬億個數據點的查詢結果。主要面向工業界的IoT場景。
IoTDB 套件由若干個組件構成，共同形成數據收集、數據攝入、數據存儲、數據查詢、數據可視化、數據分析等一系列功能。如下圖15所示：
圖15
IoTDB 特指其中的時間序列數據庫引擎；其設計以設備、傳感器為核心，為了方便管理和使用時序數據，增加了存儲組（storage group的概念）。
存儲組(Storage Group): IoTDB提出的概念，類似於關系數據庫中的Database的概念。一個存儲組中的所有實體的數據會存儲在同一個文件夾下，不同存儲組的實體數據會存儲在磁盤的不同文件夾下，從而實現物理隔離。對IoTDB內部實現而言，存儲組是一個並發控制和磁盤隔離的單位，多個存儲組可以並行讀寫。對用戶而言，方便了對設備數據的分組管理和方便使用。
設備 (Device)：對應現實世界中的具體物理設備，比如飛機發動機等。在IoTDB中, device是時序數據一次寫入的單位，一次寫入請求局限在一個設備中。
傳感器(Sensor): 對應現實世界中的具體物理設備自身攜帶的傳感器，例如：風力發電機設備上的風速、轉向角、發電量等信息采集的傳感器。在IoTDB中，Sensor也稱為測點（Measurement）。
測點/物理量（Measurement，也稱工況、字段 field）：一元或多元物理量，是在實際場景中傳感器采集的某時刻的測量數值，在IoTDB內部采用<time, value>的形式進行列式存儲。 IoTDB存儲的所有數據及路徑，都是以測點為單位進行組織。測量還可以包含多個分量（SubMeasurement），比如GPS 是一個多元物理量，包含 3 個分量：經度、維度、海拔。多元測點通常被同時采集，共享時間列。
IoTDB的存儲由不同的存儲組構成。每個存儲組是一個並發控制和資源隔離單位。每個存儲組里面包括了多個Time Partition。其中，每個存儲組對應一個WAL預寫日志文件和TsFile時序數據存儲文件。每個Time Partition中的時序數據先寫入Memtable，同時記入WAL，定時異步刷盤到TsFile。這就是所謂的tLSM時序處理算法。
攝入性能方面：IoTDB 具有最小的寫入延遲。批處理大小越大，IoTDB 的寫入吞吐量就越高。這表明 IoTDB 最適合批處理數據寫入方案。在高並發方案中，IoTDB 也可以保持吞吐量的穩定增長（受網卡、網絡帶寬約束）。
聚合查詢性能方面：在原始數據查詢中，隨着查詢范圍的擴大，IoTDB 的優勢開始顯現。因為數據塊的粒度更大，列式存儲的優勢體現出來，所以基於列的壓縮和列迭代器都將加速查詢。在聚合查詢中，IoTDB使用文件層的統計信息並緩存統計信息。多個查詢只需要執行內存計算，聚合性能優勢明顯。
數據存儲對比
基於前面的分析，我們嘗試用下面的表格對比來說明這些時序數據處理系統的特點。
表3
對於時序數據的處理，關鍵能力主要包括數據模型定義、存儲引擎、與存儲緊密協作的查詢引擎和支持分區擴展的架構設計。主流的TSDB基本都是基於LSM或者結合時序數據場景專門優化的LSM tree來實現（包括InfluxDB號稱的TSM，IoTDB的tLSM，本質上都還是LSM機制）。其中只有IoTDB獨創采用了tree schema來對時序數據建模。為了追求極致性能和極致成本，大家都在針對海量數據和使用場景，持續改進和優化數據的存儲結構設計、各種高效索引機制、和查詢效率。從單點技術或者關鍵技術上來講，有趨同性和同質化的大趨勢。
雲廠商最新動態
除了開源社區推陳出新外，國內外眾多雲服務廠商也陸續發布了相關的時序數據庫產品或者服務。
華為雲
華為雲的GaussDB for Influx[13]雲服務，基於InfluxDB進行深度優化改造，在架構、性能和數據壓縮等方面進行了技術創新，取得了很好的效果。實現了存儲與計算分離架構，其中采用了華為雲自研的高性能分布式存儲系統，顯著提升了時序數據庫的可靠性；同時方便計算節點分鍾級擴容和存儲空間的秒級擴容，同時大幅降低存儲成本。支持億級時間線（開源的能力在千萬時間線級別），寫入性能基本保持穩定；能夠支持更高的高散列聚合查詢性能；在壓縮算法上，相比原生的InfluxDB，重點針對Float、String、Timestamp這三種數據類型進行了優化和改進。。
華為雲MRS雲服務包含了IoTDB[14]，其中 IoTDB定位為面向工業設備、工業現場的時序數據庫庫。IoTDB優化后性能更好，千萬級數據點秒級寫入，TB級數據毫秒級查詢；優化后的數據壓縮比可達百倍，進一步節省存儲空間和成本；通過采用對等分布式架構，雙層多Raft協議，邊雲節點同步雙活，做到7*24小時高可用。在工業化場景，真正做到一份時序數據兼容全場景、一套時序引擎打通雲邊端和一套框架集成雲邊端。
阿里雲
據公開資料[15]，阿里雲時序時空數據庫TSDB的發展演變經歷了三個階段。在v1.0階段基於OpenTSDB，底層實現了雙引擎——HBase和HiStore。在v2.0階段中，把OpenTSDB引擎換成了自研的TSDB引擎，彌補了OpenTSDB不支持的倒排索引、面向時序場景的特殊編碼、分布式流計算聚合函數等特性。隨后實現了雲和邊緣計算一體化，TSQL兼容Prometheus生態。其中TSDB for Spatial Temporal支持時空數據，它基於自研的S3時空索引和高性能電子圍欄。最新TSDB同樣基於 Gorilla, 將單個數據點的平均使用存儲空間降為1~2個字節，可以降低90%存儲使用空間，同時加快數據寫入的速度。對於百萬數據點的讀取，響應時間小於 5 秒，且最高可以支撐每秒千萬數據點的寫入。相較於開源的 OpenTSDB 和 InfluxDB，讀寫效率提升了數倍，同時兼容 OpenTSDB 數據訪問協議。
騰訊雲
騰訊雲也推出了TencentDB for CTSDB[16]雲服務，它是一款分布式、可擴展、支持近實時數據搜索與分析的時序數據庫，兼容 Elasticsearch 常用的 API 接口和生態。它支撐了騰訊內部20多個核心業務。性能方面可以做到每秒千萬級數據點寫入，億級數據秒級分析。CTSDB也是采用LSM機制，先寫內存再周期性刷寫到存儲；然后通過倒排索引加速任意維度數據查詢，能實現數據秒級可查。也支持像histogram、percentile、cardinality這樣的通用聚合計算函數；也通過配置 Rollup 任務定時聚合歷史數據保存至新的數據表，實現降精度（Downsampling）特性。在集群中節點數量超過30個時，需要新購集群或者將通用集群架構優化升級為混合節點集群架構，以保證多節點超大集群的性能穩定。從這些特性推斷，CTSDB內核應該是借鑒了ElasticSearch內核深度優化經驗的基礎上構建的時序數據庫能力。
國內其他廠商
除了雲服務廠商提供的開箱即用的雲服務外，還有一些創新型產品涌現出來，比較有名的包括TDengine[17]、字節跳動的TerarkDB[18]、DolphinDB[19]等等。他們也在快速演進發展中，值得大家持續跟蹤關注，尤其是國內孵化出來的一些TSDB產品。
總結與展望
InfluxDB、IoTDB和OpenTSDB等除了社區版本外，也有雲廠商提供原生InfluxDB（阿里雲TSDB for InfluxDB）、IoTDB（華為雲MRS IoTDB）或OpenTSDB（華為雲MRS OpenTSDB）雲化服務，方便使用。更主流的做法是各雲廠商根據自身的技術沉淀和研發實力，借鑒、優化甚至重新研發了時序數據庫內核，能提供更強的集群能力，更高性能寫入，更快的查詢和聚合分析能力。國外廠商AWS有Timestream[20]，一種Serverless時序數據庫服務，國內華為雲的GaussDB for Influx，匯聚頂級數據庫專家團隊打造的新一代時空分析數據庫；騰訊雲的TencentDB for CTSDB，兼容ES生態；阿里雲的HiTSDB等等。這些開箱即用的、可擴展的、高可用的時序數據庫，為雲原生應用的開發與部署帶來了福音，無需管理底層基礎設施，只需專注於業務構建。
Promeheus發展過程中，其需要長期保存的歷史數據（long-term）存儲是其短板之一。業界有一些折中的集成方案。比如采用Cassandra作為Prometheus的持久化存儲；還有采用InfluxDB作為Prometheus的持久化存儲，一方面充分利用Prometheus監控相關能力和社區生態（包括支持分布式集群的Cortex）；另一方面利用好InfluxDB時序數據庫優點，尤其是超PB級的分布式數據庫能力，以彌補Prometheus在海量歷史數據存儲上的短板。
Apache Druid在OLAP即時分析領域有着很強的競爭力，也為眾多大廠所采用。業界最大的集群擁有4000多個節點。不管是時序指標，還是業務數據，應用日志等，都可以利用Druid的Kafka Indexing Service和其強大的數據預處理能力，轉換為時序數據進入Druid。目前Druid SQL特性發展也很快，包括跨表join，subquery和眾多函數、算子的持續豐富。
不管是正統的時序數據庫，還是適合時序數據的OLAP分析系統；不管是開源社區的熱門項目，還是雲廠商提供更強大的雲原生時序數據庫，都為各種時序數據（包括指標、業務數據）的存儲、檢索和分析提供多樣化的選擇。用戶結合自己的業務場景，一定能找到相對適合的工具或服務，滿足業務訴求。
參考資料
[9] https://www.influxdata.com/products/influxdb/
[10] https://prometheus.io/docs/introduction/overview/
[11] https://druid.apache.org/docs/latest/design/architecture.html
[12] https://iotdb.apache.org/SystemDesign/Architecture/Architecture.html
[13] https://bbs.huaweicloud.com/blogs/252115
[14] https://bbs.huaweicloud.com/blogs/280948
[15] https://developer.aliyun.com/article/692580
[16] https://cloud.tencent.com/developer/article/1010045
[17] https://www.taosdata.com/cn/
[18] https://github.com/bytedance/terarkdb
[19] https://www.dolphindb.cn/
[20] https://aws.amazon.com/cn/timestream