共计 3882 个字符，预计需要花费 10 分钟才能阅读完成。
编者按：自从 2021 年 1 月份推出收费的 StarRocks 标准版产品后，咱们的客户量呈现了爆发式的增长。到目前为止，曾经有数十家客户在生产环境正式上线了 StarRocks，并且有数百家客户正在进行实在业务场景的测试。咱们邀请了局部已上线的客户，分享他们的数据分析教训。这个系列的文章波及多个行业，将在将来继续输入，敬请关注。
“作者：宁彦辉，
中移物联网大数据开发工程师，次要从事流计算开发、物联网机器学习数据挖掘以及 OLAP 查问引擎数据开发”
中移物联网作为中国移动通信集团有限公司出资成立的全资子公司。公司依照中国移动整体策略布局，围绕“物联网业务服务的撑持者、专用模组和芯片的提供者、物联网专用产品的推动者”的策略定位，专业化经营物联网专用网络，设计生产物联网专用模组和芯片，打造车联网、智能家居、智能穿戴等特色产品，开发经营物联网连贯治理平台 OneLink 和物联网开放平台 OneNET，推广物联网解决方案，造成了五大方向业务布局和物联网“云 - 网 - 边 - 端”全方位的体系架构。
本文次要探讨了中移物联网在 PGW 实时会话业务数据分析与建模方面，利用 SparkStreaming 和 StarRocks 进行的摸索与实际。并心愿咱们在实时数仓建模畛域的利用实际，能给大家一些启发，也欢送大家多多交换，给咱们提出贵重的倡议。
PGW 实时会话业务背景介绍
中移物联网作为物联网业务畛域的撑持者，目前在线物联卡用户达到 6.7 亿。中移物联网智能连贯部大数据团队作为物联卡用户与物联卡之间的数据分析纽带，次要依靠物联卡的根底属性数据和应用行为数据通过数仓建模、大数据挖掘等其余伎俩为用户提供高效的数据服务。
PGW 实时会话业务次要指的是，通过 PGW 网元设施实时收集从寰球各地传送回来、合乎 Radius 协定的 GGSN 报文数据，而后通过大数据分析等伎俩，进行数据建模、数据挖掘等其余子项目。例如为团体客户提供每张物联卡的实时地位和散布状况；通过危险防控模型，比照实时收集的报文数据，为客户提供每张物联卡的危险等级等我的项目。
业务痛点及实时技术的挑战
目前该业务在具体落地过程中，以及利用业务对实时数据需要方面，次要存在以下问题和技术难点：
- 流式数据 join。目前 PGW 实时会话业务，峰值每秒数据达到 35 万 /s，针对不同的业务需要，往往在数据荡涤阶段，须要对流式数据进行字段关联，而后以宽表模式写入；
- 存量数据排序、实时剖析。一方面因为各地区网元设施的不稳固等其余因素，往往实时传送过去的数据存在乱序问题，另一方面因为单条会话长期在线(最长超过 14 天），对于单条会话的实时剖析往往须要对存量数据进行排序；
- 对立的实时 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，流式组件处理过程中代码实现。
存量数据的排序、实时剖析问题。咱们借助 StarRocks range 分区以及高效的 OLAP 性能初步缓解。
最初对立 OLAP 剖析平台，咱们齐全借助 StarRocks 实现。
3.2 StarRocks 解决的痛点和挑战
- 充分利用 StarRocks 在多表 join 方面的性能优化，如 Colocate Join、内存表等个性。将原来的流式 join 计划改为通过星型建模计划，在数据服务层进行多表 join 的联邦查问；
- 通过 StarRocks 动静分区个性对存量数据进行分区，而后利用 Bitmap 数据类型进行准确去重，而后再在各分区内实现排序。排序的后果进一步汇总到一张数据表中，和实时到来的数据放在一起排序，能够无效地解决数据乱序问题，并且保障数据分析的效率。
- StarRocks 可作为数据服务层的对立对外引擎，一方面保障查问性能，另一方面防止了原来多技术组件带来的冗余问题，极大升高了零碎的治理老本。
- 技术实现方面：代替 Hbase 局部业务，缓解了 Hbase 分区决裂带来的性能问题；通过 ES 表面引擎，解决 ES 表不能进行 join、语法非凡等技术问题。
StarRocks 在具体我的项目上的利用及优化
目前 StarRocks 集群总共 25 台 BE，4 台 FE，存储采纳反对采纳 NVME 协定的 SSD 硬盘。
PGW 用户实时地位轨迹
1、计划介绍
实时收集到的 GGSN 报文，通过 StarRocks 的聚合模型，将产生地位变更轨迹的明细数据实时积淀下来。并对不同的区域维度生成 Rollup 表。最细粒度到基站级别，而后生成省、地市级别的 Rollup 表以供不同业务查问。
GGSN 报文量 35 万 /s，通过 SparkStreaming 解决解析后，每 1 分钟 StreamLoad 一次入 StarRocks。
2、计划优化
最开始因为 Rollup 表建了省、地市、区县、乡镇，导致在写入时 IO 累赘过大，写入速度跟不上数据推送，SparkStreaming 呈现挤压，前期通过性能测试 Rollup 表只建设了省、地市维度。同时新增一张乡镇 base 表，并在其根底上建设区县 Rollup 表。
同时为保障查问的时效性,base 表 Rollup 表前缀索引在字段类型和抉择上依照官网倡议，防止应用 Varchar 类型。
区域会话明细模型
1、我的项目背景
数据服务层需对外提供每张物联卡，对立会话产生地位变更后在不同区域的套餐应用状况，会话时常等信息。进而统计物联卡各区域的漫入漫出状况。
2、我的项目计划
实时收集到的 GGSN 报文，通过 StarRocks 的聚合模型，将产生地位变更时的套餐记录，变更工夫积淀下来。而后通过定时工作，从聚合模型明细数据中计算出套餐应用状况，会话时长，生成新的 DWD 表。StarRocks 目前的物化视图很有用，但还不是很灵便，比方，只反对明细数据表模型，并且反对单表创立物化视图，不反对多表 Join 构建物化视图。
StarRocks 在中移物联网 PGW 实时会话业务畛域的瞻望
一方面咱们目前理解到，StarRocks 开发团队，目前正在解决 StarRocks 字段级别无奈反对更新的短板。在将来 StarRocks 降级过程中，咱们可能会摒弃掉 Kudu, 齐全借助 StarRocks 实现实时数仓技术架构。
另一方面，咱们期待 StarRocks 物化视图的灵活性更高，能够反对 Join 级别的物化视图和不同表引擎的物化视图。除此之外，在接下来的我的项目开发过程中咱们也打算进一步应用 bitmap 索引、Colocation Join 等更丰盛的性能进步咱们的查问速度。
除此之外，为了欠缺实时数仓的分层构造，咱们打算在将来应用 Flink 来对接 StarRocks，保障数仓的分层构造，同时进一步欠缺对立的 OLAP 数据分析平台。
