12 | 我们为什么需要Spark？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Spark是当今最流行的分布式大规模数据处理引擎，相比于MapReduce具有更高的性能、易于开发和维护，以及更高的适用性。通过弹性分布式数据集（RDD）提供了丰富的操作，如Map、Filter、flatMap、groupByKey和Union等，极大地提升了对各种复杂场景的支持。与MapReduce相比，Spark将中间数据缓存在内存中，大大减少了由于硬盘读写而导致的延迟，从而提高了处理速度。在机器学习和人工智能领域，Spark表现出色，处理速度是Hadoop的数倍甚至数十倍。此外，Spark还提供了多个扩展库，如Spark SQL、Spark Streaming、MLlib、GraphX和SparkR，使得其适用范围更加广泛。尽管Spark并非完全替代Hadoop的全新工具，但其优势和扩展库的丰富性使其成为当今最流行的数据处理平台之一。 在Spark框架中，仍然存在一些MapReduce的缺点，例如对于小文件的处理效率较低、对于实时数据处理的支持不足等。针对这些问题，可以通过合并小文件、使用Spark Streaming等技术来提高处理效率和支持实时数据处理，从而解决这些问题。 Spark的发展和不断完善将进一步提升其在大数据处理领域的地位，为用户提供更加高效、灵活的数据处理解决方案。
《大规模数据处理实战》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
jonmr编程模型单一，维护成本高，多个job执行时每个都要数据落盘。而spark拥有更高的抽象级别rdd，一次读取数据后便可在内存中进行多步迭代计算，对rdd的计算是多线程并发的所有很高效。 但是spark依然会存在数据倾斜的情况，在shuffle时有可能导致一个成为数据热点的情况作者回复: 这位同学的理解很对！
2019-05-1343- JohnT3e1. spark本质上还是批处理，只是通过微批处理来实现近实时处理。如果需要实时处理，可以使用apache flink； 2. 小文件处理依然有性能问题； 3. 仍需要手动调优，比如如何让数据合理分区，来避免或者减轻数据倾斜
作者回复: 说的很好！
2019-05-1320 
西南偏北Spark和MR的两个区别： 1. MapReduce编程模型中，每一对map和reduce都会生成一个job，而且每一次都是写磁盘，这就造成老师所说的启动时间变长，而且维护起来比较复杂；而Spark是链式计算，像map、flatmap、filter等transformation算子是不会触发计算的，只有在遇到像count、collect、saveAsTable等Action算子时，才会真正触发一次计算，对应会生成一个job。 2. MapReduce每次的MR结果都是保存到磁盘，所以时间开销大；而Spark在执行应用程序是，中间的处理过程、数据(RDD)的缓存和shuffle操作等都是在内存允许的情况下，放在内存中的，所以耗时短。作者回复: 很好的总结
2019-05-1314
锦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-1310
蒙开强老师，你好，我看你专栏里说到，MapReduce 是多进程模型。我有点疑惑，MapReduce的map阶段和reduce阶段都有并行task进行运行，它们的task不是线程级别么。作者回复: Map和Reudce的Task都是进程级别的，这也是MapReduce广为人诟病的原因
2019-05-1328
miwucc感觉mapreduce遗留的问题还有 1.数据分片分不好，导致数据过于集中在某机器导致整体处理速度慢或者无法处理问题。spark还是全靠使用者的分片函数还是自己有方法可以动态调度？ 2.对于实际复杂业务中的多job前后依赖，与业务紧密耦合的异常捕捉，处理机制是否有更好的解决方法？作者回复: 你说的很好，这两个问题都是分布式计算的痛点。用Spark的RDD API没有自动优化数据分区，很依赖开发者手动调优。后边讲到的Spark SQL的执行引擎会有这方面的优化，性能要显著优于RDD。
2019-05-135
涵老师讲到Hadoop的四个缺陷，前三个都讲到了Spark的解决方案，比如抽象层次更合理，易于使用，可用的方法更多，不限于map和reduce，还有将迭代的计算结果放入内存，提升迭代计算的效率，降低能耗。但是没有提到第四个只能批量处理数据的问题。这是不是Spark的局限?作者回复: 看过后边几讲你就明白了，Spark有Spark Streaming和Structured Streaming的流处理模块，所以它并不是只能做批量处理。
2019-05-154- 挖矿的小戈1. MR、Spark都有shuffle，shuffle难免出现数据倾斜 2.流计算上的不足：MR就不说了，SparkStreaming只能算微批处理，尽管Spark的StructStreaming已经在这方面做了改进，但是思想貌似无法改变，spark就是以批处理的思想来处理流数据，这方面感觉没法跟flink比，不过交互式查询、ML以及生态上会比flink强
作者回复: 很好的总结
2019-05-134 
竹鹏spark和flink，这两个都是分布式数据处理框架，项目中应该怎么选？作者回复: 相信你看完21讲应该就知道了，Flink在流处理上有天然的优势，而Spark虽然有各种流处理的模块，但还是做批处理比较擅长。看完21讲中Spark和Flink的对比之后相信你可以做出选择
2019-05-132
CoderLeanSparksql是不是用来替代hive的一个工具作者回复: 这个我们在15讲Spark SQL中有详细的讲解它的发展历程，它确实是用来让Spark摆脱对Hive的依赖而发展来的。
2019-05-1321
