标签：Spark

共 6 篇相关文章

IT 累计浏览 2,061

60 TB 数据：Facebook 是如何大规模使用 Apache Spark 的

这篇讲的是Facebook如何将一个关键的大数据流水线，从古老的Hive迁移到现代的Apache Spark上。背景是，他们用于实时实体排名的特征准备流程，原本基于Hive，由数百个小作业组成，耗时长达三天，且极其难以监控和维护。为了追求更快的速度和更好的可管理性，他们选择将整个流水线整合成一个单独的Spark作业，直接处理高达60TB的压缩数据。迁移过程并非一帆风顺。作者坦言，第一次甚至第十次尝试都未成功，因为要可靠地运行一个处理如此大规模shuffle数据的作业，挑战巨大。团队对Spark的可靠性进行了大量修补，例如提升节点频繁重启时的容错能力，修复了从PipedRDD获取失败到执行器内存溢出等一系列问题。这使得作业得以稳定运行。在性能优化上，他们的努力同样深入。通过自定义的火焰图等分析工具定位瓶颈后，他们对Spark底层进行了关键修改：修复排序器的内存泄漏带来了30%的速度提升；优化Snappy压缩调用节省了10% CPU；减少不必要的重排文件打开操作最高提升了50%的性能。最终，这个迁移项目不仅让Facebook自身受益，所有改进也被回馈给了开源Apache Spark社区。

IT 累计浏览 3,540

Spark性能优化——和shuffle搏斗

这篇讲的是Spark性能调优中一个最头疼的问题——shuffle。作者把shuffle比作必须击败的“大boss”，因为它会触发大量网络传输和序列化，让原本在内存中飞快的计算慢下来。文章没有堆砌理论，而是直接切入实战技巧。比如，作者用一个从3小时缩短到20分钟的例子，说明“先各自去重，再合并”为何能大幅减少shuffle数据量；还对比了`mapValues`与`map`、`reduceByKey`与`groupByKey`，点明哪些操作会偷偷引发shuffle，而哪些能保持本地高效计算。针对常见的大小表join，文章给出了一个巧妙思路：把小表广播出去，用`broadcast`加`filter`直接替代耗时的`join`操作，能完全避免shuffle。对于数据倾斜导致单节点过载的问题，作者也指出了改进key设计的解决方向。整篇文章就像一位有经验的工程师在分享如何“避坑”，从原理到代码示例都很具体，最后还提醒了关于`collect`、避免RDD嵌套操作等容易忽略的细节。对于用Spark处理大数据的人来说，这些围绕shuffle的优化思路相当实用。

IT 累计浏览 2,480

Spark的性能调优

这篇文章从实战经验出发，汇总了Spark性能调优的多个关键方向。内容不仅涵盖基础配置，更深入到应用代码设计与任务执行策略。开篇即点明，调优的第一步往往从数据序列化开始，对比了默认的Java序列化与更快更紧凑的Kryo方案。紧接着是内存管理，文章给出了具体的检测方法（如使用UI或SizeEstimator）和优化建议（如启用压缩指针）。GC调优部分尤为实用，解释了默认内存分配比例、Eden区设置，并分享了如何避免因大量对象创建导致的“GC overhead limit exceeded”错误。对于影响性能的关键因素，文章详细阐述了并行度、Reduce Task内存使用以及Shuffle的优化。例如，通过广播变量减少大表shuffle是一个经典模式。数据本地性的五个层级及其调度策略也被清晰说明。文件存储与读取优化（如使用Parquet列存格式）和Speculation（推测执行）机制也被纳入考量。最后，文章强调了合理设置分区数和减少不必要Shuffle的重要性，并给出了具体的代码示例指引。整篇文章既包含JVM级别的参数调整，也涉及Spark应用层的数据结构设计与API选择（如prefetchByKey vs groupByKey），是一份从理论公式到实战经验的综合性调优指南。

IT 累计浏览 2,200

一步一步教你怎样给Apache Spark贡献代码

这篇教程详细拆解了向Apache Spark贡献代码的全过程，从在GitHub上fork仓库开始，一步步指导读者如何本地克隆、关联上游代码、创建功能分支、解决合并冲突，直到最终提交一个规范的Pull Request。作者特别强调了几个新手容易忽略的实践细节：比如必须为每个新功能或修复创建独立的分支，而不是直接在master上提交；在提交PR前要主动rebase以避免冲突；以及提交时必须将对应的JIRA链接（如SPARK-2859）准确放入PR标题和描述中，这是Spark社区的协作规范。教程还给出了一个真实的PR和JIRA示例供参考，让整个流程变得具体可感。对于想迈出开源贡献第一步的开发者，它提供了一个清晰、可操作的技术路线图。

IT 累计浏览 4,180

Spark：一个高效的分布式计算系统

这篇讲的是Spark这个基于内存的分布式计算框架，作者从Spark与Hadoop的对比出发，深入介绍了其核心优势和关键特性。文章指出，Spark通过将中间结果保存在内存中，避免了Hadoop MapReduce频繁读写HDFS的瓶颈，从而在迭代运算密集的数据挖掘与机器学习任务中效率显著提升。其核心创新在于RDD（弹性分布式数据集）的抽象，它使得开发者能以操作本地集合的方式来处理分布式数据，支持丰富多样的转换和行动操作，编程模型比Hadoop的Map和Reduce更加灵活。文章还剖析了RDD的存储、分区、容错机制（通过血缘信息和检查点）及其11种存储级别，这些共同构成了Spark高效、可靠的基础。此外，文章梳理了Spark的生态系统，包括兼容Hive的Shark、用于流处理的Spark Streaming以及图计算框架Bagel，并列举了其多种运行模式与在业界的早期应用。总体而言，Spark并非Hadoop的替代品，而是一个更通用、更适合迭代计算的补充，它直接读写HDFS并支持在YARN上运行，为处理海量数据提供了新的高效选择。

IT 累计浏览 3,640

Spark随谈——开发指南（译）

这篇指南针对的是Spark 0.5.0版本，它翻译自官方的Spark Programming Guide，并结合了一些作者的补充说明。它不是泛泛的概念介绍，而是从实际编程出发，详细讲解了如何在Spark中编写应用程序。文章清晰地梳理了从初始化SparkContext、操作弹性分布式数据集（RDD），到进行转换（Transformation）和动作（Action）的完整流程。特别提到了RDD的两种创建方式、关键操作如`map`、`reduce`、`filter`以及持久化策略。这些细节对于刚接触Spark、希望快速上手编写的开发者来说，是很好的起点。虽然版本较早，但其阐述的核心编程模型——基于RDD的函数式操作和惰性求值原理——构成了后续Spark SQL、Streaming等模块的基础。对于想了解Spark底层设计哲学或处理历史代码的开发者，这份指南依然具有不错的参考价值。