OptaPlanner將棄用DRL(Drools)評分方式！！！

　　本來這段時間一直都在加緊我家“三胎”（易排通用智能規劃平臺）建設，畢竟我們的通用規劃平臺原定6月初就能上線，但因為其中遇到的各種技術問題及其它專案的突發情況，導致也只能跟隨國家的003號航母，只能推遲上線，進度緊迫，經過近兩個星期的奮戰，終于將我們的【易排通用智能規劃平臺】的主要功能上線了，并做了一些基本的使用資料，供各位小伙伴先得試用，

　　因為我們的平臺還處在剛上線提供試用階段，后續還有數不清的功能、平臺設計、應用小視頻需要我日以繼夜地奮力補充（這些資料里不僅僅有平臺的介紹資料喔，也有我們做規劃或供應鏈資訊化設計程序中的一些滿滿干貨，敬請期待），理應是安排不了時間發布新的文章，但發現OptaPlanner已官宣，將在8.x版開始棄用對Drools評分機制，并在9.x不再支持Drools作為評分，作為替換的，將使用Constraint Stream（約束流）方式作為評分，當然，之前支持的Easy Java score calculation和Incremental Java score calculation這兩種方式必然不會取消的，其中，我們的【易排通用規劃平臺】使用的就是Incremental Java score calculation，這種方式的優點是極度高效，有能力的小伙伴可以通過官言的示例嘗試一下，目前大多數案例都有多種評分方式的，可以通過修改配置來嘗試不同的評分方式，當問題空間足夠大時(相同的問題模型，問題空間基本上取決于資料量大小)，其運算時間差異可以是一個數量級的，甚至當數量大到一定程度時，使用Drools的評分方式會出現崩潰的情況(之前我們做過一個VRP專案遇到到這種情況，節點足夠多時，不是放一兩個小時就能跑出來，而是跑著跑著就出現JVM級別的溢位例外了)，

　　關于Drools評分方式（下稱DRL評分方式，官方也使用類似的叫法）的優劣，及未來補充的ConstraintStream方式，在本文中作一些概括性介紹，更詳細的資料及從DRL到ConstraintStream的轉換，可以參考OptaPlanner官方發布的博文：

https://www.optaplanner.org/blog/2022/05/26/optaplanner-deprecates-score-drl.html

使用DRL評分方式的優點

邏輯表達豐富，可用較簡短的腳本表達較復雜的業務邏輯

　　因為Drools本身是與OptaPlanner同屬一專案群(KIE)的開源規劃引擎軟體，它具有一套成熟的規劃描述腳本及規則推理引擎，算是目前世界上最成熟的開源規則引擎了（有沒有之一不清晰，也許是我見識不夠廣），因此，當我們使用Drools腳本，對OptaPlanner中涉及到的各種各樣業務規則(都會抽象成約束)進行評分描述時，是相當有優勢的，OptaPlanner這個引擎與Drools有相當豐富的介面，可實作兩個引擎之間的高度匹配，從而則讓OptaPlanner具備更豐富的約束表達能力，

自主生成OptaPlanner中規劃物體的約束違反統計資訊

　　我們做OptaPlanner程式的時候，歸根到底是要以高效、合理的方式對讓引擎對各個規劃物體(Planning Entity)中的規劃變數(Planning Variable)進行不同的取值組合，并照我們撰寫好的評分約束對各個組合方案進行評分，從中找到評分最高的組合方案，而在此程序中，若我們使用DRL評分方式，哪個規劃物體的哪個取值違反了哪條約束被扣了多少分，通過DRL的評分方式在運算程序，會把上述做詳細的記錄，因此，當我們完成規劃運算，得到一個方案時，通過這個方案和OptaPlanner的評分API，就可以完整、精確地描述出，究竟是哪個規劃物體的哪個變數取了什么值違反了哪個約束，導致被扣了多少分了，這樣看來這個功能是不是很炫？目前我見到的其它求解器，應該還沒有提供這種功能吧？當然也可能是我孤陋寡聞，而這個功能在業務場景上來說，是相當有用的，就是說，當你的規劃程式跑出一個生產計劃方案，這個計劃方案哪個任務放在哪個機臺上，導致扣了多少分，你直接就可以通過它的約束違反資訊，就可以直接找到違反約束的原因和具體資料，而不需要我們人工對整個計劃方案中的各個資料，一個一個尋找，

　　相同的功能要求，如果我們使用的評分方式是Incremental Java score calculation，是沒有自動的功能來記錄這些約束違反資訊的，而是需要我們在實作這個約束邏輯Java代碼里，撰寫相應的評分邏輯，來保存這些資訊的，完成了些邏輯后，最終生成的計劃方案，才能統計出各個任務的約束違反情況，否則你只能從方案知道它的分數概況，也就是僅能知道哪個約束扣了多少分，但是哪個任務分配到哪個機臺，因為與哪個任務沖突引起的扣分，不通過人工去撰寫邏輯，你是看不到的，

使用DRL評分方式的優點

　　老師教導我們，所有事物都要辯證地看，因為事物必然具有兩面性的，那么DRL的評分方式的缺點在哪里呢？

學習成本

　　這個缺點對于我們沒有涉及到規劃引擎的小伙伴來說，肯定是一個巨大的差評，畢竟我們去掌握一門新的開發語言都需要花費不少精力了，況且還要學習掌握一門專門撰寫規則的腳本，雖然它是一種描述性的腳本語言(我們在學校進而學計算課的時候，把這種語言稱為第四代語言，例如：SQL腳本)，但絲毫不代表它簡單，在面對一些復雜的場景時，要實作一些約束的邏輯，我們寫腳本雖然不長，但其實要實作它，還是要花費不少心思的，總不會有人說，SQL腳本就比C++、Java簡單吧？SQL腳本簡單的僅僅是表達的方法，但處理一大堆復雜關聯查詢時，一條SQL的難點不一定比C++低，畢竟C++還是針對具體的每個物件進行運算的，而SQL則主要設計來針對一個資料集合進行處理的，所以并不能說它就簡單，

　　要完成對Drools引擎在OptaPlanner上的應用，除了要了解Drools腳本以外，還需要對Drools這個規則引擎的一些基本原理與結構有一定理解，才能更好的理解每個評分約束中，每個變更的含義，例如：哪些變數代表的是一個物件，什么情況下一個變數代表的是一個物件串列，

　　當然若完全掌握了Drools的評分方式，并積累了一定用DRL表達OptaPlanner約束的經驗后，面對一些約束，還是很有“拿著錘子你看到的滿眼都是釘子”感覺的，也就是，當你面對一個約束時，會自然而然地很快通過Drools腳本來構思出它的大概邏輯結構，

運算效率

　　運算效率指的是使用DRL評分時，引擎的計算速度，若你深入了解了OptaPlanner引擎的主要作業就知道，它所謂的運算，絕大多數時間都是在進行分數計算，還有小部分是使用各種啟發式演算法對搜尋程序的搜尋方向進行控制，因此，在這程序中，若使用DRL評分方式，Drools規則引擎就是擔起了一個非常大運算責任，但Drools其實還是需要把這些約束轉換成Java位元組碼進行運算的，而且是大量的集合運算，因此，很多情況下，性能上相對直接用Java撰寫的邏輯會更慢的，大家回憶一下各自的系統的性能卡頓點，是不是很多時候都是一些超長超復雜的SQL存盤程序造成的？而其實它卡的原因還不一定是它的邏輯復雜，而是一些邏輯涉到資料集的運算，當我們處理不好這些資料集的關聯查詢時，就會引起很大規模的集合與集合之間的關聯運算(就是各種表、視圖進行的各種Join)，從而成為絕對的性能瓶，

　　Drools在進行約束評分運算時，實際上它就是一個規則推導程序，也有可能涉及很多物件集合的操作與判斷，因此，當資料量大，評分約束相當復雜，或關聯到眾多物件串列時，也有可能引起如SQL查詢一樣的效果，從而大大影響了運算性能，

DRL評分的替代 - ConstraintStream.

　　這種評分方式大概是從7.8x版本開始提出，8.x版本后開始慢慢完善，它充分使用了Java8以后的版本中出現的Stream特性，對大量的場景使用了函式式編程，從而大大地簡化了集合資料處理的難度，也就是說，如果我們在使用Java的Stream功能，能很靈活地撰寫其中的Lambda運算式，ConstraintStream應用起來也是得心應手的，只是因為ConstraintStream是專門針對約束編程的，因此，它提供了一些特定的API供我們使用，我們要理解這引起API的前提，還是要理解評分程序的一些原理與原則，這也是我們學習ConstraintStream最大難點，

　　我目前主要投入的精力都在我們的“三胎” - 【易排通用規劃平臺】上，這個平臺因為基于靈活性與運算性能的考慮，我并沒有使用DRL或ConstraintStream方式，而是直接使用Incremental Java score calculation的方式，這種方式與前兩種對比，最貼切就理解就是單反相機與傻瓜相機的差別吧，正是因為我能在沒有時間壓力的前提下，把我目前掌握到的各種排產約束通過Incremental Java score calculation方式精心實作，從而讓這個平臺在運算大資料量訂單時，性能遠比使用Drools或ConstraintStream高，期待大家可能嘗試該平臺，這個平臺我們將會使用租用方式，以SaaS方式提供一些有規劃要求的場景，例如MES、MOM的計劃模塊，令專門提供這類系統、方案的小伙伴可以開箱即用地擁有一個規劃引擎，當然，當你們遇到一些客戶的個性化需求、約束或優化目標，而在我們平臺上還沒有提供的，也歡大家向我們提出，我們可以通過專案合作的方式定制這些功能，

　　最后，我做了一個關于這個平臺的操作說明，因為這個平臺主要是針對我們業內小伙伴，他們都有相應的軟體技術能力，且目前時間與精力都比較緊張；因此暫時未提供操作界面供大家使用，而是使用WebAPI方式供各位小伙伴集成到自己的系統中，當然要呼叫這些介面，其中一個很重要的步驟是把你們自己的系統中的業務資料，構建成這個介面的資料規范，才能把它傳進來呼叫這些介面，關于這個介面說明視頻，我已經發布在我的公眾號上，當然知呼視頻我也會上傳，后續我會把構建這些資料的各個要點以短視頻方式給大家提供講解，從這些短視頻中，并僅僅可以掌握這個平臺介面的一些約束，還可以學到一些不錯的干貨，因為這兩個月來，為了構建這個介面資料，里面表達業務的各種原理、規則、方案，設計一個推翻一個，經過無數次的迭代，最終才形成現在相對科學合理的結構，

介面說明：

https://mp.weixin.qq.com/s/DFLFNgRbJBP-iSONdeTPEQ

平臺講解說明視頻：

https://mp.weixin.qq.com/s/x46p0en7AQVxRIsioSAmhg

　　本系列文章在公眾號不定時連載，請關注公眾號（搜“讓APS成為可能”）

　　如需了解更多關于OptaPlanner的應用，請發電郵致：12977379@http://qq.com
若有需要可添加本人微信（13631823503）或QQ(12977379)實時溝通，但因本人日常作業繁忙，通過微信,QQ等工具可能無法深入溝通，較復雜的問題，建議以郵件或討論組方式提出，(討論組屬于google郵件串列，國內網路可能較難訪問，需自行解決)

標籤：其他

上一篇：多商戶商城系統功能拆解14講-平臺端會員等級

下一篇：php 獲取縮略圖