作者 | 林青
來源 | 阿裡技術公衆号
随着 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)