Doris实践——票务平台的实时数仓建设

前言

一、引入 Doris原因

二、基于Doris搭建数据平台

2.1 构建实时数仓

2.2 Flink CDC全库同步

三、基于Doris进行OLAP报表开发

四、未来规划

原文大佬介绍的这篇票务平台的实时数仓建设有借鉴意义，现摘抄下来用作沉淀学习。如有侵权，请告知~

前言

随着在线平台的发展，票务行业逐渐实现了数字化经营，企业可以通过在线销售，数字营销和数据分析方式提升运营效率与用户体验。基于此，某头部票务平台为了更好的处理和分析各剧院的票务销售，分销渠道，用户画像等数据，引入了 Apache Doris开启实时数仓构建之旅。下文详细介绍该票务平台基于Apache Doris实时数仓的搭建过程与报表开发场景下的应用实践，并分享实时数仓如何在报表开发和查询两方面提升性能，如何在系统维护和数据处理方面保持最低成本的收益成果。

一、引入 Doris原因

考虑到剧院票务在各类演出上线后会出现订单激增的情况，实时数仓的时效性十分关键。票务平台期望数仓在报表开发和查询两方面能够提供高效性能，同时在系统维护和数据处理方面，同时在系统维护和数据处理方面保持最低成本运行。因此，对于市面上常用于报表开发的数据仓库（Apache Hive、Clickhouse、Apache Doris）进行了详细对比与分析。

在初步了解后，首先放弃了 Apache Hive。主要是因为Hive是离线数仓，对数据进行批量处理，报表按照T+1的调度周期展示结果，无法满足实时数据更新的需求。在进一步了解后也排除了Clickhouse选项。一方面 Clickhouse 对 SQL 查询语法不够友好，虽然支持了Join语义，但在进行多表Join时表现性能低，复杂的关联查询会引起内存溢出，无法满足我们对报表查询的需求。另一方面，Clickhouse的架构复杂，对于组件依赖严重，容易出现集群稳定性的问题。在面对海量新增数据时，业务人员需要对系统进行不断进行调优，不仅增加使用成本，还会增加运维管理的难度。

因此，在多方面了解和对比后，发现 Apache Doris 更符合票务平台的业务需求，特别是在使用方式，架构设计，数据导入与处理方面都具有极大优势，具体表现为：

简单易用：Apache Doris 基于 MySQL 协议，支持标准的 SQL 查询语法，使开发人员能够快速上手使用。Doris 的架构非常精简，整体部署只有 FE 与 BE 两种角色，并且支持纯净安装，使架构无需再依赖其他组件。
灵活配置监控：Doris 通过获取专门的 URL 来制定监控规则以达到优化集群状态和性能监控的目的。通过及时调整 FE、BE 角色的配置参数，始终确保数仓稳定快速的运行。
数据模型丰富：通过使用 Doris 自带的三种数据模型，可以有效的加速ETL开发过程。业务人员可以基于不同的数仓分层选用合适的模型来实现高效的数据导入，也可以根据不同的业务场景选择合适的模型进行报表开发。
查询性能更优：Doris 的物化视图和物化索引功能可以实现预计算结果，并在命中物化视图时实现快速响应，达到秒级或毫秒级的查询展示。此外，在进行大表Join时，Doris 还提供多种优化机制，进一步提升查询效率。

二、基于Doris搭建数据平台

2.1 构建实时数仓

基于 Apache Doris，票务平台进行了实时数仓构建实践。票务数据主要来自Mysql业务库、埋点数据、日志数据以及其他数据，再对数据进行采集后，同步至Apache Kafka消息队列并通过 Routine Load导入至Doris数仓中。Apache Doris主要作用于数据仓库以及直接应对前端业务报表的查询。如上方架构图所示，实时数仓共分为五层：

ODS贴源层：主要存放未经处理的原始数据结构，与 MySQL 原系统保持一致，是数据仓库的准备区域。统一采用 Unique Key数据模型，能够有效防止数据重复采集，减少任务失败。
DWD明细层：存放维度建模的事实表，对生产数据进行清洗，统一格式，脱敏等，保存各业务过程中最小粒度的操作记录，同样在明细层主要采用了 Unique Key 模型，用相同的 Key进行数据覆盖实现行级的数据更新。
DWS汇总层：以明细层数据为基础，依据业务需求划分数据主题（如订单，用户等），将相同粒度数据进行关联合成宽表。该表使用Unique Key 和 Aggregate Key两种模型进行数据轻度汇总为后续的业务查询和OALP分析做准备。
ADS 应用层：基于以上三层数据存放各项指标统一结果。主要利用 Aggregate Key模型进行高度自动聚合，为满足前端人员的具体分析需求，直接提供查询展现。
DIM 维表层：在 DIM 层中，主要存放剧院数据，项目数据，场次数据等。在实际应用中，维度数据会结合订单明细数据来进行使用。

2.2 Flink CDC全库同步

在数仓应用后，对数据接入进行了优化处理，采取Flink CDC进行同步，实现对新架构稳定接入，进一步减少数据维护成本。

在业务初期，开发人员使用Datax进行外部数据源的全量和增量抽取，以实现离线数据同步，并借助Canal 解析MySQL Binlog进行实时数据的同步。然而，这种方式无法保证数据接入的稳定性。为了解决这一类问题，开发人员决定引入 Flink CDC 来执行数据同步。为了在短时间内获取业务所需报表，还采取了全库同步的方式对动态新增表进行同步，具体思路如下图所示：

在mysql数据库中对表管理配置数据进行动态更新。
利用 Flink，在Job任务中创建两个CDC捕获任务。其中一个数据流负责捕获变更数据，另一个广播流负责进行更新配置。
在Sink端配置所有全库的表，当表新增时，会触发广播流更新配置数据。（在 Sink 端配置所有全库的表，只配置该表，暂时不用创建对应的表。）

三、基于Doris进行OLAP报表开发

作为剧院的管理后台，票务数据平台主要利用 Apache Doris 进行报表开发，提供所需数据分析，以帮助业务人员对剧院票务进行管理，提高票务销量。针对不同的报表场景，业务分析的侧重点有所不同，主要体现在：

统计报表：该报表是业务分析使用频率最高的报表，主要涉及100多家剧院的销售数据，包括分销渠道销售明细，销售员销售报表，演出明细报表，纠错报表，场次汇总报表等。
敏捷报表：针对特定活动进行报表开发，业务数据主要来自商业化运营，包括日项目数据汇总、周项目数据汇总、销售额数据汇总、GMV 月报数据、平台分销渠道数据、财务结算报表等。
数据分析：显示该剧院的运营情况，包括阅读会员日订单情况，销售收入情况、上座率、会员重复下单数量、用户画像分析等。
数据大屏：主要用于展示订单数据趋势、巨量销售趋势、提供数据视图。

根据以上报表场景的特点，使用范围与开发需求，选择Doris 自带的多种数据模型进行高效的报表开发。在满足开发性能需求的同时，还实现了对实时数仓的低成本运维以及低成本存储，Doris 的引入带来了以下具体应用收益：

Join + Rollup实现查询响应达毫秒级

在敏捷报表开发场景中，业务人员时常需要了解活动当天的数据，并在一定周期时间内形成汇总报表对活动进行复盘分析。因此不论是对开发报表的速度，还是对前端人员查询报表时的响应速度都有极高的要求。以 GMV 月报数据为例，需要在活动当月对成交量进行统计汇总，并通过报表分析票务增速，评估活动效果。

在前期搭建数仓 DWD 明细层时，已经利用 Unique Key 模型实现了数据行级别更新，确保GMV报表所需数据的覆盖，无需再花费时间进行开发。在这一基础上，还利用了 SQL 多表 Join 进行聚合，借助了 Doris Rollup功能创建物化索引以缩短数据扫描的时间，加速查询响应。通过两者结合的方式，报表展示从之前的十秒缩短至秒级或毫秒级，响应速度提升了数十倍。

支持多源异构数据，导数效率大幅提升

数据导入的效率与便捷性是衡量数据仓库最重要的因素之一。利用Doris Insert Into和丰富的内置导数方式，对本地数据，外部存储数据，kafka日志等数据源进行导入，并且在导入数据的同时还可以对其进行列映射、转换和过滤操作，有效解决了早期导数过程中数据重复采集和不同数据源导致操作复杂性的问题。同时，Doris 对接入源脚本支持了半自动化代码的功能，只需要在配置表增加表名，即可快速接入数据，不再需要手工编写脚本，大大提高了导数效率。

架构链路清晰，实现低成本运维

Doris架构简单，只有FE和BE两个进程，扩缩容方便快捷，系统升级也非常简单，只需要替换相关的安装包即可。同时，Doris对集群配置信息和状态信息提供了便捷灵活的管理方式，可以通过获取专门的url，制定监控规则以便及时的调整各类配置参数，时刻保持 Doris 集群稳定快速地运行。以上这些功能都降低了我们在系统运维的成本和难度。