UnifyLogs
TRPlan an evaluation
All use cases

Open lake storage, real-time analytical paths

Build your real-time data lakehouse

Query Iceberg, Hudi and Paimon where they live, join them with operational data and accelerate only the paths that need real-time response.

Object storage keeps history affordable, but the team now operates separate engines for lake SQL, ETL and low-latency serving—and copies data between them to make each workload usable.

A lakehouse should remove boundaries between hot and historical data—not add another query silo.

The pain

The lake is open; the path to an answer is fragmented

01

Ad-hoc queries and real-time dashboards use different engines.

02

Data copies add freshness lag and duplicate storage.

03

Hot and cold data follow separate access and permission paths.

04

Every new source adds another pipeline before it can be joined.

REFERENCE ARCHITECTURE / 2026

One query plane. Two storage temperatures. Open formats remain open.

Doris does not require every byte to move into its internal storage. Query the lake in place, keep frequently used paths hot, and use one SQL plan across both.

FORMAT BOUNDARIES

Choose the path the table format actually supports.

Open table formatRead / queryDirect write-back from DorisUse it when
Apache IcebergSupportedINSERT, OVERWRITE, UPDATE, DELETE; MERGE INTO is experimental in 4.1You want the deepest Doris-managed read/write lifecycle on the lake.
Apache HudiSupportedNot supportedExisting Hudi COW/MOR tables need snapshot, time-travel or incremental reads; writes stay with the current writer.
Apache PaimonSupportedNot supported in current 4.x docsStreaming changelogs and primary-key lake tables already exist; Doris queries or materializes the analytical path.

Important boundary: federation is not a cross-system transaction layer. Keep write-heavy operational updates in their source or Doris internal tables; use lake write-back deliberately.

ADOPTION PATH

Build it without rebuilding everything.

01

Federate first

Register catalogs and run cross-source SQL. Nothing moves yet.

02

Observe the hot set

Measure repeated joins, dashboards and latency-sensitive tables.

03

Materialize selectively

Move only valuable hot paths into Doris internal storage or Iceberg write-back.

04

Retire duplicate compute

Remove the Spark/Trino jobs that no longer own a distinct workload.

Architecture sources6 verified references

COREVA EXECUTION SURFACE

Turn the architecture into an observable operating path

Register the external catalog, validate it in SQL Studio, then observe the Doris cluster that serves the hot path. Accelerate only after the in-place query is measured.

01Iceberg · Hudi · Paimon
02External Catalog
03Doris SQL + hot path
04BI · API · operations
DORIS DATA DESIGN
  • Use Multi Catalog to query open table formats in place.
  • Join lake tables with internal real-time tables and JDBC dimensions.
  • Use file cache or asynchronous materialized views for repeated hot paths.
  • Keep format-specific write-back and snapshot behavior explicit.
BUILD IT IN COREVA
  • Create and test the connection in External Catalogs.
  • Browse objects in Data Catalog and validate joins in SQL Studio.
  • Inspect node and runtime metrics before choosing acceleration.
  • Track catalog, storage and materialized-view changes as governed operations.
BEFORE CUTOVER

Acceptance gates

  • 1Catalog metadata is visible
  • 2Baseline query is correct
  • 3Freshness and p95 target are written
  • 4Acceleration reduces cost or latency measurably

What changes

The operating pattern changes—not only the tool.

  • One SQL surface across lake and warehouse data
  • Open object-storage history without forcing a full migration
  • Low-latency serving only where the business needs it
  • Fewer copies, engines and freshness gaps

CONTACT / HUBSPOT

Bring one workload. Leave with a measured decision.

We’ll map the current cost and investigation path, then define success criteria before you replace anything.