背景介紹

城市物聯(lián)網(wǎng)實(shí)時(shí)數(shù)倉(cāng)主要解決政務(wù)運(yùn)營(yíng)管理以及數(shù)據(jù)共享問(wèn)題，其業(yè)務(wù)場(chǎng)景方面包含：物聯(lián)平臺(tái)基礎(chǔ)統(tǒng)計(jì)信息，如用戶總數(shù)、設(shè)備總數(shù)、產(chǎn)品總數(shù)、行業(yè)總數(shù)等；實(shí)時(shí)設(shè)備行為，如實(shí)時(shí)在線數(shù)、設(shè)備活躍率、實(shí)時(shí)設(shè)備告警數(shù)等；運(yùn)營(yíng)管理相關(guān)統(tǒng)計(jì)，如共享接口被訪問(wèn)次數(shù)、部門新增設(shè)備數(shù)、接口數(shù)據(jù)量等。

技術(shù)方面，主要基于Hadoop開(kāi)源技術(shù)棧，主要分為數(shù)據(jù)源層、數(shù)據(jù)采集層、離線計(jì)算與實(shí)時(shí)計(jì)算層、數(shù)據(jù)集市層、分析存儲(chǔ)層、數(shù)據(jù)服務(wù)層等。其中數(shù)據(jù)源層：包括物聯(lián)網(wǎng)OLTP業(yè)務(wù)數(shù)據(jù)、日志數(shù)據(jù)、網(wǎng)關(guān)調(diào)用數(shù)據(jù)；數(shù)據(jù)采集層：基于DataX，F(xiàn)lume，F(xiàn)ileBeat等各服務(wù)業(yè)務(wù)之間的數(shù)據(jù)匯聚、融合等問(wèn)題，將不同系統(tǒng)的數(shù)據(jù)相互打通，實(shí)現(xiàn)數(shù)據(jù)歸集；離線計(jì)算：利用Hive/Spark高可擴(kuò)展的批處理能力承擔(dān)離線數(shù)倉(cāng)的ETL和數(shù)據(jù)模型加工；實(shí)時(shí)計(jì)算層：利用Flink/Spark Streaming 完成實(shí)時(shí)數(shù)據(jù)的ETL（包括維度擴(kuò)充，多流Join，實(shí)時(shí)匯總）等；數(shù)據(jù)集市層：使用數(shù)倉(cāng)分層模型構(gòu)建ODS、DWD、DWS、DIM、DWT、ADS；分析存儲(chǔ)層：主要依賴Clickhouse、ElasticSearch、HBase、MySQL、提供OLAP查詢能力；數(shù)據(jù)服務(wù)層：該層通過(guò)提供BI分析產(chǎn)品、數(shù)據(jù)服務(wù)接口、統(tǒng)計(jì)報(bào)表，向運(yùn)營(yíng)管理人員提供數(shù)據(jù)分析決策能力。

原有架構(gòu)痛點(diǎn)

在資源不受限情況下，無(wú)論是基于Hive、Spark的離線計(jì)算、基于Flink、Spark 的實(shí)時(shí)計(jì)算，還是基于HDFS的存儲(chǔ)，基于數(shù)倉(cāng)分層模型建設(shè)等方案都已基本成熟。但是在OLAP領(lǐng)域，目前還沒(méi)有統(tǒng)一的技術(shù)棧。在城市物聯(lián)網(wǎng)實(shí)時(shí)分析中不斷探索，問(wèn)題總結(jié)大致如下：

（一）資源運(yùn)維成本

城市物聯(lián)網(wǎng)客戶主要面向政府，部署處于內(nèi)網(wǎng)，私有云部署，資源相對(duì)緊張，并且大多自建統(tǒng)一的大數(shù)據(jù)平臺(tái)，不太允許物聯(lián)網(wǎng)平臺(tái)搭建傳統(tǒng)的Hadoop/Spark/HBase集群，部署運(yùn)維非常頭痛。OLAP引擎易部署，易維護(hù)，極簡(jiǎn)的架構(gòu)就顯得額外的重要。

（二）技術(shù)成本

由于數(shù)據(jù)源類型不同，中間件不同，城市數(shù)據(jù)中先后嘗試過(guò)了MySQL、HBase、ElasticSearch、Clickhouse等OLAP引擎以及Flume，DataX，Sqoop，Spark，Hive等組件。但是隨著技術(shù)棧增多，項(xiàng)目增長(zhǎng)，維護(hù)成本，人力技能要求越來(lái)越高，維護(hù)越來(lái)越難。

（三）開(kāi)發(fā)成本

城市物聯(lián)網(wǎng)的數(shù)據(jù)分析場(chǎng)景大致可以分為：離線T+1批處理、實(shí)時(shí)更新分析場(chǎng)景。

批處理場(chǎng)景

城市物聯(lián)網(wǎng)平臺(tái)數(shù)據(jù)分析其核心的功能是基于部門、用戶、產(chǎn)品、設(shè)備、物模型上報(bào)、告警等屬性，提供多維度篩選條件，針對(duì)物聯(lián)網(wǎng)平臺(tái)資產(chǎn)信息進(jìn)行統(tǒng)計(jì)分析。針對(duì)數(shù)據(jù)更新為 T+1 的分析場(chǎng)景，探索使用的分析引擎為 Clickhouse。利用Clickhouse構(gòu)建大寬表模型，對(duì)外提供單表聚合的SQL查詢，以及通過(guò)構(gòu)建DWT主題寬表，提供即席查詢；該場(chǎng)景面臨的問(wèn)題是：雖然Clickhouse單表查詢強(qiáng)悍，但是JOIN能力不強(qiáng)，需要提前進(jìn)行關(guān)聯(lián)，將多表關(guān)聯(lián)成單表，會(huì)存在額外的開(kāi)發(fā)成本，并且Clickhouse支持的并發(fā)查詢能力較低。

實(shí)時(shí)更新場(chǎng)景

實(shí)時(shí)更新場(chǎng)景主要業(yè)務(wù)是監(jiān)控設(shè)備等信息，如實(shí)時(shí)上報(bào)數(shù)據(jù)量、實(shí)時(shí)設(shè)備接入量、設(shè)備告警等信息，為運(yùn)營(yíng)管理者提供有效的數(shù)據(jù)支撐。

針對(duì)數(shù)據(jù)為實(shí)時(shí)（秒級(jí)）更新的場(chǎng)景，采用Lambda 架構(gòu)，基于相同的主鍵，采用Flink實(shí)現(xiàn)基于窗口、多流JOIN的與計(jì)算，并將流計(jì)算與批計(jì)算的結(jié)果數(shù)據(jù)，基于相同的主鍵進(jìn)行合并。

選擇StarRocks的原因

StarRocks（前DorisDB）架構(gòu)設(shè)計(jì)融合了MPP數(shù)據(jù)庫(kù)，以及分布式系統(tǒng)的設(shè)計(jì)思想，具架構(gòu)精簡(jiǎn)，同時(shí)支持全面向量化引擎、智能查詢優(yōu)化、高效更新、智能物化視圖、標(biāo)準(zhǔn)SQL、流批一體、高可用易擴(kuò)展等特性，天然的解決了上述的問(wèn)題。

強(qiáng)大的生態(tài)

Starrocks對(duì)主流數(shù)據(jù)分析組件都有良好的支持，如可以使用StarRocks建立ElasticSearch的外表，為ElasticSearch提供SQL查詢的能力，減少數(shù)據(jù)采集環(huán)節(jié)，減少資源開(kāi)銷，更加符合城市物聯(lián)網(wǎng)資源緊張需求。

引擎歸一化

城市物聯(lián)網(wǎng)平臺(tái)涉及的多維分析，高并發(fā)查詢，預(yù)計(jì)算，實(shí)時(shí)分析，即席查詢查詢等場(chǎng)景下基本上可以使用一套StarRocks解決，解決維護(hù)多種技術(shù)組件的使用成本。

替換大寬表模型

StarRocks支持Broadcast Join、Colocate Join等分布式Join的特性，可以在查詢性能可接受的范圍內(nèi)，使用星型模型替代大寬表模型，節(jié)約提前關(guān)聯(lián)的開(kāi)發(fā)成本，同時(shí)針對(duì)事實(shí)表中歷史數(shù)據(jù)變更，需要重跑的場(chǎng)景，可以只重跑部分表的數(shù)據(jù)，提高整體的跑數(shù)效率；

簡(jiǎn)化預(yù)聚合部分

StarRocks支持明細(xì)、聚合、更新模型，可以基于StarRocks自帶預(yù)聚合的特性，優(yōu)化掉現(xiàn)有Lambda架構(gòu)中的預(yù)聚合部分。StarRocks 直接拉取/訂閱hive或者Kafka中的數(shù)據(jù)，在StarRocks中進(jìn)行聚合運(yùn)算；StarRocks的數(shù)據(jù)模型是聚合模型，通過(guò)最大值、最小值、求和等聚合函數(shù)在StarRocks中進(jìn)行預(yù)聚合。

支持模型持續(xù)迭代

針對(duì)已在線上運(yùn)行的模型，如果有需求上的變更，比如增加、刪除、變更字段，可以使用StarRocks簡(jiǎn)單SQL命令動(dòng)態(tài)地修改表的定義，在表結(jié)構(gòu)變更的過(guò)程中，線上的服務(wù)不受任何的影響，對(duì)于業(yè)務(wù)模型不確定場(chǎng)景，益處相當(dāng)巨大。

物化視圖

StarRocks支持對(duì)原表構(gòu)建物化視圖，數(shù)據(jù)更新的時(shí)候，物化視圖跟隨原表一起進(jìn)行更新，保證數(shù)據(jù)的一致性。當(dāng)用戶查詢時(shí)，并不感知物化視圖的存在，不必顯式的指定物化視圖的名稱，查詢優(yōu)化器可以根據(jù)查詢條件自動(dòng)判斷是否可以路由到相應(yīng)的物化視圖上。

實(shí)踐經(jīng)驗(yàn)

基于目前已經(jīng)在多層級(jí)離線指標(biāo)分析、即席查詢分析、實(shí)時(shí)API監(jiān)控等場(chǎng)景中探索Starrocks，總結(jié)出以下經(jīng)驗(yàn)：

（一）優(yōu)化表結(jié)構(gòu)定義

1.模型選擇

StarRocks的模型包括明細(xì)模型、聚合模型、更新模型。

如果需要對(duì)原始的數(shù)據(jù)（比如設(shè)備表，產(chǎn)品表，物模型表等）來(lái)進(jìn)行分析，可以選擇明細(xì)模型。

業(yè)務(wù)分析匯總類查詢，比如sum、count、 max等類型的查詢，可以選擇聚合模型，提前進(jìn)行預(yù)聚合（比如用戶總設(shè)備數(shù)），查詢的時(shí)候直接獲取結(jié)果。

如果數(shù)據(jù)需要頻繁的進(jìn)行狀態(tài)更新（比如設(shè)備在線狀態(tài)），可以選擇更新模型。

2.分區(qū)和分桶

StarRocks可以對(duì)表進(jìn)行分區(qū)和分桶，分區(qū)在邏輯上把表劃分成了多個(gè)子表，可以按照時(shí)間進(jìn)行分區(qū)；分桶可以按照不同的策略將數(shù)據(jù)劃分為不同的tablet，分布在不同的BE節(jié)點(diǎn)上。

3.索引優(yōu)化

為了提高查詢的性能，可以對(duì)StarRocks的表結(jié)構(gòu)額外構(gòu)建索引。稀疏索引：可以將查詢中常見(jiàn)的過(guò)濾字段放在Schema的前面, 區(qū)分度越大，頻次越高的查詢字段越往前放；同時(shí)對(duì)區(qū)分度比較大的列構(gòu)建Bloomfilter；對(duì)區(qū)分度不大的列構(gòu)建Bitmap Index；

4.物化視圖

針對(duì)實(shí)際查詢場(chǎng)景中經(jīng)常用到的查詢SQL，可以對(duì)原始表構(gòu)建物化視圖，其本質(zhì)為原始表的一個(gè)物化索引，通過(guò)物化視圖提前進(jìn)行索引排序、指標(biāo)預(yù)計(jì)算，查詢的時(shí)候自動(dòng)路由到物化視圖進(jìn)行查詢；

5.去重優(yōu)化

在產(chǎn)品與設(shè)備數(shù)據(jù)上報(bào)次數(shù)，針對(duì)百億級(jí)別數(shù)據(jù)量，使用常規(guī)的方式（COUNT DISTRINCT）去重，其缺點(diǎn)是需要消耗極大的計(jì)算和存儲(chǔ)資源，對(duì)大規(guī)模數(shù)據(jù)集和查詢延遲敏感的去重場(chǎng)景支持不夠友好。通過(guò)定義BITMAP的數(shù)據(jù)類型，可以減少傳統(tǒng)COUNT DISTINCT去重的執(zhí)行需要的內(nèi)存空間、執(zhí)行時(shí)長(zhǎng)；而對(duì)于像API調(diào)用計(jì)算，在允許有部分統(tǒng)計(jì)偏差的前提下，可以定義HyperLogLog的數(shù)據(jù)類型，提高去重效率；

（二）優(yōu)化查詢SQL

1.JOIN優(yōu)化

當(dāng)小表與大表進(jìn)行JOIN的時(shí)候，可以使用 Broadcast JOIN ，該方式可以用于事實(shí)表與維度表進(jìn)行關(guān)聯(lián)查詢；當(dāng)大表與大表進(jìn)行JOIN的時(shí)候，為了加速查詢，相關(guān)表可以采用共同的分桶列進(jìn)行分桶。當(dāng)分桶列相同，相關(guān)表進(jìn)行JOIN操作時(shí)，可以直接在本地進(jìn)行JOIN，再將結(jié)果數(shù)據(jù)進(jìn)行合并，避免數(shù)據(jù)在中間計(jì)算的時(shí)候就在集群中的傳輸，減少數(shù)據(jù)shuffle帶來(lái)的資源開(kāi)銷。

2.CBO優(yōu)化器

針對(duì)復(fù)雜即席查詢場(chǎng)景，可以開(kāi)啟StarRocks的基于成本（Cost-based Optimizer ，CBO）的查詢規(guī)劃器，在眾多查詢計(jì)劃空間中快速找到最優(yōu)計(jì)劃，提高查詢優(yōu)化器；

（三）數(shù)據(jù)集成

通過(guò)Routine Load或者Stream Load訂閱Kafka數(shù)據(jù)實(shí)時(shí)將設(shè)備上報(bào)數(shù)據(jù)，告警數(shù)據(jù)實(shí)時(shí)同步到StarRocks，減少Flink采集數(shù)據(jù)額外開(kāi)銷成本，便于日常維護(hù)。

后續(xù)規(guī)劃

城市物聯(lián)網(wǎng)項(xiàng)目目前需要適配國(guó)產(chǎn)化信創(chuàng)環(huán)境，而Starrocks目前對(duì)國(guó)產(chǎn)化操作系統(tǒng)有了較好的支持，后續(xù)需要在國(guó)產(chǎn)化環(huán)境下驗(yàn)證，大數(shù)據(jù)量，高并發(fā)場(chǎng)景下，Starrocks實(shí)時(shí)數(shù)據(jù)分析的兼容性、穩(wěn)定性以及性能情況。