《AnalyticDB PostgreSQL实时物化视图在飔合科技实时数仓的实践.pdf》由会员分享,可在线阅读,更多相关《AnalyticDB PostgreSQL实时物化视图在飔合科技实时数仓的实践.pdf(18页珍藏版)》请在三个皮匠报告上搜索。
1、DataFunSummit#2023AnalyticDB PostgreSQL实时物化视图在飔合科技实时数仓的实践侯鹏-飔合科技-数据工程师01实时物化视图介绍02实时物化视图实践03总结目录CONTENTDataFunSummit#202301实时物化视图介绍背景 随着信息技术的发展,业务对数据分析的时效性要求越来越高,很多业务开始从传统的基于批处理的离线模式,转向基于流处理的实时模式。常见的一种实时数据解决方案是:流处理引擎+消息队列+大数据OLAP产品。以上方案有如下劣势:1)要布多套组件,机器成本高;2)离线和实时数仓两套架构,代码难以复用,开发和运维成本高;3)遇到问题,需要排查的组
2、件多,有时需要深度了解各组件才能找到根因,Debug成本高。技术方案 AnalyticDB PostgreSQL 版基于实时物化视图构建流批一体的一站式实时数仓解决方案,实现一套系统、一份数据、一次写入,即可在数仓内完成实时数据源头导入到实时分析全流程。实时数仓的构建链路通常包含实时数据写入、实时处理、实时分析(消费)三个步骤。在数据量比较小、业务较简单的情况下(如统计累计订单数)时这个流程会比较简单,单纯采用流处理引擎即可完成。但当数据规模较大、数据格式不规范、计算逻辑复杂,同时下游对中间表的表依赖大时,简单的实时分析链路无法满足业务需求,需要借鉴数据仓库分层架构设计即ODS、DWD、DWS
3、、ADS。AnalyticDB PostgreSQL 版基于实时物化视图可以完美地融合离线数仓的分层架构,让用户能够专注于业务设计和应用,数据实时流转链路由产品本身来保障。数据架构 AnalyticDB PostgreSQL 版实时数仓的架构如下:1)实时写入:高性能,低延迟,写入立即可见,完备的事务支持;2)实时处理:基于实时物化视图,流式增量的实时对数据进行ETL处理。相较于普通(非实时)物化视图,实时物化视图无需手动调用刷新命令,即可实现数据更新时自动同步刷新物化视图。当基表发生变化时,构建在基表上的实时物化视图将会自动更新。还可以在实时物化视图上再创建实时物化视图,当基表发生变化时,相
4、关级联的实时物化视图也会自动更新。基于此特性可以方便地构建分析数据的实时ETL处理链路;3)实时分析:基于SIMD指令集向量化执行引擎、CBO的查询优化器、列式的存储引擎,实现高性能实时分析。核心优势 架构领先、成本最优AnalyticDB PostgreSQL 版支持对接RDS业务数据库实时日志构建一站式实时数仓,相比采用流处理引擎+消息队列+大数据OLAP产品成本上更优,同时依赖的组件更小在稳定性和运维性上更优。一站式实时数仓的开发和数据流转都在仓内完成,无需多套系统间反复流转。整体来说:1)成本:仅一份数据存储,仅一套系统部署,仅一次写入开销,整体资源成本最优;2)性能:没有复杂的链路流
5、转,资源开销低,并且数据延迟低;3)开发:通常一套SQL开发即可,无需多系统适配联调等;4)运维:只需要维护一套系统,数据异常排查便利,数据订正容易。核心优势 支持批流一体AnalyticDB PostgreSQL 版除了支持RDS业务数据库日志外,还支持丰富的数据源写入方式,可以高效完成入仓之后进行融合处理和融合查询:1)通过DTS对接RDS Binlog日志,实现业务数据准时地同步到实时数仓中;2)支持实时数据源如消息队列Kafka、RocketMQ等;3)支持和实时流处理引擎对接,实现数据消费;4)支持通过数据同步或读外表的形式将数据写入到 AnalyticDB PostgreSQL 版
6、中。核心优势 支持复杂批处理任务实时数仓建设过程中的一大难点就是将原有的复杂批处理任务,转化为实时处理任务,通常来说批处理可以较为轻松地支持复杂的SQL语法,尤其是多重嵌套等复杂SQL,而流处理对SQL的语法的限制较多,AnalyticDB PostgreSQL版基于传统数仓对复杂SQL查询支持的优势,相比流计算引擎可以在复杂批处理任务转化为实时处理任务时有更小的改造成本。支持无限窗口数据库引擎,通常都是面向磁盘存储设计的,相比于基于内存设计的流计算引擎,可以更好的支持超大表的实时JOIN,尤其是多大表复杂的实时JOIN。基于AnalyticDB PostgreSQL版的实时物化视图,可以支持
7、任意历史数据的回溯,不受窗口限制。对于历史数据的订正和回溯,实时物化视图非常便捷,只需要对原始数据做更新即可自动反映到实时链路中。核心优势 简单透明查询改写传统的数仓分层,需要业务SQL显式指定访问预处理的结果集。而在一站式实时数仓内,实时分析和实时处理是合并在同一套系统内,可以相互打通和感知,轻松支持透明的查询改写。实时分析的业务可以在固定访问SQL不用变更的情况下,通过搭建和撤销实时处理链路,对实时分析进行加速和取消加速。依托数据库强大的优化器,不仅可以自动优选最优加速方案,还可以方便地进行冷热链路的切换和维护。DataFunSummit#202302实时物化视图实践飔合数据仓库架构遇到问
8、题 离线数仓无法应对一些时效性要求高的需求,为了尽可能保证数据时效性,最开始的解决方案是缩短调度周期,但随着业务的发展,数据量剧增,频繁调度经常导致数据库资源拉满,造成查询抖动。另外,一些时效性要求在秒级的需求,也无法通过缩短调度周期来实现。引入实时物化视图 相比于新建一套流处理体系,实时物化视图几乎不需要对现有架构做什么变更,只需将普通SQL改造为实时物化视图即可。实时物化视图写法上更简洁,不用像普通SQL一样需要考虑基表数据的增、删、改情况。案例分享:电价预测 第三方会提供一些基础预测数据,比如风、光、水电的预测出力、输电线路的预测负荷等,会有多个预测版本,预测时间越近的版本理论上越准确,
9、算法会根据这些基础预测数据推导出对电价的预测,进而指导电力交易员的交易策略。基础数据获取后存在ADB PG数仓,通过DMS定时调度SQL对数据做清洗、定制化处理后,再提供给算法使用。DMS定时调度周期最短为1h,在获得最新的预测数据后,数仓不能及时处理,提供给算法的数据是滞后的,理论最长滞后时间为1h。交易员获得的电价预测信息就相对不准确,最终可能导致在交易过程中赔钱。将普通SQL改造成实时物化视图后,算法能及时拿到最新的数据,对电价的预测会更准确,给交易员提供有力的数据支撑。算法为什么不直接拿源数据?DataFunSummit#202303总结总结 AnalyticDB PostgreSQL实时物化视图实现了一个低成本的数据库内部的流处理。对时效性要求不高的需求建议还是采用普通SQL批处理方式,对时效性要求高的需求可以使用实时物化视图实现。一般来讲,企业真实需要实时的场景并不多,所以建议数仓建设还是以离线为主,实时为辅。感谢观看