開發與維運

塑雲科技:性能突破,基於KafKa+OTS+MaxCompute 完成了一次物聯網系統技術重構

背景:創業團隊,專注於氫能燃料電池生態鏈的運營支撐,當前主要的業務組成為新能源車整車實時運營監控分析,加氫站實時運營監控分析,車輛安全運營支撐。

系統面臨的主要挑戰:高頻數據的實時解析、存儲、分析。拿整車實時運營監控分析來講,每輛車以每秒1K的原始報文上報,要求做到秒級延遲的解析應答以及入庫。同時需要針對解析後的每車每秒33K的報文進行快速查詢以及後繼的分析。考慮到未來車輛接入的量,需要在考慮性能的基礎上以最經濟的方式進行系統設計。按照每車每秒33K的解析後報文,每車每月預計生成30G的報文數據(車輛按照每天運行10小時計算)。

原有系統存在的問題如下(羅列部分):

  1. 系統架構中未對OLAP和OLTP系統的範圍進行清晰界定,使用JAVA程序對OTS的表定時進行任務統計,代碼複雜並且性能極差並且影響到服務器上其他OLTP系統的正常運行。
  2. 存儲的解析後的報文數據,未針對OTS的計價規則進行針對性優化,一個大JSON串中冗餘的KEY過多,KEY的長度超長(平均30個字符串)。
  3. OTS(阿里雲tablestore)按照公司進行分表設計,存在單個實例下表數量超過OTS限制(64表)的風險。
  4. OTS以車月作為分區鍵,單個分區(30G)過大,超過OTS建議的1G推薦大小。
  5. OTS單車的分區連續分佈未做散列,不能在物理機器層面最優併發性能。
  6. 沒有針對最核心的讀取場景(按天按車查詢報文)進行編碼層面的優化。

在做系統優化之前,首先要做的就是架構層面的梳理,對產品中需要使用到的中間件產品的適用範圍進行了明確的界定。數據在各個環節的流轉進行明確的定義如下:

image.png

這裡主要的改進

一、引入KAFKA作為多個環節異步解耦的基礎支撐,提升對終端的報文快速回復。

二、引入MaxCompute 作為OLAP系統的基礎支撐。將複雜的業務分析轉交給MaxCompute 來處理。

三、針對OTS的計價原則,對OTS的模型進行了重構(此文暫不討論)

MaxCompute作為阿里雲強大的數據分析利器,因為之前的經歷相對比較熟悉。所以在這次的改造中特別針對性能、成本、可運維等方面做了較多的思考。

這裡首先講一講基於成本的考慮。首先根據數據的使用頻度將數據切分為在線、離線、歸檔三類。車輛終端上報的報文數據作為歸檔數據選擇OSS的歸檔存儲。在線數據設定N月的生命週期,主要包括報文解析之後需要實時查詢的數據,離線數據主要包括基於解析的報文數據進行離線分析統計之後形成的各類中間結果、報表數據。

針對數據的使用場景界定數據類型之後,這裡主要考慮離線數據使用OSS還是MaxCompute(ODPS)或者是OTS來存儲的問題。根據三類產品的存儲計算成本我做了一個粗略對比如下:

image.png

這裡已經考慮通過壓縮的方式存儲OTS減少計價存儲的情況。當然MaxCompute的計價是按照實際壓縮存儲之後的容量計算。MaxCompute官方文檔介紹的是5:1的壓縮比,而我們的數據因為本身的特點,實測可以到7~8 :1的壓縮比,所以最後數據方案反倒是MaxCompute直接存儲離線數據性價比最高。同時也符合數據靠近計算的原則。

經過測試使用OTS外部表作為數據載體的計算性能一般(當前MaxCompute對OTS的外部表的Map Reduce計算直覺覺得是基於OTS的分片,並且缺少分區的概念,每次都是基於全表掃描,這點可以從MaxCompute的任務詳情可以觀測出來)。

技術選型確定以後,剩下的是如何利用MaxCompute為業務提供可靠、穩定數據服務。這裡特別需要強調的是數倉的建模、數據集成、工作運維的使用。

數據集成主要這方面主要體現MYSQL跟MaxCompute的雙向同步,這個不需要特別講,主要是設計上需要考慮到數據的重複同步的設計即可。關於工作運維則是更多地體現在對任務的運行狀況的監控以及重跑的支持。

數倉的建模主要考慮的還是成本和模型的複用。首先針對海量、質量不高的底層數據進行分層建模。保證上層的業務模型只依賴中間結果。這裡帶來的直接效益就是計算成本的大幅下降(每每看到有些開發同事動不動就對著一個上百G的原始表做各種查詢的時候,心是痛的…).其次是中間模型為系統補數帶來更快的性能,畢竟因為一些業務或者數據的原因需要重跑部分報表,這個時候如果需要重新掃描原始數據的時候,首先就是費錢,非常費錢。其次就是耗時,非常耗時。

在離線統計分析的重構完成之後,系統充分利用MaxCompute的並行計算能力,並且藉助其強大的函數尤其是窗口函數的支持,我們實現比較不錯的分析能力,客戶的一個核心部件的數據統計分析,之前一個專業的工作人員分析一個部分需要耗時一天,還容易出錯。藉助平臺的分析能力,可以在10分鐘內計算完將近1000個部件的數據分析工作。類似下面的曲線圖分析每次數據波動期間的均值,之前幾乎無法人工計算,即便是JAVA編碼也是一個非常複雜的編碼工作,通過平臺的支持,系統處理得遊刃有餘。

image.png

一次計流水賬式的總結,且當做一次經驗的沉澱

Leave a Reply

Your email address will not be published. Required fields are marked *