【本期推薦】華為雲社群6月刊來了，新鮮出爐的Top10技術幹貨、重磅技術專題分享；還有畢業季闖關大挑戰，華為雲專家帶你做好職業規劃。
摘要：本文将會系統地為大家介紹 MRS IoTDB 的來龍去脈和功能特性，重點為大家介紹 MRS IoTDB 時序資料庫的整體架構設計與實作。
本文分享自華為雲社群《MRS IoTDB時序資料庫的總體架構設計與實作》，原文作者：cloudsong。
MRS IoTDB 是華為 FusionInsightMRS 大資料套件最新推出的時序資料庫産品，其領先的設計理念在時序資料庫領域展現出越來越強大的競争力，得到了越來越多的使用者認可。為了大家更好地了解 MRS IoTDB，本文将會系統地為大家介紹 MRS IoTDB 的來龍去脈和功能特性，重點為大家介紹 MRS IoTDB 時序資料庫的整體架構設計與實作。
1. 什麼是時序資料庫
時序資料庫是時間序列資料庫的簡稱，指的是專門對帶時間标簽（按照時間的順序變化，即時間序列化）的資料進行存儲、查詢、分析等處理操作的專用資料庫系統。通俗來說，時序資料庫就是專門用來記錄例如物聯網裝置的溫度、濕度、速度、壓力、電壓、電流以及證券買入賣出價等随着時間演進不斷變化的各類數值（測點、事件）的資料庫。
目前，随着大資料技術發展和應用的不斷深入，以物聯網 IoT(InternetOf Things)、金融分析為代表的兩類資料，表現出随着時間的演進連續不斷地産生大量傳感器數值或事件資料。時間序列資料(timeseries data)就是以資料(事件)發生的時刻（時間戳）為時間軸形成的連續不斷的數值序列。例如某物聯網裝置不同時刻的的溫度資料構成一個時間序列資料：
無論是機器産生的傳感器資料，還是人類活動産生的社會事件資料，都有一些共同的特征：
（1）采集頻率高：每秒采集幾十次、上百次、十萬次乃至百萬次；
（2）采集精度高：最少支援毫秒級采集，有些需要支援微秒級和納秒級采集；
（3）采集跨度大：7*24 小時持續不斷地連續采集幾年、乃至數十年資料；
（4）存儲周期長：需要支援時序資料的持久存儲，甚至對有些資料需要進行長達上百年的永久存儲（例如地震資料）；
（5）查詢視窗長：需要支援從毫秒、秒、分鐘、小時到日、月、年等不同粒度的時間視窗查詢；也需要支援萬、十萬、百萬、千萬等不同粒度的數量視窗查詢；
（6）資料清洗難：時間序列資料存在亂序、缺失、異常等複雜情況，需要專用算法進行高效實時處理；
（7）實時要求高：無論是傳感器資料還是事件資料，都需要毫秒級、秒級的實時處理能力，以確定對實時響應和處理能力；
（8）算法專業強：時間序列資料在地震、金融、電力、交通等不同領域，都有很多垂直領域的專業時序分析需求，需要利用時序趨勢預測、相似子序列。
分析、周期性預測、時間移動平均、指數平滑、時間自回歸分析以及基于 LSTM 的時序神經網絡等算法進行專業分析。
從時序資料的共同特征可以看出，時間序列特殊的場景需求給傳統的關系資料庫存儲和大資料存儲都帶來了挑戰，無法是采用關系資料庫進行結構化存儲，還是采用 NoSQL 資料庫進行存儲，都無法滿足海量時序資料高并發實時寫入和查詢的需求。是以，迫切需要一種專門用于存儲時間序列資料的專用資料庫，時序資料庫的概念和産品就這樣誕生了。
需要注意的是：時序資料庫不同于時态資料庫和實時資料庫。時态資料庫(TemporalDatabase)是一種能夠記錄對象變化曆史，即能夠維護資料的變化經曆的資料庫，比如 TimeDB。時态資料庫是對傳統關系資料庫中時間記錄的時間狀态進行細粒度維護的系統，而時序資料庫完全不同于關系資料庫，隻存儲不同時間戳對應的測點值。有關時序資料庫與時态資料庫的更詳細對比，後續将會發文專門介紹，在此不再詳述。
時序資料庫也不同于實時資料庫。實時資料庫誕生于傳統工業，主要是因為現代工業制造流程及大規模工業自動化的發展，傳統關系資料庫難以滿足工業資料的存儲和查詢需求。是以，在 80 年代中期，誕生了适用于工業監控領域的實時資料庫。由于實時資料庫誕生早，在擴充性、大資料生态對接、分布式架構、資料類型等方面存在局限，但是也有産品配套齊全、工業協定對接完整的優勢。時序資料庫誕生于物聯網時代，在大資料生态對接、雲原生支援等方面更有優勢。
時序資料庫與時态資料庫、實時資料庫的基本對比資訊如下：
2．什麼是 MRS IoTDB 時序資料庫
MRS IoTDB 是華為 FusionInsightMRS 大資料套件中的時序資料庫産品，在深度參與 ApacheIoTDB 社群開源版的基礎上推出的高性能企業級時序資料庫産品。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 在 ApacheIoTDB 已有架構的基礎上，融合 MRS Manager 強大的日志管理、運維監控、滾動更新、安全加強、高可用保障、災備恢複、細粒度權限管控、大資料生态內建、資源池優化排程等企業級核心能力，對 ApacheIoTDB 核心架構尤其是分布式叢集架構做了大量的重構優化，在穩定性、可靠性、可用性和性能方面做了大量的系統級增強。
（1）接口相容性：
進一步完善北向接口和南向接口，支援 JDBC、Cli、API、SDK、MQTT、CoAP、Https 等多種通路接口，進一步完善類 SQL 語句，相容大部分 Influx SQL，支援批量導入導出
（2）分布式對等架構：
MRS IoTDB 在基于 Raft 協定的基礎上，采用了改進的 Multi-Raft 協定，并對 Muti-Raft 協定的底層實作進行了優化，采用了 CacheLeader 等優化政策在保障無單節故障的基礎上，進一步提升 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 管理時間序列資料，增加了存儲組的概念，下面為大家分别解釋一下：
存儲組(StorageGroup): IoTDB 為了管理時序資料提出的一個概念，類似于關系資料庫中的資料庫的概念。從使用者角度，主要用于對裝置資料進行分組管理；從 IoTDB 資料庫角度，存儲組又是一個并發控制和磁盤隔離的機關，不同存儲組之間可以并行讀寫。
裝置 (Device)：對應現實世界中的具體實體裝置，例如：電廠某制造單元、風力發電機、汽車、飛機發動機、地震波采集儀器等。在 IoTDB 中, device 是時序資料一次寫入的機關，一次寫入請求局限在一個裝置中。
傳感器(Sensor): 對應現實世界中的具體實體裝置自身攜帶的傳感器，例如：風力發電機裝置上的風速、轉向角、發電量等資訊采集的傳感器。在 IoTDB 中，Sensor 也稱為測點（Measurement），具體指傳感器采集的某時刻的傳感器值，在 IoTDB 内部采用<time, value>的形式進行列式存儲。
存儲組、裝置、傳感器的關系如下面的例子：
時間序列(TimeSeries): 類似于關系資料庫中的一張表，不過這張表主要有時間戳(Timestamp)、裝置 ID(Device ID)、測點值(Measurement)三個主要字段。為了便于對時間序列的裝置資訊進行更多描述，IoTDB 還增加了 Tag 和 Field 等擴充字段，其中 Tag 支援索引，Field 不支援索引。在有的時序資料庫中，又稱為時間線，表示記錄某裝置某傳感器值随着時間不斷變化的值，形成一條沿着時間軸不斷追加測點值的時間線。
路徑(Path)：IoTDB 構造了一個以 root 為根節點、把存儲組、裝置、傳感器串聯在一起的樹形結構，從 root 根節點經過存儲組、裝置到傳感器葉子節點，構成了一條路徑。如下圖所示：
虛拟存儲組：由于存儲組的概念具有使用者對裝置分組和系統進行并發控制的雙重作用，二者的過度耦合會造成使用者的不同使用方式對系統并發控制的影響。例如：使用者把不相關的所有裝置資料都放到一個存儲組中，IoTDB 對這個存儲組加鎖進行并發控制，限制了資料的并發讀寫能力。為了是實作存儲組與并發控制的相對松耦合，IoTDB 設計了虛拟存儲組這個概念，把對存儲組的并發控制細粒度拆分到虛拟存儲組這個粒度，進而減少了并發控制的粒度。
4.2 MRS IoTDB 的基本架構
單機 MRS IoTDB 主要不同的存儲組構成，每個存儲組是一個并發控制和資源隔離機關，每個存儲組裡面包括了多個 TimePartition。其中，每個存儲組對應一個 WAL 預寫日志檔案和 TsFile 時序資料存儲檔案。每個 TimePartition 中的時序資料先寫入 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)包含了查詢資料時的路由資訊，存儲組（StorageGroup）的中繼資料資訊在叢集所有節點上全量儲存。存儲組的粒度較大，一個叢集内部的存儲組數量級遠遠小于時間序列的數量級。是以在叢集所有節點上對這些存儲組中繼資料的儲存，大大減少了記憶體的占用。
中繼資料組中的每個節點稱為中繼資料持有者，采用 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.
其次， 完成 slot 到 DataGroup、Time Partition 和 time series 的映射。
IoTDB 叢集根據 raft 協定劃分成多個 DataGroup 組，每一個 DataGroup 組中包含多個 slot，而每一個 slot 中包含多個 time partition，同時每一個 time partition 中包含多個 time series，構成關系如下圖所示：
最後，通過 Hash 計算 slot 的值，完成輸入存儲組和時間戳到 slot 的映射：
1）先按時間範圍分區，利于時間範圍查詢：
TimePartitionNum = TimeStamp %PartitionInterval
其中 TimePartitionNum 是時間分區的 ID,TimeStamp 是待插入測點資料的時間戳，PartitionInterval 是時間分區間隔，預設是 7 天。
2）再按存儲組分區，通過 Hash 計算出 slot 的值：
Slot = Hash(StorageGroupName + TimePartitionNum) % maxSlotNum
其中 StorageGroupName 是存儲組的名字，TimePartitionNum 是第 1 步計算出的時間分區 ID，maxSlotNum 是最大 slot 數，預設 10000。
Data Group 和 StorageGroup 的關系如下圖所示，其中節點 3 和節點 1 上的 Data Group 1 展示的是同一個 Data Group 分布在兩個節點上的情形：