carloea2 commented on code in PR #8512: URL: https://github.com/apache/texera/pull/8512#discussion_r4254317234
########## common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/source/scan/parquet/ParquetScanSourceOpDesc.scala: ########## @@ -0,0 +1,190 @@ +/* + * 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.texera.amber.operator.source.scan.parquet + +import com.fasterxml.jackson.annotation.JsonIgnoreProperties +import org.apache.parquet.hadoop.ParquetFileReader +import org.apache.parquet.io.LocalInputFile +import org.apache.texera.amber.core.executor.OpExecWithClassName +import org.apache.texera.amber.core.storage.DocumentFactory +import org.apache.texera.amber.core.tuple.Schema +import org.apache.texera.amber.core.virtualidentity.{ExecutionIdentity, WorkflowIdentity} +import org.apache.texera.amber.core.workflow.{PhysicalOp, SchemaPropagationFunc} +import org.apache.texera.amber.operator.StandaloneCodeGenerator +import org.apache.texera.amber.operator.StandaloneCodeGenerator.SourceFilePlaceholder +import org.apache.texera.amber.operator.source.scan.ScanSourceOpDesc +import org.apache.texera.amber.util.JSONUtils.objectMapper + +import java.io.IOException +import java.net.URI +import scala.util.Using + +/** + * Reads a Parquet file. The format states its own column types in a footer, so + * unlike the CSV and JSONL sources this one infers nothing: the INTEGER the + * file was written with is the INTEGER that arrives. + */ +@JsonIgnoreProperties(value = Array("fileEncoding")) +class ParquetScanSourceOpDesc extends ScanSourceOpDesc with StandaloneCodeGenerator { + + fileTypeName = Option("Parquet") + + // A DECIMAL is the one column pandas does not land on the same type as the + // executor: it fills that column with decimal.Decimal objects, which a script + // cannot then multiply by a float. pyarrow is what pandas reads a Parquet file + // with; the footer is asked for directly here to read it the executor's way. + override def standaloneImports(): Seq[String] = + Seq("from datetime import date", "from decimal import Decimal", "import pyarrow.parquet as pq") + + override def standaloneSourcePath(): Option[String] = fileName + + override def generateStandaloneCode(): String = { + // No timestamps to parse, and no dtype map. pandas reads the types out of + // the same footer the executor does, which is the whole point of the format; + // the text formats parse theirs because they carry nothing to read. + // Read into the nullable dtypes, as the Arrow source is. Parquet says of + // every value whether it is there, and a numpy column has nowhere to put + // that: pandas widens a holed integer column through a float, where every + // value past 2^53 is rounded and 9007199254740993 came back as ...992. The + // executor reads the exact long, and the declared column stays integral. + // + // The footer is handed back to the reader stripped of its metadata. A file + // pandas wrote records there which of its columns held the frame's index, + // and pandas restores those as an index rather than as columns: a file + // written from a frame keyed by `customer_id` reads back without that + // column, and a projection naming it raises. The executor reads the columns + // the footer states and knows nothing of an index, so it hands `customer_id` + // on like any other. Stripped, pandas reads every column the file holds, + // under the name the footer gives it and in the order it states them. + // + // An INT96 timestamp is read in microseconds, in the footer and in the rows + // alike. pyarrow's default is nanoseconds, which only reach 1677 to 2262, and + // a date outside them wraps silently: 2500 read back as 1915. The executor + // keeps the digits under the microsecond, which this drops. + val read = + s"""|out1df = pd.read_parquet( + | $SourceFilePlaceholder, + | dtype_backend="numpy_nullable", + | schema=pq.ParquetFile( + | $SourceFilePlaceholder, coerce_int96_timestamp_unit="us" + | ).schema_arrow.remove_metadata(), + | coerce_int96_timestamp_unit="us", Review Comment: I confirmed the documented loss changes results. An INT96 file containing 2024-03-05 12:00:00.123456001, 2024-03-05 12:00:00.123456789 and a year 2500 value has 3 distinct native timestamps but only 2 after export. The original ordinary fixture also reads .123456000 instead of .123456789. Full microsecond controls pass. Please preserve these distinct values rather than rounding them globally; a per-value representation can keep ordinary nanoseconds alongside wide dates, as the #8358 update does. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
