22 | Apache Beam的前世今生
蔡元楠
该思维导图由 AI 生成，仅供参考
你好，我是蔡元楠。
今天我要与你分享的主题是“ Apache Beam 的前世今生”。
从这一讲开始，我们将进入一个全新的篇章。在这一讲中，我将会带领你了解 Apache Beam 的完整诞生历程。
让我们一起来感受一下，Google 是如何从处理框架上的一无所有，一直发展到推动、制定批流统一的标准的。除此之外，我还会告诉你，在 2004 年发布了 MapReduce 论文之后，Google 在大规模数据处理实战中到底经历了哪些技术难题和技术变迁。我相信通过这一讲，你将会完整地认识到为什么 Google 会强力推崇 Apache Beam。
在 2003 年以前，Google 内部其实还没有一个成熟的处理框架来处理大规模数据。而当时 Google 的搜索业务又让工程师们不得不面临着处理大规模数据的应用场景，像计算网站 URL 访问量、计算网页的倒排索引（Inverted Index）等等。
那该怎么办呢？这个答案既简单又复杂：自己写一个。
没错，当时的工程师们需要自己写一个自定义的逻辑处理架构来处理这些数据。因为需要处理的数据量非常庞大，业务逻辑不太可能只放在一台机器上面运行。很多情况下，我们都必须把业务逻辑部署在分布式环境中。所以，这个自定义的逻辑处理架构还必须包括容错系统（Fault Tolerant System）的设计。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Apache Beam的前世今生 Apache Beam是一个统一的大规模数据处理框架，其发展历程源自Google的Dataflow Model。该框架整合了多个优秀的大规模数据处理框架的优点，旨在提供统一的API来处理批处理和流处理数据。文章首先介绍了Google在处理大规模数据之前的挑战，以及MapReduce的诞生和成功。随后，详细介绍了FlumeJava的思想和优势，以及Millwheel项目对无边界数据的支持。文章还提到了Dataflow Model的诞生和Google推出的Cloud Dataflow平台。Apache Beam的名字来源于其统一了批处理和流处理的框架，意在解决不同平台上运行程序的问题。该框架支持多种Runner，包括Apache Spark和Apache Flink，并且目标是支持任意多的编程语言来编写。总之，Apache Beam的发展历程展示了其在大规模数据处理领域的重要性和影响，为读者提供了对其前世今生的快速了解。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《大规模数据处理实战》，新⼈⾸单¥59
《大规模数据处理实战》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(9)
- 最新
- 精选
- 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-10278 
渡码我举一个前端技术变迁的例子，移动端开发最早分android和iOS分别开发，往往相同逻辑要不同团队开发两次，成本大且重复。后来出现h5 ，但h5性能不行。再后来fb推react native，在原生开发之上加了一层bridge，上层提供统一接口，下层分平台调用，这解决了h5的性能问题，但应用大了以后上层与原生层通信又是影响性能的瓶颈。后来谷歌推出了flutter 直接编译成不同平台运行代码，减少了中间通信过程，有点beam的意思。看来谷歌挺热衷于干这事作者回复: 谢谢分享！这个例子我觉得非常棒！
2019-06-1441
coder感觉MapReduce、FlumeJava、Spark等这些框架的思想跟目前在ML领域大火的tensorflow类似。TensorFlow是把数据抽象成Tensor，有一系列对它的操作，conv、pooling等，dnn模型在框架内部的表示也是图的形式，计算图，节点表示计算，边表示tensor，通过在计算图上做调度和优化，转换成比较高效的计算图。再通过stream executor映射到具体的计算平台上，e.g. TPU，GPU等，操作会转换成库调用或者通过xla编译器转换成hlo IR，再经过一系列的优化，最终转换成具体硬件平台的指令。总之，这些框架背后的思想挺类似的作者回复: 谢谢你的留言！非常好的总结！
2019-06-11215- morgan您好，beam和spark是什么关系呢？
作者回复: 谢谢提问！Spark可以作为Beam的一个底层Runner来运行通过Beam SDK所编写的数据处理逻辑。我觉得在读完第23讲中所讲述的Beam生态圈后，你会对这个概念有一个更好的认识。
2019-06-114 
住羽光请问老师，是如何了解这些大数据处理框架的历史呢？，老师自己，有什么查找资料的好方法吗？作者回复: 谢谢你的提问！这个要靠平时多看看论文和听听大数据处理的Summit，当然其中也有和其他工程师交流知道的信息。
2019-07-281
Milittleonnx走的路子和beam一致呀作者回复: 谢谢分享啊！
2019-06-24
CoderLean一直有个疑问，既然StructedStreaming已经实现了流批一致的API，为什么还要学Beam2019-07-0545
Eden2020经历过数据库技术变迁，关系数据库，面向分析的列式数据库，分布式文档数据库，时序数据库，图数据库等等2020-03-272
linuxfans如蔡老师所说，任何新技术都要了解来龙去脉，尤其是如何解决当前问题的。但实际上操作起来，尤其在国内，我们是无法在网上找到线索或者文章分析新技术的动机和理念的，通常就是直接告诉你，我这个技术多好，可往往未必适合自己的场景，这个如何破？2019-06-162
收起评论
