迈向云原生：理想汽车 OLAP 引擎变革之路
本文发表于： &{ new Date(1743436800000).toLocaleDateString() }
作者：海博，理想汽车大数据工程师
导读：本文整理自理想汽车大数据工程师在StarRocks Summit Asia 2024的分享
在如今数据驱动的时代，高效的分析引擎对企业至关重要。理想汽车作为智能电动汽车的领军企业，面临着海量数据分析的挑战。本文将展开介绍理想汽车 OLAP 引擎从存算一体向云原生架构演进的变革历程，以及在此过程中面临的挑战，以及是如何通过镜舟数据库存算分离架构解决这些问题的。
一、理想汽车 OLAP 引擎的演进历程
理想汽车目前 OLAP 平台规模已相当可观，拥有 12+集群、1.3 万 CPU 核心，日均处理超过 1000 万查询请求，管理约 300T 的数据量，每天百亿级数据入库，业务发展速度令人瞩目。
理想汽车 OLAP 引擎的演进历程反映了企业数据分析平台的成长与挑战，可分为三个关键阶段：
第一阶段（2022 年）：引擎统一
2022 年初，理想汽车面临多种 OLAP 引擎并存的复杂局面，团队同时使用 Impala、StarRocks 以及 TiDB 等多种组件服务 OLAP 场景。多引擎共存的状态也带来了负担：资源成本居高不下，维护工作异常复杂，用户使用体验也大打折扣。
面对这一挑战，团队果断决定统一 OLAP 引擎，将湖仓分析和分析型数据库都交由 StarRocks 承担。这一决策大幅简化了技术栈，也为后续发展奠定了基础。
第二阶段（2023 年）：稳定性与易用性提升
随着引擎统一后用户规模扩大，新的问题逐渐显现。由于用户使用处于“裸机”状态，缺乏规范和约束，系统稳定性问题频发。
针对这些问题，团队构建了全方位的稳定性保障体系，包括监控、巡检和告警机制，完善了用户操作规范和 SOP，实施了资源隔离策略。此外，团队还加强了元数据操作与数据导入导出的产品化能力，大幅提升系统易用性。
第三阶段（2024 年）：向云原生演进
尽管取得了显著进步，团队仍然意识到存算一体架构存在固有的隔离问题、扩容困难和成本高昂等挑战。2024 年，理想汽车决定向云原生架构演进，采用镜舟数据库作为核心引擎，利用其 Multi-warehouse、存算分离、K8s 等云原生能力重构整个 OLAP 平台，开启了数据分析系统的新篇章。
平台定位：大数据场景下的统一查询、分析引擎
在经历了多个发展阶段后，理想汽车明确将数据平台定位为整个企业大数据生态的统一查询分析引擎。团队在镜舟数据库之上构建了 DQS（统一查询服务），提供鉴权、路由、熔断、限流等核心能力，形成大数据平台的统一出口。
这一架构设计不仅实现了技术上的优化，更重要的是满足了业务需求的多样性。从智能座舱、智能驾驶到企业经营分析，从湖仓分析、实时离线分析到 Ad-hoc 查询和联邦查询，镜舟数据库已经全面覆盖了理想汽车的所有业务场景和分析需求，成为企业数据决策的核心引擎。
二、存算一体架构面临的核心挑战
随着业务规模扩大和分析需求深入，存算一体架构的局限性日益凸显。理想汽车团队在实践中遇到了三大核心挑战。
挑战一：单集群内隔离困难，稳定性难保障
在存算一体架构下，多业务共用集群时常出现相互影响的问题：“我们曾经发生过单个业务异常流量暴增，直接将整个集群 CPU 资源打满，导致其他业务查询排队无法获取资源。”尽管团队尝试使用 Resource Group 实现隔离，但对 CPU 资源的隔离效果远不理想。
此外，内表与外表共存也带来了稳定性风险：外表依赖众多外部组件（如 HiveMetaStore、Alluxio 等），外部组件不稳定可能导致整个集群崩溃。
挑战二：机器扩容不灵活且成本高
车辆数据自助分析平台是理想汽车的关键业务系统，最初主要分析 APP 层和少量明细数据。随着业务发展，系统需要接入车机埋点和车辆信号数据，单表数据量迅速增长至万亿行级别，存储需求达到 250TB。在存算一体架构下，团队不得不按照存储需求扩容计算资源。
在如此庞大的数据量下，团队发现：99%的查询只关注近一个月的热数据，大量历史数据很少被访问。这不仅导致大量 CPU 和内存资源浪费，更重要的是，随着车辆数量持续增长，这种扩容模式将变得越来越不可持续。
挑战三：弹性伸缩能力弱，资源利用率低
在智能驾驶数据分析场景中，维护着一个超过 2000 亿条记录的主键模型表，用于智能驾驶模型训练的数据标签检索。这一场景下的查询有三个特点：查询需要全表扫描并过滤聚合、结果集规模巨大（千万级）、查询性能要求高（5 秒内完成）。
更具挑战的是，查询峰值波动大，但出现概率低。为满足峰值需求，只能按照最高负载配置资源，导致整体资源利用率仅约 20%。
这三大挑战共同指向一个核心问题：传统存算一体架构难以满足大规模 OLAP 系统日益增长的灵活性、隔离性和成本效益需求，亟需对架构进行升级重构。
三、镜舟数据库存算分离架构实践
面对存算一体架构的种种挑战，理想汽车团队在 2024 年做出了战略性决策：采用镜舟数据库作为新一代 OLAP 引擎，利用其云原生能力重构整个数据分析平台，给三个关键领域带来了的突破性进展。
1.Multi-Warehouse，解决隔离问题
镜舟数据库的 Multi-Warehouse 能力为理想汽车提供了全新的隔离方案。团队设计了一套三级隔离策略，彻底解决了之前的稳定性难题。
第一级：内外表集群隔离
团队将湖仓外表查询与内表业务完全分离，避免不稳定的外表查询影响内表业务。
第二级：业务场景隔离
在湖仓集群中，团队将 Ad-hoc 灵活分析与传统 BI 业务分离；在内表集群中，则按业务优先级分离高优与低优业务。这种纵向物理隔离比 Resource Group 更加彻底，确保了高优业务的稳定运行。
第三级：读写负载隔离
团队通过将写入场景（包括 compaction 负载）放到独立 warehouse 执行，配合资源组的横向隔离能力，实现更完善的多维度隔离。
通过 Warehouse 的纵向隔离加上 Resource Group 的横向隔离，理想汽车实现了非常完善的隔离能力，大幅提升了稳定性。
2.构建全方位稳定性保障体系
在应用存算分离架构之前，团队已经建立了一套完善的稳定性保障体系，涵盖事前、事中、事后全生命周期：
一是事前预防。通过构建通用巡检机制，提前发现潜在风险，通过 DQS 服务实现 SQL 拦截，过滤高风险查询，并配合开发资源预估工具，确保资源合理配置。
二是事中控制。通过多级隔离能力，团队可以在发生故障时有效缩小影响范围，大幅降低连锁故障的风险。
三是事后治理。提供数据治理能力，排除数据或元数据风险，并定期分析历史问题，识别优化点。同时积极向社区提交 PR，修复发现的 bug。
通过这套完整的稳定性保障体系，结合 Multi-Warehouse 的隔离能力，理想汽车平台稳定性达到了 99.99%，相比之前有了显著提升。
3.存算分离，解决扩容不灵活问题
理想汽车的车辆数据平台是存算分离架构价值的最佳证明。面对持续增长的车辆数据，团队采用了全新的存储策略：将冷数据存储在对象存储中，仅将近一个月的热数据缓存到本地磁盘。
这个决策背后有着严密的数据支撑，理想汽车大数据团队分析了近半年的查询日志，发现 99%的查询仅访问最近 30 天的数据。通过这种热冷分离的方式，能大幅减少本地存储需求，同时保持查询性能。
团队还在业务层面实施了资源削峰措施，即夜间预先计算结果，降低 CPU 并行度，白天直接查询预计算结果。这种用时间换空间的策略，将夜间预计算的资源需求控制在一个合理水平，为日间高峰期留出足够余量。
通过这些措施，在保持查询性能不下降的前提下，节省了 30%的机器资源，不仅解决了当前问题，更为未来数据量进一步增长提供了可持续的解决方案。
4.镜舟数据库 on K8s 部署实现弹性伸缩
理想汽车大数据团队敏锐地察觉到 OLAP 查询和 Spark 生产任务存在天然的波峰波谷互补特性：白天是 OLAP 查询高峰期而 Spark 任务较少，夜间则相反。
基于此，团队利用两者负载的波峰波谷互补特性，日间镜舟数据库使用资源分析数据，夜间 Spark 使用资源生产数据，在不同时段动态调整镜舟数据库和 Spark 的资源分配，实现真正的资源弹性。
验证结果显示：当本地缓存命中时，查询性能与存算一体架构持平；即使缓存未命中，经过参数优化后，性能下降也控制在可接受范围内。
另外，团队发现单表写入性能实际上优于原有架构，单个 CN/BE 节点导入能力达到 142MB/s。通过这种方案，预计可将整体资源利用率提高 50%。
5.镜舟数据库替代 Spark，进行湖仓 Ad-hoc 加速
除了核心架构问题，理想汽车团队还利用镜舟数据库解决了湖仓 Ad-hoc 查询的效率问题。
传统架构下，这类查询依赖 Linkis+Spark 组合，即使简单查询也需要几十秒时间，用户体验较差。
团队设计了全新的查询加速方案：通过 Flink 实时同步 Metastore 元数据至镜舟数据库，消除元数据获取延迟；利用镜舟数据库的资源常驻能力，避免每次查询的资源申请开销；结合自研 DQS 服务替代 Linkis，简化查询路径并增强稳定性保障。
这套方案将 Ad-Hoc 查询性能提升了 10 倍，不仅提升了数据分析师的工作效率，还为业务决策提供了更加及时的数据支持。
四、未来规划：完全云原生架构
随着镜舟数据库在理想汽车的成功应用，团队已经开始规划下一阶段的架构演进，目标是构建一个完全云原生的 OLAP 平台。
完全存算分离架构是团队的首要目标。现阶段的存算分离主要针对计算节点，而元数据服务仍采用存算一体模式。未来计划实现所有集群合并为单一集群，通过共享元数据避免数据孤岛。
团队计划按照场景划分 Warehouse 架构。在单一集群内实现内外表切分，基于业务优先级、负载类型灵活切分 Warehouse，实现内外表混合管理和统一元数据访问。
在资源弹性与成本优化方面，团队计划将低优先级业务部署于 K8s 环境实现弹性伸缩，而高性能需求场景则部署于物理机或云主机。同时，设计支持 Warehouse 间动态负载调整的机制，进一步提升资源利用率。
通过这一系列云原生架构演进，理想汽车与镜舟数据库合作构建了一套兼具稳定性、弹性和成本效益的现代化 OLAP 平台。这一平台不仅有效支撑了从车辆智能分析到企业经营决策的全场景需求，更重要的是为企业在数据驱动转型的道路上奠定了坚实基础，使数据真正成为推动业务创新的核心动力。
