大规模数据处理实战
蔡元楠
硅谷资深工程师
41608 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
大规模数据处理实战
15
15
1.0x
00:00/00:00
登录|注册

17 | Structured Streaming:如何用DataFrame API进行实时数据分析?

端到端exactly once的语义
更好的容错性
Structured Streaming对事件时间处理有很好的支持
连续处理模式
Structured Streaming更接近实时处理
Spark SQL引擎优化功能
DataFrame API相对高level
DStream API与RDD API低level
输出结果流
基于事件时间的时间窗口操作
基本查询操作
创建DataFrame
输出模式:完全模式、附加模式、更新模式
数据按时间间隔划分成数据段
无边界的关系型数据表
Spark SQL执行引擎自动优化程序
高级API,类似于SQL的query接口
例子中的机制及限制
结构化流数据处理中如何处理晚到达的数据并返回正确结果
对事件时间的支持
实时性
简易度和性能
Streaming DataFrame API
事件时间处理
模型
优点
基于DataFrame API
思考题
Structured Streaming与Spark Streaming对比
结构化流数据处理的模块Structured Streaming

该思维导图由 AI 生成,仅供参考

你好,我是蔡元楠。
上一讲中,我们介绍了 Spark 中的流处理库 Spark Streaming。它将无边界的流数据抽象成 DStream,按特定的时间间隔,把数据流分割成一个个 RDD 进行批处理。所以,DStream API 与 RDD API 高度相似,也拥有 RDD 的各种性质。
在第 15 讲中,我们比较过 RDD 和 DataSet/DataFrame。你还记得 DataSet/DataFrame 的优点吗?你有没有想过,既然已经有了 RDD API,我们为什么还要引入 DataSet/DataFrame 呢?
让我们来回顾一下 DataSet/DataFrame 的优点(为了方便描述,下文中我们统一用 DataFrame 来代指 DataSet 和 DataFrame):
DataFrame 是高级 API,提供类似于 SQL 的 query 接口,方便熟悉关系型数据库的开发人员使用;
Spark SQL 执行引擎会自动优化 DataFrame 程序,而用 RDD API 开发的程序本质上需要工程师自己构造 RDD 的 DAG 执行图,所以依赖于工程师自己去优化。
那么我们自然会想到,如果可以拥有一个基于 DataFrame API 的流处理模块,作为工程师的我们就不需要去用相对 low level 的 DStream API 去处理无边界数据,这样会大大提升我们的开发效率。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Spark 2.0版本推出的Structured Streaming模块基于DataFrame API,实现了对实时数据的处理和分析。相比低级的DStream API,DataFrame API提供了类似SQL的query接口,使得开发者能够更高效地处理无边界数据。Structured Streaming将流数据抽象成无边界的关系型数据表,并通过Spark SQL引擎实现对流数据的持续处理和更新计算结果。该模块支持完全模式、附加模式和更新模式的输出,并在事件时间处理上具有便利性。在使用Structured Streaming时,DataFrame既可以代表静态的有边界数据,也可以代表无边界数据,支持基于事件时间的时间窗口操作。在Spark 2.3版本中,Structured Streaming引入了连续处理的模式,进一步拓展了其应用广度。Structured Streaming对基于事件时间的处理有很好的支持,具有更好的容错性,保证了端到端exactly once的语义等等。综合来说,Structured Streaming是比Spark Streaming更好的流处理工具。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大规模数据处理实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • 青石
    watermark,process time - event time > watermark则直接丢失,process time - event time < watermark则接收数据处理,更新结果表。
    2019-05-29
    14
  • se7en
    同样都是微批处理,为什么spark streaming 就不能处理微秒,而structure streaming就可以
    2019-06-09
    2
    12
  • 彭琳
    关于思考题……据说是有水印机制,跟踪数据的事件时间,阈值内的延迟数据将会被聚合,比阈值更延迟的数据将被删除,在内存中留有一个中间状态。若有不对,请指正;不过推荐看一下这篇文章《Spark 2.3.0 Structured Streaming详解》,相当于官网翻译:https://blog.csdn.net/l_15156024189/article/details/81612860
    2020-01-14
    10
  • 大大丸子🍡
    1、Structured Streaming是基于事件事件处理,而不是处理事件,所以,延迟接收的数据,是能被统计到对应的事件时间窗口的 2、设定数据延迟的窗口时间阈值,通过判断阈值来决定延迟数据是否需要纳入统计;这个阈值的设定可以避免大量数据的延迟导致的性能问题
    2019-09-10
    7
  • 向黎明敬礼
    withWatermark函数第一个参数是 数据表中的时间戳字段的字段名,第二个参数是延迟的时间阈值
    2019-06-04
    4
  • Ming
    我不确定有没有完全理解问题.. 我想大概是因为,输出时间所对应的窗口可以故意设置的比输出时间稍微早一点,这样可以对数据延迟有一定的抗性。不然例子中的1:09分的数据就没机会被使用了。 不过相应的,这样的机制似乎终究是个妥协,妥协的越大,实时性就越差。
    2019-05-27
    4
  • Geek_86e573
    用过才知道,这个东西目前坑还挺多
    2019-06-20
    1
    3
  • CoderLean
    各个类的继承关系最好画一个图,不然在这几个章节打转搞得有点晕
    2019-06-18
    2
  • cricket1981
    spark structure streaming有没有类似flink的sideOutput机制?支持超过watermark的事件被处理到
    2019-05-27
    2
  • CoderLean
    最后的思考题只知道flink有一个watermark机制可以保证
    2019-06-19
    1
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部