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