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 比 Impala+Kudu 更快，DorisDB 有比较方便的物化视图（Rollup）可以满足统计查询的需求，另外 DorisDB 在关联查询方面性能有比较明显的优势。

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

3. 现有技术框架

3.1 现有技术框架整体介绍

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

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

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

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

3.2 DorisDB 解决的痛点和挑战

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

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

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

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

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

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

1. PGW 用户实时位置轨迹

1.1 方案介绍

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

GGSN 报文量 35 万/s，通过 SparkStreaming 处理解析后，每 1 分钟 StreamLoad 一次入 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 数据分析平台。