近年来，全球汽车行业向电动化、智能化加速转型，随着技术的不断迭代，智能化能力已成为行业头部公司间互相比拼的重点。2023 年以来，中国汽车市场的新能源渗透率更是进一步提升，智能驾驶已成为影响用户购车的核心因素之一。极越汽车作为高端智能汽车机器人品牌，致力于打造智能化领先的汽车机器人，以高阶智驾、智舱产品和创新数字化服务，为用户创造标杆级智能科技出行体验。
与互联网行业相比，新能源汽车的数据来源更丰富，数据场景也更加多样化。为了满足客户端、车端、门店端等海量数据实时分析的需求，以数据驱动汽车智能化的演进，极越汽车选择 Apache Doris 作为数据底座来升级整体数据智能服务体系。 截至目前， Apache Doris 已经在实时数仓、BI 多维分析、用户画像、车云中心（Serving）等多个业务场景中落地。
业务挑战和诉求
在实际运营过程中，新能源汽车每天都会产生海量的、对汽车全生命周期至关重要的复杂数据，这些数据来源主要包括： APP 与小程序、门店与工厂、车端数据、云端数据等 。
为了充分发挥数据背后的价值，我们构建了多个业务平台来响应一线业务人员和经营管理者的分析系统，例如统一的实时/离线数据仓库体系、BI 多维分析引擎、用户画像 CDP 平台以及车辆中心云平台等。丰富多样的数据服务场景和高时效性的业务要求，其中所依赖的核心便是 OLAP 数据库，因此我们希望其具备以下能力：
OLAP 调研与技术选型
在选型调研阶段，我们深入考察了 Apache Doris、ClickHouse、Apache Kylin 和某云厂商产品 H 这四款 OLAP 数据库产品，主要从数据实时更新能力、多维数据分析和 JOIN 性能三个方面进行考察。
考虑实时数据更新能力和 Join 性能的高优先级需求，我们首先排除了ClickHouse和 Apache Kylin，再对比与某云厂商的产品，由于其产品非开源且产品生态较为封闭，综合对比下来 Apache Doris 与我们的目标诉求高度匹配：
实时数仓建设与实践优化
在引入 Apache Doris 之前，过去的实时数仓基于 Kafka 流式数据构建。由于 Kafka 对海量数据的存储能力比较有限，限制了长时间历史数据的查询和回溯。另外加工好的数据需要存放在不同的查询引擎，导致数据加工的成本比较高，且难以支持复杂的即席查询。
以 Apache Doris 升级实时数据仓库，可以充分有效解决我们目前面临的问题。因此，我们基于 Apache Doris 打造了统一的离线/实时数仓体系，实时响应业务需求。下图是引入 Apache Doris 后的实时数仓架构图，具体工作机制如下：
初期阶段，我们也遇到了一些性能方面的挑战。下面结合两个具体应用场景，分享我们在使用过程中的性能调优经验。
01 高频 DDL Alter 优化
在离线/实时数仓 ETL 场景，每天凌晨 5 点常常出现 Doris DDL 频繁操作失败的情况。经过排查，原因如下：
针对上述问题，我们调整了以下线程池参数：
调优后，操作失败率显著改善。相比于之前 90% 的失败率，现在的失败率仅有 10% 左右。
调整以上参数后，DDL 高频操作失败的问题暂时得以解决，但进一步了解业务场景后发现，为了将离线数据导入到 Doris ，前期我们进行了 Truncate 表操作和添加 Partition 操作，其中 Truncate 表操作会造成所有的 Tablet 重建，这个操作消耗了大量的内存，而且存在数据 GAP 时间（在 GAP 时间内，用户查询数据时得到的结果并非最新数据）。
针对这种场景，我们在 Doris 中有一个推荐的最佳实践方案：
02 Stream Load 写入性能调优
智能汽车在行驶过程中，系统会对驱动电机、能耗情况、通讯定位等数据全面监测，因此在离线和实时场景下，都需要写入大规模车辆数据。
为了提升 Stream Load 的写入性能，我们进行了多处参数调优：
max_cumulative_compaction_num_singleton_deltas = 500max_tablet_version_num = 1500min_compaction_failure_interval_sec = 5另外，在大批量 Stream Load 导入的过程中容易遇到 -235 的问题，因为我们加入了 Stream Load 写入保护机制，具体为：
这两个写入保护机制的引用，有效缓解了 Doris 写入大量数据时的压力，使得数据导入场景的任务成功率和吞吐率提升了 50%。
BI 分析平台实践及优化
BI 分析平台涵盖丰富的汽车数据业务场景，包括经营决策分析、市场趋势分析、销量预测、增长分析等。在数据分析模块，我们往往倾向于使用可视化查询分析引擎，为业务决策赋能。
01 早期业务痛点
上图是 1.0 平台架构图，早期的业务十分依赖第三方引擎的数据处理能力， 由于构建成熟度低，系统性能瓶颈很快暴露出来，对业务支持带来严峻挑战：
02 BI 分析平台 2.0
面对双向复杂的数据架构环境，首要挑战是数据实时响应的压力，我们需要确保 BI 分析平台能够迅速、准确地应对各种车端及用户端数据变化，这也促使我们开始了 BI 分析平台 2.0 的改造计划。在整个 BI 分析平台的改造过程中，我们充分将业务需求与 Apache Doris 的各项优势相结合：
基于 Apache Doris 我们重新构造了 BI 分析平台 2.0，在数据处理、分析应用等方面进行了架构升级。在重构过程中，我们也积累了一些 Doris 性能优化的经验，与大家一同分享。
03 内存占用优化
在使用 BI 分析 2.0 平台时，部分用户反馈某页面图标无法展现，此时 Doris BE 内存占用率高达 99%，导致其他查询失败。经排查，某个 SQL 扫描了全表，而 Doris Session 级别和 Global 级别的内存保护机制均未生效。
进一步排查发现，MemTracker 的两个参数
mem_tracker_cancel_query
、
proc_meminfo_cancel_query
默认值都是 False ，当内存超过一定限制时拦截无法生效；改为 true 后，内存保护机制正常运行，问题得以解决。
1.2.x 版本后，这两个参数默认值已调整为 true。
04 BE Crash 问题定位
2.0 平台的某单个 Query 异常导致 BE 崩溃，这类问题需要第一时间定位到灾难场景，以便进行诊断与快速修复。在使用过程中，我们遇到了两个未产生 Query Id 的场景，审计日志、be.INFO 日志中都未发现目标 Query 。
于是我们尝试以下 2 个方法进行问题定位：
经分析，导致 Crash 的原因主要有以下两点：
针对以上问题，我们也提出了相应的修复方案，主要包括：
用户画像实践及优化
01 背景
用户画像包括用户画像 CDP 平台引擎，涵盖人群圈选、事件分析、路径分析等，为极越汽车的增长、销售、运营、售后等关键环节提供了统一全面的用户打标、人群圈选、用户画像分析以及用户行为分析的能力，从而帮助极越汽车更精准地把握用户需求，优化数据服务策略。
在用户画像的构建过程中，我们通常会对数据进行离散化处理，转化为 KV 格式后，利用 Bitmap 高效存储，确保用户画像的精准性和实时性。用户画像业务架构图如下：
根据图中所示，数据服务和数据分析两个模块充分利用了 Doris 强大的多维分析能力。数据分析师或者业务运营同学通过 CDP 平台在用户属性、行为数据、业务数据等基础上建立人群圈选的规则之后，规则可直接转换为 Doris SQL 进行计算，计算后的圈选结果（数据集）通过 Bitmap 的方式存入到 Doris 并供下游服务。
02 查询问题定位
下图是用户标签管理模块的
tag_ser_Bitmap
表，其中， user_ID 的数据类型是 Bitmap。在生产环境（5 BE）下，查询 user_ID 为 1 的所有用户标签时，执行时间长达 19 秒之多，执行时间远超预期，而此时数据量只有 5000 多行。基于此，我们开始探索 Bitmap 快速查询问题所在。
一开始我们尝试从 Profile 入手，先是对比了 1.1.5 和 1.2.5 两个版本的核心参数：
CompressedBytesRead
、
Uncompressed BytesRead
、
RawRowsRead
和
BlockLoadTime
。
经测试，在测试和生产环境中，读取数据量都存在解压缩情况，数据体积膨胀约 1 倍多；IOtimer 时间较短，但 BlockLoadTime 时间很长，这说明读的过程存在明显的数据倾斜，猜测是 BlockLoadTime 出现了性能瓶颈。针对以上问题，我们改善了对应数据分布：
优化后，查询结果从 19 秒 缩短到 5 秒，查询速度提升 3.4 倍，但仍未达到一秒返回查询结果的要求。
随后我们尝试从 Bitmap 入手，猜测慢查询是 BlockLoadtime 运行过程中 Segmentlteror 读取迭代源码时磁盘 IO、反序列化较慢导致的，随后进行了验证操作：
<div style={{textAlign:'center'}}><img src="https://cdn.selectdb.com/static/Doris_4_74ec12ac5e.png" alt="极越汽车-基于 Doris 用户画像实践及优化-4" style={{display: 'inline-block'}}/></div >
验证结果表明，问题在于 Bitmap Value 的存储结构存在序列化和 IO 瓶颈问题。由于 Bitmap 底层由 Roaring Bitmap 构建，存储方面不存在资源浪费的问题，因此我们继续关注 Bitmap 底层的工作原理。通过进一步探索发现：
结合 Bitmap32 和 Bitmap64 的存储原理：
针对该用户标签管理场景，user ID 为 64 位，存储方式是红黑树 + Roaring Bitmap，这就会产生两个问题：
03 优化方案
基于以上分析，我们提出了 2 种优化方案：
1. 利用 IdMapping 服务将 user_id 转换成 Bitmap 32：Bitmap 32 最高可达到 46 亿用户量，满足业务系统的数据存储需求。
测试时，我们加入了 100 个测试标签，每个标签值内（Bitmap Value）的基数达 400 多万个。全部转化成 32 位 Bitmap 后，查询结果仅需 55 毫秒，查询效率提升近百倍。
2. 正交 Bitmap：将高 32 位拆成额外一列（例如：user_id_prefix）存储中，不同的高 32 位膨胀到不同的行中每次查询和写入都通过高 32 位查询判断哪些行存在 Roaring Bitmap。
04 问题排查小结
经过上述实践，我们简单总结了问题排查思路与具体步骤，与大家分享一下：
日志探查与分析
问题复现与反馈
源码分析与调试
总结与展望
截至目前，基于 Apache Doris 的数据智能服务体系已经部署了近十套生产集群，节点规模已经接近百台，存储的数据总量达数百 T，覆盖了实时数仓、BI 多维分析、用户画像、车云中心（Serving）、日常分析等多个业务场景。从业务侧来看，Apache Doris 为极越汽车在提升客户用车体验、实时监测车辆信息、保障安全驾驶等方面提供了更全面、更准确的业务洞察和决策支持，有力推进了极越汽车创新数字化服务的步伐。从技术侧看，Doris 优秀的读写性能、低成本数据接入流程和丰富的大数据生态支持，既提升了车端、云端数据处理效率，又简化实时数据流架构，还能一定程度上节约计算和存储成本、简化运维。
未来，我们计划在以下几个方面继续升级和优化：
