作者**｜**国内某头部票务平台 大数据开发工程师 刘振伟

**本文导读：**

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

近年来，文化产业在全球范围内快速发展，成为了经济增长的重要支柱。剧院票务作为文化产业的重要组组成部份，也得到了更多的关注。随着在线平台的发展，票务行业逐渐实现了数字化经营，企业可以通过在线销售、数字营销和数据分析等方式提升运营效率与用户体验。

基于此，国内某头部票务平台为了更好地处理和分析各剧院的票务销售、分销渠道、用户画像等数据，决定搭建实时数据仓库，并建设高效快捷的数据分析系统，将系统应用于常规业务报表、敏感数据监控以及票务推荐等应用。希望通过数据报表对剧院票务进行精细化地分析与处理，最终赋能营销策略、掌握市场需求，并达到票务销量增长。本文将详细介绍该票务公司引入 Apache Doris 实时数仓的搭建过程与报表开发场景下的应用实践，并分享在数据导入、数据开发、数据查询与系统运维等方面的收益成果。

# 为什么引入 Apache Doris

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

在初步了解后，首先放弃了 Apache Hive 。主要因为 Apache 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 还提供多种优化机制，进一步提升查询效率。

# 基于 Apache Doris 搭建数据平台

### 如何构建实时数仓

![](http://img.blog.itpub.net/blog/2023/07/27/fa7f109b870378b0.png?x-oss-process=style/bb)

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

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

基于剧院票务的多样外部数据源，采用分层管理方式可以简化数据清洗过程，使每一个数据层都具有其明确的作用域和职责，在使用表时能够更易于定位和理解。开发通用的中间层数据还可以大大减少重复计算，实现准实时数据拉宽。此外，分层提供了统一的数据出口，确保对外输出口径一致，方便后续数据查询与分析。

### 引入 Flink CDC 全库同步

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

![](http://img.blog.itpub.net/blog/2023/07/27/6d3afe1019190b8a.png?x-oss-process=style/bb)

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

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

# 基于 Doris 进行 OLAP 报表开发

![](http://img.blog.itpub.net/blog/2023/07/27/a72fa0cb5390a158.png?x-oss-process=style/bb)

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

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

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

### 全面覆盖 OLAP 报表，开发效率极大提升

在最常用的统计报表开发场景中，面对数据量巨大且数据繁杂的情况，我们采用了 Aggregation Key 模型来实现数据的自动聚合。通过使用相同的 Key 对列进行合并，提前进行聚合，大幅提升了开发效率。以销售员销售报表为例，将同一个销售员与按天维度的支付时间作为相同的 Key 值，票房收入作为值来进行自动聚合。一旦数据进入该报表中，即可直接为业务人员所用。**在引入 Doris 之前，开发一张报表需要半天甚至一天时间，而现在开发周期缩短至 10 - 30 分钟，有效解决开发周期长的痛点，使开发效率极大提升。**

### Join + Rollup 强强联合，查询响应达毫秒级

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

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

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

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

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

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

# 未来规划

当前，我们的票务平台已经基于 Apache Doris 搭建了实时数据仓库，并全面覆盖了报表的开发与分析，帮助剧院后台实时分析销量情况。未来，公司将基于 Doris 不断探索与优化，我们将重点推进以下几个方面的工作：

-   集群优化：加强指标管理体系、数据质量监控体系，对 Doris 集群进行性能优化升级
-   实时拉宽：强数仓血缘关系的管理，使准实时的数据拉宽升级为实时数据拉宽，达到数据高度一致与实时同步。
-   扩大 Doris 使用范围：逐步将实时数仓应用至票务推荐系统，基于 Doris 对用户购买行为和市场趋势推荐对应的产品，进一步提升票务销量。

在此特别感谢 [SelectDB ](https://selectdb.com)技术团队长期以来的技术支持，未来我们会持续关注 Apache Doris 2.0 版本的新特性，在后续业务拓展中引入使用。同时，我们也会更积极参与社区活动，向社区贡献更多的实践经验，与社区共同进步和成长！

ITPub博客

Apache Doris 在头部票务平台的应用实践：报表开发提速数十倍、毫秒级查询响应

最新文章