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

时间:2023-01-30 15:11:02

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

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

  • 业务场景

  • 架构演变

  • 收益现状

  • 未来展望

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

编辑整理|刘步龙

出品社区|DataFun


01

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

1. 企业介绍

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

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

2. 业务需求
针对以上业务,我们基于 Doris 实现的需求主要包括四大类:

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

02

架构演变

1. 架构演变——架构 1.0

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

在 1.0 架构中我们引用了 StreamSets、Kudu、Impala 等技术。实时数仓链路是,先通过 SteamSets 采集数据库的 binlog,实时写入 Kudu,再通过 Impala 等工具查询和使用。实时计算部分是,将埋点数据发送到 kafka,之后通过 Flink 做实时计算,最终结果数据一部分落入分析库,一部分落入 Hive 中,用于数仓中使用。
随着业务的发展,1.0 架构的弊端也逐渐显现出来了。
架构 1.0 的优点为:

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

架构 1.0 的为:

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

2. 架构演变——架构 2.0

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

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

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

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

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

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

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

上图是 Doris 的部署架构,架构特点如下:

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

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

Apache 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 任务开发

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

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

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

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

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

这个图是我们提交作业之后进行作业的监控和管理。监控会对任务定时扫描,如果出现问题会有提醒,同时会尝试将任务重新拉起。
(4)自研查询页面和 Doris Help 集成

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

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

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

上图是集群监控,当出现异常时,会自动提醒并尝试拉起节点。
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 集群进行升级,使用新特性,更快速响应需求
  • 针对“指标管理体系”、“数据质量监控体系”进行强化建设