aokolnychyi commented on a change in pull request #1738: URL: https://github.com/apache/iceberg/pull/1738#discussion_r520056497
########## File path: spark3-extensions/src/main/scala/org/apache/spark/sql/catalyst/optimizer/RewriteDelete.scala ########## @@ -0,0 +1,160 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.spark.sql.catalyst.optimizer + +import java.util.UUID +import org.apache.spark.sql.{sources, AnalysisException} +import org.apache.spark.sql.catalyst.analysis.Resolver +import org.apache.spark.sql.catalyst.expressions.{Alias, Attribute, AttributeReference, EqualNullSafe, Expression, InputFileName, Literal, Not, PredicateHelper, SubqueryExpression} +import org.apache.spark.sql.catalyst.expressions.Literal.FalseLiteral +import org.apache.spark.sql.catalyst.plans.logical.{Aggregate, DeleteFromTable, DynamicFileFilter, Filter, LocalRelation, LogicalPlan, OverwriteFiles, Project} +import org.apache.spark.sql.catalyst.rules.Rule +import org.apache.spark.sql.connector.catalog.{SupportsMetadataOnlyDeletes, Table} +import org.apache.spark.sql.connector.write.{LogicalWriteInfo, LogicalWriteInfoImpl, RowLevelOperationsBuilder, SupportsPushDownRowLevelFilters} +import org.apache.spark.sql.execution.datasources.DataSourceStrategy +import org.apache.spark.sql.execution.datasources.v2.{DataSourceV2Relation, DataSourceV2ScanRelation} +import org.apache.spark.sql.internal.SQLConf +import org.apache.spark.sql.types.{BooleanType, StructType} +import org.apache.spark.sql.util.CaseInsensitiveStringMap + +// TODO: should be part of early scan push down after the delete condition is optimized +object RewriteDelete extends Rule[LogicalPlan] with PredicateHelper { + + import org.apache.spark.sql.execution.datasources.v2.ExtendedDataSourceV2Implicits._ + + private val FILE_NAME_COL = "_file" + + override def apply(plan: LogicalPlan): LogicalPlan = plan resolveOperators { + // no need to execute this delete as the condition is false + case DeleteFromTable(_, Some(FalseLiteral)) => + LocalRelation() + + // don't rewrite deletes that can be answered using metadata only operations + case d @ DeleteFromTable(r: DataSourceV2Relation, Some(cond)) if isMetadataOnlyOperation(r, cond) => + d + + // rewrite all operations that require reading the table to delete records + case DeleteFromTable(r: DataSourceV2Relation, Some(cond)) => + // TODO: do a switch based on whether we get BatchWrite or DeltaBatchWrite + val writeInfo = newWriteInfo(r.schema) + val builder = r.table.asRowLevelModifiable.newRowLevelOperationsBuilder(writeInfo) + + pushDownFilters(builder, cond, r.output) + + val scan = builder.buildScan() + val scanRelation = DataSourceV2ScanRelation(r.table, scan, r.output) + val filterPlan = buildFilterPlan(cond, scanRelation) + + val batchWrite = builder.buildBatchWrite() + // TODO: group by something so that we can write back + // Option 1: repartition/sort by partition values + // Option 2: repartition by _file and local sort by partition values (how to deal with 1 GB files?) Review comment: Subquery execution will introduce a shuffle so the data will be everywhere. If we decide to write it after that, we will produce a huge number of small files. Also, if we don't add a shuffle, we probably won't be able to write 1-1 files as the input split size will control our target file size. In our internal implementation, we went for option 1 initially. In certain cases, this poses a problem. For example, let's say you compacted your table and produced 1GB sorted files (it is an extremely expensive operation). If you do a delete and try to resort the data again before writing, this will be way too expensive. Moreover, the file sizes won't be ideal so you will most likely have to compact again. So, it seems to me that we should try to write 1-1 replacements. That way, if you had 1 GB sorted file, you would delete records and write 1GB file again. If we introduce a global sort by `_file` that will be hard to scale (e.g. extra job for skew estimation, having a single task write that much of data, etc). Instead, we may hash partition it by `_file`. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
