概述
在物流系統相關的大屏中,供應鏈大屏復雜度較高,數據鏈路較長,穩定性要求較高,當前大屏已經經過2年時間的打磨,整體表現已經相對比較成熟穩定。
本文描述了物流供應鏈業務較復雜的業務場景下,結合了大數據計算相關技術,總結了實時監控大屏指標建設和服務構建的框架和經驗,為后續其他核心大屏的高可用和高實時性建設提供建設思路。以下幾點需要重點關注:
1、基于Flink的數據加工鏈路和OLAP的數據分析引擎
基于目前較為成熟的實時計算Flink,結合ClickHouse搭建基礎模型,借助雙流和EasyData實現一鍵切換。
2、指標的一致性
加工和展示分離,可基于單倉原子指標進行區域和品類上卷,既保障了指標的維度一致性(單倉-區域-全國),又保障了同一個數據版本的時間一致性。
同時借助緩存庫/表,來滿足不同的業務場景。
3、穩定性建設
?數據鏈路的穩定性
?接口服務的兜底
?指標準確性的驗證機制
?重算機制
本文內容有限,很多設計的小細節未能體現,感興趣的可隨時與我交流,希望上述內容對正在從事大屏建設的同學有一些新的啟發和思考。
一、背景
供應鏈大屏是供應鏈事業部重要的看數工具,尤其在大促期間,為業務管理層掌握大促實時動態提供了支撐,為事業部的目標達成、排產提供重要的數據支持。
特點:
?指標較多,170+;
?刷新頻率,1分鐘;
?數據來源較多,大件、逆向、冷鏈、服務+、Udata、離線等;
?鏈路長:10+個計算傳輸節點
?重要性高,穩定性要求高,準確性要求高;
二、方案
2.1 數據模型存儲選型
供應鏈大屏涉及模型較多,消息量較大,對寫入性能和查詢性能要求較高,主要基于Elasticsearch和ClickHouse進行對比選型,對比項如下:
比較項 | Elasticsearch | ClickHouse |
實現原理 | 基于Lucene的分布式搜索引擎,ES通過分布式技術,利用分片與副本機制,解決了集群下搜索性能與高可用的問題。 | 基于MPP(Massively Parallel Processing)架構的分布式ROLAP(關系OLAP)分析引擎,擁有完備的管理功能,是列式數據庫管理系統(DBMS)。通過使用日志合并樹,稀疏索引和向量化執行引擎(CPU的SIMD單指令多數據)充分發揮了硬件優勢,實現高效的計算。 |
寫入性能 | 中等,有寫入延遲問題 | 較高,吞吐量大,經測試是ES的5倍以上 |
查詢性能 | 中等 | 高,經測試查詢速度比ES快5-30倍以上 |
多表聯合查詢 | 不支持 | 支持 |
服務器成本 | 高 | 相同數據占用的磁盤空間只有ES的1/3到1/30,節省了磁盤空間的同時,也能有效的減少磁盤IO;另一方面ClickHouse比ES占用更少的內存,消耗更少的CPU資源 |
SQL查詢 | 不支持 | 支持 |
高并發支持 | 較好,經過優化可以支持上萬QPS | 官方建議qps為100 |
全文檢索 | 支持 | 不支持 |
由上面的比較可以看出,作為OLAP數據庫,CH的寫入,查詢性能都優于ES,但是唯一的問題是高并發支持問題。所以對于不需要高并發和全文檢索的場景,選擇CH是更合適的。針對某些需要高并發的場景,可以選擇ES,或者CH+緩存層實現。
?
2.2 整體架構
?
由于數據來源多、復雜度高,為了提升指標服務的穩定性,降低代碼復雜度提升可維護性,提升指標的復用性,整體架構分5層,包括模型加工層、數據處理層、單倉指標加工層、區域指標加工層和展示層。各層的職責如上圖所示。
2.3 指標分層及一致性設計
以倉訂單相關指標為例,所有指標加工保持1套邏輯,同一主任務觸發,加工完成之后,基于單倉指標上卷加工區域等更高維度的指標,保證指標數據的一致性。
針對不同的業務報表,根據不同的場景,進行指標查詢,通過指標緩存表的方式,減少數據量,提升指標的查詢性能。
?
2.4 穩定性設計
由于數據鏈路長,穩定性較差,問題主要集中在Flink、CH環節,恢復周期長。對于大屏等核心任務,數據的實時性和準確性要求較高,以下是歷史發生過的問題:
?CK分區太多,寫入阻塞
?CK rename操作,節點太多,表結構同步慢,導致寫入報錯,大量消息積壓,丟消息
?Flink機房網絡故障
?flink 偶發丟消息,未定位到原因
?checkpoint失敗
?jdq分片不均,單個分區消息增加400倍,消息積壓
?維表數據未更新,導致丟失字段
?上游運單模型積壓,丟失部分字段
?數據積壓
?加工邏輯復雜,偶發亂序問題
?state未保存,丟數據
?CK跨分區字段查詢明細,性能較低
?代碼編寫使用了Flink序列化未支持的格式、循環過多,導致算子背壓嚴重
?邏輯復雜,上線風險高且回滾困難
從整個鏈路中,針對易出問題的flink-CK鏈路進行雙流,物理隔離,遇到問題可一鍵切換至備流。
?
?
?
2.5 擴展性設計
基于UCC配置,通過配置靈活適配業務訴求,節約開發成本,方便定位問題和恢復;
包括4H/24H/28H、同環比日期配置、預測日期配置、單倉兜底配置、展示配置等;
(1)28小時模式配置化:可通過配置將任意一天切換為28小時、4小時模式,為業務和研發側提供了充分的線上驗證機會;
(2)閾值開關配置化:可通過閾值開關進行數據兜底邏輯管控,確保數據平穩;
(3)自動刷新白名單配置化:靈活配置大屏自動刷新白名單,支持封版期間人員白名單權限控制;
(4)歷史日期配置化:計算預測全天指標使用指定歷史日期的單量占比作為對比項,數據庫里包含部分歷史大促日單量數據,可靈活配置修改對比的歷史日期;
(5)重算機制:可基于某一時間段進行數據重算。
?
參數配置:
?
{ "thresholdEnable": "false", //大促預測上下線是否開啟,開啟后upperLimit與lowerLimit生效, "upperLimit": "1.6d", //上限 "lowerLimit": "0.6d", //下限 "zyShowFlag": true, //中小件產品維度-自營是否展示開關 "swShowFlag": true, //中小件產品維度-商務是否展示開關 "jjShowFlag": true, //中小件產品維度-經濟是否展示開關 "wdShowFlag": true, //中小件產品維度-外單是否展示開關 "todayTradeCleanRateShowFlag": true, //今日交易清理率展示開關 "promotionTradeCleanRateShowFlag": true,//大促交易清理率展示開關 "isDebug": true, //是否debug,目前還沒使用 "isCacheOn": true, //是否打開緩存,默認開 "isWriteMinuteAndHour": true, //是否雙寫分鐘表和小時表,代表是否寫 wms_order_analysis_report_minute_2023 和 wms_order_analysis_report_hour_2023 "isMinuteWrite": true, //是否寫分鐘表wms_order_analysis_report_minute_2023 開關 "isHourWrite": true, //是否寫wms_order_analysis_report_hour_2023 開關 "isMinuteNotice": false, //是否分鐘表寫完發mq "isHourNotice": false,//是否小時表寫完發咚咚推送mq }
?
對比策略配置:
{ "sTime": "2023-06-17 00:00:00", // 大屏策略時間開始 "eTime": "2023-06-17 19:59:59", // 大屏策略時間結束 "tbSTime": "2022-06-17 00:00:00", //同比開始 "tbETime": "2022-06-17 19:59:59",//同比結束 "hbSTime": "2022-11-10 00:00:00",//環比開始 "hbETime": "2022-11-10 19:59:59",//環比結束 "showType": "24h",//類型,24h同20h小時,都可以 "special24hCompDateStr": "2022-06-17",//大促24h特殊對比日期,(4h,28h不使用) 主要影響預測;主要用作非 4h/28h 的預測不使用昨日了; "specialCompDateStr": "" //大促4h/28h預測對比天數 }
2.6 數據監控
多種驗證及監控手段組合保證數據準確性
1)前端自動化模型,定時截取每個大屏關鍵節點截圖。
2)自動化抓包,分鐘級記錄接口調用情況,結合定時截圖,便用問題排查及定位。
3)大屏結果分鐘級落庫,并通過Grafana,創建大屏數據監控看板,持續監控大屏數據,通過異常拐點發現問題點,避免遺漏問題。并結合不同看板分析數據趨勢及變化原因。
4)結合大屏計算邏輯,通過京東動力搭建測試模型,做到自由指定時間計算大屏指標明細,驗證分析大屏數據。
?審核編輯 黃宇
-
監控
+關注
關注
6文章
2208瀏覽量
55199 -
供應鏈
+關注
關注
3文章
1675瀏覽量
38895 -
數據鏈
+關注
關注
2文章
39瀏覽量
15787
發布評論請先 登錄
相關推薦
評論