林青 阿里技術

隨著 IoT 技術的快速發展，物聯網裝置產生的資料呈爆炸式增長，資料的總量（Volume）、資料型別越來越多（Variety）、訪問速度要求越來越快（Velocity）、對資料價值（Value）的挖掘越來越重視。物聯網產生的資料通常都具備時間序列特徵，時序資料庫是當前針對物聯網 IoT、工業網際網路 IIoT、應用效能監控 APM 場景等垂直領域定製的資料庫解決方案，本文主要分析物聯網場景海量時序資料儲存與處理的關鍵技術挑戰及解決方案。

一 時序資料儲存挑戰

1 典型時序應用場景

隨著 5G/IoT 技術的發展，資料呈爆炸式增長，其中物聯網 (IoT) 與應用效能監控 (APM) 等是時序資料最典型的應用領域，覆蓋物聯網、車聯網、智慧家居、工業網際網路、應用效能監控等常見的應用場景，海量的裝置持續產生執行時指標資料，對資料的讀寫、儲存管理都提出了很大的挑戰。

2 時序資料的特徵

在典型的物聯網、APM 時序資料場景裡，資料的產生、訪問都有比較明顯的規律，有很多共同的特徵，相比當前網際網路典型的應用特徵有比較大的區別。

資料按時間順序產生，一定帶有時間戳，海量的物聯網裝置或者被監控到應用程式，按固定的週期或特定條件觸發，持續不斷的產生新的時序資料。

資料是相對結構化的，一個裝置或應用，產生的指標一般以數值型別（絕大部分）、字元型別為主，並且在執行過程中，指標的數量相對固定，只有模型變更、業務升級時才會新增/減少/變更指標。

寫多讀少，極少有更新操作，無需事務能力支援，在網際網路應用場景裡，資料寫入後，往往會被多次訪問，比如典型的社交、電商場景都是如此；而在物聯網、APM 場景，資料產生儲存後，往往在需要做資料運營分析、監控報表、問題排查時才會去讀取訪問。

按時間段批次訪問資料，使用者主要關注同一個或同一類類裝置在一段時間內的訪問趨勢，比如某個智慧空調在過去1小時的平均溫度，某個叢集所有例項總的訪問 QPS 等，需要支援對連續的時間段資料進行常用的計算，比如求和、計數、最大值、最小值、平均值等其他數學函式計算。

近期資料的訪問遠高於歷史資料，訪問規律明顯，歷史資料的價值隨時間不斷降低，為節省成本，通常只需要儲存最近一段時間如三個月、半年的資料，需要支援高效的資料 TTL 機制，能自動批次刪除歷史資料，最小化對正常寫入的影響。

資料儲存量大，冷熱特徵明顯，因此對儲存成本要求比較高，需要有針對性的儲存解決方案。

結合時序的特徵，要滿足大規模時序資料儲存需求，至少面臨如下的幾個核心挑戰：

高併發的寫入吞吐：在一些大規模的應用效能監控、物聯網場景，海量的裝置持續產生時序資料，例如某省域電網用電測量資料，9000萬的電錶裝置，原來每個月採集一次，後續業務升級後15分鐘採集一次，每秒的時序資料點數達到數百萬甚至千萬時間點，需要數十到上百臺機器的叢集規模來支撐全量的業務寫入；時序資料儲存需要解決大規模叢集的橫向擴充套件，高效能平穩寫入的需求。

高效的時序資料查詢分析：在典型的監控場景，通常需要對長週期的資料進行查詢分析，比如針對某些指標最近1天、3天、7天、1個月的趨勢分析、報表等；而在物聯網場景，有一類比較典型的斷面查詢需求，例如查詢某個省指定時間所有電錶的用電量量明細資料，查詢某個品牌空調的某個時間的平均執行溫度；這些查詢都需要掃描大量的叢集資料才能拿到結果，同時查詢的結果集也可能非常大；時序資料儲存需要支援多維時間線檢索、並具備流式處理、預計算等能力，才能滿足大規模 APM、IoT 業務場景的典型查詢需求，並且針對時序大查詢要最小化對寫入的影響。

低成本的時序資料儲存：某典型的車聯網場景，僅20000輛車每小時就產生近百GB的車輛指標資料，如果要儲存一年的執行資料就需要PB級的資料儲存規模；由於資料規模巨大，對儲存的低成本要求很高，另外時序資料的冷熱特徵明顯。時序資料儲存需要充分利用好時序資料量大、冷熱訪問特徵明顯、做好計算、儲存資源的解耦，透過低成本儲存介質、壓縮編碼、冷熱分離、高效 TTL、Servereless 等技術將資料儲存成本降低到極致。

簡單便捷的生態協同：在物聯網、工業網際網路等場景，時序資料通常有進一步做運營分析處理的需求，在很多情況下時序資料只是業務資料的一部分，需要與其他型別的資料組合來完成查詢分析；時序資料儲存需要能與生態 BI 分析工具、大資料處理、流式分析系統等做好對接，與周邊生態形成協同來創造業務價值。

為了應對海量時序資料的儲存與處理的挑戰，從2014年開始，陸續有針對時序資料儲存設計的資料庫誕生，並且時序資料庫的增長趨勢持續領先，時序資料庫結合時序資料的特徵，嘗試解決時序資料儲存在高寫入吞吐、橫向擴充套件、低成本儲存、資料批次過期、高效檢索、簡單訪問與時序資料計算等方面面臨的挑戰。

3 業界時序資料庫發展

時序資料庫經過近些年的發展，大致經歷了幾個階段：

第一階段，以解決監控類業務需求為主，採用時間順序組織資料，方便對資料按時間週期儲存及檢索，解決關係型資料庫儲存時序資料的部分痛點，典型的代表包括 RDDTool、Wishper（Graphite）等，這類系統處理的資料模型比較單一，單機容量受限，並且通常內嵌於監控告警解決方案。

第二階段，伴隨大資料和Hadoop生態的發展，時序資料量開始迅速增長，業務對於時序資料儲存處理擴充套件性方面提出更高的要求。基於通用可擴充套件的分散式儲存專門構建的時間序列資料庫開始出現，典型的代表包括 OpenTSDB（底層使用 HBase）、KairosDB（底層使用 Cassandra）等，利用底層分散式儲存可擴充套件的優勢，在 KV 模型上構建定製的時序模型，支援海量時序的倒排檢索與儲存能力。這類資料庫的資料儲存本質仍然是通用的 KV 儲存，在時序資料的檢索、儲存壓縮效率上都無法做到極致，在時序資料的處理支援上也相對較弱。

第三階段，隨著 Docker、Kubernetes、微服務、IoT 等技術的發展，時間序列資料成為增長最快的資料型別之一，針對時序資料高效能、低成本的儲存需求日益旺盛，針對時序資料定製儲存的資料庫開始出現，典型的以InfluxDB 為代表，InfluxDB 的 TSM 儲存引擎針對時序資料定製，支援海量時間線的檢索能力，同時針對時序資料進行壓縮降低儲存成本，並支援大量面向時序的視窗計算函式，InfluxDB 目前也是 DB Engine Rank 排名第一的時序資料庫。InfluxDB 僅開源了單機版本，高可用叢集版僅在企業版和雲服務的版本里提供。

第四階段，隨著雲計算的高速發展，雲上時序資料庫服務逐步誕生，阿里雲早在2017年就推出了 TSDB 雲服務，隨後 Amazon、Azure 推出 Amazon TimeStream、Azure Timeseires Insight 服務，InfluxData 也逐步往雲上轉型，推出 InfluxDB 雲服務；時序資料庫雲服務可以與雲上其他的基礎設施形成更好的協同，雲資料庫已是不可逆的發展趨勢。

二 Lindorm TSDB 背後的技術思考

1 Lindorm 雲原生多模資料庫

為了迎接 5g/IoT 時代的資料儲存挑戰，阿里雲推出雲原生多模資料庫 Lindorm ，致力於解決海量多型別低成本儲存與處理問題，讓海量資料存得起、看得見。

Lindorm 支援寬表、時序、搜尋、檔案等多種模型，滿足多型別資料統一儲存需求，廣泛應用於物聯網、車聯網、廣告、社交、應用監控、遊戲、風控等場景。其中 Lindorm TSDB 時序引擎提供高效讀寫效能、低成本資料儲存、時序資料聚合、插值、預測等計算能力，主要應用於物聯網(IoT)、工業網際網路（IIoT）、應用效能監控（APM）等場景。

2 Lindorm TSDB 核心設計理念

Lindorm TSDB 做為下一代時序資料庫，在架構升級過程中，我們認為時序資料庫的發展會有如下趨勢：

多模融合：未來時序資料庫與通用KV資料庫、關係型資料庫等的配合聯絡會越來越緊密，例如在物聯網場景，裝置元資料的儲存、執行時資料的儲存、業務類資料的儲存通常會使用不同的資料模型來儲存。

雲原生：隨著雲計算的發展，未來時序資料庫的儲存要基於雲原生技術，充分利用雲上的基礎設施，形成相互依賴或協同，進一步構建出時序儲存的競爭力。

時序原生：未來時序資料庫的儲存引擎是針對時序資料高度定製化的，保證高效的時序多維檢索能力，高寫入吞吐及高壓縮率，支援冷熱資料自動化管理。

分散式彈性：未來時序資料庫要具備分散式擴充套件的能力，應對大規模的時序資料庫儲存，在時序的典型應用場景，例如物聯網、工業電網、監控、都有海量裝置資料寫入和儲存的需求，必須要做到彈性擴充套件，透過分散式、Serverless 等技術實現規模從小到大的彈性伸縮。

時序 SQL：未來時序資料庫的訪問要支援標準 SQL（or SQL Like 表達方式），一方面使用上更加便捷，降低資料庫的使用門檻，同時也能基於 SQL 提供更加強大並有時序特色的計算能力。

雲邊一體：未來時序資料庫在邊緣裝置端不再是孤立的資料儲存，邊緣側會不斷加深與雲端協同，形成一體化的時序儲存解決方案。

基於以上判斷，我們構建了雲原生多模資料庫 Lindorm，支援寬表、時序、搜尋、檔案等多種常用模型，解決物聯網/網際網路海量資料儲存的常見需求，其中 Lindorm TSDB 採用計算儲存分離的架構，充分利用雲原生儲存基礎設施，定製時序儲存引擎，相比業界的解決方案更具競爭力。

多模融合、統一儲存：Lindorm TSDB 引擎與寬表、搜尋、檔案等形成配合，解決使用者多型別資料的統一儲存處理需求。

雲原生低成本儲存，計算儲存分離：Lindorm TSDB 引擎基於雲原生分散式儲存平 LindormStore，提供高可靠的資料儲存，並支援彈性擴充套件，提供標準型、效能型、容量型等多種儲存形態，滿足不同場景的需求，同時支援冷熱資料一體化管理的能力。

時序定製儲存引擎：Lindorm TSDB 引擎針對時序資料的特徵，定製基於 LSM Tree 結構的時序引擎，在日誌寫入、記憶體組織結構、時序資料儲存結構以及 Compaction 策略上都針對時序特徵最佳化，保證極高的寫入吞吐能力。在引擎內部支援內建的預處理計算引擎，支援對時序資料進行預降取樣、預聚合，來最佳化查詢效率。

多維資料分片、彈性伸縮：Lindorm TSDB 引擎支援橫向擴充套件，透過對時間線進行 Hash 分片，將海量時間線資料分散到多個節點儲存；在節點內部，支援按時間維度進一步切分，支援叢集的無縫擴容，同時也能解決雲原生監控場景時間線膨脹的問題；透過 Serverless 形態實現任意規模的彈性伸縮。

定製時序 SQL 查詢：Lindorm TSDB 引擎提供時序 SQL 訪問能力，針對時序場景定製特色計算運算元，使用者學習、使用成本低。

邊雲同步一體化：Lindorm TSDB 引擎提供輕量級邊緣部署的版本，解決邊緣時序儲存需求，並支援邊緣側資料與雲端無縫同步，以便充分利用雲上基礎設施來進一步挖掘資料價值。

三 Lindorm TSDB 關鍵技術

1 時序定製儲存引擎

Lindorm 基於儲存計算分離架構設計，以適應雲計算時代資源解耦和彈性伸縮的訴求，其中雲原生儲存分散式儲存 Lindorm Store 為統一的儲存底座，向上構建各個垂直專用的多模引擎，包括寬表引擎、時序引擎、搜尋引擎、檔案引擎。LindormStore 是面向公共雲基礎儲存設施(如雲盤、DBFS、OSS) 設計、相容 HDFS 協議的分散式儲存系統，並同時支援執行在本地盤環境，以滿足部分專有云、專屬大客戶的需求，向多模引擎和外部計算系統提供統一的、與環境無關的標準介面。

基於雲原生分散式儲存 LindomStore，Lindorm TSDB 採用針對寫入最佳化的 LSM Tree 結構來儲存時序資料，並結合時序資料的特徵，在日誌寫入、記憶體組織結構、時序資料儲存結構進行時序壓縮，最大化記憶體利用效率、磁碟儲存效率；同時在 Compaction 策略上也針對資料通常有序產生的特徵進行最佳化。透過引擎自帶的 WAL 日誌，Lindorm TSDB 能非常方便的支援實時的資料訂閱，以及在引擎內部對資料進行針對性的降取樣、聚合等預處理操作。

Lindorm TSDB 針對時序資料的查詢，支援豐富的處理運算元，包括降取樣、聚合、插值、過濾等。使用者的查詢請求經過 Parser 解析後，通常分為多個主要的處理階段，以 Pipeline 的形式高效處理。

Index Scan：根據使用者指定的查詢條件，基於正排索引 + 倒排索引找出所有滿足條件的時間線 ID 集合。

Data Scan：基於第1階段找出的時間線 ID，從 TSFile 讀取對應時間範圍的資料。

Aggregation/Filter: 針對第2階段的掃描結果，對時間線資料進一步的處理，包括在一條時間線上對資料按一定週期進行降取樣，或對多條時間線相同時間點上的資料進行聚合（sum、count、avg、min、max等）操作等。

2 分散式彈性

Lindorm TSDB 具備橫向擴充套件的能力，海量的時間線資料會被分散儲存到多個 Shard 中，Shard 是叢集中獨立的資料管理單元，Shard 內部是一個自治管理的 LSM Tree 儲存引擎（參考2.2），包含單獨的 WAL、TPI、TSFile 等檔案。

在水平方向，時間序列資料會根據 metric + tags 組成的時間線標識，採用 Hash 分片的策略，將資料分到多個節點；在垂直方向（時間軸維度），分到同一個節點的資料，可按照時間維度進行切分，這樣每個 Shard 就負責一部分時間線在一定時間範圍內的資料管理。

水平方向的分片能保證叢集的負載均分到各個節點，後續還會結合業務特徵，支援業務自定義的分片策略，最佳化讀寫效率；垂直方向（按時間範圍）的分片，對於膨脹型時間線場景（比如雲原生監控的場景，容器頻繁上下線導致大量老時間線的消亡，新時間線的建立）非常有幫助，同時在叢集擴容時，也可以藉助時間分片策略來儘可能的減小對寫入的影響。

3 TSQL 時序查詢

Lindorm TSDB 提供 SQL 訪問能力，Lindorm TSDB 的資料模型針對物聯網場景高度最佳化定製，概念上儘量保留開發者對資料庫的普遍理解，一個例項包含多個數據庫，一個數據庫包含多張表，表裡儲存多個裝置的時序資料，每個裝置包含一組用於描述裝置的 Tag、裝置包含多個 Field 指標，新的指標資料隨時間持續不斷的產生。除了支援常規的 SQL 基礎能力，Lindorm TSDB 還定製了 sample by、latest 等運算元，用於方便的表達時序降取樣、時序聚合、最新點查詢等常見的時序操作，簡化使用的同時，增強了時序 SQL 的表達能力，讓使用者使用時序資料庫更加簡單、高效。

基於 TSQL 查詢介面，Lindorm TSDB 還能針對時序資料進行一系列的拓展分析，包括時序資料預測、異常檢測等，讓應用能更好的發揮時序資料價值。

4 Serverless

Lindorm TSDB 透過時序定製的儲存引擎、結合分散式擴充套件的能力，能很好的滿足大規模時序場景的業務需求。但對於一些業務訪問較小的應用場景起步成本相對較高，例如在平臺級的應用監控、IoT 場景，平臺需要管理大量使用者的時序資料，而大部分使用者的資料規模初期都相對較小，為了進一步降低使用者的使用成本，適應從小到大任意規模的時序儲存需求，更好的賦能上層的應用監控、物聯網類 SaaS 平臺服務，未來 Lindorm 將會沿著多租戶 Serverless 服務模式持續演進，提升彈效能力。

5 邊雲同步

隨著 IoT 技術的發展，邊緣計算需求日益明顯，在智慧家居、工業工控、智慧園區、交通大腦等場景，考慮到網路頻寬成本等原因，資料通常需要先就近本地儲存，並週期性的同步到雲端進行進一步分析處理。為了方便邊緣側的部署，Lindorm TSDB 支援邊緣輕量級部署的版本，並支援資料全量、增量同步到雲端，形成邊雲一體化的解決方案。

四 時序儲存解決方案

1 物聯網裝置資料儲存

Lindorm TSDB 是物聯網裝置執行資料儲存的最佳選擇，無縫與阿里雲 IoT 平臺、DataHub、Flink 等進行連線，極大的簡化物聯網應用開發流程。例如透過 Lindorm TSDB，你可以收集並存儲智慧裝置的執行指標，透過自帶的聚合計算引擎或BI類工具進行智慧分析，深入瞭解裝置執行狀態。

2 工業邊緣時序儲存

Lindorm TSDB 邊緣版非常適合工業網際網路場景，在邊緣側輕量化輸出，與工業裝置就近部署，同時支援將資料同步到 Lindorm 雲端。例如透過 Lindorm TSDB，你可以實時採集工業生產線裝置的執行指標，對產線的執行狀況進行分析及視覺化，從而最佳化產線執行效能。

3 應用監控資料儲存

Lindorm TSDB 非常適合應用監控資料儲存，無縫對接 Prometheus、Telegraf、ARMS 等監控生態，提供針對監控指標的高效讀寫與儲存，同時提供聚合分析、插值計算等能力。例如透過 Lindorm TSDB，你可以收集應用程式的 CPU、記憶體、磁碟等指標的使用情況，並進行分析及視覺化，實時監測應用執行情況。

五 總結

從網際網路&大資料時代的分散式，到雲計算、5G/IoT時代的雲原生多模，業務驅動是Lindorm不變的演進原則。面對資源按需彈性和資料多樣化處理的新時代需求，Lindorm以統一儲存、統一查詢、多模引擎的架構進行全新升級，並藉助雲基礎設施紅利，重點發揮雲原生彈性、多模融合處理、極致價效比、企業級穩定性的優勢能力，全力承載好經濟體內部和企業客戶的海量資料儲存處理需求。

Lindorm TSDB 時序引擎面向物聯網、工業網際網路、應用效能監控等領域的時序資料儲存需求，全面擁抱雲原生，並充分利用雲原生基礎設施，定製時序儲存引擎，構建海量低成本的時序資料儲存與處理能力，提供邊雲一體化的時序儲存解決方案。未來 Lindorm 引擎將繼續在彈性伸縮、低成本海量儲存、多模融合、時序流計算等方向持續突破，構建萬物互聯的資料底座。