大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8436 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从这里开始,带你走上硅谷一线系统架构师之路
免费
模块一 | 直通硅谷大规模数据处理技术 (3讲)
01 | 为什么MapReduce会被硅谷一线公司淘汰?
02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?
03 | 大规模数据处理初体验:怎样实现大型电商热销榜?
模块二 | 实战学习大规模数据处理基本功 (8讲)
04 | 分布式系统(上):学会用服务等级协议SLA来评估你的系统
05 | 分布式系统(下):架构师不得不知的三大指标
06 | 如何区分批处理还是流处理?
07 | Workflow设计模式:让你在大规模数据世界中君临天下
08 | 发布/订阅模式:流处理架构中的瑞士军刀
09 | CAP定理:三选二,架构师必须学会的取舍
10 | Lambda架构:Twitter亿级实时数据分析架构背后的倚天剑
11 | Kappa架构:利用Kafka锻造的屠龙刀
模块三 | 抽丝剥茧剖析Apache Spark设计精髓 (10讲)
12 | 我们为什么需要Spark?
13 | 弹性分布式数据集:Spark大厦的地基(上)
14 | 弹性分布式数据集:Spark大厦的地基(下)
15 | Spark SQL:Spark数据查询的利器
16 | Spark Streaming:Spark的实时流计算API
17 | Structured Streaming:如何用DataFrame API进行实时数据分析?
18 | Word Count:从零开始运行你的第一个Spark应用
19 | 综合案例实战:处理加州房屋信息,构建线性回归模型
20 | 流处理案例实战:分析纽约市出租车载客信息
21 | 深入对比Spark与Flink:帮你系统设计两开花
模块四 | Apache Beam为何能一统江湖 (8讲)
22 | Apache Beam的前世今生
23 | 站在Google的肩膀上学习Beam编程模型
24 | PCollection:为什么Beam要如此抽象封装数据?
25 | Transform:Beam数据转换操作的抽象方法
26 | Pipeline:Beam如何抽象多步骤的数据流水线?
27 | Pipeline I/O: Beam数据中转的设计模式
28 | 如何设计创建好一个Beam Pipeline?
29 | 如何测试Beam Pipeline?
模块五 | 决战 Apache Beam 真实硅谷案例 (7讲)
30 | Apache Beam实战冲刺:Beam如何run everywhere?
31 | WordCount Beam Pipeline实战
32 | Beam Window:打通流处理的任督二脉
33 | 横看成岭侧成峰:再战Streaming WordCount
34 | Amazon热销榜Beam Pipeline实战
35 | Facebook游戏实时流处理Beam Pipeline实战(上)
36 | Facebook游戏实时流处理Beam Pipeline实战(下)
模块六 | 大规模数据处理的挑战与未来 (4讲)
37 | 5G时代,如何处理超大规模物联网数据
38 | 大规模数据处理在深度学习中如何应用?
39 | 从SQL到Streaming SQL:突破静态数据查询的次元
40 | 大规模数据处理未来之路
专栏加餐 | 特别福利 (4讲)
FAQ第一期 | 学习大规模数据处理需要什么基础?
加油站 | Practice makes perfect!
FAQ第二期 | Spark案例实战答疑
FAQ第三期 | Apache Beam基础答疑
结束语 (1讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

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

蔡元楠 2019-05-27
你好,我是蔡元楠。
上一讲中,我们介绍了 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(22)

  • se7en
    同样都是微批处理,为什么spark streaming 就不能处理微秒,而structure streaming就可以
    2019-06-09
    1
    6
  • Ming
    我不确定有没有完全理解问题..

    我想大概是因为,输出时间所对应的窗口可以故意设置的比输出时间稍微早一点,这样可以对数据延迟有一定的抗性。不然例子中的1:09分的数据就没机会被使用了。

    不过相应的,这样的机制似乎终究是个妥协,妥协的越大,实时性就越差。
    2019-05-27
    3
  • cricket1981
    spark structure streaming有没有类似flink的sideOutput机制?支持超过watermark的事件被处理到
    2019-05-27
    2
  • 大大丸子🍡
    1、Structured Streaming是基于事件事件处理,而不是处理事件,所以,延迟接收的数据,是能被统计到对应的事件时间窗口的
    2、设定数据延迟的窗口时间阈值,通过判断阈值来决定延迟数据是否需要纳入统计;这个阈值的设定可以避免大量数据的延迟导致的性能问题
    2019-09-10
    1
  • Geek_86e573
    用过才知道,这个东西目前坑还挺多
    2019-06-20
    1
  • CoderLean
    最后的思考题只知道flink有一个watermark机制可以保证
    2019-06-19
    1
  • CoderLean
    各个类的继承关系最好画一个图,不然在这几个章节打转搞得有点晕
    2019-06-18
    1
  • 向黎明敬礼
    withWatermark函数第一个参数是 数据表中的时间戳字段的字段名,第二个参数是延迟的时间阈值
    2019-06-04
    1
  • 青石
    watermark,process time - event time > watermark则直接丢失,process time - event time
    < watermark则接收数据处理,更新结果表。
    2019-05-29
    1
  • AF
    一般是处理滞后一定时间的数据,超过了这个时间范围,就会舍弃
    2019-05-27
    1
  • 方伟
    我知道在flink中可以通过watermark来处理这样的场景,在Structured Streaming中应该也是这样的方式来处理吧。
    2019-05-27
    1
  • Rainbow
    10分钟统计一次,按照处理时间分1:00-1:10,1:10-1:20;所以单词的处理时间位于第二个区间会被第二次统计到;如果按照事件时间,sql里time>1:00 and time<1:10就可以把单词归类到第一个区间,这么理解对吗,老师?
    2019-05-27
    1
  • .
    各位大佬好,流式处理应该消息应该只被消费一次吧,waterMark机制可以确保在1:20输出,什么情况下在1:10输出了对应的结果呢?求解。
    2019-11-26
  • windcaller
    我用那个withWaterMark限制时间窗口进行思考题中的数据过滤时候,就感觉怪怪的,有时候放弃掉,有时候就怎么都不放弃,一直不太理解这块内容
    2019-07-27
  • 淹死的大虾
    structure streaming相当于一直在更新输出一个表,这个表有事件时间信息,所以可以按事件时间处理;spark streaming只能按处理时间来的rdd处理,缺少一个汇总
    2019-06-26
  • 张凯江
    输出模式支持呀。
    完全模式和更新模式哈。
    2019-05-29
  • 我觉得可能是通过冗余计算上一个时间窗口中的数据来实现的。
    局限性就是不支持迟到太久的数据
    2019-05-29
  • 周凯
    程序在1:10处理的是1:09之前生成的数据,往后推10分钟,那1:20处理的是1:19之前生成的数据
    2019-05-29
  • 胡鹏
    老师, 我最近遇到个问题还望帮忙提点一下:
    1. 需求: 统计实时订单量(类似)
    2. 通过maxwell读取binlog数据同步到kafka
    3. spark-streaming处理kafka里面的数据
    4. spark-sql定义不同的实时报表

    这样做的时候, 对于不同sql定义的报表我就懵了,
       假如昨天需求方写了10个SQL放到数据库, 然后我们启动流计算, 提交job到spark, 那么10个实时的报表就开始变动起来了
       但是今天需求方说, 这里还有两个指标需要统计一下, 就给我了2条SQL,

    (先说明下前提, maxwell把mysql的数据提取出来提交到了一个kafka的topic里面)
    疑问点出来了:
        1. 如果从新提交一个2条sql的job, 就得独立消费kafka数据, 否则数据有遗漏, (相当于一条河流, 做了多个截断), 与其对比的是: 在之前提交10个SQL的job中, 先写好SQL来源是动态从某个数据库某张表取出来的, 然后数据流来了直接共享server进行计算, (相当于一条河流一次截断, 多个筛选, 复用了job的提交和kafka消费这一步), 不知道后者是否可行, 或是有什么坑?
        2. 假如选择了问题1 的第一种情况, 且假如重复消费很消耗新能, 然后我想到了替代方案,不同的数据库binlog放到不同的kafka的topic中, 计算出结果之后再聚合, (这样做缺点是不是就是开发程序非常麻烦呢)?

    目前存在如上两个疑问, 我目前觉得第一个问题的第二种情况比较靠谱, 希望可以求证, 或者我原本思考方向就是错的, 还望老师帮忙指点一下
    2019-05-29
  • RocWay
    我的理解是:虽然设立了窗口,但是有些事件可能由于网络或其他原因迟到了,这些迟到的事件也要被计算在内。否则这段窗口内的数据计算就会“不准”。当然也不能无限允许迟到,所以Spark也设立了watermark。如果窗口的结束时间减去watermark,比某个事件的时间还“晚”,那这个事件就不能算在这个窗口里。
    2019-05-28
收起评论
22
返回
顶部