5 理想汽车-迈向云原生：理想汽车OLAP引擎变革之路.pdf

迈车向OL云AP原引生擎：变理革想之汽路 海博 理想汽车大数据工程师 01理想汽车OLAP引擎的演进历程 02StarRocks存算一体旧架构的挑战 03StarRocks存算分离架构实践 04未来规划 01 理想汽车OLAP引擎的演进历程 集群规模现状 12+ 集群 1.3w+CPU cores 960w+ 查询/每天 300T+ 数据量 发展历程 2022 2023 2024 统一OLAP引擎 稳定性&产品化建设 服务化建设&迈向云原生 问题： •StarRocks、Impala、Tidb共存，资源成本高、运维成本高、使用成本高 措施： •统一OLAP引擎为StarRocks 问题： •稳定性不足：监控预警能力不完善、用户使用缺乏规范，随意使用 •产品化能能力不完善，不易用措施： •构建完善的监控、告警、巡检体系 •做好集群规划，流程建设，规范用户使用 •资源组隔离大业务&跟进社区最新版本 •完善元数据、数据导入等产品能力 问题： •集群内隔离能力不足 •机器成本不断上涨，资源利用率低措施： •mutil-warehouse •存算分离 •探索onk8s部署 定位：大数据数据场景下的统一查询、分析引擎 StarRocks统一引擎、DQS统一出口： •全业务线覆盖 1.智能座舱 2.智能驾驶 3.运营/经营4....... •全分析场景覆盖 1.湖仓分析 2.实时/离线分析 3.ad-hoc灵活分析 4.联邦查询 02S的ta挑rR战ocks存算一体旧架构 挑战一：单集群内难隔离，稳定性难保障 多业务间互相影响 单业务打满集群cpu单业务打满磁盘 导致导致 其他业务无法查询其他业务无法写入 资源组隔离大业务 CPU隔离不彻底,不能根除 背景：多业务共用集群 如何解决 挑战一：单集群内难隔离，稳定性难保障 外表不稳定致使集群不可用 FE卡住BE卡住 查询40w分区hive表 获取alluxio文件信息超时 查询到大量bos冷数据 metaCache拉取线程卡住 pull-remote-files线程池打满 scan线程池打满 背景：内外表共用集群 ad-hoc查询引发异常影响看板,如何解决 挑战二：机器扩容不灵活且成本高 业务背景新需求扩容方案 接入车机埋点、部分车辆信号明细数据： •单表各万亿行 •3副本共250T+数据(保留1年) •99%场景查询1个月的热数据按存储需扩容20台 随着车辆数增多，数据逐步增长 问题： 1）为了扩磁盘需扩容大量机器造成CPU和内存的浪费 2）冷数据被查到的频率很低，也造成存储资源的浪费 挑战三：弹性伸缩能力弱，资源利用率低 业务场景业务特点问题 都是大query，资源消耗大 •全表上的标签过滤和聚合 •结果集超千万 查询性能要求高:<=5s (智能驾驶数据挖掘业务) 查询峰值高，但是概率低：需满足峰值要求 如上，按峰值配置资源： •是低峰时的3倍 •整体资源利用率低(20%) •造成大量资源浪费 03StarRocks存算分离架构实践 Multi-Warehouse解决隔离问题 一、内外表集群隔离 ：没合并 避免影响内表业务(更高优) 外表集群隔离出BIwarehouse,避免被ad-hoc影响(更不稳定) 二、业务隔离 高低优业务物理隔离 业务内资源组隔离限制大查询 三级隔离 三、读写分离 需读写链路、cache层配合 探索中 Mutil-Warehouse&稳定性保障 巡检、SQL拦截 识别并消除风险因素 资源预估、性能测试 事前 确保资源充足不浪费 数据治理规范建表 排除数据、元数据风险 稳定性99.99% 事中Multi-Warehouse隔离 多级隔离，缩小影响范围 事后Bug修复&跟进稳定版本避免问题再现 存算分离解决扩容不灵活、成本高的问题 存算分离： (保证热数据缓存100%命中) 资源削峰： 1、查询性能未下降 •大表查询在6s左右 •中小表秒级响应 2、机器资源节省30% 1.夜间预计算：pipeline_dop设为1/2，加大query_timeout 2.白天预计算结果服务用户：pipeline_dop正常 3000+core ->2000+core StarRocksonK8s解决弹性伸缩问题 方案 验证配置: •镜像：cn-ubuntu:3.1.5、fe-ubuntu:3.1.5 •资源：128核/512GB/4*4T*3 •存储：bos+alluxio 验证结论: Spark和StarRocks资源波峰波谷互补： •夜间Spark使用资源生产数据 •日间StarRocks使用资源分析数据 Spark和StarRocks共用k8s集群，互相削峰填谷，资源利用率可提高50% 待上线 查询性能： •命中本地缓存：性能和存算一体持平 •不命中本地缓存：相比于存算一体，有5.8倍的性能下降 写入性能： •单表单次写入：存算分离反而稍优于存算一体 •单BE导入能力：单CN导入速度平均可达142mb/s,且还有上升空间 替代Spark进行湖仓ad-hoc加速 背景 慢 解决方案 快10倍 StarRocks替代Spark： •元数据实时同步减少元数据延迟 •资源常驻&SR强劲计算能力，大幅提升查询速度 DQS替代Linkis •免去EC启动时间 •拦截超大Query •路由至Spark兜底 04未来规划 未来规划 一、只有一个集群 •FE存算分离后共享元数据 •按场景隔离FE 二、按场景切分warehouse •内外分离 •读写分离 •高优低优分离 三、资源弹性、按量付费 •ad-hoc、低优场景onk8s弹性伸缩 •内表场景设置弹性warehouse •故障时，基于k8s快速拉起backup集群 关注公众号 T感hanky谢ou! 观看！