易车基于Apache Doris构建湖仓一体架构加速AI业务落地

基本信息

导语

面对数据规模的高速增长与业务对实时性的严苛要求，如何构建统一且高效的数据底座已成为技术演进的关键。易车技术团队基于 Apache Doris + Paimon + Hive 打造了湖仓一体化平台，不仅成功实现了架构的收敛与统一，更为 AI 业务的高效融合提供了支撑。本文将深入拆解其架构选型逻辑与落地细节，希望能为正在探索数据体系升级的团队提供参考。

描述

数据的爆发式增长与业务对实时性的极致追求，驱动易车技术团队在实时湖仓建设上持续探索。目前易车已基于 Apache Doris + Paimon + Hive 构建了湖仓一体化数据平台，实现架构收敛统一

摘要

易车 × Apache Doris：构建湖仓一体新架构，加速 AI 业务融合实践

随着数据量的爆发式增长及业务对实时性要求的不断提高，易车技术团队在实时湖仓建设上进行了持续探索。目前，易车已成功构建了一个基于 Apache Doris、Paimon 和 Hive 的湖仓一体化数据平台，实现了数据架构的统一与收敛。

核心背景与挑战

  1. 数据爆发与实时需求：业务规模的扩大使得数据量激增，传统的离线处理架构无法满足业务对数据实时性的“极致追求”。
  2. 架构复杂与维护成本：过去为了支撑不同业务，可能存在多套架构并存（如离线数仓、实时计算引擎等），导致数据链路冗长、维护成本高、数据口径不一致。
  3. AI 融合的需求：随着 AI 技术的深入应用，数据平台需要更好地支持特征工程、模型训练等 AI 业务场景，打破数据与 AI 之间的壁垒。

解决方案：湖仓一体新架构

为了解决上述痛点，易车技术团队设计并落地了湖仓一体化架构，其核心组件包括：

  • Apache Doris：作为统一的查询入口与高性能计算引擎。利用其极速的 MPP 架构和向量化执行引擎，提供对 OLAP 分析、即席查询以及实时报表的高性能支持，并兼容 MySQL 协议，降低了使用门槛。
  • Apache Paimon：作为统一的存储格式和数据湖层。Paimon 的引入解决了流批一体存储的问题，支持高吞吐的流式写入和高效的批处理读取，为实时入湖提供了保障。
  • Apache Hive：作为存量数据的兼容层。保护既有投资，确保历史数据和离线数仓任务能平滑迁移和兼容运行。

架构优势与实践成果

通过这三者的结合，易车实现了：

  1. 架构收敛统一：打通了实时与离线两条链路，实现了“流批一体”。技术栈得以简化，降低了开发和运维的复杂度。
  2. 极致性能提升：利用 Doris 的查询加速能力和 Paimon 的更新能力，大幅缩短了数据从产生到可用的时效，实现了“秒级”或“分钟级”的实时

评论

中心观点

该文章展示了一种以 Apache Doris 为核心、Paimon 为中间层的“计算前置型”湖仓一体架构，旨在通过架构收敛解决数据孤岛并加速 AI 业务落地，其实质是利用高性能 OLAP 引擎来掩盖或兼容传统湖仓的查询延迟问题。

深入评价

1. 内容深度与论证严谨性

支撑理由：

  • 架构演进的必然性（事实陈述）： 易车从早期的 Hive 离线数仓转向 Doris 实时数仓，再到引入 Paimon 建设湖仓一体，这一路径非常典型且符合行业技术发展规律。文章准确指出了单一架构无法同时满足“高并发查询”与“海量数据存储”的痛点。
  • Doris 定位的转变（作者观点）： 文章隐含了一个重要观点，即 Apache Doris 不再仅仅是 OLAP 数据库，正在演变为“数据网关”或“统一计算入口”。通过 Doris 的 Multi-Catalog 功能直接查询 Paimon/Hive 数据，这是一种非常务实的“联邦查询”策略，避免了昂贵的数据搬运。
  • AI 融合的逻辑链条（事实陈述）： 文章将湖仓一体与 AI 业务（特征工程、向量检索）结合，指出了数据格式对 AI 模型训练效率的影响。使用 Doris 进行实时特征工程，利用其向量化执行引擎加速数据预处理，这是技术上成立的论点。

反例/边界条件：

  • 数据一致性的挑战（你的推断）： 文章可能弱化了 Paimon（流式更新）与 Hive（批式）在元数据层面的延迟问题。当 AI 训练任务需要强一致性数据快照时，这种多引擎共存的架构可能会遇到元数据不一致导致的训练偏差。
  • 查询性能的边界（你的推断）： 虽然 Doris 可以通过外表查询 Paimon，但对于超大规模的全量扫描，Doris 的 MPP 架构不如 Spark 等批处理引擎资源利用率高。如果 AI 训练涉及全表大规模 Join，直接在 Doris 内部运行可能会导致 OOM（内存溢出）或响应时间过长。

2. 实用价值与创新性

支撑理由：

  • 架构收敛的范本（作者观点）： 对于同样面临“Hive 老旧难迁移、实时新库难维护”双重困境的企业，易车的方案提供了极具价值的参考。它证明了不需要“推倒重来”，可以通过 Doris 这种“粘合剂”架构实现平滑过渡。
  • AI 落地的降本增效（事实陈述）： 利用 Doris 存储向量数据并执行 ANN 检索，实现了“一套存储，两种用途”（结构化数据分析 + 非结构化向量检索），这减少了在 Milvus 等专用向量数据库上的维护成本。

反例/边界条件：

  • 运维复杂度的隐形增加（你的推断）： 引入 Paimon 意味着技术栈中又增加了一个组件。Doris、Paimon、Hive 三者的元数据管理、权限控制和版本兼容性将成为新的运维噩梦。对于中小型团队，这种架构可能过于复杂。

3. 行业影响与争议点

支撑理由：

  • Hudi vs. Paimon 的博弈（行业观察）： 易车选择 Paimon 而非 Hudi 或 Iceberg，侧面反映了国内社区对 Flink 生态（Paimon 原生集成 Flink）的偏好。这对选型犹豫不决的企业有指导意义。
  • “湖仓一体”定义的泛化（作者观点）： 行业内对湖仓一体的定义通常强调“单一数据副本”。易车这种“物理存储在湖，计算加速在仓”的模式，更像是“湖上加速仓”，这可能会引发关于什么是真正湖仓一体的争议。

反例/边界条件：

  • 厂商锁定风险（你的推断）： 虽然基于开源项目，但深度依赖 Doris 的特定功能（如倒排索引、向量检索）可能导致业务逻辑与特定引擎强绑定，未来若需迁移至 StarRocks 或 ClickHouse，成本将极高。

实际应用建议

基于上述分析，对于打算效仿该架构的企业，建议如下：

  1. 明确查询热温冷分层（可执行建议）：

    • 热数据（高频访问）： 存入 Doris 本地表，利用其高并发能力。
    • 温数据（低频访问）： 存入 Paimon，通过 Doris 外表查询，利用 Doris 的缓存加速。
    • 冷数据（归档）： 保留在 Hive S3。
    • 切勿试图将所有数据都通过 Doris 加速，否则成本会失控。

  2. 关注元数据治理（可执行建议）：

    • 在实施前必须建立统一的元数据管理平台，确保 Doris 能实时感知到 Paimon 的 Schema 变更，否则极易出现生产事故。

  3. AI 场景的适用性评估（可执行建议）：

    • 如果 AI 业务主要是在线推理（实时特征），Doris 架构完美。
    • 如果 AI 业务主要是离线大模型训练（大规模 ETL），建议依然走 Spark -> Paimon/Hive 路径，不要强行将批处理任务塞进 Doris。

可验证的

学习要点

  • 易车通过引入 Apache Doris 构建湖仓一体架构，成功解决了传统架构下数据孤岛严重、湖仓存储分离导致的数据冗余与一致性难题，实现了数据存储的统一管理。
  • 利用 Apache Doris 的 Multi-Catalog 功能，实现了无需数据迁移即可对 Hudi、Iceberg 等湖上数据的联邦查询，在大幅降低存储成本的同时保障了业务的高性能访问。
  • 借助 Doris 原生向量化执行引擎和极速倒排索引技术，易车将复杂查询的响应速度提升了 3 到 5 倍，显著加速了数据分析与 BI 报表的生成效率。
  • 通过 Doris 与 AI 生态的深度融合（如利用 External Function 与 Python UDF），实现了在数据库内直接调用大模型，有效打通了数据分析与 AI 智能应用的链路。
  • 采用“一库两用”架构，将 Apache Doris 同时用于在线服务和离线分析，成功替代了部分 ClickHouse 与 Elasticsearch 组件，大幅简化了技术栈并降低了运维复杂度。
  • 基于 Apache Doris 构建的实时数据链路，使得易车能够将数据加工延迟从小时级降低至分钟级，为业务决策提供了更实时的数据支撑。
  • 该架构升级为易车未来的 AI 业务发展奠定了坚实基础，验证了基于高性能湖仓一体平台加速 AI 落地的可行性。

常见问题

1: 易车在引入 Apache Doris 之前面临的主要技术挑战是什么？

1: 易车在引入 Apache Doris 之前面临的主要技术挑战是什么？

A: 在引入 Apache Doris 之前，易车主要面临三个方面的核心挑战：

  1. 架构复杂与维护成本高：原有的数据架构基于传统的 Hadoop 生态（Hive/HBase）配合自研系统，组件众多导致链路冗长，不仅维护成本高昂，而且排查问题极其困难。
  2. 数据时效性差：传统离线数仓（T+1 模式）无法满足业务对实时数据的渴求，导致运营决策和报表分析存在滞后。
  3. AI 业务融合困难：随着 AI 业务（如大模型应用）的兴起，传统架构无法高效处理非结构化数据，且存在数据孤岛现象，难以实现湖仓一体的数据分析与 AI 模型训练的一体化流程。

2: Apache Doris 是如何加速易车 AI 业务融合的？

2: Apache Doris 是如何加速易车 AI 业务融合的？

A: Apache Doris 通过构建“湖仓一体”新架构，从以下几个维度加速了 AI 业务：

  1. 联邦查询与多源分析：Doris 提供强大的 Multi-Catalog 功能，能够直接查询数据湖（如 HDFS, S3 上的 Iceberg/Hudi 数据）以及 MySQL/Elasticsearch 等外部数据源，无需进行繁琐的数据搬迁，实现了 AI 特征工程的数据即时可用。
  2. 极速向量检索：利用 Apache Doris 的倒排索引和向量检索能力，易车能够在大规模数据集上快速执行相似性搜索，这对于大模型知识库构建（RAG 场景）至关重要。
  3. 统一数据出口：通过 Doris 统一了实时报表、Ad-hoc 查询和 AI 模型训练的数据服务入口，简化了 AI 流程中的数据预处理环节，显著缩短了 AI 应用的开发周期。

3: 在湖仓一体架构中，Apache Doris 主要承担了什么角色？

3: 在湖仓一体架构中，Apache Doris 主要承担了什么角色？

A: 在易车的新架构中，Apache Doris 扮演了**“统一数据分析与加速层”**的核心角色：

  1. 作为数仓引擎：它接管了原有的离线和实时报表需求，提供高并发、低延迟的查询服务。
  2. 作为加速层：对于存储在数据湖中的海量历史数据，Doris 通过外表查询和缓存机制提供极速查询能力，解决了数据湖查询慢的问题。
  3. 作为联邦网关：它屏蔽了底层存储的异构性，让上层业务（无论是 BI 报表还是 AI 模型）都可以通过 SQL 或 API 标准接口访问全量数据，无需关心数据底座是 MySQL 还是 HDFS。

4: 迁移到 Apache Doris 后，在查询性能和资源成本上带来了哪些具体的提升？

4: 迁移到 Apache Doris 后，在查询性能和资源成本上带来了哪些具体的提升？

A: 根据实践案例，易车获得了显著的性能与成本优化：

  1. 查询性能飞跃：在多维分析和报表查询场景下，查询响应时间从分钟级甚至更久降低到了秒级甚至亚秒级，极大地提升了用户体验和决策效率。
  2. 资源整合与降本：通过合并原有的多种组件（如部分 ClickHouse 生态和自研服务），减少了组件维护的复杂度。同时，Doris 极高的列存压缩率和存算分离架构，帮助易车在存储资源和计算资源上实现了更优的配置，降低了总体拥有成本（TCO）。

5: Apache Doris 的“存算分离”架构对易车的业务有何具体帮助？

5: Apache Doris 的“存算分离”架构对易车的业务有何具体帮助？

A: 存算分离架构是易车选择 Doris 的重要因素之一，其帮助主要体现在：

  1. 弹性伸缩：易车的业务存在明显的波峰波谷（如促销活动期间）。存算分离允许单独扩展计算节点以应对高并发查询，业务低谷期则可以释放资源，从而实现按需付费和资源利用率最大化。
  2. 降低存储成本：计算节点本地不再需要持久化存储大量数据，数据可以廉价地存储在对象存储（如 S3）或 HDFS 上，避免了为了扩容计算而不得不扩容昂贵的高性能 SSD 本地盘。
  3. 故障恢复更快：由于计算节点无状态，当发生节点故障时，可以实现秒级的快速重启和恢复，提升了系统的高可用性。

6: 对于非结构化数据和 AI 向量检索，Doris 是如何处理的？

6: 对于非结构化数据和 AI 向量检索，Doris 是如何处理的？

A: Apache Doris 通过引入倒排索引和向量索引功能，原生支持非结构化数据的处理：

  1. 全文检索：Doris 内置了倒排索引，能够像搜索引擎一样对文本数据进行高效的全文检索，这对于处理用户日志、评论等文本数据非常高效。
  2. 向量检索：在 AI 业务中，易车利用 Doris 的向量索引功能存储和检索由大模型生成的 Embedding 向量。这使得 Doris 不仅能处理传统的结构化数据，还能作为向量数据库使用，支持“RAG（检索增强生成）”场景，即从海量知识

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章