1.SPARK-38864 - Spark支持unpivot源码分析
2.spark sql源码系列 | with as 语句真的源码会把查询的数据存内存嘛？
3.Hive Server2对execute和executeQuery的处理
4.为什么sparkSQL

SPARK-38864 - Spark支持unpivot源码分析

       unpivot是数据库系统中用于列转行的内置函数，如SQL SERVER,实现 Oracle等。以数据集tb1为例，源码每个数字代表某个人在某个学科的实现成绩。若要将此表扩展为三元组，源码可使用union实现。实现python源码实例但随列数增加，源码SQL语句变长。实现许多SQL引擎提供内置函数unpivot简化此过程。源码unpivot使用时需指定保留列、实现进行转行的源码列、新列名及值列名。实现

       SPARK从SPARK-版本开始支持DataSet的源码unpivot函数，逐步扩展至pyspark与SQL。实现在Dataset API中，源码简爱同城交友源码ids为要保留的Column数组，Column类提供了从String构造Column的隐式转换，方便使用。利用此API，可通过unpivot函数将数据集转换为所需的三元组。values表示转行列，variableColumnName为新列名，valueColumnName为值列名。

       Analyser阶段解析unpivot算子，将逻辑执行计划转化为物理执行计划。当用户开启hive catalog，SPARK SQL根据表名和metastore URL查找表元数据，转化为Hive相关逻辑执行计划。物理执行计划如BroadcastHashJoinExec，读取网页中文源码表示具体的执行策略。规则ResolveUnpivot将包含unpivot的算子转换为Expand算子，在物理执行计划阶段执行。此转换由开发者自定义规则完成，通过遍历逻辑执行计划树，根据节点类型及状态进行不同处理。

       unpivot函数实现过程中，首先将原始数据集投影为包含ids、variableColumnName、valueColumnName的列，实现语义转换。随后，通过map函数处理values列，构建新的抄底王 号源码行数据，最终返回Expand算子。在物理执行计划阶段，Expand算子将数据转换为所需形式，实现unpivot功能。

       综上所述，SPARK内置函数unpivot的实现通过解析列参数，组装Expand算子完成，为用户提供简便的列转行功能。通过理解此过程，可深入掌握SPARK SQL的开发原理与内在机制。

spark sql源码系列 | with as 语句真的会把查询的数据存内存嘛？

       在探讨 Spark SQL 中 with...as 语句是否真的会把查询的数据存入内存之前，我们需要理清几个关键点。首先，网上诸多博客常常提及 with...as 语句会将数据存放于内存中，余赚网源码来提升性能。那么，实际情况究竟如何呢？

       让我们以 hive-sql 的视角来解答这一问题。在 hive 中，有一个名为 `hive.optimize.cte.materialize.threshold` 的参数。默认情况下，其值为 -1，代表关闭。当值大于 0 时（如设置为 2），with...as 语句生成的表将在被引用次数达到设定值后物化，从而确保 with...as 语句仅执行一次，进而提高效率。

       接下来，我们通过具体测试来验证上述结论。在不调整该参数的情况下，执行计划显示 test 表被读取了两次。此时，我们将参数调整为 `set hive.optimize.cte.materialize.threshold=1`，执行计划显示了 test 表被物化的情况，表明查询结果已被缓存。

       转而观察 Spark SQL 端，我们并未发现相关优化参数。Spark 对 with...as 的操作相对较少，在源码层面，通过获取元数据时所做的参数判断（如阈值与 cte 引用次数），我们可以发现 Spark 在这个逻辑上并未提供明确的优化机制，来专门针对 with...as 语句进行高效管理。

       综上所述，通过与 hive-sql 的对比以及深入源码分析，我们得出了 with...as 语句在 Spark SQL 中是否把数据存入内存的结论，答案并不是绝对的。关键在于是否通过参数调整来物化结果，以及 Spark 在自身框架层面并未提供特定优化策略来针对 with...as 语句进行内存管理。因此，正确使用 with...as 语句并结合具体业务场景，灵活调整优化参数策略，是实现性能提升的关键。

Hive Server2对execute和executeQuery的处理

       实现SparkSQL的SQL Server服务时，需兼容Hive的JDBC Driver，以便通过beeline连接服务。Java的JDBC标准提供execute和executeQuery两类接口。execute用于DDL（数据定义语言）操作，返回true/false，而executeQuery则处理查询，返回ResultSet结果集。

       在thrift接口实现中，对DDL操作，直接将结果置空并设置setHasResultSet为false。然而，beeline客户端始终显示错误，因为其使用了beeline的JDBC驱动。通过源码调试发现，在Hive的JDBC实现中，executeQuery直接调用execute。如果返回false，则抛出异常：The query did not generate a result set!

       在执行SQL后，beeline客户端会通过GetOperationStatus获取操作状态。在类似while true的循环中，直到操作结束，开始获取结果集。关键在于，如果isHasResultSet为false，execute会直接抛出异常。因此，isHasResultSet必须返回true，后端在封装thrift结果集时，需调整逻辑。

       通常，设置setHasResultSet为false且设置setHasResultSetIsSet为true即可。但实践中发现，两者关联影响结果。最终解决方案是，对无结果集的DDL执行，手动生成相应返回。

       Hive在处理execute和executeQuery时，存在实现上的不完美之处。

为什么sparkSQL

       Shark和sparkSQL 但是，随着Spark的发展，其中sparkSQL作为Spark生态的一员继续发展，而不再受限于hive，只是兼容hive；而hive on spark是一个hive的发展计划，该计划将spark作为hive的底层引擎之一，也就是说，hive将不再受限于一个引擎，可以采用map-reduce、Tez、spark等引擎。

       ã€€ã€€Shark为了实现Hive兼容，在HQL方面重用了Hive中HQL的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从MR作业替换成了Spark作业（辅以内存列式存储等各种和Hive关系不大的优化）；同时还依赖Hive Metastore和Hive SerDe（用于兼容现有的各种Hive存储格式）。这一策略导致了两个问题，第一是执行计划优化完全依赖于Hive，不方便添加新的优化策略；二是因为MR是进程级并行，写代码的时候不是很注意线程安全问题，导致Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支（至于为何相关修改没有合并到Hive主线，我也不太清楚）。

       ã€€ã€€æ­¤å¤–，除了兼容HQL、加速现有Hive数据的查询分析以外，Spark SQL还支持直接对原生RDD对象进行关系查询。同时，除了HQL以外，Spark SQL还内建了一个精简的SQL parser，以及一套Scala DSL。也就是说，如果只是使用Spark SQL内建的SQL方言或Scala DSL对原生RDD对象进行关系查询，用户在开发Spark应用时完全不需要依赖Hive的任何东西。