? 最近一段時間，因為忙于【易排(EasyPlan)規劃平臺】的設計與開發作業，平臺的一些功能設計，需要對OptaPlanner的各種特性作更深入的研究與應用，慢慢發現，OptaPlanner進入8.X版本之后，變化還是挺大的，對于我個人的專案、平臺及咨詢作業，這些變化中，大部分還是幫助很大的，但也發現一些不太合理的地方，這兩天終于完成了平臺的“規劃評分分析功能”，就擠點時間出來，記錄一下OptaPlanner 8.X的這些變化吧，
以下是我應用OptaPlanner程序中歸納的一些關于該軟體的發展方向，及此程序中遇到的一些問題，
實時規劃介面優化
實時規劃是OptaPlanner的一重大特有特性，目前在其它求解器還沒發現類似的功能，就是考慮到當求解一個問題的時間過長時(例如資料量大、約束復雜)有可能在求解的程序中，資料已經發生變化，此時，實時規劃就可以在未完成整份資料的完全求解，即可通過實時規劃的API對資料進行更新，OptaPlanner會在已完成了部分求解的基礎上，將變更納入考慮，而無需停止整個規劃程序，重新跑一次規劃，實時規劃的另一個經典應用場景，就是在VRP(車輛路徑規劃)程序中的實進車輛調度功能，即車輛按原計劃的路線行駛，當遇到路況不佳時，司機可以將路況反饋回服務端，以OptaPlanner為作引擎的服務端會馬上作出反饋，重新規劃一條新的路線給司機，并對后續的訪問節點進行適當調配，其實這一程序同樣適用于車間的調度作業，我們的平臺將會添加這一功能 - 車間實時作業調度模塊，
那么實時規劃功能，在OptaPlanner的8.X版本中有哪些改善呢？其實，我們在8.X以前一直都已經有實時規劃功能，但那些版本我們需要實作實時規劃，OptaPlanner提供的介面，還是相對比較零碎且繁復的，例如，當我需要增加一個資料時，需要先判斷添加這個資料是一個Planning Entity，還是一個普通的Problem Fact，不同的情況需要使用不同的API，添加與洗掉兩種操作也使用不同的API區分，因此，要實作實時規劃，需要考慮：你是需要從規劃空間中增加物件，還是洗掉物件；你增加/洗掉的是什么型別的物件；從而采用不同API，撰寫不同的處理邏輯，
而到了8.X之后，將上述情況都整合成一個介面 - ProblemChange. 即無論你的操作是增加還是洗掉物件，無論你操作的物件無論是Planning Entity還是Problem Fact；對于整個規劃問題來說，都是對規劃問題的修改，因此，這些操作都抽象成一個介面 - ProblemChange，只要我們新建一個類實作ProblemChanged這個介面即可，當然，具體在這個介面的實作類中，需要如何實作新增、洗掉邏輯，還是需要我們自己去撰寫的，因為這屬于業務邏輯的范疇；但也僅僅涉及這些物件被增刪后，規劃空間中剩余物件的一些業務性要求而已，而評分之類由引擎自行處理的邏輯則不需我們來處理，例如，在VRP場景中，如果有一個節點臨時取消了，那么我們可以通過實時規劃把這個節點從一條車輛行駛路線中洗掉，但是，因為一條路線是由各個節點首尾相接構成的，因此，如果你刪掉這條路線上的一個節點，這條路線就被截斷了，為了保持路線的完整性，你需要把被洗掉節點的前后兩個節點連接起來，從而保證路線的完整（這也是OptaPlanner中Chain的一個原則性要求），這就是洗掉一個節點需要處理的唯一一個需要人工處理的業務邏輯，當然各種場景需要處理的邏輯不同，例如添加一個節點，則不需要任何處理，因為一個新的物件出現，對OptaPlanner來說，相當于有一個物件還未被規劃處理而已，它會自動把這個新的物件納入考慮，
上述描述的實作業務程序，也都在ProblemChange這個介面內實作即可，而且整個介面需要實作的方法也只有doChangeg一個方法，構造好一個ProblemChange物件，直接將這個物件傳送給SovlerManager物件的addProblemChange方法即可，相對于之前版本的介面簡單明了，
評分方式，以ConstraintStream取代Drools
8.X之后，由該團隊成員 Luká? Petrovicky 主導的ConstraintStream功能得到長足發展，事實上ConstraintStream早在7.X版本就已出現，但當時提供的API還是比較少，未能覆寫最常用的Drools表達的所有功能，到了8.X之后，相長的時間與版本里，都在完善ConstraintStream功能，ConstraintStream我們通常稱之為“約束流”，熟悉Java8以上版stream特性的小伙伴應該知道，通過stream功能，可以實作類似SQL腳本一樣的復雜查詢，規劃約束的本質也是對資料集的過濾、條件判斷和評分設定(這就是所謂運籌優化演算法的核心之一)，
目前OptaPlanner關于分數計算(也即評分)有以下方法：
- Easy Java score calculation - 相對較容易實作但因為沒有增量評分，性能稍差
- Drools score calculation- 基于Drools引擎，直接使用Drools腳本撰寫約束，性能一般表達方法豐富，但需要學習Drools，在8.X版本已被標識為“棄用”，即不再更新，預計在9.X將會取消該種計分方法，
- Constraint streams score calculation- 新的約束流評分，實作起來較精簡，但需要熟悉掌握各個函式式編程API，后臺還是基于Drools引擎）
- Incremental Java score calculation- 性能最強、靈活性最高，但官方不推薦，原因是實作難度較大)
Drools評分是目前最為成熟易用的一種評分方法，規劃模型里的第一個約束，對應于Drools腳本中的每一個規則(腳本里稱為Rule),一個規則體由LHS和RHS構成，其中LHS根據約束的要求實作規則邏輯，當LHS的所有條件都滿足了，就會執行RHS中的內容，因此，RHS主要是實作評分功能，即具體是要求引擎對哪個型別、哪個層次作出多少分值的懲罰或獎勵，這種方法具有非常豐富的邏輯表達方式，豐富的Drools腳本表達能力也可以充分利用，當然，要掌握Drools腳本也需要有一定的學習程序，
根據OptaPlanner官方發布的計劃，Drools評分方式將會在下一個主版本(通常認為是9.X版)將會取消相關介面，屆時將無法使用Drools腳本實作評分約束，取而代之的是ConstraintStream評分方式，而在我決定開發易排(EasyPlan)通用規劃平臺的時候，考慮到以后的兼容性及性能要求，我目前使用的是Incremental Java Score calculation的方式實作相關約束，這種方法雖然實作起來難度最高，但其性能與靈活性也是最好的，考驗的是開發人員對約束的實作能力，同時需要實作方案的分數分析，若使用Drools或ConstraintStream這兩個主分方式，完成規劃后，一個方案的分布也已經自動生成的，而使用Incremental Java Score calculation則需要實作額外的介面，才能得到主分的分布資訊，但我認為若作為一個定制專案，這些額外的付出需要根據實際情況考慮，而我們實作的是一個性能、靈活性要求都更高的產品，因此，花更多的時間精力來實作Incremental Java Score calculation是完全有必要的，
關于ConstraintStream的底層實作基礎，在一篇OptaPlanner官方發布，建議人們將Drools約束移植到ConstraintStream方式的文章(見以下鏈接)里提到，ConstraintStream其底層也是基于Drools引擎的，只是提供一套對Java開發人員更為熟悉的函式式編程的ConstraintStream API，以方便開發人員撰寫約束，見以下截圖：
截圖出處： OptaPlanner deprecates score DRL
部分未成熟的功能
SolverManager的Problem ID（即規劃資料集的ID）問題仍有Bug
在我們的【易排(EasyPlan)通用智能規劃平臺】的開發程序中， 我們使用了SolverManager來實作多個資料集并行規劃，平臺的API呼叫后可即時回傳，其中就用到SolverManager的Problem ID來識別規劃空間中不同資料集，從而查詢各個資料集的狀態和規劃結果，但在開發程序中，我們發現，當一個資料集規劃運算例外時，我們重新把這個資料集再次提交到引擎，且使用的資料集ID（Problem ID）與前一個資料集ID一樣，會出現一個例外，提示該ID的資料集已經處理，很明顯這是一個錯誤，因此我已在他們社區的JIRA里創建了一個issue，希望能早日修復此問題，
也正因為這個問題，我在我們的平臺關于規劃ID的機制作出相應的變更，以避開OptaPlanner這個問題，若看過平臺最早一個版本的說明檔案的小伙伴應該有印象，每個資料集的規劃ID是由我們在生成資料集(即那個json)時，自己去維護其中的id欄位的，這也能很好地讓呼叫方較容易地控制各個資料集的ID，但若程序中出現這個例外，當我們重新提交一個資料集給平臺重新跑規劃運算時，若使用了與這前出現例外的資料集一樣的ID，就會回傳一個例外，提示：該問題(id為1）已在處理，因此，那個版本我們提供了一個介面，用于查詢一個ID是否已經存在規劃資料集，還有一個介面用于生一個新的ID，但這種設計其實相對大家的前端呼叫程式的設計是比較繁復的，因此，但我們必須在OptaPlanner官方修復該問題前，避免該問題出現，同時也提高呼叫端的易用程度，因此，我們將介面修改為，提交資料集到平臺做規劃運算時，資料集的ID并不作準，而是平臺自己根據當前的規劃空間情況，生成一個新的ID，以該ID為準，用于后續操作使用，
例如：一個資料集在客戶端（例如你們自己的MES系統）生成時，其ID是1，但通過介面提交到平臺時，平臺可能回傳的是2(呼叫反饋json中的PID欄位值)，那么，此次規劃的ID是2，后續需要查詢狀態、獲取結果，以及以后需要實時規劃時，更新一個規劃資料集，使用的ID都需要使用2，而不是使用你們自己生成的1. 希望官方能早日修復些問題，
前一個資料集出現例外時，后續再使用相同的ID，就會出現這樣的例外
Geoffrey De Smet建議本人創建的issue
新的鏈狀態設計仍有部分特性未實作
另外一個問題是，在8.x的其中一個版本（具體哪個版本沒細查了），我們之前常用的時間鏈(Chained Through Time)模式，提供了一種新的方式來實作，并引入了 @IndexShadowVariable 和 @PlanningListVariable 兩個新的標注, 其目標是簡化時間鏈模式，令鏈實作起來更直觀，使用過時間鏈模型的小伙伴應該還記得，該模式需要定義通過繼承父類或實作介面的方式，來定義一條鏈上的錨和節點的關系，實作起來比較繞，可只要我們一旦掌握了要領，實作起來還是比較靈活的， OptaPlanner為了簡單此模式，引入了串列規劃變理(即一個規劃變更可以是一個串列)，但事實上這個功能尚未完全成熟，還是有一特列情況無法實作的，而在官方的示例中，我們可以看到，一些功能未能實作而需要做些取舍，
綜上，大家在使用最新版本OptaPlanner的時候，有些功能還需要根據具體情況使用相應的方法，有一些新加上去的功能，看上去實作起來會更簡潔，但其實它不一定成熟的，需要看情況使用，例如，因為上述新的鏈狀功能的實作還沒成熟，TaskAssigning示例的Consume功能在新的版本中被屏蔽，還沒辦法演示員工對任務完成情況的案例，如下圖，
以上是本人對于OptaPlanner新版本總結出來的一些問題，分享給大家，希望大家在使用時能盡可能避坑，
同時也邀請大家使用我們的【易排(EasyPlan)通用智能規劃平臺】，它基于OptaPlanner對APS的一些常用規劃邏輯進行封裝，大家只需要管理、維護好自己系統(使用MES、MOM、ERP中的計劃模塊)中的工單資料，即可快速地實作一個APS模塊，后續我們還會添加【VRP - 車輛路徑規劃】和【在線調度】模塊，敬請期待，可以通過以下鏈接查看更多該平臺的使用方法，
易排(EasyPlan)通用智能規劃平臺 Q&A
與平臺相關疑問，可以添加本人微信(13631823503)探討，或關注我們的公眾號【讓APS成為可能】及時接收相關訊息，
一個IT老農，先盡力擔好當兒子、丈夫和父親的責任，然后做點有趣的事，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/499862.html
標籤：其他
上一篇：國內外知名原始碼商城系統盤點