中移物联网作为中国移动通信集团有限公司出资成立的全资子公司 。 公司按照中国移动整体战略布局 ， 围绕物联网业务服务的支撑者、专用模组和芯片的提供者、物联网专用产品的推动者的战略定位 ， 专业化运营物联网专用网络 ， 设计生产物联网专用模组和芯片 ， 打造车联网、智能家居、智能穿戴等特色产品 ， 开发运营物联网连接管理平台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亿 。

稿源：(中国资讯报道网)

【傻大方】网址：http://www.shadafang.com/c/111295O612021.html

标题：中国资讯报道网|在中移物联网PGW实时会话业务领域的应用