本文共 1697 字,大约阅读时间需要 5 分钟。
本文来自于2019年10月15日-17日荷兰首都阿姆斯特丹举行的 SPARK + AI SUMMIT Europe 2019 会议,议题名为《Near Real Time Data Warehousing with Apache Spark and Delta Lake》,分享者 Jasper Groot。
本文 PPT 请关注过往记忆大数据微信公众号,并回复 data_warehouse 关键字获取。本分享配套视频:
本分享主要包括三部分
Structed Streaming
Delta Lake
数据仓库
Structed Streaming 从 Spark 2.0 开始引入,其 API 和 DataFrame 的 API 类似。
上面都是 Structed Streaming 的基本介绍,详细可以参见 https://www.iteblog.com/archives/2084.html。下面我们来简要介绍 Delta Lake
随着时间的推移,磁盘中会存在大量的事务日志,Delta Lake 提供了 VACUUM 来清理过期的事务日志,默认只保存7天。VACUUM 命令会有短暂的停留,会对写有些影响。不像 update、delete、insert 等操作,VACUUM 是不记事务日志的。
下面我们来看看如何使用 VACUUM 命令:
到这里我们已经简要的介绍了 Structed Streaming 和 Delta Lake 是什么。下面我们来看看将这两者结合起来如何实现近实时数据仓库。
我们把 Structed Streaming 和 Delta Lake 放在一起,利用 Structed Streaming 的 DataFrame API、很好地处理迟到的数据以及可以和很多实时流数据源进行 Join。利用 Delta Lake 的 ACID 事务、事务日志以及相关文件管理,来构建数据仓库。
批处理,这个使用 Spark batch 能力,直接读取 MySQL 里面的数据,然后写到 Delta Lake 数据库中;
- 近实时处理,这个获取 MySQL 的 binlog,然后写入到 Kafka,接着使用 Structed Streaming 处理 binlog 数据最终写入到 Delta Lake 中。
写入到 Delta Lake 的数据可以用于 Adhoc 查询分析,或者使用 Spark 处理再将结果导出到 MySQL 中。
下面是我们表的模式以及关联关系:
CDC Capture 是 Changed Data Capture 的简称,也就是改变数据捕获,这里我们是读取 MySQL 的 Binlog 实现的,使用这个来获取表的更改操作,并写入 Kafka。比如下面我们获取到一条插入的数据。
数据到了 Kafka 之后,我们使用 Structed Streaming 读取 Kafka 的实时数据,并解析,然后写到 Delta Lake 中。
下面就是我们写到 Delta Lake 表中的数据
虽然上面的流程能够满足我们的业务需求,但是以下几个问题我们必须警惕:
实时流的计算触发(trigger)间隔比较短,这就意味着对应的 Delta Lake 表存在很多小文件,从而影响读的效率;
表的历史数据如何使用;
文件大小优化。
对于 stream-to-stream joins 我们必须使用 Watermarks;
必须留意实时流数据的延迟
- 如果确实有数据出现延迟,而且使用 Watermarks 已经不能解决时,我们必须设置好实时流错误的触发条件。
新福利:
从11月01日开始至12月06日截止,一共五周时间,每周五我会从公众号底部留言+转发+在看综合最多的读者中抽取一名读者,免费包邮送实体新书《Flink入门与实战》,留言互动起来吧~
转载地址:https://iteblog.blog.csdn.net/article/details/102889946 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!