摘要：MRS IoTDB，它是華為FusionInsight MRS大數據套件中的時序資料庫產品，在深度參與Apache IoTDB社區開源版的基礎上推出的高性能企業級時序資料庫產品。 本文分享自華為雲社區《工業數據分析為什麼要用FusionInsight MRS IoTDB？》，作者：高深廣 。 ...
摘要：MRS IoTDB，它是華為FusionInsight MRS大數據套件中的時序資料庫產品，在深度參與Apache IoTDB社區開源版的基礎上推出的高性能企業級時序資料庫產品。
本文分享自華為雲社區《工業數據分析為什麼要用FusionInsight MRS IoTDB？》，作者：高深廣 。
隨著工業互聯網逐步興起，在加速工業自動化、智能化的同時，也進一步加速工業生產時間序列數據的產生速度。但對於工業生產中的數據分析，仍然存在重覆樣本多，數據膨脹率大，缺乏專業易用的平臺，這些問題成為阻礙工業數據分析的最大障礙。
工業是現代文明的基礎，提起工業，我們就能想到滾動向前的火車，轟鳴的飛機，為現代工業生產、出行提供便利。同時，衡量一個國家的綜合實力時，也離不開工業。工業數字化浪潮隨著信息基礎設施的建設，通過人工智慧、大數據技術與行業的不斷深入行業場景，使得數據在企業單位內得以正確使用，享受數據價值紅利。
近年來，全球多個國家將數據列為戰略資源，並頒佈數項數據政策，旨在進一步通過數據提升經濟實力，讓人能享受數據帶來的巨大進化紅利。而在工業生產過程中，早期以流水線、自動化為主，對比其他產業，中國各行業的數字化整體規模仍存在差距第二產業數字化發展之後，但近年來增速較快，以能源業為代表的陝煤、山能、三峽集團等大中型企業，以“上雲用數賦智”為牽引，不斷提升生產效率，實現精細化運營。當前，中國是當前世界上最大的製造業國家，規模等於美日德綜合，在數字化轉型道路上道艱且長。
隨著雲計算、大數據、物聯網、5G等場景對於時序數據需求的持續增長，專門用於存儲和處理時間序列數據的時序資料庫應運而生。時序資料庫面臨著採集頻率密、採集精度高、採集跨度大、存儲周期長、實時要求高等有別於傳統資料庫的挑戰。
1 什麼是時序數據及工業時序數據的特點
工業數字化滾滾而來，在信息基礎設施之上，工業生產環境產出了大量的以物聯網IoT(Internet Of Things)數據，並隨著時間的演進連續不斷地產生大量感測器數值或事件數據。時間序列數據(time series data)就是以數據(事件)發生的時刻（時間戳）為時間軸形成的連續不斷的數值序列。
例如，下表為某物聯網設備不同時刻的的溫度數據構成的一個時間序列數據樣本：
無論是機器產生的感測器數據，還是工業生產活動的數據，都有一些共同的特征：
（1）實時性要求高：處理上無論是感測器數據還是事件數據，都需要毫秒級、秒級的實時處理能力，以確保對實時響應和處理能力；採集最少支持毫秒級採集，有些需要支持微秒級、納秒級採集；
（2）採集頻率高：每秒採集幾十次、上百次、十萬次乃至百萬次；
（3）存儲分析周期長：需要支持時序數據的持久存儲，甚至對有些數據需要進行長達上百年的永久存儲（例如地震數據）；分析需7*24小時持續不斷地連續採集幾年、乃至數十年數據；查詢視窗長：需要支持從毫秒、秒、分鐘、小時到日、月、年等不同粒度的時間視窗查詢；也需要支持萬、十萬、百萬、千萬等不同粒度的數量視窗查詢；
（4）數據清洗難：時間序列數據存在亂序、缺失、異常等複雜情況，需要專用演算法進行高效實時處理；
（5）演算法專業強：時間序列數據在工業、金融、電力、交通等不同領域，都有很多垂直領域的專業時序分析需求，需要利用時序趨勢預測、相似子序列分析、周期性預測、時間移動平均、指數平滑、時間自回歸分析以及基於LSTM的時序神經網路等演算法進行專業分析。
從時序數據的共同特征可以看出，時間序列特殊的場景需求給傳統的關係資料庫存儲和大數據存儲都帶來了挑戰，無論是採用關係資料庫進行結構化存儲，還是採用NoSQL資料庫進行存儲，都無法滿足海量時序數據高併發實時寫入和查詢的需求。因此，迫切需要一種專門用於存儲時間序列數據的專用資料庫，時序資料庫的概念和產品就這樣誕生了。
2 時序資料庫和其他資料庫的區別
需要註意的是，時序資料庫不同於時態資料庫和實時資料庫。時態資料庫(Temporal Database)是一種能夠記錄對象變化歷史，即能夠維護數據的變化經歷的資料庫，比如TimeDB。時態資料庫是對傳統關係資料庫中時間記錄的時間狀態進行細粒度維護的系統，而時序資料庫完全不同於關係資料庫，只存儲不同時間戳對應的測點值。
時序資料庫也不同於實時資料庫。實時資料庫誕生於傳統工業，主要是因為現代工業製造流程及大規模工業自動化的發展，傳統關係資料庫難以滿足工業數據的存儲和查詢需求。因此，在80年代中期，誕生了適用於工業監控領域的實時資料庫。由於實時資料庫誕生早，在擴展性、大數據生態對接、分散式架構、數據類型等方面存在局限，但是也有產品配套齊全、工業協議對接完整的優勢。時序資料庫誕生於物聯網時代，在大數據生態對接、雲原生支持等方面更有優勢。
時序資料庫與時態資料庫、實時資料庫的基本對比信息如下：
2.1 當前主流時序資料庫的基本情況
為了高效存儲、處理、查詢和分析海量時序數據，市面上先後出現了幾十種時序資料庫。
時序資料庫是時間序列資料庫的簡稱，指的是專門對帶時間標簽（按照時間的順序變化，即時間序列化）的數據進行存儲、查詢、分析等處理操作的專用資料庫系統。通俗來說，時序資料庫就是專門用來記錄例如物聯網設備的溫度、濕度、速度、壓力、電壓、電流以及證券買入賣出價等隨著時間演進不斷變化的各類數值（測點、事件）的資料庫。
這些時序資料庫架構形態和性能特性各異，但是基本上可以概括為以下幾種：
2.1.1 基於傳統關係庫擴展的時序資料庫
在傳統關係資料庫的基礎上，利用關係資料庫的內核引擎，把時間序列作為一個插件擴展實現。例如，TimescaleDB是基於PostgreSQL資料庫打造的一款時序資料庫。PostgreSQL是一個功能非常強大的、源代碼開放的客戶/伺服器關係型資料庫管理系統。PostgreSQL擁有強勁的功能集，其中包括多版本併發控制(MVCC)、時點恢復、細粒度訪問控制、表空間、非同步複製、嵌套事務、聯機/熱備份、完善的查詢規劃器/優化器以及預寫式日誌。
由於TimescaleDB基於PostgreSQL，因此同時具備了傳統關係資料庫的優點和缺點，優點在於PostgreSQL完備地實現了關係資料庫標準，因此具有強大的生態相容能力和強一致性的保障。Timescale作為PostgreSQL的一個插件，為快速獲取和複雜查詢進行了優化。它執行的是完整的SQL，相應地很容易像傳統的關係資料庫那樣使用。然而，TimescaleDB也繼承了傳統關係資料庫的不足：單邊列數有上限、單表行數不宜過多（少於一千萬行）、需要手動進行分庫分表，缺乏自動伸縮能力，時間序列數據隨著導入時間的增加，導入速度不斷下降，海量（GB或千萬條以上）時序數據遍歷速度緩慢等。
2.1.2 基於KV資料庫的時序資料庫
隨著大數據技術的興起，以KV資料庫為代表的NoSQL資料庫大量涌現，打破了關係資料庫ACID的嚴格限制，以CAP作為約束，底層以大數據分散式文件系統為存儲引擎，突破了傳統關係資料庫面對海量數據存儲的局限。其中，HBase是NoSQL資料庫的典型代表，具備海量數量的靈活擴展存儲能力。時序資料庫OpenTSDB基於HBase的這種能力，專門針對時序數據的海量存儲和查詢做了擴展。OpenTSDB的整體架構如下所示，由運行在HBase之上的一個或者多個時間序列守護程式TSD (Time Series Daemon) 組成，每個TSDB都是無狀態的獨立節點，因此可以根據系統負載情況進行任意節點的橫向擴展：
OpenTSDB的數據模型是基於tag的單值模型，即寫入的每行記錄（數據點）中只有一個指標值，如下所示：
由於基於HBase，OpenTSDB具備了HBase的優勢：可以輕鬆管理海量時間序列數據，支持時序分區和並行查詢，具備分散式集群部署和擴展能力。但是，同樣也具備基於HBase帶來的不足：由於HBase是弱類型列式資料庫，使用Java語言操作，使得OpenTSDB也存在查詢受限問題，對於多序列時間對齊查詢等複雜查詢支持能力受限，但客戶和技術人員通常僅具備標準SQL語言技術知識儲備，使用門檻高。同時由於採用的是HBase通用存儲格式，沒有針對時間序列數據的特性進行針對性壓縮，因此導致壓縮比低，讀寫速度較慢，通常1份數據要膨脹3倍，使用和運維成本居高不下。OpenTSDB的存儲模型，其主要設計特點是採用了UID編碼，大大節省了存儲空間，並且利用UID編碼的固定位元組數的特性，利用HBase的Filter做了很多查詢的優化。但是採用UID編碼後也帶來了很多的缺陷，一是需要維護metric/tagKey/tagValue到UID的映射表，所有data point的寫入和讀取都需要經過映射表的轉換，映射表通常會緩存在TSD或者client，增加了額外的記憶體消耗；二是由於採用了UID編碼，導致metric/tagKey/tagValue的基數是有上限的，取決於UID使用的位元組數，並且在UID的分配上會有衝突，會影響寫入。
另外一款基於Cassandra的時序資料庫KairosDB也是類似OpenTSDB。Cassandra是一個高度可擴展的高性能分散式NoSQL資料庫，用於處理大量商用伺服器上的大量數據，提供高可用性，無單點故障。它是一個通用NoSQL，面向列的資料庫, 分佈設計基於Amazon的Dynamo及其在Google的Bigtable上的數據模型，並不依賴於Hadoop生態體系，對於現網存在大數據平臺的客戶，將會造成進一步的數據孤島、數據冗餘和更多的數據搬遷工作。Cassandra實現了一個沒有單點故障的Dynamo風格的複製模型，但增加了一個更強大的“列族”數據模型。Cassandra適應所有可能的數據格式，包括：結構化，半結構化和非結構化，可以根據需要動態地適應變化的數據結構。KairosDB採取的存儲模型，是利用了Cassandra寬表的特性。Cassandra的底層文件存儲格式與HBase不同，它一行數據不會為每一列都重覆的存儲Rowkey，所以它不需要使用UID編碼。雖然Cassandra針對OpenTSDB的不足做了改進，本質都是依靠大數據領域已有的通用NoSQL分散式資料庫引擎作為底層存儲，因此從根本上受制於底層存儲的限制，無法針對時間序列數據的特點進行針對性優化。
2.1.3 基於專有時序數據引擎的時序資料庫
吸收了基於關係資料庫和KV資料庫在時序數據存儲方面的經驗教訓，逐步出現了基於專有時序數據引擎的專業時序資料庫，其中最有代表性的就是InfluxDB。InfluxDB是由InfluxData公司開發的時間序列資料庫（TSDB）。InfluxDB使用Go語言編寫，適用於各類時間序列數據的高效存儲與檢索。InfluxDB專為時間序列數據編寫的定製高性能數據存儲，TSM引擎可實現高提取速度和數據壓縮。InfluxDB採用了專屬文件結構和專屬優化，具有高壓縮比、高併發、海量存儲等顯著優勢。但是其在易用性和生態對接方面仍需提供更多支持投入。
2.1.4 華為雲MRS IoTDB “專快易穩省”的專業時序資料庫
專業時序資料庫的另一個代表就是MRS IoTDB，它是華為FusionInsight MRS大數據套件中的時序資料庫產品，在深度參與Apache IoTDB社區開源版的基礎上推出的高性能企業級時序資料庫產品。IoTDB顧名思義，是針對IoT物聯網領域推出的專用時序資料庫軟體，是由清華大學發起的國產Apache開源軟體。自IoTDB誕生之初，華為就深度參與IoTDB的架構設計和核心代碼貢獻，對IoTDB集群版的穩定性、高可用和性能優化投入了大量人力並提出了大量的改進建議和貢獻了大量的代碼。
IoTDB在設計之初，全面分析了市面上的時序資料庫相關產品，包括基於傳統關係資料庫的Timescale、基於HBase的OpenTSDB、基於Cassandra的KariosDB、基於時序專屬結構的InfluxDB等主流時序資料庫，借鑒了不同時序數據在實現機制方面的優勢，形成了自己獨特的技術優勢：
（1）支持高速數據寫入
獨有的基於兩階段LSM合併的tLSM演算法有效保障了IoTDB即使在亂序數據存在的情況下也能輕鬆實現單機每秒千萬測點數據的併發寫入能力。
（2）支持高速查詢
支持TB級數據毫秒級查詢
（3）功能完備
支持CRUD等完整的數據操作（更新通過對同一設備同一時間戳的測點數據覆蓋寫入來實現，刪除通過設置TTL過期時間來實現），支持頻域查詢，具備豐富的聚合函數，支持相似性匹配、頻域分析等專業時序處理。
（4）介面豐富，簡單易用
支持JDBC介面、Thrift API介面和SDK等多種介面。採用類SQL語句，在標準SQL的語句上增加了對於時間滑動視窗的統計等時序處理常用的功能，提供了系統使用效率。Thrift API介面支持Java、C\C++、Python、C#等多語言介面調用。
（5）低存儲成本
IoTDB獨立研發的TsFile時序文件存儲格式，專門針對時序處理處理做了優化，基於列式存儲，支持顯式的數據類型聲明，不同數據類型自動匹配SNAPPY、LZ4、GZIP、SDT等不同的壓縮演算法，可實現1:150甚至更高的壓縮比（數據精度進一步降低的情況下），極大地降低了用戶的存儲成本。例如某用戶原來用9台KariosDB伺服器存儲的時序數據，IoTDB用1台同等配置的伺服器即可輕鬆實現。
（6）雲邊端多形態部署
IoTDB獨有的輕量級架構設計保障了IoTDB可以輕鬆實現“一套引擎打通雲邊端，一份數據相容全場景”。在雲服務中心，IoTDB可以採用集群部署，充分發揮雲的集群處理優勢；在邊緣計算位置，IoTDB可以在邊緣伺服器上部署單機IoTDB，也可以部署少量節點的集群版，具體視邊緣伺服器配置而定；在設備終端，IoTDB可以TsFile文件的形態直接嵌入到終端設備的本地存儲中，並直接被設備終端的直接讀寫TsFile文件，不需要IoTDB資料庫伺服器的啟動運行，極大地減少了對終端設備處理能力的要求。由於TsFile文件格式開放，終端任意語言和開發平臺可以直接讀寫TsFile的二進位位元組流，也可以利用TsFile自帶的SDK進行讀寫，對外甚至可以通過FTP將TsFile文件發送到邊緣或雲服務中心。
（7）查詢分析一體化
IoTDB一份數據同時支持實時讀寫與分散式計算引擎分析，TsFile與IoTDB引擎的松耦合設計保障了一方面IoTDB可以利用專有的時序數據處理引擎對時序數據進行高效寫入和查詢，同時TsFile也可以被Flink、Kafka、Hive、Pulsar、RabbitMQ、RocketMQ、Hadoop、Matlab、Grafana、Zeepelin等大數據相關組件進行讀寫分析，極大地提升了IoTDB的查詢分析一體化能力和生態擴展能力。
MRS IoTDB對Apache IoTDB內核架構尤其是分散式集群架構做了大量的重構優化，在穩定性、可靠性、可用性和性能方面做了大量的系統級增強。
（1）介面相容性：
進一步完善北向介面和南向介面，支持JDBC、Cli、API、SDK、MQTT、CoAP、Https等多種訪問介面，進一步完善類SQL語句，相容大部分Influx SQL，支持批量導入導出。
（2）分散式對等架構：
MRS IoTDB在基於Raft協議的基礎上，採用了改進的Multi-Raft協議，並對Muti-Raft協議的底層實現進行了優化，採用了Cache Leader等優化策略在保障無單節故障的基礎上，進一步提升MRS IoTDB數據查詢路由的性能；同時，對強一致性、中等一致性和弱一致性策略進行了細粒度優化；對一致性哈希演算法加入虛擬節點策略避免數據傾斜，同時融合了查表與哈希分區的演算法策略，在提升集群高可用的基礎上進一步保障集群調度的性能。
（3）雙層粒度元數據管理：
由於採用了對等架構，元數據信息自然分佈在集群所有節點上進行存儲，但是由於元數據的存儲量較大會帶來記憶體的較大消耗。為了平衡記憶體消耗與性能，MRS IoTDB採用了雙層粒度元數據管理架構，首先在所有節點間進行時間序列組元數據的同步，其次在分區節點間進行時間序列元數據的同步。這樣在查詢元數據的時候，首先會基於時間序列組進行過濾樹剪枝，大大減少搜尋空間，然後在進一步在過濾後的分區節點進行時間序列元數據的查詢。
（4）本地磁碟高性能訪問：
MRS IoTDB採用專用的TsFile文件格式進行時間序列優化存儲，採用列存格式進行自適應編碼與壓縮，支持流水線優化訪問和亂序數據高速插入
（5）HDFS生態集成：
MRS IoTDB支持HDFS文件讀寫，並對HDFS進行了本地緩存、短路讀、HDFS I/O線程池等多種優化手段，全面提升MRS IoTDB對HDFS的讀寫性能，同時，MRS IoTDB支持華為OBS對象存儲併進行了更加高性能的深度優化。在HDFS集成的基礎上，MRS IoTDB支持Spark、Flink、Hive等MRS組件對TsFile的高效讀寫。
（6）多級許可權管控：
- 支持存儲組、設備、感測器等多級許可權管控
- 支持創建、刪除、查詢等多級操作
- 支持Kerberos認證
- 支持Ranger許可權架構
（7）雲邊端部署：
支持雲邊端靈活部署，邊緣部分可以基於華為的IEF產品進行對接，也可以直接部署在華為的IES中。
MRS IoTDB集群版支持動態擴縮容，可以為雲邊端提供更加靈活的部署支持。
總之，MRS IoTDB在Apache IoTDB已有架構的基礎上，融合FusionInsight MRS Manager強大的日誌管理、運維監控、滾動升級、安全加固、高可用保障、災備恢復、細粒度許可權管控、大數據生態集成、資源池優化調度等企業級核心能力，針對工業級時間序列數據實時性高，採集頻率高，存儲周期長，演算法專業強等特點，提供海量時序數據高併發實時寫入和查詢的能力，有力支撐新一代信息技術與工業深度融合發展，將進一步加速工業乃至產業數字化。
