大规模数据处理实战
蔡元楠
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讲)
结束语 | 世间所有的相遇，都是久别重逢
大规模数据处理实战
登录|注册
12 | 我们为什么需要Spark？
蔡元楠 2019-05-13
你好，我是蔡元楠。
今天我要与你分享的主题是“我们为什么需要 Spark”。
也许你之前没有做过大规模数据处理的项目，但是 Spark 这个词我相信你一定有所耳闻。
Spark 是当今最流行的分布式大规模数据处理引擎，被广泛应用在各类大数据处理场景。
2009 年，美国加州大学伯克利分校的 AMP 实验室开发了 Spark。2013 年，Spark 成为 Apache 软件基金会旗下的孵化项目。
而现在，Spark 已经成为了该基金会管理的项目中最活跃的一个。Spark 社区也是成长迅速，不仅有数以千计的个人贡献者在不断地开发维护，还有很多大公司也加入了这个开源项目，如 Databricks、IBM 和华为。
在技术不断高速更迭的程序圈，一个新工具的出现与流行，必然是因为它满足了很大一部分人长期未被满足的需求，或是解决了一个长期让很多人难受的痛点。
所以，在学一个新技术之前，你有必要先了解这门技术出现的意义。这样，你才能更好地理解：它是应用到什么场景的？与同类工具相比，它的优缺点是什么？什么时候用它比其它工具好（或差）？……
至少理解了这些，你才好说自己是真正掌握了这个工具，否则只能说是浅尝辄止，半生不熟。
学习 Spark 同样是如此。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(22)
jonmr编程模型单一，维护成本高，多个job执行时每个都要数据落盘。而spark拥有更高的抽象级别rdd，一次读取数据后便可在内存中进行多步迭代计算，对rdd的计算是多线程并发的所有很高效。
但是spark依然会存在数据倾斜的情况，在shuffle时有可能导致一个成为数据热点的情况作者回复: 这位同学的理解很对！
2019-05-13 19
朱同学似乎数据倾斜是所有分布式计算引擎的通病2019-05-13 13
AFSpark和MR的两个区别：
1. MapReduce编程模型中，每一对map和reduce都会生成一个job，而且每一次都是写磁盘，这就造成老师所说的启动时间变长，而且维护起来比较复杂；而Spark是链式计算，像map、flatmap、filter等transformation算子是不会触发计算的，只有在遇到像count、collect、saveAsTable等Action算子时，才会真正触发一次计算，对应会生成一个job。
2. MapReduce每次的MR结果都是保存到磁盘，所以时间开销大；而Spark在执行应用程序是，中间的处理过程、数据(RDD)的缓存和shuffle操作等都是在内存允许的情况下，放在内存中的，所以耗时短。作者回复: 很好的总结
2019-05-13 7
蒙开强老师，你好，我看你专栏里说到，MapReduce 是多进程模型。我有点疑惑，MapReduce的map阶段和reduce阶段都有并行task进行运行，它们的task不是线程级别么。作者回复: Map和Reudce的Task都是进程级别的，这也是MapReduce广为人诟病的原因
2019-05-13 1 6- JohnT3e1. spark本质上还是批处理，只是通过微批处理来实现近实时处理。如果需要实时处理，可以使用apache flink；
2. 小文件处理依然有性能问题；
3. 仍需要手动调优，比如如何让数据合理分区，来避免或者减轻数据倾斜作者回复: 说的很好！
2019-05-13 5 
涵老师讲到Hadoop的四个缺陷，前三个都讲到了Spark的解决方案，比如抽象层次更合理，易于使用，可用的方法更多，不限于map和reduce，还有将迭代的计算结果放入内存，提升迭代计算的效率，降低能耗。但是没有提到第四个只能批量处理数据的问题。这是不是Spark的局限?作者回复: 看过后边几讲你就明白了，Spark有Spark Streaming和Structured Streaming的流处理模块，所以它并不是只能做批量处理。
2019-05-15 3
楚翔stylesparkcontext不能在集群全局共享，比如我submit了100个spark任务，每个任务都要初始化自己的sc，还要销毁，每一次的创建销毁都很耗时。 这块有什么策略可以优化下吗？ 谢谢2019-05-13 3
珅剑Spark在Shuffle阶段依然有可能产生大量的小文件，大量的随机读写造成磁盘IO性能下降，2019-06-09 2
锦Spark是在MapReduce的基础上一点点通过工程和学术相结合做出来的，那么是不是意味着背后的理论模型都是分治思想？
相对于MapReduce多进程模型来说，Spark基于多线程模型，启动速度更快，Cpu利用率更好和内存共享更好。
MapReduce只提供Map和Reduce操作，而Spark中最基本的弹性分布式数据结构RDD，提供丰富的Api，对机器学习，人工智能更友好，更适用于现代数据处理场景。
MapReduce计算后的中间数据需要落盘，而Spark的中间数据缓存在内存中用于后续迭代，速度更快。
疑问:Spark相对于Storm在流计算中有哪些优势呢？作者回复: 看过后边讲Spark流处理的章节就明白了，Storm的优势是纯实时处理，延迟可以到毫秒级，所以试用于需要低延迟的实时场景。我认为Spark在纯流处理上唯一的优势是吞吐量要高。但是考虑使用Spark Streaming最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性
2019-05-13 2
miwucc感觉mapreduce遗留的问题还有
1.数据分片分不好，导致数据过于集中在某机器导致整体处理速度慢或者无法处理问题。spark还是全靠使用者的分片函数还是自己有方法可以动态调度？
2.对于实际复杂业务中的多job前后依赖，与业务紧密耦合的异常捕捉，处理机制是否有更好的解决方法？作者回复: 你说的很好，这两个问题都是分布式计算的痛点。用Spark的RDD API没有自动优化数据分区，很依赖开发者手动调优。后边讲到的Spark SQL的执行引擎会有这方面的优化，性能要显著优于RDD。
2019-05-13 2- Geek_59总用scala 写spring cloud项目，属于杀鸡用牛刀吗？2019-05-14 1
启能spark和flink，这两个都是分布式数据处理框架，项目中应该怎么选？作者回复: 相信你看完21讲应该就知道了，Flink在流处理上有天然的优势，而Spark虽然有各种流处理的模块，但还是做批处理比较擅长。看完21讲中Spark和Flink的对比之后相信你可以做出选择
2019-05-13 1- 走小調的凡世林请教下老师，我们有个需求：根据各种自定义规则（比如分辨率、大小等）计算海量资源的分数（资源可以是图片、视频、音频）。总分100，图片分辨率太小或视频太大都要扣分，最后算出一个资源总分，这种需求可以用spark实现吗？主要考虑算分过程可能比较耗时，且资源数量较多。如果可以的话如何实现呢？老师是否可以提供下思路，感谢！2019-11-30
趁早k8s,mesos都知识编排工具吧，那具体数据存哪里呢2019-07-20
darren可以为每个进程设定使用资源，对每个线程就不好控制2019-07-02
滩涂曳尾怎么感觉spark相比hadoop只是做了一些工程上的优化，多线程vs多进程(类比apache vs. nginx)，内存缓存磁盘数据，... 学了后面的再看2019-06-30- 13311195819老师好，您文章中提到“MapReduce 状态机“，这个词该怎么理解呢？是不是类似于flink中state的概念？2019-06-19
一老师好，“多进程模型便于细粒度控制每个任务占用的资源”这一句不太理解，进程不是粗粒度的概念吗？为什么以进程为单位的并发反而便于细粒度的控制每个任务占用的资源呢？2019-05-24 1- 利利1. MR、Spark都有shuffle，shuffle难免出现数据倾斜
2.流计算上的不足：MR就不说了，SparkStreaming只能算微批处理，尽管Spark的StructStreaming已经在这方面做了改进，但是思想貌似无法改变，spark就是以批处理的思想来处理流数据，这方面感觉没法跟flink比，不过交互式查询、ML以及生态上会比flink强作者回复: 很好的总结
2019-05-13 
大鹏两者共存的数据热点问题，依然需要手工介入，一个方法是减少无用的信息，第二个就是单独处理且分而治之2019-05-13
收起评论