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

引言

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

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

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

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

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

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

動(dòng)機(jī)

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

汽車(chē)零件物流具備幾個(gè)特點(diǎn)：

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

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

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

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

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

汽車(chē)零件訂單履行精細(xì)化運(yùn)營(yíng)

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

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

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

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

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

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

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

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

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

3.3 汽車(chē)零件訂單履行異況處理

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 算法設(shè)計(jì)

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

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

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

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

4.2 算法流程

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

1）算法 1。根據(jù)每個(gè)節(jié)點(diǎn)上存在當(dāng)前 Pod 對(duì)象類(lèi)型的數(shù)量，計(jì)算節(jié)點(diǎn)分?jǐn)?shù)，執(zhí)行流程如圖 7 所示。

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

實(shí)驗(yàn)對(duì)比與分析

5.1 訂單履行異況知識(shí)圖譜測(cè)評(píng)

使用 20 000 條異況描述訓(xùn)練語(yǔ)料進(jìn)行實(shí)體和關(guān)系抽取，構(gòu)建異況知識(shí)圖譜模型。以準(zhǔn)確率、召回率和 F 值3 個(gè)指標(biāo)來(lái)評(píng)估異況知識(shí)圖譜模型的實(shí)際效果。驗(yàn)證結(jié)果見(jiàn)表 2。

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

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

5.3 Flink 資源調(diào)度改進(jìn)算法測(cè)評(píng)

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

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

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

總結(jié)及展望

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

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