[
https://issues.apache.org/jira/browse/HIVE-12631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033964#comment-16033964
]
Sergey Shelukhin commented on HIVE-12631:
-----------------------------------------
Wrt VectorizedOrcAcidRowBatchReader.DeleteEventsOverflowMemoryException - what
is the logic for this one? Should it be different for LLAP compared to Tez? If
it's based on process size (like IIRC GBY table used to be until it was fixed),
it's going to cause LLAP to OOM if all the tasks try to get to that limit.
> LLAP: support ORC ACID tables
> -----------------------------
>
> Key: HIVE-12631
> URL: https://issues.apache.org/jira/browse/HIVE-12631
> Project: Hive
> Issue Type: Bug
> Components: llap, Transactions
> Reporter: Sergey Shelukhin
> Assignee: Teddy Choi
> Attachments: HIVE-12631.1.patch, HIVE-12631.2.patch,
> HIVE-12631.3.patch, HIVE-12631.4.patch, HIVE-12631.5.patch,
> HIVE-12631.6.patch, HIVE-12631.7.patch, HIVE-12631.8.patch, HIVE-12631.8.patch
>
>
> LLAP uses a completely separate read path in ORC to allow for caching and
> parallelization of reads and processing. This path does not support ACID. As
> far as I remember ACID logic is embedded inside ORC format; we need to
> refactor it to be on top of some interface, if practical; or just port it to
> LLAP read path.
> Another consideration is how the logic will work with cache. The cache is
> currently low-level (CB-level in ORC), so we could just use it to read bases
> and deltas (deltas should be cached with higher priority) and merge as usual.
> We could also cache merged representation in future.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
