摘要：?塑云科技：性能突破，基于KafKa+OTS+MaxCompute 完成了一次物聯(lián)網(wǎng)系統(tǒng)技術(shù)重構(gòu) 背景：創(chuàng)業(yè)團隊，專注于氫能燃料電池生態(tài)鏈的運營支撐，當(dāng)前主要的業(yè)務(wù)組成為新能源車整車實時運營監(jiān)控分析，加氫站實時運營監(jiān)控分析，車輛安全運營支撐。

塑云科技：性能突破，基于KafKa+OTS+MaxCompute?完成了一次物聯(lián)網(wǎng)系統(tǒng)技術(shù)重構(gòu)

背景：創(chuàng)業(yè)團隊，專注于氫能燃料電池生態(tài)鏈的運營支撐，當(dāng)前主要的業(yè)務(wù)組成為新能源車整車實時運營監(jiān)控分析，加氫站實時運營監(jiān)控分析，車輛安全運營支撐。

?

系統(tǒng)面臨的主要挑戰(zhàn)：高頻數(shù)據(jù)的實時解析、存儲、分析。拿整車實時運營監(jiān)控分析來講，每輛車以每秒1K的原始報文上報，要求做到秒級延遲的解析應(yīng)答以及入庫。同時需要針對解析后的每車每秒33K的報文進行快速查詢以及后繼的分析?？紤]到未來車輛接入的量，需要在考慮性能的基礎(chǔ)上以最經(jīng)濟的方式進行系統(tǒng)設(shè)計。按照每車每秒33K的解析后報文，每車每月預(yù)計生成30G的報文數(shù)據(jù)（車輛按照每天運行10小時計算）。

?

原有系統(tǒng)存在的問題如下（羅列部分）：

1.???????系統(tǒng)架構(gòu)中未對OLAP和OLTP系統(tǒng)的范圍進行清晰界定，使用JAVA程序?qū)TS的表定時進行任務(wù)統(tǒng)計，代碼復(fù)雜并且性能極差并且影響到服務(wù)器上其他OLTP系統(tǒng)的正常運行。

2.???????存儲的解析后的報文數(shù)據(jù)，未針對OTS的計價規(guī)則進行針對性優(yōu)化，一個大JSON串中冗余的KEY過多，KEY的長度超長（平均30個字符串）。

3.???????OTS（阿里云tablestore）按照公司進行分表設(shè)計，存在單個實例下表數(shù)量超過OTS限制（64表）的風(fēng)險。

4.???????OTS以車月作為分區(qū)鍵，單個分區(qū)（30G）過大，超過OTS建議的1G推薦大小。

5.???????OTS單車的分區(qū)連續(xù)分布未做散列，不能在物理機器層面最優(yōu)并發(fā)性能。

6.???????沒有針對最核心的讀取場景（按天按車查詢報文）進行編碼層面的優(yōu)化。

在做系統(tǒng)優(yōu)化之前，首先要做的就是架構(gòu)層面的梳理，對產(chǎn)品中需要使用到的中間件產(chǎn)品的適用范圍進行了明確的界定。數(shù)據(jù)在各個環(huán)節(jié)的流轉(zhuǎn)進行明確的定義如下：

這里主要的改進

一、引入KAFKA作為多個環(huán)節(jié)異步解耦的基礎(chǔ)支撐，提升對終端的報文快速回復(fù)。

二、引入MaxCompute?作為OLAP系統(tǒng)的基礎(chǔ)支撐。將復(fù)雜的業(yè)務(wù)分析轉(zhuǎn)交給MaxCompute?來處理。

三、針對OTS的計價原則，對OTS的模型進行了重構(gòu)（此文暫不討論）

?

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

這里首先講一講基于成本的考慮。首先根據(jù)數(shù)據(jù)的使用頻度將數(shù)據(jù)切分為在線、離線、歸檔三類。車輛終端上報的報文數(shù)據(jù)作為歸檔數(shù)據(jù)選擇OSS的歸檔存儲。在線數(shù)據(jù)設(shè)定N月的生命周期，主要包括報文解析之后需要實時查詢的數(shù)據(jù)，離線數(shù)據(jù)主要包括基于解析的報文數(shù)據(jù)進行離線分析統(tǒng)計之后形成的各類中間結(jié)果、報表數(shù)據(jù)。

針對數(shù)據(jù)的使用場景界定數(shù)據(jù)類型之后，這里主要考慮離線數(shù)據(jù)使用OSS還是MaxCompute（ODPS）或者是OTS來存儲的問題。根據(jù)三類產(chǎn)品的存儲計算成本我做了一個粗略對比如下：

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

經(jīng)過測試使用OTS外部表作為數(shù)據(jù)載體的計算性能一般（當(dāng)前MaxCompute對OTS的外部表的Map Reduce計算直覺覺得是基于OTS的分片，并且缺少分區(qū)的概念，每次都是基于全表掃描，這點可以從MaxCompute的任務(wù)詳情可以觀測出來）。

技術(shù)選型確定以后，剩下的是如何利用MaxCompute為業(yè)務(wù)提供可靠、穩(wěn)定數(shù)據(jù)服務(wù)。這里特別需要強調(diào)的是數(shù)倉的建模、數(shù)據(jù)集成、工作運維的使用。

數(shù)據(jù)集成主要這方面主要體現(xiàn)MYSQL跟MaxCompute的雙向同步，這個不需要特別講，主要是設(shè)計上需要考慮到數(shù)據(jù)的重復(fù)同步的設(shè)計即可。關(guān)于工作運維則是更多地體現(xiàn)在對任務(wù)的運行狀況的監(jiān)控以及重跑的支持。

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

在離線統(tǒng)計分析的重構(gòu)完成之后，系統(tǒng)充分利用MaxCompute的并行計算能力，并且借助其強大的函數(shù)尤其是窗口函數(shù)的支持，我們實現(xiàn)比較不錯的分析能力，客戶的一個核心部件的數(shù)據(jù)統(tǒng)計分析，之前一個專業(yè)的工作人員分析一個部分需要耗時一天，還容易出錯。借助平臺的分析能力，可以在10分鐘內(nèi)計算完將近1000個部件的數(shù)據(jù)分析工作。類似下面的曲線圖分析每次數(shù)據(jù)波動期間的均值，之前幾乎無法人工計算，即便是JAVA編碼也是一個非常復(fù)雜的編碼工作，通過平臺的支持，系統(tǒng)處理得游刃有余。

一次計流水賬式的總結(jié)，且當(dāng)做一次經(jīng)驗的沉淀

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載