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