Apache Doris 在同程数科数仓建设中的实践

导读：随着大数据的进一步发展，实时分析数据库的发展也越来越繁荣。Apache Doris 作为一个高性能、简单易用、支持实时的 MPP 架构分析数据库也被越来越多的公司使用。今天会和大家分享一下 Apache Doris 在同程数科数仓建设中的实践。

今天的介绍会围绕下面四点展开：

• 业务场景

• 架构演变

• 收益现状

• 未来展望

分享嘉宾｜王星 同程数科 大数据高级工程师

编辑整理｜刘步龙

出品社区｜DataFun

---

01

业务场景

首先分享一下我们的业务场景。

1. 企业介绍

同程数科是属于同程集团旗下的一个旅游产业金融服务平台。前身为同程金服，成立于 2015 年 11 月。愿景是“以数字科技引领旅游产业”，希望以科技的力量来赋能旅游产业。业务包含四大主要板块，产业金融服务、消费金融服务、金融科技和数字科技。现在累计服务用户超过千万，涵盖了 76 座城市。

2. 业务需求

针对以上业务，我们基于 Doris 实现的需求主要包括四大类：

• 看板类：业务实时驾驶舱；T+1 业务看板
• 预警类：实时业务流程预警（比如：风控熔断、资金异常、流量监控）
• 分析类：数据查询分析；临时取数；实时用户标签查询
• 财务类：财务清算对账；支付对账

02

架构演变

1. 架构演变——架构 1.0

在 1.0 架构中我们引用了 StreamSets、Kudu、Impala 等技术。实时数仓链路是，先通过 SteamSets 采集数据库的 binlog，实时写入 Kudu，再通过 Impala 等工具查询和使用。实时计算部分是，将埋点数据发送到 kafka，之后通过 Flink 做实时计算，最终结果数据一部分落入分析库，一部分落入 Hive 中，用于数仓中使用。

随着业务的发展，1.0 架构的弊端也逐渐显现出来了。

架构 1.0 的优点为：

• 使用 CDH 构建，在现有 CDH 集群下，能够快速相互集成并投入使用
• 实时采集能够可视化配置式开发

架构 1.0 的不足为：

• 引入组件过多，（组件、作业）维护复杂，问题排查困难，数据修复困难
• 数据开发链路过长，对数仓人员技术要求高，开发效率低
• 聚合查询能力不足，大表 join 效率不高
• 离线与实时集群未做分离，导致资源相互竞争
• 有预警能力，但是作业自动恢复能力不足

2. 架构演变——架构 2.0

在架构 2.0 的选型中，我们引入了 Doris，对实时数仓进行了改造。首先通过 Canal去采集业务库数据，这也是一个 CDC 的能力。将采集的数据放入 kafka，之后使用Doris Routine Load 进行数据加载。之前实时计算流程没有太大的改变，唯一变化的地方就是 Doris 对 Hive 数据的接入比较友好，通过 Broker Load，可以很方便的将离线集群数据直接接入到 Doris 中。

之所以选择 Doris 主要是基于以下几个原因：

• 丰富的数据接入能力（支持众多数据源）
• 采用 MySQL 协议通信
• Doris SQL 基本覆盖 MySQL 语法
• 支持MPP并行计算能力
• 官方文档健全，上手较快

3. 架构 2.0——Doris 部署架构

上图是 Doris 的部署架构，架构特点如下：

• Doris 的部署不依赖于现有大数据的组件，可独立部署。
• 整体分两层：FE（前端节点）、BE（后端节点）。FE主要负责接收请求和返回请求，对元数据和集群的管理，以及查询计划的生成；BE 主要负责数据节点的管理，和对执行计划的执行。
• Doris 整体运维简便，高可用，可扩展性强。

我们曾经历了一次机房迁移，我们采用的是滚动式迁移，12 台 Doris 机器，在 3天内完成了全部迁移工作。迁移过程中，时间主要用在了对机器下架、搬移和上架动作上。迁移 Doris 时，用到的指令主要是对 FE 节点缩容与扩容，以及 BE 节点的缩容与扩容。对于 BE 节点，建议不要使用 DROPP 强制缩容，因为数据无法恢复，而是尽量使用 DECOMMISSION（解除）的方式，迁移数据后缩容。

4. Doris 实时系统架构

上图是我们基于 Doris 的实时数仓架构。首先是数据源来自于我们各个业务线，数据采集主要通过 Canal 和 API 接口，Canal 采集使用的是 Canal-Admin 维护。然后将采集到的数据发送到 kafka 消息队列，再通过 Routine Load 接入 Doris 集群。

在 Doris 数仓部分，主要分为三层：DWD 明细层，DWS 汇总层和 ADS 应用层。DWD 层用的是unique模型，DWS 和 ADS 层用的是 aggregate 模型。

数据最终应用在实时看板、挖掘分析、数据服务等。

5. Doris 新数仓特点

数据导入方式简便，针对不同场景数据采用方式如下：

• routine load：业务数据（写入kafka）实时接入 Doris
• broker load：离线数据定时或手工导入 Doris（包含：基础维度表、历史数据等）
• insert into：定时作业，从 DWD 层处理出 DWS 层，之后处理出 ADS 层
• 良好的数据模型，使开发效率更高
• unique 模型：业务数据接入 Doris 时使用，防止重复采集
• aggregate 模型：从 DWD 层到 DWS 或 ADS 层使用，帮我们减少了很大一部分 SQL 代码量
• 使用门槛低，查询效率高
• 基于 MySQL 协议，标准的 SQL 查询语法，查询分析无压力
• 使用物化视图达到预计算效果，如果查询命中，将快速响应
• 部署架构简便，运维维护成本低
• 针对 FE、BE、BROKER 角色，配置监控，异常重启

6. 如何更友好地使用 Doris

对于一个新组件大家可能会更关心以下几点：

• 快速开发：如何能够简单快速的将数据导入 Doris，并快速实现 ETL 开发
• 调度管理：如何管理上线的任务，保证任务调度的稳定，以及调度恢复能力
• 数据查询：生产与办公网络隔离，如何让大家安全便捷的查询分析
• 集群管理：如何感知节点异常，并且能够重试自动恢复
• 整体宗旨：高效率、高质量、高稳定。

7. 数据平台——Doris 开发

（1）Doris 数据开发：快速构建代码，实现 routine load、broker load 任务开发

对于数据接入这一块，我们做了一些半自动化的工作，通过选择数据源和表生成一些routine load 脚本，相当于也是一些快速生成组件。然后只要对 kafka 的 topic 进行修改指定，就可以快速形成一个 routine load 任务。broker load 任务也是类似的动作，我们选择数仓的源和表，就可以通过元数据快速生成 broker load 脚本。

（2）routine load、broker load、常规任务提交或测试

当任务生成之后， 就是如何提交和管理。routine load 是一个常驻进程，我们进行一次提交就可以了，提交后会变成 running 的状态。如果有异常会在页面显示和告警出来。

（3）Doris 调度与监控

这个图是我们提交作业之后进行作业的监控和管理。监控会对任务定时扫描，如果出现问题会有提醒，同时会尝试将任务重新拉起。

（4）自研查询页面和 Doris Help 集成

由于我们生产和办公网段是隔离的，所以查询只能通过 web 的形式。为了解决查询问题，我们在平台里面开发了一些查询页面，可以将 DB 下面所有的表给列出来。上图中右半部分是查询编辑的页面，下面是查询展示结果。同时我们也集成了 Doris Help 的功能，通过关键字，就可以查询到 Doris 内部集成的帮助和示例。

（5）节点监控

上图是集群监控，当出现异常时，会自动提醒并尝试拉起节点。

03

收益现状

通过升级架构，使得成本大大的降低，效益增长也十分明显。新架构带来的效益如下：

• 数据接入：新架构数据接入代码可快速构建，3-5 分钟完成一个接入。老架构手工部分比较多。接入一张表需要 20-30 分钟。
• 数据开发：Doris 自带 unique、aggregate 模型，能够加速 ETL 开发过程。老架构数据 ETL 过程没有底层数据模型支撑，很多处理逻辑需要自行开发。 
• 数据查询：基于 Doris 新架构带有物化视图或 Rollup 物化索引提升查询效率。同时大表 join 时 Doris 内部提供很多优化机制。
• 数据报表：基于 Doris 的查询展示，报表相应速度基本在秒级或毫秒级响应。
• 环境维护：没有 Hadoop 数仓环境复杂，整个平台链路方案清晰。同时 Doris 集群的运维成本远低于 Hadoop 集群运维（迁移一次就懂了）。

04

未来展望

对与新架构的提升，我们有如下愿景：

• 尝试引入 Doris Manager 对集群进行维护和管理
• 实现基于 Flink CDC 方式的数据接入。这是我们 3.0 架构规划（进行中）
• 对现有 Doris 集群进行升级，使用新特性，更快速响应需求
• 针对“指标管理体系”、“数据质量监控体系”进行强化建设