9 月 24 日，“保障數據永不丟失！數據管理實戰：分區、同步與備份”直播中，天謀科技時序數據庫內核研發工程師，IoTDB 項目交付負責人曹志佳圍繞 IoTDB 分區同步和備份相關原理及實踐展開，為大家介紹了數據分區對時序數據庫的重要性、IoTDB 的分區機制和同步方式，以及流處理框架的應用場景。

此次直播回放可在這里查看，主要內容我們為你總結如下：

01 數據分區的重要性及特征

（1）時序數據背景及特征

隨著 IT 和 OT 行業技術的快速迭代，時序數據在工業、能源、軍工等眾多領域的價值日益凸顯，如在 AI 分析、設備預警等場景中發揮著重要作用。

時序數據的特點，一是測點數量巨大，如儲能行業大型儲能站傳感器數量可百萬級，全國范圍內測點量級能達百億；汽車行業某品牌在路上行駛車輛的測點量級可達 10 億以上。二是存儲代價大，如鋼鐵制造行業超大型煉鋼裝置和新能源發電場景中的風機，數據產生量大且采集頻率高，對磁盤需求達 PB 級以上。

（2）數據分區的定義及優勢

數據分區的定義為將數據按照一定規則進行切分，形成可獨立管理的數據單元。以圖書館管理書籍為例，有數據分區時，按類別將書籍放置在不同書架，管理和查找效率更高。

面對海量的時序數據，傳統數據庫難以管理，數據分區可提高數據管理和查詢效率。

02 IoTDB 的數據分區機制

（1）分區維度及概念

IoTDB 的數據分區基于序列和時間兩個維度，涉及概念包括序列分區槽和時間分區槽。

序列分區槽是對時間序列的縱向管理機制，默認是數據庫級別的，每個數據庫持有固定數量（默認 1,000 個）的序列分區槽，通過哈希算法將序列分配到不同槽位，可避免內存映射占用過多問題。

時間分區槽是對時間序列的橫向管理機制，將數據按固定時間范圍（默認 7 天）切分，可提高數據查詢效率。

（2）分區在集群中的分布

IoTDB 節點分為 ConfigNode 和 DataNode，ConfigNode 是集群的管理者和協調者，DataNode 處理客戶的讀寫請求。

源數據分區和數據分區位于 DataNode 中，每個 DataNode 上存在一個或多個 SchemaRegion 和 DataRegion。IoTDB 集群通過負載均衡算法保證數據分區在不同節點上均勻分布，提高數據存儲和寫入的均衡性和效率。

（3）讀寫視角下的分區執行流程

寫入流程中，客戶端將寫入請求發送給 IoTDB 集群的任意節點，節點根據 device_id 做負載均衡算法，確定數據寫入的節點，再根據數據攜帶的時間判斷其所屬的時間分區。

查詢流程中，查詢請求發送到數據庫后，查詢引擎通過 device_id 快速判斷數據所在節點，將請求轉發給該節點生成查詢計劃，再根據查詢請求中的時間范圍從相應時間分區中撈取數據，無需掃描其他時間分區，提升查詢效率。

03 IoTDB 的數據同步機制

（1）數據同步的分類及場景

IoTDB 的數據同步機制分為集群內同步和集群外同步。

集群內同步是指集群不同節點之間的數據同步，基于一致性協議實現，目的是保證集群的高可用和數據副本的一致性。

集群外同步是指不同 IoTDB 集群之間的數據同步，可用于多集群間的數據協同，如熱備份、容災和端邊云協同等場景。

（2）集群內同步的協議及流程

IoTDB 支持的協議類型分為強一致性和弱一致性（最終一致性）協議。IoTDB 源數據分區和 ConfigNode 采用 Ratis 強一致性協議，確保請求在所有副本間成功更新才認為成功，但會產生數據延遲；DataNode 的讀寫采用團隊自研的 IoTConsensus 協議，允許數據先寫入本地，再異步同步到其他節點，可最大化提升寫入性能。

同步流程中，服務端收到請求后，先由共識層處理，將請求下發給狀態機，再由狀態機下發給 DataRegion，DataRegion 調用存儲引擎將請求寫入內存表和 WL。日志分發線程異步將寫入請求同步給副本節點，維護一個待同步隊列，當隊列無元素時向共識層索要請求。若副本節點掉線，主節點會記錄同步進度，節點恢復后繼續同步，保證數據的最終一致性。

集群內協議可用于集群內單點故障的容災，當主節點出現問題時，備節點能自動升級為主節點繼續提供讀寫服務。

（3）集群間同步的框架及應用場景

IoTDB 提供的流處理框架包括數據抽取、數據處理和數據發送三個階段。數據抽取決定從 IoTDB 中取出的數據范圍，包括測點范圍和時間范圍；數據處理可對抽取的數據進行編程化處理，如刪除離散值、轉換數據類型等；數據發送由用戶決定將處理后的數據發送到何處?？蚣苤С钟脩艋诠俜教峁┑臉藴驶幊炭蚣茏远x邏輯，官方也提供了一些內置插件。

IoTDB 的流處理框架可用于備份和容災，通過簡單 SQL 即可創建數據同步任務，無需依賴第三方組件，實現異地容災，延遲可達毫秒級。還可應用于數據庫內的實時告警、流計算、實時聚合和數據寫回等場景，數據庫間的雙活集群、降采樣同步、跨網閘傳輸和數據加密等場景，以及數據庫外的數據訂閱、發送到消息隊列、Flink 數據加工和離線歷史備份等場景。

04 問答環節信息匯總

（1）Ratis 協議使用建議

對于追求數據高一致性且對寫入性能要求不高的場景，可考慮使用 Ratis 協議，IoTDB 對數據分區支持 Ratis 協議，但性能不如 IoTConsensus 協議。

（2）序列分區設計原因

面對超海量的源數據，如儲能和氣象場景，為減少內存管理資源消耗，采用序列分區槽的降維方式進行管理。

（3）跨網閘傳輸適配

流處理框架已對常見網閘（如南瑞、科東）做過適配，未適配的網閘只需進行簡單適配即可使用。

（4）高性價比軟硬件存儲方案

IoTDB 支持多級存儲，可將高頻數據存儲在 SSD 上，低頻數據存儲在機械硬盤或 S3 上，且支持查詢時從 S3 拉回數據，用戶對此過程無感。

（5）主節點磁盤損壞數據丟失問題

主節點給副本節點發數據延遲低，基本可控制在 1 毫秒以內，但極端情況下可能有數據丟失，這是最終一致性協議相對于強一致性協議的小弊端。

（6）高一致性與最終一致性對比

寫入時，使用 Ratis 協議和 IoTConsensus 協議性能相差一半以上；查詢時，IoTDB 默認查主節點，只要數據寫入，查詢效率不受影響。

（7）主副本掉線數據丟失問題

主節點會在共識層維護寫入請求的 index，記錄數據同步進度，節點恢復后能繼續同步未完成的數據，不會丟失。

（8）多副本影響

多副本保證數據高可用，但會增加存儲空間需求。寫入時，副本同步為異步操作，一般不影響主線程，但在服務器資源瓶頸時可能有影響。

（9）主節點帶寬要求

IoTDB 采用多主協議，每個節點都可對外提供查詢服務，數據查詢負載相對均衡。若帶寬有限，可在網絡傳輸中對數據進行壓縮，但會降低傳輸效率。

（10）查詢優化

客戶端知道每個設備所在的 leader 節點，可自動連接該節點進行查詢，減少請求轉發。

（11）client 存儲配置

cache leader 功能可配置，客戶端資源好時可開啟，資源不足時可關閉。

（12）指定節點存儲副本問題

目前不支持指定節點存儲數據副本，但支持手動遷移。可通過創建多個集群進行實時數據同步，實現異地雙活。