汽車零件訂單履行是產銷協同業務模式中重要的一環，過程中出現的異常狀況（簡稱異況）如果不及時告警并后續調整，將會導致最終生產計劃延期。本文提出了一種汽車零件訂單履行狀況實時監控告警的方法，通過實時監控過程異況，對異況根因實時分析，以便及時告警和調整后續節點過程，能最大限度規避生產計劃延期風險。本文針對 Kubernetes 集群節點磁盤 I/O 及網絡負載過大時，出現節點資源使用率和 Flink 任務運行效率降低的問題，提出了一種新的 Kubernetes 資源調度算法，通過實驗論證，最終實現了更好的資源彈性伸縮效果，為營銷業務模式的轉型提供了更為可靠的技術支持。

引言

隨著數字化浪潮席卷全球，汽車產業外部環境日趨復雜嚴峻，傳統生產、制造及服務模式都面臨著前所未有的挑戰。汽車產業從依靠增量發展的階段邁入了存量調整的時代，行業提質增效與轉型升級已成為趨勢。在新形勢下，大數據開發和應用對汽車行業生態鏈，帶來了機遇和挑戰。

為了接近用戶，擁有越來越多的用戶去開拓市場，期望最終去提升產品銷量，產銷一體化成為了汽車營銷的新模式。產銷一體化中，生產制造是重要的組成部分，其中，汽車零件訂單履行又是重中之重。汽車零件從下單到收貨，是一個種類繁多、數目龐大、結構復雜及精細化程度高的物流過程。既要保證汽車零件訂單履行的高效準確，又要控制降低相應成本投入，變成了汽車行業企業和個人日益關注的焦點。

除開業務模式上的變化，整條過程鏈路的數據類型也發生了改變。其中不再全部都是離線數據了，實時數據也越來越多。由此對實時數據的實時計算是必不可少的環節。

本文為了規避因汽車零件訂單履行異常狀況（下文簡稱異況）導致生產計劃延期風險，基于 Flink 流處理引擎設計并實現了汽車零件訂單履行狀況監控系統。圍繞汽車零件訂單履行過程，構建訂單的 One ID 數據模型，實現對訂單生命周期管理、訂單履行異況判定和訂單履行監控告警。通過在 Kubernetes 默認調度器調度的各個階段埋點測試后 ， 優化了主要性能瓶頸的優選階段。提出了一種改進后的 Kubernetes 資源調度算法，經過實驗測試驗證，相較 Kubernetes 默認資源調度算法，其對 Flink任務的運行性能和節點資源使用率有一定的提升。

目前國內外對于汽車零件物流的研究較為豐富。丁則宇將質量管理領域應用較廣的魚骨圖分析法，引入到對汽車零件物流成本控制的影響因素分析中，并針對汽車零件物流成本的控制，提出了對儲存與運輸成本進行控制的策略。鐘慧甄以一家汽車制造廠為研究對象，通過分析其精益供應鏈中汽車零件進口的管理現狀，提出敏捷物流在其進口操作中的應用方案，使精益與敏捷相結合，達到降本增效的目的。周豪等針對傳統采購平臺的局限性，以供應商產能、項目供方唯一性、產品質量、產品按時到貨率和價格折扣為約束，建立了 3 目標的 0 到 1 整數規劃模型。針對該模型，設計了改進的混沌優化算法進行求解，有效解決了傳統多目標優化過程中參數難以選擇的問題，避免了人為干預。陳宇丹在考慮供應數量不確定性以及新能源系列零件采購特征的基礎上，構建了新能源系列零件訂單分配的多目標模型，并運用模糊數和構建隸屬度函數從解集中豐富的新能源系列零件訂單的分配方案選出最符合經營目標的分配方案。

目前 Kubernetes 的調度還存在有待提升的方面。Dong Li等提出了一種平衡磁盤 I/O 優先級的動態算法來改善節點之間的磁盤 I/O 平衡，和一種平衡 CPU 和磁盤 I/O 優先級的動態調度算法來解決單個節點上 CPU 和磁盤 I/O 負載不平衡。Gengsheng Zheng等提出了一種基于 Docker 集群的自定義 Kubernetes 調度器的調度策略，其可幫助節省更多的系統調度資源，提高集群調度的公平性和效率。Zhiheng Zhong等提出了一種容器化任務協同定位調度器，采用彈性任務協同定位策略來提高資源利用率，支持動態任務重新調度，有效防止頻繁的任務逐出導致嚴重的 QoS 降低。Fabiana Rossi等提出了一種依賴于 Kubernetes 并通過自適應和網絡感知放置功能對其進行擴展的編排工具，該工具考慮了計算資源之間不可忽略的網絡延遲，以滿足對延遲敏感的應用程序的服務質量要求。

動機

汽車零件物流是汽車零件供應商的運輸供應物流，也是指上游供應商向整車廠提供汽車零件、生產材料和輔料到整車廠的倉庫入口的流程。

汽車零件物流具備幾個特點：

1）準時性。一般來說，汽車裝配線的生產節拍是20 ～ 40 輛 /h，每種車型的裝配零件是 3 000 多種。生產線旁的物流位置有限，需要連續不斷地向生產線準時供貨，但汽車零件物流過程會面臨零件數量大和長距離運輸等問題，所以供貨的準時性決定了生產的準時性。

2）準確性。汽車裝配的準確性是整車裝配質量最基本的保證。在一條裝配線上，混流裝配 2 個或 2 個以上平臺、十幾種配置的汽車，上萬種零件準確地送到消耗點，是物流配送的難點，它需要配送商對汽車生產有深刻的了解和豐富的經驗。

3）質量保證性。汽車零件的質量是汽車質量的基本保證。零件在運輸、搬運、更換包裝容器和倉儲的物流活動中，必須追求物流服務的質量。

目前汽車零件物流運輸方式可分為 2 種，一種是直接運輸，當供應商單次發貨量比較大，能夠形成一定的規模數量時，采用直接在供應商處將零件裝載完畢后再直接送到主機廠的運輸模式。這種運輸方式的特點是能設定更便宜的費用，沒有因重新裝載而造成的損害，運輸時間比較短。但會出現“高裝載低頻次”或“低裝載高頻次”的情況，從而導致倉儲成本或運輸成本增加。

另一種是混載運輸，如圖 1 所示，混載運輸在路徑聯運上的表現形式是牛奶運輸方式或設立中轉倉庫的形式，在裝載形式上的表現是內外制件混載、不同材質的混載?；燧d運輸方式與直接運輸方式相比，不足之處是運輸費用較高，由于運輸地點較多，需要的時間比較長，其優點是能實行小量、多廠家運輸，能實現中轉倉庫等干線的長距離運送。

汽車零件訂單履行精細化運營

3.1 數據采集接入

實際工作生產中，汽車零件訂單需要和企業內部諸多生產制造相關系統產生關聯關系，包括 MES（制造執行系統）、WMS（倉庫管理系統）和 QMS（質量管理系統）等。這些生產制造系統的數據總量大、數據變動頻次高及數據變動量大，平均日均數據變動總量能達到 TB級。這些生產制造系統的數據都存儲在傳統 Oracle 關系型數據庫中，如果直接使用 Oracle 數據庫去做數據關聯，往往會因數據庫性能瓶頸而出現“慢”和“失敗”的情況。因此，在數據采集過程中，需要一個數據緩沖層，用于先把變動數據都存儲下來。

Kafka 是一種高吞吐量的分布式發布訂閱消息中間件，它可以處理消費所有變動的實時數據。Kafka 支持多主題多分區，能為多生產者生產數據，多消費者消費數據，具備高吞吐低延時、可拓展和持久可靠等優勢，提升了并行處理大規模變動數據的能力。

由于數據源是存放在 Oracle 10g 中，和已有的 Kafka版本不兼容，所以 Oracle 10g 的源數據需要使用 OGG（Oracle GoldenGate）實時同步至 Oracle 11g 數據倉庫中，然后 Oracle 11g 數據倉庫中的數據再使用 OGG for Kafka實時同步至 Kafka 相應的 Topic 中，以供后續下游去消費，如圖 2 所示。

3.2 數據實時處理

將各業務系統中的變動數據實時采集到 Kafka 后，下游將通過 Flink 實時計算引擎去處理及關聯，最終得到以 One ID 為標準的結果數據。

One ID 把不同時期孤立建設的系統，用統一的 ID 串聯起來，就可以更全面、更完整地了解數據本身，能夠更加精準地評價數據的價值，為精細化運營夯實數據基礎。

TiDB 是一款聯機事務處理和聯機分析處理的融合型數據庫產品，實現了一鍵水平伸縮、強一致性的多副本數據安全、分布式事務和實時 OLAP 等重要特性。同時兼容 MySQL 協議和生態，遷移便捷，運維成本極低。

如圖 3 所示，在實際情況中，有上海、南京、鄭州和寧德 4 個工廠的生產制造數據，所以從 Oracle 數倉同步到 Kafka 有 4 份 Topic。通過 Flink KafkaConsumer 去實時處理新增及變動數據，將來自 4 個生產基地的數據，以主鍵車的 Vin 碼（車輛識別代碼）關聯起來，最終得到 One ID 寬表結果數據存放在 TiDB 中，并分組過濾出不同品牌的數據，供下游使用。

3.3 汽車零件訂單履行異況處理

（1）訂單異況責任判定規則 汽車零件訂單履行鏈路過程主要包含訂單確認、供應商備貨、自運發貨、MR 提貨、TDS 入廠和道口收貨 6 個主要流程節點。

整個鏈路過程中，將會在每個節點進行到達時間、離開時間、零件數量和型號及零件質量狀況的確認，這些確認情況都將會第一時間更新到業務系統數據中。實際汽車零件物流運輸方式是混載運輸，由于運輸地點較多、時間長，訂單異況的責任判定是必要的。

訂單異況的責任主要分為時間計劃延誤、零件裝配錯誤和零件破損 3 類。對于時間計劃延誤責任，如果當前節點到達時間晚于計劃應到時間，將會追究上一節點承擔方責任。如果當前節點離開時間晚于計劃離開時間，將會追究當前節點承擔方責任。對于零件裝配錯誤和零件破損，如果當前節點收貨前檢查發現零件裝配錯誤或零件破損，將會追究上一節點承擔方責任。以上 3 種責任如果有連鎖連帶責任情況，都將會以首次發生責任的承擔方判定為主。

汽車主機廠會和各物流承運商簽訂的合同中詳細界定責任范圍。物流運輸途中發生異常狀況都將由對應環節的物流承運商負責，零件到了中轉節點之后將由專人驗收和簽署回單，專門人員會將相關零件信息錄入更新至業務系統中。

（2）訂單異況根因分析 1）異況知識圖譜。零件訂單在履行過程出現異況時，相關節點人員會將異況和原因錄入到系統中，但由于人員文本描述情況不同，無法做到快速明確異況根因，此時需要建立相關知識圖譜。

實體抽取要從文本數據集中自動識別出命名實體。實體抽取的質量對后續的知識獲取效率和質量影響極大，是信息抽取中最為基礎和關鍵的部分。初始業務系統數據庫中節點人員錄入的描述信息，首先會使用 CRF 對實體邊界進行識別，如圖 4 所示。

采用自適應感知機算法實現對實體自動分類，最終可以對圖 4 所示的描述信息識別出實體并進行分類，如圖 5 所示。

文本語料經過實體抽取，得到的是一系列離散的命名實體，為了得到語義信息，還需要使用高斯核函數提取出實體之間的關聯關系，才能夠形成網狀的知識結構。如圖 6 所示。

2）異況根因查詢及更新。對建立好的異況知識圖譜，會以異況、關系和異況根因三元組形式存儲到關系型數據庫中。

其中通過訂單編號查詢異況跟因，如果異況知識圖譜有數據新增、更新和刪除，將通過增量的方式進行人工干預。

3）異況告警。零件訂單狀態監控系統會將出現的異況第一時間告警至涉及人員，并基于異況根因分析情況進行后續的調整，力爭不會對主機廠最終的生產計劃造成影響。

零件訂單履行異況產生的供貨延期主要分為 3 類。第一類是一般供貨延期，是指影響到正常的庫存量，但未對主機廠造成實際影響的供貨延期。第二類是重要供貨延期，是指影響到主機廠正常的生產計劃，使生產計劃延期完成或需調整生產計劃的供貨延期，其分類見表 1。第三類是嚴重供貨延期，是指影響到主機廠正常生產計劃的完成，同時影響到主機廠銷售計劃的供貨延期。

改進的資源調度算法

4.1 算法設計

通過在本地 Kubernetes 集群加入性能測試集，對Kubernetes 默認調度器調度的各個階段進行埋點測試。最終定位到主要的瓶頸是在優選階段。

假定集群中 Pod 總數為 Np，平均每個 Pod 的AffinityTerm 數為 3，經過預選后的節點數為 Nn，節點的label 個數為 6，所有 Pod 中，與待調度 Pod 匹配的同組Pod 數為 Nsp，則優化后的優選算法復雜度為

為了進一步更加直觀的分析優化效果，假定集群總節點數為 N，每個節點上平均有 30 個 Pod，進入優選階段的節點比例為 a，則可以得到：

若假定 Nsp 及 a 為常數，則隨著集群規模 N 增大，計算復雜度的優化倍數很快會收斂。

4.2 算法流程

Kubernetes 默認調度器 kube-scheduler 在優選時會調用自定義擴展程序進行給節點打分。優化后的優選算法執行流程如下：

1）算法 1。根據每個節點上存在當前 Pod 對象類型的數量，計算節點分數，執行流程如圖 7 所示。

2）算法 2。根據每個節點上資源負載情況，計算節點的最終分數，執行流程如圖 8 所示。

實驗對比與分析

5.1 訂單履行異況知識圖譜測評

使用 20 000 條異況描述訓練語料進行實體和關系抽取，構建異況知識圖譜模型。以準確率、召回率和 F 值3 個指標來評估異況知識圖譜模型的實際效果。驗證結果見表 2。

5.2 訂單履行狀態監控系統測評

零件訂單履行狀態監控系統通過虛擬機本地部署，實驗初始環境見表 3。選取對比了 2020 年 10—12 月零件訂單履行情況，有效降低了異況的發生，減少了對生產計劃的影響，具體情況見表 4。

5.3 Flink 資源調度改進算法測評

采用 Flink 1.12 和 Kubernetes 1.15 版本，Kubernetes通過虛擬機本地部署，集群初始共有 2 個 master 和 4 個worker 共 6 個節點，配置見表 5。

在數據量增大時，Flink 測試任務的計算結果時延、數據堆積、集群節點 CPU 使用率和內存使用率對比結果如圖 9、圖 10、圖 11 和圖 12 所示。從實驗結果上來看，通過自定義優選調度算法，對任務運行性能和集群資源使用率上均有一定程度的提升，驗證了本文方法的有效性。

需要說明的是，上述對比分析結果在程序中的實際表現會受到其他很多因素的影響導致偏差，但仍可以作為參考。

總結及展望

本文提出了一種實時監控汽車零件訂單履行異常狀況的方法，通過將業務系統數據實時同步至消息隊列 Kafka中，并由 Flink 消費和實時計算，連接形成 One ID 標準的寬表結果數據，存放在 TiDB 中。對寬表結果數據中異況描述文本進行實體和關系的抽取，構建出零件訂單履行異況知識圖譜，最終基于異況知識圖譜，實時分類得到異況根因，可以提前告警并及時規避生產計劃的延期風險。實驗表明，零件訂單履行異況知識圖譜在實際業務數據測試中，相關模型評價指標表現良好，同比去年同期未應用零件訂單履行狀況監控系統情況，由于零件訂單履行異況而造成生產計劃延期事件的發生次數和比例有所降低。

通過對Kubernetes默認調度器調度各階段埋點測試，找到了需要優化的性能瓶頸?；?Kubernetes 集群節點CPU、內存、磁盤 I/O 和網絡負載情況，并考慮了節點上當前 pod 對象類型的數量，提出了一種新的優選階段調度算法，最后通過實驗對比分析，驗證了算法的有效性。