途虎养车基于 Apache Doris 构建统一 OLAP 数据底座，支撑用户画像与 BI 多维分析

导读 ：本文系统阐述了途虎养车在大数据 OLAP 领域的架构演进路径。针对历史架构中多套技术栈并存导致的数据孤岛、多系统接力及运维成本高等痛点，团队以用户标签系统为突破口，推行以 Apache Doris " 为核心的统一数据底座建设，逐步实现点查、圈选、BI 报表、即席分析统一承载，实现核心查询场景提速约 20 倍。 本文整理自途虎养车 数据平台开发工程师 王文博 在 Doris Summit 2025 中的演讲。 为什么需要统一 OLAP 数据底座？ 途虎养车的核心业务模式是“线上预约 + 线下履约”，用户通过 APP、小程序、官网等线上渠道完成选购、预约和支付，并在线下工场店及合作门店完成安装、保养、美容等服务。目前，平台已服务超过 1.26 亿车主，业务覆盖轮胎、机油保养、汽车美容等多类汽车产品与服务。 随着业务规模持续扩大，平台每天都会产生大量用户行为、订单交易、门店履约、仓储物流和库存变更数据。这些数据来源分散、链路较长，同时对实时性和分析效率要求较高，给 OLAP 平台带来了三方面挑战： 全渠道数据打通难。 线上多入口与线下门店系统共同构成完整服务链路，数据分散在不同系统中。平台需要将用户行为、交易和履约数据统一到同一用户视图下，支撑用户画像、精准营销和经营分析。供应链分析实时性要求高。 汽车服务业务涉及大量 SKU、仓库、门店和物流节点，库存变化、履约进度和区域供需情况都需要及时分析，以支撑补货决策、库存预警和履约效率优化。高并发查询与写入压力大。 用户预约、订单支付、库存扣减、营销触达等环节会持续产生高频数据流。在促销活动或业务高峰期，平台既要保障数据及时入仓，也要支撑用户标签、人群圈选、经营看板和即席分析等低延迟查询需求。 因此，途虎养车 OLAP 平台需要同时具备高吞吐写入、低延迟查询、统一数据口径和高并发服务能力，主要支撑精准营销、BI 固定报表、实时数据大屏和 BI 多维分析四类核心场景。 原有 Hive + HBase + MySQL + Trino 架构遇到哪些问题？ 途虎养车 OLAP 平台的演进历程，主要经历了四个关键阶段： 在老架构（早期阶段）下，由于业务部门的烟囱式发展，技术栈呈现出不断叠加、分层和碎片化的特征。当时数据分散于多个异构系统中：原始日志在 HDFS、加工表在 Hive、维表在 MySQL、实时数据在 HBase。 从数据加工的全局流程看，一份数据产生后需复制多份，在多条流水线上传递：先进入 Hive 离线加工，一部分结果导入 HBase 供实时查询，另一部分数据又同步回 MySQL，最后还要为 Trino（Presto） 的即席分析做准备。 这种多系统接力模式带来了以下技术瓶颈： 技术栈臃肿：团队需同时维护 Hive、HBase、MySQL、Trino 等多个组件，运维成本高。数据一致性难以保障：数据在不同系统中存在多份副本，数据链路长，极易造成数据口径不一致，引发数据信任危机。开发效率低：业务侧提一个既要多维分析又要高并发点查的需求，开发同学需要在多个异构系统间编写数据同步链路，难以快速响应业务。 为什么选择 Apache Doris？ 因此，团队开始推动 OLAP 架构向统一数据底座演进，希望用一套更简洁的架构同时承载离线分析、实时写入、高并发查询和多维分析等核心场景。经过调研和验证，团队最终选择 Apache Doris 作为统一 OLAP 引擎，逐步替代原先分散在多套系统中的分析能力。 Apache Doris 能够支撑这一演进，主要基于以下几方面能力： 第一，统一的查询与存储能力 。Doris 采用 MPP 分布式架构和列式存储，能够同时支持大规模明细数据分析和高并发低延迟查询。对于用户圈选、画像查询、经营分析等场景，业务可以直接通过标准 SQL 访问统一数据源，减少在不同系统之间切换和同步的成本。 第二，完善的实时数据接入能力 。Doris 支持 Stream Load、Routine Load、Flink CDC 等多种实时或准实时导入方式，可以将用户行为、订单、库存等数据及时写入 OLAP 平台，满足业务对分钟级甚至秒级数据时效的要求。 第三，较低的迁移和使用成本 。Doris 兼容 MySQL 协议，并支持标准 SQL，原有报表、分析工具和数据开发流程可以较平滑地迁移到新架构中，降低了数据开发、分析人员和业务系统的改造成本。 第四，更简洁的系统架构。 相比多套组件接力的模式，Doris 主要由 FE 和 BE 节点组成，整体架构更清晰。通过统一存储、统一计算和统一 SQL 接口，团队减少了跨系统数据同步链路，也降低了后续运维和问题排查复杂度。 基于这些能力，途虎养车将 Doris 作为新一代 OLAP 统一数据底座，优先在用户标签系统中落地验证，并在验证效果稳定后，进一步扩展到 BI 报表、多维分析和实时数据应用等场景。 用户画像系统如何基于 Doris 重构？ 面对复杂的旧系统，团队选择从用户标签系统（用户画像）切入，作为 Doris 的首个落地项目。该场景对数据读写覆盖全面：既需要高并发点查（获取单用户标签），又需支持灵活的多维圈选，且对实时性有一定要求。 原有架构运行时的局限性 在旧架构下，一个完整的人群圈选与画像查询需求，被拆分为三套异构系统的接力，存在明显的性能与开发痛点： MySQL 难以支撑海量点查：查询单个用户标签时请求打到 MySQL。当数据量突破亿级后，其在高并发点查下的延迟明显上升，且易因慢 SQL 影响业务库的稳定性。HBase 不擅长复杂圈选：进行复杂多维筛选时（例如：筛选出“深圳地区、车龄 > 5 年、购买过轮胎”的车主），HBase 只擅长按 Key 查询，灵活的多维筛选需开发同学编写大量代码模拟，开发效率极低。Hive与 Trino 响应时滞长：对圈出的人群进行深入多维探索时，离线分析方案耗时通常在分钟级，无法支持交互式分析。 基于 Doris 的一体化架构设计 新架构的核心演进方向是收拢数据源与计算引擎，用一个 Apache Doris 系统承接原先三套系统的所有场景，在计算层面推行“统一数据源、统一计算引擎、统一 SQL 语言”的一体化策略。 重构具体路径： 统一数据导入： 通过 Broker Load 进行离线批数据导入，通过 Stream Load 进行实时数据接入，从入口端解决数据分散问题。针对不同查询场景配置差异化表模型：画像点查场景：采用 Duplicate 明细模型，利用前缀索引实现毫秒级响应。人群圈选场景：采用 Aggregate 聚合模型，对常用维度进行预聚合，查询速度较老架构提升数十倍。统一对外服务接口： 顶层构建统一数据应用服务，无论是画像点查、人群圈选还是复杂即席分析，后端统一走标准 SQL 路由至 Doris 响应，架构大幅简化。 重构收益 性能优化：核心人群圈选查询由原先超过 60 秒缩短至 3 秒以内；单用户画像点查延迟控制在 10 毫秒左右；数据更新由 T+1 升级为分钟级实时处理。运维降本：减少了异构组件间的数据传输和版本同步链条，降低了分布式集群的整体运维复杂度。业务价值：数据平台由成本中心转变为业务增长引擎，营销转化率提升约 15%，显著提升整体