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

本文导读：

跟着在线途径的发展，票务行业逐步完成了数字化运营，企业能够经过在线出售、数字营销和数据剖析等方法进步运营功率与用户体会。依据此，国内某头部票务途径为了更好地处理和剖析各剧院的票务出售、分销途径、用户画像等数据，决议引进 Apache Doris 开启实时数仓构建之旅。本文将详细介绍该票务途径依据 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 建立数据途径

怎么构建实时数仓

依据 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 进行数据同步，完成对新架构安稳接入，进一步削减数据保护本钱。

在事务初期，开发人员运用 DataX 进行外部数据源的全量和增量抽取，以完成离线数据同步，并借助 Canal 解析 MySQL Binlog 进行实时数据的同步。但是，这种方法无法保证数据接入的安稳性。为了处理这一问题，开发人员决议引进 Flink CDC来履行数据同步。为了在短时刻内获取事务所需报表，还采纳了全库同步的方法对动态新增表进行同步，详细思路如图所示：

• 在 MySQL 数据库中对表办理装备数据进行动态更新。
• 运用 Flink，在 Job 使命中创立两个 CDC 捕获使命。其中一个数据流担任捕获改变数据，另一个播送流担任进行更新装备。
• 在 Sink 端装备一切全库的表，当表新增时，会触发播送流更新装备数据。（ 在 Sink端装备一切全库的表，只装备该表，暂时不用创立对应的表。）

依据 Doris 进行 OLAP 报表开发

作为剧院票务的办理后台，票务数据途径首要运用 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 技能团队长期以来的技能支撑，未来咱们会持续重视 Apache Doris 2.0 版本的新特性，在后续事务拓展中引进运用。一起，咱们也会更积极参与社区活动，向社区奉献更多的实践经验，与社区共同进步和生长！