SparkSQL分布式执行引擎详解：Thrift服务解析(第七天)

系列文章目录

SparkSQL的分布式执行引擎
1、启动Thrift服务
2、beeline连接Thrift服务
3、开发工具连接Thrift服务
4、控制台编写SQL代码
5、Spark 核心执行流程（补充）

---

前言

本文主要讲述SparkSQL的分布式执行引擎-Thrift服务，Spark 核心执行流程（补充）。

---

一、SparkSQL的分布式执行引擎(了解)

分布式执行引擎 == Thrift服务 == ThriftServer == SparkSQL中的Hiveserver2

1、启动Thrift服务

​ 前提：已经完成Spark集成Hive的配置。但是目前集成后，如果需要连接Hive，此时需要启动一个Spark的客户端（spark-sql、代码）才可以。这个客户端底层相当于启动服务项，用于连接Hive的metastore的服务，进行处理操作。一旦退出客户端，相当于这个服务也就没有了，无法再使用

​ 目前的情况非常类似于在Hive部署的时候，有一个本地模式部署（在启动Hive客户端的时候，内部自动启动一个Hive的hiveserver2服务项）

大白话: 目前在Spark后台，并没有一个长期挂载的Spark的服务(Spark HiveServer2服务)。导致每次启动Spark客户端，都需要在内部启动一个服务项。这种方式，不适合测试使用，不合适后续的快速开发

​ 如何启动Spark 提供的分布式的执行引擎呢? 这个引擎大家完全可以将其理解为Spark的HiveServer2服务，实际上就是Spark的Thrift服务项

# 注意: 要启动sparkThriftServer2服务，必须要保证先启动好Hadoop以及Hive的metastore，不能启动Hive的hiveserver2服务!
# 启动 hadoop集群
start-all.sh

# 启动hive的metastore
nohup /export/server/hive/bin/hive --service metastore &

# 最后执行以下命令启动sparkThriftServer2:
/export/server/spark/sbin/start-thriftserver.sh \
--hiveconf hive.server2.thrift.port=10000 \
--hiveconf hive.server2.thrift.bind.host=node1 \
--hiveconf spark.sql.warehouse.dir=hdfs://node1:8020/user/hive/warehouse \
--master local[2]

校验是否成功：

访问界面：默认4040

2、beeline连接Thrift服务

启动后，可以通过spark提供beeline的方式连接这个服务。连接后，直接编写SQL即可

相当于模拟了一个Hive的客户端，但是底层执行的是Spark SQL，最终将其转换为Spark RDD的程序

启动命令:/export/server/spark/bin/beeline

然后输入:!connect jdbc:hive2://node1:10000

继续输入用户名: root
注意密码: 不需要写，直接回车

3、开发工具连接Thrift服务

如何通过DataGrip或者PyCharm连接Spark进行操作

博主已经上传资源：

4、控制台编写SQL代码

进入以下页面就可以愉快的编写sql了,再也不用担心在spark.sql()中编写没有提示了:)

二、Spark 核心执行流程（补充）

1. 初始化 SparkContext

   • 当用户编写 Spark 应用程序时，首先需要初始化一个 SparkContext 对象。这个对象会告诉 Spark 如何访问集群。
   • SparkContext 负责与集群管理器（Cluster Manager）进行通信，以获取资源（如 CPU、内存等）。

2. 构建 DAG（有向无环图）

   • 用户通过 RDD（弹性分布式数据集）的转换操作（transformations）和动作操作（actions）来构建应用程序。
   • 这些操作会被 Spark 转换成一个有向无环图（DAG），用于描述计算过程。

3. 将 DAG 划分成 Stages

   • Spark 会根据 RDD 之间的依赖关系将 DAG 划分成多个 Stages。
   • 每个 Stage 代表一个可以并行执行的任务集（TaskSet）。

4. 任务调度与分发

   • Spark 使用任务调度器（Task Scheduler）来调度和分发任务。
   • 任务调度器会根据集群的状态（如资源可用性、节点健康状况等）来决定在哪里执行这些任务。

5. 执行任务

   • 集群管理器（如 Standalone、YARN、Kubernetes 等）会分配资源给 Executor。
   • Executor 进程在节点上启动，并执行分配给它的任务。

6. 收集结果

   • 当动作操作（如 collect()、count() 等）被调用时，Spark 会收集并返回计算结果。
   • 这些结果会被返回到驱动程序（Driver Program）中，并展示给用户。

1、使用 SparkSubmit 提交 job 到 Standalone 模式

1. 配置 Standalone 集群

   • 你需要配置一个 Spark Standalone 集群，包括一个 Master 节点和多个 Worker 节点。
   • Master 节点负责资源管理和任务调度，而 Worker 节点负责执行任务。

2. 编写 Spark 应用程序

   • 使用 Scala、Java、Python 或 R 等语言编写 Spark 应用程序。
   • 确保你的应用程序中包含了 SparkContext 的初始化代码，以及相应的 RDD 操作。

3. 使用 spark-submit 提交 job

   • 在客户端机器上，使用 spark-submit 命令提交你的 Spark 应用程序。
   • 你需要指定应用程序的 JAR 包、主类、Master URL 等参数。
   • 例如：spark-submit --class org.example.MyApp --master spark://master-url:7077 my-app.jar

4. Standalone 模式下的资源分配

   • 当 spark-submit 命令被执行时，它会连接到指定的 Master 节点。
   • Master 节点会检查集群中 Worker 节点的资源状态，并分配资源给 Executor。
   • Executor 进程会在 Worker 节点上启动，并执行分配给它的任务。

5. 监控与日志

   • 你可以通过 Spark UI（Web UI）来监控 job 的执行状态、资源使用情况等。

   • Spark UI 提供了丰富的可视化界面，帮助你更好地理解 Spark 应用程序的运行情况。

   • 同时，你也可以查看 Worker 节点和 Executor 的日志文件，以获取更详细的执行信息。

三、常见面试题

Repartition和Coalesce的关系与区别？

关系：

• 在Apache Spark中，repartition和coalesce都是用于重新分区RDD（弹性分布式数据集）或DataFrame的转换操作。它们的主要功能都是改变数据的分区数量，但实现方式和处理机制有所不同。
• 从实现层面上讲，repartition实际上是coalesce的一个特例，其底层调用的是coalesce方法，但设置了shuffle参数为True。

区别：

1. shuffle操作：

   • repartition：在执行时，无论分区数量是增加还是减少，都可能会涉及到数据的重新洗牌（shuffle）。这可能导致数据的重新分配和传输，增加了计算的开销。
   • coalesce：主要用于减少分区数量，并且尽可能避免数据的重新洗牌。在减少分区时，它会尝试将相同executor上的分区合并，从而减少数据的移动。

2. 使用场景：

repartition
     - 当需要调整数据的并行度以适应不同的计算资源或优化性能时使用。
     - 例如，如果一个任务因为数据倾斜而运行缓慢，可以通过增加分区来改善性能。

coalesce

 - 当需要减少数据的并行度，以减少资源消耗或在执行减少操作（如reduce或collect）之前准备数据时使用。
 - 由于其避免了不必要的shuffle操作，因此在合并分区时通常比`repartition`更高效。

3. 参数和效果：

   • repartition：允许增加或减少分区数量，可以指定一个分区器来控制数据在新分区中的分布。
   • coalesce：只能减少分区数量，如果指定的分区数大于当前分区数，它将保持当前的分区数不变。

4. 性能考虑：

   • 在减少分区数量时，如果数据量较大，使用coalesce通常比使用repartition更高效，因为它减少了数据移动的次数。
   • 然而，如果希望将数据重新分区为一个新的分区布局或生成新的RDD，则可能需要使用repartition。

总结来说，repartition和coalesce在Spark中都是用于重新分区RDD或DataFrame的操作，但在处理分区数量、shuffle操作、使用场景和性能方面有所不同。根据具体的需求和场景，选择适当的操作可以优化Spark应用程序的性能和资源使用。