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

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

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

?

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

?

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

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

2.???????存儲(chǔ)的解析后的報(bào)文數(shù)據(jù)，未針對(duì)OTS的計(jì)價(jià)規(guī)則進(jìn)行針對(duì)性優(yōu)化，一個(gè)大JSON串中冗余的KEY過(guò)多，KEY的長(zhǎng)度超長(zhǎng)（平均30個(gè)字符串）。

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

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

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

6.???????沒(méi)有針對(duì)最核心的讀取場(chǎng)景（按天按車(chē)查詢報(bào)文）進(jìn)行編碼層面的優(yōu)化。

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

這里主要的改進(jìn)

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

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

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

?

MaxCompute作為阿里云強(qiáng)大的數(shù)據(jù)分析利器，因?yàn)橹暗慕?jīng)歷相對(duì)比較熟悉。所以在這次的改造中特別針對(duì)性能、成本、可運(yùn)維等方面做了較多的思考。

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

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

這里已經(jīng)考慮通過(guò)壓縮的方式存儲(chǔ)OTS減少計(jì)價(jià)存儲(chǔ)的情況。當(dāng)然MaxCompute的計(jì)價(jià)是按照實(shí)際壓縮存儲(chǔ)之后的容量計(jì)算。MaxCompute官方文檔介紹的是5:1的壓縮比，而我們的數(shù)據(jù)因?yàn)楸旧淼奶攸c(diǎn)，實(shí)測(cè)可以到7~8 ：1的壓縮比，所以最后數(shù)據(jù)方案反倒是MaxCompute直接存儲(chǔ)離線數(shù)據(jù)性價(jià)比最高。同時(shí)也符合數(shù)據(jù)靠近計(jì)算的原則。

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

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

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

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

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

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

閱讀原文

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