大规模数据处理实战
蔡元楠
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讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

22 | Apache Beam的前世今生

蔡元楠 2019-06-10
你好,我是蔡元楠。
今天我要与你分享的主题是“ Apache Beam 的前世今生”。
从这一讲开始,我们将进入一个全新的篇章。在这一讲中,我将会带领你了解 Apache Beam 的完整诞生历程。
让我们一起来感受一下,Google 是如何从处理框架上的一无所有,一直发展到推动、制定批流统一的标准的。除此之外,我还会告诉你,在 2004 年发布了 MapReduce 论文之后,Google 在大规模数据处理实战中到底经历了哪些技术难题和技术变迁。我相信通过这一讲,你将会完整地认识到为什么 Google 会强力推崇 Apache Beam。
在 2003 年以前,Google 内部其实还没有一个成熟的处理框架来处理大规模数据。而当时 Google 的搜索业务又让工程师们不得不面临着处理大规模数据的应用场景,像计算网站 URL 访问量、计算网页的倒排索引(Inverted Index)等等。
那该怎么办呢?这个答案既简单又复杂:自己写一个。
没错,当时的工程师们需要自己写一个自定义的逻辑处理架构来处理这些数据。因为需要处理的数据量非常庞大,业务逻辑不太可能只放在一台机器上面运行。很多情况下,我们都必须把业务逻辑部署在分布式环境中。所以,这个自定义的逻辑处理架构还必须包括容错系统(Fault Tolerant System)的设计。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • JohnT3e
    文章中的几篇论文地址:
    0. MapReduce: https://research.google.com/archive/map reduce-osdi04.pdf
    1. Flumejava: https://research.google.com/pubs/archive/35650.pdf
    2. MillWheel: https://research.google.com/pubs/archive/41378.pdf
    3. Data flow Model: https://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf

    个人认为还是应该读一读的,毕竟几十年的发展不能靠看一两篇文章就搞清楚的

    作者回复: 👍

    2019-06-10
    37
  • 渡码
    我举一个前端技术变迁的例子,移动端开发最早分android和iOS分别开发,往往相同逻辑要不同团队开发两次,成本大且重复。后来出现h5 ,但h5性能不行。再后来fb推react native,在原生开发之上加了一层bridge,上层提供统一接口,下层分平台调用,这解决了h5的性能问题,但应用大了以后上层与原生层通信又是影响性能的瓶颈。后来谷歌推出了flutter 直接编译成不同平台运行代码,减少了中间通信过程,有点beam的意思。看来谷歌挺热衷于干这事

    作者回复: 谢谢分享!这个例子我觉得非常棒!

    2019-06-14
    16
  • coder
    感觉MapReduce、FlumeJava、Spark等这些框架的思想跟目前在ML领域大火的tensorflow类似。TensorFlow是把数据抽象成Tensor,有一系列对它的操作,conv、pooling等,dnn模型在框架内部的表示也是图的形式,计算图,节点表示计算,边表示tensor,通过在计算图上做调度和优化,转换成比较高效的计算图。再通过stream executor映射到具体的计算平台上,e.g. TPU,GPU等,操作会转换成库调用或者通过xla编译器转换成hlo IR,再经过一系列的优化,最终转换成具体硬件平台的指令。总之,这些框架背后的思想挺类似的

    作者回复: 谢谢你的留言!非常好的总结!

    2019-06-11
    4
  • morgan
    您好,beam和spark是什么关系呢?

    作者回复: 谢谢提问!Spark可以作为Beam的一个底层Runner来运行通过Beam SDK所编写的数据处理逻辑。我觉得在读完第23讲中所讲述的Beam生态圈后,你会对这个概念有一个更好的认识。

    2019-06-11
    3
  • CoderLean
    一直有个疑问,既然StructedStreaming已经实现了流批一致的API,为什么还要学Beam
    2019-07-05
    1
    2
  • 住羽光
    请问老师,是如何了解这些大数据处理框架的历史呢?,老师自己,有什么查找资料的好方法吗?

    作者回复: 谢谢你的提问!这个要靠平时多看看论文和听听大数据处理的Summit,当然其中也有和其他工程师交流知道的信息。

    2019-07-28
    1
  • Milittle
    onnx走的路子和beam一致呀

    作者回复: 谢谢分享啊!

    2019-06-24
  • linuxfans
    如蔡老师所说,任何新技术都要了解来龙去脉,尤其是如何解决当前问题的。但实际上操作起来,尤其在国内,我们是无法在网上找到线索或者文章分析新技术的动机和理念的,通常就是直接告诉你,我这个技术多好,可往往未必适合自己的场景,这个如何破?
    2019-06-16
收起评论
8
返回
顶部