营销型网站的现状,成营销型网站制作,网站排名分析 用户需求,百度网站推广找谁做目录
前言
一、引入 Doris原因
二、基于Doris搭建数据平台
2.1 构建实时数仓
2.2 Flink CDC全库同步
三、基于Doris进行OLAP报表开发
四、未来规划 原文大佬介绍的这篇票务平台的实时数仓建设有借鉴意义#xff0c;现摘抄下来用作沉淀学习。如有侵权#xff0c;请告知…目录
前言
一、引入 Doris原因
二、基于Doris搭建数据平台
2.1 构建实时数仓
2.2 Flink CDC全库同步
三、基于Doris进行OLAP报表开发
四、未来规划 原文大佬介绍的这篇票务平台的实时数仓建设有借鉴意义现摘抄下来用作沉淀学习。如有侵权请告知~ 前言 随着在线平台的发展票务行业逐渐实现了数字化经营企业可以通过在线销售数字营销和数据分析方式提升运营效率与用户体验。基于此某头部票务平台为了更好的处理和分析各剧院的票务销售分销渠道用户画像等数据引入了 Apache Doris开启实时数仓构建之旅。下文详细介绍该票务平台基于Apache Doris实时数仓的搭建过程与报表开发场景下的应用实践并分享实时数仓如何在报表开发和查询两方面提升性能如何在系统维护和数据处理方面保持最低成本的收益成果。
一、引入 Doris原因 考虑到剧院票务在各类演出上线后会出现订单激增的情况实时数仓的时效性十分关键。票务平台期望数仓在报表开发和查询两方面能够提供高效性能同时在系统维护和数据处理方面同时在系统维护和数据处理方面保持最低成本运行。因此对于市面上常用于报表开发的数据仓库Apache Hive、Clickhouse、Apache Doris进行了详细对比与分析。 在初步了解后首先放弃了 Apache Hive。主要是因为Hive是离线数仓对数据进行批量处理报表按照T1的调度周期展示结果无法满足实时数据更新的需求。在进一步了解后也排除了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 集群稳定快速地运行。以上这些功能都降低了我们在系统运维的成本和难度。
四、未来规划 当前票务平台已经基于 Doris搭建了实时数据仓库并全面覆盖了报表的开发与分析帮助剧院后台实时分析销量情况。未来将基于Doris不断探索与优化将重点推进以下几个方面的工作
集群优化加强指标管理体系、数据质量监控体系对Doris集群进行性能优化升级实时拉宽强数仓血缘关系的管理使准实时的数据拉宽升级为实时数据拉宽达到数据高度一致与实时同步扩大Doris 使用范围逐步将实时数仓应用至票务推荐系统基于 Doris 对用户购买行为和市场趋势推荐对应的产品进一步提升票务销量。 参考文章
Apache Doris 在头部票务平台的应用实践报表开发提速数十倍、毫秒级查询响应
