共计 4612 个字符，预计需要花费 12 分钟才能阅读完成。
作者 | 国内某头部票务平台 大数据开发工程师 刘振伟
本文导读：
随着在线平台的倒退，票务行业逐步实现了数字化经营，企业能够通过在线销售、数字营销和数据分析等形式晋升经营效率与用户体验。基于此，国内某头部票务平台为了更好地解决和剖析各剧院的票务销售、分销渠道、用户画像等数据，决定引入 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 版本的新个性，在后续业务拓展中引入应用。同时，咱们也会更积极参与社区活动，向社区奉献更多的实践经验，与社区共同进步和成长！
