Qiegang Long created SPARK-60442:
------------------------------------
Summary: Variant decoding rejects spec-valid decimals
Key: SPARK-60442
URL: https://issues.apache.org/jira/browse/SPARK-60442
Project: Spark
Issue Type: Bug
Components: PySpark, SQL
Affects Versions: 4.0.4, 4.1.3, 4.2.0, 4.3.0
Reporter: Qiegang Long
h3. Problem
Spark rejects a variant decimal as {{MALFORMED_VARIANT}} when its scale is
larger than the max precision of its physical type (9 for decimal4, 18 for
decimal8):
{code:java}
// VariantUtil.checkDecimal
if (d.precision() > maxPrecision || d.scale() > maxPrecision) throw
malformedVariant(); {code}
The [Variant
spec|https://github.com/apache/parquet-format/blob/master/VariantEncoding.md]
only ties precision to the physical type. All three decimal types store a "1
byte scale in range [0, 38]". The physical type only sets the size of the
unscaled integer; the scale just places the decimal point.
h3. Examples
The same value, 1.234E-10 (unscaled 1234, scale 13, precision 4), in different
physical types:
{noformat}
Encoding Value bytes (hex) Value Spark today
decimal8, scale 13 24 0D D2 04 00 00 00 00 00 00 1.234E-10 0.0000000001234
decimal4, scale 13 20 0D D2 04 00 00 1.234E-10
MALFORMED_VARIANT
decimal8, scale 25 24 19 D2 04 00 00 00 00 00 00 1.234E-22
MALFORMED_VARIANT
{noformat}
The first two rows are the same value, but only the decimal8 encoding is
accepted.
h3. Impact
parquet-java 1.17.0+ ([PR
#3335|https://github.com/apache/parquet-java/pull/3335]) picks the decimal type
by precision only, so it writes 1.234E-10 as decimal4 with scale 13. Spark
fails on any expression that decodes such a field ({{to_json}},
{{variant_get}}, {{cast}}, {{schema_of_variant}}). Data written only by Spark
is not affected, because Spark's writer picks the type by both scale and
precision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
