Real-Time Lakehouse Migration: Tongcheng's Hudi→Paimon Shift & Trip.com's StarRocks Unification

Background and Technical Evolution

Online travel is among the most data-intensive industries, characterized by numerous business lines (hotels, flights, trains, packages, corporate travel, marketing), pronounced tidal traffic patterns (holidays, hourly spikes, flash sales), and dual demand for executive analytics and real-time operational dashboards. Lakehouse evolution in this sector is driven incrementally by legacy architecture pain points rather than greenfield builds.

Two companies address different layers of the real-time lakehouse pipeline:

Tongcheng Travel replaces the storage foundation — migrating real-time lake tables from Apache Hudi to Apache Paimon to solve slow real-time writes and large-table synchronization resource exhaustion.

Trip.com (Artnova platform) replaces the query entry point — using StarRocks as a unified query engine to directly query Hive data lake via Hive Catalog, eliminating Trino and the data warehouse replicas previously built for acceleration.

One operates on the write side, the other on the read side, together covering the two most common migration patterns in real-time lakehouse adoption.

Core Concepts and Architecture Positioning

Tongcheng uses federated HDFS as the storage base with Paimon as the unified lake table format; upper-layer query engines include Flink, Spark, Trino, and StarRocks. The core problem: real-time ODS tables must support streaming updates while being reused by multiple downstream consumers — the "storage unification" requirement. Before Paimon, Kudu and Hudi successively filled this role but both fell short.

Trip.com Artnova sits on a Hive data lake managed by Hive Metastore, with StarRocks as the unified query engine. The core problem: the lake itself was too slow to query, forcing critical data to be copied into a dedicated warehouse. StarRocks enables "warehouse-grade performance directly querying the lake," allowing removal of Trino and warehouse replicas.

Key distinction: Tongcheng changes the storage format to make writes and real-time updates smoother; Trip.com changes the query engine so lake data no longer needs copying to be queried fast. One moves the data landing layer, the other moves the consumption layer.

Deep Dive: Underlying Principles

4.1 Tongcheng Travel: Three-Stage Evolution and Kernel Reasons

According to Tongcheng's big data expert at Flink Forward Asia 2023, their streaming lakehouse went through three stages, each with kernel-level explanations.

Stage 1: Spark + Apache Kudu

Early offline warehouse on Hive; Kudu introduced for real-time needs. ODS data written to both Hive and Kudu, then Spark scheduled every 10 minutes or 1 hour on Kudu tables. Issues: latency remained 10 minutes to 1 hour (batch scheduling, not true streaming); ODS data stored twice in Hive and Kudu, hurting reuse; Kudu SSD-based, high cost and operational difficulty. Kernel reason: Kudu is a separate storage system, not unified with the lake; "real-time" relied on frequent batch scheduling — expensive and with a latency floor.

Stage 2: Flink + Apache Hudi (2022)

Adopted Hudi for real-time upsert on ODS tables and downstream reuse, plus streaming reads. New problems emerged: a single Hudi table over 10 GB took 10+ hours to sync; larger tables consumed more resources; data consistency hard to guarantee; query efficiency below expectations. Kernel reason (linking to internal article 10): Hudi was designed for Spark upsert; its file organization and merge model lean batch-oriented. Under continuous streaming updates and large tables, write and merge overhead scales with data volume.

Stage 3: Flink + Apache Paimon (mid-2023 onward)

Tongcheng adopted Paimon to solve Hudi's issues, building end-to-end real-time processing. Per their sharing, Paimon guarantees eventual data consistency, compatibility with multiple table formats, and primary-key updates. Kernel reason: Paimon combines LSM-Tree with lake format (detailed in article 10) — writes go to memory first, flush to L0, background compaction — natively designed for streaming updates, hence smoother on large-table real-time writes and streaming reads. This is not "Paimon code is faster" but a storage-model-to-scenario fit.

4.2 Trip.com Artnova: From "Lake + Trino + Warehouse Replicas" to "StarRocks Unified Lake Query"

Per StarRocks official case study, Artnova serves hotel, flight, corporate travel, packages, marketing, and other business units.

Old Architecture

Hive data lake + Trino query. Large data volumes with low-latency high-concurrency requirements exceeded Trino's capability. Team copied/imported data into StarRocks (then used as high-performance warehouse) for acceleration. This introduced three problems: data freshness degraded (extra import step); maintaining import jobs, schemas, and indexes became complex; copying data to a dedicated warehouse was both complex and costly, so only the most critical workloads were moved.

New Architecture

Key shift: StarRocks not only persists data as a warehouse but also queries the data lake at warehouse-grade performance . Team removed Trino, made StarRocks the unified query engine, accessing data via unified Catalog (Hive Catalog + StarRocks Catalog). Slow queries accelerated via materialized views : external MVs and nested MVs for pre-computation (denormalization, pre-aggregation), with StarRocks automatic query rewrite — user SQL unchanged, optimizer auto-hits the best MV. Default queries hit raw lake data directly; pre-computation only on demand.

Kernel reason (linking to article 12): StarRocks' vectorized execution + CBO makes direct lake query fast; MV auto-rewrite transforms "pre-copy data to warehouse" into "on-demand pre-compute on lake," enabling removal of warehouse replicas.

Core Pipelines and Key Processes

Tongcheng's Migration Pipeline (Storage Format Migration)

After selecting Paimon, real-time jobs migrated from Hudi incrementally — per their sharing, ~80% of jobs (500+ jobs) migrated, building 10+ end-to-end real-time scenarios and 10+ batch scenarios using lookup engine. Paimon stores ~100 TB data, ~100 billion records. Migration was not a big-bang cutover but scene-by-scene replacement with consistency verification.

Trip.com's Query Pipeline (Query Engine Unification)

User query enters StarRocks → optimizer locates lake data via Hive Catalog; direct query where possible (predicate pushdown, partition pruning); slow queries served by external/nested MV pre-computation, auto-rewritten at query time → results returned. Underlying Hive data keeps MVs in sync via refresh. This pipeline replaces the "pre-import to warehouse" step with "query-time direct lake access + on-demand MV."

Real Business Scenarios and Engineering Practices

The most transferable aspects are their methodologies , not specific parameters.

Transferable Practice 1: Storage Format Migration via "Scene-Based Canary, Dual-Run Verification"

Tongcheng did not switch all at once. They first validated Paimon in end-to-end real-time scenes, then gradually replaced Hudi jobs. Landing approach: pick 1-2 most painful large tables/real-time scenes for pilot; dual-run old and new pipelines with reconciliation (row counts, primary keys, aggregation results consistent); verify compaction keeps up and streaming reads stable; then roll out in batches. Aligns with canary (article 13) and stress testing (article 14) methodologies.

Transferable Practice 2: Direct Lake Query with "Default Raw, On-Demand MV"

Trip.com's experience: don't pre-build acceleration tables for every report. Let queries default to direct lake query; build few MVs only for true slow queries (case used only 4 on-demand MVs to resolve all slow queries). Landing: first connect lake via Catalog, test direct query performance; then build MVs per slow query, rely on auto-rewrite to hit them; avoid falling back into "maintaining a pile of pre-computed tables."

Transferable Practice 3: Real-Time SLA Tiered by Business

Both cases confirm articles 9 and 14 — not all reports need second-level latency; minute-level (typical for Paimon streaming lake storage) satisfies most operational analytics; only true second-level scenarios warrant heavier real-time solutions. Tiering SLA by business significantly reduces cost.

Performance, Cost, and Technology Selection

Mechanism-determined (directional conclusions from design choices): Paimon's LSM model is inherently smoother than batch-designed formats for "streaming primary-key updates, streaming incremental reads"; StarRocks direct lake query + MV inherently avoids one import step and yields fresher data than "copy to warehouse."

Project-side self-reported (single-party data, reference only): Per Tongcheng public sharing: ODS sync resource down ~30%, write speed up ~3x, some query efficiency up ~7x, tag-based feature cuts data export storage ~40%, metric development efficiency up ~50%. Per StarRocks case: same data and production queries, StarRocks ~7.4x faster than Trino; overall (with MV acceleration) ~10x+ improvement. These numbers are highly dependent on data distribution, hardware, query templates, and versions; they are "project claims" and cannot be your expected values — must stress-test in your own environment.

Selection Conclusion: Pain point "slow real-time write/update, large-table sync drains resources" → evaluate Paimon-class LSM lake formats. Pain point "slow lake query, forced to copy data to warehouse" → evaluate unified query engines capable of direct lake query + auto MV. The two often combine — Tongcheng's upper layer also uses StarRocks, exactly the "storage on Paimon, query on StarRocks" combo.

Production Issues and Troubleshooting Methods

Issue 1: Large-Table Compaction/Sync Still Lags After Migration

Symptom: Format changed, but files still pile up at peak. Following "symptom → metrics → principle → locate → fix": check if write speed exceeds merge speed (resource shortage) or trigger thresholds misconfigured; per articles 10 and 14, give compaction dedicated resources, size compute per stress-test peak load.

Prevention: During migration stress test, use "file count convergence under sustained load" as acceptance criterion, not just instantaneous throughput.

Issue 2: Unstable Direct Lake Query Performance

Symptom: Same query sometimes fast, sometimes slow. Root causes often: stale statistics causing CBO to pick wrong plan, or MV not refreshed/not hit.

Locate: EXPLAIN to see if MV used, partition pruning effective.

Fix: Refresh statistics and MVs; add MVs if needed. Prevention: Include statistics and MV refresh in scheduling.

Issue 3: Data Mismatch During Dual-Run Period

Symptom: Old and new pipeline results diverge. Possible causes: migration boundary misalignment, Changelog mode differences, late-data handling differences.

Locate: Reconcile segment by segment on primary key and time window to find divergence point.

Fix: Align semantics before cutover. Prevention: Dual-run must cover at least one full business cycle (including tidal peaks).

Advanced Interview and Architecture Thinking

Q1: Why did Tongcheng migrate from Hudi to Paimon? Explain the mechanism.

Key points: Hudi designed for Spark upsert, batch-leaning; large tables (>10 GB) streaming sync time scales with data volume. Paimon fuses LSM with lake format — writes to memory, background compaction — natively fits continuous streaming updates. It's a model-fit problem.

Q2: Why could Trip.com "throw away the warehouse"?

Key points: StarRocks achieves warehouse-grade performance directly querying Hive lake; combined with external/nested MV auto-rewrite for on-demand pre-computation, it replaces "copy data to warehouse" — one less import, fresher data, less maintenance.

Q3: Can migration gains (3x/7x/10x) be written into proposals?

Key points: Cannot be commitments. They are project-side self-reports, environment-sensitive; only usable as "some team achieved this magnitude" reference. Proposals must state "subject to own stress test."

Q4: Given a multi-line, tidal-heavy travel platform, how would you plan the lakehouse?

Key points: Unify storage to open lake format; query with direct-lake-capable engine + on-demand MV; tier real-time SLA by business; migrate via canary dual-run — exactly the combination of both cases in this article.

Summary, Knowledge Extraction, and Next Episode

This article uses two online travel cases to dissect the two most common real-time lakehouse migrations:

Tongcheng on the write side replaces Hudi with Paimon , leveraging LSM model to solve large-table real-time sync slowness.

Trip.com on the query side uses StarRocks to unify lake query , leveraging direct query + materialized views to replace warehouse replicas.

We've seen the kernel reasons behind three-stage evolution, mastered storage-format migration and query-engine unification methodologies, and strictly separated mechanism conclusions from project-side self-reported numbers.

One-sentence conclusion: Lakehouse migration essence is making "storage model match real-time writes, query model match direct lake query" — direction decided by mechanism, benefit numbers only for reference, must self-test.

Next episode (Article 18, Industry Deep-Dive Case 02) enters Finance & Risk Control : dissecting Didi's real-time risk control engineering on StarRocks (StarRocks official blog) and Ant Group's Paimon unified storage replacing HBase/ES, focusing on finance's hard constraints for consistency, permissions, audit, and how they land in lakehouse.