海量時序資料低成本存儲架構設計

作者：王潭潭(俟命) 阿裡雲基礎産品團隊

一、導讀

近些年來得益于傳感器技術、無線網絡技術、雲計算和人工智能技術的發展，物聯網的基礎設施日益完善，并應用到了新能源、智能家居、車聯網、智慧工業等衆多領域中，實作了“人與物”、“物與物”之間的互聯。物聯網給各行各業帶來紅利的同時，也給目前的技術帶來了巨大的挑戰，其中最關鍵的就是資料規模的急劇增長。根據IDC報告，到2025年物聯網資料規模将達到79.4ZB，尋找合适的物聯網資料存儲解決方案自然變得非常重要。本文将結合物聯網的資料特點和業務特性來解讀如何降低資料存儲成本，以及對比業内一些時序資料存儲的實作方式。

二、物聯網存儲場景解讀

物聯網資料的産生是基于傳感器采集的裝置狀态、事件、消息等資料，裝置根據自身的類型使用對應的物聯網通信協定接入到資料網關（IoT 網關），最後轉發到存儲，這是物聯網資料流轉到存儲的通用鍊路。但是由于這些資料的應用場景不同，決定了其對存儲架構的需求差異。例如業務上如果存儲的是裝置最新狀态資訊，那麼每台裝置隻會對應一行裝置狀态資料（中繼資料），這個資料量級是由裝置數決定的，一般在百萬級，對于存儲的需求更偏向于支援高TPS和索引能力。

另一種場景是業務上存儲的是裝置所有曆史狀态或者曆史事件資料，那麼裝置數與資料量是1對N的關系，資料總量與裝置數和存儲時間範圍正相關。以車輛軌迹資料存儲為例，每輛汽工廠中的房間隔一段時間就會上報一個GPS點，那麼就需要存儲一段時間内所有車輛上報的曆史坐标，用于檢視行車軌迹和位置，通常這類資料被稱為時間序列資料（Timeseries Data）。時序資料的特點與通路模式都與傳統網際網路資料有非常大的差異，這導緻其對于存儲架構有着特殊的要求。

三、時序資料特點和讀寫模式

在解讀時序資料存儲架構之前，首先需要了解一下時序資料的一些概念和特點。通常來說，一個經典的時序資料模型包括：資料源（datasource），标簽（tags），時間戳（timestamp），度量名額（mertics）。資料源 + 标簽表示獨立的時間線，資料源 + 标簽 + 時間戳表示獨立的時間點。

例如我們構造了一組時序資料樣例，将其映射到二維表結構上如下圖所示，圖中包含了三組時間線，每一個時間線代表了裝置個體的曆史資料變化。其中資料源（datasource）和 tags（标簽）用于區分裝置，不同的裝置型号的度量名額（mertics）不一樣。

從中可以總結出如下幾個特點：

1、資料源唯一

時序資料總是由固定裝置産生，不同裝置之間産生資料的過程互相獨立。這一點對于資料的通路性能和存儲空間都有着非常大的優化空間。

2、名額次元多

物聯網裝置種類非常複雜，每種類型的裝置度量名額大不一樣，例如A類型裝置上報的是溫度、濕度，而B類型裝置上報的是壓力值。存儲所有裝置的度量名額所需要定義的字段會達到幾十個甚至上百個，且會動态增加。如果使用關系型資料庫來存儲，則需要根據字段數的動态變化頻繁修改資料表 schema，這顯然是不能接受的。如果按照裝置類型分表存儲，那麼當業務上對多種類型裝置聚合分析時，就需要多表 join，這不僅會提高業務代碼的複雜度，同時會降低查詢的性能。

3、時間順序産生

時序資料是按照固定的周期或者是某個事件觸發上報的，每一行時序資料都會帶有資料上報時間戳 timestamp 屬性。通常情況下，同一個裝置下的時序資料是按照時間遞增的，并且很少會有更新某一行時序資料的請求。

4、資料冷熱明顯

業務上更多關注的是裝置最近一段時間的狀态，例如查詢車輛近一段時間的軌迹，而很少會查詢一年前的車輛軌迹。時序資料的價值會随着時間推移而降低，是以距離目前時間越近的資料通路頻率要遠高于時間更早的資料。

5、多元度聚合分析

時序資料的業務場景中經常存在面向時間範圍的多元度互動查詢和聚合分析。以上圖資料為例：分析一個月内 model = "A 的所有裝置平均溫度。這類分析請求包含了多條時間線。

四、時序資料存儲如何設計

基于上述對時序資料特點和業務讀寫模式的分析，可以給出時序資料存儲的設計目标：大規模低成本資料存儲、高 TPS 寫入、高效資料分析。要實作這幾個目标，可以從 更細粒度的資源控制、更低單價的存儲媒體、更高的資料壓縮率、更高的副本使用率 四個方向進行優化。

4.1 更細的資源控制粒度

資源可以分為存儲資源和計算資源。要實作對資源更細粒度的控制，就需要将計算層與存儲層解耦。首先我們來看一下幾種存儲計算架構。

4.1.1 單機架構

單點架構是最簡單的一種存儲架構，單台機器節點上包含了存儲服務和磁盤，所有的讀寫請求都會發送到一台機器上。當機器出現故障時，整個存儲服務将變為不可用的狀态，這無法滿足不了時序資料存儲的可用性需求。

4.1.2 分布式存算耦合

為了解決存儲服務的可用性問題，可以采用主從叢集架構。寫入請求先發送到主節點（primary node）上，再基于分布式一緻性協定将資料全量同步到其他節點中，這樣可以保證存儲服務的可用性和可靠性。但是從成本角度分析，假設每個節點都是寫入本地磁盤，在不考慮節點内資料備援的情況下，則需要分别預留三份存儲資源和計算資源。

4.1.3 分布式存算分離

計算層：計算層是一組無狀态節點組成的叢集，具有更好的可擴充性。計算層分離還有一個好處，由于時序資料的讀寫是相對不均衡的，寫入流量是取決于裝置數和上報周期，基本是穩定的；而讀取流量取決于業務，存在一定的波動性。這就可以将計算層按照讀和寫進一步分離，可以做到為讀取和寫入分别預留适當的計算資源。

存儲層：存儲層選擇分布式存儲，例如 HDFS、對象存儲等。同時可以按照時序資料的通路特性進行分層存儲，将不同時間段的資料分别存儲到單價不同的存儲媒體中，做到精細化存儲。

4.2 更低單價的存儲

4.2.1 區分冷熱資料

近期寫入的時序資料我們可以将其看作為熱資料（Hot Data），而寫入時間更早的資料我們可以看作為冷資料（Cold Data）。熱資料具有高 TPS、寫入時間近的特點，通常用于高頻的單個時間線查詢，例如查詢某台車輛近期的行駛軌迹；冷資料具有規模大、極少修改、寫入時間早的特點，通常用于低頻的多個時間線互動式分析，例如計算某個型号所有裝置的平均能耗值。

時序資料的通路頻率會随着時間推移呈現出由熱到冷的趨勢，正是由于不同時間範圍的時序資料通路特性不一樣，對于底層存儲的性能要求也有所差異。利用這一點可以描繪出一個資料分層存儲架構。

4.2.2 分層存儲

存儲優化的思路是對時序資料分層存儲。結合上述不同時間範圍的時序資料通路頻率的差異，存儲層可以采用多種存儲媒體和存儲方式來分别負責熱資料和冷資料的存儲，進而在保證性能的同時最大化地降低存儲成本。

存儲單價按照由高到低可以分為固态硬碟（SSD）、混合硬碟（HHD）、機械硬碟（HDD），另外還包括存儲密度更大、單價更低的對象存儲（Object Store）。

由于熱資料對于存儲的性能要求較高，通常可以使用 SSD 或 HHD 存儲。而冷資料的規模很大，更多關注的是存儲成本的大小，那麼存儲單價更低的對象存儲更為合适。如下圖展示了時序資料分層存儲的架構：

4.2.3 資料存儲格式

冷熱資料的業務通路模式決定了适用的存儲格式，常見的資料存儲格式分為基于行的存儲和基于列的存儲。

熱資料的讀寫模式包括高并發寫入、小範圍掃描，這個場景行存儲更為合适。行存儲的優點是磁盤的單個塊中可能包含整行所有字段，查詢整行資料時有利于減少範圍查詢時的磁盤 I/O 次數。存儲側基于 LSM 引擎，利用了磁盤順序寫性能大于随機寫性能的特點，提高寫入速度。

冷資料基本不會更新，業務查詢的方式通常是多個時間線的互動分析，這一特性非常适合采用按列組織存儲。列存是面向讀優化的（Read-Optimized），适用于資料分析的場景。時序場景中經常會分析裝置的一些名額，例如求和、求均值等，如果采用行存儲，則會讀取到其他不參與計算的列，這将會降低分析性能。而列存格式可以避免掃描非相關列的問題，多個列的資料分析可以并行執行。另外列存格式資料之間的相關性更高，這意味着列存資料可以有更高的壓縮率，有利于降低存儲量，也能降低分析時的 I/O 量。

4.3 更高的資料壓縮率

時序資料采用列存格式存儲，資料之間的相關性較高，這就可以采用資料編碼和壓縮算法對裝置上報的原始資料進行壓縮，使得最終存儲的資料量減少。一些時序資料庫内置的壓縮功能可以将資料量壓縮到十倍甚至二十倍以上，進而降低存儲成本。例如同一個裝置上報的資料必然會包含裝置元屬性的備援，例如上文提到的 datasource、tags 等，重複存儲這些資料會浪費大量的存儲資源，那麼就可以針對這部分資料做一個去重優化。再比如時序資料中的 timestamp 屬性，同一個裝置上報的 timestamp 相對而言有比較明顯的規律，下面我們以二階差分編碼（delta-of-delta）對時間戳的壓縮舉例：

delta-of-delta 算法

時序資料中每一個資料點（一行資料）都會包含時間戳字段，如果按照時間戳的原始值進行存儲，那麼每一個時間戳值都會占用 64 bit，這則會造成存儲成本的增加。我們知道對于同一時間線的時序資料中的 timestamp 值都是順序遞增的，并且非常可能是以等差數列增長（取決于裝置上報周期）。利用這一特點，可以采用數值壓縮算法（delte-of-delta）來對時間戳進行壓縮，本質上是存儲兩行資料之間的時間戳內插補點，這個存儲大小将遠遠小于原始值。例如下圖展示了存儲原始時間戳和壓縮後的時間戳，所占用的空間大小對比：

存儲格式	原始時間戳	delta	‍‍‍delta-of-delta
存儲值	1658214010922
1658214010932	10	10
1658214010942	10
1658214010952	10
1658214010972	20	10
存儲大小	320 bit	109 bit	85 bit

可以看出經過 delta-of-delta 編碼壓縮後的存儲大小相對于原始的資料大小下降了三倍以上，事實上時序資料庫都會采用例如 XOR、Delta、Zigzag 等算法對不同資料類型的原始資料進行壓縮編碼，進而達到降低存儲空間和成本的目的，資料壓縮率也成為了衡量一款時序資料存儲産品性能的名額之一。

4.4 更高的副本空間使用率

副本機制是保證資料高可靠的方案，副本的數量是影響時序資料存儲成本的重要因素之一。正常的做法是使用三副本來保證資料的可靠性，但是這種方式實際上隻有一份資料會被使用到，得盤率僅有 33.3%。而使用糾删碼（Erasure-Code）可以大大得提高得盤率，減少實際存儲的副本大小。例如采用“ EC 8+2”的得盤率能夠提高到80%，關于EC的原理不在本文做介紹。由于EC機制會将資料拆分到多個 block 中存儲，那麼當對小塊資料随機讀寫時，就需要同時讀寫多個 block，這會造成 I/O 放大的問題，但是對于大塊資料順序讀寫場景，多個 block 并發讀寫能夠提升性能。時序資料場景中，都會基于 LSM 引擎将随機寫優化成順序寫，并且資料落盤前都會合并成一個大的資料塊，這一特點可以避免 EC 機制帶來的問題。是以通過 EC 來保證時序資料的可靠性，能在保證性能的同時減少存儲成本。

五、總結

物聯網中時序資料具有規模大、更新少、冷熱明顯等特點，這決定了其如何被高效地存儲和分析。我們可以從業内常見的時序資料存儲設計選擇上做分析。

例如 DB-Engines 時序資料庫系列排行第一的産品 InfluxDB，其本身是僅支援本地盤存儲的，是一種明顯的存算耦合架構，存儲上無法做到靈活選擇。2020 年 InfluxDB 官方宣布重構底層存儲引擎，推出新時序存儲項目 InfluxDB_IOx，設計上對資源重新配置設定、存儲層選擇本地盤 + AWS S3 混存，這正是上述設計思路的展現（感興趣的讀者可以閱讀 InfluxDB IOx 解析）。

再例如阿裡雲表格存儲 Tablestore 2022 年正式商業化的物聯網存儲 IoTstore，選擇讀、寫、存儲三層分離架構，依托雲原生的 Serverless 屬性，相對于開源時序存儲具備資源彈性控制的成本優勢。同時 IoTstore 将時序資料進一步按時間範圍劃分成熱、溫、冷資料，采用行列混存設計，底層選擇多級分層存儲，實作存儲粒度上精确切分。除了上述的産品外，業内還有許多其他各具特色的時序存儲産品，下圖做了一個簡單的歸納：

時序存儲	存儲架構	冷熱存儲	高可靠政策	資料壓縮
InfluxDB	存算耦合	不支援	/	支援
表格存儲 Tablestore	存算分離	支援	EC	支援
AWS Timestream	存算分離	支援	多副本	支援
OpenTSDB	存算分離	不支援	EC	支援

時序資料存儲基于存儲計算分離、冷熱分層存儲、資料壓縮、EC 等技術方向進行優化，以達到更細資源控制粒度、更多層級的冷熱存儲、更高的資料壓縮率、更高的副本使用率的目的。這些時序存儲設計更多的是成本與性能之間的考量。