[ 
https://issues.apache.org/jira/browse/HIVE-29866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

László Bodor resolved HIVE-29866.
---------------------------------
    Resolution: Fixed

merged to master, thanks a lot [~dkuzmenko] for reviewing this!

> Optimize LLAP IO cache encoding path for text tables with MultiDelimitSerDe
> ---------------------------------------------------------------------------
>
>                 Key: HIVE-29866
>                 URL: https://issues.apache.org/jira/browse/HIVE-29866
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: László Bodor
>            Assignee: László Bodor
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 4.3.0
>
>         Attachments: Screenshot 2026-09-03 at 13.56.34.png, 
> TopLevelParseBench.java, heap-dump_Top_Components.zip
>
>
> *MultiDelimitSerDe currently OOMs in LLAP text-cache encoding*
> {*}TLDR{*}: LLAP OOMs while encoding large rows from {*}MultiDelimitSerDe{*}, 
> please find Eclipse MAT HTML report for the same: 
> [^heap-dump_Top_Components.zip]
> {*}Details{*}:
> When LLAP ingests text and writes it into its ORC-encoded cache, the routing 
> gate in 
> [{{VectorDeserializeOrcWriter.create()}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/llap-server/src/java/org/apache/hadoop/hive/llap/io/encoded/VectorDeserializeOrcWriter.java#L101]
>  today is:
> {code:java}
> if (... || !(serDe instanceof LazySimpleSerDe)) {
>   return new DeserializerOrcWriter(serDe, sourceOi, allocSize);
> }
> {code}
> ({{{}DeserializerOrcWriter{}}} lives as an inner class in 
> [{{SerDeEncodedDataReader}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/llap-server/src/java/org/apache/hadoop/hive/llap/io/encoded/SerDeEncodedDataReader.java#L1564].)
> {{MultiDelimitSerDe}} fails the check, so every row travels through 
> {{{}DeserializerOrcWriter{}}}, the generic per-row fallback. For each row it:
>  # Calls {{serDe.deserialize(Writable)}} → a fresh 
> *[{{LazyStruct}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/serde/src/java/org/apache/hadoop/hive/serde2/lazy/LazyStruct.java]*
>  wrapping…
>  # …a fresh 
> *[{{LazyString}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/serde/src/java/org/apache/hadoop/hive/serde2/lazy/LazyString.java]
>  / 
> [{{LazyInteger}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/serde/src/java/org/apache/hadoop/hive/serde2/lazy/LazyInteger.java]
>  / …* object per column (writable + underlying byte buffer refs).
>  # Walks the struct through an {{ObjectInspector}} — every field getter 
> allocates a *{{{}Text{}}}/{{{}IntWritable{}}}/…* to hand to the ORC writer.
>  # ORC's {{TreeWriter}} then re-encodes those objects into columnar buffers.
> For a wide row (thousands of columns), that's {*}~1 struct + ~N lazy field 
> objects + ~N writables per row{*}, all short-lived. Combined with LLAP's 
> normal cache-fill pressure, the daemon runs out of heap.
> The vectorized path avoids all of this: 
> [{{LazySimpleDeserializeRead.topLevelParse()}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/serde/src/java/org/apache/hadoop/hive/serde2/lazy/fast/LazySimpleDeserializeRead.java#L419]
>  scans the raw bytes into a reused 
> [{{VectorizedRowBatch}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/storage-api/src/java/org/apache/hadoop/hive/ql/exec/vector/VectorizedRowBatch.java#L40]
>  
> ([{{DEFAULT_SIZE=1024}}|https://github.com/apache/hive/blob/bff3870c637184d096c1d6789761e0c0afdd6037/storage-api/src/java/org/apache/hadoop/hive/ql/exec/vector/VectorizedRowBatch.java#L66]
>  rows at a time, fixed-size column vectors, {*}zero per-row allocation{*}). 
> Wiring MultiDelimit into that path is what the fix does.
> please also find (sorry about dark mode here, the winner is StructTreeWriter):
> !Screenshot 2026-09-03 at 13.56.34.png|width=783,height=130!
> 12 instances most probably belong to 12 IO threads in the LLAP daemon where 
> this investigation took place
>  
> Repro steps, kinda pseudo:
> h2. How to reproduce
> # Create a MultiDelimit text table:
> {code:sql}
> CREATE TABLE mdelim_test (a STRING, b STRING, c STRING)
> ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe'
> WITH SERDEPROPERTIES ('field.delim'='~|')
> STORED AS TEXTFILE;
> {code}
> # Load a large text file with {{~|}} as the field separator (wide rows and/or 
> many rows amplify the effect).
> # On LLAP with cache enabled ({{hive.llap.io.enabled=true}}), run:
> {code:sql}
> SELECT COUNT(*) FROM mdelim_test;
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to