5 理想汽車-邁向云原生：理想汽車OLAP引擎變革之路.pdf

《5 理想汽車-邁向云原生：理想汽車OLAP引擎變革之路.pdf》由會員分享，可在線閱讀，更多相關《5 理想汽車-邁向云原生：理想汽車OLAP引擎變革之路.pdf（20頁珍藏版）》請在三個皮匠報告上搜索。

1、邁向云原生：理想汽車OLAP引擎變革之路海博理想汽車大數據工程師01020304理想汽車OLAP引擎的演進歷程StarRocks存算一體舊架構的挑戰StarRocks存算分離架構實踐未來規劃01理想汽車OLAP引擎的演進歷程集群規?，F狀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!關注公眾號