应用实践 | 数仓体系效率全面提升!同程数科基于 Apache Doris 的数据仓库建设
导读:同程数科成立于 2015 年,是同程集团旗下的旅游产业金融服务平台。2020 年,同程数科基于 Apache Doris 丰富的数据接入方式、优异的并行运算能力、极简运维等特性,引入 Apache Doris 进行数仓架构2.0 的搭建。本文详细讲述了架构1.0 到 2.0 的演进过程及 Doris 的应用实践,希望对大家有所帮助。
作者|同程数科大数据高级工程师 王星
业务背景
业务介绍
同程数科是同程集团旗下的旅游产业金融服务平台,前身是同程金服,正式成立于 2015 年。同程数科以“数字科技引领旅游产业”为愿景,坚持以科技的力量,赋能我国旅游产业。
目前,同程数科的业务涵盖产业金融服务、消费金融服务、金融科技及数字科技等板块,累计服务覆盖超过千万用户和 76 座城市。

图1.1 业务场景-业务介绍
业务需求
主要包含四大类:
-
看板类:主要包括业务实时驾驶舱以及 T+1 业务看板等。
-
预警类:主要包括风控熔断、资金异常以及流量监控等。
-
分析类:主要包括及时性数据查询分析以及临时取数等。
-
财务类:主要包括清算以及支付对账需求。

图1.2 业务场景-业务需求
综合以上业务需求,我们进行了系统架构建设。
架构演进之 1.0
工作流程

图2.1 架构演变-架构1.0
架构1.0 是前几年非常流行的以 SteamSets 和 Apache Kudu 为核心的第一代架构。
该架构通过 StreamSets 进行数据库 Binlog 采集后实时写入 Apache Kudu 中,最后通过 Apache Impala 和可视化工具进行查询和使用。这个过程存在架构链路较长以及 SteamSets 对部分配置复用性表现欠佳的问题,另外 Apache Kudu 的多表关联与大表关联存在一定的性能瓶颈,且对 IO 方面要求较高。
图2.1 下半部分中实时计算流程的应用与上半部分较为相近,在实时计算中,埋点数据发送到 Kafka 后会通过 Flink 进行实时计算,并将计算结果数据落入分析库与 Hive 库中用于数仓关联。
优势与不足

图2.2 架构演变 优点与缺点
优势:
-
架构1.0 选择了 CDH 全家桶。CDH 提供了众多大数据组件,可以相互集成并投入使用,同时其配置相对灵活。
-
使用的 SteamSets 支持可视化拖拉式与配置式的开发方式,因此开发人员对 SteamSets 的接受程度较高。。
不足:
-
组件引入过多,维护成本随之增加;当数据出现问题时,排查与修复链路相对较长。
-
多种技术架构和过长的开发链路,提高了数仓人员的学习成本与要求,数仓人员需要在不同地方转换后再进行开发,导致开发流程不顺畅、开发效率降低。
-
Apache Kudu 在大表关联 Join 方面性能差强人意。
-
由于架构使用 CDH 构建,离线集群和实时集群未进行分离,形成资源相互竞争;离线跑批的过程中对 IO 或磁盘消耗较大,无法保证实时数据的及时性。
-
虽然 SteamSets 配备了预警能力,但作业恢复能力仍相对欠缺。配置多个任务时对 JVM 的消耗较大,导致恢复速度较慢。
架构演进之 2.0
工作流程
由于架构1.0 的不足远多于优点,在 2020年,我们调研了市面许多进行实时开发的组件,发现了 Apache Doris,通过调研对比,最终决定将 Apache Doris 引入了架构2.0。


同程数科利用ApacheDoris构建了新一代数仓架构2.0,提升了数据接入、开发、查询和维护效率。通过引入Doris的丰富数据接入方式、并行计算能力和极简运维,解决了旧架构中组件过多、开发链路长、性能瓶颈等问题。Doris的MPP架构、SQL兼容性以及与BI工具的友好集成,加速了实时看板、分析和财务需求的响应速度。未来,同程数科计划引入DorisManager、FlinkCDC,并持续跟进社区迭代,以优化现有架构。
最低0.47元/天 解锁文章
1538





