杜星熠,胡 靜,蔣 偉,宋鐵成
(東南大學 信息科學與工程學院,江蘇 南京 210096)
隨著物聯網(Internet of Things,IoT)的不斷發展,數據量劇增,對設備數據的監控處理成為維護物聯網的重要部分。在海量數據中獲取、查詢到可供維護人員使用的有用信息,成為物聯網數據管理系統設計時需要解決的問題。因此,由數據驅動的針對物聯網的復雜事件處理[1]成為研究的熱點。物聯網的日常管理充斥著大量規則,并且這種規則隨著業務和上層決策的變化而變化。規則引擎可以實現業務規則和應用代碼的去耦合,可以通過調整業務規則而不改變應用代碼的方式來改變物聯網的運行機制,讓物聯網更加快速、平穩地應對需求的變化。
規則引擎起源于專家系統[2],其通過規則來進行任務的決策。規則用于描述業務的邏輯或策略。目前,國內外的規則引擎技術越來成熟,由于其具備靈活性和廣泛適用性,故在物聯網、電力、娛樂等領域都發揮著重要的作用。其中,使用最廣泛的是Drools規則引擎[3]。目前,國內外物聯網場景中對規則引擎的使用主要是獲取實時數據進行推理,并根據推理過程的結果進行操作。在物聯網數據管理應用中,目前的主流方法是使用Drools規則引擎的DRL文件和XLS決策表[4]文件來配置規則。這種方式可以實現規則與應用代碼的完全分離,并且可以快速建立規則網絡。在查詢數據時,每個數據均會進入網絡進行匹配。但在大數據量的環境下,重復機械的比對會產生冗余,會對性能產生較大影響。所以,針對不同的使用場景,選擇合適的架構對提升查詢性能有著重要的作用。
為了解決物聯網數據查詢中重復比對產生冗余的問題,在DRL規則文件與決策表文件架構的基礎上,設計了修正數據庫的數據查詢方法。該方法通過將JSON格式的規則文件解析后存入數據庫中,動態地與數據關鍵字對比,從而得到符合約束條件的表單數據;并通過實驗對比了DRL規則文件、決策表文件方法和修正數據庫在大數據環境下查詢數據的性能。實驗結果證明:修正數據庫方法可以有效減少數據匹配的冗余。
規則引擎本質上是一種推理引擎[5],通過將事實、數據與產生式規則進行匹配,并在規則庫中對規則進行統一管理,最終匹配的規則將被執行[6]。規則引擎將代碼與業務部分進行區分,使業務決策變為一個單獨的部分。其核心工作就是獲取規則映射的知識,再將其應用到特定的數據上。規則生產寄存器中可以通過解析將復雜的規則用清晰的形式表達出來。圖1為Drools規則引擎的運行機制[7]。

圖1 Drools規則引擎的運行機制
在Drools規則引擎的結構中,事實是對象之間、對象屬性之間的關系,并且事實存在于工作區域中,是普通業務對象的結果集[8]。規則是業務人員根據工作需求使用規則引擎提供的接口來編寫的規則文件(在Drools規則引擎中可以是DRL規則文件也可以是XLS決策表)。將規則文件加載至內存中,可以對事實進行一系列的操作,從而進行篩選[9]。
Forgy[10]在1979年提出的Rete算法,是產生式系統高效的模式匹配算法。Rete算法利用規則各個域之間的公用部分,減少規則的存儲。同時為了保證匹配過程中的速度,Rete算法保存匹配過程中的臨時結果[11]。為了保存臨時結果,算法將規則拆分,以節點的形式存在,通過節點連接成為一個網絡。將所有事實數據通過網絡進行規則篩選。圖2為Rete算法規則網絡。

圖2 Rete算法規則網絡
Rete匹配網絡由知識庫、Alpha網絡、Beta網絡和輸出集合組成[12]。知識庫是事實進入網絡的入口,也被稱為root節點或knowledge節點。輸出節點又稱output節點,代表對應的規則經過匹配已經激活。Alpha網絡是模式網絡[13],由規則庫中的規則構成,用于記錄每一個匹配條件,每一個節點代表一種匹配模式,每一個模式的所有節點相連就構成一條匹配鏈[14]。Alpha網絡由alpha節點構成,每個alpha節點只有1個輸入。為了減少重復計算量,不同的規則中若存在不同的模式則可以共用1個節點。Beta網絡是連接網絡[15],用于檢查規則內部不同模式之間因相同變量造成的約束關系。Beta網絡由beta節點構成[16],每個beta節點最多可以有2個輸入。當信息傳遞至輸出節點時[17],代表Rete網絡與知識庫對應的規則已經被解析激活。
Drools規則引擎極大地推動了行業的發展,但仍有很多問題需要解決。DRL文件的語言是類Java語言,需要一定的維護門檻。若維護人員對Java較為生疏,則需要一定的學習成本。規則引擎主要應用于金融或政務服務部門,用于對復雜的規則體系以及較為簡單的數據進行復雜事物處理。隨著物聯網設備的數量和種類不斷增加,對設備數據的實時性要求也隨之增加。物聯網管理也逐漸呈現多規則的特點。規則引擎在建立多規則的規則網絡方面有著獨特的優勢,但大量數據進行單一的重復性比對會造成時間和資源的浪費。
為了驗證Drools規則引擎在物聯網數據查詢中的性能,設計的架構包括數據接入單元、規則引擎模塊和數據庫驅動模塊。其中,數據接入模塊模擬物聯網傳輸數據,用于存儲不同量級的數據;規則引擎模塊用于物聯網數據查詢語句規則的解析和數據約束條件的解析處理;數據庫驅動模塊用于連接規則引擎與數據庫,使得解析后的查詢語句和查詢到的數據可以繼續解析處理。
規則引擎模塊是整個實驗系統的核心部分。支持用戶根據實際靈活定義規則。匹配規則分別通過DRL規則文件、決策表和修正數據庫的方式定義。傳入規則引擎的待解析實例采用JSON格式文件,用于描述數據庫查詢語言和數據的約束條件。實例通過規則引擎按照規則的設定解析成標準的查詢語句并獲取數據的約束條件,最后通過數據庫查找到符合查詢規則和數據約束條件的數據。
DRL規則文件描述規則時一般包含表1所示的內容。

表1 DRL文件語法示例
其中,package為定義規則文件的包名,代表程序對規則的指示,不代表真實規則的存儲路徑;import是需要導入的類名,由于DRL文件用類Java語言編寫,故可以導入外部定義的變量和公共的靜態方法;rule代表規則的開始,并且用唯一的規則名標識;salience為規則的優先級,在有多條規則時,其數字越大,相應規則的優先級程度越高[18];when之后為條件部分[19],定義了當前規則的條件,此部分可以有零或多個條件;結果部分處于then與end之間,是滿足條件之后需要執行的動作,這部分語句可以用Java語言編寫,end代表此規則結束。
采用DRL規則文件方式的工作流程如圖3所示。

圖3 采用DRL規則文件方式的工作流程
DRL文件中存儲的是解析實例的規則,將DRL文件導入到規則引擎的指定路徑,規則引擎開始根據規則文件進行查詢語句的解析,循環遍歷所有規則,將滿足查詢語句規則約束條件的終節點取出拼接成標準的數據庫查詢語句;利用關于數據的約束條件的節點形成規則網絡;使用JDBC連接數據庫查詢到相應表單的數據后,數據作為實例通過數據規則網絡進行數據篩選,最后輸出合適的數據。
決策表是一個精確且緊湊的表示邏輯的方式,目前決策表支持的文件格式主要有XLS、CSV,其可以與DRL規則文件實現無縫替換。表2為決策表使用格式。

表2 決策表使用格式
其中,RuleSet相當于DRL文件中的package,用于定義規則的包名;Import是規則文件中需要導入的類名,可以導入外部定義的變量和公共的靜態方法;CONDITION是規則的觸發文件;ACTION為對應條件觸發后的動作,一般與CONDITION是并行存在的。需要注意的是,決策表判斷的條件參數需要在文件下方列出,通過傳參的方式進行比較。決策表也可在需要的時候解析為普通的DRL文件使用。
決策表在編譯時,也需要與DRL文件一樣在kmodule.xml模塊中配置相應的標識,并在規則引擎會話開始時導入相應的標識。圖4為決策表實現流程。

圖4 決策表實現流程
編寫好相應的解析查詢語句規則和數據匹配規則的決策表文件導入規則引擎指定路徑并在kmodule.xml中配置好規則文件標識。觸發規則引擎和節點后,會循環查找規則文件中的CONDITION,并與ACTION部分進行解析與處理,獲得查詢語句和數據約束條件的網絡。通過數據庫獲取數據后會繼續匹配數據規則,并篩選出符合條件的數據,最后會輸出符合查詢條件的數據。
2.1節和2.2節所述方式要先建立查詢語句與數據匹配規則網絡之后再將數據導入規則網,導致所有的數據均要通過匹配網絡進行匹配。這使得大量的無關數據會在節點中進行比較,因此會消耗較多的時間。修正數據庫采用JSON格式的規則語句,通過規則引擎進行JSON規則的解析,并將解析得到的規則類型和數據的約束條件存入數據庫中。在存入規則類型的同時,規則引擎操作數據庫根據解析規則類型選擇相應的表單,并將表單數據與解析的數據約束條件進行比較篩選。循環此過程直至規則解析結束,此時,獲取的表單數據就是滿足查詢條件的數據。圖5為修正數據庫實現流程。

圖5 修正數據庫實現流程
修正數據庫架構較DRL規則文件方法和決策表文件方法的改進體現在:使用JSON數據格式的規則文件,解析速度較快;數據篩選與解析規則是在同一時間進行,雖然損失了一些解析時間,但優化了數據查詢輸出的時間;不需要頻繁地更換規則文件,只需改變相應的JSON格式文件的內容。
修正數據庫方式具體工作流程如下。
(1)用JSON格式的語句描述需要查詢語句的規則以及相應的數據約束條件。
(2)配置入規則引擎進行相應格式的解析。
① 解析到對應數據的表單關系。
② 通過JDBC連接數據庫并將相應的表單數據存入庫中,同時建立網絡。
③ 依次解析數據約束格式并存入與2.2節對應的表單中。
④ 根據已解析部分規則網絡進行數據篩選,并將數據結果暫存。
(3)重復執行①~④,直至所有規則及約束條件完全解析。
(4)根據解析結果選擇對應的表單數據。
為了更好地比較規則引擎在物聯網數據管理中的應用,本文設置了2組實驗。第一組為分析相同規則數不同實例數和相同實例數不同規則數對規則引擎性能的影響。第二組為基于大數據量的查詢對DRL規則文件方法、決策表方法和修正數據庫方法進行進一步的評估。實驗軟硬件環境配置如表3所示。

表3 實驗環境配置
(1)實驗一:為了適應多規則配置的方便性,使用DRL文件進行配置,分別設置規則數為10條、100條、200條、500條的規則文件,并分別用500例、1500例、3000例、5000例、7500例、10000例通過不同的規則,規則數與實例數耗時如圖6所示。
由圖6可知,隨著規則數量的增加,規則建網時間也隨之增加,同一數量級實例數通過不同規則文件的總耗時不同,并且時間增加主要與建網時間的增加有關;規則數相同,不同實例數經過規則引擎時,時間增加呈現正相關關系。在實例數一定時,規則數的增加會使實例匹配的時間變長。尤其是規則數達到500后,規則的冗余性變強,匹配的增幅變大。由此可知,在物聯網規則引擎設計中,選取適量的規則數有利于提升物聯網管理系統的性能。

圖6 規則數與實例數耗時
(2)實驗二:通過將隨機生成數據存入數據庫模擬設備運行期間發送的各種數據。隨機數據是通過設置數據整體格式,通過Java隨機產生不同的數據。為了對比不同方式對不同數據量的處理性能,實驗分別設置了5000條、10000條、100000條和1000000條數據的表單,分別用DRL規則文件、決策表文件和修正數據庫3種方法對規則進行解析并查詢相應數據。所有測試數據保持格式統一。不同配置方法查詢同一量級數據時,數據類型和數據內容保持一致。評判標準為總耗時時間、解析規則時間和查詢輸出時間。以程序開始為總計時起點、程序結束為計時終點,以此得到總時間。輸出的第一條數據作為計算查詢輸出數據時間的起點。修正數據庫方法、DRL規則文件方法和決策表文件方法的測試性能如表4所示。

表4 不同配置方法的測試性能
系統的并發量可以用吞吐量(Throughput)來衡量。表4中的吞吐量為標準時間內的吞吐量,即單位時間的吞吐量(單位為條),計算公式為
(1)
式中:m1為t1時刻處理的數據總量;m2為t2時刻處理的數據總量;Throughput為t1和t2期間系統處理數據的平均吞吐量。
由表4可得,隨著各種方式數據量的增加,總耗時隨之增加,并且吞吐量也會有所增加。對比3種不同方法對于同一數據量級的性能,修正數據庫方法的總耗時和吞吐量均優于DRL規則文件方法和決策表文件方法。
圖7~圖10為在4種不同數據量級下3種配置方法的性能對比。查詢總時間由解析時間與數據匹配查詢時間構成,具體數據如表5所示。由圖7~圖10可知,在同一數量級的前提條件下,修正數據庫方法的查詢總時間相對于DRL規則文件方法和決策表文件方法有明顯改善。

圖8 10000條數據查詢時間

圖9 100000條數據查詢時間

圖10 1000000條數據查詢時間

表5 不同配置方法的性能分析 單位:s
由表5可知,DRL規則文件方法與決策表文件方法解析時間有些許不同,DRL規則文件方法通過規則引擎分解規則建立規則網絡,故速度更快。決策表文件方法需要讀取決策表文件并將決策表內語言轉換為相應的格式,所以解析性能相較DRL規則文件方法略有下降。在數據篩選查詢階段,兩種方法的耗時差異較小,均是所有數據一一進入網絡進行匹配。修正數據庫方法的解析規則和約束關系時間較長,這是因為修正數據庫方法在解析規則時,將規則和約束條件解析至數據庫存儲后進行動態篩選,故解析時間有所增加。
修正數據庫方法中,解析時間占據了大部分查詢總時間,這是因為解析規則和數據初篩選是在一起的,隨著規則解析結束和數據初篩選的結束,可以一次性獲得數據庫中的表單數據。雖然修正數據庫方法解析時會有相對較多的時間損耗,但是數據匹配查詢時間會大幅減少,因此其查詢總時間可以快速超過DRL規則文件方法和決策表文件方法,圖7~圖9中的交點就是修正數據庫方法查詢總時間逼近DRL規則文件方法的時間點。相較于DRL規則文件和決策表文件架構,修正數據庫架構雖然損失了一部分解析時間,但是對于大數據量的查詢總時間有較大的改善作用,對規則內部形式較為單一且規則數量、數據數量大的場景有著較好的性能。
針對DRL規則文件和決策表文件架構在數據查詢中出現的重復比對冗余問題,設計了一種修正數據庫的數據查詢方法,并給出了該方法的工作流程。通過實驗分析了Drools規則引擎中規則數、實例數與查詢性能之間的關系,以及DRL規則文件、決策表文件和修正數據庫方法在不同量級數據環境下的查詢性能。實驗結果表明:修正數據庫數據查詢方法減少了無效數據的重復比對,減少了冗余,有效地提高了數據查詢的性能。