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

《5 理想汽车-迈向云原生：理想汽车OLAP引擎变革之路.pdf》由会员分享，可在线阅读，更多相关《5 理想汽车-迈向云原生：理想汽车OLAP引擎变革之路.pdf（20页珍藏版）》请在三个皮匠报告上搜索。

1、迈向云原生：理想汽车OLAP引擎变革之路海博理想汽车大数据工程师01020304理想汽车OLAP引擎的演进历程StarRocks存算一体旧架构的挑战StarRocks存算分离架构实践未来规划01理想汽车OLAP引擎的演进历程集群规模现状12+集群1.3w+CPU cores960w+查询/每天300T+数据量发展历程2024服务化建设&迈向云原生问题：集群内隔离能力不足机器成本不断上涨，资源利用率低措施：mutil-warehouse存算分离探索on k8s部署2023稳定性&产品化建设问题：稳定性不足：监控预警能力不完善、用户使用缺乏规范，随意使用产品化能能力不完善，不易用措施：构建完善的监

2、控、告警、巡检体系做好集群规划，流程建设，规范用户使用资源组隔离大业务&跟进社区最新版本完善元数据、数据导入等产品能力2022统一OLAP引擎问题：StarRocks、Impala、Tidb共存，资源成本高、运维成本高、使用成本高措施：统一OLAP引擎为StarRocks定位：大数据数据场景下的统一查询、分析引擎StarRocks 统一引擎、DQS 统一出口：全业务线覆盖1.智能座舱2.智能驾驶3.运营/经营4.全分析场景覆盖1.湖仓分析2.实时/离线分析3.ad-hoc 灵活分析4.联邦查询02StarRocks存算一体旧架构的挑战挑战一：单集群内难隔离，稳定性难保障多业务间互相影响单业务打

3、满集群cpu单业务打满磁盘其他业务无法查询其他业务无法写入CPU隔离不彻底,不能根除导致导致资源组隔离大业务如何解决背景：多业务共用集群挑战一：单集群内难隔离，稳定性难保障外表不稳定致使集群不可用查询到大量bos冷数据查询40w分区hive表 获取alluxio文件信息超时FE卡住BE卡住metaCache拉取线程卡住pull-remote-files线程池打满scan线程池打满ad-hoc查询引发异常影响看板,如何解决背景：内外表共用集群挑战二：机器扩容不灵活且成本高业务背景新需求扩容方案问题：1）为了扩磁盘需扩容大量机器造成 CPU 和内存的浪费 2）冷数据被查到的频率很低，也造成存储资源

4、的浪费接入车机埋点、部分车辆信号明细数据：单表各万亿行3副本共250T+数据(保留1年)99%场景查询1个月的热数据按存储需扩容20台随着车辆数增多，数据逐步增长挑战三：弹性伸缩能力弱，资源利用率低业务场景业务特点问题(智能驾驶数据挖掘业务)都是大query，资源消耗大全表上的标签过滤和聚合结果集超千万查询峰值高，但是概率低：需满足峰值要求如上，按峰值配置资源：是低峰时的3倍整体资源利用率低(20%)造成大量资源浪费查询性能要求高:StarRocks on K8s解决弹性伸缩问题验证结论:镜像：cn-ubuntu:3.1.5、fe-ubuntu:3.1.5资源：128核/512GB/4*4T*

5、3存储：bos+alluxio方案Spark和StarRocks资源波峰波谷互补：夜间Spark使用资源生产数据日间StarRocks使用资源分析数据Spark和StarRocks共用k8s集群，互相削峰填谷，资源利用率可提高50%查询性能：命中本地缓存：性能和存算一体持平不命中本地缓存：相比于存算一体，有 5.8倍的性能下降 写入性能：单表单次写入：存算分离反而稍优于存算一体单BE导入能力：单 CN 导入速度平均可达 142mb/s,且还有上升空间验证配置:待上线替代Spark进行湖仓ad-hoc加速背景慢解决方案快10倍DQS替代Linkis免去EC启动时间拦截超大Query路由至Spark兜底StarRocks替代Spark：元数据实时同步减少元数据延迟资源常驻&SR强劲计算能力，大幅提升查询速度04未来规划一、只有一个集群FE存算分离后共享元数据按场景隔离FE二、按场景切分warehouse内外分离读写分离高优低优分离三、资源弹性、按量付费ad-hoc、低优场景on k8s弹性伸缩内表场景设置弹性warehouse故障时，基于k8s快速拉起backup集群未来规划感谢观看！Thank you!关注公众号