Hi, I'm curious about the remaining blockers. From my perspective, HIVE-29445 and HIVE-29415 might be needed if we include Iceberg v3. I think it's possible to put it off until 4.4. HIVE-29415 requires Iceberg 1.10.2 or 1.11.0 if I understand correctly.
Hadoop 3.5 is nice, but it hasn't been released yet. Most likely, we need to keep using 3.4 for a while. If we release 4.3 now, I think we should upgrade the Iceberg library from 1.10.0 to 1.10.1, which has some bug fixes and is not a big effort. Regards, Okumin On Thu, Jan 22, 2026 at 7:44 PM László Bodor <[email protected]> wrote: > > As to: > > #4 Hadoop 3.5 support would be great. Do we plan to include a newer Tez > version in 4.5? From what I can see, a significant number of changes have > recently landed in the repository. > > I don’t think Tez will reach 1.0.0 before Hive 4.5. Given the major version > milestone, we’re aiming to push more changes and are less afraid of breaking > things. So unless there’s something blocking, I believe Hive 4.5 can continue > to use Tez 0.10.5. My personal expectation for Tez 1.0.0 is "sometime later > this year". > > > On Tue, 20 Jan 2026 at 15:45, Ayush Saxena <[email protected]> wrote: >> >> Hi Attila, >> Regarding: >> >>> As you mentioned, Iceberg v3 is a major part of this release. I fully >>> agree, and I think we should clearly highlight that Hive is one of the core >>> engines supporting Iceberg v3. Potentially even earlier than Trino or other >>> competitors. One thing I would like to put attention to (coming from >>> discussions with the Apache Impala team) is that the Vector Delete spec >>> seems to have changed, with row-lineage becoming a prerequisite. As far as >>> I remember, this is not yet implemented in Hive. If we want Hive to >>> officially support Iceberg v3 with vector deletes, we should verify and >>> address this gap. https://iceberg.apache.org/spec/#row-lineage >> >> >> ----- >> I’m not entirely sure what the issue is on the Impala side. Iceberg V3 >> writes and Deletion Vectors are working correctly in Hive, even with the >> latest Iceberg version. As far as I know, Iceberg V3 does not allow >> committing a snapshot unless row IDs are populated. We also have tests in >> place that cover writes and deletes for Iceberg V3. >> >> We don’t have anything explicit for row lineage because Hive relies on >> Iceberg writers; we haven’t implemented custom writers. As a result, the >> Iceberg layer is responsible for populating the row IDs and the next row ID, >> and that seems to be working as expected. >> >> I tested this locally and verified the metadata files, which clearly contain >> the row IDs. I’m attaching screenshots of the metadata for reference. >> >> If Impala is observing unexpected behavior and there turns out to be an >> issue with our implementation, they can report it via a ticket. However, >> from a fundamentals point of view, this looks correct on the Hive/Iceberg >> side. >> >> -Ayush >> >> >> On Tue, 20 Jan 2026 at 19:24, Denys Kuzmenko <[email protected]> wrote: >>> >>> Hi everyone, >>> >>> +1 on collecting the performance numbers. >>> >>> I’d like to propose a few additional items to consider: >>> >>> #1 REST Catalog HA and vended credentials support >>> - HIVE-29391, >>> - HIVE-29228 >>> >>> #2 Federated Catalog support >>> - HIVE-28879 >>> >>> #3 Kubernetes manifests / Helm chart for Apache Hive deployment >>> >>> #4 New V3 items (that I am aware of) >>> >>> 1. VARIANT shredding: >>> - HIVE-29287, >>> - HIVE-29354 >>> >>> 2. Z-order support for Iceberg tables: >>> - HIVE-29132 >>> >>> Best regards, >>> Denys
