OptaPlanner 發展方向與問題
最近一段時間，因為忙於【易排(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áš Petrovický 主導的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 - 車輛路徑規劃】和【線上排程】模組，敬請期待。可以通過以下連結檢視更多該平臺的使用方法。
與平臺相關疑問，可以新增本人微信(13631823503)探討，或關注我們的公眾號【讓APS成為可能】及時接收相關訊息。