编者按：自从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数据分析平台。