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

引言

隨著數(shù)字化浪潮席卷全球，汽車產(chǎn)業(yè)外部環(huán)境日趨復雜嚴峻，傳統(tǒng)生產(chǎn)、制造及服務(wù)模式都面臨著前所未有的挑戰(zhàn)。汽車產(chǎn)業(yè)從依靠增量發(fā)展的階段邁入了存量調(diào)整的時代，行業(yè)提質(zhì)增效與轉(zhuǎn)型升級已成為趨勢。在新形勢下，大數(shù)據(jù)開發(fā)和應(yīng)用對汽車行業(yè)生態(tài)鏈，帶來了機遇和挑戰(zhàn)。

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

除開業(yè)務(wù)模式上的變化，整條過程鏈路的數(shù)據(jù)類型也發(fā)生了改變。其中不再全部都是離線數(shù)據(jù)了，實時數(shù)據(jù)也越來越多。由此對實時數(shù)據(jù)的實時計算是必不可少的環(huán)節(jié)。

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

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

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

動機

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

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

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

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

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

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

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

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

3.1 數(shù)據(jù)采集接入

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

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

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

3.2 數(shù)據(jù)實時處理

將各業(yè)務(wù)系統(tǒng)中的變動數(shù)據(jù)實時采集到 Kafka 后，下游將通過 Flink 實時計算引擎去處理及關(guān)聯(lián)，最終得到以 One ID 為標準的結(jié)果數(shù)據(jù)。

One ID 把不同時期孤立建設(shè)的系統(tǒng)，用統(tǒng)一的 ID 串聯(lián)起來，就可以更全面、更完整地了解數(shù)據(jù)本身，能夠更加精準地評價數(shù)據(jù)的價值，為精細化運營夯實數(shù)據(jù)基礎(chǔ)。

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

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

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

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

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

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

汽車主機廠會和各物流承運商簽訂的合同中詳細界定責任范圍。物流運輸途中發(fā)生異常狀況都將由對應(yīng)環(huán)節(jié)的物流承運商負責，零件到了中轉(zhuǎn)節(jié)點之后將由專人驗收和簽署回單，專門人員會將相關(guān)零件信息錄入更新至業(yè)務(wù)系統(tǒng)中。

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

實體抽取要從文本數(shù)據(jù)集中自動識別出命名實體。實體抽取的質(zhì)量對后續(xù)的知識獲取效率和質(zhì)量影響極大，是信息抽取中最為基礎(chǔ)和關(guān)鍵的部分。初始業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫中節(jié)點人員錄入的描述信息，首先會使用 CRF 對實體邊界進行識別，如圖 4 所示。

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

文本語料經(jīng)過實體抽取，得到的是一系列離散的命名實體，為了得到語義信息，還需要使用高斯核函數(shù)提取出實體之間的關(guān)聯(lián)關(guān)系，才能夠形成網(wǎng)狀的知識結(jié)構(gòu)。如圖 6 所示。

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

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

3）異況告警。零件訂單狀態(tài)監(jiān)控系統(tǒng)會將出現(xiàn)的異況第一時間告警至涉及人員，并基于異況根因分析情況進行后續(xù)的調(diào)整，力爭不會對主機廠最終的生產(chǎn)計劃造成影響。

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

改進的資源調(diào)度算法

4.1 算法設(shè)計

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

假定集群中 Pod 總數(shù)為 Np，平均每個 Pod 的AffinityTerm 數(shù)為 3，經(jīng)過預選后的節(jié)點數(shù)為 Nn，節(jié)點的label 個數(shù)為 6，所有 Pod 中，與待調(diào)度 Pod 匹配的同組Pod 數(shù)為 Nsp，則優(yōu)化后的優(yōu)選算法復雜度為

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

若假定 Nsp 及 a 為常數(shù)，則隨著集群規(guī)模 N 增大，計算復雜度的優(yōu)化倍數(shù)很快會收斂。

4.2 算法流程

Kubernetes 默認調(diào)度器 kube-scheduler 在優(yōu)選時會調(diào)用自定義擴展程序進行給節(jié)點打分。優(yōu)化后的優(yōu)選算法執(zhí)行流程如下：

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

2）算法 2。根據(jù)每個節(jié)點上資源負載情況，計算節(jié)點的最終分數(shù)，執(zhí)行流程如圖 8 所示。

實驗對比與分析

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

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

5.2 訂單履行狀態(tài)監(jiān)控系統(tǒng)測評

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

5.3 Flink 資源調(diào)度改進算法測評

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

在數(shù)據(jù)量增大時，F(xiàn)link 測試任務(wù)的計算結(jié)果時延、數(shù)據(jù)堆積、集群節(jié)點 CPU 使用率和內(nèi)存使用率對比結(jié)果如圖 9、圖 10、圖 11 和圖 12 所示。從實驗結(jié)果上來看，通過自定義優(yōu)選調(diào)度算法，對任務(wù)運行性能和集群資源使用率上均有一定程度的提升，驗證了本文方法的有效性。

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

總結(jié)及展望

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

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