Apache Doris 在同程数科数仓建设中的实践|今日快讯-- 迪族网

Apache Doris 在同程数科数仓建设中的实践|今日快讯

来源：DataFunTalk 　2023-01-25 05:34:12

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

(资料图片)

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

业务场景架构演变收益现状未来展望

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

编辑整理｜刘步龙

出品社区｜DataFun

业务场景

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

1. 企业介绍

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

2. 业务需求

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

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

架构演变

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）节点监控

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

收益现状

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

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

未来展望

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

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

今天的分享就到这里，谢谢大家。

｜分享嘉宾｜

王星｜同程数科大数据高级工程师

曾就职平安集团、复星集团。

在平安集团期间获得“平安知鸟讲师”称号。

在复星集团期间负责大数据架构相关工作。

现就职同程数科，担任大数据高级工程师一职。

负责同程数科整体大数据平台技术选型、技术架构以及大数据平台建设工作。

｜《数据智能知识地图》下载｜