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

自2021年1月推出免费DorisDB标准版产品以来，我们的客户数量爆炸性增加。迄今为止，数十家客户在生产环境中正式在线DorisDB，数百家客户正在进行实际业务场景的测试。我们邀请了部分已上线的客户，分享他们的数据分析经验。这个系列的文章涉及多个行业，将在未来持续输出，敬请关注。

作者:宁彦辉移动物联网大数据开发工程师主要从事流程计算开发、物联网机械学习数据挖掘、OLAP查询引擎数据开发

移动物联网作为中国移动通信集团有限公司出资成立的全资子公司。公司根据中国移动整体战略布局，围绕物联网业务服务的支持者、专用模块和芯片提供者、物联网专用产品推进者的战略定位、专业运营物联网专用网络、设计生产物联网专用模块和芯片、汽车网络、智能家庭、智能服装等特色产品，开发运营物联网连接管理平台OneLink和物联网开放平台OneNET

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

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、DorisDB、Kudu相继调查。对我们的业务分析和业务痛点进行了以下测试。

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

DorisDB:查询分析性能强，多表关联速度比其他产品快得多。类似于Clickhouse，DorisDB目前不支持分段级数据更新，同时查询性能与表格的设计和集群性能密切相关。原则上，集群性能随数据节点的线性增加。此外，简单的运输管理也是DorisDB的亮点。目前，DorisDB开发版本反复快，需要及时跟进官方版本的进展。

Kudu:支持快速数据更新、快速数据分析和即时查询，但数据量不应过大，单表数据量不应超过15亿。

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

综上所述，实时数仓方案，采用KudubdorisDB结合，实现现有PGW实时对话业务。DorisDB作为主要技术组件，Kudu辅助实现分段更新业务场景。

3.现有技术框架

3.1现有技术框架总体介绍

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

PGW对话业务中流动Join的问题，一部分通过DorisDB中星型建模方案的解决，另一部分通过关系型存储器数据库VoltDBGoogle对GuavaCache进行代码处理。

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

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

3.2.DorisDB解决的痛点和挑战

1.充分利用DorisDB在多表join方面的性能优化，如ColocateJoin、内存表等特性。将原始流动join方案改为星形建模方案，在数据服务层进行多表join联邦查询

2.通过DorisDB动态分区特性分区库存数据，利用Bitmap数据类型正确重量，在各分区内完成排序。排序的结果进一步总结到一张数据表中，与实时到达的数据一起排名，可以有效地解决数据混乱的问题，保证数据分析的效率。

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

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

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

1.PGW用户实时位置轨迹

1.1方案介绍

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

GGSN报告量为35万/s，通过SparkStreaming处理分析后，每1分钟进入DorisDB。

1.2方案优化

最初由于Rollup表建设了省、地市、区县、乡镇，写作时IO负担过大，写作速度跟不上数据推送，SparkStreaming出现压迫，后期性能测试Rollup表只建立了省、地市维度。同时追加乡镇base表，在此基础上建立区县Rollup表。

为了保证查询的时效性，base表Rollup表的前缀索引根据字段类型和选择的官方建议，不使用Varchar类型。

2区域对话明细模型

2.1项目背景

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

2.2项目方案

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

DorisDB在移动物联网PGW实时对话业务领域的展望

另一方面，DorisDB开发团队现在解决了DorisDB字段水平无法支持更新的短板。在未来DorisDB升级过程中，我们可能会抛弃Kudu，完全利用DorisDB实现实时数仓技术结构。

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

除此之外，为了完善实时数仓的分层结构，我们计划在未来使用Flink对接DorisDB，保证数仓的分层结构，同时进一步完善统一的OLAP数据分析平台。