作者 | 林青
來源 | 阿里技術公眾號
隨著 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 引擎將繼續在彈性伸縮、低成本海量存儲、多模融合、時序流計算等方向持續突破，構建萬物互聯的數據底座。
免費領取電子書
《雲原生大規模應用落地指南》
企業上雲已經成為一種必然趨勢，作為誕生於雲計算時代的新技術理念，雲原生讓企業用雲的方式發生著從“上雲”到“雲上”的轉化。本書從技術體系升級到技術能力突破，再到雙11雲原生實踐，全面分享阿里巴巴雙11雲原生技術實踐經驗。
掃碼加阿里妹好友，回覆“雲指南”獲取吧~(若掃碼無效，可直接添加alimei4、alimei5、alimei6、alimei7)
