OptaPlanner逐步學習(0) : 基本概念 - OptaPlanner,規劃問題, 約束,方案

  之前的文章中,分別從APS,排產到規劃引擎敘述了一些理論基礎;並介紹了一些OptaPlanner大概的情況;並一步步將Optaplanner的示例運行起來,將示例源碼導進Eclipse分析了一下它的Hello world入門示例,從本篇開始,我們將分步學習它的一些概念及用法。 

什麼是OptaPlanner

  其實這個名稱是作者將這個引擎貢獻給了Jboss社區後,才使用的名,之前叫做Drools planner。沒錯,它就是結合Drools(一個開源規則引擎)一起應用的(也可以單獨使用),Drools在這裏的作用主要是用來作編寫計分腳本,事實上完全可以拋開Drools,直接使用OptaPlanner自己的API,通過Java代碼自己來計分,但這個難度就大得多。詳細情況講到相應的章節再細說。

  名稱的前綴應該是Optimize的詞根,或取近音吧,因爲OptaPlanner其實就是一個對待規劃的方案組合進行優化的引擎。好了,關於它的名稱就不花費太多的口水去深究,我們看看官方是怎麼定義OptaPlanner的。"OptaPlanner is a constraint solver. It optimizes business resource planning use cases, such as Vehicle Routing, Employee Rostering, Cloud Optimization, Task Assignment, Job Scheduling, Bin Packing and many more. " - Optaplanner 是一個約束解決器,它可以優化業務資源,規劃各種案例,例如車間調度,職員排班,雲優化,任務分配,工作排程,裝箱等相關的問題,例如下圖。

  

  而我對OptaPlanner的理解,它是一個Planning Engine - 規劃引擎,針對各行各業的業務需求,開發人員需要將一些業務規則翻譯成約束,並對業務場景中的實體進行抽象建模,規劃引擎根據上述約束和模型對象進行規劃,找出一個相對最優化的方案出來返回給用戶。其實如果需要規劃的業務對象不多(種類和數量都不多),規則不太複雜,人類是可以通過自己的經驗、推算和規則運行,得到一個可行方案的,甚至當問題規模足夠小的時候,是可以找到一個最優方案的。關於規劃問題,大家可以參考這個系統文章中的一篇入門介紹《OptaPlanner - 入門介紹》,裏面講到,規劃問題其實就是數學上的NP問題或NPC問題,目前數據世界對於這種問題,是沒有可用算法直接實現的,當問題足夠大的時候,只能夠通過一些尋優算法(例如爬山算法,模擬退火及遺傳算法等)提高找到問題相對優解的機率。而OptaPlanner正是一個集成了這類算法,實現快速尋找相對最優方案的引擎。它是一個輕量級的,可嵌入的規劃引擎,也就是說你可以在自己的程序中通過Jar包直接和相關的配置項來直接使用OptaPalnner. 當然,當你需要一個獨立的,具有良好擴展性的規劃服務組件時,可以直接使用OptaPlanner建立自己的規劃服務器,通過Spring等框架,對外提供規劃服務。

  OptaPlanner是基於Apache Software License.協議的,你可以直接使用它作爲商業用途。並且它是使用純Java編寫的,最低功能要求下,只需安裝一個JVM即可以使用OptaPlanner了。並且它所有的包都可以從Maven中央庫中獲得,即只需要建立一個Maven項目,簡單配置好依賴項,就可以開始基於OptaPlanner的開發了。

下面,就開始對OptaPlanner中概念進行逐一講解.

什麼是規劃問題(Planning Problem)

規劃問題是 - 基於有限資源,及指定約束條件下達到優化目標(包括資源、排程安排等優化).,例如:

  • 最大化利潤
  • 最小化對生態環境的影響
  • 提高員工及客戶的滿意度
  • ........

要實現這些目標,需要以下條件:

  • 人員
  • 時間
  • 預算(資金)
  • 物理資產(例如機臺、汽車,電腦,建築等等)

下圖是Optaplanner官網對規劃問題的定義:

  

  上面是對官網的一些翻譯。通俗地講,規劃問題就是:

1. 存在一堆對象,例如:任務、人員、資源等,以後稱作規劃實體 - 官方稱planning entity;

2. 還存在一些條件規則,例如:任務最遲需要什麼時候完成,人員每天最多隻能上班8小時,在指定的時間段內資源是有限的。以後稱約束 - 官方稱Constraint

3. 根據上述第2點的條件,對第1點所述的規劃實體進行資源分配和時間安排,例如,哪個任務應該安排在哪個機臺上,在什麼時候開始作業;哪個人員安排在哪個車間的哪個班次;哪種資源(例如:機臺、原料等)需要確保在哪個時間送到哪個車間等。

  上述第3點所做的工作就是一個規劃的過程,也就是引擎會根據約束的限制和規劃實體的特性,對這些規劃實體進行時間或/和空間上的規劃;這個就是規劃過程。而我們面對的這些規劃實體和這些約束的結合體,就稱作規劃問題。例如:排定下個學期每個年級的課程表,令每個課程的老師不會出現同一時候分配到不同的班級上課。現有一堆外賣,規劃好各個騎手的取餐、送餐路線,令每個騎手都以儘量小的路程和時間成本送最多的單。這些都可以被視作規劃問題。

規劃實體與規劃變量(Planning Entity & Planning Variable)

  我們知道,規劃問題,就是對一些規劃實體進規劃預計分配。例如編造排班表,是一個規劃問題,那麼抽象出來,一個工人就是一個規劃實體(Planning Entity)了,它是被規劃的對象。而工人在指定的時間在哪個車間上班,就是這個規劃實體的規劃變量(Planning vaiable)了。所以,其實解決這個規劃問題的過程,就是針對每一個規劃實體,根據約束及每個規劃實體的情況,來給它的規劃變量設置適當的值,令到所有規劃實體的所有規劃變量的組合達到整體最優。即是設定每個工人(規劃實體),在哪個時間,去哪個車間上班(上班時間和車間就是規劃變量)。

問題事實(Problem Fact)

  問題事實是相對規則實體而言的,它也是一個業務實體,與規劃實體不同的是,它只反映出業務情況,而在規劃的過程中,不會被規劃引擎進行修改。也就是說,問題事實只是用於提供資料,輔助規劃引擎進行規劃運算的。在整個規劃過程,問題事實是隻讀的。例如規則班次計劃的時間,其中的班次是在開始規則之前已經確定的,所以“班次”這個業務實體只會在規劃過程中,提供每個班次具體的時間等信息,而不會改變的。那麼“班次”這個業務實體,就是一個問題事實。

約束(硬約束與軟約束)

  上而我們把業務規則定義爲約束,其實目前針對排程方面的規劃問題,主要是通過約束進行評分機制的尋優方法。約束就是根據業務規則抽象出來,針對規劃變量,在求解規劃問題時候的一種限制,或懲罰機制。也就是說,約束是用來制約引擎對規劃變量的賦值行爲的。例如一個人不可能有超過24個小時的可用時間。

  硬約束:硬約束是指那些不能違反的約束,違反了就會出現不符合常理,即業務可能出現絕不允許的情況出現。例如上面提高,一個人不可能有超過24小時的可用時間(常理);機臺運行過程中,機修工不能進行維修工作(涉及安全生產問題,法律及業務有硬性要求。)。因此,硬約束可以被人視爲是用於對規則行爲進行定義的。

  軟約束:軟約束是相對硬約束而言的,它是可違反的。設立軟約束之目的並不是不允許它違反,而是定量地制約規劃結果(結果,即是下面講到的"解"或者"方案")的發展方向,起到對規劃結果的偏向作用,即讓規則結果儘量向指定的一個方向偏移。也就是說在滿足了硬約束的前提下,再對軟約束進行判斷,如果軟約束能不違反就最好,要是必須違反,違反得越少,所得的方案就越好。例如成本高低就是一種軟約束,生產運營中不可能不產生成本,那麼如果成本越低,那麼方案肯定越好,當然是在滿足了硬約束的前提下。

 

規劃問題其實是NP問題或NP-Hard問題

  其實在《Optaplanner - 入門介紹》中已經有講解過關於NP或NP-Hard(那講到NPC問題),大家可以去參考一下那篇文章。這時概括地重述一下,NP或NP-Hard問題是問題以下條件的:

  • 對於一個給定的規劃的結果(官網中稱作solution, 即是解),很容易在合理的時間內對其進行驗證是否可行。例如:課程表編排得正不正確,可以根據約束來覈對一下就可以確定了,例如有沒有出現同一個時間內,一個老師被分配到不同的班級上課。
  • 不存在一個可確定的方法,在合理的時間內找到一個最優解(這裏指的是絕對最優解)。這個也不難理解,對於這種沒有任何快捷方法找最優解的規劃問題,我們唯一的辦法就是把所有不同的組合情況全部排列出來,一個一個比較(即逐一枚舉),那必然是可以找到最優解的。但是,因爲這種方法其實是一種暴力窮舉法,當問題非常複雜、且需要規劃的實體數量非常多時,它的時間複雜度是隨着組合情況的增加,呈指數式上升的,暴力窮舉的方法是不可取的。

規劃問題存在巨量搜索空間

  搜索空間:因爲目前針對規劃問題,只能通過搜索的方式去尋找相對最優解,因爲相對一些直接通過算法操作得到的辦法而言,規劃問題只能將它的解一個一個地對比,逐步收斂逼近的辦法來得到相對最優解。所以,你可以認爲規劃問題的相對最優解是搜索出來的,而且每一步搜索都需要對約束進行運算;從所有經歷過的解中,找到相對最優一個。所以規劃問題存在一個搜索空間的問題,即有多少種可能的解,就表示搜索空間有多大。例如將3個任務分配到兩個機臺上,存在多少種可能?大家可以自己去算,其實就是排列組合問題。

  而對實際問題時,稍複雜的約束,稍多一點的規劃實體,最後得出的可能解的數量都是非常巨大的,很多問題其搜索空間輕易就是一個天文數字。所以,如果對於所有規則問題,都是使用這些暴力枚舉的辦法,以現有世界上的計算機的算力,很多問題是沒辦法找到最優解的。

  規劃問題的規模,即是規劃實體及每個實體的規劃變量的組合,例如時間、空間,及影響因素,及這些因素的所有情況組合。例如,如果上述所有實體,規劃的變量和所有因素,展開後的數量是M,而一個解是對其中的N個變量進行規劃,那麼有多少個解呢?其實就是M到N的排列P(M->N).當遇到實際問題的,這些組合的數量就是天文數字了。

可能解,可行解,相對最優解與絕對最優解

  在規則問題中,需要清楚解的概念,在OptaPlanner裏稱作solution, 即方案。在本系列文章中,解與方案是相同的意義,請注意。本猿只是根據中文表達的習慣,在不同的場合以最順口的方式,視情況確定到底應用用“解”,還是“方案”來表述。

在接下來的一系列文章中,我在講解這些方案的過程中,會用到以下概念:

  可能解:一個規劃問題的任意一個解都稱爲可能解,也就是所有規則實體的所有規則變量,任意一個組合,都稱作一個可能解。例如分配工人A,在1月20日晚班,到1號車間;分配工人A在1月20日晚班到2號車間;分別是兩個不同的可能解,儘管它們的差別只是分配到不同的車間.而每個工人的每個班次的工作車間,正好是規劃變量。所以任意一個規劃變量的不同,都會產生不同的可能解。現在知道爲什麼規劃問題存在巨量搜索空間了吧?

  可行解:可行解就是那些完全符合硬約束的解。即若存在一個解,它對任何一個硬約束都是符合的,則稱這個解爲可行解。可行解是可能解的一個子集。可行解是可驗證的,只要根據目前所有的硬約束,對解中的每一個規劃實體中的每個規劃變量,逐一覈對,看是否符合所有硬約束,如果符合,那就表示這個解是可行解。

  相對最優解:上面已經提,規劃問題的搜索空間非常巨量,大多數情況下是不可能計算並比較所有解的值,再取得最佳方案(這個解就是絕對最優解)的。在固定的時間內,Optaplanner引擎幫我們找到的最優方案,就是稱作相對最優解了。大家來思考一下,相對最優解必然是可行解嗎?

  絕對最優解:同樣的上面提到,就是所有可能解中最優的那個解,目前是沒有直接確定的算法,通過運算在合理的時間內去找到一個問題的絕對最優解的,所以要得到絕對最優解,只有一個辦法,就是將所有可能解都遍歷一次才能找到。當問題規模不算大的時候,以目前的CPU速度還是能實現的。但如果問題稍複雜一點,規劃實體和規劃變量稍多一點,那麼可能解的數量就是一個天文數字了,這種情況下是沒辦法完全遍歷的。所以,在我們現實中,我們是無法得到絕對最優解的。其實更貼切地說,我們所得到的相對最優解,我們不知道它是不是絕對最優解。因爲現在數學上還沒有辦法(除了遍歷)證明一個相對最優解是否絕對最優。

 

  本篇先介紹一下上述兩個概念,下一篇將我們再具體介紹其它概念。

原創不易,如果覺得文章對你有幫助,歡迎點贊、評論。文章有疏漏之處,歡迎批評指正。


本系列文章在公衆號不定時連載,請關注公衆號(讓APS成爲可能)及時接收,二維碼:


如需瞭解更多關於OptaPlanner的應用,請發電郵致:[email protected]
或到討論組發表你的意見:https://groups.google.com/forum/#!forum/optaplanner-cn
若有需要可添加本人微信(13631823503)或QQ(12977379)實時溝通,但因本人日常工作繁忙,通過微信,QQ等工具可能無法深入溝通,較複雜的問題,建議以郵件或討論組方式提出。(討論組屬於google郵件列表,國內網絡可能較難訪問,需自行解決)

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章