Spark dataset.mapPartitions debug到mapPartitions的函数体

Spark数据处理:debug MapPartitions函数
这段代码展示了如何在Spark中对mapPartitions函数进行调试。首先,定义一个空的Dataset,然后获取其Schema。接着,使用mapPartitions方法,传入一个实现了MapPartitionsFunction接口的匿名类,并在call方法中处理数据。在debug时,需要定位到mapPartitions调用处,点击StepInto进入call方法进行逐行调试。
Dataset dataset = null;
StructType schema = dataset.schema();
Dataset<Row> rowDataset = dataset.mapPartitions(
        new MapPartitionsFunction<Row, Row>() {
            @Override
            public Iterator<Row> call(Iterator<Row> iterator) throws Exception {
                List<Row> list = new ArrayList<>();
                while (iterator.hasNext()) {
                    Row next = iterator.next();
                }
                return null;
            }
        }
        , RowEncoder.apply(schema));

如上代码,如果debug需要定位到new MapPartitionsFunction<Row, Row>() 的call方法,需要如下操作:
1、定位到mapPartitions所在行
在这里插入图片描述
2、点击左下角debug的Step Into按钮
在这里插入图片描述
此时代码会出现如下情景:
在这里插入图片描述
3、这时点击call的函数体,此时就可进入call的函数里进行debug

at org.apache.spark.sql.errors.QueryCompilationErrors$.queryFromRawFilesIncludeCorruptRecordColumnError(QueryCompilationErrors.scala:2896) at org.apache.spark.sql.execution.datasources.json.JsonFileFormat.buildReader(JsonFileFormat.scala:113) at org.apache.spark.sql.execution.datasources.FileFormat.buildReaderWithPartitionValues(FileFormat.scala:138) at org.apache.spark.sql.execution.datasources.FileFormat.buildReaderWithPartitionValues$(FileFormat.scala:129) at org.apache.spark.sql.execution.datasources.TextBasedFileFormat.buildReaderWithPartitionValues(FileFormat.scala:346) at org.apache.spark.sql.execution.FileSourceScanExec.inputRDD$lzycompute(DataSourceScanExec.scala:548) at org.apache.spark.sql.execution.FileSourceScanExec.inputRDD(DataSourceScanExec.scala:537) at org.apache.spark.sql.execution.FileSourceScanExec.doExecute(DataSourceScanExec.scala:575) at org.apache.spark.sql.execution.SparkPlan.$anonfun$execute$1(SparkPlan.scala:195) at org.apache.spark.sql.execution.SparkPlan.$anonfun$executeQuery$1(SparkPlan.scala:246) at org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151) at org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:243) at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:191) at org.apache.spark.sql.execution.InputAdapter.inputRDD(WholeStageCodegenExec.scala:527) at org.apache.spark.sql.execution.InputRDDCodegen.inputRDDs(WholeStageCodegenExec.scala:455) at org.apache.spark.sql.execution.InputRDDCodegen.inputRDDs$(WholeStageCodegenExec.scala:454) at org.apache.spark.sql.execution.InputAdapter.inputRDDs(WholeStageCodegenExec.scala:498) at org.apache.spark.sql.execution.ProjectExec.inputRDDs(basicPhysicalOperators.scala:51) at org.apache.spark.sql.execution.WholeStageCodegenExec.doExecute(WholeStageCodegenExec.scala:751) at org.apache.spark.sql.execution.SparkPlan.$anonfun$execute$1(SparkPlan.scala:195) at org.apache.spark.sql.execution.SparkPlan.$anonfun$executeQuery$1(SparkPlan.scala:246) at org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151) at org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:243) at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:191) at org.apache.spark.sql.execution.SparkPlan.getByteArrayRdd(SparkPlan.scala:364) at org.apache.spark.sql.execution.SparkPlan.executeTake(SparkPlan.scala:498) at org.apache.spark.sql.execution.SparkPlan.executeTake(SparkPlan.scala:483) at org.apache.spark.sql.execution.CollectLimitExec.executeCollect(limit.scala:61) at org.apache.spark.sql.Dataset.collectFromPlan(Dataset.scala:4333) at org.apache.spark.sql.Dataset.$anonfun$head$1(Dataset.scala:3316) at org.apache.spark.sql.Dataset.$anonfun$withAction$2(Dataset.scala:4323) at org.apache.spark.sql.execution.QueryExecution$.withInternalError(QueryExecution.scala:546) at org.apache.spark.sql.Dataset.$anonfun$withAction$1(Dataset.scala:4321) at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$6(SQLExecution.scala:125) at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:201) at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$1(SQLExecution.scala:108) at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:900) at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:66) at org.apache.spark.sql.Dataset.withAction(Dataset.scala:4321) at org.apache.spark.sql.Dataset.head(Dataset.scala:3316) at org.apache.spark.sql.Dataset.take(Dataset.scala:3539) at org.apache.spark.sql.Dataset.getRows(Dataset.scala:280) at org.apache.spark.sql.Dataset.showString(Dataset.scala:315) at org.apache.spark.sql.Dataset.show(Dataset.scala:838) at org.apache.spark.sql.Dataset.show(Dataset.scala:797) at org.apache.spark.sql.Dataset.show(Dataset.scala:806) at com.itligh.sparksql.SparkSql01_Env.main(SparkSql01_Env.java:16)
最新发布
11-05
<think>我们正在处理一个Spark SQL运行时异常:`org.apache.spark.sql.errors.QueryCompilationErrors$.queryFromRawFilesIncludeCorruptRecordColumnError` 根据用户提供的引用,我们并没有直接看到这个异常。但是,用户提供了三个引用,其中引用[1]是关于非类型化Scala UDF的异常,引用[2]是关于计划树生成时的错误,引用[3]是关于序列化异常。 用户当前询问的是另一个不同的异常:`QueryCompilationErrors`中的`queryFromRawFilesIncludeCorruptRecordColumnError`。 由于用户提供的引用中没有直接提到这个异常,我们需要根据异常名称进行推断。 异常名称:`queryFromRawFilesIncludeCorruptRecordColumnError` 从名称看,可能与读取原始文件(raw files)时包含损坏记录列(corrupt record column)有关。 在Spark中,当读取文件(如JSON、CSV)时,可以设置一个选项`columnNameOfCorruptRecord`来将解析错误的行放入该列。但是,如果在查询中引用了这个损坏记录列,而该列在数据源中并不存在(或者设置不当),则可能会抛出此异常。 常见原因: 1. 设置了`columnNameOfCorruptRecord`选项,但在查询中使用了该列,而该列在数据源中并不存在(因为实际读取时可能没有损坏记录,或者数据源中根本没有该列)。 2. 在读取文件时,指定的`schema`中不包含该损坏记录列,但设置了`columnNameOfCorruptRecord`,并且在查询中引用了该列。 解决方案: 1. 检查是否在读取文件时设置了`columnNameOfCorruptRecord`选项,例如: ```scala spark.read.format("json") .option("columnNameOfCorruptRecord", "_corrupt_record") .schema(someSchema) .load(path) ``` 然后,在查询中避免直接使用该列(除非你确实需要),或者确保该列在`schema`中被定义。 2. 如果不需要处理损坏记录,可以去掉该选项。 3. 如果确实需要该列,确保在`schema`中定义该列,类型为`StringType`。 4. 另一种方法是设置`mode`选项,例如`PERMISSIVE`(默认,将损坏记录放入由`columnNameOfCorruptRecord`指定的列)、`DROPMALFORMED`(忽略损坏记录)或`FAILFAST`(遇到损坏记录立即失败)。如果选择`FAILFAST`,则不需要`columnNameOfCorruptRecord`。 5. 检查查询中是否引用了该损坏记录列。如果不需要,则从查询中移除对该列的引用。 由于用户没有提供具体的代码,我们只能给出一般性的建议。 另外,用户之前提到的引用[1]是关于UDF的,引用[3]是关于序列化的,可能与当前问题无关。引用[2]提到生成计划树时出错,而当前异常也是编译时错误(QueryCompilationError),所以可能是在生成执行计划时遇到问题。 因此,我们建议用户检查读取数据源的代码,特别是与损坏记录列相关的设置。 如果用户没有设置损坏记录列,但异常仍然出现,那可能是因为数据源本身包含一个名为`_corrupt_record`的列,而Spark默认会使用这个列名?实际上,Spark默认不会设置,除非用户显式设置。 所以,我们重点检查用户代码中是否有设置`columnNameOfCorruptRecord`。 综上,解决方案步骤: 1. 检查读取数据源时是否设置了`columnNameOfCorruptRecord`选项,并检查该列是否在`schema`中定义。 2. 如果设置了,确保在查询中不引用该列(除非必须引用且该列存在)。 3. 尝试去掉该选项,或者更改模式(mode)为`DROPMALFORMED`或`FAILFAST`。 4. 如果问题仍然存在,检查数据源中是否已经有一个名为`_corrupt_record`的列(或者你设置的列名),并确保在`schema`中定义。 注意:该异常是编译时异常,所以它发生在计划阶段,而不是运行时。因此,错误信息中应该会指明具体的列名。 如果用户能够提供具体的异常堆栈和代码片段,可以更精确地定位。 由于用户没有提供相关引用,我们只能根据经验给出上述建议。 接下来,生成相关问题。 </think>### Spark SQL运行时异常解决方法 针对异常 `org.apache.spark.sql.errors.QueryCompilationErrors$.queryFromRawFilesIncludeCorruptRecordColumnError`,此错误通常与文件读取时处理损坏记录(corrupt record)相关。以下是系统性的解决方案: #### 1. **确认损坏记录处理配置** 此异常表明Spark在读取原始文件时检测到损坏记录列配置冲突: - 检查是否设置了 `columnNameOfCorruptRecord` 选项但未在查询中包含该列 - 验证数据源是否启用了损坏记录处理: ```scala spark.read.format("parquet") .option("columnNameOfCorruptRecord", "_corrupt_record") // 检查此配置 .load("path/to/files") ``` #### 2. **解决方案步骤** ✅ **方案1:显式包含损坏记录列** ```scala // 在Schema中明确定义损坏记录列 import org.apache.spark.sql.types._ val customSchema = new StructType() .add("valid_col1", StringType) .add("_corrupt_record", StringType) // 必须包含此列 spark.read.schema(customSchema) .option("columnNameOfCorruptRecord", "_corrupt_record") .parquet("input_path") ``` ✅ **方案2:禁用损坏记录处理** ```scala // 移除columnNameOfCorruptRecord配置 spark.read.format("parquet") .load("path/to/files") // 删除corrupt record相关选项 ``` ✅ **方案3:修改读取模式** ```scala // 使用FAILFAST模式直接报错而非记录损坏列 spark.read.option("mode", "FAILFAST").parquet("path") ``` #### 3. **配置优化** ```bash # 调整Spark配置(不推荐长期方案) spark-submit --conf spark.sql.legacy.allowUntypedScalaUDF=true ... ``` > **注意**:此配置可能掩盖其他类型问题[^1] #### 4. **根本原因分析** 此类异常通常由以下情况触发: - 数据文件损坏(如parquet文件页脚缺失) - Schema定义与文件实际结构不匹配 - 跨版本兼容问题(如Spark 2.4 → 3.x升级) ```mermaid graph LR A[读取文件] --> B{启用corrupt_record?} B -- 是 --> C[Schema包含该列?] C -- 否 --> D[抛出此异常] C -- 是 --> E[正常执行] ``` **最佳实践**:建议优先采用**方案1**明确定义损坏记录列,确保Schema完整性。若业务无需处理损坏数据,则采用**方案2**彻底禁用该功能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值