Continuous events, current state, immediate serving

Build real-time analytics without a second serving stack

Ingest streams and CDC, apply primary-key updates and serve fresh dashboards, APIs and embedded analytics from the same engine.

All sources / last 1 hour

Unified event stream

1 HOUR

ALL SOURCESAPPLICATIONKUBERNETESSECURITY

TIMESOURCELEVELMESSAGE

10:42:18.904checkout-apiERRORpayment upstream timeout · trace=8fa2

10:42:18.887k8s / podWARNreadiness probe failed · checkout-7c4

10:42:17.512doris-feINFOquery finished · latency=184ms

Error spike began 3 min after the checkout deploymentInvestigate →

The warehouse explains yesterday, while customer-facing and operational applications need the latest state now. Separate stream processors and serving stores create another consistency boundary.

Real-time analytics is useful when fresh data and historical context answer through the same model.

The pain

Fresh data arrives before the analytical path is ready

Batch refreshes make dashboards stale.

Upserts require a separate operational serving store.

Streaming and historical data are queried through different systems.

Every new API duplicates transformations already defined for BI.

REFERENCE PATH / REAL-TIME ANALYTICS

Fresh events become query-ready decisions in one engine.

Combine continuous ingestion, row-level change handling and materialized acceleration so dashboards, APIs and applications can read the same current state.

Data sources

OLTP databases

PostgreSQL · MySQL

Event streams

Kafka · CDC

Lake files

Iceberg · object storage

Ingestion

Routine Load

Continuous from Kafka

Stream Load

HTTP streaming ingest

CDC paths

Native jobs or existing pipelines

Update

Unique Key tables

Primary-key upserts

Merge-on-Write

Latest row is query-ready

Materialized views

Repeated query acceleration

Analyze

Real-time SQL

Current and historical data

Multi-table joins

Facts with live dimensions

Cost-based planning

Vectorized MPP execution

Serve

BI tools

Dashboards and reporting

APIs

Application-facing queries

Embedded analytics

Customer-facing experiences

TECHNICAL SOURCESDoris data updates Doris materialized views

BUILD PLAN / REAL-TIME ANALYTICS

Make freshness, correctness and serving one measurable path

Choose one event stream and one consumer. Define which key represents current state, how late data wins and what freshness and query latency the workload actually requires.

01Kafka · CDC · HTTP

02Continuous load

03Unique Key · MoW

04BI · API · application

DORIS DATA DESIGN

Use Unique Key Merge-on-Write only where the latest row per key is required.
Keep immutable event history in append-oriented tables when replay matters.
Build materialized views for stable repeated aggregations, not speculative dashboards.
Separate ingestion and serving workloads when concurrency requires isolation.

BUILD IT IN UNIFYLOGS

Register and test the source path with representative updates and late events.
Inspect generated table design, distribution and retention before creating it.
Use SQL Studio to validate current-state and historical queries side by side.
Observe node pressure and runtime queries under the target concurrency.

BEFORE CUTOVER

Acceptance gates

1Late update semantics are correct
2Freshness target is met
3Representative p95 query passes
4Consumer reads one authoritative state

What changes

The operating pattern changes—not only the tool.

One current state for BI and application queries
Fewer copies between stream, warehouse and serving layers
Incremental updates without rebuilding full tables
A measurable freshness and latency path per workload

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.