spark3的bug

1.[SPARK-39936][SQL] Store schema in properties for Spark Views，spark视图保存到hive metastore时未清空tableschema导致解析失败

Hive DataType解析器主要发生在Hive的元数据存储（Hive Metastore）阶段。当Hive创建表或解析表结构时，Hive会使用DataType解析器来解析表中定义的数据类型。这个解析器会尝试解析和转换表的列、字段和分区的数据类型、长度、约束等信息。它会确保表定义与Hive的数据类型系统相匹配，并正确解析表结构，从而能够正确地进行数据的存储和查询。如果在解析过程中出现格式错误或不受支持的数据类型，解析器会抛出异常并中断解析过程。在这个阶段，Hive DataType解析器负责将用户定义的数据类型转换为Hive支持的数据类型，并确保数据的一致性和正确性。

[SPARK-39936][SQL] 在Spark视图中存储模式属性

这个pull request提出了什么样的改变？

通常我们将tableSchema存储在table属性中，而不是作为实际模式。我们通常这样做是因为它有助于绕过一些Hive-Metastore问题，包括与SparkSQLDataType解析器的解析问题。

然而，问题在于我们没有清空Spark视图的tableSchema（Spark视图本来就与Hive不兼容）。因此，Hive DataType解析器会尝试解析模式并导致错误。解决方法是在将Spark视图保存到Hive Metastore时清空tableSchema。

这修复了以下错误：

-- this works since we use backticks in `date-of-creation`
create table table_with_hyphen (f array<struct<validColumnTypeName:string>>) using parquet;
-- this should work since we use backticks in `date-of-creation` but will break without this bugfix
create or replace view view_with_hyphen as select f from table_with_hyphen;

 

2.[SPARK-40002][SQL] Don't push down limit through window using ntile，将nitle函数应用于limit的结果将会导致错误的结果

[

这个拉取请求提议的更改是更改"LimitPushDownThroughWindow"，使其不再支持通过ntile函数将limit下推到窗口。

需要进行这些更改的原因是在无分区窗口中，目前ntile函数应用于limit的结果。这种行为会导致与Spark 3.1.3、Hive 2.3.9和PrestoDB 0.268产生冲突的结果。

举个例子：

假设有以下数据

Assume this data:
```
create table t1 stored as parquet as
select *
from range(101);
```
Also assume this query:
```
select id, ntile(10) over (order by id) as nt
from t1
limit 10;
```
With Spark 3.2.2, Spark 3.3.0, and master, the limit is applied before the ntile function:
```
+---+---+
|id |nt |
+---+---+
|0  |1  |
|1  |2  |
|2  |3  |
|3  |4  |
|4  |5  |
|5  |6  |
|6  |7  |
|7  |8  |
|8  |9  |
|9  |10 |
+---+---+
```
With Spark 3.1.3, and Hive 2.3.9, and Prestodb 0.268, the limit is applied _after_ ntile.

Spark 3.1.3:
```
+---+---+
|id |nt |
+---+---+
|0  |1  |
|1  |1  |
|2  |1  |
|3  |1  |
|4  |1  |
|5  |1  |
|6  |1  |
|7  |1  |
|8  |1  |
|9  |1  |
+---+---+
```
Hive 2.3.9:
```
+-----+-----+
| id  | nt  |
+-----+-----+
| 0   | 1   |
| 1   | 1   |
| 2   | 1   |
| 3   | 1   |
| 4   | 1   |
| 5   | 1   |
| 6   | 1   |
| 7   | 1   |
| 8   | 1   |
| 9   | 1   |
+-----+-----+
10 rows selected (1.72 seconds)
```
Prestodb 0.268:
```
id | nt
----+----
  0 |  1
  1 |  1
  2 |  1
  3 |  1
  4 |  1
  5 |  1
  6 |  1
  7 |  1
  8 |  1
  9 |  1
(10 rows)

```

3. [SPARK-40963][SQL] Set nullable correctly in project created by ExtractGenerator，可能会导致错误的结果以及空指针问题

 

　　

### 此拉取请求中提出了哪些更改？

在 `ExtractGenerator` 中创建新投影列表时，考虑到生成器是否为外部生成器，在设置生成器相关的输出属性的可空性时。

### 为什么需要这些更改？

这个拉取请求修复了一个可能导致结果不正确或引发`NullPointerException`的问题。这个问题有点难以重现，除非使用具有内联表的子查询。

例子：
```
select c1, explode(c4) as c5 from (
select c1, array(c3) as c4 from (
select c1, explode_outer(c2) as c3
from values
(1, array(1, 2)),
(2, array(2, 3)),
(3, null)
as data(c1, c2)
)
);

+---+---+
|c1 |c5 |
+---+---+
|1 |1 |
|1 |2 |
|2 |2 |
|2 |3 |
|3 |0 |
+---+---+
```
在最后一行中，`c5` 是0，但应为 `NULL`。

另一个例子：
```
select c1, exists(c4, x -> x is null) as c5 from (
select c1, array(c3) as c4 from (
select c1, explode_outer(c2) as c3
from values
(1, array(1, 2)),
(2, array(2, 3)),
(3, array())
as data(c1, c2)
)
);

+---+-----+
|c1 |c5 |
+---+-----+
|1 |false|
|1 |false|
|2 |false|
|2 |false|
|3 |false|
+---+-----+
```
在最后一行中，`false` 应该为 `true`。

在这两种情况下，在实例化 `CreateArray(c3)` 时，`c3` 的可空性是不正确的，因为由 `ExtractGenerator` 创建的新投影使用来自 `explode_outer(c2)` 的 `generatorOutput` 作为投影列表。`generatorOutput` 没有考虑到 `explode_outer(c2)` 是一个外部爆炸，因此丢失了可空性设置。

`UpdateAttributeNullability` 最终会为引用 `c3` 的属性修复可空性设置，但它不能修复来自第一个示例中的 `explode(c4)` 或来自第二个示例中的 `exists(c4, x -> x is null)` 的 `containsNull` 设置。

此示例将引发 `NullPointerException`：
```
select c1, inline_outer(c4) from (
select c1, array(c3) as c4 from (
select c1, explode_outer(c2) as c3
from values
(1, array(named_struct('a', 1, 'b', 2))),
(2, array(named_struct('a', 3, 'b', 4), named_struct('a', 5, 'b', 6))),
(3, array())
as data(c1, c2)
)
);
22/10/30 17:34:42 ERROR Executor: Exception in task 1.0 in stage 8.0 (TID 14)
java.lang.NullPointerException
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.generate_doConsume_1$(Unknown Source)
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.generate_doConsume_0$(Unknown Source)
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.processNext(Unknown Source)
at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
at org.apache.spark.sql.execution.WholeStageCodegenExec$$anon$1.hasNext(WholeStageCodegenExec.scala:760)
at org.apache.spark.sql.execution.SparkPlan.$anonfun$getByteArrayRdd$1(SparkPlan.scala:364)
```

### 这个 PR 是否引入了用户界面上的任何更改？

没有。

### 如何测试这个补丁？

 

5.[SPARK-41668][SQL] DECODE function returns wrong results when passed NULL，传NULL后DECODE返回结果有误