How We Brought Back Tez UI for Hive 4.x, Securely

If you’ve worked with Apache Hive recently, you’ve likely noticed a glaring omission: the Tez UI is gone. For data engineers, the Tez UI was the ultimate magnifying glass. It provided a visual representation of Directed Acyclic Graphs (DAGs), vertex- and task-level execution details, and resource bottlenecks. Without it, tuning and debugging slow queries feels like navigating a maze in the dark.

While commercial Hadoop distributions ship their own monitoring tools, open-source and bare-metal users are often left staring at raw text logs. As part of a recent proof-of-concept (POC) at Ksolves, we took on the challenge of bringing the Tez UI back to Hive 4.x, and more importantly, making it enterprise-grade secure.

Here’s a look at why this component disappeared, how we brought it back, and the security architecture that makes it safe for production.

The Problem: Why Did Tez UI Disappear?

The removal of the standalone Tez UI wasn’t a sudden accident; it was a consequence of an architectural shift in the Hadoop ecosystem.

Starting around Hive 3.x, the ecosystem moved its focus from YARN’s Application Timeline Server v1 (ATS v1) to Timeline Service v2 (ATS v2). ATS v2 is built on a distributed, scalable backend (HBase) designed for large multi-tenant clusters, and most modern distributions optimized their tooling around it. The standalone Tez UI, however, was written to talk to the ATS v1 REST API, not ATS v2. As distributions moved on, the standalone UI fell out of active packaging and maintenance, and many open-source Hive 4.x deployments were left without it by default.

The Solution: A Conceptual Architecture

To solve this, we didn’t downgrade any core services; we reconnected the missing link. By deploying the standalone Tez UI (built against a Tez 0.10.x release compatible with Hive 4.x’s bundled Tez version) and wiring it correctly to an ATS v1 Timeline Server endpoint, we restored full DAG visibility without disturbing the rest of the stack.

Here’s how data flows through the integrated environment:

1. Client interaction: A user submits a query via Beeline or a JDBC/ODBC client.
2. Execution engine: HiveServer2 compiles the query and hands the execution plan to Apache Tez.
3. Resource management: YARN allocates containers (via the Tez AppMaster) and executes the DAG across the cluster’s NodeManagers.
4. History logging: As the DAG runs, the Tez AppMaster emits timeline events, which are pushed to the Timeline Server (ATS v1) instead of being discarded once the application finishes.
5. Visualization: The standalone Tez UI queries the ATS v1 REST API for this historical and near-real-time data and renders it as interactive DAG graphs, vertex swimlanes, and counters.

It’s worth noting this is an architectural trade-off rather than a “free” restoration: running ATS v1 alongside a cluster whose other tooling may assume ATS v2 means maintaining an additional timeline service, and teams should weigh this against their long-term roadmap (for example, evaluating whether Tez’s own future releases will add native ATS v2 support).

Fortifying the Setup: The Security Triad

In a modern Big Data environment, deploying a UI is easy; securing it is the real challenge. Leaving a monitoring endpoint open can expose sensitive metadata: query text, DAG structure, resource consumption patterns, and internal cluster topology.

To make this POC production-ready, we wrapped the architecture in three layers of security:

1. Kerberos: The Foundation of Trust

Kerberos is the authentication backbone for the whole cluster. Every service — HiveServer2, YARN’s ResourceManager and NodeManagers, and the Timeline Server — authenticates using service principals and keytabs, and every client must present a valid Kerberos ticket (via kinit) before interacting with the cluster. Because service-to-service RPC calls are Kerberized end to end, an unauthenticated process cannot impersonate a service, inject fabricated timeline events, or read timeline data it isn’t entitled to.

2. SPNEGO: Seamless Web Authentication

Kerberizing back-end RPC is only half the problem; the Tez UI and the Timeline Server’s REST endpoints are accessed over HTTP from a browser. We enabled SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) on the Timeline Server’s web interface. SPNEGO lets a browser that already holds a valid Kerberos ticket (via an OS-level ticket cache and browser configuration) negotiate authentication transparently over HTTP, instead of falling back to weaker mechanisms like HTTP Basic Auth. A user without a valid ticket is challenged and denied at the HTTP layer before ever reaching application data.

3. ACLs: Strict Data Privacy

Authentication proves identity; authorization decides what that identity is allowed to see. On top of Kerberos and SPNEGO, we configured YARN and Timeline Server ACLs (yarn.admin.acl, application-level view/modify ACLs, and Timeline Server’s own access controls) so that regular users can only view the DAGs and logs for applications they submitted, while designated admin accounts retain cluster-wide visibility. This gives multi-tenant clusters a real isolation boundary between departments or teams sharing the same Hive/Tez environment.

The Value Delivered

By integrating the Tez UI with Hive 4.x on a fully secured cluster, this POC delivered three concrete wins:

• Restored developer productivity: Engineers can visually inspect vertex dependencies, skewed tasks, and stage-level bottlenecks instead of grepping through YARN logs.
• No security trade-offs: Kerberos, SPNEGO, and ACLs mean the monitoring layer inherits the same trust boundary as the rest of the data lake; nothing is exposed to gain visibility.
• Cost-effective observability: An open-source solution that restores DAG-level insight without an immediate dependency on commercial monitoring add-ons.

Wrapping Up

The deprecation of a tool doesn’t always mean it has lost its value. The Tez UI remains one of the most effective ways to understand how Hive queries actually execute under Tez. By understanding why it disappeared, deliberately reconnecting it to ATS v1, and layering in Kerberos, SPNEGO, and ACLs, we showed it’s entirely possible to bring this visibility back to a modern, secure Hive 4.x cluster.

Ksolves is a trusted IT company that helps enterprises design, secure, and optimize their Hadoop, Hive, and Spark ecosystems. Our team regularly works on exactly this kind of deep-in-the-stack problem: restoring lost tooling, hardening clusters with Kerberos/SPNEGO/ACLs, and tuning query engines for scale.

If your team is dealing with Hive performance issues, security gaps, or upgrade challenges like the one described above, Ksolves experts can help you. We provide Apache Hive support services to help you get the most out of your data platform, from architecture reviews and cluster hardening to hands-on migration and tuning support.

FAQs