2023年3月，在阿里云瑶池数据库峰会上，阿里云与飞轮科技正式达成战略合作协议。双方旨在共同开发新一代实时数据仓库“阿里云数据库版”，为用户提供阿里云全托管服务。
是飞轮科技基于核心打造的、专注于企业大数据实时分析需求的企业级产品。因此，阿里云数据库版也延续了卓越的性能、精简的架构、稳定可靠、丰富的生态等核心特性。它还融合了云服务的按需功能。通过云原生计算分离的创新架构，为企业带来分钟级弹性扩展、高性价比、易用、安全稳定的云上一键式实时分析体验。
为了更深入地了解阿里云数据库版，我们可以从多个角度全面了解其应用实践和经验。
极跃是高端智能汽车机器人品牌。基于百度领先的AI能力和吉利东南亚庞大的建筑生态赋能，致力于打造领先的智能汽车机器人，以高端智能驾驶和智能座舱产品及创新数字服务为用户打造标杆。一流的智能科技出行体验。随着全球汽车产业加速向电动化、智能化转型，对车端数据实时、准确响应的需求也日益增加。经过比选，吉悦汽车选择利用实时数据仓库库来升级BI分析平台和用户。图像系统。截至目前，开发的数据智能服务系统2.0已部署在多个生产集群中。其优异的读写性能、低成本的数据访问流程以及丰富的大数据生态支持，不仅提高了车上和云端的数据处理效率，简化了实时数据流架构，节省了计算和存储成本，在一定程度上简化了操作和维护。
近年来，全球汽车产业加速向电动化、智能化转型。随着技术的不断迭代，智能能力已成为行业领先企业竞争的焦点。 2023年以来，中国汽车市场新能源渗透率进一步提升，智能驾驶成为影响用户购车的核心因素之一。作为高端智能汽车机器人品牌，吉悦汽车致力于打造领先的智能汽车机器人，以高端智能驾驶和智能座舱产品以及创新的数字化服务为用户打造标杆的智能科技出行体验。
与互联网行业相比，新能源汽车拥有更丰富的数据源、更多样化的数据场景。为了满足客户、车辆、门店等海量数据实时分析的需求，用数据驱动汽车智能化演进，吉悦汽车选择以它为数据库，对整体进行升级。数据智能服务系统。目前已在实时数仓、BI多维分析、用户画像、汽车云中心等多个业务场景落地。
业务挑战和需求
在实际运营过程中，新能源汽车每天都会产生海量的复杂数据，这些数据对车辆的整个生命周期至关重要。这些数据来源主要包括：APP和小程序、商店和工厂、车端数据、云端数据等。
为了充分发挥数据背后的价值，我们搭建了多个业务平台来响应一线业务人员和运营管理者的分析系统，如统一的实时/离线数据仓库系统、BI多维度分析引擎、用户画像CDP平台和车辆中心云平台等。丰富多样的数据服务场景和高时效性的业务需求依赖于OLAP数据库为核心，所以我们希望它具备以下能力：
OLAP研究与技术选型
在选型调研阶段，我们对云厂商的四款OLAP数据库产品：、、、、H产品进行了深入考察，主要从实时数据更新能力、多维数据分析、JOIN性能三个方面进行了深入考察。
考虑到实时数据更新能力和Join性能的高优先级要求，我们首先排除，然后与某云厂商的产品进行比较。由于他们的产品不开源，产品生态相对封闭，综合比较与我们的目标诉求高度吻合。 :
实时数据仓库建设与实践优化
在它出现之前，过去的实时数据仓库都是基于流数据构建的。由于海量数据的存储容量有限，长期历史数据的查询和回溯受到限制。另外，处理后的数据需要存储在不同的查询引擎中，导致数据处理成本较高，且难以支持复杂的即席查询。
升级实时数据仓库可以全面有效地解决我们目前面临的问题。因此，我们构建了统一的离线/实时数据仓库系统，实时响应业务需求。下图是介绍后的实时数据仓库架构图。具体工作机制如下：
在早期阶段，我们也遇到了一些性能挑战。下面我们结合两个具体的应用场景来分享一下我们在使用过程中的性能调优经验。
01 高频DDL优化
在离线/实时数据仓库ETL场景中，每天凌晨5点经常会出现频繁的DDL操作失败。经调查，原因如下：
线程池重建过程中，默认的异步线程返回时间设置不当，导致超时。跟踪源码发现，由于当前线程池规模比较小，导致多个DDL操作并行执行时线程资源不足，导致线程等待，最终超时失败。
针对上述问题，我们调整了以下线程池参数：
经过调优后，操作失败率明显改善。与之前90%的故障率相比，目前的故障率只有10%左右。
调整以上参数后，暂时解决了DDL高频操作失败的问题。但进一步了解业务场景后，我们发现为了将离线数据导入数据库，我们前期进行了建表操作和加法操作。表操作将导致所有重建。该操作消耗大量内存，并且存在数据GAP时间（在GAP时间内，用户查询数据时得到的结果不是最新数据）。
对于这种情况，我们建议的最佳实践如下：
02 加载写入性能调优
智能汽车行驶时，系统会全面监控驱动电机、能耗、通讯定位等数据。因此，大规模车辆数据需要在离线和实时场景下进行写入。
为了提高Load的写入性能，我们进行了多个参数调优：
另外，大批量Load导入时很容易遇到-235的问题，因为我们添加了Load写保护机制，具体为：
这两种写保护机制的参考，有效缓解了大数据量写入时的压力，将数据导入场景的任务成功率和吞吐率提升了50%。
BI分析平台实践与优化
BI分析平台涵盖了广泛的汽车数据业务场景，包括业务决策分析、市场趋势分析、销量预测、增长分析等。在数据分析模块中，我们倾向于使用可视化查询分析引擎来赋能业务决策。
01 早期业务痛点
上图是1.0平台架构图。早期业务严重依赖第三方引擎的数据处理能力。由于建设成熟度较低，系统性能瓶颈很快暴露出来，给业务支撑带来严峻挑战：
02 BI分析平台2.0
面对双向复杂的数据架构环境，首要挑战是数据实时响应的压力。我们需要保证BI分析平台能够快速、准确地响应各种车辆端和用户端的数据变化。这也促使我们启动BI分析平台2.0改造计划。在整个BI分析平台的改造过程中，我们充分结合了业务需求和各种优势：
基于重构后的BI分析平台2.0，我们在数据处理、分析应用等方面进行了架构升级。在重构的过程中，我们也积累了一些性能优化的经验，分享给大家。
03 内存使用优化
在使用BI 2.0平台时，部分用户反映某页面图标无法显示。此时BE内存使用率高达99%，导致其他查询失败。经排查，某条SQL扫描了全表，但级别和级别内存保护机制均未生效。
进一步排查发现，uery和这两个参数都是，内存超过一定限制时拦截无法生效；改为true后，内存保护机制正常运行，问题解决。
1.2.x版本之后，这两个参数的默认值已经调整为true。
点击查看详细功能分析
04 BE问题定位
2.0平台上的一个异常会导致BE崩溃。此类问题需要尽快定位灾难场景进行诊断和快速修复。在使用过程中，我们遇到了两种没有生成ID、在审计日志和be.INFO日志中找不到目标的场景。
于是我们尝试了以下2种方法来定位问题：
检查Core Dump文件，没有发现有效信息；检查客户端日志，目标位于 RPC 的超时上下文部分。
经分析，主要原因如下：
针对上述问题，我们也提出了相应的修复方案，主要包括：
用户画像实践与优化01背景
用户画像包括用户画像CDP平台引擎，涵盖人群选择、事件分析、路径分析等，为吉悦汽车的成长、销售、运营、运营等关键环节提供统一、全面的用户标记、人群选择、用户识别。和售后。画像分析和用户行为分析能力帮助吉悦汽车更精准地把握用户需求，优化数据服务策略。
在构建用户画像的过程中，我们通常会对数据进行离散化，转换为KV格式，并使用高效的存储来保证用户画像的准确性和实时性。用户画像业务架构图如下：
如图所示，数据服务和数据分析两个模块充分利用了强大的多维度分析能力。数据分析师或业务运营同学通过CDP平台根据用户属性、行为数据、业务数据等建立人群选择规则后，可以将规则直接转换成SQL进行计算，计算出的选择结果（数据集）通过方法被存入并提供给下游服务。
02 查询问题位置
下图是用户标签管理模块的表格，其中数据类型为。在生产环境（5 BE）中，查询所有值为1的用户标签时，执行时间长达19秒，远超预期。此时数据量只有5000多行。基于此，我们开始探索快速查询的问题。
我们试图从头开始，首先比较两个版本的核心参数：1.1.5、1.2.5。
经测试，在测试环境和生产环境下，解压后读取数据量，数据量膨胀约1倍；时间很短，但是时间却很长，这说明读取过程中存在明显的数据倾斜。猜测是出现了性能瓶颈。针对上述问题，我们改进了相应的数据分布：
优化后，查询结果由19秒缩短至5秒，查询速度提升3.4倍，但仍达不到1秒返回查询结果的要求。
然后我们尝试从头开始，在运行过程中读取迭代源码时猜测查询慢是由磁盘IO慢和反序列化引起的，然后进行验证操作：
验证结果表明问题出在存储结构的序列化和IO瓶颈上。由于底层是从头开始构建的，所以不存在存储方面浪费资源的问题，所以我们继续关注底层是如何工作的。进一步探索发现：
和 结合的存储原理：
使用红黑树+存储：
对于该用户标签管理场景，用户ID为64位，存储方式为红黑树+。这会导致两个问题：
03 优化方案
基于以上分析，我们提出2个优化方案：
1、利用服务将转为32：32最多可达46亿用户，满足业务系统的数据存储需求。
在测试过程中，我们添加了100个测试标签，每个标签值中的碱基（ ）数量达到了400万以上。全部转换为32位后，查询结果仅需55毫秒，查询效率提升近百倍。
2.正交：将高32位分割成额外的列（例如：）在存储中，不同的高32位被扩展成不同的行。每次查询和写入都通过高32位查询来确定存在哪些行。
04 故障处理总结
经过以上实践，我们简单总结了故障排除思路和具体步骤，分享给大家：
日志探索与分析