Part 01

背景介紹 

城市物聯網實時數倉主要解決政務運營管理以及數據共享問題，其業務場景方面包含：物聯平臺基礎統計信息，如用戶總數、設備總數、產品總數、行業總數等；實時設備行為，如實時在線數、設備活躍率、實時設備告警數等；運營管理相關統計，如共享接口被訪問次數、部門新增設備數、接口數據量等。

技術方面，主要基于Hadoop開源技術棧，主要分為數據源層、數據采集層、離線計算與實時計算層、數據集市層、分析存儲層、數據服務層等。其中數據源層：包括物聯網OLTP業務數據、日志數據、網關調用數據；數據采集層：基于DataX，Flume，FileBeat等各服務業務之間的數據匯聚、融合等問題，將不同系統的數據相互打通，實現數據歸集；離線計算：利用Hive/Spark高可擴展的批處理能力承擔離線數倉的ETL和數據模型加工；實時計算層：利用Flink/Spark Streaming 完成實時數據的ETL（包括維度擴充，多流Join，實時匯總）等；數據集市層：使用數倉分層模型構建ODS、DWD、DWS、DIM、DWT、ADS；分析存儲層：主要依賴Clickhouse、ElasticSearch、HBase、MySQL、提供OLAP查詢能力；數據服務層：該層通過提供BI分析產品、數據服務接口、統計報表，向運營管理人員提供數據分析決策能力。

Part 02

原有架構痛點 

在資源不受限情況下，無論是基于Hive、Spark的離線計算、基于Flink、Spark 的實時計算，還是基于HDFS的存儲，基于數倉分層模型建設等方案都已基本成熟。但是在OLAP領域，目前還沒有統一的技術棧。在城市物聯網實時分析中不斷探索，問題總結大致如下：

（一）資源運維成本

城市物聯網客戶主要面向政府，部署處于內網，私有云部署，資源相對緊張，并且大多自建統一的大數據平臺，不太允許物聯網平臺搭建傳統的Hadoop/Spark/HBase集群，部署運維非常頭痛。OLAP引擎易部署，易維護，極簡的架構就顯得額外的重要。

（二）技術成本

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

（三）開發成本

城市物聯網的數據分析場景大致可以分為：離線T+1批處理、實時更新分析場景。

• 批處理場景

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

• 實時更新場景

實時更新場景主要業務是監控設備等信息，如實時上報數據量、實時設備接入量、設備告警等信息，為運營管理者提供有效的數據支撐。

針對數據為實時（秒級）更新的場景，采用Lambda 架構，基于相同的主鍵，采用Flink實現基于窗口、多流JOIN的與計算，并將流計算與批計算的結果數據，基于相同的主鍵進行合并。

Part 03

選擇StarRocks的原因 

StarRocks（前DorisDB）架構設計融合了MPP數據庫，以及分布式系統的設計思想，具架構精簡，同時支持全面向量化引擎、智能查詢優化、高效更新、智能物化視圖、標準SQL、流批一體、高可用易擴展等特性，天然的解決了上述的問題。

• 強大的生態

圖片

Starrocks對主流數據分析組件都有良好的支持，如可以使用StarRocks建立ElasticSearch的外表，為ElasticSearch提供SQL查詢的能力，減少數據采集環節，減少資源開銷，更加符合城市物聯網資源緊張需求。

• 引擎歸一化

城市物聯網平臺涉及的多維分析，高并發查詢，預計算，實時分析，即席查詢查詢等場景下基本上可以使用一套StarRocks解決，解決維護多種技術組件的使用成本。

• 替換大寬表模型

StarRocks支持Broadcast Join、Colocate Join等分布式Join的特性，可以在查詢性能可接受的范圍內，使用星型模型替代大寬表模型，節約提前關聯的開發成本，同時針對事實表中歷史數據變更，需要重跑的場景，可以只重跑部分表的數據，提高整體的跑數效率；

• 簡化預聚合部分

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

• 支持模型持續迭代

針對已在線上運行的模型，如果有需求上的變更，比如增加、刪除、變更字段，可以使用StarRocks簡單SQL命令動態地修改表的定義，在表結構變更的過程中，線上的服務不受任何的影響，對于業務模型不確定場景，益處相當巨大。

• 物化視圖

StarRocks支持對原表構建物化視圖，數據更新的時候，物化視圖跟隨原表一起進行更新，保證數據的一致性。當用戶查詢時，并不感知物化視圖的存在，不必顯式的指定物化視圖的名稱，查詢優化器可以根據查詢條件自動判斷是否可以路由到相應的物化視圖上。

Part 04

實踐經驗 

基于目前已經在多層級離線指標分析、即席查詢分析、實時API監控等場景中探索Starrocks，總結出以下經驗：

（一）優化表結構定義

1.模型選擇

StarRocks的模型包括明細模型、聚合模型、更新模型。

如果需要對原始的數據（比如設備表，產品表，物模型表等）來進行分析，可以選擇明細模型。

業務分析匯總類查詢，比如sum、count、 max等類型的查詢，可以選擇聚合模型，提前進行預聚合（比如用戶總設備數），查詢的時候直接獲取結果。

如果數據需要頻繁的進行狀態更新（比如設備在線狀態），可以選擇更新模型。

2.分區和分桶

StarRocks可以對表進行分區和分桶，分區在邏輯上把表劃分成了多個子表，可以按照時間進行分區；分桶可以按照不同的策略將數據劃分為不同的tablet，分布在不同的BE節點上。

3.索引優化

為了提高查詢的性能，可以對StarRocks的表結構額外構建索引。稀疏索引：可以將查詢中常見的過濾字段放在Schema的前面, 區分度越大，頻次越高的查詢字段越往前放；同時對區分度比較大的列構建Bloomfilter；對區分度不大的列構建Bitmap Index；

4.物化視圖

針對實際查詢場景中經常用到的查詢SQL，可以對原始表構建物化視圖，其本質為原始表的一個物化索引，通過物化視圖提前進行索引排序、指標預計算，查詢的時候自動路由到物化視圖進行查詢；

5.去重優化

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

（二）優化查詢SQL

1.JOIN優化

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

2.CBO優化器

針對復雜即席查詢場景，可以開啟StarRocks的基于成本（Cost-based Optimizer ，CBO）的查詢規劃器，在眾多查詢計劃空間中快速找到最優計劃，提高查詢優化器；

（三）數據集成

通過Routine Load或者Stream Load訂閱Kafka數據實時將設備上報數據，告警數據實時同步到StarRocks，減少Flink采集數據額外開銷成本，便于日常維護。

Part 05

后續規劃 

城市物聯網項目目前需要適配國產化信創環境，而Starrocks目前對國產化操作系統有了較好的支持，后續需要在國產化環境下驗證，大數據量，高并發場景下，Starrocks實時數據分析的兼容性、穩定性以及性能情況。