<p>企业在数据驱动的道路上，始终面临一对核心矛盾：既需要低成本、可扩展的存储方案来承载海量结构化、半结构化乃至非结构化数据（这正是数据湖的强项），又渴望实时、低延迟的分析能力来支撑业务决策（这是分析型数据库的核心优势）。</p> 然而现实是，单独的解决方案往往难以两全：以 Apache Paimon 为代表的数据湖技术，虽凭借开放格式、弹性扩展和低成本存储成为企业数据中台的基石，但在低延迟响应上存在天然短板；而以 Apache Doris 为代表的分析型数据库，虽能提供高效的查询性能，却缺乏数据湖的存储灵活性与开放性。
本文的核心观点是：”架起数据库与数据湖的桥梁” 并非趋势，而是破局的关键。小米通过将 Apache Doris（数据库）与 Apache Paimon（数据湖）深度融合，不仅解决了数据湖分析的性能瓶颈，更实现了 “1+1>2” 的协同效应。
数据库与数据湖的互补之力
“桥接数据库与数据湖”的核心价值，在于构建”存储灵活、计算高效、格式协同 “的一体化架构——不仅是存储与计算能力的分工互补，更包含数据格式层面的深度协同，让两者的技术特性形成叠加效应。
1. 数据湖仓的分工定位
从基础能力来看，两者的分工已形成天然互补：
- Apache Paimon 作为数据湖，核心优势体现在存储层：其开放格式（兼容 Spark、Flink、Trino 等多引擎）、基于对象存储（S3、HDFS）的 PB 级弹性扩展能力，以及对事务、Schema 演进的原生支持，使其成为海量异构数据的”统一存储基座”，兼顾低成本与兼容性。
- Apache Doris 作为分析型数据库，核心优势体现在计算层：分布式并行引擎、向量化执行框架、以及针对复杂聚合场景的算子优化，使其能提供毫秒至秒级的低延迟查询响应，成为数据价值挖掘的”高效计算引擎”。
2. 数据格式的特性互补
更深层的协同点，在于数据格式的特性互补：
- 数据湖格式（如 Paimon）为适配多引擎读写与大规模存储场景，在设计上以通用性为优先，虽能满足跨引擎兼容需求，但在高频查询、复杂计算场景下，其通用格式的解析效率、IO 开销难以进一步优化；
- 而数据库（如 Doris）则拥有专为查询性能设计的 高效内部存储格式——例如基于列存的分层存储结构、自适应编码压缩算法（如字典编码、RLE 压缩）、原生索引（如前缀索引、 bloom filter）等，这些格式通过深度耦合计算引擎的执行逻辑，可最大限度减少数据扫描量与 IO 消耗，实现亚秒级查询响应。
3. 桥接架构的双向赋能
桥接架构下，数据湖仓可实现双向赋能：
- 海量冷数据、全量历史数据以 Paimon 格式存储于数据湖，保持低成本与多引擎兼容性；
- 高频访问的热数据、需复杂聚合的核心指标，则通过 Doris 的物化视图、本地缓存等机制，转换为 Doris 高效内部格式存储，借助其原生存储与计算的协同优化，实现极致查询性能。
这种模式既避免了单一数据湖格式在查询性能上的瓶颈，又解决了单一数据库格式在存储成本与扩展性上的局限。唯有通过”桥接”，才能让数据湖的通用存储优势与数据库的高效格式特性形成合力，实现”存储成本可控、查询性能最优”的理想状态。
Apache Doris & Paimon 在小米的实践与挑战
Apache Paimon 是一款优秀的开放数据湖格式，其流批一体的设计很好的满足了湖上数据的实时处理需求。
Doris 在 2.1 版本开始支持 Paimon Catalog，可以直接访问 Paimon 数据并加速 Paimon 数据分析。在 Paimon TPC-DS 1TB 测试集上，Doris 的总体查询性能是 Trino 的 5 倍。
从 2.1 版本到 3.0、3.1 版本，Doris 在持续针对 Paimon 格式进行功能更新和性能增强，包括但不限于以下功能：
- 通过元信息对 Paimon 数据进行分区、分桶裁剪和谓词下推，优化查询效率。
- 支持 Paimon Deletion Vector 读取，利用向量化 C++ 引擎加速 Paimon 更新数据的读取。
- 支持 Paimon 数据的本地文件缓存，充分利用本地高速磁盘提升热点数据的查询效率。
- 支持 Paimon 时间旅行、增量数据读取、Branch/Tag 数据读取，方便用户进行 Paimon 数据的多版本管理。
- 支持基于 Paimon 的物化视图，包括分区级别的增量物化视图构建，以及本文后续将要介绍的基于快照级别的增量构建，同时支持强一致的物化视图透明改写能力，将湖和仓的能力深度结合。
- 支持 Paimon Rest Catalog（DLF），方便云上用户接入 Paimon 生态，实现统一元数据管理。
在本文中，我们将重点介绍小米如何基于 Doris + Paimon 构建统一湖仓平台，以及在项目开发过程中的功能贡献和优化思路。
01 化繁为简：基于 Doris + Paimon 的统一湖仓平台建设
作为一家业务覆盖汽车、IoT、手机、互联网服务等多个领域的大型企业，小米集团对 OLAP 系统和湖仓平台提出了如下关键需求：
- 多维度分析：支持高并发、低延迟的多维聚合分析（如用户行为、设备状态、运营监控等）。
- 多源接入：需要打通 Flink、Spark、Flink CDC 等流批框架的输入，覆盖离线、实时全链路数据处理场景。
- 统一数据访问：支持跨引擎、多格式的数据消费需求（如 Doris、Paimon、Iceberg 等）。
- 降低平台复杂度：减少技术栈分裂，统一数据建模与管控，提升数据平台运维效率。
当前架构的挑战与瓶颈
尽管已有较成熟的数据平台体系，但小米的 OLAP 湖仓架构长期存在如下”繁杂、割裂”的结构问题：
- 存储多源异构，数据重复堆叠
- 为满足不同业务对数据的不同时效性需求，需要按照分钟、小时、天级别的时效性要求，将数据存储在不同的数据系统中（Iceberg、Paimon、Druid、Doris），导致数据冗余、不一致等问题
- 湖仓割裂，缺乏统一接口
- 需要同时使用不同的引擎进行数据查询，（如 Presto、Druid、Doris、Spark 等）。各系统有独立的数据建模、运维和权限控制逻辑，平台治理成本高，入口不统一，使用方式不统一。
