在使用spark的applyInPandas方法过程中,遇到类型冲突问题如何解决
背景
在最近数据开发中,遇到一个坑,即在使用 pandas Udf 函数时,udf 函数是使用 pandas 写的,输入的数据是 Spark DataFrame,在使用时遇到数据类型不一致的报错。
原因
在 spark 中,使用 applyInPandas 中,遇到类型冲突问题,查询问题是 arrow 错误,根本原因是 spark sql 和 pandas 两个框架对数据类型的定义和底层实现不一样,而 arrow 作为他们中间的数据交换器,遇到它不认识的方言就不起作用了 。
applyInPandas 的工作流程是：Spark DataFrame → arrow 转换 → Pandas DataFrame python 函数 → arrow 转换 → Spark DataFrame 。可以看到有很多的转换过程,问题就出在这里。
核心区别
- Spark DataFrame : 是一个分布式、不可变的数据集 。它的数据类型是为了在集群中高效、安全地处理海量数据而设计的,比如
StringType、IntegerType、TimestampType等。是在底层进行优化的,能被序列化后在网络间传输。 - Pandas DataFrame : 本质是一个单机内存中数据结构,数据类型直接基于 Numpy,比如
object、inter、float64、datetime64[ns]等,是追求在单机上的计算性能和灵活性 。
类型系统的本质差异
Spark SQL 采用基于 JVM 的、静态的、强类型系统。它的数据类型(如 IntegerType, DoubleType, StructType)在定义 Schema 时就已确定,并且在运行时严格校验,旨在保证分布式计算的环境下数据的精确性和可靠性。
Pandas 基于 Python/NumPy,其类型系统更为灵活和动态 。它广泛使用 object 类型(可以容纳任何 Python 对象),并且对数值精度(如 int32 vs int64)的处理有时不那么严格 。当您使用 applyInPandas 时,Spark 需要将数据通过 Arrow 序列化后发送到各个 Executor 节点的 Python 进程中,并转换为 Pandas DataFrame 进行处理。处理完毕后,再将结果通过 Arrow 反序列化回 Spark 的 JVM 内存格式。
Apache Arrow 的角色与瓶颈
Apache Arrow 作为高效的列式内存数据格式,旨在充当 Spark 的 JVM 和 Python 的 Pandas/NumPy 之间高速数据传输的桥梁 。但它也扮演了一个"严格裁判"的角色,会强制执行类型安全。当它发现 Pandas 中的数据格式与 Spark SQL 中声明的目标类型不兼容时,就会抛出异常,防止潜在的数据丢失或精度损失。
常见的类型冲突
最容易出问题的几种类型
| Spark SQL 类型 | Pandas 对应类型 | 潜在问题与说明 |
|---|---|---|
TimestampType |
datetime64[ns] |
最常见的问题区! Spark 的 TimestampType 是不带时区的(UTC),而 Pandas 的 datetime64[ns] 可以带时区信息。Arrow 在转换时对时区非常敏感,容易出错 。 |
StringType |
object(dtype) |
Pandas 的 object 类型是个"大杂烩",可以存字符串、数字、甚至 Python 对象。当 Spark 的 StringType 列中混入了 None 或其他类型,转换到 Panda 的 object 时可能没问题,但返回给 Spark 时,如果 Pandas 列里混入了非字符串(比如 int),Arrow 就会报类型冲突 。 |
IntegerType |
int64 (Or Int64) |
None/NaN 是魔鬼! Spark 的 IntegerType 列可以完整地表示 NULL。但 Pandas 的 int64 不能存 NaN(空值),一旦有空值,整个列的 dtype 会自动向上转型为 float64,这就造成了类型不匹配。Pandas 的新版 Int64 (注意大写 I)可以存空值,但 Arrow 对它的支持可能不完美 。 |
DateType |
object |
有时 Spark 的 DateType 会被转换成 Pandas 的 object 类型,里面存的是 Python 的 datetime.date 对象,而不是 datetime64。这在返回时也可能引发问题。 |
ArrayType |
object |
Spark 的数组列会被转换成 Pandas 的 object 列,其中每个单元格是一个 Python list。这个转换通常比较顺利,但如果列表内的元素类型不一致,也可能出问题 。 |
系统性的解决方案
解决这个问题需要从数据、代码、配置三个层面系统性地入手。下面的表格梳理了核心的解决思路:
| 解决层面 | 核心思路 | 具体方法与考量 |
|---|---|---|
| 数据溯源与修正 | 确保 Pandas UDF 处理前后,每个数据元素都是预期的标量类型,而非数组或复杂对象。 | 检查 UDF 内的逻辑,确保没有无意中返回数组。例如,在使用某些 NumPy 或 Scikit-learn 函数后,使用 .item() 或索引 [0] 将单元素数组转换为标量 。 |
| 类型声明与匹配 | 在 UDF 中显式、精确地定义输入和输出的 Schema,为 Arrow 转换提供清晰的指引 。 | 仔细检查 applyInPandas 函数中为返回数据定义的 Spark Schema,确保其与 Pandas DataFrame 的实际数据类型完全匹配。在 Pandas 端,可提前使用 astype() 方法统一数据类型。 |
| 配置调整(治标) | 作为临时绕过验证的应急手段,调整 Arrow 的安全校验规则 。 | 不推荐长期使用。若确认数据转换是安全且可接受的,可尝试关闭安全类型检查： spark.conf.set("spark.sql.execution.pandas.convertToArrowArraySafely", False) 。 |
重要补充与最佳实践
- 版本一致性: 确保你的 PySpark (或 Spark)、PyArrow 和 Pandas 版本之间具有良好的兼容性 。不同版本对数据类型的支持程度可能不同,版本不匹配是许多诡异问题的根源。
- 性能权衡 : 将
spark.sql.execution.pandas.convertToArrowArraySafely设置为False的方案是一把双刃剑。它虽然绕过了错误,但也失去了 Arrow 在类型安全方面的重要保护,可能存在数据截断或溢出的风险 。因此,这应被视为最后的手段或临时解决方案。 - 替代方案: 对于非常大的数据集,如果内存压力可能导致不可预测的数据结构变化,可以考虑在 UDF 内部实现更精细的分批次处理逻辑,确保每个批次的数据都能被稳定地处理 。
个人认为如果没有十足把握,就尽量使用 spark sql 的算子处理数据,其算子种类已经非常丰富,能够解决绝大多数的场景,实在需要使用,一定要注意数据类型的问题 。