五分钟技术趣谈 | 基于StarRocks的城市物联网数据分析

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实时数据分析的兼容性、稳定性以及性能情况。

关键词：