FFA2024分論壇-Data+AI.pdf

1、LLM技術在B站大規模Flink運維中的探索與實踐張勛祥嗶哩嗶哩資深開發工程師背景解決方案實踐成果未來展望背景業務規模6500+Jobs20W+Cores25+Consults集群規模作業規模咨詢量/周760T+Memory內存規模運維問題實時研發代碼編寫、資源配置、調試實時運維性能優化實時告警Checkpoint失敗告警、斷流告警、作業失敗告警用戶問題涉及開發、調試、運維各過程告警后需人工干預，定位困難分析過程需結合日志、監控、指標等問題需要用戶補充背景才能理解多個方面需要提供基礎能力用戶問題往往包含多個子問題問題呈現形式：文字、文字+圖片、文字+鏈接可能涉及多個方面分析多方面反饋的結果需加

2、工、過濾和關聯運維特點問題多樣根因復雜門檻高Flink使用姿勢、原理等涉及繁雜支持豐富的connector、業務鏈路多業務要求高高吞吐、低延遲、低checkpoint失敗率解決方案Flink運維平臺演進Flink運維平臺 1.0圍繞Flink進行基礎能力建設重點解決：數據源、場景痛點、及時觸達Flink運維平臺 2.0針對復雜運維場景突破重點解決：用戶咨詢的自動化解答和復雜運維問題的自動化分析Flink運維平臺 1.0核心目標：接入各類數據源，滿足分析必要條件 解決業務的核心痛點，優先落地重要場景 完善監控告警機制，及時有效觸達用戶 擴展并解決更多場景平臺架構資源調優作業診斷健康分接口層業務邏

3、輯層調度層調度器數據源元倉數據引擎指標數據作業日志日志診斷匹配根因分析規則指標診斷選擇執行解析檢測資源調優計劃執行分析問題節點自愈分析執行收集容量評估機器異常巡檢.日志診斷作業失敗規則告警轉發匹配根因分析l 90+規則l AND/OR 組合匹配l 優先級排序l 不同場景分類分析l 結合相關因素分析l 通知群/用戶/SRELLM歸納總結多數據源組合分析指標診斷BackPressureSymptomHighCpuSymptomHighMemorySymptomDataSkewSymptomBackPressureDetectorHighCpuDetectorHighMemoryDetectorDa

4、taSkewDetectorDataDelayResolverMemoryResolverSelectorSymptomsActionExecutorCandidates資源調優指標流量信息Cpu UsageThrottleMemoryUsageGCCheckpointThroughput外部系統延遲并行度調整Kafka TP擴容資源配置優化問題節點自愈慢節點定位故障節點定位節點自愈采集作業LatencyMark指標計算Operator維度的延遲指標統計段時間內Operaptor指標計算ZScore通過Operator與Container之間的映射關系，給Container投票數據傾斜?Con

5、tainer票數過半?結束是否否是統計段時間內各作業TM失聯信息獲取TM失聯所在機器指標信息獲取當前機器上作業個數作業失敗個數是否超過閾值/機器核異常?結束機器故障是否節點異常判斷類型節點不可調度結束機器下線卸載磁盤掛載磁盤更改磁盤權限重設K8sLabel節點設為可調度慢節點故障節點加名單慢節點不足點缺乏手段自動化回答用戶咨詢的問題作業運行時異常根因分析依然以人工為主Flink運維平臺 2.0核心目標：實現部分用戶咨詢場景運維自動化 加強和完善根因分析能力平臺架構QueryAnswerRouterAgentFlinkConsultAgentJobInterruptionAgentJobStac

6、kingAgentJobCheckpointAgentQuery UnderstandEmbeddingRerankSummary(LLM)chunks#1-#2-#n-rerankedchunks#3 -#50 -#89 -Planing(LLM)Function ToolsExecuteCode(LLM)Test(LLM)xxxConsultAgentParse&SplitterVectorization(Embedding)ESMachineFaultAgentFunction Tools私域知識庫基于Advanced RAG范式構建私域知識庫架構圖文件上傳自定義文件上傳刪除無關信息文件

7、解析切片構建索引固定塊query索引聚類樹索引提問query改寫拆解拓展補全知識庫1知識庫2知識庫n多路召回語義檢索關鍵詞檢索排序rerank模型LLMprompt模型回答ChatEngine主要挑戰如何有效理解用戶問題如何保證整個回答鏈路更快如何有效的文本切分如何有效提升索引準確率如何讓大模型回答更快些回答準確率回答時效解決手段支持多輪對話支持混合檢索Query優化引入Raptor功能 借助多輪對話信息補全 采用融合重寫進行補全(RAG-Fusion重寫)根據用戶維度緩存對話信息 繼承llamaIndex中多聊天類保留歷史對話信息 開發倒數排名融合（RRF）算法，支持關鍵字匹配+向量檢索混合

8、查詢 能夠同時捕捉到文本中的高層次信息和細節，在處理復雜的主題查詢時優勢大RRF算法原理：根據簡單的評分共識對文檔進行排序。給定一組要排序的文檔D和一組文檔的排名R，每個文檔的排名在1len(D)之間，其中k=60。具體計算公式如下：解決手段l 物理機配置：兩臺，48core/250GB資源型號、每臺是4塊為Tesla P40的GPU型號l 軟件配置 LLM模型（mistral、llama3.2、qwen:32b等）使用Ollama部署、Embedding（bge-large-zh-v1.5）和Rerank（bge-reranker-large）使用Xinference部署GPU_01GPU_

9、02GPU_03GPU_04OllamaOllamaOllamaOllamaNginxXinferenceGPU物理機域名容器智能客服服務智能客服服務主要優化：初始化多個Ollama進程，每個進程指定一塊GPU編號利用Nginx做負載均衡，充分利用GPU資源https:/診斷智能體Agent（代理）在人工智能領域，被賦予了新的定義：具有自主性、反應性、交互性等特征的智能“代理”。大模型賦予了AI Agent核心改變。大模型時代的AI Agent=LLM (規劃+記憶+工具+執行)實現流程：規劃生成執行是否成功？創建計劃生成多個計劃生成組合計劃CodeTestCode代碼解釋器執行生成結果Que

10、ry提交提交提交是/執行超過閾值否返回結果Function Tools總結業務場景分析作業數據斷流分析數據源問題Flink應用內部問題網絡問題外部依賴服務問題作業數據堆積分析算子處理速度慢并行度設置不合理數據傾斜外部系統響應慢作業Checkpoint失敗分析狀態數據過大網絡問題存儲系統問題資源不足問題分析可能性因素多，排查復雜不同問題既有共性，也有差異主要挑戰規劃要求 理解問題，并拆解子任務 子任務包含工具調用工具構建執行方式如何回答 規范函數定義、注釋、輸出數據結構 根據業務場景，開發相關函數 將規劃思路過程生成Python代碼 編寫測試代碼，提供入參信息 執行測試代碼，獲取結果 根據各個函

11、數返回結果，進行分析、組織、總結解決手段生成代碼Prompt重試機制通用化規劃Prompt生成測試代碼Prompt工具定義通用化執行階段通用化Prompt定制化流程通用化實例介紹用戶問題規劃最優執行計劃生成Code生成Test Code生成結果總結123456實踐成果場景展示作業失敗診斷錯誤日志診斷機器故障查詢場景展示Flink知識咨詢作業斷流根因分析作業堆積根因分析值班變化15+80%60%半自動化咨詢覆蓋率半自動化咨詢量/周問題排查時效降比未來展望未來與展望應用更多場景診斷智能體持續演進從分析到解決構建閉環THANK YOU謝 謝 觀 看字節推薦場景萬億級FeatureStore演進歷程和

12、挑戰楊健章字節跳動推薦架構工程師李旺字節跳動推薦架構工程師背景推薦場景 Feature Store序列特征存算引擎LLM 在特征場景應用未來規劃背景字節推薦 Feature Store 演進歷程基于Flink SQL+DataStream初步構建特征產引擎，持窗、全局統計類特征產20192020特征引擎平臺化建設，并引Flink Batch持部分批式特征產場景2021l 建設特征產、消費體平臺化l 構建流批體特征產引擎Planner，同時持特征程和樣本程l 推出Python SDK特征產范式，提升算法特征研發效率20222023l 特征寬表能建設，提出特征產、效標準范式l 成式推薦能建設，持序

13、列特征產、調研能建設l 探索LLM在特征產場景的應2024特征引擎特征平臺特征中臺Feature Store離在線特征物化多題材多引擎挑戰特征復用支持跨體裁業務間特征共享版本管理多版本能力，支持特征回退、回溯特征管理基于LLM進行血緣回溯、特征研發抽象物化引擎，提升索引構建效率執引擎抽象抽象通用能力，提升特征開發人效序列特征研發全周期支持長序列特征生產、生效推薦場景 Feature StoreFeature Store 業界現狀l普及和標準化：提供特征全命周期管理，使特征發現、共享和使變得更加效和致l多樣化：開源社區、商業化以及云商積極推出各Feature Store產品，如Feast、Tec

14、tonl應業泛：在融、醫療、零售等多個業泛應，構建更精準的推薦系統、險評估模型等l技術挑戰：臨數據致性、實時性、擴展性和數據治理等挑戰ModelModelTrainerFeature ServiceOffline StoreOnline StoreStream SourceBatch SourceFeature ViewFeature ViewFeature ViewFeature ViewTecton架構：業界進展：推薦場景 Feature Store 架構圖KafkaHDFSRPCValidationCompilerMeta CenterBig TableLakeKVGraphValida

15、tionCompilerUnified DSLPlannerUnified DataflowFlink(Streaming/Batch)Spark(Batch)Feature ViewIndex OrchestrationFlink/SparkSort ServiceModel trainingStrategy ServiceFeature Service特征消費數據源Feature PipelineOffline Store Materialized PipelineOnline Store視頻直播電商業務多題材背景跨題材特征寬表(Offline Store)問題：l 不同業務具有獨的特征空

16、間，特征空間壁壘導致各題材特征數據分散在個個信息孤島l 各題材之間法特征唯性驗證，導致同業務場景下不同題材業務法共享特征 訴求：l 打破特征空間壁壘，各體裁特征可實現業務間共享l 提供從特征創建、離線特征寬表存儲、索引構建、在線特征窄表存儲全鏈路跨題材能live entity feature tableE-com Entity TableE-com Online TableCross-entity JoinFeature JobLive Entity TableVideo Entity TableLive Online TableVideo Online TableCross-entity J

17、oingidf1f2f3gidf4f5f6gidf7f8f9Product2Entity1Entity2Entity3Feature1Feature2Feature3特征Meta(product2唯性)Offline Store(Entity2 table)Offline Store(Entity3 table)Feature View(Index1)Feature View(Index2)Online Store(forward index)Online Store(inverted index)產品Meta實體MetaOffline Store(Entity1 table)寬表Meta(離

18、線寬表存儲)視圖Meta(索引視圖抽象)窄表Meta(在線索引存儲)Product1Feature Store元數據抽象：跨題材特征寬表(Offline Store)特征寬表產、效：Feature JobFeature JobFeature JobFeature Job特征產索引構建Video EntityLive EntityE-com EntityDouyin WorkspaceFeature Materialize：物化引擎 什么是物化引擎：l 根據索引構建類型(如：正排、倒排、候選等)，可對離線特征寬表中的特征進場景化編排，將編排之后的特征數據導到在線存儲中，以便在線推薦服務使Feat

19、ure Materialize：物化引擎BigTableLakeOffline StoreOnlineStoreKVForward IndexInverted IndexCandidatesMaterialize EngineMaterialize TriggerIncrement TriggerFull TriggerScenario based Index OrchestrationOptimization&SchedulerMulti-view MergeIncremental Materialized ViewView SchedulingMaterialize Python SDKF

20、eature Column SelectionFeature Row SelectionCross-entity JoinSimple CalculationOnline StoreKVOnline StoreKV離線寬表存儲在線索引存儲Engine RuntimeFeature Materialize：Python SDKcontext=materialize.create_context(.)entity_1=context.get_entity(.)entity_2=context.get_entity(.)forward_index_view=context.get_forward_i

21、ndex(.).ttl(.)df=entity_1.with_trigger(.).select(f1,f2).lookup_join(entity_2,join_key=gid).select(f3,f4).where(f1 0,on_true=UPDATE,on_false=DELETE)df.materialize(forward_index_view)實體對應寬表觸發變更物化效索引編排索引對應視圖Feature Materialize：索引構建流程Change Event TriggerFlink Materialize JobSourceView mergeLookupSinkInd

22、ex1SinkIndex2Bind Featuregidf1f2f3f4uiduidf5f6gid3gid2gid1f1f2feature_view1feature_view2變更關聯視圖WideTable1WideTable2Feature Job1Feature Job2Feature Job3Feature Job4feature_view1feature_view3feature_view2WideTable1WideTable2gidf1f2f3f4uiduidf5f6特征任務索引視圖Feature Materialize：索引構建流程Feature Job1Feature Job2

23、Feature Job3Feature Job4feature_view1feature_view3feature_view2Change Event TriggerFlink Materialize JobSourceView mergeLookupSinkIndex1SinkIndex2WideTable1WideTable2Bind Featuregidf1f2f3f4uiduidf5f6特征任務索引視圖gidf1f2f3f4uiduidf5f6gid2f3f4feature_view2feature_view3變更關聯視圖WideTable1WideTable2gid3Feature

24、Materialize：索引構建流程Feature Job1Feature Job2Feature Job3Feature Job4feature_view1feature_view3feature_view2Change Event TriggerFlink Materialize JobSourceView mergeLookupSinkIndex1SinkIndex2WideTable1WideTable2Bind Featuregidf1f2f3f4uiduidf5f6特征任務索引視圖gidf1f2f3f4uiduidf5f6gid3f2f4feature_view1feature_v

25、iew2變更關聯視圖WideTable1WideTable2feature_view3序列特征存算引擎生成式推薦：序列優先 連續和離散等特征都 encode 到序列特征中(展現序列與行為)連續值特征在序列中隱含表達，直接從模型輸入中刪除 離散型特征根據時間排序融合，如用戶關注列表，分解到不同時間關注的 author_id的序列，融合結果用于最終的序列建模特征演進序列特征的特性和挑戰計算鏈路復雜主推薦場景長度 10w+，序列跨度 3 year+單條序列特征總數據量達 PB 級序列長度超長序列數據量大序列特征生產鏈路包含實時、增量、回溯三種計算任務支持快速加屬性調研和保證序列一致性序列調研復雜序列

26、特征存算架構ValidationCompilePython SDKLocal Test計算優化SQL TranslateAuto SplitParallel ExecDAG RewriteRuntimeFlink(實時)Spark(增量)Spark(冷啟)內存型 KV磁盤型 KV序列產序列存儲序列ServingSDKJavaC+IO 優化列裁剪統緩存Partial DumpIO 合并IO 讀取裁剪序列 Merge內存型 KV 讀取磁盤型 KV 讀取序列質量監控序列度分布Metric 指標分析異常監控告警屬性異常值檢測緣鏈路建設增量 bulkloadnn-1n-2n-3SST全量構建痛點計算量，

27、消耗量計算資源，影響序列特征產出時效性天級全量特征產出，浪費量存儲資源PB 級 Shuffle 數據影響特征產出和作業穩定性Stage 尾法充分利集群資源nn-1n-2n-3SST1增量構建SST2優勢Parallel ExecutionAuto Split產任務持只計算增量序列，計算量下降兩個數量級 PB-TB序列存儲引擎持增量 bulkload，存儲空間下降 50%多個 Spark 任務 Parallel Execution，隊列平均利率 70%-95%Speculative Schedulersplit_2split_nSST_1_2SST_2SST_nSST_1_1SST_1SST_2

28、SST_n/home/.date1/task_id1/shard1/cf1/home/.date1/task_id2/shard1/cf1/home/.date1/task_id3/shard2/cf1/home/.date1/task_id4/shard3/cf1/home/date1/shard1/cf1/home/date1/shard2/cf1/home/date1/shard3/cf1SinkTasknSinkTask2SinkTask1.2split_1split_1SinkTask1.1CANCLEDExecutorsDriversfailed/successFailed刪除臨時

29、件/home/.date1刪除線上件/home/date1Success刪除臨時件/home/.date1動態加列序列特征新增屬性需要重新產歷史全量數據，消耗量計算資源加列期間，存儲集群需要預留 2 倍資源，存儲資源利率過低加列操作過重，端到端耗時 1 周+，嚴重影響模型迭代效率戶為表JOING 側屬性表DISTINCTAGGSST2SST1加列問題Q：加列場景，已有列不變，是否可以只產包含新增列的 SST 件？Read View序動態加列戶為表JOING 側屬性表DISTINCTAGGSELECTSST2SST1Async CompactionSSTRead View戶為表 Source 節

30、點后，動態插 SELECT 算，篩選出下游算所需字段(join keys,group keys,distinct key etc)加列回溯任務只產包含新增列的 SST 件，保證和存量列的 SST 件對序列存儲引擎提供異步 compaction 能，逐步消除多件讀帶來的性能劣化動態加列序列調研 Hive 表產優化DAY1DAY2MONTH1DAY_k-1DAY_k-2MONTkDAY_n-1DAY_nMONTHk天級為明細表級bucket聚合表調研 Hive1調研冷啟階段DAY_m調研 Hive2全量 Merge(shuffle less)增量 Merge(shuffle less)周期序列調研

31、 Hive 表優化思路冷啟動兩階段聚合，減少單任務 Shuffle 的數據量級聚合表利 bucket 優化，在全量序列 merge 階段消除 group by 帶來的 Shuffle 開銷增量階段利已有的調研分區，進增量 Merge，消除重復計算LLM 在特征場景應用書機器LLM多Agent架構用戶產品層open api開發套件集成MasterAgent層Master1Master2Master3Worker Agent 層緣Agent智能開發AgentDSL智能修復Agent相似任務檢測Agent工具庫血緣查詢工具代碼執行工具知識檢索工具指標采集工具短期記憶長期記憶鏈式思考目標拆解自主規劃記

32、憶功能相似任務推薦數據預處理流程任務推薦流程LLM AgentMeta DatabaseEmbedding ServiceDSL核信息摘要VectorDatabase戶DSLDSL核信息摘要LLM Agent相似度計算LLM Agent最相似的任務相似度top5的dslLLM Agent問答形式開發套件集成多種靈活的觸發式openapi觸發代碼執行工具歷史問題檢索具主調錯誤分析結果：.修復意：.基于ReAct框架實現具庫基于ReAct的DSL智能修復功能展示代碼輔助生成智能問答代碼修復血緣查詢未來展望 Feature Store計算引擎：l 持續打造推薦通計算引擎，建設推薦離線計算Unifie

33、d Runtime體系，覆蓋特征產/回溯、樣本計算/回溯等場景l 持續演進物化引擎，圍繞物化時效性、異構存儲體物化、特征質量監控等探索和建設 成式推薦&推薦模型持：l 持續迭代序列特征存算引擎能，推進向量化計算、存量分離等l 基于Lake構建序列特征Offline Store，提升序列迭代效率未來規劃THANK YOU謝 謝 觀 看基于 Flink 和 Elasticsearch設計企業級高級 RAG 架構朱杰Elastic中國首席解決方案架構師Elastic社區和阿里云Elasticsearch社區布道者Elastic-Elasticsearch背后的公司2800+員工40+國家設立分公司4

34、B+下載量54%的財富500強企業信任Elastic解決方案成立于 2012 年Elasticsearch開源成果搜索 改變了世界 使用數據的方式 160K+提交70K+GitHub Stars46億+下載量3700+貢獻者120億+Elastic Cloud 每天搜索量GAI時代Elasticsearch需要與時俱進過去未來向量搜索向量和經典混合搜索語義搜索模型重排序端到端RAG解決方案向量量化全文 結構化 地理位置分析聚合NLP模型多模態搜索簡單RAG架構正確答案GAI/LLM原始問題公開互聯網數據 私有化業務數據文檔圖像音頻上下文窗口+原始問題？高級RAG架構文檔加工切片索引構建quer

35、y改寫向量化多路召回重排序提示詞優化RAG定制模型評測指標ElasticsearchFlink和ES助力構建更高級RAG架構文檔加工切片索引構建query改寫向量化多路召回重排序提示詞優化RAG定制模型評測指標問答緩存熱點問題問題推薦敏感信息實時審計Elasticsearch全鏈路可觀測性文檔加工鏈路為什么要用Flink CDC多數據源集成Flink CDC支持多種數據庫和數據源，能夠將來自不同系統的數據整合在一起。這對于RAG文檔的生成非常重要，因為通常需要綜合多個數據源的信息以形成完整的視圖。實時數據同步Flink CDC能夠實時捕捉數據庫中的數據變化，包括插入、更新和刪除操作。這使得RA

36、G文檔在處理數據時能夠及時反映最新的狀態，確保文檔內容的實時性和準確性。數據處理和轉換使用Flink的流處理能力，可以對捕獲到的數據進行實時的轉換和加工。例如，可以根據業務規則對數據進行清洗、過濾、聚合等操作，從而生成符合RAG標準的文檔內容。高可用性和容錯性Flink具備高可用性和容錯機制，可以確保在數據處理過程中即使發生故障也不會丟失數據，保證RAG文檔加工的可靠性Flink CDCFlink CDC文檔加工架構圖關系型數據庫文檔數據庫Flink CDC流批一體稀疏向量模型密集向量模型多模態向量模型Elasticsearch數據湖結構化非結構化實時感知元數據變化多數據源融合Elastics

37、earch向量數據庫Create VectorEmbeddingsHybrid Search(text+vector)Choice&Flexibility of embedding modelsFiltering&FacetingAutocompleteOptimized for text,geo,&other data Ingest Tools(web crawler,connectors,Beats,Agent,API framework)SearchAnalyticsTrained model out-of-the-boxDocument-level SecurityOn-prem/Cl

38、oud/HybridStore&SearchVectorEmbeddings大部分向量數據庫一些向量數據庫Elasticsearch生成式人工智能應用程序所需的全部功能，超出了單純向量數據庫提供的功能AggregationsElasticsearch向量引擎優化方向硬件加速利用CPU硬件指令加速向量索引和計算速度增加單個查詢并發增加查詢并發度，充分利用更多的計算核心向量量化向量有損壓縮，float到int8、int4、Bit來平衡精度、速度和成本并發查詢間協同一個查詢的多個并發線程間協同共享信息，提前終止一些查詢線程更快更強Elasticsearch向量引擎-硬件加速的起點Panama For

39、eign Function Interface(FFI)調用本地代碼ARM 本地優化代碼X86 本地優化代碼Elasticsearch進一步利用本地代碼進行加速利用更多硬件能力并全面應用到其它搜索和計算Elasticsearch會更多利用本地代碼Panama Vector API 實現確定的向量化SIMD指令FMA指令Lucene利用硬件加速編譯器自動向量化Elasticsearch向量引擎-搜索并發集群整體吞吐優先限制單個查詢的資源每個查詢每個分片一個查詢線程每個查詢每個分片中的段一個查詢線程改進了搜索延遲可以重復利用更多核心數應用到其它搜索領域并發間協調以前現在Elasticsearch向

40、量量化轉化向量的數據類型 Float32-Int8 Int4 Bit大多數模型輸出 float32 類型的向量Int8 Int4 Bit可以更好的在精度、性能、成本之間平衡 對精度有一定影響通過增加候選數量來緩解優化了索引的大小增強搜索性能、降低搜索延遲增強索引性能Elasticsearch向量引擎-混合搜索密集向量文本向量稀疏向量圖片向量Elasticsearch Search APIsBM25文本搜索強大的語義和混合搜索RRF模型重排序非常重要Elasticsearch 統一推理接口ElasticsearchInference APIembedding、chat、rerankElastic

41、search部署的模型私有化部署的模型在線推理服務將ES核心功能和多樣化的推理服務解耦擴展支持更多的推理服務滿足自建、云服務等等多樣化的部署方式適配大中小各種規模的應用RAG LLM 緩存設計企業中每天會問大量相同的問題LLM需要響應時間，如果命中緩存可以加速響應節約重復問題的費用實時分析統計高配查詢，生成問題推薦分析聚合相似問題記錄問題的反饋記錄用戶交互，統計熱點文檔，段落，改進RAG用戶體驗RAG 安全合規審計企業認證服務集成精細化控制需要有和集中認證服務整合的能力LDAP/AD 鑒權SSO單點登錄精細化權限控制索引級別字段級別文檔級別基于規則的關鍵詞過濾通過構建規則混合搜索中精確過濾掉敏

42、感信息EQL事件查詢語言Flink CEP實時監測實時事件驅動監測支持復雜的事件流實時模式匹配Elasticsearch數據源頭簡單規則定時基于日志的監測廣泛用在風控、用戶行為分析RAG場景也需要風控和審計信息安全費用控制使用Elastic APM 為RAG構建可觀測Elastic APM 提供了各種語言的APM agent支持OpenTelemetry規范支持采集Trace Metric 異常日志可以關聯日志和APM方便對RAG各個環節監控性能和異常阿里云一站式AI搜索平臺搜索開發工作臺服務廣場基于主流開源搜索引擎，提供原子級算法插件及開發模板，結合底層算力支持，快速構建成熟的AI語義搜索、

43、RAG等場景化搜索服務大模型服務搜索專屬大模型百煉-通義千問大模型開源生態檢索引擎企業版Elasticsearch引擎阿里云Havenask開源搜索引擎Milvus開源引擎等第三方開源大模型模板串聯 RAG檢索增強生成模版行業語義搜索模版多模態搜索模版開箱即用的成熟RAG產品LLM智能問答版新更多AI能力及解決方案企業級ES檢索分析秒級彈性、更低成本日志檢索Serverless版行業級AI語義搜索行業算法版向量檢索版高性能、低成本圖關系檢索圖檢索版文檔解析切分語義切片文檔解析圖片解析召回服務向量檢索混合檢索排序服務重排模型向量表示稀疏/稠密向量多語言向量向量降維查詢分析意圖理解NL2SQL問題

44、擴展微調及測評服務模型微調效果測評新新非結構化數據PDFDOCPPTTXTHTMLIMAGEAUDIOVIDEO結構化數據數據湖場景化產品六大MaaS搜索產品更多學習資料和最佳實踐elastic.co/search-labselastic.co/security-labselastic.co/observability-labs京東零售基于FLINK的推薦系統智能數據體系張穎京東技術專家推薦系統架構召回服務推薦服務模型服務策略服務個性化推薦熱門推薦新品推薦多樣性推薦點擊相似商品召回搜索詞熱門召回i2i召回粗排精排重排混排多目標流量扶持ItemList關鍵模塊推薦系統智能數據體系智能數據體系推薦

45、系統召回個性化召回基礎召回模型精排粗排策略多目標混排特征索引樣本可解釋指標相關性排序多樣性推薦搜索內容分析實時推薦推薦用戶畫像建模用戶活躍度提升用戶增長個性化推薦協同過濾用戶反饋優化推薦系統智能數據體系構成索引樣本特征可解釋指標索引什么是索引？索引為召回服務提供數據索引類型召回服務索引構建底池數據個性化索引偏好*品類/品牌 索引用戶行為足跡索引基礎索引時間索引品類、品牌索引策略索引兜底索引流量扶持（冷啟、低曝）什么是索引？正排數據商品id品類id標簽品牌得分113002機華為2.5213002機3.6313002機蘋果4.8413004鮮佳沃4.8倒排數據倒排key品類_13002品類_130

46、04標簽_機標簽_鮮value3；2；1；4；3；2；1；4；索引架構全量索引（天級）增量索引（小時級）OLAP實時屬性補齊基礎、策略倒排Hive實時索引（秒級）kafka數據解析數據去重離線屬性補齊寫入kafka正排計算個性化倒排索引構建索引服務屬性補齊正排計算基礎、策略倒排個性化倒排索引構建索引服務樣本樣本開發架構曝光、點擊、下單埋點kafka特征數據kafka流式樣本拼接流式樣本秒級增量樣本小時/分鐘級曝光、點擊、下單表hive特征表hive批式樣本拼接批式樣本天級全量訓練月級樣本增量訓練月級+增量樣本實時訓練秒級樣本123樣本特定場景樣本冷啟樣本特征回溯延時反饋樣本采樣離線樣本實時樣本

47、離線樣本架構曝光、點擊、下單表hive特征表hive批式樣本拼接批式樣本天級全量訓練月級樣本樣本冷啟三階段特征回溯三階段跟單、點擊Label 計算（全量、月級）Feature 寬表生成（全量、月級）Feature+Label 拼接（全量、月級）Fn+1 新表生成（全量、月級）Fn+1 表、樣本表主鍵對齊（全量、月級）樣本表新增Fn+1特征（全量、月級）實時樣本架構-分階段窗口曝光埋點kafka特征數據kafkaPB解析數據解析拼接曝光特征點擊拼接曝光 點擊特征加購、下單曝光 點擊 下單特征Sample時間窗：5min時間窗：10min時間窗：20min下單時間判斷Hive 離線樣本樣本mix實

48、時樣本shuffle延時反饋實時拼接時間窗口可按照品類設置全鏈路監控等實時樣本架構-OnlineEvaluation實時樣本95%采樣5%采樣離線樣本mixed樣本hdfskafkapredictor實時樣本OnlineEvaluation實時樣本shuffle特征需求多邏輯復雜回溯難特征回溯計算量大，耗費周期長特征開發難點用戶維度的、Item維度的；統計類的、序列類的等特征開發和模型實驗緊密結合，需求非常多實時特征開發架構（觸發流架構）行為接入層行為補全層用戶行為瀏覽商品List點擊商品List商品行為商品點擊List&count商品曝光List&count點擊近5min對品類點擊量近5mi

49、n 點擊量用戶統計特征長期序列短期序列用戶序列特征特征挖掘層曝光瀏覽加購下單下單商品List加購商品List近5min點擊數近5min曝光數商品統計特征用戶屬性 X 商品品牌用戶屬性 X 商品品類用戶&商品交叉特征特征在離線不一致&穿越解決方案特征開發埋點數據戶數據商品數據特征存儲predictor特征服務特征程SDK特征快照dumpSample Feature特征在離線一致計算特征SDK在離線一致FeatureDump特征在離線不一致特征穿越特征樣本在離線DIFF技術手段埋點口徑&邏輯解析一致算子實時Union+Timer多流拼接大狀態優化離線JOIN優化問題&解決質量&校驗實時&離線數據口

50、徑不一致實時&離線數據解析不一致實時&離線數據計算不一致特征樣本分布特征有值率特征樣本延時樣本特征、Label Diff埋點口徑&邏輯解析一致性實時實時SourceOpsParseOps離線離線SourceOpsParseOps埋點口徑在離線一致解析算子邏輯一致特征計算屬性特征、序列特征等特征寫入自動化限流樣本拼接多流拼接、超大窗口樣本糾偏、延時反饋樣本工程在離線一致樣本采樣上線采樣樣本JOIN樣本寬表策略樣本表特征寬表生成屬性特征、序列特征Embedding 等特征導入自動化限流計算一致性可解釋什么是推薦系統的可解釋？解釋推薦系統排序結果將物料從召回、過濾、排序、策略等各個階段詳細記錄，作為

51、可解釋的基石解釋推薦系統模型結果從特征的角度解釋模型/鏈路對某個（些）sku 的得分高/低解釋推薦系統流量結果從整體流量（召回、排序、策略）維度解釋商品差異（分層、長尾等）的原因排序可解釋模型可解釋流量可解釋可解釋系統架構模型可解釋應用單sku 特征重要性多sku特征重要性用戶特征重要性全局特征重要性底層架構搭建算法日志、用戶行為數據解析攢批多聚合、精細化場景case 查詢召回問題分析模型問題分析排序可解釋過濾問題分析策略問題分析Sku 流量對比原因分析流量可解釋Grafana全域模型打分問題FLINK：實現了天級PB級增長數據（特征、召回、排序、策略等）實時入倉ClickHouse：提供多維

52、度分析查詢功能，解決排序可解釋鏈路分析難的問題排序可解釋推薦物料可解釋：debug 鏈路推薦物料可解釋：trace 鏈路用戶畫像行為畫像商品畫像排序可解釋模塊消息隊列(Kafka)ETL數據解析（Flink）排序服務器（SDK日志采集）OLAP數據存儲數據基石流量可解釋用戶行為動線建設推薦系統整體流量歸因（召回、排序）流量可解釋模塊消息隊列(Kafka)ETL數據解析（Flink）排序服務器（SDK日志采集）OLAP數據存儲埋點數據用戶行為序列跟單上層應用模塊特征回溯樣本冷啟指標指標實時化曝光點擊跟單服務端曝光OLAP多維分析實驗維度品類維度品牌維度(U)CTR(U)CVRGMV單量其它joi

53、nTHANK YOU基于pyflink的算法工作流的設計和改造Design and transformation of algorithm workflow based on pyflink程興源碩橙科技 大數據工程師github:kaori-seasons掘金:語落心生spring cloud alibaba committer主導過Rocketmq社區的冪等性方案設計參與過第一屆flink hackathon目前負責碩橙科技算法工作流系統以及數據中臺的建設Why Flink公司的業務現狀以及如何與Flink相結合算法工作流的設計算法的種類介紹以及工作流的編排性能優化的探索之路尋找可能落地的

54、方案上下游鏈路協作的思考數據鏈路中的流轉方式未來與展望工業場景的歸因目標Why Flink公司的業務現狀以及如何與Flink相結合碩橙科技成立于2016年，是一家專注通過全感知智能硬件、AI算法以及數字基座賦能工業智能運維、智能制造、數字孿生、智慧城市等多個數字化經濟領域的國家高新技術企業。公司面向全場景、全鏈接、全智能市場創建了涵蓋產品、平臺、云服務和AI服務的盼橙生態體系，實現了從智能傳感器、邊緣計算中心、工業大數據、AI算法、到工業互聯網平臺的完整技術布局，形成了具有自主知識產權的核心技術與完整的產品體系。預測性維護自動化AI質檢環境異常警報設備遠程監控產線實時監測.碩橙算法作流服務于業

55、互聯的場景,我們是家業互聯公司，主要向電，油化,礦礦業,兵器業，航天航空,船舶汽，港港務，電能源，品飲料，煙草業，化，利務，產品質檢，機械加，醫療醫藥提供服務。其中的項特服務是向業場景基于獨有的特征算法結合多維數據，為客戶提供AI預測性維護。關鍵業務:在不同類型的客戶部署數采硬件或從三取得傳感數據后，針對被監測設備的每個部件得到專業的狀態監測報告和數據分析報告。研發關鍵點：讓算法同學更好的編寫插件(比如分析函數，神經網絡)使得客戶能夠在算法控制臺靈活的配置機器學習工作流讓客戶快速的得到數據分析報告多樣化特征庫（閾值檢測區間、頻段區間、配置況）不同種類的檢測算法存儲計算引擎算法控制臺（算法wor

56、k_flow）在我們的場景當中，因為要同時處理秒級和定時評估算法的數據,并且點位到來的數據可能存在到達的延遲時間周期.存在需要經過時間窗處理的情況。再加上算法側需要經常利python寫些分析算法作為特征計算的邏輯，所以選擇了pyflink。采集站1.數據上送邊緣端的kafka算法控制臺配置作流json2.從邊緣端接收過來原始特征數據算法依賴框架得到算法數據緩存的結果3.通過不同檢測算法產生算法結果4.1生成特征分析報告特征分析頻譜分析輸出分析報告邊緣關存量歷史數據（clickhouse）算法結果（clickhouse）算法工作流的設計公司的業務現狀以及簡介數據源分算法1分算法3分算法3匯總結果

57、分算法2輸出配置的事件類型輸出配置的事件類型算法結果數據源分算法1分算法3分算法3匯總結果分算法2輸出配置的事件類型輸出配置的事件類型算法結果數據源分算法1分算法3分算法3匯總結果分算法2輸出配置的事件類型輸出配置的事件類型算法結果collects:algorithm_id:1464,result_data:nodeId:1464,algorithmId:1464,devices:device_id:1464 ,feature_data:,transfer_data:nodeId:1464,algorithmId:1464,devices:device_id:1464 ,dataTime:17

58、26675236000,status:0,health:elec_noise_gt8k:0,.,event:,feature_data:1.輸出對設備健康度的預測2.輸出可能的故障原因與類型、設備狀態、況等123為了保證多點位能夠運在同個作業的點位經過計算后。算出結果輸出給戶側。我們采算法實例為維度進數據緩存，并基于緩存進迭代計算。分發服務接收的算法數據分為兩種，種原始數據,即測點數據.種算法回傳的數據.需要算法框架從緩存當中取出維護,批量計算數據。算法實例上下游之間成銜接關系.需要保證算法出參參都帶有實例id.便當前實例從上游算法實例取字段。性能優化的探索之路公司的業務現狀以及簡介測試環境：

59、系統：Ubuntu 22.04.4 LTS內存：8GCPU：Intel(R)Core(TM)i5-10400 CPU 2.90GHzPyFlink：1.16.1測試法：以天（個點位每秒條數據，天共86400條）為單位，進不同的數據量測試分別測試 3 個算、5 個算和 10 個算情況下的性能對都帶有 output_type 和不都帶 output_type 參數的性能測試步驟：1.設置測試環境2.運測試程序，分別在帶有和不帶有 output_type 參數的情況下進測試3.記錄每次測試的耗時4.計算性能提升百分每個算參數不帶有output_type參數的測試代碼其中 output_type 定義

60、了傳輸數據每個字段類型，定義式如下圖：每個算參數帶有output_type參數的測試代碼a)測試3個算時長帶有 output_type 耗時（秒）沒有 output_type耗時（秒）提升效率1 天9.4569.9735.18%3 天14.53218.18720.10%5 天28.91138.78625.46%7 天34.39751.69133.46%b)測試5個算時長帶有 output_type 耗時（秒）沒有 output_type耗時（秒）提升效率1 天9.97110.4014.13%3 天20.30825.74421.12%5 天30.16640.30525.16%7 天40.3405

61、4.40525.85%c)測試10個算時長帶有 output_type 耗時（秒）沒有 output_type耗時（秒）提升效率1 天11.46812.1305.45%3 天23.69731.12123.85%5 天38.01549.50823.21%7 天48.85965.14024.99%從之前的測試結果來看，在 PyFlink DataStream 中明確指定 output_type 參數能夠顯著提高序列化性能，特別是在數據量較大和算子較多的情況下，提升效果更加明顯。使用 output_type 可以減少序列化和反序列化的開銷，減少類型推斷的計算，進而提高性能。根據pyflink的進程間

62、通信機制，我們的性能瓶頸發生在時序4-10，也就是從JVM到PVM通信的編解碼，這部分在pyflink內部采用原生的pickle實現編解碼。1.定義序列化(avro等進制序列化)是否能夠提速2.批模式跑單點位單并度3.數據均衡優化發現瓶頸嘗試進行avro序列化發現keyby反壓，嘗試打散數據批模式+pandas udf改造source數據均衡優化通過DatraStream或者SQL作業返回的schema進推導，轉換成avro格式，作為指定的output_type序列化，但性能并沒有很提升?；玖鞒蹋涸谒惴ǖ臄祿溌樊斨邢冗M轉列,接著按照點位進分流，在處理過程當中存將每個點位經過系列插件處理后，

63、將輸出的算法結果進合流操作。在其中需要先根據點位等信息進分區，然后封裝統的算法udf插件進實現。在下游的keyby分發過程中，存在三種式：1.基于時間窗的多流分發計算2.基于value值的分發3.在分發時候對于多個點位做mergekey的合并計算1.基于window tvf+udtf的式 將經過批量數據驗證后的算法輸出的結果以表值函數的形式運,2.將所有字段作為udf的參，原先的插件邏輯轉化為基于schema的物理字段計算3.基于Partition by 產的每個點位的分區增id,區分每個點位產的數據，聚合的時候通過mini-batch階段提交的式進優化法收益:這種式下會將所有算統調度起來，并

64、且按照上下游算的關系分成多個stage，按照順序調度.如圖所示,下游的算需要經過多次分流。會造成下游上游算處理數據時，因為數據沒有流經到下游算造成阻塞等待。這種模式的好處是數據能夠次性拉到PythonAgg算。在source端不會有太多的時間損耗。此外由于采pandas udf，下游的發送數據的時候也能得到性能優化。keyby算是來拆分鍵控流的，內部使hash來進key的分區，就是根據key去計算，當前key應該分配到哪個subtask中運。1.根據key計算屬于哪個keyGroup計算規則:1)將算并度*1.5后，向上取整到2的n次冪2)跟128也就是2的7次相，取max3)跟2的15次相，

65、取min2.計算KeyGroup屬于哪個subtask需要從runtimeContext上下當中獲取當前線程執的并度，然后按照計算出的keyGroup取模，如現在有5個并度，每個并度分配10個key.結果如下 keyGroupIndex：0 keyGroupRange:0-25 key:4,6,8keyGroupIndex：1 keyGroupRange:26-51 key：9keyGroupIndex：2 keyGroupRange:52-76 key:keyGroupIndex：3 keyGroupRange:77-102 key:0,1keyGroupIndex：4 keyGroupRa

66、nge:103-127 key:2,3,5,7def computeKeyGroupForKeyHash(keyHash:int,maxParallelism:int):keyHash=murmurHash(keyHash)%maxParallelismreturn keyHash#將數據做旋，也就是指定數據要移位到距離int類型最值多少個進制位def rotate_left(value,distance):distance=distance%32return(value (32-distance)#hash散列函數def murmurHash(code:int):code*=0 xcc9e2

67、d51code=(code 17)#替代 Integer.rotateLeftcode*=0 x1b873593code=(code 19)#替代 Integer.rotateLeftcode=code*5+0 xe6546b64code=4code=bitMix(code)if code=0:return codeelif code!=-2147483648:#Integer.MIN_VALUEreturn-codeelse:return 0完整代碼取:https:/ memory，種基于堆外內存。如果當前基于udf的計算過多,flink會調度較多的BeamPythonRunner線程。每個

68、線程會在udf計算的時候，將udf計算所需要的所有內存全部累加。得出最終Python解釋器需要申請的內存。通常flink的管理內存不僅僅于python解釋器的內存占，還會在算進計算的時候做些算本地計算(map,flatmp)，中間狀態的成(如udaf這種聚合操作).不建議pyflink在內存分配的時候將這些操作的內存分配到起.所以這種情況建議將python解釋器的內存分配給堆外內存管理。管理內存優化Python VM與JVM通信的數據量控制JVM作業拓撲圖的上下游絡通信010203pyflink提供了消費者權重 分為三部分配置 (operator,statebackend),python ta

69、skmanager.memory.managed.consumer-weights,OPERATOR:70,STATE_BACKEND:70,PYTHON:30其中operator和statebackend就是上述所說的本地計算以及中間狀態的成在總體的管理內存當中所占的例,python為Python解釋器啟動的時候所占總體內存的在pyflink的計算邏輯當中，udf的部分歸屬于python解釋器所占的計算內存,udf的部分歸屬于jvm所占的計算內存.前開發環境的flink on k8s的tm總體為8g 按照內存計算的分配taskmanager.memory.managed.fraction,0

70、.4taskmanager.memory.jvm-overhead.fraction,work.fraction,0.1taskmanager.memory.framework.off-heap.size,512mbflink內存設置思路:https:/ 上述已經提到,udf的部分歸PVM進計算.udf計算后會將執計劃下推到flink sql當中.通過BeamPythonFunctionRunner執Udf計算python解釋器的內存總和=每個python udf worker的內存總和+python解釋器python udf worker申請的內存=apache beam為udf進序列化傳輸

71、的內存總和調優配置#python每個worker進程緩存的數據條數python.state.cache-size,100000#map狀態讀取map state的最條數,通過后臺志觀測,聚合計算會占HashMapBackendpython.map-state.read-cache-size,100000python.execution-mode,process#從PVM次性發往JVM的數據量python.fn-execution.bundle.size,100000上述所說的流模式+keyby的式，業界普遍的做法是在拿到這個點位的id后 對并度進取模。這種案適于key數量較多 不確定。對下游的

72、處理邏輯沒有過多要求的場景。對我們的場景不適。所以放棄這種做法。想要在保持多點位運的同時，做到多并度的負載均衡。于是調研了window tvf。在絡波動、數據堆積等情況發時，會導致作業偶爾阻塞,這是因為flink算間的絡通信是通過上下游緩沖區的內存決定的.在TM中設置8并度的情況下，查看監控仍然會出現outPool和inputPool波動頻繁的原因，這是因為默認的算間通信的netty,會在個channel當中單位時間內處理兩個buffer。下游算的緩沖區計算：work.memory.buffers-per-channel:8taskmanager.memory.segment-size:512

73、mb#緩沖消脹功能計算 subtask 可能達到的最吞吐（始終保持繁忙狀態時）并且通過調整緩沖數據量來使得數據的消費時間達到配置值。work.memory.buffer-debloat.enabled:true調優配置：法收益:keyby做了負載均衡，將數據打散到了各個分區鍵。但這種適合于keyby的鍵不確定的情況.如現在存在三個key,key1有300個,key2有400個,key3有500個?？梢酝ㄟ^key對并度取余，分攤到不同并度。但是公司的業務中算法作業每次的點位是固定的。也就是說像上圖這種數據分配到個并度的情況會存在。因此這種算法不太適。1.scflink:沒有任何算法插件，這也就意

74、味著這種式是在條算鏈上進連續的transform操作，不存在調完插件再重新拼接作流的操作2.workflow:datastream版本的機器學習作流,作為源的source連接器是通過jdbc的式查詢clickhouse的數據到內存，再條條發往下游3.流模式式:改寫為sql作業進測試在同等實現當中，流模式式work_flow式快上半。式數據數量156w/2d311w/4d624w/8d935wwork_flow 式（s）313.229589.7021151.23620min1816.303scflink 式（s）153.596289.018598.65410min931.176流模式式(s)15

75、0s效率差（%）51514849原先的性能測試當中，都是以并度為1的式本地測試。并且經過溝通,前的scflink和workflow式采取的實現不樣。所以測試報告上存在些不等價的對。上下游鏈路協作的思考數據鏈路中的流轉方式在業互聯的場景當中，每個點位上報的特征值頻率是不樣的(如電波，轉速，噪聲，振動)。且由于業現場的絡及環境復雜性，數據缺失也很常，如果需要在個作業對多個點位的數據做聯動的實時計算。探索出以下三種補數據法：select udf(device_id,tp_watermark_time)from (select device_id,tp_watermark_time from iot_

76、kv_main group by device_id)time_series_tmp1）滑動窗為了保證算法最后的樣本分布不會出現右偏分布，應該新增個udf剔除動插值的樣本,返回是否插值的標記?？偨Y:基于時間序列插值補數據，可以動選擇個窗中的空值數據進補全,但法對遲到的數據在下游通過flink的changelog做upsert或者retract保證致性。在udaf數據聚合的時候，基于pands.series進時間序列插值,再通過udtf進轉列并發往下游2)udaf數據聚合+udtf一行轉多行+window tvf 滑動窗口通過flink-faker-connector在flink framewo

77、rk層(尚未進flink算前的時候，從SourceContext動補數據)，從使上來說相當于個單獨的數據源,會在框架層緩存計算狀態(雙指針+滑動窗)，判斷上條數據是否已經到達且指定主鍵。如果到期主鍵致，上條先到達的事件時間戳更新，則發往下游?；趂link本的changelog做致性保證。3)自定義補數連接器算法服務告警服務數據分析報告戶畫像標簽庫:包含每條告警的點位信息，點位所屬的房，該報警所關聯的異動特征值 以時級 天級，周級統計異動的時間區間出現的百分，檢驗法的置信區間。為事件明細庫:異常上報的告警數據，健康度 以及告警的時間，和置信度相關的閾值區間。隨著前告警系統的指標建設.算法告警和

78、數據源報警所關聯的指標不太樣.算法告警的指標會從算法側相關聯,如況為轉速,avgspeed50&load=1.這的兩個指標平均轉速和負載值就是跟轉速有關的派指標。在規則流設置的時候，需要根據算法側定義的指標做動態的drk規則成。每個任務需要根據不同的算法實例做多點位的聯合告警,從上游算法側每個實例的輸出字段當中可以拿到個作業中多個點位的信息，戶可以選擇設置動態keyby,判斷有哪些點位的數據要輸出告警數據。因為告警上游的算法作業，在同個作業運的都是同種算法實例的DAG,所以如果數據流的上游可能來于多個算法實例的topic,需要做多流合并。123如“容忍度”和“報警間隔”這兩個指標。需要記錄經過

79、閾值線的連續告警。需要在”容忍度”這個規則在內存中命中相關事件后，將命中的事件從flink的state中取出按照規則的編排順序進”報警間隔”這個規則的匹配。如果在flink的state當中取不到對應時間區間的數據，則到緩存當中取數。未來與展望未來工作流架構的演進方向未來要做的工作工業數據指標體系的定義告警系統cep的復雜DSL定義ChatBI落地的可能采fury進Java和Python進程之間的序列化，由于本在pickle編碼上已經做了增強(pickle5)當前Apache fury已經完成了flink java側的序列化。在pyflink側需要實現相關的編解碼,以及對接flink的類型系統。

80、相關issue:https:/issues.apache.org/jira/browse/FLINK-36769報警條件:分隔不同等級的報警條件 如果填寫等級超出等級模版,只會取范圍內部的 MinValue 0.7|240 300惡化通知:報警間隔內觸發更等級報警則推送容忍度:超過任意閾值線多少次不會產報警重置策略:持輸7種表達式符號，樣例：觀察正常計數 數據時間間隔 觀察正常計數 0 數據時間間隔=10080 數據正常計數指的是觸發異常值后回落到正常值計數多少次 數據時間間隔是從次關機到下次開機的時間間隔 滿條件之后重置計數1.先定義個名為alert的Pattern，該Pattern的作就是

81、過濾出錯誤率于0.7的數據，2.times(3),表示要匹配三次，也就是要三次于0.7。3.consecutive 表示上述的三次匹配要是連續的，如0.75、0.8、0.78，只有類似這樣的數據才能被匹配到，中間不能有不符合的數據出現。4.followedBy表示該alert pattern的下要跟著個recovery pattern，followedBy是寬松匹配，也就是兩個模式之間可以有其他的數據，如果要采嚴格匹配，是使next。5.最后recovery pattern加上個optional 是我為了區分報警，和報警恢復想的的個案，這樣的話，如果是只匹配到了alert pattern，輸出

82、的就是報警，如果recovery pattern也匹配到了，那么就是報警恢復。定義個Pattern，于匹配相關的數據質量閾值 Pattern pattern=Pattern.begin(alert).where(new IterativeCondition()Override public boolean filter(Result i,Context context)throws Exception return i.getErrorRate()0.7D;).times(3).consecutive().followedBy(recovery).where(new IterativeCond

83、ition()Override public boolean filter(Result i,Context context)throws Exception return i.getErrorRate()B(attribute=30)(3s)規則轉換(施中):https:/ 級標簽：房,設備,點位 級標簽:設備的部件(如軋機，存在電機，輪箱)注:這的軋機是否是設備的個部件，現場怎么部署，呈什么序顯示 三級標簽:需要參考前智能運維平臺上質檢的駕駛艙(產線-軋機)的結構是怎么成的分析結果類型:頻譜分析 FFT快速傅葉變換(分為兩個域:時域和頻域)時域:聲頻信號被分解為若正弦波,設置不同頻率的信號

84、(低,)，可增強特定頻段,移除噪聲 頻域:將組聲根據不同頻段轉化為赫茲(聲的不同分)歸因的標:輸出按時，周級上報的頻段，以及異常的波動趨勢,以及相關的健康度等級告警由于機器學習作流的最終的是為了輸出狀態檢測報告和數據分析報告。如果期望提供給戶些維護建議，結合當下的RAG來實現或許是種選擇。但是需要聯或者通過權威檔進分詞。對我們這種預測性維護的場景不太靠譜。當下chatBI可以根據建的標簽庫做到動歸因，也是未來要探索的個向。感謝公司研發部，設計部的同事協助。感謝好友shopee的潘鵬師和pyflink維護者之付典師在此過程中的幫助。謝謝會給這個平臺讓我展示公司的業務和未來規劃。歡迎家關注碩橙科技。THANK YOU謝 謝 觀 看