面向工業基礎數據的產線節拍邊緣存儲系統研究

關鍵詞：邊緣存儲；數據存儲系統；丁業互聯網；產線節拍

中圖分類號：TP392 文獻標志碼：A

0引言（Introduction）

工業4.0將信息物理系統融人生產系統，實現了設備智能化連接，促進了物理環境與計算系統之間的精確感知與高效協同，這使得過去無法獲取的生產環境信息得以有效收集。隨著邊緣計算的興起，將物聯網數據存儲在邊緣端并進行低延時的分析和處理成為一種趨勢。同時，工業物聯網設備的多樣化導致了產線基礎數據的多樣性，邊緣存儲終端需要能夠應對不同的數據類型和應用場景，并提供了一種統一的數據抽象。

本文提出了工業裝備數據庫（Industrial EquipmentDatabase，IEDB，以下簡稱“裝備數據庫”），這是一種專為工業產線生產節拍設計的數據存儲解決方案，IEDB以產品的生產節拍為基本存儲單位，支持多種數據類型，并提出了基于生產節拍的統一數據抽象。每一個裝備數據庫被部署在邊緣計算機上，將存儲邊界向邊緣端延伸，采集、整合并直接存儲來自PLC（可編程邏輯控制器）或其他設備的不同粒度和類型的工業基礎數據，具備優異的性能。

1部署架構（Deployment architecture）

裝備數據庫具有較高的部署靈活性和可擴展性。丁業裝備數據庫集群的主要架構如圖1所示。該圖展示了裝備數據庫的主要部署場景：每臺邊緣計算機連接某一產線的若干PLC控制器，PLC通過常用控制總線如CAN（Controller Area Network）、OPC（Open Platform Communications）、Profi總線等連接生產裝備，每個裝備數據庫節點兼任數據采集和存儲工作，因此不同產線的數據分布在不同的邊緣節點中，實現了總存儲容量的線性增長，且生產線的結構發生調整時，其他產線的數據存儲不會受到影響。裝備數據庫集群采用去中心化的設計，每一個裝備數據庫均獨立對外提供數據接入API（Application Programming Interface），在局域網（Local Area Network，LAN）內已授權的客戶端利用裝備數據庫管理平臺軟件或API有能力分別同時訪問集群中所有數據庫內的數據，利用性能強大的客戶端硬件進行數據集成和數據挖掘、展示。區別于傳統的基于云的中心化存儲模式，將存儲負載轉移到邊緣節點能有效消除隨著節點數量增加而導致的中心節點瓶頸效應。

邊緣計算機更加靠近邊緣物聯網設備，這使其有能力對異構設備進行實時分析，此部署方式有利于數據庫與PLC控制程序的集成，與裝備數據庫直連的PLC控制器相當于擁有了一個極低訪問延遲的數據存儲系統，便于PLC控制器進行基于實時數據分析的過程控制。為確保實時程度，裝備數據庫僅提供基本的數據持久化和查詢服務，以及一些基礎的統計分析功能，這使其足夠輕量化且不會對邊緣計算機造成過大的負擔。

2系統設計（System design）

單節點模式下的裝備數據庫可以獨立運行。單個裝備數據庫邊緣節點的主要功能模塊如圖2所示。產線數據通過數據采集協議注入存儲引擎并持久化，客戶端調用查詢操作后，查詢引擎將向存儲引擎獲取數據內容并處理返回；用戶能夠通過元數據管理進行數據定義等操作。本小節將介紹裝備數據庫各個主要模塊的設計和實現過程，包括基于生產節拍的數據模型，以及存儲引擎和查詢引擎等。

2.1節拍數據模型

在實際生產過程中，裝備的運行和動作均由PLC控制器通過周期性地發送指令進行控制。由于指令都是由PLC對設備實時狀態進行分析和計算后獲得的，設備的動作狀態自然也可以通過PLC采集。但是，簡單地存儲所有PLC發出的完整指令信息和其時間戳將會消耗大量的存儲空間，這是因為PLC控制器發送控制指令的周期可以非常短并可能會存儲大量冗余數據。事實上，每一個設備或機器在生產過程中僅周期性地重復同一套動作，如此便能以一個模板描述生產節拍內進行的動作，并僅需存儲生產節拍內的關鍵測量點或信號。基于這些信息，配合不同生產裝備的基本運作特性，可以完整還原一個產品在生產過程中涉及的所有生產裝備的運作過程。

裝備數據庫使用樹形結構描述生產節拍，這種結構更適合描述繼承歸屬關系。節拍樹層級示意圖如圖3所示。圖3中結點的深度表示其在生產關系中的實體層級。本文使用路徑編碼描述其中實體間的繼承關系。路徑編碼是節拍樹中從根節點出發到葉子節點經過的路徑中所有編號的組合，因此一個編碼可以全局唯一地標識一個實體或測量點，例如0102010203表示圖3中最右側的葉子結點；當需要表示一個設備時，僅需使用010201*即可。葉子結點中會額外存儲測量點的數據類型。裝備數據庫支持豐富的數據類型，不僅包括遵循IEC61131-3標準的基本數據類型，還支持數組、時間序列等結構化數據以及圖片、視頻流等二進制數據。

節拍模板按照用戶定義的生產節拍樹生成，其包含樹中的每一個葉子結點的路徑和信息，以連續線性結構排列和存儲，便于以文件形式持久化。每個節拍模板（Rhythm Template）是由其節拍樹所包含的所有葉子結點N的集合。形式上，一個葉子結點可以表示為

在生產節拍中若需要調整關系結構，如新增傳感器、測量點或信號時，僅需編輯節拍樹結點即可。

在裝備數據庫中，數據操作的基本單位是節拍對象（Rhythm Object），節拍對象R是一個存儲生產節拍中所有數據點及節拍標識屬性的數據結構，可以描述為

其中：id用以唯一地標識一個節拍對象，在數據插入時分配；tzmestamp是記錄此節拍對象的發生起始時間戳，賦予節拍對象時序屬性，是數據查詢的關鍵依據；data points是所有測量點或信號的集合，datapoints以連續內存形式組織，其中數據點的偏移量由節拍模板T中定義的順序決定，每個數據點可根據需要附帶一個生產節拍內的相對時間戳，用以表示信號在節拍內的發射時間或測量點的采集時間，這一屬性需要占用額外的存儲空間，因此需要在定義節拍模板T時指定。

2.2元數據管理器

為了對生產節拍樹的元數據進行定義和編輯，由元數據管理器負責管理。用戶可根據某一生產線的某一生產過程周期內涉及的所有設備運作信息定義節拍模板，裝備數據庫將根據定義的模板信息，通過以太網從PLC中采集數據并存儲。存儲在裝備數據庫中的節拍數據，在查詢時將根據此模板信息進行解析。當模板信息被修改后，元數據管理器將保留一份原始元數據的拷貝，并以此元數據的有效起止時間標記，保證歷史數據依然可以正常查詢。

2.3存儲引擎

存儲引擎是實時數據注入（Data ingestion）的主要組件，具有高數據吞吐率特性，負責數據的高效存儲和讀取；它包含一個精簡的堆棧式文件系統（Stacked file system），可以實現自主文件目錄管理以及磁盤空間管理等，并提供流式文件讀寫接口。通過設置不同的磁盤寫入策略，可以決定在磁盤空間不夠時，是否覆蓋最早的歷史數據。

存儲引擎還支持對物理文件中節拍對象的封裝和抽象，為查詢引擎提供以節拍對象為基本單位的操作接口；它將對文件的I/O操作以及煩瑣的文件數據解析轉換為對節拍對象的操作，上層查詢引擎不必關注底層文件結構，能夠直接以節拍對象的粒度進行數據的讀取和處理。

2.3.1數據緩沖

由于數據不保證有序到達，因此為了實現高寫入吞吐率，本文使用RocksDB作為數據緩沖容器。RocksDB是一個高性能的Key-Value型NosoL數據庫。通過調整RocksDB的配置參數，使其能夠更高效地運行在主內存中。實現原理為將RocksDB的數據文件存儲在臨時文件系統Tmpfs中。Tmpfs在絕大多數類Unix系統中均有實現，可將所有文件保存在虛擬內存中，適用于臨時文件的存儲。相比于同樣可運行于內存的數據庫Redis，RocksDB的優勢在于其能以鏈接庫的形式嵌入應用，而非作為服務端通過Socket傳輸數據，節省了網絡協議棧間的開銷，其性能也相應更高。

存儲引擎將插入的數據暫時緩沖到RocksDB中，節拍中的每一個數據點均帶有額外的標記信息，由后臺線程負責對其中的數據點按照節拍模板中定義的順序重組并格式化為在磁盤中持久化的組織形式。盡管同一節拍中不同數據點的到達次序不保證有序，但是不同節拍間的同一數據點有先后順序，這為正確有序地持久化節拍提供了依據。

在持續的數據插入過程中，當RocksDB中緩沖的數據量達到一定閾值時，將觸發Flush操作，存儲引擎將讀取RocksDB中重組后的數據并格式化和寫入磁盤。若部署于較為不穩定的環境下，為防止出現斷電或系統崩潰導致數據丟失的情況，裝備數據庫可啟用寫前日志（Write-Ahead Logging，WAL）技術，保證還未持久化的數據能夠被恢復。數據插入和刷寫過程如圖4所示。

2.3.2數據文件存儲格式

在數據持續插入的過程中，存儲引擎中的后臺Flush線程會把緩沖容器中已重組完成的部分進行格式化后寫入磁盤。文件格式的設計需要盡可能地降低查詢操作時磁盤I/O的開銷。數據文件的詳細格式如圖5所示。

節拍對象R是在裝備數據庫中操作的最小粒度文件對象，其中的數據點按照節拍模板中定義的順序連續存放，每個節拍對象在插入時會被分配一個唯一的ID并帶有一個絕對時間戳。這些信息會被存放在頁頭部。

數據頁面（Page）P={R₁，R₂，…，R_i}是一組連續節拍對象的集合，節拍對象連續存放于數據區，根據頁頭部的索引快速查找符合條件的節拍對象在頁面內的位置。此外，存儲引擎會在每一個頁面后追加頁面內容的CRC（Cyclic Redundancy Check）校驗信息，在一定程度上確保了數據的正確性。數據頁面（含CRC校驗碼）的大小不固定，一般為磁盤簇大小（通常為4kB）的整數倍，多余的空間用0填充。這樣的設計是為了避免不同數據頁面中的內容同時存在于一個磁盤簇中，進而影響I/O效率。

若干數量的數據頁面組成一個塊（Chunk），C={P₁，P₂，…，P_i}。一個塊最終以其存儲的節拍對象的時間戳起止范圍，命名為一個數據文件被寫入磁盤，以便后續檢索。在塊和頁面的頭部將會建立額外的快速查詢索引信息：塊頭部（Chunk Header）和頁頭部（Page Header）。這些信息用以輔助查詢，通常不會占用過多的空間。將所有頁面的頭部信息集中存放的優勢是能夠在一次磁盤I/O內獲取所有頭部信息，并在內存中處理，從而平均僅需2次磁盤I/O即可定位到數據在文件中的位置。對一個塊的數據寫入通常不會一次性完成，需要經過多次Flush操作后封口。采用直接I/O，每次Flush操作后數據均被確實寫入磁盤，而非存入操作系統緩沖，因此即使寫入過程發生斷電等意外情況，實際寫入的內容依然能夠預期，可以盡可能地恢復數據。

2.4查詢引擎

查詢引擎負責數據流的管理、數據分析、緩存的管理及索引的維護，同時對外提供數據查詢和數據基本統計分析的接口。本小節將分別介紹對數據處理性能影響較大的數據索引和數據緩存模塊的設計。

2.4.1數據索引

索引需要充分挖掘數據的時序特性。索引管理器在主內存中維護一個基于時間戳的索引樹，在非葉子結點中不存放數據，以節拍的時間戳范圍區分數據頁。索引結點的鏈路結構如圖6所示。由于對索引的操作通常局限于結點的追加，塊級索引和某一塊內的頁級索引使用連續內存存放，因此能夠對其進行二分查找，兼顧了單點查詢和范圍查詢的性能，能以O（log n）的時間復雜度定位數據頁面的位置。使用索引可避免查詢時對數據的全盤掃描，大幅提升了高頻率、小范圍查詢的性能。索引樹支持二進制的持久化，在啟動時可直接讀取主內存。

2.4.2數據緩存

使用緩存暫時存放讀取過的數據頁面能夠進一步提升系統的數據吞吐量，裝備數據庫使用直接I/O（Direct I/O）方式讀寫磁盤，繞過了操作系統的緩存，從而實現了對主內存更精細的控制粒度，避免了不必要的資源消耗。

緩存頁面能夠以鍵一值對的形式存取，因此同樣可使用RocksDB作為數據頁面緩存容器。在數據頁面置換算法方面，本研究選擇了主流的LRU（Least Recently Used）算法變種——LRU-K算法，基于LRU-K置換的數據查詢流程如圖7所示。在向LRU控制器請求獲取指定頁面時，若未命中，則轉而向存儲引擎請求數據，存儲引擎負責在磁盤中尋找數據，找到數據后，先將數據傳輸給查詢引擎，然后LRU控制器記錄此次訪問，并決定是否將此頁面置換入RocksDB。若命中，直接從RocksDB中的數據頁面中查詢數據。LRU控制器會記錄所有的訪問請求，并維護必要的數據結構。

LRU-K算法的基本思路是追蹤活躍的數據頁面的最近K次歷史訪問，一個新的數據頁面必須被訪問K次，才有機會被置換入內存中。與經典LRU相比，緩存頁面更難被置換出去，這能夠在很大程度上防止在一次大范圍查詢中熱點數據被置換，進而造成緩存污染。通常，K值設為2，即LRU-2能夠應對大多數場景。

3系統評估（System evaluation）

3.1測試環境

在本文的測試中，將單節點部署場景下的裝備數據庫原型與當前廣泛使用的關系型數據庫MysoL，以及專為工業互聯網場景設計的高性能時序數據庫IoTDB進行比較。本研究使用的測試平臺為運行在VMWare ESXi虛擬化平臺上的Linux虛擬機，并為其分配了系統資源（表1）。

本實驗中使用的MysoL版本為8．0．34，IoTDB的版本為0.13。本文將評估插人性能和基于時間范圍的查詢性能。由于沒有為裝備數據庫設計soL語言解析模塊，因此在測試程序中使用裝備數據庫的API接口，也能達到SQL語言解析模塊相同的效果。在本研究的測試數據樣例中，包含60個測量點和信號，覆蓋了所有數據類型。對于MySQL，額外增加一列用于存儲時間戳并將其設為主鍵；對于IoTDB，則是使用60條時間序列。

本研究使用MysoL C++連接器操作MysoL數據庫，同時利用IoTDB提供的C++原生客戶端API進行交互，裝備數據庫原型使用C++開發，這有助于充分挖掘邊緣計算機的性能潛力，其基于庫函數嵌入應用程序中。每項測試使用相同的隨機數據生成程序產生的測試數據。

3.2數據插入性能

本測試程序依據同一隨機種子生成測試用數據，并調用各數據庫的數據插入接口，在達到一定的插入次數時，記錄當前檢查點的時間戳。在測試前關閉系統中不必要的其他進程，測試程序確保所有測試數據均在內存中生成，不進行額外的磁盤讀取操作，盡可能地避免數據庫服務以外的程序進行I/O操作。此測試項目是為了比較在模擬場景中各個數據庫在極限狀態下的數據持續插入能力。不同插入次數的時間消耗如表2所示，表2中的數據展示了在一次持續插入過程中各個檢查點已消耗的時間。

采用的節拍化的數據模型和基于RocksDB的數據緩沖設計充分挖掘了磁盤的順序寫入能力。在系統架構方面，避免了冗余的模塊設計，減少了不必要的計算，使得裝備數據庫在節拍數據持續插入方面遠勝于其他數據庫。雖然MySQL和IoTDB在運行過程中額外多出了本地網絡協議棧以及SQL語句解析等開銷，但是在實際部署場景中，這些開銷無法避免，而IEDB的部署方式和嵌入式的應用形式，則成為其在這種場景下的顯著優點。

3.3數據檢索性能

在本小節中將進行范圍查詢性能的基準測試。對于在線分析處理（Online Analytical Processing，OLAP）工作負載場景，大部分情況下主要使用的是范圍查詢。在“3.2”小節中已為所有數據庫做了相同次數的數據插入基準測試，它們各自存儲了1000000條以上相同的數據。在每一輪測試前，必須確保已重啟系統，避免操作系統的緩存數據干擾測試結果，還要確保操作系統內僅有一個被測數據庫系統處于運行狀態。基于時間區間的范圍查詢，將分別對MysoL、IoTDB、IEDB進行若干次查詢，并取平均成績作為最終結果。所有的時間區間均由相同的隨機數種子隨機生成，每個數據庫完成所有查詢的時間消耗如表3所示。

IoTDB的查詢性能在次數較少時表現最好，IEDB次之，但均遠高于MysoL。在進行連續10000次范圍查詢時，IoTDB服務器端出現了內存溢出（Out of Memory，OOM）錯誤導致系統崩潰。值得注意的是，隨著查詢次數的增加，IEDB的緩存預熱后，查詢性能沒有明顯損耗，性能均高于其他數據庫。不僅如此，本實驗中的IEDB僅使用了32MB的頁面緩存空間，對于系統資源的消耗遠低于前兩者。這主要歸功于針對范圍查詢的數據文件格式優化設計和輕量化的架構設計，它們分別降低了I/O開銷和CPU開銷。

4結論（Conclusion）

本文對工業場景下的節拍數據特點和存儲需求進行了深入分析，為彌補在當前丁業4.0模型中工業基礎數據采集存儲模塊缺失的缺陷，提出了節拍化的數據存儲方式和節拍數據抽象，基于此討論了裝備數據庫的系統架構和模塊的設計，針對產線節拍數據的特性在底層存儲設計上進行了特殊優化，并完成了裝備數據庫原型。經實驗評估，其在工業節拍數據處理方面的綜合性能高于其他常見關系型數據庫和時間序列數據庫。本研究為工業基礎數據的進一步拓展應用提供了可靠的數據基礎。