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

海博理想汽车大数据工程师 理想汽车OLAP引擎的演进历程 StarRocks存算一体旧架构的挑战 StarRocks存算分离架构实践 04 理想汽车OLAP引擎 服务化建设&迈向云原生 稳定性&产品化建设 问题： 问题： 问题： •稳定性不足：监控预警能力不完善、用户使用缺乏规范，随意使用•产品化能能力不完善，不易用 •集群内隔离能力不足•机器成本不断上涨，资源利用率低 •StarRocks、Impala、Tidb共存，资源成本高、运维成本高、使用成本高 措施：•统一OLAP引擎为StarRocks 措施： 措施： •mutil-warehouse•存算分离•探索on k8s部署 •构建完善的监控、告警、巡检体系•做好集群规划，流程建设，规范用户使用•资源组隔离大业务&跟进社区最新版本•完善元数据、数据导入等产品能力 StarRocks统一引擎、DQS统一出口： •全业务线覆盖 1.智能座舱2.智能驾驶3.运营/经营4....... •全分析场景覆盖 1.湖仓分析2.实时/离线分析3.ad-hoc灵活分析4.联邦查询 StarRocks存算一体旧架构 问题： 1）为了扩磁盘需扩容大量机器造成CPU和内存的浪费2）冷数据被查到的频率很低，也造成存储资源的浪费 业务特点 业务场景 如上，按峰值配置资源：•是低峰时的3倍 •整体资源利用率低(20%)•造成大量资源浪费 查询峰值高，但是概率低：需满足峰值要求 (智能驾驶数据挖掘业务) 1、查询性能未下降•大表查询在6s左右 •中小表秒级响应 存算分离： 资源削峰： 2、机器资源节省30% 1.夜间预计算：pipeline_dop设为1/2，加大query_timeout2.白天预计算结果服务用户：pipeline_dop正常 StarRocks on K8s解决弹性伸缩问题 验证配置: •镜像：cn-ubuntu:3.1.5、fe-ubuntu:3.1.5•资源：128核/512GB/4*4T*3•存储：bos + alluxio 验证结论: 查询性能： •命中本地缓存：性能和存算一体持平•不命中本地缓存：相比于存算一体，有5.8倍的性能下降 Spark和StarRocks资源波峰波谷互补：•夜间Spark使用资源生产数据•日间StarRocks使用资源分析数据 •单表单次写入：存算分离反而稍优于存算一体•单BE导入能力：单CN导入速度平均可达142mb/s,且还有上升空间 Spark和StarRocks共用k8s集群，互相削峰填谷，资源利用率可提高50% 一、只有一个集群•FE存算分离后共享元数据•按场景隔离FE 二、按场景切分warehouse•内外分离 •读写分离•高优低优分离 三、资源弹性、按量付费•ad-hoc、低优场景on k8s弹性伸缩 •内表场景设置弹性warehouse•故障时，基于k8s快速拉起backup集群 Thank you!