大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8443 人已学习
课程目录
已完结 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讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

26 | Pipeline:Beam如何抽象多步骤的数据流水线?

蔡元楠 2019-06-21
你好,我是蔡元楠。
今天我要与你分享的主题是“Pipeline:Beam 如何抽象多步骤的数据流水线”。
在上两讲中,我们一起学习了 Beam 是如何抽象封装数据,以及如何抽象对于数据集的转换操作的。在掌握了这两个基本概念后,我们就可以很好地回答 Beam 编程模型里的 4 个维度 What、Where、When、How 中的第一个问题——What 了。也就是,我们要做什么计算?想得到什么样的结果?
这个时候你可能已经跃跃欲试,开始想用 PCollection 和 Transform 解决我们平常经常会使用到的批处理任务了。没有问题,那我们就先抛开 Where、When 和 How 这三个问题,由简至繁地讲起。
现在假设我们的数据处理逻辑只需要处理有边界数据集,在这个情况下,让我们一起来看看 Beam 是如何运行一套批处理任务的。

数据流水线

在 Beam 的世界里,所有的数据处理逻辑都会被抽象成数据流水线(Pipeline)来运行。那么什么是数据流水线呢?
Beam 的数据流水线是对于数据处理逻辑的一个封装,它包括了从读取数据集将数据集转换成想要的结果输出结果数据集这样的一整套流程。
所以,如果我们想要跑自己的数据处理逻辑,就必须在程序中创建一个 Beam 数据流水线出来,比较常见的做法是在 main() 函数中直接创建。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • espzest
    bundle怎么聚合成pcollection? 一个bundle处理失败,为什么需要重做前面的bundle?

    作者回复: 谢谢你的提问!其实我们在第24讲中知道,PCollection是具有无序性的,所以最简单的做法bundle在处理完成之后可以直接append到结果PCollection中。

    至于为什么需要重做前面的bundle,这其实也是错误处理机制的一个trade-off了。Beam希望尽可能减少persistence cost,也就是不希望将中间结果保持在某一个worker上。可以这么想,如果我们想要不重新处理前面的bundle,我们必须要将很多中间结果转换成硬盘数据,这样一方面增加很大的时间开销,另一方面因为数据持久化了在具体一台机器上,我们也没有办法再重新动态分配bundle到不同的机器上去了。

    2019-06-21
    9
  • cricket1981
    bundle随机分配会不会产生数据倾斜?完美并行背后的机制是?beam应该也有类似spark的persist方法缓存转换中间结果,防止出错恢复链太长吧?

    作者回复: 谢谢你的提问!其实文章中所讲到的随机分配并不是说像分配随机数那样将bundle随机分配出去给workers,只是说根据runner的不同,bundle的分配方式也会不一样了,但最终还是还是希望能最大化并行度。

    至于完美并行的背后机制,Beam会在真正处理数据前先计算优化出执行的一个有向无环图,希望保持并行处理数据的同时,能够减少每个worker之间的联系。

    Beam据我所知是有的,BEAM-7131 issue就有反应这个问题。

    2019-06-21
    5
  • 沈洪彬
    在 Beam 的数据流水线中,当处理的元素发生错误时流水线的的错误处理机制分两种情况

    1.单个Transform上的错误处理
    如果某个Bundle里元素处理失败,则整个Bundle里元素都必须重新处理

    2.多步骤Transform上的错误处理
    如果某个Bundle里元素处理失败,则整个Bundle里元素及与之关联的所有Bundle都必须重新处理

    作者回复: 谢谢留言!总结得不错!

    2019-06-23
    3
  • YZJ
    老师请教个问题:PCollectionA transform PCollectionB, 假如PCollectionB 要比PCollectionA大很多倍,比如transform 是把PCollectionA 中每个字符串重复1000次,那PCollectionB 就要大1000倍,worker会不会有内存溢出问题? spark中可以配置executor 的core和memery来控制每个task内存用量,beam有类似机制吗?不然怎样让资源利用最优化呢?

    作者回复: 谢谢你的提问!这个问题很好啊,运行大型的Beam pipeline遇到OOM也是有可能的。要配置底层资源的话要看Runner支不支持,像如果将Google Cloud Dataflow作为Runner的话,我们可以通过配置PipelineOption来达到目的。底层使用Spark的话我个人还没有使用过,不过应该是可以用SparkContextOptions来配置的。

    2019-06-21
    3
  • AF
    Beam的错误处理和RDD的真的很像,因为transformation都是lazy的,只有action才会触发计算,中间的转换过程都是被记录在DAG中的,这就导致中间某个transformation失败之后,需要往上追溯之前的转换,可以理解为是寻找父transformation,然后父transformation还要往上寻找父父transformation,直到没有父transformation为止,就像是类加载机制一样。但是如果能把中间结果保存在内存中,在失败重新计算时,就能提高计算的效率。

    作者回复: 的确如此

    2019-06-26
    2
  • Alpha
    上一期讲到,PCollection 是有向图中的边,而 Transform 是有向图里的节点。这一期的图咋又变了呢

    作者回复: 谢谢留言!哈哈,需要表达的内容不一样了。

    2019-06-21
    1
  • 常超
    <在多步骤的 Transform 上,如果处理的一个 Bundle 元素发生错误了,则这个元素所在的整个 Bundle 以及与这个 Bundle 有关联的所有 Bundle 都必须重新处理。
    如果upstream transform里状态有更新操作,重新处理已经成功的bundle会出现数据重复,可能导致状态更新不正确吧?

    作者回复: 谢谢你的提问!这个问题非常好啊,如果你所说的是stateful processing的话,那它的错误处理机制和stateful-less会不太一样。Stateful processing里的ParDo在处理每一个元素的时候会将它的state持久化,也就是保存到外部的storage中,下次需要用到这个元素的时候会再读取这个元素的state。如果是发生了错误的话,会有机制reclaim这些states或者是invalidate它们。

    2019-06-21
    1
  • onepieceJT2018
    老师 想到一个问题啊 如果有个计算是 需要worker1 和 worker2 都算完的结果再计算 发生worker1 一直错误没通过 这时候worker2会一直傻傻等待嘛

    作者回复: 谢谢你的提问!这个依赖worker1和worker2计算结果的Transform会一直等待。但是与此同时,worker2可以做其它的计算,甚至有可能worker1的计算如果一直出错,Beam会将这个bundle重新分配给worker2来计算。

    2019-06-21
    1
  • jimyth
    老师你好,既然PCollection 是无序的,请问一下怎么处理数据流中的先后依赖的问题,本节例子的 bound中的数据都是有序的分配的,实际计算过程中是不是会出现 1,3,5出现在一个 bound ;2,4,6 出现在一个 bound
    您在 23 讲的例子中,ParDo 是针对单个元素的处理,怎么实现计算2 个元素的累加的呢?
    例如下面是一组速度数据
    时间 速度
    2019-07-26 00:00:00 10
    2019-07-26 00:00:01 15
    2019-07-26 00:00:02 20
    2019-07-26 00:00:03 40
    2019-07-26 00:00:04 70
    我需要大概怎么计算加速度,
    2019-07-26
  • chief
    老师您好,bundle经过Transform会产生新的bundle,那么是同时保留前后bundle数据还是在新生成的bundle中保留血缘关系?

    作者回复: 谢谢你的留言!前后bundle保不保留这个还要看你的执行DAG需不需要还用到这个bundle。至于保留前后关系的话主要是用于在发生错误的情况下重新trace back到最开始的那个transform,这个信息从DAG中就可以找到了。

    2019-07-04
  • fy
    老师,有编程语言基础。我也去Beam看了看教程,请问这个可以直接学吧。还需要其他基础么,比如操作系统,计算机组成原理等

    作者回复: 谢谢你的留言!确实是可以直接学习,不过我也建议如果平时有时间的话,可以看看这些计算机的基础。像操作系统的话里面的一些调度算法或许可以给你平时的实际应用有一些启发。

    2019-06-23
  • TJ
    能否说一下Beam和底层执行系统的边界在哪里?那些功能由Beam提供,那些由底层如Spark提供?
    如果底层是spark,是否PCollection就是RDD?

    作者回复: 谢谢你的留言!如果我没有理解错你的问题的话,我想你说的“边界”指的就是在第23讲中讲到的Beam的统一模型层了。

    其实Beam提供的是在Dataflow Model论文里面的一种批流统一处理的思想,数据处理引擎如果能够按照这个思想提供出相应的APIs的话那这个数据处理引擎就可以成为Beam的底层Runner。

    最后一问的话是的,PCollection抽象就是Spark中的RDD。

    2019-06-21
  • JohnT3e
    由于beam优化器,是不是实际产生的bundle要少于逻辑上的个数?

    作者回复: 谢谢你的留言!你这样的理解其实也没有错,如果Beam优化器能优化合并掉一些步骤的话,那确实实际产生出来的bundle会比理论上可以产生出来的bundle要少。

    2019-06-21
  • dancer
    想问老师,一个bundle的数据必须要全部处理完之后才能进行第二个transform吗?如果部分数据经过transform1后就可以继续执行transform2,这样数据并行度会更高吧,为什么没有采用这种机制呢?

    作者回复: 谢谢你的提问!这个问题还是要看情况吧,如果多步骤的Transform都是ParDo的话,那确实可以按照你说的做法去做。不过当Transform涉及到Combine或者Flatten这种Transform的话, 那就必须等到这一阶段所有的Transform完成了之后才能够进行下一步的Transform了。

    2019-06-21
收起评论
14
返回
顶部