TL;DR: Tuhu Car, a leading auto care company in Asia, rebuilt its OLAP architecture with Apache Doris after years of running Hive, HBase, MySQL, and Trino side by side. The results were concrete: audience segmentation queries improved 20x, from more than 60 seconds to under 3 seconds; single-user profile lookups stabilized around 10 ms; data freshness moved from T+1 to minute-level updates; and BI P90 latency dropped from 52 seconds to 7 seconds.
Founded in 2011, Tuhu Car is publicly traded on the Hong Kong Stock Exchange (9690.HK) and serves 126 million car owners through an online-to-offline business model: car owners book services online, then visit Tuhu workshops or partner stores for maintenance, tire replacement, repairs, detailing, and other automotive aftersales services.
At that scale, Tuhu needed one view across user behavior, transactions, store fulfillment, inventory, logistics, and marketing. But Tuhu faced a familiar problem: a fragmented data stack. In that stack, MySQL handled dimension and report data, Hive handled batch processing, HBase handled real-time random reads, and Trino handled ad hoc analysis.
That setup worked for separate workloads, but cross-domain analysis became expensive. The same data moved through long pipelines, existed in multiple copies, and often needed reconciliation before teams could trust the numbers.
Tuhu rebuilt this architecture with Apache Doris, unifying data ingestion, storage, compute, and SQL access in one system. The team started with the user tagging system, then expanded to multidimensional BI analysis. Here is how the migration unfolded.
Challenge: A Fragmented Stack with Hive + HBase + MySQL + Trino
Tuhu's OLAP platform evolved through four stages:
| Stage | Timeline | Architecture | Problems |
|---|---|---|---|
| Early stage: fast response | 2018 to 2019 | Siloed development. Teams commonly used MySQL for transactions and ran reports directly on it, effectively using OLTP as OLAP. | Data volume approached MySQL's single-table limits. Complex reports often dragged down business clusters and created serious data silos. |
| Growth stage: early consolidation | 2019 to 2022 | Hybrid architecture. Tuhu adopted the Hadoop ecosystem, introduced Hive for the T+1 batch data warehouse, and added HBase for real-time random reads and writes. | The architecture became highly complex. The team had to maintain multiple stacks, and HBase could not efficiently support broad multidimensional analysis. |
| Bottleneck stage: looking for other options | 2022 to 2023 | Attempting federated query. The team introduced Trino for cross-source queries, trying to query all data with one SQL interface. | Compute-storage separation created network transfer bottlenecks. Slow queries and weak concurrency became frequent issues, and local optimizations could not solve the root problem. |
| Exploration stage: unified foundation | 2023 to present | The team stopped adding more individual components and chose Apache Doris as the unified foundation for real-time analytics and computation. | Tuhu reduced several multi-component bottlenecks and built a unified foundation for real-time analytics. |
The old architecture reflected how the platform had grown. Raw logs lived in HDFS, processed tables lived in Hive, dimension tables lived in MySQL, and real-time data lived in HBase.
A single dataset often moved through several systems. Data first entered Hive for batch processing. The team then loaded some results into HBase for real-time queries, synchronized others back into MySQL, and prepared another copy for ad hoc analysis through Trino (Presto).
These handoffs created three practical problems:
-
Bloated stack: The team had to maintain Hive, HBase, MySQL, Trino, and other components at the same time.
-
Inconsistent metrics: Multiple copies of the same data lived in different systems. Long pipelines made metric mismatches more likely and weakened trust in the data.
-
High development cost: When the business needed both multidimensional analysis and high-concurrency point lookups, engineers had to build synchronization pipelines across systems before they could even start on the query logic.
Why Tuhu Needed a Unified OLAP Foundation
As Tuhu's business scaled, the data platform had to connect online booking, offline fulfillment, inventory, logistics, and marketing. The hard part was serving these workflows together. Every cross-domain query depended on extra synchronization and reconciliation, making it harder to deliver fresh data, consistent metrics, and fast analysis all at once.
The pressure showed up in three places:
-
Full-channel user view: User behavior, transactions, and store fulfillment data lived in separate systems. That made it harder to build one user view for profiling, targeting, and business analysis.
-
Supply chain freshness: Auto care involves many SKUs, warehouses, stores, and logistics nodes. Teams needed timely analysis of inventory changes, fulfillment progress, and regional supply-demand patterns to support replenishment and inventory alerts.
-
Mixed read and write pressure: Appointments, payments, inventory updates, and marketing events kept generating new data, while teams still needed fast queries for user tags, audience segmentation, dashboards, and ad hoc BI analysis.
Tuhu needed one OLAP foundation for high-throughput ingestion, consistent metrics, high concurrency, and low-latency analytics.
Why Tuhu Chose Apache Doris
To fix these problems at the root, Tuhu decided to rebuild the fragmented stack around one OLAP engine. After research and validation, the team chose Apache Doris and gradually moved analytical workloads out of the old multi-system architecture.
Four capabilities mattered most:
-
Query and storage in one system: Apache Doris uses an MPP distributed architecture and columnar storage, so it can support both large-scale detail analysis and high-concurrency, low-latency queries. Teams could query audience segments, user profiles, and business metrics through standard SQL without moving between systems.
-
Real-time ingestion: Apache Doris supports CDC and streaming ingestion through Stream Load, Routine Load, and Apache Flink CDC. Tuhu used these capabilities to write user behavior, orders, inventory, and other data into the OLAP platform in real time, meeting minute-level and even second-level freshness requirements.
-
Lower migration cost: Apache Doris is compatible with the MySQL protocol and supports standard SQL, so existing reports, analysis tools, and data development workflows could move over with less rework.
-
Simpler operations: Apache Doris mainly consists of FE and BE nodes. With one storage layer, one compute engine, and one SQL interface, the team reduced cross-system synchronization and made troubleshooting easier.
Tuhu first validated Apache Doris in the user tagging system. After that deployment stabilized, the team expanded it to BI reporting, multidimensional analysis, and real-time data applications.
Rebuilding the User Profiling System with Apache Doris
The team chose the user tagging system (user profiling) as its first Apache Doris scenario because the workload covered a broad range of read and write patterns: high-concurrency point lookups for single-user tags, flexible multidimensional audience segmentation, and real-time freshness requirements.
Limitations of the Old Architecture
Under the old architecture, one audience segmentation or profile query could touch three different systems. Each system handled part of the workload, but the handoffs created performance and development problems:
-
MySQL struggled with large-scale point lookups: MySQL handled single-user tag queries. After data volume reached hundreds of millions of rows, latency rose under high-concurrency point lookups. Slow SQL could also affect the stability of the transaction database.
-
HBase struggled with complex audience segmentation: HBase worked well for key-based queries, but flexible multidimensional filtering was a poor fit. For example, finding car owners in a specific city with vehicles older than five years who had bought tires required engineers to write custom logic instead of using simple analytical queries.
-
Hive and Trino were too slow for interactive analysis: When analysts needed to explore a selected audience group, the batch analysis path usually took minutes.
The Unified Apache Doris Architecture
The new architecture pulled the data sources and compute paths into Apache Doris. Instead of routing point lookups, audience segmentation, and ad hoc analysis through separate systems, Tuhu served them through one SQL engine.
The rebuild had three parts:
-
The team used Broker Load for batch data import and Stream Load for real-time ingestion.
-
For profile point lookups, the team used the Duplicate Key model and prefix indexes to reach millisecond-level response.
-
For audience segmentation, the team used the Aggregate Key model and pre-aggregated common dimensions, improving query speed more than tenfold over the old architecture.
At the service layer, the team built one data application interface. Profile lookup, audience segmentation, and ad hoc analysis requests all went to Apache Doris through standard SQL.
Results
-
Performance: Core audience segmentation queries improved 20x, from more than 60 seconds to under 3 seconds. Single-user profile lookup latency stayed around 10 ms. Data updates moved from T+1 to minute-level processing.
-
Operations: The team removed several cross-system transfer and version synchronization chains, which simplified cluster operations.
-
Business value: Faster audience segmentation also improved marketing execution. Tuhu reported about a 15% increase in marketing conversion rate.
Note: These metrics come from production statistics for core query scenarios. Actual results may vary based on data scale, query complexity, and cluster configuration.
Migrating Multidimensional BI Analysis from Trino to Apache Doris
After the user tagging system went live, the team applied the same approach to larger-scale multidimensional BI analysis, gradually migrating the old HDFS + Trino architecture to Apache Doris.
The old HDFS + Trino setup hit network bandwidth bottlenecks under high-throughput multidimensional analysis. With Apache Doris, Tuhu moved computation closer to the storage nodes and reduced large-scale network data transfer.
The team used Broker Load to synchronize historical Hive data and migrated query access to Apache Doris through a unified SQL gateway.
After the migration, P90 query latency dropped from 52 seconds to 7 seconds, an 86% reduction. Overall performance improved by around 7x.
Both the user tagging system and the BI analysis system now run stably in production. The team is also upgrading its real-time data warehouse and dashboards as it expands real-time analytics to more business units.
Future Plans: From Unified OLAP to Intelligent Data Infrastructure
With the core migration complete, Tuhu plans to keep improving the platform in three areas: lakehouse architecture, semantic interaction, and automated operations. The goal is to move beyond query acceleration and build a data platform that can support more real-time and AI-driven workloads.
-
Lakehouse architecture: The team plans to integrate more deeply with open-source lakehouse formats such as Apache Hudi and Apache Iceberg. Object storage can lower the cost of historical cold data, while Apache Doris can serve high-concurrency ad hoc analysis on hot data and support automatic hot/cold tiering.
-
Semantic interaction for business users: The team plans to combine Text-to-SQL with vector search to build an LLM-powered chat engine. With a business semantic layer, non-technical users can explore data and analyze metric changes in natural language.
-
Automated platform operations (AIOps): The team plans to turn operational experience into platform features, including predictive resource scaling, automatic throttling for slow queries, and automatic materialized view creation.
If your team is dealing with a fragmented stack built around Hive, HBase, MySQL, Trino, ClickHouse, Elasticsearch, or other systems, Tuhu's case shows what a unified OLAP architecture can change: fewer data copies, simpler pipelines, fresher analytics, and faster queries across core business workloads.
Join the Apache Doris community on Slack and connect with other Doris experts and users. If you're looking for a fully managed Apache Doris cloud service, contact the VeloDB team.
