深度解讀MRS IoTDB時序資料庫的整體架構設計與實現

z_paul發表於2021-09-11

摘要：本文將會系統地為大家介紹MRS IoTDB的來龍去脈和功能特性，重點為大家介紹MRS IoTDB時序資料庫的整體架構設計與實現。

本文分享自華為雲社群《MRS IoTDB時序資料庫的總體架構設計與實現》，原文作者：cloudsong。

MRS IoTDB是華為FusionInsight MRS大資料套件最新推出的時序資料庫產品，其領先的設計理念在時序資料庫領域展現出越來越強大的競爭力，得到了越來越多的使用者認可。為了大家更好地瞭解MRS IoTDB，本文將會系統地為大家介紹MRS IoTDB的來龍去脈和功能特性，重點為大家介紹MRS IoTDB時序資料庫的整體架構設計與實現。

什麼是時序資料庫

時序資料庫是時間序列資料庫的簡稱，指的是專門對帶時間標籤（按照時間的順序變化，即時間序列化）的資料進行儲存、查詢、分析等處理操作的專用資料庫系統。通俗來說，時序資料庫就是專門用來記錄例如物聯網裝置的溫度、溼度、速度、壓力、電壓、電流以及證券買入賣出價等隨著時間演進不斷變化的各類數值（測點、事件）的資料庫。

當前，隨著大資料技術發展和應用的不斷深入，以物聯網IoT(Internet Of Things)、金融分析為代表的兩類資料，表現出隨著時間的演進連續不斷地產生大量感測器數值或事件資料。時間序列資料(time series data)就是以資料(事件)發生的時刻（時間戳）為時間軸形成的連續不斷的數值序列。例如某物聯網裝置不同時刻的的溫度資料構成一個時間序列資料：

無論是機器產生的感測器資料，還是人類活動產生的社會事件資料，都有一些共同的特徵：

（1）採集頻率高：每秒採集幾十次、上百次、十萬次乃至百萬次；

（2）採集精度高：最少支援毫秒級採集，有些需要支援微秒級和納秒級採集；

（3）採集跨度大：7*24小時持續不斷地連續採集幾年、乃至數十年資料；

（4）儲存週期長：需要支援時序資料的持久儲存，甚至對有些資料需要進行長達上百年的永久儲存（例如地震資料）；

（5）查詢視窗長：需要支援從毫秒、秒、分鐘、小時到日、月、年等不同粒度的時間視窗查詢；也需要支援萬、十萬、百萬、千萬等不同粒度的數量視窗查詢；

（6）資料清洗難：時間序列資料存在亂序、缺失、異常等複雜情況，需要專用演算法進行高效實時處理；

（7）實時要求高：無論是感測器資料還是事件資料，都需要毫秒級、秒級的實時處理能力，以確保對實時響應和處理能力；

（8）演算法專業強：時間序列資料在地震、金融、電力、交通等不同領域，都有很多垂直領域的專業時序分析需求，需要利用時序趨勢預測、相似子序列

分析、週期性預測、時間移動平均、指數平滑、時間自迴歸分析以及基於LSTM的時序神經網路等演算法進行專業分析。

從時序資料的共同特徵可以看出，時間序列特殊的場景需求給傳統的關聯式資料庫儲存和大資料儲存都帶來了挑戰，無法是採用關聯式資料庫進行結構化儲存，還是採用NoSQL資料庫進行儲存，都無法滿足海量時序資料高併發實時寫入和查詢的需求。因此，迫切需要一種專門用於儲存時間序列資料的專用資料庫，時序資料庫的概念和產品就這樣誕生了。

需要注意的是：時序資料庫不同於時態資料庫和實時資料庫。時態資料庫(Temporal Database)是一種能夠記錄物件變化歷史，即能夠維護資料的變化經歷的資料庫，比如TimeDB。時態資料庫是對傳統關聯式資料庫中時間記錄的時間狀態進行細粒度維護的系統，而時序資料庫完全不同於關聯式資料庫，只儲存不同時間戳對應的測點值。有關時序資料庫與時態資料庫的更詳細對比，後續將會發文專門介紹，在此不再詳述。

時序資料庫也不同於實時資料庫。實時資料庫誕生於傳統工業，主要是因為現代工業製造流程及大規模工業自動化的發展，傳統關聯式資料庫難以滿足工業資料的儲存和查詢需求。因此，在80年代中期，誕生了適用於工業監控領域的實時資料庫。由於實時資料庫誕生早，在擴充套件性、大資料生態對接、分散式架構、資料型別等方面存在侷限，但是也有產品配套齊全、工業協議對接完整的優勢。時序資料庫誕生於物聯網時代，在大資料生態對接、雲原生支援等方面更有優勢。

時序資料庫與時態資料庫、實時資料庫的基本對比資訊如下：

2．什麼是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的查詢分析一體化能力和生態擴充套件能力。

3. MRS IoTDB的整體架構

MRS IoTDB在Apache IoTDB已有架構的基礎上，融合MRS Manager強大的日誌管理、運維監控、滾動升級、安全加固、高可用保障、災備恢復、細粒度許可權管控、大資料生態整合、資源池優化排程等企業級核心能力，對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叢集版支援動態擴縮容，可以為雲邊端提供更加靈活的部署支援。

4. MRS IoTDB的單機架構

4.1 MRS IoTDB的基礎概念

MRS IoTDB主要聚焦在IoT物聯網領域的裝置感測器測點值的實時處理，因此，MRS IoTDB的基礎架構設計以裝置、感測器為核心概念，同時為了便於使用者使用和IoTDB管理時間序列資料，增加了儲存組的概念，下面為大家分別解釋一下：

儲存組(Storage Group): IoTDB為了管理時序資料提出的一個概念，類似於關聯式資料庫中的資料庫的概念。從使用者角度，主要用於對裝置資料進行分組管理；從IoTDB資料庫角度，儲存組又是一個併發控制和磁碟隔離的單位，不同儲存組之間可以並行讀寫。

裝置 (Device)：對應現實世界中的具體物理裝置，例如：電廠某製造單元、風力發電機、汽車、飛機發動機、地震波採集儀器等。在IoTDB中, device是時序資料一次寫入的單位，一次寫入請求侷限在一個裝置中。

感測器(Sensor): 對應現實世界中的具體物理裝置自身攜帶的感測器，例如：風力發電機裝置上的風速、轉向角、發電量等資訊採集的感測器。在IoTDB中，Sensor也稱為測點（Measurement），具體指感測器採集的某時刻的感測器值，在IoTDB內部採用<time, value>的形式進行列式儲存。

儲存組、裝置、感測器的關係如下面的例子：

時間序列(Time Series): 類似於關聯式資料庫中的一張表，不過這張表主要有時間戳(Timestamp)、裝置ID(Device ID)、測點值(Measurement)三個主要欄位。為了便於對時間序列的裝置資訊進行更多描述，IoTDB還增加了Tag和Field等擴充套件欄位，其中Tag支援索引，Field不支援索引。在有的時序資料庫中，又稱為時間線，表示記錄某裝置某感測器值隨著時間不斷變化的值，形成一條沿著時間軸不斷追加測點值的時間線。

路徑(Path)：IoTDB構造了一個以root為根節點、把儲存組、裝置、感測器串聯在一起的樹形結構，從root根節點經過儲存組、裝置到感測器葉子節點，構成了一條路徑。如下圖所示：

虛擬儲存組：由於儲存組的概念具有使用者對裝置分組和系統進行併發控制的雙重作用，二者的過度耦合會造成使用者的不同使用方式對系統併發控制的影響。例如：使用者把不相關的所有裝置資料都放到一個儲存組中，IoTDB對這個儲存組加鎖進行併發控制，限制了資料的併發讀寫能力。為了是實現儲存組與併發控制的相對鬆耦合，IoTDB設計了虛擬儲存組這個概念，把對儲存組的併發控制細粒度拆分到虛擬儲存組這個粒度，從而減少了併發控制的粒度。

4.2 MRS IoTDB的基本架構

單機MRS IoTDB主要不同的儲存組構成，每個儲存組是一個併發控制和資源隔離單位，每個儲存組裡麵包括了多個Time Partition。其中，每個儲存組對應一個WAL預寫日誌檔案和TsFile時序資料儲存檔案。每個Time Partition中的時序資料先寫入Memtable，同時記入WAL，定時非同步刷盤到TsFile，具體實現機制後續會給大家詳細介紹。MRS IoTDB單機的基本架構如下：

5. MRS IoTDB的叢集架構

5.1 基於Multi-Raft的分散式對等架構

MRS IoTDB叢集是完全對等的分散式架構，既基於Raft協議避免了單點故障問題，又通過Multi-Raft協議避免了單一Raft共識組帶來的單點效能問題，同時對分散式協議的底層通訊、併發控制和高可用機制做了進一步優化。

首先，整個叢集的所有節點構成一個後設資料組(MetaGroup)，只用於維護儲存組的後設資料資訊。例如下圖藍灰色框所示的一個4節點的IoTDB叢集，全部4個節點構成一個後設資料組(MetaGroup)；

其次，根據資料副本數構造資料組。例如副本數為3，則構造一個包括3個節點的資料組(DataGroup)。儲存組用於儲存時間序列資料及對應的後設資料。

分散式系統中通常以多副本的方式實現資料的可靠儲存。同一份資料的多個副本儲存在不同的節點中且必須保證一致，因此需要使用Raft共識協議來保證資料的一致性，它將一致性的問題拆分成了幾個相對獨立的子問題，即領導者選舉、日誌複製、一致性保證等。Raft協議中有以下重要的概念:

(1)Raft組。Raft組中有一個通過選舉產生的leader節點，其他節點是follower。當一個寫入請求到來時，首先要提交給leader節點處理，leader節點先在自己的日誌裡面記錄下這個寫入請求，然後將這條日誌分發到follower節點。

(2)Raft日誌。Raft通過日誌的方式保證操作不會丟失，日誌中維護了一個 Commit編號和Apply編號。如果一條日誌被Commit，就代表目前叢集中超過半數的節點都收到並持久化了這條日誌。如果一條日誌被Apply，就表示當前節點執行了這條日誌。當某些節點出現故障並重新恢復時，該節點的日誌就會落後於leader的日誌。則在這個節點追上leader的日誌之前，它不能向外界正常提供服務。

5.2 後設資料分層管理

後設資料管理策略是MRS IoTDB分散式設計中的要點。在進行後設資料管理策略設計時首先要考慮後設資料在讀寫流程中的用途:

寫入資料時需要後設資料進行資料型別、許可權等合法性檢查
查詢資料時需要後設資料進行查詢路由。同時，由於時序資料場景中元數

據龐大，還需要考慮後設資料對記憶體資源的消耗。

現有的後設資料管理策略要麼採用將後設資料交由後設資料節點專門管理的方式，這種方法會降低讀寫效能; 要麼採用在叢集所有節點全量儲存後設資料的方式，這種方式會消耗大量的記憶體資源。

為了解決上述問題，MRS IoTDB設計了雙層粒度後設資料管理策略，其核心思想是通過將後設資料拆分為儲存組和時間序列兩層分別管理：

(1)儲存組元資料：後設資料組(MetaGroup)包含了查詢資料時的路由資訊，存

儲組（Storage Group）的後設資料資訊在叢集所有節點上全量儲存。儲存組的粒度較大，一個叢集內部的儲存組數量級遠遠小於時間序列的數量級。因此在叢集所有節點上對這些儲存組後設資料的儲存，大大減少了記憶體的佔用。

後設資料組中的每個節點稱為後設資料持有者，採用Raft協議來保證每個持有者與同組的其他持有者的資料一致性。

（2）時間序列後設資料：資料組(DataGroup)中的時間序列後設資料中包含了資料寫入時需要的資料型別、許可權等資訊，這些資訊儲存在資料組所在節點（叢集部分節點）上。由於時間序列後設資料的粒度較小，數量遠遠多於儲存組後設資料，因此這些時間序列後設資料儲存在資料組所在的節點上，避免了不必要的記憶體佔用，同時也能通過儲存組後設資料的一級過濾快速定位，同時資料組的Raft一致性也避免了時間序列後設資料儲存的單點故障。

資料組中的每個節點稱為資料分割槽持有者，採用Raft協議來保證每個持有者與同組的其他持有者的資料一致性。

該方法將後設資料按儲存組和時間序列兩層粒度分別在後設資料持有者和資料分割槽持有者中管理，由於時間序列資料和後設資料在資料組內同步，因此每次資料寫入不需要進行後設資料的檢查與同步操作，僅需要在修改時間序列後設資料時進行儲存組後設資料的檢查與同步操作，從而提高系統效能。例如建立一個時間序列並進行50萬次資料寫入的操作中，後設資料檢查與同步操作從50萬次降至1次。

5.3 後設資料分佈

根據後設資料分層管理可知，後設資料分為儲存組後設資料和時間序列後設資料。

儲存組後設資料在全叢集所有的節點上都有副本，屬於MetaGroup組。

時間序列後設資料只在對應的DataGroup上儲存，儲存一些時間序列的屬性，欄位型別，欄位描述等資訊。時間序列後設資料的分佈方式和資料分佈方式一樣，都是通過slot hash產生。

5.4 時間序列資料分佈

分散式系統實現中基於雜湊環和環上查詢演算法將時序資料按照儲存組進行分割槽。將叢集各個節點按雜湊值放到雜湊環上，對於到來的一個時間序列資料點，計算這個時間序列名稱所對應的儲存組的雜湊值並放置到雜湊環上，在環上按順時針方向進行搜尋，找到的第1個節點就是要插入的節點。

使用雜湊環進行資料分割槽時，容易出現兩個節點的雜湊值的差較小的情況，因此在使用一致性雜湊環的基礎上引入虛擬節點，具體做法是將每個物理節點虛擬成若干個，並將這些虛擬節點按照雜湊值放置到雜湊環上，在很大程度上避免了資料傾斜的情況，使資料分佈得更加均勻。

首先，整個叢集預設10000個slot，均勻將此10000個slot分佈在各個DataGroup上。如下圖所示，IoTDB叢集有4個DataGroup，整個叢集有10000個slot，則平均每個DataGroup有10000/4=2500個slot.由於DataGroup的數量等於叢集節點數4，也就相當於平均每個節點2500個slot.