本文导读：

同程数科是同程集团旗下的旅游产业金融科技服务平台，为上下游企业和个人消费者提供数字金融科技服务。近年来，随着同程数科业务的不断拓展和用户量的增加，高效可靠的一站式数据中心建设已成为必不可少的需求。为帮助业务人员提升数据开发的效率与质量，同程数科历经三代架构演进，最终引入 Apache Doris 搭建统一实时数仓，在后续的实际应用中，将实时数仓平台化，进一步构建了一站式数据平台 Ark，为业务人员提供了简单易用、便于维护的系统，实现任务自主开发、灵活上线、简便查询、持续监控等使用功能。

作者：陈松，同程数科 大数据平台工程师

同程数科是同程集团旗下旅游产业金融科技服务平台，前身为同程金服，成立于 2015 年 11 月，以数字科技引领旅游产业，以科技的力量赋能旅游产业为愿景，为旅游公司在深层次的生态链条上构建竞争力，同时为旅游产业链上下游企业和个人消费者提供数字金融科技服务。同程数科的业务涵盖了旅游产业链金融服务、旅游消费金融服务、支付科技等板块，累计服务用户超过千万，涵盖 76 座城市。 目前，同程数科已获得首轮战略投资，联合多家产业金融机构，为旅游产业开拓新业务的服务平台。

近年来，随着同程数科业务的不断拓展和用户量的不断增加，我们越来越需要一个可靠、高效的数据中心，以帮助企业更好地了解业务运营情况和制定策略，这包括但不限于建立实时业务报表看板、实时业务指标预警、营销用户画像与标签、以及金融风控实时监测等分析工具。因此，我们更加关注于实时数仓的构建，希望利用数仓帮助业务人员提升数据开发的效率与质量，从而为业务分析提供强大的后盾。

基于此，我们开始了实时数据仓库的探索之旅。如今，数仓架构已经经历了三代演进，经过第一代离线架构与第二代 Lambda 架构的使用后，通过需求分析与调研，最终引入 Apache Doris 搭建了统一的实时数据仓库。本文将详细介绍三代架构的演进过程，分享我们如何基于 Apache Doris 搭建一站式数据平台 Ark，以及如何在业务使用、系统维护、数仓开发等方面达到降本增效的收益与成果。

早期架构演进

在大数据技术发展和运用的初期，同程数据以 Apache Hive 为核心建立了离线数仓，并使用 Hive 进行数仓分层。当数据从源头进入离线数仓后，通过 ODS 、DWD 、DWS 层级处理，数据输出至 MySQL、Redis、HBase 等应用数据库，以供报表平台使用。该架构虽然具有耦合性低、稳定性高等优势，但其缺点也比较明显，主要体现在当进行局部更新时需要对数据进行全量合并，流程冗长，使数据更新时间变长，时效性无法得到保证。随着数据规模不断增加，局部更新需求越来越多，该架构在数据计算效率低下和资源利用不充分的弊端也变得愈加明显。

基于第一代架构存在的问题，我们对架构进行了升级改造。第二代架构为典型的 Lambda 架构，在保留原有离线数仓的同时，新增了以 Apache Flink 与 Apache Kafka 为核心的实时数仓。在该架构中，离线链路主要对数据进行批量处理，负责解决周期性数据跑错的问题。新增的实时链路利用 Flink 对于数据源进行流式处理、利用 Kafka 对数仓分层，最终输出至应用数据库。

尽管该架构解决了第一代架构中数据时效性较低的问题，但是在长期的运行中，我们发现仍存在一些使用痛点：

• 架构复杂，运维难度高： 由于两套链路同时运行，实时链路需要通过 Apache Flink 与 Apache Kafka 对数据进行流处理，离线链路需要利用 Apache Hive 与 Apache Spark 对数据进行批处理，并且两条链路的维表层中均利用 MySQL 或 Redis 进行存储，这导致整体架构涉及的组件过多，数据处理流程过于复杂。除此之外，该架构会重复计算相同的数据，导致整体资源占用增加、运维管理成本增加、后期维护难度增加。
• 数据开发成本高： 实时数仓部分完全依赖 Apache Kafka 进行数仓分层，而 Kafka 对于数据的存储周期具有限制，新的数据导入任务需要进行额外的开发工作，这将极大增加开发成本。
• 数据一致性低： 相同的数据在实时数仓中流处理，离线数仓中批处理，存在数据处理逻辑不统一的问题，数据一致性与准确性得不到保障。由于无法复用第一代架构中的数据血缘、数据质量等管理体系，在运行过程中，当实时链路出现乱序问题时，需要回放全量日志进行数据回溯，增加数据修复的复杂性。

Apache Doris 和 Clickhouse 选型对比

为了彻底解决早期架构的问题，在引入新架构之前，我们决定进行深度的产品调研来选择更适合的数仓搭建方案。我们发现 MPP 架构数据库能够支持统一实时的数据分析，可以有效解决 Lambda 架构复杂、数据一致性无法保障的问题，而这一产品细分下，Apache Doris 与 Clickhouse 比较匹配我们的业务诉求。基于此，我们对这两款 MPP 架构数据库进行了选型对比，并发现 Doris 的表现更加优异，非常符合我们的选型要求，具体表现如下：

• 产品易用性： ClickHouse 不支持标准 SQL，而 Apache Doris 支持标准 SQL 并兼容 MySQL 协议，使开发人员上手简单，不需要付出额外的学习成本。
• Join 性能优异： Doris 支持分布式 Join，查询灵活度较高，且性能表现优异。而 ClickHouse 由于 Join 查询限制、函数局限性以及可维护性较差等原因，不满足我们当前的业务需求。
• 数据导入： Doris 的数据导入功能完备，支持 Routine Load、Stream Load 和 JDBC Insert Into 等多种数据导入方式，即使在海量数据下也能保持数据稳定写入，性能与速度远高于 ClickHouse。
• 运维难度： Doris 架构精简，只有 FE 与 BE 两种角色，整体部署简单快速，同时 Doris 在扩容方面非常快捷，支持滚动升级，只需要替换相关安装包即可。而 ClickHouse 对组件依赖较高，在使用和扩容上需要做许多准备工作，这就要求提供一支专业的团队来支持日常的开发与运维工作。

更关键的是，Doris 可以同时支持实时数据服务、交互数据分析和离线数据处理等多场景。 Multi-Catalog 提供了联邦查询的能力，支持对多个数据源进行读取，提高数据的准确性和质量，简化任务开发流程。此外，这一功能可以使开发人员更快速地找到所需数据，减少查询时间和成本，提高查询效率。因此 Apache Doris 的高效运行性能和低开发成本的优势，更符合我们对一站式数据平台搭建的需求。

新一代统一实时数仓

引入 Apache Doris 后，我们对架构进行了重构。如上图所示，我们使用 Apache Doris 统一进行数据存储与计算，完全替代了原先的离线架构与 Lambda 架构，并构建了一站式数仓，不仅保证了数据的一致性，还实现了架构的精简，极大降低了架构运维成本。 其次，在数据源进入实时数仓时，我们新增了 Input 统一数据集成引擎，支持多种异构数据源的数据同步，实现数据入口的统一。总而言之，Doris 的引入真正帮助我们实现了数据集成、存储、计算、输出方面的统一，真正意义上实现了实时统一数仓。

基于 Apache Doris 的一站式数据平台

基于新一代的数仓，我们搭建了一站式数据平台 Ark，希望通过该数据平台实现任务开发、任务提交与测试、任务调度与监控、数据查询、集群监控等一体化服务，为内部人员在实际业务中提升任务开发效率，提高任务监控质量。

• 数据开发： 我们希望外部数据接入 Apache Doris 时可以高效地进行 ETL 开发，提升报表产出速度。
• 调度管理： 在业务人员开发完成并上线任务后，我们需要保证任务调度的稳定性以及调度恢复能力，避免问题发生。
• 数据查询： 由于生产与办公网络中间有隔断，办公网络不能直接使用生产网络的连接，只能通过 Web 形式解决网络隔断，我们希望借助平台能够提供安全便捷地查询和分析方式。
• 集群管理： 当集群出现异常状况时，我们希望平台能够及时监控捕捉并进行自动化处理。

一键生成任务脚本，提升任务开发效率

Apache Doris 支持丰富的数据源接入，利用这一功能，在 Ark 平台中可以根据不同的数据源，获取相对应的元数据信息来形成脚本，实现任务快速生成。在数据接入方面，平台进行了半自动化代码的相关工作，并创建了快速生成组件。如上图所示，在平台中输入数据源或表的信息可以自动生成 Routine Load 脚本。基于该脚本，只需要对 Apache Kafka 接入源进行 Topic 修改，即可马上生成 Routine Load 任务。同样，对于 Broker Load 的任务开发原理相同，在选择对应的数仓源之后，可以及时生成 Broker Load 所需脚本。利用 Doris 多源异构数据的写入能力，平台能够快速构建代码，实现对 Routine Load 与 Broker Load 的高效任务开发。

自动调度监控，保障任务正常运行

在任务开发与提交之后，平台可以针对 Routine Load 或者 Broker Load 任务进行查询、检查是否存在异常等常规调度操作。对于需要特别关注的任务，可以加入监控列表中，这样系统会定期自动地对任务进行扫描，发生问题时会进行提示并尝试将任务重新拉起。此外，由于 Routine Load 是常驻进程，对于该任务的监控，平台支持定期且持续的自动化监控功能，而对于 Broker Load 与其他常规任务，平台在定期扫描后会对失败的任务进行预警提示。

安全便捷的可视化查询分析

由于生产与办公网段隔离，我们只能通过 Web 进行查询，使用起来繁琐且不方便。为了解决这个问题，我们曾经尝试使用集成 Hue 的方式，使 Doris 通过 MySQL 协议连接到 Hue 进行数据查询，虽然查询过程有所简化，但是这种方法存在数据安全隐患。

因此，同程数科自行开发了内部查询分析页面，设置了权限管理，解决了查询安全性的问题。同时，在 Ark 平台中集成了 Doris Help 功能，使业务人员能够通过关键字搜索进行 SQL 语法和示例的查询，解决常规查询操作问题，以此降低学习成本，提高内部人员查询的便捷性。

完备智能的集群监控

通过 Apache Doris 集群监控页面可以实时监管 FE 、BE 以及 Broker 节点状况。当集群发生异常状况时，监控系统会发送自动提醒并尝试将集群拉起，及时对异常情况进行自动化处理，避免引发更大的问题。同时集群监控的看板也可以帮助我们观察节点的健康度情况，通过 FE 节点状态判断健康度高低。

总结收益与成果

当前，同程数科已经基于 Apache Doris 搭建了高度统一实时的数据仓库，并使用数十台 Doris 节点机器。此外，我们还将 Doris 功能平台化至 Ark 一站式数据平台中，实现对于 Ark 平台能够包罗万象的开发初衷。对于 Doris 的引入，为我们带来以下收益与成果：

• 缩减开发周期：利用平台一键开发功能，业务人员能够自主开发，无需将需求提给大数据团队，开发时间由原来的半小时缩短到仅需三分钟，显著压缩了任务开发周期，开发效率提升了十倍；
• 灵活数据开发：配合 Ark 一站式数据平台，数据开发能够灵活分析，需求可以快速上线；
• 统一数据处理：Doris 在数据导入、存储、计算实现统一，保证数据一致性，实现真正意义的实时统一；
• 提升查询效率：从过去分钟级效应时间到如今秒级甚至毫秒级，查询效率得到数十倍提升；
• 降低学习成本：因为 Apache Doris 兼容 MySQL 协议，并且使用标准 SQL，在使用上简单易用。业务人员能够如同使用数据库一样使用大数据，从而进一步降低学习成本；
• 降低运维成本： Doris 的部署简单，精简架构使整体链路体系简洁，便于维护。

未来规划

在未来，我们希望基于 Apache Doris 能够搭建实时数仓生态体系，并在同程数科的内部进行大规模使用。我们将会持续建设并优化基于 Apache Doris 一站式实时数仓架构，完善统一计算和存储、流批一体能力。对于 Ark 一站式数据平台持续迭代增强，整个实时数仓体系向着时效性、稳定性、灵活性发展。完善 Ark 数据集成平台的图形化功能，持续增加更多异构数据源之间的数据同步功能，增强引擎对数据的处理能力。

其次，我们将持续关注 Apache Doris 在数据湖分析方面的能力，我们希望在湖中能够对多源异构数据进行采集，实现数据统一存储、统一多范式计算，最后由 Doris 的 API 接口统一对外提供服务。另外，我们对于 Apache Doris 2.0 的尝鲜测试也非常感兴趣，特别是倒排索引功能和 JSONB 数据类型的优化，在后续的架构优化中我们会考虑利用倒排索引替换现有的日志系统，利用更新的 Json 数据类型进一步完善查询能力。

在此特别感谢 SelectDB 技术团队 团队长期以来的及时响应和技术支持。未来，我们也会更积极参与社区贡献及活动，与社区共同进步和成长，欢迎大家选择和使用 Doris，相信 Doris 一定不会让你失望！