之乎者也·的博客

大数据开发离不开各种框架，我们通过学习 Apache Hadoop、Spark 和 Flink 之间的特征比较，可以从侧面了解要学习的内容。众所周知，Hadoop vs Spark vs Flink是快速占领 IT 市场的三大大数据技术，大数据岗位几乎都是围绕它们展开。本文，将详细介绍三种框架之间的区别。

将耗时最长的Stage展开，进一步看下具体的耗时比对，先看下Shuffle Read的耗时，由于原生Spark Shuffle需要从各个Executor上拉取数据，涉及到大量的网络开销以及磁盘的随机IO，耗时非常长，甚至达到了2分钟，而Remote Shuffle Service由于读取时降低了网络开销，且读取的是整块Shuffle数据，所以耗时短且较为稳定。这种shuffle方式多用于类MR的框架，比如MapReduce、Spark，它的特点是具有较高的容错性，适合较大规模的批处理作业。

本文讨论了京东Spark计算引擎研发团队关于自主研发并落地Remote Shuffle Service，助力京东大促场景的探索和实践。近年来，大数据技术在各行各业的应用越来越广泛，Spark自UCBerkeley的AMP实验室诞生到如今3.0版本的发布，已有十年之久，俨然已经成为大数据计算领域名副其实的老将。虽经过不断的迭代和优化，Spark功能日趋成熟与完善，但在性能及稳定性方面，仍然还有很多可以提升的地方。Shuffle过程作为MapReduce编程模型的性能瓶颈，就是其中重点之一。

混部资源治理以降低作业的失败率，确保作业的稳定性为主要目标，同时需要提高整个集群的 Shuffle 性能，减少资源浪费。，与刚才介绍的 ESS 模式不同，在 Push Based Shuffle 模式下，不同 Mapper 的同一个 Reducer Partition 数据都会发送到一个共同的远程服务上，在这个服务上进行合并，最后在某个 Worker 上写上一个或者多个文件，使得 Reduce 阶段可以通过 Sequential Read 模式读取这些 Partition 数据，减少随机 IO 的开销。

① 部署运维难度大目前我们大家所熟悉的Spark集群都是在传统的 Hadoop 集群内部，比如CDH，或者早期的云上的EMR集群，这种全家桶式的部署方式的好处在于组件比较丰富，但是部署组件繁多，无论是安装、部署、运维都比较复杂，带来比较大的运维和人力成本。② 弹性能力不足这种部署模式需要比较固定的资源预估，比如跑作业需要多少 master，多少worker，都要提前准备好，还要事先完成环境的安装和组件的部署。这样，弹性扩容的效率就比较差。③ 存储与计算耦合传统 Spark 集群既要部署HDFS 的 data

回顾整个方案的设计过程，实际上没有太多选择的余地，在没法在spark引擎层做兼容的前提，和以脚本提交任务的现状下，只能选择基于git版本管理的自动化迁移流程。方案能这么顺利实施，主要因为任务代码是以脚本的形式存在，这样我们可以很方便的用各种程序处理脚本源代码，避免了大量重复性的工作，特别是用git进行版本管理，如果我们的任务都写在了公司中台上，那么迁移工作量会大很多。

ZOrder可以认为是sort的变种，在Spark中，单列的sort对文件的过滤是比较友好的，但如果sort by多列的话，会首先对column0做sort，然后column0相同的时候再做column1的sort，所以如果过滤的where条件是column1或者column2的时候文件过滤效果就不是很好。于是我们就做了一个列的生命周期管理，就是在query的时候会把查询了哪些列报告给数据治理服务，数据治理服务会做一个统计，用户可以设置对应的列被查询多少次才认为它是有价值的。这是一个数据治理服务的总览。

我们实现了一个TopNAccumulator累加器，内部维护一个Map[String, Long]类型的对象，使用Join的Key值作为Map的Key并维护该Key的Count值在Map的Value中，在SortMergeJoinExec中对于每行数据进行累加计算，由于数据是有序的我们只需要对插入的Key进行累加，并在插入新的Key时判断是否达到N值，淘汰掉最少的Key。另外，Spark只支持展示Long类型的统计指标，我们还对SQL统计指标的展示逻辑进行修改适配了Map类型的值。

Spark 作为开源社区优秀的大数据计算引擎，极大地提高了传统 Hadoop 生态下大数据计算的效率。随着云计算时代的发展，给大数据开发者带来了便利的同时也带来了新的挑战。首先来看一下传统 Hadoop 生态下的大数据集群有哪些缺陷。（1）第一个缺陷是成本高，我们需要维护多个集群，还需要非常专业的运维人员才能去维护非常多的组件，如 Hadoop、Hive、ZooKeeper 等等，集群运维成本非常高。另外，服务器本身裸机价格和物理硬件的维护成本也是非常高的。还有 Hadoop 生态下的 HDFS 为了高可用

下图展示了物化视图的使用流程，user，item，users_items是3张表，先创建物化视图mv，使用SQL查询时，将基于mv对SQL生成的Logical Plan进行重写，生成新的基于物化视图的Plan，再进行查询。基于内部的SQL信息收集系统，我们发现不同的SQL存在大量的重复数据访问，比如，相同视图的重复访问。下文所有描述的物化视图的落地场景，都是基于这些统计信息，简单来说，物化视图的收益大小取决于数据的重用次数，而完善的统计信息能让我们更直观的判断该如何创建物化视图，从而获取更多的收益。

另一部分就是在线到离线的潮汐资源，这部分就需要将在线集群空闲的资源出借到离线集群，我们整体是基于 Virtual-Kubelet 来实现的，这部分也都是整卡资源，它的供给是随着业务高低峰起伏有一个明显的规律，在线业务低峰的时候就通过自动缩容把资源空出来，然后出借到离线集群，等到高峰时又会扩容，集群把离线 Pod 给驱逐掉，它是一个中等的隔离级别，在离线的 Pod 是要跑在同一台机器上，但是卡还是可隔离开的。另外因为这些本身就是碎片资源，需要任务的大小尺寸相对适中，不能是特别大的任务。

我们在优化层面上支持了多引擎的查询性能优化，也取得了非常好的效果。Kyuubi 再跑这些 SQL 的时候，就会动态感知这些 Table 里面的 Properties，判断是否要为这些写的数仓类任务增加 Rebalance + Z Order，去规范化每一个数仓类任务的产出，从而让整个产出的数据质量及产出的表的下游任务在读的时候有非常好的查询性能。可以看到，这是个非常简单的 Demo，它的数据已经出现了非常小的一些分区，实际在 Reduce 分区里面只有3个分区是有数据的，剩下197个是空的。

Spark 是典型的主从型（M/S，Master/Slave）架构，从系统的角度来看，Spark 分布式系统的核心进程只有两种：Driver 和 Executor，分别对应主从架构的 Master 和 Slave。显而易见，在 Spark 分布式系统中，Driver 只有一个，而 Executor 可以有多个。

Spark是一个快速、通用的大数据处理框架，它提供了丰富的核心组件和功能，用于处理和分析大规模数据集。Spark Core：Spark的核心组件，提供了分布式任务调度、内存管理和错误恢复等基本功能。它还定义了RDD（弹性分布式数据集）的概念，RDD是Spark中的基本数据结构，用于表示可并行处理的数据集。Spark SQL：用于处理结构化数据的模块，支持SQL查询和DataFrame API。

cogroup：对多个（2~4）RDD 中的 KV 元素，每个 RDD 中相同 key 中的元素分别聚合成一个集合。与 reduceByKey 不同的是：reduceByKey 针对一个 RDD中相同的 key 进行合并。而 cogroup 针对多个 RDD中相同的 key 的元素进行合并。cogroup 的函数实现。

reduceByKey和groupByKey都存在shuffle的操作，但是reduceByKey可以在shuffle前对分区内相同key的数据进行预聚合（combine）功能，这样会减少落盘的数据量，而groupByKey只是进行分组，不存在数据量减少的问题，reduceByKey性能比较高。广播变量用来高效分发较大的对象。在Driver程序中定义的变量，在Executor端的每个Task都会得到这个变量的一份新的副本，每个task更新这些副本的值后，传回Driver端进行merge，从未实现累加。

核算业务的特征比较偏向数据和规则的处理，大数据引擎的引入有助于整体业务的交付效率提升和成本降低。目前我们对Spark的认知主要在完成数据处理逻辑开发及日常的调优上，随着运行实例的增多以及业务的不断发展，当前的技术方案也会不断的迭代演进。

在大数据领域，肯定有很多小伙伴跟笔者一样为了让生产中数据执行速度更快、性能更高而去使用Spark，当我们用Spark程序实现功能开发并使程序正常稳定运行起来的时候，一定是非常有成就感的；但是随着数据量的增加以及需求的完善，我们就开始关注我们这个程序能否做到在运行起来的时候让数据查询更快、让页面响应更快、尽可能的节省空间占用率；而前面提到这些"美好的设想"其实是由很多方面决定的，由很多部分组成，并不是仅仅通过调节几个参数就可以大幅度提升作业性能的。

首先介绍一下 Spark 的创始团队开创的公司 Databricks。Databricks 是湖仓一体概念的提出者和先驱者。目前除了 Spark，开源的热门项目还有 Delta Lake 和 Mlflow，服务客户超过一万，在全球有非常高的投资和年收入。公司在大中华区开始开展业务。国内可通过 Azure Databricks 来使用公司的产品。Databricks 提供统一的湖仓一体平台（Lakehouse），可以支撑整个企业数据平台的使用，和一些AI相关的开发工作。

Spark的DAGScheduler相当于一个改进版的MapReduce，如果计算不涉及与其他节点进行数据交换，Spark可以在内存中一次性完成这些操作，也就是中间结果无须落盘，减少了磁盘IO的操作。有一个误区，Spark是基于内存的计算，所以快，这不是主要原因，要对数据做计算，必然得加载到内存，Hadoop也是如此，只不过Spark支持将需要反复用到的数据Cache到内存中，减少数据加载耗时，所以Spark跑机器学习算法比较在行（需要对数据进行反复迭代）。进程的创建销毁的开销较大，线程开销较小。

在编程API方面，对API做了精简，合并dataframe和datasets，1.6的dataset包含了dataframe的功能，这样两者存在很大冗余，所以2.0将两者统一，保留dataset api，把dataframe表示为dataset[Row]，即dataset的子集。在SQL支持层面，1.0阶段，SQL的很多功能并不能很好的支持，在2.0阶段，引入了ANSI SQL解析器，并且支持子查询，已经可以运行TPC-DS所有的99个查询，基本覆盖了常见的99%应用场景。

Spark 是一个开源的数据处理框架，能快速处理大量数据的转换。其高性能来自Spark的分布式框架，通常一个任务会被平均分配，跨机器集群工作。但Spark本身并不管理这些计算机，他需要一个集群的管理器来管理集群。Spark定义了需要执行的任务，而管理器决定了任务将如何被分配被执行，由此可见其重要性。这个管理器需要负责任务的接收、资源的调度和分配、任务的启动、TaskTrack监控等。传统上，我们会选择Hadoop YARN来作为资源调度管理器，并且使用spark-submit提交任务。

在提交成功后, 将alive master直接kill掉不会影响程序运行，当新的master接收集群后, 程序继续运行, 正常得到结果。在YARN中 有一个历史服务器, 其功能是将YARN运行的程序的历史日志记录下来, 通过历史服务器方便用户查看程序运行的历史信息.Spark的历史服务器, 功能: 将Spark运行的程序的历史日志记录下来, 通过历史服务器方便用户查看程序运行的历史信息.不同的是, 这个解释器环境 运行的不是python代码, 而是scala程序代码。

Apache Spark是用于大规模数据处理的统一分析引擎，基于内存计算，提高了在大数据环境下数据处理的实时性，同时保证了高容错性和高可伸缩性，允许用户将Spark部署在大量硬件之上，形成集群。Spark源码从1.x的40w行发展到现在的超过100w行，有1400多位大牛贡献了代码。整个Spark框架源码是一个巨大的工程。下面我们一起来看下spark的底层执行原理。

具体来说，TaskScheduler会将每个Stage中的任务（TaskSet）划分为多个Task，并根据任务的资源需求和当前集群的资源情况，将这些Task分配给可用的Executor进行执行。总结起来，TaskScheduler负责将每个Stage中的任务提交给可用的Executor进行执行，并根据具体算法进行任务的分配决策。每个Stage内的任务可以在同一个Executor节点上并行执行，而Stage之间的任务则可以在不同的Executor节点上并行执行，以提高整个应用程序的执行效率。

如果从先前的 checkpoint 信息点重新开始，是无法完成预先升级的程序代码的，checkpoint 本质上包含序列化后的 Scala/Java/Python 对象，将对象进行反序列化为新的对象，修改的类可能会导致错误，在这种情况下，可以让升级的应用程序使用不同的 checkpoint 目录或者删除以前的检查点目录。例如，如果您使用的是 10 分钟的窗口操作，那么 Spark Streaming 将保留最后 10 分钟的数据，并主动丢弃旧数据。根据 Receiver 的类型，提供了不同的语义。

在 MapReduce 框架中， Shuffle 阶段是连接 Map 与 Reduce 之间的桥梁， Map 阶段通过 Shuffle 过程将数据输出到 Reduce 阶段中。。Spark 也有 Map 阶段和 Reduce 阶段，因此也会出现 Shuffle。

被分配到各个 Executor 的单位工作内容，它是 Spark 中的最小执行单位，一般来说有多少个 Paritition（物理层面的概念，即分支可以理解为将数据划分成不同部分并行处理），就会有多少个 Task，每个 Task 只会处理单一分支上的数据。在阶段划分完成和Task创建后， Driver会向Executor发送 Task；3）、Executor在接收到Task后，会下载Task的运行时依赖，在准备好Task的执行环境后，会开始执行Task，并且将Task的运行状态汇报给Driver；

分布式机器学习的框架，可以使用许多常见的机器学习和统计算法，例如：支持向量机、 回归、 线性回归、 逻辑回归、 决策树、 朴素贝叶斯、汇总统计、相关性、分层抽样、 假设检定、随机数据生成等，简化大规模机器学习。的快速调度能力来运行流分析，通过时间窗口截取小批量的数据并可以对之运行。类似，Spark 也有本地模式，和线上集群模式，不过不同的是，是一个快速的，多用途的集群计算系统， 相对于。当然现在有了更为发展趋势，更好处理流式数据的。的基础,，提供了分布式任务调度和基本的。的数据抽象化的概念，提供了在。

在此，我们对Spark的基本概念、使用方式以及部分原理进行了简单的介绍。Spark以其强大的处理能力和灵活性，已经成为大数据处理领域的一个重要工具。然而，这只是冰山一角。Spark的世界里还有许多深度和广度等待着我们去探索。作为初学者，你可能会觉得这个领域庞大且复杂。但请记住，每个都是从初学者开始的。不断的学习和实践，你将能够更好的理解和掌握Spark，并将其应用于解决实际问题。这篇文章可能不能涵盖所有的知识点，但我希望它能带给你收获和思考。

在这个数据驱动的时代，信息的处理和分析变得越来越重要。而在众多的大数据处理框架中，「」以其独特的优势脱颖而出。本篇文章，我们将一起走进Spark的世界，探索并理解其相关的基础概念和使用方法。本文主要目标是让初学者能够对Spark有一个全面的认识，并能实际应用到各类问题的解决之中。