作者：蔚來(lái)汽車(chē)數(shù)字化業(yè)務(wù)發(fā)展部大數(shù)據(jù)團(tuán)隊(duì)

小編導(dǎo)讀：

蔚來(lái)汽車(chē)是一家全球化的智能電動(dòng)汽車(chē)公司，是高端智能汽車(chē)市場(chǎng)的先驅(qū)及領(lǐng)跑者。蔚來(lái)致力于通過(guò)提供高性能的智能電動(dòng)汽車(chē)與極致用戶體驗(yàn)，為用戶創(chuàng)造愉悅的生活方式。

為了提升內(nèi)部大數(shù)據(jù)分析的效率，蔚來(lái)陸續(xù)嘗試了多種組件，如 Apache Druid、TiDB 和 Apache Doris，最終選擇 StarRocks，作為極速統(tǒng)一的數(shù)據(jù)分析層，落地場(chǎng)景包含：用戶畫(huà)像平臺(tái)、數(shù)據(jù)運(yùn)營(yíng)平臺(tái)、BI 自助取數(shù)和整車(chē)三電可靠性數(shù)據(jù)庫(kù)。引入 StarRocks 之后，在不同場(chǎng)景下分別有 4-8 倍的提升。

OLAP 架構(gòu)演進(jìn)

蔚來(lái)汽車(chē)內(nèi)部有豐富的 OLAP 使用場(chǎng)景需求，包括銷(xiāo)售潛在客戶人群圈選、供應(yīng)鏈/生產(chǎn)/物流時(shí)效看板、車(chē)主用車(chē)行為分析、車(chē)輛電池報(bào)警監(jiān)控、售后維修歸因等。

• 支持較高程度的并發(fā)（主鍵模型）
• 實(shí)時(shí)與離線分析的雙重支持
• 支持明細(xì)和聚合模型
• 支持一定程度的更新
• 優(yōu)秀的 Rollup 和物化視圖能力，顯著提升了查詢效率
• 兼容 MySQL 協(xié)議，開(kāi)發(fā)和使用成本比較低
• 全面的向量化引擎，支持 SIMD 指令，讀寫(xiě)性能非常優(yōu)異，滿足我們的要求
• 架構(gòu)簡(jiǎn)潔，運(yùn)維成本比較低

（StarRocks 架構(gòu)簡(jiǎn)潔且提供 MySQL 協(xié)議接口）

在我們的大數(shù)據(jù)架構(gòu)中，來(lái)自 Kafka/Hive 的業(yè)務(wù)/用戶數(shù)據(jù)源，通過(guò) Broker Load/Routine Load/Stream Load/Flink Connector 等多種離線/實(shí)時(shí)導(dǎo)入方式寫(xiě)入 StarRocks，主要用來(lái)存儲(chǔ) DWD/DWS/ADS 層的數(shù)據(jù)，用于離線和實(shí)時(shí)指標(biāo)的快速分析。我們深度自研的 DataSight 一站式數(shù)據(jù)治理與開(kāi)發(fā)平臺(tái)，已經(jīng)集成了 StarRocks，支持通過(guò)配置化方式方便的讀寫(xiě) StarRocks。

將歷史任務(wù)遷移到 StarRocks 后，改善和收益顯而易見(jiàn)。無(wú)論是查詢速度還是運(yùn)維成本，都得到了提升。以某車(chē)輛數(shù)據(jù)指標(biāo)的 BI 服務(wù)為例，過(guò)去該指標(biāo)采用 Druid 和 Cassandra 兩種數(shù)據(jù)庫(kù)存儲(chǔ)，在遷移到 StarRocks 后，通過(guò)合理的 Rollup 策略，平均查詢延遲從 2s+ 降低到 500ms，查詢效率提高 4-5 倍，并且僅需使用一種 OLAP 查詢引擎。

目前，公司已有 20 多個(gè)業(yè)務(wù)線開(kāi)始使用 StarRocks，廣泛應(yīng)用于研發(fā)、生產(chǎn)制造以及用戶車(chē)輛運(yùn)營(yíng)等多個(gè)領(lǐng)域的業(yè)務(wù) BI 看板和指標(biāo)大屏。

主要應(yīng)用場(chǎng)景介紹

StarRocks 在我們團(tuán)隊(duì)主要有幾個(gè)典型的應(yīng)用場(chǎng)景：用戶畫(huà)像平臺(tái)、數(shù)據(jù)運(yùn)營(yíng)平臺(tái)、BI 自助取數(shù)、整車(chē)三電可靠性數(shù)據(jù)庫(kù)等。

蔚來(lái)數(shù)字化業(yè)務(wù)發(fā)展部門(mén)自主研發(fā)的用戶畫(huà)像平臺(tái)是具備標(biāo)簽、分群、洞察和觸達(dá)能力的平臺(tái)，可以幫助業(yè)務(wù)全方位了解用戶。這個(gè)平臺(tái)全面幫助業(yè)務(wù)部門(mén)深入了解用戶，通過(guò)標(biāo)簽圈選人群，生成用戶畫(huà)像定制個(gè)性化內(nèi)容，并在用戶生命周期中與他們進(jìn)行深入互動(dòng)。同時(shí)，平臺(tái)會(huì)自動(dòng)跟蹤觸達(dá)效果，確保高效地為用戶提供極致貼心的服務(wù)。

用戶畫(huà)像平臺(tái)主要使用 StarRocks 來(lái)存儲(chǔ)用戶的標(biāo)簽和分群數(shù)據(jù)，利用 StarRocks 強(qiáng)大的數(shù)據(jù)分析能力，可以通過(guò)用戶的標(biāo)簽自由組合出各類(lèi)用戶畫(huà)像，并運(yùn)用于營(yíng)銷(xiāo)、運(yùn)營(yíng)、服務(wù)和數(shù)據(jù)分析等眾多場(chǎng)景。

1. 離線標(biāo)簽部分：使用了 Spark 任務(wù)計(jì)算出日級(jí)更新的標(biāo)簽，并導(dǎo)入 StarRocks 的離線標(biāo)簽表。
2. 實(shí)時(shí)標(biāo)簽部分：使用了 Flink 任務(wù)實(shí)時(shí)監(jiān)聽(tīng)業(yè)務(wù)數(shù)據(jù)庫(kù)表變更，并實(shí)時(shí)進(jìn)行數(shù)據(jù)加工處理，最后將實(shí)時(shí)標(biāo)簽數(shù)據(jù)導(dǎo)入到 StarRocks 的實(shí)時(shí)標(biāo)簽表。
3. 算法標(biāo)簽部分：包含了離線的打標(biāo)和實(shí)時(shí)的打標(biāo)，最終數(shù)據(jù)都會(huì)進(jìn)行到 StarRocks 相關(guān)表里。
4. 數(shù)據(jù)服務(wù)部分：結(jié)合離線和實(shí)時(shí)標(biāo)簽數(shù)據(jù)，計(jì)算出各類(lèi)分群數(shù)據(jù)，并存儲(chǔ)到 StarRocks 分群表，在此基礎(chǔ)上對(duì)外提供標(biāo)簽和分群服務(wù)，上層業(yè)務(wù)系統(tǒng)可據(jù)此構(gòu)建各種各樣的基于特定人群的功能。

數(shù)據(jù)運(yùn)營(yíng)平臺(tái)

• 較低延時(shí)：業(yè)務(wù)數(shù)據(jù)產(chǎn)生到可使用，以秒級(jí)延遲為主，分鐘級(jí)~小時(shí)級(jí)延遲為輔。
• 靈活使用：分析指標(biāo)多樣性，指標(biāo)由平臺(tái)使用人員根據(jù)明細(xì)自由拖拉組合產(chǎn)生。
• 大數(shù)據(jù)聚合和極速查詢：包含業(yè)務(wù)全生命周期數(shù)據(jù)，99th 查詢需要在 3s 以內(nèi)。

• 多種更新周期：同一數(shù)據(jù)表的不同字段的更新周期不同（有近實(shí)時(shí)、小時(shí)級(jí) T+1、天級(jí) T+1）。

• 物化視圖(MATERIALIZED VIEW)導(dǎo)致 Disk Storage 只增不減及查詢無(wú)法命中物化視圖

  文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-700163.html

StarRocks DWS 表由 DIM 表和 DWD 表關(guān)聯(lián)后得到，原設(shè)想 DWS 使用多表關(guān)聯(lián)建立 MATERIALIZED VIEW，同 Rollup 表一樣是可以在 DWS 中及時(shí)對(duì) DIM 和 DWD 的行級(jí)變更做出更新，在 StarRocks v2.4.3 版本驗(yàn)證使用過(guò)程中發(fā)現(xiàn) MATERIALIZED VIEW 底層實(shí)現(xiàn)為 insert overwrite，Disk I/O 耗時(shí)較大，實(shí)測(cè) 500w 的數(shù)據(jù)行大約需要 10s~15s，需要更新數(shù)據(jù)量的大小直接影響了數(shù)據(jù)的更新時(shí)效。

創(chuàng)建的 MATERIALIZED VIEW 會(huì)導(dǎo)致 Disk Storage 只增不減，反饋 StarRocks 社區(qū)后定位為 bug，后續(xù)已經(jīng)修復(fù)。

• 并行 Insert Load 導(dǎo)致 Mem 和 CPU 負(fù)載過(guò)高

由于物化視圖存在的問(wèn)題，DWS 層的產(chǎn)出受到限制。為了克服這個(gè)問(wèn)題，我們采用了與底層實(shí)現(xiàn)相同的 insert overwrite 方法，通過(guò)多個(gè)規(guī)則，包括分區(qū)規(guī)則和數(shù)據(jù)量規(guī)則，對(duì)數(shù)據(jù)進(jìn)行分片更新。為確保所有 DWS 層數(shù)據(jù)幾乎同時(shí)產(chǎn)出，我們?yōu)樗?DWS 表配置了相同的調(diào)度頻次和時(shí)間。在 DWS 更新過(guò)程中，曾出現(xiàn) CPU 和 MEM 過(guò)高的情況，但后來(lái)經(jīng)過(guò)優(yōu)化，我們采用了幾個(gè)優(yōu)先級(jí)隊(duì)列來(lái)串行更新，從而保持 CPU 和 MEM 的占用相對(duì)平穩(wěn)，最大限度地減少了資源熱點(diǎn)問(wèn)題。下圖顯示了資源占用在優(yōu)化前后的變化情況：

• Broker Load 和 Routine Load 監(jiān)控告警

StarRocks 提供的集群監(jiān)控指標(biāo)在 Broker Load 只有各個(gè)狀態(tài)的統(tǒng)計(jì)數(shù)量，而對(duì)于 load 失敗后欠缺及時(shí)告警機(jī)制。對(duì)此問(wèn)題我們制作了一些工具，基于 show load 和 show routine load 查詢當(dāng)前 Broker Load 和 Routine Load 的狀態(tài)信息，在 load 失敗后進(jìn)行重試、自動(dòng)拉起并發(fā)出通知告警。

Datasight 的 BI 數(shù)據(jù)應(yīng)用模塊，主要解決的是用戶看板需求、日常取數(shù)、分析、挖掘等場(chǎng)景。這些場(chǎng)景的數(shù)據(jù)有以下特點(diǎn)：數(shù)據(jù)變更頻繁、報(bào)表需要實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)更新和大規(guī)模查詢。

在 Datasight-BI 第一版的實(shí)現(xiàn)中，所有自主取數(shù)和數(shù)據(jù)集等需求，因用戶 SQL 變更頻繁，由于用戶 SQL 頻繁變更且為了解決查詢性能問(wèn)題，均通過(guò) Presto 直連查詢來(lái)完成。隨著平臺(tái)的擴(kuò)展，大量業(yè)務(wù)使用案例涉及到數(shù)據(jù)跨度較大且涉及多個(gè)大型維表的查詢，導(dǎo)致 Presto 查詢變得緩慢，查詢延遲可長(zhǎng)達(dá)數(shù)十秒甚至幾十秒，給 Presto 集群造成了巨大壓力。

經(jīng)過(guò)調(diào)研，考慮到業(yè)務(wù)在使用報(bào)表的過(guò)程中不同報(bào)表的查詢速度和更新頻率有所不同，我們最終決定選用 StarRocks 作為存儲(chǔ)引擎進(jìn)行改進(jìn)。改進(jìn)過(guò)程中，用戶在直接連接 Presto 的時(shí)候編寫(xiě) SQL 進(jìn)行即時(shí)查詢，確認(rèn)數(shù)據(jù)后創(chuàng)建抽取計(jì)劃。簡(jiǎn)言之，即將用戶通過(guò) Presto 查詢獲取的數(shù)據(jù)導(dǎo)入到 StarRocks。此后，用戶所有查詢都通過(guò)直接連接 StarRocks 進(jìn)行。通過(guò)這一改進(jìn)，整體報(bào)表的查詢速度得到了提升，同時(shí) Presto 總體查詢壓力得以減輕。

整車(chē)三電可靠性數(shù)據(jù)庫(kù)

可靠性是指產(chǎn)品在規(guī)定條件下和特定時(shí)間內(nèi)完成預(yù)定功能的能力或概率。產(chǎn)品的可靠性涵蓋了整個(gè)壽命周期的各個(gè)方面。我們的數(shù)據(jù)平臺(tái)會(huì)基于已有車(chē)輛的可靠性相關(guān)指標(biāo)數(shù)據(jù)，對(duì)整車(chē)零部件、EDS 電機(jī)核心零件上市后的可靠性進(jìn)行預(yù)估。這能夠揭示零件的過(guò)度設(shè)計(jì)或欠缺設(shè)計(jì)情況，為下一代車(chē)型和電驅(qū)動(dòng)系統(tǒng)的研發(fā)提供數(shù)據(jù)依據(jù)和支持。

可靠性指標(biāo)一般為月度指標(biāo)，涵蓋了多樣的維度，如車(chē)型、電機(jī)組合等（約 20 個(gè)維度）。這些指標(biāo)需要實(shí)時(shí)獲取，包括次數(shù)、持續(xù)時(shí)長(zhǎng)等統(tǒng)計(jì)度量。我們選擇 StarRocks 來(lái)存儲(chǔ)可靠性數(shù)據(jù)，目前 DWD 層的存量數(shù)據(jù)已達(dá)到數(shù)十億條，而每月新增數(shù)據(jù)達(dá)到億級(jí)。利用 StarRocks 強(qiáng)大的數(shù)據(jù)分析能力，我們能夠快速計(jì)算頻數(shù)、分位數(shù)等用戶所需的指標(biāo)。

鑒于可靠性精準(zhǔn)載荷指標(biāo)維度的多樣性，我們采用 StarRocks 聚合模型表，針對(duì)用戶頻繁查詢維度建立多個(gè)維度的 Rollup 索引。增加 Rollup 索引后，多指標(biāo)同時(shí)查詢計(jì)算速度可由 15 秒縮減至 2s 左右，性能提升了近 8 倍。下圖展示了集成 StarRocks 的可靠性數(shù)據(jù)庫(kù)系統(tǒng)架構(gòu)：

在表設(shè)計(jì)方面，由于可靠性數(shù)據(jù)庫(kù)涉及業(yè)務(wù)指標(biāo)較多且指標(biāo)來(lái)源頻繁更新（經(jīng)常增加新的零部件數(shù)據(jù)），同時(shí)歷史數(shù)據(jù)同步表時(shí)間較長(zhǎng)（每次需要同步幾年的歷史數(shù)據(jù)）等業(yè)務(wù)特點(diǎn)，如果將多個(gè)指標(biāo)存入一張表中，后期的可維護(hù)性較差，并且會(huì)影響用戶使用體驗(yàn)。因此，我們的可靠性數(shù)據(jù)庫(kù)在設(shè)計(jì)中將每個(gè)指標(biāo)都對(duì)應(yīng)一個(gè)表，而將公共數(shù)據(jù)單獨(dú)存儲(chǔ)在維度表中。這樣在灌歷史數(shù)據(jù)時(shí)就不會(huì)對(duì)其他的指標(biāo)數(shù)據(jù)造成影響了。

此外，對(duì)于一些 ID 數(shù)量的統(tǒng)計(jì)，如車(chē)輛 ID 的統(tǒng)計(jì)，由于其是聚合表的一個(gè)維度，直接使用 SELECT COUNT(DISTINCT id) 進(jìn)行統(tǒng)計(jì)仍可能導(dǎo)致全表掃描。此時(shí)可通過(guò)改寫(xiě) SQL，在計(jì)算聚合指標(biāo)值之前先對(duì)該 ID 進(jìn)行聚合操作，從而實(shí)現(xiàn)對(duì) Rollup 查詢的有效利用，可以一定程度上增加聚合查詢速度。

• 穩(wěn)定性：為保證生產(chǎn)集群的穩(wěn)定性，我們每個(gè)集群都部署三個(gè) FE 節(jié)點(diǎn)，以確保高可用性，避免因單點(diǎn)故障引起的問(wèn)題。
• 易運(yùn)維：集群所有 FE 和 BE 進(jìn)程都使用 system 進(jìn)行托管，并加入開(kāi)機(jī)自啟動(dòng)。

• 監(jiān)控告警：采用 Prometheus+Grafana 方案進(jìn)行監(jiān)控和告警，保證集群穩(wěn)定性

在過(guò)去關(guān)鍵版本升級(jí)時(shí)（如跨大版本升級(jí)），我們得到了 StarRocks 社區(qū)團(tuán)隊(duì)的大力支持。他們協(xié)助我們制定了詳盡的升級(jí)計(jì)劃，而且在我們?yōu)榱俗钚』瘜?duì)業(yè)務(wù)的影響而選擇在半夜進(jìn)行升級(jí)時(shí)，社區(qū)的技術(shù)支持同學(xué)也為我們提供了遠(yuǎn)程協(xié)助，在這里特別表示感謝。

• 內(nèi)存泄漏問(wèn)題

在集群版本升級(jí)到 2.5.5 之后，業(yè)務(wù)方上線了一些作業(yè)，每天凌晨 0:00 到 4:00 左右集群經(jīng)常有任務(wù)報(bào)錯(cuò)使用內(nèi)存超限制。具體錯(cuò)誤如下：

通過(guò)監(jiān)控?cái)?shù)據(jù)的分析，我們注意到 Backend 的內(nèi)存使用率會(huì)在達(dá)到 100GB 后突然出現(xiàn)下降。初期我們猜測(cè)這可能是由于內(nèi)存資源不足導(dǎo)致任務(wù)失敗，然而在進(jìn)行了擴(kuò)容后，內(nèi)存使用依然呈直線上升的趨勢(shì)，而且即便在進(jìn)行了一天的擴(kuò)容之后，仍然出現(xiàn)了內(nèi)存不足的情況?；谶@些情況，我們開(kāi)始懷疑系統(tǒng)存在內(nèi)存泄漏的問(wèn)題。

根據(jù)系統(tǒng)的內(nèi)存使用，也發(fā)現(xiàn)將近 50GB 的內(nèi)存不知所蹤，具體如下圖所示：

后來(lái)查詢社區(qū)論壇，看到社區(qū)有人說(shuō)2.5.4版本之后有內(nèi)存泄漏問(wèn)題，和我們的情況很類(lèi)似 [1]，經(jīng)過(guò)多方確認(rèn)之后，我們升級(jí)到最新的版本解決了該問(wèn)題。

• Delete 操作未生效

業(yè)務(wù)同學(xué)反饋 FlinkSQL 同步 Kafka 的數(shù)據(jù)到 StarRocks 的時(shí)候遇到了一個(gè)問(wèn)題。Kafka 的存儲(chǔ)格式是 debezium-json，在某些情況下，當(dāng)數(shù)據(jù)的操作類(lèi)型（op）為 delete 時(shí)，StarRocks 未能正確地將該數(shù)據(jù)刪除。這問(wèn)題表現(xiàn)為似乎 delete 操作沒(méi)有生效。舉例來(lái)說(shuō)，對(duì)于同一個(gè)主鍵 id，print 輸出顯示一條insert 和一條 delete 的操作，但在將數(shù)據(jù)寫(xiě)入 StarRocks 后，該條數(shù)據(jù)仍然存在。后來(lái)經(jīng)過(guò)和 StarRocks 的專(zhuān)家溝通之后，確認(rèn)了這個(gè)問(wèn)題。相關(guān) PR 已合入 2.5.9 版本[2]。

• 集群擴(kuò)容后的數(shù)據(jù)均衡

當(dāng)集群 BE 擴(kuò)容后，由于當(dāng)前集群 tablet 數(shù)量比較多，都是通過(guò)副本在各個(gè) BE 之間拷貝完成的。如果同一臺(tái) BE 同一時(shí)間執(zhí)行過(guò)多的任務(wù)，則會(huì)帶來(lái)較大的 I/O 壓力。因此，StarRocks 在調(diào)度時(shí)控制了每個(gè)節(jié)點(diǎn)上能夠執(zhí)行的任務(wù)數(shù)目。最小的資源控制單位是磁盤(pán)（即在 be.conf 中指定的一個(gè)數(shù)據(jù)路徑）。StarRocks 默認(rèn)為每塊磁盤(pán)配置兩個(gè) slot 用于副本修復(fù)。一個(gè) clone 任務(wù)會(huì)占用源端和目的端各一個(gè) slot。如果 slot 數(shù)目為零，則不會(huì)再對(duì)這塊磁盤(pán)分配任務(wù)。該 slot 個(gè)數(shù)可以通過(guò) FE 的 tablet_sched_slot_num_per_path 參數(shù)動(dòng)態(tài)配置。

因?yàn)?StarRocks 的架構(gòu)簡(jiǎn)單清晰，天然具有易運(yùn)維的性質(zhì)。經(jīng)過(guò)多版本的更新升級(jí)后，當(dāng)前版本集群已經(jīng)十分穩(wěn)定，在未來(lái)的運(yùn)維工作中我們會(huì)針對(duì)集群資源隔離和查詢隊(duì)列做進(jìn)一步的探索，限制查詢對(duì)資源的消耗，防止單一用戶，或者單一大查詢占用集群過(guò)多資源和影響其他租戶的正常使用，從而實(shí)現(xiàn)多租戶之間的資源隔離與合理利用，增加集群可用性和穩(wěn)定性。

未來(lái)規(guī)劃

• 大數(shù)據(jù)元數(shù)據(jù)管理和 Iceberg 數(shù)據(jù)湖整合：我們計(jì)劃將多個(gè) StarRocks 集群接入大數(shù)據(jù)元數(shù)據(jù)管理系統(tǒng)，并和 Iceberg 數(shù)據(jù)湖進(jìn)行打通，為構(gòu)建基于元數(shù)據(jù)的統(tǒng)一數(shù)據(jù)查詢分析平臺(tái)奠定基礎(chǔ)。
• 存算分離和成本優(yōu)化：我們計(jì)劃嘗試使用 StarRocks 3.x 版本的存算分離架構(gòu)，把海量車(chē)聯(lián)網(wǎng)明細(xì)數(shù)據(jù)放到騰訊云對(duì)象存儲(chǔ)上，從而降低海量車(chē)聯(lián)網(wǎng)數(shù)據(jù)的存儲(chǔ)成本。
• 資源隔離和多租戶管控：啟用資源隔離功能，進(jìn)行更好的多租戶資源管控和審計(jì)，以保證高優(yōu)租戶讀寫(xiě)穩(wěn)定性。

• 擴(kuò)展云服務(wù)支持：我們希望 StarRocks 能夠支持更多的公有云服務(wù)，如騰訊云和亞馬遜 AWS，并期待能推出 serverless 云服務(wù)。這將有助于未來(lái)的遷移工作，顯著降低數(shù)據(jù)團(tuán)隊(duì)在 StarRocks 運(yùn)維方面的成本。
• 權(quán)限管理增強(qiáng)：支持更細(xì)粒度的權(quán)限管理（行級(jí)別、列級(jí)別權(quán)限），可以和 Ranger 權(quán)限系統(tǒng)打通。
• 流式讀取和物化視圖更新：支持 Flink 流式數(shù)據(jù)讀取（row level 數(shù)據(jù)行變更）；支持流式物化視圖，能根據(jù)上游依賴表的 row level 級(jí)變更自動(dòng)更新物化視圖。

• 復(fù)雜嵌套類(lèi)型支持：在內(nèi)置原生 OLAP 引擎中支持 Struct 和 Map 等復(fù)雜嵌套類(lèi)型 (已在 3.1 支持)。

在引入 StarRocks 后，我們團(tuán)隊(duì)除了積極向社區(qū)反饋問(wèn)題外，也向官方貢獻(xiàn)了一些代碼。到目前為止，我們提交的 PR 有包含比特位運(yùn)算函數(shù)支持和 StarRocks Spark Connector 寫(xiě)數(shù)據(jù) bug 修復(fù)等。后續(xù)我們也會(huì)積極參與開(kāi)源社區(qū)，貢獻(xiàn)我們的一份心力。我們對(duì)于 StarRocks 小伙伴們一直以來(lái)所提供的支持和協(xié)助表示感激，同時(shí)也祝愿 StarRocks 開(kāi)源社區(qū)能夠繼續(xù)取得更大的成就！

關(guān)于 StarRocks 

•     

到了這里，關(guān)于駛向高效運(yùn)營(yíng)，StarRocks 助力蔚來(lái)汽車(chē)數(shù)據(jù)分析再升級(jí)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！