摘要：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強大的日誌管理、運維監控、滾動升級、安全加固、高可用保障、災備恢復、細粒度許可權管控、大資料生態整合、資源池最佳化排程等企業級核心能力，針對工業級時間序列資料實時性高，採集頻率高，儲存週期長，演算法專業強等特點，提供海量時序資料高併發實時寫入和查詢的能力，有力支撐新一代資訊科技與工業深度融合發展，將進一步加速工業乃至產業數字化。