StarRocks在中移物联网PGW实时会话业务领域的应用

　　中移物联网作为中国移动通信集团有限公司出资成立的全资子公司。公司按照中国移动整体战略布局，围绕“物联网业务服务的支撑者、专用模组和芯片的提供者、物联网专用产品的推动者”的战略定位，专业化运营物联网专用网络，设计生产物联网专用模组和芯片，打造车联网、智能家居、智能穿戴等特色产品，开发运营物联网连接管理平台OneLink和物联网开放平台OneNET，推广物联网解决方案，形成了五大方向业务布局和物联网“云-网-边-端”全方位的体系架构。

　　本文主要讨论了中移物联网在PGW实时会话业务数据分析与建模方面，利用SparkStreaming和StarRocks进行的探索与实践。并希望我们在实时数仓建模领域的应用实践，能给大家一些启发，也欢迎大家多多交流，给我们提出宝贵的建议。

　　PGW实时会话业务背景介绍

　　中移物联网作为物联网业务领域的支撑者，目前在线物联卡用户达到6.7亿。中移物联网智能连接部大数据团队作为物联卡用户与物联卡之间的数据分析纽带，主要依托物联卡的基础属性数据和使用行为数据通过数仓建模、大数据挖掘等其他手段为用户提供高效的数据服务。

　　PGW实时会话业务主要指的是，通过PGW网元设备实时收集从全球各地传送回来、符合Radius协议的GGSN报文数据，然后通过大数据分析等手段，进行数据建模、数据挖掘等其他子项目。例如为集团客户提供每张物联卡的实时位置和分布情况;通过风险防控模型，对比实时收集的报文数据，为客户提供每张物联卡的风险等级等项目。

　　业务痛点及实时技术的挑战

　　目前该业务在具体落地过程中，以及应用业务对实时数据需求方面，主要存在以下问题和技术难点：

　　1.流式数据join。目前PGW实时会话业务，峰值每秒数据达到35万/s，针对不同的业务需求，往往在数据清洗阶段，需要对流式数据进行字段关联，然后以宽表形式写入;

　　2.存量数据排序、实时分析。一方面因为各地区网元设备的不稳定等其他因素，往往实时传送过来的数据存在乱序问题，另一方面因为单条会话长期在线(最长超过14天)，对于单条会话的实时分析往往需要对存量数据进行排序;

　　3.统一的实时OLAP数据平台构建。我们的用户包括：内部售后团队、运营、产品等内部人员外，还有外部政企平台客户。不同的用户往往关系的数据粒度、时间频率、维度等各不相同。但是我们希望能建立一套统一的实时OLAP数据平台，并提供一套灵活、安全可靠的实时数据服务。

　　目前整个业务的数据规模和业务如下：

　　技术框架的调研与演进

　　1.原有技术框架

　　原有技术框架以及整个PGW实时会话业务的处理流程如上。实时数据通过流处理组件处理后，针对不同需求和业务方，数据存储和展示借助多技术组件。并且大多情况下为满足一个业务需求往往需要多技术组件配合使用。如PGW明细会话查询，往往是借助Redis或ES作为索引组件再去查询Hbase，一方面Hbase只能进行简单的模糊查询，无法做到联邦查询、聚合统计查询，另一方面若统计查询借助Impala+Hive时效性往往很难保证。

　　2.MPP技术框架的调研

　　为解决实时分析的时效性，同时又能保证数据快速写入，并且能够对外提供一个较为统一和简单的OLAP数据平台。我们先后调研了ClickHouse、StarRocks、Kudu。并针对我们的业务分析和业务痛点做了以下测试。

　　ClickHouse：虽然具备较好的OLAP分析性能，但因其底层的架构设计，集群模式下数据写入需开发人员手动指定写入节点以及数据存储目录以保证集群数据平衡。同时集群扩容后很难做到数据自平衡，对运维人员提出较高要求，另一方面由于该数据库不支持事务特性，在数据更新时容易出现数据重复，且不易解决此问题。

　　StarRocks：查询分析性能强悍，多表关联速度比其他产品快很多。与Clickhouse类似，StarRocks目前不支持字段级别的数据更新，同时查询性能与表的设计和集群性能密切相关。原则上集群性能随数据节点线性增长。另外，简便的运维管理也是StarRocks的一大亮点。目前StarRocks开发版本迭代快，需要及时跟进官方的版本进展。

　　Kudu：支持快速数据更新、快速数据分析与即席查询，但是数据量不宜过大，单表数据量不宜超过15亿。

　　性能方面，批量写入性能Clickhouse略优于其他系统，相同资源条件下明细查询性能ClickHouse和StarRocks比Impala+Kudu更快，StarRocks有比较方便的物化视图(Rollup)可以满足统计查询的需求，另外StarRocks在关联查询方面性能有比较明显的优势。

　　综上所述，实时数仓方案，采用Kudu+StarRocks相结合，实现现有PGW实时会话业务。StarRocks作为主要技术组件，Kudu辅助实现字段级别更新业务场景。

　　3.现有技术框架

　　3.1、现有技术框架整体介绍

　　为解决现有的业务痛点，同时平衡在实时数据处理技术实现上的难点。我们摒弃了部分技术组件，采用新的技术组件搭建整个实时数仓用于满足PGW实时会话业务。其中StarRocks可以满足大多场景的需求。

　　PGW会话业务中流式Join问题，一部分我们通过在StarRocks中星型建模的方案的解决，另一部分我们借助关系型内存数据库VoltDB+Google Guava Cache，流式组件处理过程中代码实现。

　　存量数据的排序、实时分析问题。我们借助StarRocksrange分区以及高效的OLAP性能初步缓解。

　　最后统一OLAP分析平台，我们完全借助StarRocks实现。

　　3.2、StarRocks解决的痛点和挑战

　　1.充分利用StarRocks在多表join方面的性能优化，如Colocate Join、内存表等特性。将原来的流式join方案改为通过星型建模方案，在数据服务层进行多表join的联邦查询;

　　2.通过StarRocks动态分区特性对存量数据进行分区，然后利用Bitmap数据类型进行精确去重，然后再在各分区内完成排序。排序的结果进一步汇总到一张数据表中，和实时到来的数据放在一起排序，可以有效地解决数据乱序问题，并且保证数据分析的效率。

　　3.StarRocks可作为数据服务层的统一对外引擎，一方面保证查询性能，另一方面避免了原来多技术组件带来的冗余问题，极大降低了系统的管理成本。

　　4.技术实现方面：替代Hbase部分业务，缓解了Hbase分区分裂带来的性能问题;通过ES外表引擎，解决ES表不能进行join、语法特殊等技术问题。

　　StarRocks在具体项目上的应用及优化

　　目前StarRocks集群总共25台BE，4台FE，存储采用支持采用NVME协议的SSD硬盘。

　　1.PGW用户实时位置轨迹

　　1.1、方案介绍

　　实时收集到的GGSN报文，通过StarRocks的聚合模型，将发生位置变更轨迹的明细数据实时沉淀下来。并对不同的区域维度生成Rollup表。最细粒度到基站级别，然后生成省、地市级别的Rollup表以供不同业务查询。

　　GGSN报文量35万/s，通过SparkStreaming处理解析后，每1分钟StreamLoad一次入StarRocks。

　　1.2、方案优化

　　最开始因为Rollup表建了省、地市、区县、乡镇，导致在写入时IO负担过大，写入速度跟不上数据推送，SparkStreaming出现挤压，后期通过性能测试Rollup表只建立了省、地市维度。同时新增一张乡镇base表，并在其基础上建立区县Rollup表。

　　同时为保证查询的时效性,base表Rollup表前缀索引在字段类型和选择上按照官方建议，避免使用Varchar类型。

　　2.区域会话明细模型

　　2.1、项目背景

　　数据服务层需对外提供每张物联卡，统一会话发生位置变更后在不同区域的套餐使用情况，会话时常等信息。进而统计物联卡各区域的漫入漫出情况。

　　2.2、项目方案

　　实时收集到的GGSN报文，通过StarRocks的聚合模型，将发生位置变更时的套餐记录，变更时间沉淀下来。然后通过定时任务，从聚合模型明细数据中计算出套餐使用情况，会话时长，生成新的DWD表。StarRocks目前的物化视图很有用，但还不是很灵活，比如，只支持明细数据表模型，并且支持单表创建物化视图，不支持多表Join构建物化视图。

　　StarRocks在中移物联网PGW实时会话业务领域的展望

　　一方面我们目前了解到，StarRocks开发团队，目前正在解决StarRocks字段级别无法支持更新的短板。在未来StarRocks升级过程中，我们可能会摒弃掉Kudu,完全借助StarRocks实现实时数仓技术架构。

　　另一方面，我们期待StarRocks物化视图的灵活性更高，可以支持Join级别的物化视图和不同表引擎的物化视图。除此之外，在接下来的项目开发过程中我们也计划进一步使用bitmap索引、Colocation Join等更丰富的功能提高我们的查询速度。

　　除此之外，为了完善实时数仓的分层结构，我们计划在未来使用Flink来对接StarRocks，保证数仓的分层结构，同时进一步完善统一的OLAP数据分析平台。(作者：宁彦辉中移物联网大数据开发工程师，主要从事流计算开发、物联网机器学习数据挖掘以及OLAP查询引擎数据开发)