1. 為什么我們需要認(rèn)真聊聊OLAP數(shù)據(jù)分析這個(gè)行當(dāng)里OLAP是個(gè)繞不開(kāi)的詞。你去看任何一款數(shù)據(jù)產(chǎn)品的介紹十有八九會(huì)提到“支持OLAP分析”“OLAP引擎”“實(shí)時(shí)OLAP”之類的字眼。但真要讓人用一句話說(shuō)清楚OLAP到底是什么很多人會(huì)卡殼。我自己剛?cè)胄心菚?huì)兒也一樣面試被問(wèn)到“說(shuō)說(shuō)你對(duì)OLAP的理解”腦子里第一反應(yīng)就是“聯(lián)機(jī)分析處理”這六個(gè)字然后呢然后就沒(méi)有然后了。這篇文章我想把OLAP這件事從頭到尾捋一遍。不光是概念定義更重要的是它為什么存在、它和OLTP到底差在哪里、底層是怎么實(shí)現(xiàn)的、市面上那些五花八門(mén)的OLAP引擎各自適合什么場(chǎng)景、以及在實(shí)際項(xiàng)目中怎么選型、怎么避坑。如果你是一個(gè)數(shù)據(jù)工程師、數(shù)據(jù)分析師、后端開(kāi)發(fā)或者只是單純想搞明白“為什么查個(gè)報(bào)表有時(shí)候快有時(shí)候慢”這篇內(nèi)容應(yīng)該都能給你一些實(shí)在的參考。我盡量不說(shuō)廢話用從業(yè)者之間聊天的口吻來(lái)寫(xiě)。有些地方會(huì)涉及比較底層的原理我會(huì)盡量用生活化的類比來(lái)解釋有些地方會(huì)涉及具體的參數(shù)和配置我會(huì)把計(jì)算過(guò)程和選擇理由都寫(xiě)清楚。整篇內(nèi)容會(huì)比較長(zhǎng)建議你找個(gè)安靜的時(shí)間慢慢看或者收藏起來(lái)當(dāng)參考手冊(cè)用。2. OLAP到底是什么從一次慢查詢說(shuō)起2.1 一個(gè)真實(shí)場(chǎng)景引發(fā)的思考假設(shè)你在一家電商公司做數(shù)據(jù)開(kāi)發(fā)。某天運(yùn)營(yíng)同事跑過(guò)來(lái)跟你說(shuō)“我想看一下過(guò)去三年每個(gè)品類在每個(gè)省份的月度銷售額趨勢(shì)順便按同比環(huán)比排個(gè)序?！蹦愦蜷_(kāi)數(shù)據(jù)庫(kù)寫(xiě)了一條SQL涉及三張表關(guān)聯(lián)加上GROUP BY、ORDER BY、窗口函數(shù)然后點(diǎn)擊執(zhí)行。接下來(lái)發(fā)生的事情取決于你用的什么數(shù)據(jù)庫(kù)如果是一套典型的事務(wù)型數(shù)據(jù)庫(kù)這條查詢可能跑了十幾分鐘還沒(méi)出結(jié)果甚至直接把數(shù)據(jù)庫(kù)拖垮影響到線上交易。這個(gè)場(chǎng)景就是OLAP要解決的核心問(wèn)題。OLAP的全稱是Online Analytical Processing中文叫聯(lián)機(jī)分析處理。它和OLTP聯(lián)機(jī)事務(wù)處理是兩種截然不同的數(shù)據(jù)處理模式。OLTP關(guān)心的是“把一筆交易準(zhǔn)確地記下來(lái)”比如用戶下單、支付、修改地址OLAP關(guān)心的是“從海量歷史數(shù)據(jù)里挖出規(guī)律和趨勢(shì)”比如上面那個(gè)運(yùn)營(yíng)同事的需求。你可以這樣理解OLTP像是超市的收銀臺(tái)每一筆交易都要快速、準(zhǔn)確地完成不能出錯(cuò)OLAP像是超市總部的分析師拿著過(guò)去幾年的銷售小票試圖找出“哪個(gè)品類的紙巾在哪個(gè)季節(jié)賣得最好”。兩者的目標(biāo)不同所以底層的數(shù)據(jù)組織方式、存儲(chǔ)結(jié)構(gòu)、查詢優(yōu)化策略也完全不同。2.2 OLAP和OLTP的核心差異很多人會(huì)把這兩個(gè)概念混淆或者只是模糊地知道“一個(gè)管交易一個(gè)管分析”。我把它們的關(guān)鍵差異整理成一張表方便你對(duì)照理解。對(duì)比維度OLTP聯(lián)機(jī)事務(wù)處理OLAP聯(lián)機(jī)分析處理核心目標(biāo)快速、準(zhǔn)確地處理單條或少量記錄從大量數(shù)據(jù)中聚合、分析、挖掘規(guī)律典型操作INSERT、UPDATE、DELETE、點(diǎn)查SELECT GROUP BY、JOIN、窗口函數(shù)數(shù)據(jù)量級(jí)單次操作涉及少量行單次查詢掃描百萬(wàn)到百億行響應(yīng)時(shí)間毫秒級(jí)秒級(jí)到分鐘級(jí)視引擎而定數(shù)據(jù)時(shí)效當(dāng)前最新?tīng)顟B(tài)歷史快照、時(shí)間序列并發(fā)量高并發(fā)、短連接低并發(fā)、長(zhǎng)查詢存儲(chǔ)方式行式存儲(chǔ)為主列式存儲(chǔ)為主索引策略B樹(shù)、哈希索引分區(qū)、排序鍵、位圖索引、Zone Map典型產(chǎn)品MySQL、PostgreSQL、OracleClickHouse、Doris、StarRocks、Presto這張表里的每一行都值得展開(kāi)說(shuō)但我先挑最核心的一點(diǎn)行式存儲(chǔ)和列式存儲(chǔ)的區(qū)別。這是OLAP性能優(yōu)勢(shì)的根基。2.3 行存和列存為什么OLAP快得起來(lái)假設(shè)有一張用戶訂單表包含訂單ID、用戶ID、商品名稱、品類、金額、下單時(shí)間、省份這幾個(gè)字段。如果按行存儲(chǔ)每一行的數(shù)據(jù)在磁盤(pán)上是連續(xù)存放的就像Excel表格一樣一行一行往下排。這種存儲(chǔ)方式對(duì)OLTP非常友好因?yàn)槟阋椤坝唵蜪D為12345的詳情”只需要定位到那一行把整行數(shù)據(jù)讀出來(lái)就行。但OLAP的查詢往往是這樣的“統(tǒng)計(jì)每個(gè)省份的總銷售額”。這個(gè)查詢只需要用到“省份”和“金額”兩列其他字段完全不需要。如果是行式存儲(chǔ)數(shù)據(jù)庫(kù)不得不把每一行的所有字段都讀出來(lái)然后再丟棄不需要的列。這就好比你要從一本書(shū)里找所有提到“北京”的句子但每次都得把整頁(yè)紙復(fù)印一遍才能看。列式存儲(chǔ)則完全不同。它把每一列的數(shù)據(jù)單獨(dú)存放在一起省份列的所有值連續(xù)排列金額列的所有值連續(xù)排列。當(dāng)查詢只需要省份和金額時(shí)數(shù)據(jù)庫(kù)只讀取這兩列的數(shù)據(jù)其他列碰都不碰。I/O量可能只有行式存儲(chǔ)的十分之一甚至更少。而且同一列的數(shù)據(jù)類型相同壓縮效率極高進(jìn)一步減少了磁盤(pán)讀取量。注意列式存儲(chǔ)并不是銀彈。如果你的查詢模式是“查某一條記錄的完整信息”列存的性能反而不如行存因?yàn)樾枰逊稚⒃诟髁械臄?shù)據(jù)重新拼成一行。所以O(shè)LAP引擎通常不擅長(zhǎng)點(diǎn)查這是設(shè)計(jì)上的取舍。3. OLAP的技術(shù)演進(jìn)從MOLAP到現(xiàn)代湖倉(cāng)3.1 三代OLAP技術(shù)的核心思路OLAP這個(gè)概念從上世紀(jì)九十年代被正式提出到現(xiàn)在經(jīng)歷了幾個(gè)明顯的技術(shù)階段。每個(gè)階段都在解決前一代的痛點(diǎn)同時(shí)也在新的場(chǎng)景下暴露出新的問(wèn)題。第一代MOLAP多維OLAP。核心思路是預(yù)計(jì)算。系統(tǒng)提前把各種可能的維度組合和聚合結(jié)果算好存成一個(gè)多維數(shù)據(jù)立方體Data Cube。查詢的時(shí)候直接從這個(gè)立方體里取數(shù)速度極快。但問(wèn)題也很明顯維度一多立方體的體積會(huì)爆炸式增長(zhǎng)。比如10個(gè)維度、每個(gè)維度10個(gè)值理論上的組合數(shù)就是10的10次方根本存不下。而且數(shù)據(jù)更新后需要重新構(gòu)建立方體時(shí)效性差。第二代ROLAP關(guān)系型OLAP。不再預(yù)計(jì)算所有組合而是把數(shù)據(jù)存在關(guān)系型數(shù)據(jù)庫(kù)里查詢時(shí)通過(guò)SQL動(dòng)態(tài)聚合。靈活性大大提升但性能依賴底層數(shù)據(jù)庫(kù)的優(yōu)化能力。早期很多ROLAP方案就是在MySQL或Oracle上硬扛數(shù)據(jù)量一大就撐不住了。第三代現(xiàn)代列式OLAP引擎。以ClickHouse、Doris、StarRocks為代表結(jié)合了列式存儲(chǔ)、向量化執(zhí)行、MPP架構(gòu)、智能索引等技術(shù)在靈活性和性能之間找到了更好的平衡。這也是目前大多數(shù)互聯(lián)網(wǎng)公司的首選方案。3.2 現(xiàn)代OLAP引擎的四大核心技術(shù)要理解現(xiàn)代OLAP為什么能做到“億級(jí)數(shù)據(jù)秒級(jí)響應(yīng)”需要搞明白四個(gè)關(guān)鍵技術(shù)。我用做菜來(lái)打個(gè)比方列式存儲(chǔ)是食材預(yù)處理向量化執(zhí)行是批量烹飪MPP是多個(gè)廚師同時(shí)開(kāi)工智能索引是提前備好的調(diào)料包。列式存儲(chǔ)前面已經(jīng)講過(guò)了核心價(jià)值在于減少I(mǎi)/O和提升壓縮率。這里補(bǔ)充一個(gè)數(shù)據(jù)在實(shí)際業(yè)務(wù)場(chǎng)景中列式存儲(chǔ)的壓縮比通常能達(dá)到5:1到20:1意味著原本需要1TB存儲(chǔ)的數(shù)據(jù)壓縮后可能只需要50GB到200GB。這不僅省磁盤(pán)更重要的是減少了查詢時(shí)需要讀取的數(shù)據(jù)量。向量化執(zhí)行是指CPU一次處理一批數(shù)據(jù)而不是一行一行地處理。傳統(tǒng)的火山模型Volcano Model每次只處理一行函數(shù)調(diào)用開(kāi)銷大CPU緩存命中率低。向量化執(zhí)行把數(shù)據(jù)按批比如1024行加載到CPU緩存中用SIMD指令并行計(jì)算性能可以提升幾倍到幾十倍。你可以理解為以前是一個(gè)一個(gè)搬磚現(xiàn)在是用傳送帶一次搬一堆。MPP架構(gòu)Massively Parallel Processing是指把一個(gè)大查詢拆成多個(gè)子任務(wù)分發(fā)到多臺(tái)機(jī)器上并行執(zhí)行最后匯總結(jié)果。比如要統(tǒng)計(jì)10億行數(shù)據(jù)的銷售額單機(jī)可能需要幾十秒但如果分成100個(gè)分片每臺(tái)機(jī)器只處理1000萬(wàn)行理論上1秒就能完成。當(dāng)然實(shí)際會(huì)有網(wǎng)絡(luò)傳輸和結(jié)果合并的開(kāi)銷但整體加速比仍然非?？捎^。智能索引包括Zone Map、Bitmap索引、Bloom Filter等。Zone Map記錄每個(gè)數(shù)據(jù)塊中某列的最小值和最大值查詢時(shí)如果條件不在這個(gè)范圍內(nèi)直接跳過(guò)整個(gè)數(shù)據(jù)塊。Bitmap索引適合低基數(shù)列比如性別、省份可以快速做交并集運(yùn)算。Bloom Filter用于快速判斷某個(gè)值是否存在于某個(gè)數(shù)據(jù)塊中避免不必要的讀取。3.3 從數(shù)據(jù)倉(cāng)庫(kù)到湖倉(cāng)一體OLAP引擎的演進(jìn)還伴隨著數(shù)據(jù)架構(gòu)的變遷。早期大家用數(shù)據(jù)倉(cāng)庫(kù)Data Warehouse數(shù)據(jù)經(jīng)過(guò)ETL清洗后加載到倉(cāng)庫(kù)里再在倉(cāng)庫(kù)上做OLAP分析。后來(lái)數(shù)據(jù)湖Data Lake興起原始數(shù)據(jù)直接存到HDFS或?qū)ο蟠鎯?chǔ)上靈活但查詢性能差?，F(xiàn)在的趨勢(shì)是湖倉(cāng)一體Lakehouse在數(shù)據(jù)湖上直接構(gòu)建OLAP能力兼顧靈活性和性能。這個(gè)演進(jìn)對(duì)OLAP引擎提出了新的要求不僅要查得快還要能直接訪問(wèn)湖上的開(kāi)放格式如Parquet、ORC、Iceberg支持Schema演進(jìn)支持事務(wù)一致性。Doris和StarRocks在這方面做得比較靠前ClickHouse也在通過(guò)外部表的方式逐步補(bǔ)齊。4. 主流OLAP引擎選型沒(méi)有最好只有最合適4.1 選型前必須想清楚的五個(gè)問(wèn)題每次有人問(wèn)我“哪個(gè)OLAP引擎最好”我都會(huì)先反問(wèn)五個(gè)問(wèn)題。這五個(gè)問(wèn)題的答案基本能決定選型方向。第一數(shù)據(jù)量有多大是千萬(wàn)級(jí)、億級(jí)還是百億級(jí)不同引擎在數(shù)據(jù)量上的表現(xiàn)差異很大。ClickHouse在單表億級(jí)到百億級(jí)場(chǎng)景下性能極強(qiáng)但JOIN能力相對(duì)弱Doris和StarRocks在中等數(shù)據(jù)量下表現(xiàn)均衡JOIN支持更好。第二查詢模式是什么是固定的報(bào)表查詢還是靈活的自助分析固定報(bào)表可以用預(yù)計(jì)算加速靈活分析則需要引擎有強(qiáng)大的即席查詢能力。Presto/Trino在即席查詢上很擅長(zhǎng)但延遲通常比ClickHouse高。第三數(shù)據(jù)實(shí)時(shí)性要求多高是T1就夠了還是需要秒級(jí)可見(jiàn)ClickHouse和Doris都支持實(shí)時(shí)寫(xiě)入但Doris的實(shí)時(shí)更新能力更強(qiáng)適合需要頻繁UPSERT的場(chǎng)景。第四團(tuán)隊(duì)技術(shù)棧是什么如果團(tuán)隊(duì)已經(jīng)重度使用Hadoop生態(tài)Presto/Trino或Hive on Spark可能更順手如果團(tuán)隊(duì)偏Java技術(shù)棧Doris和StarRocks的運(yùn)維成本更低。第五運(yùn)維成本能接受多少ClickHouse的運(yùn)維相對(duì)復(fù)雜集群擴(kuò)縮容、數(shù)據(jù)重分布需要人工介入較多Doris和StarRocks在運(yùn)維自動(dòng)化上做得更好但資源消耗也更高。4.2 主流引擎對(duì)比與適用場(chǎng)景我把目前市面上最常用的幾款OLAP引擎整理成一張對(duì)比表方便你快速定位。引擎核心優(yōu)勢(shì)主要短板典型適用場(chǎng)景ClickHouse單表查詢極快、壓縮率高、成本低JOIN弱、UPDATE/DELETE弱、運(yùn)維復(fù)雜日志分析、用戶行為分析、寬表聚合Apache Doris實(shí)時(shí)更新強(qiáng)、JOIN好、運(yùn)維簡(jiǎn)單極致性能略遜于ClickHouse實(shí)時(shí)報(bào)表、數(shù)據(jù)看板、多維分析StarRocks性能均衡、物化視圖強(qiáng)、湖倉(cāng)能力好社區(qū)相對(duì)Doris略小湖倉(cāng)一體、實(shí)時(shí)分析、高并發(fā)查詢Presto/Trino聯(lián)邦查詢強(qiáng)、即席查詢靈活延遲較高、內(nèi)存消耗大跨源即席分析、Ad-hoc查詢Apache Kylin預(yù)計(jì)算能力強(qiáng)、查詢極快靈活性差、Cube膨脹固定維度組合的報(bào)表Druid時(shí)序數(shù)據(jù)強(qiáng)、實(shí)時(shí)攝入好JOIN弱、SQL支持有限監(jiān)控指標(biāo)、時(shí)序分析這張表只是一個(gè)大致的參考實(shí)際選型還要結(jié)合具體業(yè)務(wù)。我見(jiàn)過(guò)不少團(tuán)隊(duì)一開(kāi)始選了ClickHouse后來(lái)因?yàn)镴OIN需求越來(lái)越多不得不遷移到Doris或StarRocks。也見(jiàn)過(guò)團(tuán)隊(duì)用Doris做日志分析發(fā)現(xiàn)單表聚合性能不如ClickHouse又加了一套ClickHouse專門(mén)做日志。沒(méi)有哪個(gè)引擎能通吃所有場(chǎng)景混合架構(gòu)往往是更務(wù)實(shí)的選擇。4.3 選型時(shí)容易踩的三個(gè)坑第一個(gè)坑是只看Benchmark不看業(yè)務(wù)。網(wǎng)上有很多TPC-H、TPC-DS的跑分對(duì)比但那些測(cè)試場(chǎng)景和你的實(shí)際業(yè)務(wù)可能差很遠(yuǎn)。比如你的查詢都是寬表聚合ClickHouse可能碾壓其他引擎但如果你的查詢涉及多表JOINClickHouse可能直接OOM。選型前一定要用自己的真實(shí)數(shù)據(jù)和查詢跑一遍。第二個(gè)坑是低估運(yùn)維成本。有些引擎在測(cè)試環(huán)境跑得很好上了生產(chǎn)才發(fā)現(xiàn)擴(kuò)縮容、數(shù)據(jù)均衡、故障恢復(fù)都很麻煩。ClickHouse的分布式表需要手動(dòng)管理分片和副本Doris和StarRocks在這方面自動(dòng)化程度更高。如果團(tuán)隊(duì)沒(méi)有專職的DBA建議優(yōu)先考慮運(yùn)維友好的方案。第三個(gè)坑是忽視數(shù)據(jù)更新需求。很多OLAP引擎擅長(zhǎng)批量導(dǎo)入但不擅長(zhǎng)頻繁更新。如果你的業(yè)務(wù)需要實(shí)時(shí)UPSERT比如訂單狀態(tài)變更一定要選支持主鍵模型的引擎。Doris的Unique Key模型和StarRocks的主鍵模型在這方面表現(xiàn)較好ClickHouse的ReplacingMergeTree雖然也能做但查詢時(shí)需要額外處理。5. OLAP實(shí)操?gòu)慕ū淼讲樵儍?yōu)化的完整流程5.1 建表分區(qū)、分桶與排序鍵的設(shè)計(jì)建表是OLAP使用的第一步也是最容易埋坑的一步。以Doris為例建表時(shí)需要重點(diǎn)考慮三個(gè)設(shè)計(jì)分區(qū)Partition、分桶Bucket和排序鍵Sort Key。分區(qū)通常按時(shí)間字段來(lái)做比如按天或按月分區(qū)。這樣做的好處是查詢時(shí)可以分區(qū)裁剪只掃描相關(guān)時(shí)間段的數(shù)據(jù)。比如查詢“最近7天”的數(shù)據(jù)如果按天分區(qū)引擎只需要掃描7個(gè)分區(qū)而不是全表。分區(qū)的粒度需要根據(jù)數(shù)據(jù)量和查詢模式來(lái)定數(shù)據(jù)量大、查詢頻繁按天過(guò)濾就按天分區(qū)數(shù)據(jù)量小、查詢按月過(guò)濾就按月分區(qū)。分桶是把每個(gè)分區(qū)內(nèi)的數(shù)據(jù)進(jìn)一步切分到不同的桶里每個(gè)桶是一個(gè)獨(dú)立的物理文件。分桶鍵的選擇很關(guān)鍵要選高基數(shù)的列比如用戶ID并且是查詢中常用的JOIN鍵或過(guò)濾鍵。分桶數(shù)建議是機(jī)器數(shù)的整數(shù)倍這樣數(shù)據(jù)分布更均勻。如果分桶數(shù)太少單個(gè)桶太大查詢并行度不夠如果分桶數(shù)太多小文件過(guò)多元數(shù)據(jù)管理開(kāi)銷大。排序鍵決定了數(shù)據(jù)在桶內(nèi)的物理排序順序。查詢時(shí)如果過(guò)濾條件命中了排序鍵的前綴可以快速定位到數(shù)據(jù)塊減少掃描量。排序鍵的設(shè)計(jì)原則是把最常用的過(guò)濾字段放在前面基數(shù)高的字段放在后面。比如查詢經(jīng)常按“省份城市”過(guò)濾排序鍵就設(shè)為省份城市。-- Doris建表示例 CREATE TABLE sales_analysis ( order_date DATE, province VARCHAR(50), city VARCHAR(50), category VARCHAR(50), sales_amount DECIMAL(18,2), order_count INT ) ENGINEOLAP DUPLICATE KEY(order_date, province, city) PARTITION BY RANGE(order_date) ( PARTITION p202401 VALUES [(2024-01-01), (2024-02-01)), PARTITION p202402 VALUES [(2024-02-01), (2024-03-01)) ) DISTRIBUTED BY HASH(province) BUCKETS 32 PROPERTIES ( replication_num 3, storage_medium SSD );提示分桶數(shù)不是越多越好。一般建議單個(gè)桶的數(shù)據(jù)量在1GB到10GB之間。如果單個(gè)桶太小比如只有幾十MB元數(shù)據(jù)和調(diào)度開(kāi)銷會(huì)占比過(guò)高如果單個(gè)桶太大比如超過(guò)50GB查詢并行度不夠性能會(huì)下降。5.2 數(shù)據(jù)導(dǎo)入批量與實(shí)時(shí)的取舍OLAP引擎的數(shù)據(jù)導(dǎo)入方式主要分兩種批量導(dǎo)入和實(shí)時(shí)導(dǎo)入。批量導(dǎo)入適合T1的離線場(chǎng)景通常從Hive、Spark或?qū)ο蟠鎯?chǔ)中一次性加載大量數(shù)據(jù)。實(shí)時(shí)導(dǎo)入適合需要秒級(jí)可見(jiàn)的場(chǎng)景通常從消息隊(duì)列如Kafka中持續(xù)消費(fèi)數(shù)據(jù)。以Doris為例批量導(dǎo)入常用Broker Load或Spark Load實(shí)時(shí)導(dǎo)入常用Routine Load或Flink Connector。Broker Load適合從HDFS或S3導(dǎo)入大文件吞吐量高Routine Load適合從Kafka持續(xù)消費(fèi)延遲低但吞吐量受限于消息隊(duì)列的分區(qū)數(shù)。導(dǎo)入過(guò)程中最容易遇到的問(wèn)題是兩個(gè)數(shù)據(jù)傾斜和版本沖突。數(shù)據(jù)傾斜是指某些分桶的數(shù)據(jù)量遠(yuǎn)大于其他分桶導(dǎo)致部分節(jié)點(diǎn)成為瓶頸。解決方法是在導(dǎo)入前對(duì)分桶鍵做預(yù)處理或者在導(dǎo)入時(shí)設(shè)置更高的并行度。版本沖突是指并發(fā)導(dǎo)入時(shí)同一批次的數(shù)據(jù)被多次寫(xiě)入導(dǎo)致查詢結(jié)果重復(fù)。解決方法是在導(dǎo)入時(shí)指定唯一的Label引擎會(huì)自動(dòng)去重。5.3 查詢優(yōu)化從執(zhí)行計(jì)劃到物化視圖查詢優(yōu)化是OLAP使用中最考驗(yàn)功力的環(huán)節(jié)。同樣一條SQL寫(xiě)法不同性能可能差幾十倍。我總結(jié)了幾條最實(shí)用的優(yōu)化原則。第一盡量用分區(qū)裁剪。查詢條件里一定要帶上分區(qū)字段否則引擎會(huì)掃描全表。比如查詢“2024年1月的銷售額”WHERE條件里必須寫(xiě)order_date 2024-01-01 AND order_date 2024-02-01而不是只寫(xiě)month 1。**第二避免SELECT ***。列式存儲(chǔ)的優(yōu)勢(shì)是按需讀取如果寫(xiě)了SELECT *引擎需要讀取所有列I/O量大幅增加。只選需要的列性能提升立竿見(jiàn)影。第三JOIN時(shí)把小表放在右邊。大多數(shù)OLAP引擎的JOIN實(shí)現(xiàn)是“右表廣播”把小表廣播到所有節(jié)點(diǎn)大表留在本地掃描。如果寫(xiě)反了大表被廣播網(wǎng)絡(luò)傳輸會(huì)成為瓶頸。第四善用物化視圖。物化視圖是預(yù)計(jì)算的聚合結(jié)果查詢時(shí)如果命中物化視圖可以直接返回結(jié)果無(wú)需掃描原始數(shù)據(jù)。Doris和StarRocks都支持自動(dòng)物化視圖改寫(xiě)建好物化視圖后優(yōu)化器會(huì)自動(dòng)判斷是否可以使用。-- 創(chuàng)建物化視圖示例 CREATE MATERIALIZED VIEW mv_sales_by_province AS SELECT province, category, DATE_TRUNC(order_date, month) AS month, SUM(sales_amount) AS total_sales, COUNT(*) AS order_count FROM sales_analysis GROUP BY province, category, DATE_TRUNC(order_date, month);注意物化視圖不是越多越好。每個(gè)物化視圖都會(huì)占用存儲(chǔ)空間并且在數(shù)據(jù)導(dǎo)入時(shí)需要同步更新。如果物化視圖過(guò)多導(dǎo)入性能會(huì)明顯下降。建議只為最核心、最頻繁的查詢創(chuàng)建物化視圖。5.4 資源管理與并發(fā)控制OLAP引擎通常支持多租戶和資源隔離。以Doris為例可以通過(guò)Resource Group把不同的查詢分配到不同的資源組限制CPU和內(nèi)存使用。這樣可以避免一個(gè)大查詢把整個(gè)集群的資源耗盡影響其他業(yè)務(wù)。并發(fā)控制方面大多數(shù)引擎支持查詢隊(duì)列和并發(fā)上限。如果并發(fā)查詢數(shù)超過(guò)閾值新的查詢會(huì)排隊(duì)等待而不是直接失敗。隊(duì)列的長(zhǎng)度和超時(shí)時(shí)間需要根據(jù)業(yè)務(wù)容忍度來(lái)設(shè)置。對(duì)于延遲敏感的報(bào)表查詢可以設(shè)置較高的優(yōu)先級(jí)對(duì)于后臺(tái)的ETL查詢可以設(shè)置較低的優(yōu)先級(jí)。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 查詢變慢的五大原因與排查路徑在實(shí)際運(yùn)維中查詢變慢是最常見(jiàn)的問(wèn)題。我整理了一個(gè)排查路徑按優(yōu)先級(jí)從高到低排列。排查項(xiàng)可能原因排查方法解決方案分區(qū)裁剪失效WHERE條件未命中分區(qū)字段查看執(zhí)行計(jì)劃中的分區(qū)掃描范圍修改SQL補(bǔ)上分區(qū)過(guò)濾條件數(shù)據(jù)傾斜分桶鍵分布不均查看各節(jié)點(diǎn)掃描行數(shù)和耗時(shí)調(diào)整分桶鍵或增加分桶數(shù)小文件過(guò)多頻繁導(dǎo)入導(dǎo)致碎片查看分區(qū)下的文件數(shù)量執(zhí)行Compaction合并小文件內(nèi)存不足大JOIN或大聚合查看查詢內(nèi)存使用峰值優(yōu)化SQL或增加內(nèi)存限制并發(fā)過(guò)高同時(shí)運(yùn)行的查詢太多查看當(dāng)前運(yùn)行查詢數(shù)和隊(duì)列長(zhǎng)度增加資源組或限制并發(fā)這個(gè)表格里的每一項(xiàng)我都實(shí)際遇到過(guò)。最隱蔽的是數(shù)據(jù)傾斜因?yàn)椴樵儽旧砜赡懿粓?bào)錯(cuò)只是慢。有一次我們一個(gè)查詢跑了半小時(shí)最后發(fā)現(xiàn)是某個(gè)省份的數(shù)據(jù)量是其他省份的100倍導(dǎo)致那個(gè)分桶的節(jié)點(diǎn)成了瓶頸。后來(lái)把分桶鍵從省份改成用戶ID問(wèn)題就解決了。6.2 數(shù)據(jù)導(dǎo)入失敗的典型場(chǎng)景數(shù)據(jù)導(dǎo)入失敗通常有幾種表現(xiàn)任務(wù)超時(shí)、版本沖突、數(shù)據(jù)質(zhì)量問(wèn)題。任務(wù)超時(shí)最常見(jiàn)的原因是導(dǎo)入的數(shù)據(jù)量超過(guò)了單次導(dǎo)入的限制或者網(wǎng)絡(luò)帶寬不足。解決方法是拆分導(dǎo)入任務(wù)或者調(diào)整導(dǎo)入的超時(shí)參數(shù)。版本沖突通常發(fā)生在并發(fā)導(dǎo)入同一張表時(shí)。Doris的導(dǎo)入任務(wù)是按Label去重的如果兩個(gè)任務(wù)用了相同的Label第二個(gè)任務(wù)會(huì)被拒絕。解決方法是確保每個(gè)導(dǎo)入任務(wù)的Label唯一通常用“表名時(shí)間戳隨機(jī)數(shù)”來(lái)生成。數(shù)據(jù)質(zhì)量問(wèn)題包括字段類型不匹配、空值約束沖突、分區(qū)字段格式錯(cuò)誤等。這類問(wèn)題最好在導(dǎo)入前做數(shù)據(jù)校驗(yàn)比如用Spark或Flink做一層ETL清洗確保數(shù)據(jù)符合目標(biāo)表的Schema。6.3 集群擴(kuò)縮容的注意事項(xiàng)OLAP集群的擴(kuò)縮容不是簡(jiǎn)單的加機(jī)器或減機(jī)器。以Doris為例擴(kuò)容時(shí)需要把新節(jié)點(diǎn)加入集群然后觸發(fā)數(shù)據(jù)重分布把部分分片遷移到新節(jié)點(diǎn)上。這個(gè)過(guò)程會(huì)占用網(wǎng)絡(luò)和磁盤(pán)I/O建議在業(yè)務(wù)低峰期執(zhí)行?？s容更麻煩需要先把要下線節(jié)點(diǎn)上的數(shù)據(jù)遷移到其他節(jié)點(diǎn)確認(rèn)數(shù)據(jù)完整后再下線。如果直接下線節(jié)點(diǎn)可能導(dǎo)致數(shù)據(jù)丟失或副本數(shù)不足。任何擴(kuò)縮容操作前一定要先備份元數(shù)據(jù)并且確認(rèn)副本數(shù)大于1。提示擴(kuò)縮容后建議觀察一段時(shí)間比如24小時(shí)的查詢性能和穩(wěn)定性確認(rèn)沒(méi)有異常后再進(jìn)行下一步操作。我見(jiàn)過(guò)擴(kuò)容后因?yàn)閿?shù)據(jù)分布不均導(dǎo)致部分節(jié)點(diǎn)負(fù)載反而更高的案例。6.4 我的三條避坑心得第一條不要在生產(chǎn)環(huán)境直接跑大查詢。新寫(xiě)的SQL先在測(cè)試環(huán)境跑一遍看看執(zhí)行計(jì)劃和資源消耗。如果測(cè)試環(huán)境數(shù)據(jù)量太小看不出問(wèn)題可以用EXPLAIN命令分析執(zhí)行計(jì)劃重點(diǎn)關(guān)注掃描行數(shù)和是否命中索引。第二條監(jiān)控比調(diào)優(yōu)更重要。很多問(wèn)題在爆發(fā)前都有征兆比如查詢延遲逐漸上升、磁盤(pán)使用率持續(xù)增長(zhǎng)、導(dǎo)入任務(wù)排隊(duì)變長(zhǎng)。建好監(jiān)控告警把問(wèn)題扼殺在萌芽階段比事后救火輕松得多。第三條文檔和規(guī)范要落地。建表規(guī)范、命名規(guī)范、查詢規(guī)范這些看起來(lái)是小事但團(tuán)隊(duì)大了之后沒(méi)有規(guī)范就會(huì)亂套。比如有人用日期做分區(qū)有人用字符串做分區(qū)查詢時(shí)根本沒(méi)法統(tǒng)一優(yōu)化。建議在項(xiàng)目初期就把規(guī)范定好并且用代碼審查來(lái)保證執(zhí)行。7. 寫(xiě)在最后的一點(diǎn)個(gè)人體會(huì)OLAP這個(gè)領(lǐng)域變化很快新引擎、新架構(gòu)、新優(yōu)化技術(shù)層出不窮。但底層的東西其實(shí)沒(méi)怎么變列式存儲(chǔ)、向量化執(zhí)行、MPP、智能索引這些核心原理從十年前到現(xiàn)在一直適用。把原理搞明白了再去看那些新出的引擎你會(huì)發(fā)現(xiàn)它們只是在某個(gè)維度上做了改進(jìn)而不是顛覆。我在實(shí)際項(xiàng)目中的體會(huì)是選型時(shí)不要追求“最先進(jìn)”或“性能最強(qiáng)”而要選“最適合當(dāng)前團(tuán)隊(duì)和業(yè)務(wù)”的。一個(gè)運(yùn)維復(fù)雜但性能極致的引擎如果團(tuán)隊(duì)沒(méi)有能力駕馭反而會(huì)成為負(fù)擔(dān)。相反一個(gè)性能中上但穩(wěn)定易用的引擎可能帶來(lái)更大的整體價(jià)值。另外OLAP不是孤立的。它和上游的數(shù)據(jù)采集、ETL、消息隊(duì)列下游的BI、報(bào)表、數(shù)據(jù)應(yīng)用是一個(gè)完整的鏈路。只優(yōu)化OLAP引擎本身往往達(dá)不到最好的效果。比如上游數(shù)據(jù)質(zhì)量差OLAP里再怎么優(yōu)化也查不出正確結(jié)果下游BI工具寫(xiě)法不當(dāng)再快的引擎也扛不住。所以做OLAP優(yōu)化要有全局視角。最后分享一個(gè)小技巧如果你不確定某個(gè)查詢?yōu)槭裁绰扔肊XPLAIN看看執(zhí)行計(jì)劃重點(diǎn)關(guān)注三個(gè)指標(biāo)——掃描行數(shù)、掃描字節(jié)數(shù)、是否命中分區(qū)裁剪。這三個(gè)指標(biāo)基本能定位80%的性能問(wèn)題。剩下的20%再去看數(shù)據(jù)分布、資源競(jìng)爭(zhēng)和并發(fā)情況。這個(gè)排查順序我用了很多年屢試不爽。