MPP 這個詞很多人第一次接觸到它是在面試或者在處理一個跑了幾小時都沒出結(jié)果的報表時被有經(jīng)驗的同事一句“這表得走 MPP 引擎”給點醒。說實話MPP 不是一個新概念從數(shù)據(jù)倉庫時代它就存在了但這些年隨著大數(shù)據(jù)和云數(shù)倉的普及它又一次成了架構(gòu)選型里繞不開的坎。如果只看定義MPP 就是 Massively Parallel Processing大規(guī)模并行處理聽起來很直白但真正理解它并不是在說“把任務(wù)分成多個并行執(zhí)行”這么簡單而是要先搞明白它解決的是哪一類問題、為什么分布式系統(tǒng)繞了這么多年卻依然以 MPP 為骨干。這篇內(nèi)容我打算從一個實際問題切入當(dāng)單機計算撐不住的時候MPP 是如何通過一整套分工協(xié)作機制扛下來的。我會從架構(gòu)拆解、平臺支持、以及我實際踩過的幾個坑出發(fā)把 MPP 的“家底”一次說清楚。適合剛接觸分布式數(shù)據(jù)庫的讀者也適合那些正在做技術(shù)選型、想搞清楚 Greenplum、ClickHouse、Redshift 這些引擎底層邏輯的同學(xué)。1. 內(nèi)容整體設(shè)計與思路拆解1.1 核心需求解析單機瓶頸到底卡在哪要理解 MPP 存在的意義得先看單機架構(gòu)走到盡頭時暴露的三個瓶頸。硬件層面單臺服務(wù)器的 CPU 核數(shù)和內(nèi)存帶寬是有上限的即使一臺 128 核、2TB 內(nèi)存的機器在處理 TB 級數(shù)據(jù)的關(guān)聯(lián)聚合時內(nèi)存帶寬和 I/O 也會迅速飽和。軟件層面?zhèn)鹘y(tǒng)單機數(shù)據(jù)庫的查詢優(yōu)化器基于的是集中式執(zhí)行模型所有數(shù)據(jù)都要經(jīng)過一個執(zhí)行引擎節(jié)點數(shù)據(jù)量上去之后這個節(jié)點的 CPU 和網(wǎng)絡(luò)協(xié)議棧會成為絕對的瓶頸。運維層面單機擴容是縱向擴展換一臺更強的機器往往意味著停機、遷移、重新壓測成本非常高。這三個瓶頸分別對應(yīng)了 MPP 架構(gòu)的核心設(shè)計目標(biāo)通過將數(shù)據(jù)分布到多個計算節(jié)點上讓每個節(jié)點只處理一部分?jǐn)?shù)據(jù)并且節(jié)點之間通過網(wǎng)絡(luò)連接協(xié)同完成一個查詢?nèi)蝿?wù)。如果把單機數(shù)據(jù)庫比作一家全能型的小店店員既要收銀又要理貨還要做售后那么 MPP 就是一家連鎖超市每家門店只負(fù)責(zé)自己片區(qū)里的商品總部通過一套調(diào)度系統(tǒng)把顧客的需求拆解到對應(yīng)的門店去執(zhí)行。這種“拆解”就是 MPP 的精髓也是它和普通分布式系統(tǒng)最本質(zhì)的區(qū)別。1.2 MPP 的定位不是某一個數(shù)據(jù)庫而是一類計算范式很多人容易把 MPP 理解為某款產(chǎn)品比如 Greenplum、Teradata或者干脆有人說 ClickHouse 就是 MPP其實這里有個概念混淆。MPP 是一個計算范式的統(tǒng)稱它描述的是“無共享架構(gòu)下多個節(jié)點并行處理同一任務(wù)”的軟件設(shè)計模式。在這個范式之下各家系統(tǒng)有不同的實現(xiàn)方式有基于 PostgreSQL 擴展而來的 Greenplum有純列式存儲的 Vertica有基于 PostgreSQL 的 Citus也有 ClickHouse 這種兼顧列式存儲和分布式查詢的引擎。理解了這一點再去討論平臺支持就有意義了。因為 MPP 不是一個孤立的軟件而是一種架構(gòu)選型這意味著你在選型時更多是在選“哪套平臺對 MPP 的實現(xiàn)更貼合我的業(yè)務(wù)”而不是在選“哪個數(shù)據(jù)庫支持 MPP”。從這個角度看MPP 的架構(gòu)拆解反而是更值得花時間的地方因為無論底層是哪家系統(tǒng)它們的核心模型基本一致理解了共性再看差異就是分分鐘的事。2. MPP 的核心架構(gòu)拆解2.1 三個關(guān)鍵角色協(xié)調(diào)節(jié)點、計算節(jié)點、存儲層一套標(biāo)準(zhǔn)的 MPP 架構(gòu)里無論外觀怎么變內(nèi)部基本都跑不了這三個角色。協(xié)調(diào)節(jié)點Coordinator有的系統(tǒng)叫 Master、Leader、Query Planner負(fù)責(zé)接收用戶的 SQL做語法解析、邏輯優(yōu)化、生成執(zhí)行計劃然后把計劃分發(fā)到各個計算節(jié)點上執(zhí)行。它不存儲真正的業(yè)務(wù)數(shù)據(jù)或者說只有元數(shù)據(jù)、統(tǒng)計信息、分布策略這類輕量數(shù)據(jù)。這里很多人會有個誤區(qū)以為協(xié)調(diào)節(jié)點就是瓶頸其實在成熟的 MPP 系統(tǒng)里協(xié)調(diào)節(jié)點的作用更接近“指揮中樞”而不是“數(shù)據(jù)搬運工”。它負(fù)責(zé)拆任務(wù)但不負(fù)責(zé)算數(shù)據(jù)數(shù)據(jù)還是在各個計算節(jié)點本地完成的這樣協(xié)調(diào)節(jié)點的壓力就能控制在一定范圍內(nèi)。計算節(jié)點Segment、Worker、Executor是最核心的角色。它們各自持有數(shù)據(jù)的一部分通常是以分片Shard或分區(qū)Partition的形式存儲。當(dāng)一個查詢被協(xié)調(diào)節(jié)點拆分后每個計算節(jié)點只需要處理自己本地的那份數(shù)據(jù)這個過程叫本地計算Local Compute也是 MPP 能獲得線性擴展能力的基礎(chǔ)。存儲層在 MPP 里有兩種形態(tài)一種是存儲和計算耦合的本地盤模式像 Greenplum、ClickHouse 集群數(shù)據(jù)直接落在各節(jié)點的本地存儲上數(shù)據(jù)分布策略決定了數(shù)據(jù)落在哪些節(jié)點另一種是存儲和計算分離的模式像云數(shù)倉 Redshift Spectrum、Snowflake數(shù)據(jù)放在對象存儲上計算節(jié)點按需加載數(shù)據(jù)到本地緩存。后一種在彈性擴縮容上更有優(yōu)勢但數(shù)據(jù)傳輸?shù)男释蔀樾碌钠款i這也是為什么云廠商都在搞緩存親和性和數(shù)據(jù)本地性優(yōu)化。2.2 數(shù)據(jù)分布策略分布鍵是 MPP 的靈魂如果說協(xié)調(diào)節(jié)點是 MPP 的大腦那分布鍵就是血液。MPP 的數(shù)據(jù)分布策略直接決定了后續(xù)所有查詢的性能表現(xiàn)。以 Greenplum 為例建表時通過 DISTRIBUTED BY 指定分布鍵數(shù)據(jù)會根據(jù)該鍵的哈希值散列到各個 Segment 節(jié)點上如果不指定系統(tǒng)會默認(rèn)按第一個字段的哈希分布。這個分布鍵的選擇極其講究因為它決定了關(guān)聯(lián)查詢時數(shù)據(jù)能否在本地完成。舉個例子一個訂單表和一個訂單明細(xì)表如果兩張表都用“訂單ID”作為分布鍵那么在關(guān)聯(lián)查詢時每個計算節(jié)點上都能找到自己本地對應(yīng)的訂單和明細(xì)數(shù)據(jù)整條關(guān)聯(lián)鏈路完全走本地執(zhí)行不需要任何跨節(jié)點數(shù)據(jù)傳輸。反之如果訂單表按訂單ID分布明細(xì)表按商品ID分布那關(guān)聯(lián)時系統(tǒng)就得把明細(xì)表的數(shù)據(jù)按訂單ID重新洗牌Redistribute到對應(yīng)節(jié)點上這一下會帶來巨大的網(wǎng)絡(luò)開銷查詢可能從秒級直接變成分鐘級。這種“按分布鍵對齊”的設(shè)計在 MPP 術(shù)語里叫 co-located join。不僅是關(guān)聯(lián)分組聚合、去重這類操作同樣受分布鍵影響。比如要按用戶維度做聚合用戶ID作為分布鍵時每個節(jié)點只需要聚合本地的那部分用戶完全不需要 shuffle 數(shù)據(jù)。所以分布鍵的選擇絕不是建表時隨便填一個字段那么簡單它需要結(jié)合業(yè)務(wù)最常見的查詢模式來做設(shè)計。這也是我后面要重點講的實操要點之一。2.3 為什么 Shared-Nothing 架構(gòu)是 MPP 的主流MPP 領(lǐng)域最經(jīng)典的架構(gòu)分類是 Shared-Nothing 和 Shared-Disk。Shared-Disk 指的是所有計算節(jié)點共享同一套存儲系統(tǒng)比如 Oracle RAC數(shù)據(jù)只有一份所有節(jié)點都能訪問但為了保證一致性需要額外的鎖機制和緩存融合機制這在高并發(fā)下非常容易出現(xiàn)阻塞。Shared-Nothing 指的是每個節(jié)點獨享自己的 CPU、內(nèi)存和磁盤節(jié)點之間只通過網(wǎng)絡(luò)交換數(shù)據(jù)不存在共享存儲的競爭問題。MPP 數(shù)據(jù)庫絕大多數(shù)都采用了 Shared-Nothing原因很直接第一擴展性更好加一個節(jié)點數(shù)據(jù)就多一份分布落點計算能力跟著線性增長不需要考慮存儲層面的共享瓶頸第二數(shù)據(jù)本地性更好每個節(jié)點只需要處理本地數(shù)據(jù)不需要遠程讀取I/O 延遲大幅降低第三故障隔離更好某個節(jié)點宕機其他節(jié)點還可以繼續(xù)工作配合副本機制可以實現(xiàn)高可用。當(dāng)然 Shared-Nothing 也有代價。數(shù)據(jù)需要冗余多份存儲成本高一些節(jié)點間通信依賴網(wǎng)絡(luò)質(zhì)量萬兆網(wǎng)卡和低延遲交換機幾乎是標(biāo)配數(shù)據(jù)重分布的操作代價也比較大比如集群擴容時要重新平衡數(shù)據(jù)如果節(jié)點間傳輸?shù)臄?shù)據(jù)量巨大這個過程可能持續(xù)數(shù)小時。但整體上看Shared-Nothing 在大規(guī)模并行計算場景下依然是性價比最高的選擇這也是從 Teradata 到 Greenplum再到云上 Snowflake 都堅持這一架構(gòu)的根本原因。2.4 控制平面與數(shù)據(jù)平面的分離成熟的 MPP 系統(tǒng)在設(shè)計上會把控制平面和數(shù)據(jù)平面分開。控制平面處理元數(shù)據(jù)、鎖管理、會話管理、調(diào)度決策數(shù)據(jù)平面負(fù)責(zé)數(shù)據(jù)的存儲、傳輸和計算。這種分離帶來的好處非常實際控制平面負(fù)載很輕即使集群規(guī)模很大協(xié)調(diào)節(jié)點也能輕松應(yīng)對數(shù)據(jù)平面則可以充分水平擴展每個計算節(jié)點獨立處理自己的數(shù)據(jù)分片互不干擾。以 Greenplum 為例控制平面由 Master 節(jié)點承擔(dān)數(shù)據(jù)平面由多個 Segment 節(jié)點構(gòu)成。Master 節(jié)點的硬件要求反而沒有那么夸張因為它的職責(zé)只是接收 SQL、生成計劃、匯總結(jié)果真正耗資源的計算都發(fā)生在 Segment 上。這個架構(gòu)設(shè)計的另一個好處是在做性能調(diào)優(yōu)時定位問題會清晰很多如果查詢計劃階段耗時高問題大概率在控制平面如果執(zhí)行階段耗時高再去看數(shù)據(jù)平面的節(jié)點負(fù)載和網(wǎng)絡(luò)傳輸。3. 平臺支持全景從傳統(tǒng)數(shù)倉到大數(shù)據(jù)庫生態(tài)再到云上數(shù)倉3.1 傳統(tǒng)數(shù)倉陣營里MPP 是怎么站穩(wěn)腳跟的MPP 在傳統(tǒng)數(shù)據(jù)倉庫領(lǐng)域的代表有 Teradata、Vertica、Greenplum、Netezza 等。Teradata 是鼻祖級的存在1990 年代就開始大規(guī)模應(yīng)用在金融、電信、零售行業(yè)它的節(jié)點間通信機制和優(yōu)化器設(shè)計影響了后來很多產(chǎn)品。Teradata 的架構(gòu)是典型的 Shared-Nothing每個節(jié)點也叫 AMP數(shù)據(jù)按主索引分布在各個 AMP 上這個設(shè)計和 Greenplum 的分布鍵幾乎是一個邏輯。Vertica 很有意思它是列式存儲和 MPP 結(jié)合的典范最早源自 C-Store 研究項目后來被 HP 收購現(xiàn)在是 Micro Focus 旗下的產(chǎn)品。Vertica 最大的特點是壓縮率極高列式存儲配合高級壓縮算法相同的數(shù)據(jù)量比行式存儲省 5-10 倍空間在這個基礎(chǔ)上再跑 MPP 查詢I/O 量就明顯小下去。Greenplum 則是開源領(lǐng)域最有代表性的 MPP 數(shù)據(jù)庫它基于 PostgreSQL 改造兼容 PostgreSQL 語法這大概是它能在互聯(lián)網(wǎng)公司大規(guī)模落地的重要原因。Greenplum 在 6.x 版本后引入了增強的 ORCA 優(yōu)化器對復(fù)雜查詢的優(yōu)化能力大幅提升。但要注意Greenplum 更像是一個分析型數(shù)倉OLTP 類的高并發(fā)點查并不是它的強項。Netezza 則被 IBM 收購它獨特的地方在于使用了 FPGA 加速在硬件層面做數(shù)據(jù)過濾和聚合這個設(shè)計理念至今仍有參考意義。3.2 大數(shù)據(jù)生態(tài)里的 MPPClickHouse、Trino、Impala大數(shù)據(jù)生態(tài)里掛 MPP 名字的系統(tǒng)更多ClickHouse、Trino前身 Presto、Impala 都常被歸入 MPP 陣營但它們的實現(xiàn)風(fēng)格差別很大。ClickHouse 是俄羅斯公司 Yandex 開源的列式數(shù)據(jù)庫它的 MPP 實現(xiàn)方式非常激進。ClickHouse 默認(rèn)不做跨節(jié)點的數(shù)據(jù)關(guān)聯(lián)它更鼓勵通過預(yù)先設(shè)計好的分布式表和大寬表來規(guī)避 shuffle。ClickHouse 的分布式查詢走的是“每個分片獨立執(zhí)行完再由協(xié)調(diào)節(jié)點合并”的模式如果查詢涉及跨分片的數(shù)據(jù)關(guān)聯(lián)性能會退化得非常明顯。所以 ClickHouse 在多數(shù)場景下是被當(dāng)作“單機性能極強的分布式聚合引擎”來使用而不是一個完整的分布式數(shù)據(jù)倉庫。Trino 則走的是另一條路線它定位是分布式 SQL 查詢引擎本身不存儲數(shù)據(jù)數(shù)據(jù)源可以接 Hive、對象存儲、MySQL、PostgreSQL 等。它的 MPP 能力體現(xiàn)在查詢執(zhí)行階段數(shù)據(jù)從數(shù)據(jù)源并行讀入在內(nèi)存里完成 join 和 aggregation。Trino 的優(yōu)勢是靈活能跨多種數(shù)據(jù)源做聯(lián)邦查詢劣勢則是它完全依賴網(wǎng)絡(luò)傳輸數(shù)據(jù)如果數(shù)據(jù)源到引擎的網(wǎng)絡(luò)帶寬不夠查詢性能就上不去。Impala 是 Cloudera 推出的查詢引擎和 Trino 類似也依賴底層存儲如 HDFS 或 S3。Impala 的無共享架構(gòu)在查詢優(yōu)化和并行執(zhí)行上做得不錯尤其在搭配 Kudu 時可以實現(xiàn)分鐘級數(shù)據(jù)更新的分析場景。但它對內(nèi)存的要求很高深度分頁或者大聚合時內(nèi)存溢出是常見的事故源頭。3.3 云數(shù)倉對 MPP 的重塑Snowflake、Redshift、BigQuery云數(shù)倉把 MPP 從“物理集群”變成了“虛擬資源池”這是對傳統(tǒng)架構(gòu)的一次重大修正。Snowflake 的做法最有代表性存儲層用對象存儲計算層用虛擬 warehouse多個計算集群可以同時掛載在同一個存儲層上互不共享計算資源但共享同一份數(shù)據(jù)。這種架構(gòu)下擴縮容只是啟停虛擬計算集群的事按需計費而且讀寫隔離做得很好不會出現(xiàn)一個慢查詢拖垮其他查詢的情況。Redshift 是 AWS 的老牌數(shù)倉它的核心用的是基于 PostgreSQL 改造的 MPP 引擎。Redshift 早期是典型的 Shared-Nothing節(jié)點掛本地存儲后來推出 RA3 節(jié)點類型把數(shù)據(jù)落地到 S3 并引入本地緩存走向了存儲計算分離的方向。Redshift 的分布鍵和排序鍵設(shè)計非常關(guān)鍵和 Greenplum 的分布鍵是同一個邏輯但 Redshift 還額外增加了分布方式的選擇比如 ALL 分布適合小表廣播EVEN 分布適合按順序輪詢KEY 分布則是哈希分布。BigQuery 則是 Google 的云數(shù)倉它的 MPP 能力藏在柱狀存儲和分布式執(zhí)行引擎 Dremel 的背后。BigQuery 對用戶屏蔽了分片和節(jié)點概念用戶只管寫 SQL系統(tǒng)自動調(diào)度執(zhí)行。它的優(yōu)化器依賴統(tǒng)計信息自動選擇執(zhí)行策略因此用戶不需要手動指定分布鍵但反過來也意味著如果表數(shù)據(jù)的統(tǒng)計信息陳舊執(zhí)行計劃可能不理想。云數(shù)倉的共性趨勢是存儲和計算分離、彈性擴縮容、按量計費這些本質(zhì)上都是 MPP 架構(gòu)的延伸和優(yōu)化只是把資源管理的維度從物理節(jié)點提升到了虛擬資源池。對用戶來說運維復(fù)雜度降低了很多但架構(gòu)理解和查詢優(yōu)化的工作量并沒有減少反而因為屏蔽了底層細(xì)節(jié)更考驗工程師對執(zhí)行計劃的把握。3.4 一個真實例子MPP 引擎處理一條查詢的全流程為了更直觀地理解 MPP 的工作流程我用 Greenplum 處理一條 SQL 來串一遍整個過程。假設(shè)有兩張表用戶表包含用戶ID、注冊城市、注冊時間訂單表包含訂單ID、用戶ID、訂單金額、下單時間。查詢需求是統(tǒng)計每個城市的訂單總額。這條 SQL 到達 Master 節(jié)點后先是解析和驗證生成語法樹然后走優(yōu)化器。優(yōu)化器會做兩件事代價估算和執(zhí)行計劃生成。這里關(guān)鍵的點是優(yōu)化器需要知道兩張表的分布鍵是什么。如果用戶表按用戶ID分布訂單表也按用戶ID分布那優(yōu)化器會認(rèn)為這種 join 可以走本地關(guān)聯(lián)于是采用 co-located join 策略每個 Segment 節(jié)點只處理本地那部分用戶的訂單。之后按注冊城市做分組聚合每個 Segment 節(jié)點本地做一次聚合得到部分結(jié)果然后把結(jié)果發(fā)回 MasterMaster 再做最終合并返回給客戶端。如果分布鍵不匹配執(zhí)行計劃里就會多出一步 Redistribute 或者 Broadcast。Redistribute 是把一張表的數(shù)據(jù)按目標(biāo)字段重新哈希后發(fā)送到對應(yīng)節(jié)點Broadcast 則是把小表復(fù)制到所有節(jié)點。這兩種數(shù)據(jù)移動都會增大網(wǎng)絡(luò)開銷也是 MPP 查詢變慢最常見的可視化原因。通過 EXPLAIN 查看執(zhí)行計劃時如果看到運動節(jié)點Motion非常多就該懷疑分布鍵設(shè)計是否有問題了。另外MPP 執(zhí)行還有一個值得注意的細(xì)節(jié)——物化中間結(jié)果。有些 MPP 引擎會把 shuffle 的中間結(jié)果寫磁盤Greenplum 在內(nèi)存不足時也會做磁盤溢出這會進一步放大 I/O 開銷。所以控制中間結(jié)果集的大小比如盡早做過濾、避免 SELECT 全字段、盡量在聚合前壓縮數(shù)據(jù)量是 MPP 查詢優(yōu)化的重要思路。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 環(huán)境選型與節(jié)點規(guī)劃在規(guī)劃一套 MPP 集群時第一個要決定的是“要不要上 MPP”而不是“上哪個 MPP”。當(dāng)數(shù)據(jù)量在幾百 GB 到幾個 TB 級別、查詢模式以 SQL 聚合分析為主、對實時寫入沒有極端要求時MPP 是一個非常合理的選擇。但如果數(shù)據(jù)量只有幾十 GB且頻繁的并發(fā)點查占比很高傳統(tǒng)的關(guān)系型數(shù)據(jù)庫或者單機 PostgreSQL 反而是更好的選擇。選型確定之后節(jié)點規(guī)劃有一些實戰(zhàn)經(jīng)驗可以分享。計算節(jié)點數(shù)量和 CPU 核數(shù)的配比要結(jié)合查詢復(fù)雜度來看。一般建議單個 Segment 節(jié)點分配 8 核到 16 核內(nèi)存和 CPU 核心數(shù)按 8GB 到 16GB 每核心來配。比如一個 4 節(jié)點的 Greenplum 集群每個節(jié)點 16 核、128GB 內(nèi)存總共 64 核、512GB 內(nèi)存這樣的規(guī)模應(yīng)對 5TB 左右的數(shù)倉數(shù)據(jù)是夠用的。另外要考慮網(wǎng)絡(luò)。MPP 集群的節(jié)點間通信對網(wǎng)絡(luò)延遲和帶寬非常敏感強烈建議上萬兆網(wǎng)絡(luò)。我見過一個集群因為用了千兆網(wǎng)絡(luò)結(jié)果在數(shù)據(jù)重分布階段網(wǎng)絡(luò)成了瓶頸整個集群跑一個跨節(jié)點的 join 都要十幾分鐘后來換成萬兆網(wǎng)絡(luò)同一個查詢只需要不到一分鐘這個差距非?？鋸垺?.2 建表語句里的分布鍵設(shè)計現(xiàn)場在建表時分布鍵的選擇需要結(jié)合業(yè)務(wù)的實際查詢模式。一個來自生產(chǎn)環(huán)境的經(jīng)驗做法是找出查詢頻率最高的三張表和它們最常用的關(guān)聯(lián)條件把這些關(guān)聯(lián)字段作為分布鍵的首選。比如前面的用戶表和訂單表如果訂單表是事實表用戶表是維度表那么訂單表按用戶ID分布用戶表也按用戶ID分布就能讓最常見的關(guān)聯(lián)查詢走本地關(guān)聯(lián)。另一個關(guān)鍵技巧是處理數(shù)據(jù)傾斜。如果分布鍵的取值分布不均比如用戶ID集中在少數(shù)幾個值上例如某個頭部用戶貢獻了絕大多數(shù)訂單那么這些熱點數(shù)據(jù)會全部落到同一個節(jié)點上導(dǎo)致該節(jié)點的負(fù)載遠高于其他節(jié)點形成“木桶效應(yīng)”。解決方法是使用復(fù)合分布鍵或者在前綴字段上增加一個隨機因子也可以在建模時把大用戶的數(shù)據(jù)單獨分桶處理。簡單的檢查方法是執(zhí)行一個“SELECT 分布鍵, COUNT(*) FROM 表 GROUP BY 分布鍵”的查詢觀察各個取值的數(shù)據(jù)量如果發(fā)現(xiàn)有明顯的長尾分布就要考慮調(diào)整分布策略。在 Redshift 里還有一個 ALL 分布的選擇。對于數(shù)據(jù)量較小的維度表比如幾百 MB 的國家表、城市表直接用 ALL 分布在每個節(jié)點都放一份全量數(shù)據(jù)join 時就可以完全避免廣播操作。這個技巧雖然簡單但在實際優(yōu)化中的效果非常顯著。4.3 查詢優(yōu)化從執(zhí)行計劃里找運動節(jié)點在實際做性能調(diào)優(yōu)時第一件事永遠是看執(zhí)行計劃。以 Greenplum 為例EXPLAIN ANALYZE 輸出中的關(guān)鍵信息有三個每步操作的行數(shù)估算和實際行數(shù)、Motion 的類型和行數(shù)、以及每個節(jié)點的執(zhí)行耗時。Motion 在 Greenplum 執(zhí)行計劃里就是數(shù)據(jù)移動的標(biāo)志如果在計劃里看到很多 Redistribute Motion 或者 Broadcast Motion且涉及的行數(shù)很大那這個查詢必然快不了。一個經(jīng)常被忽略的問題是統(tǒng)計信息的時效性。MPP 優(yōu)化器依賴統(tǒng)計信息來做代價估算如果一張千萬級的表從創(chuàng)建后就沒跑過 ANALYZE優(yōu)化器可能認(rèn)為它是空表或者在過濾條件上嚴(yán)重低估行數(shù)導(dǎo)致選錯 join 順序。比如一張大事實表和維度表關(guān)聯(lián)維度表過濾后的數(shù)據(jù)量被低估了 10 倍優(yōu)化器就可能選擇把維度表廣播到所有節(jié)點產(chǎn)生大量無效數(shù)據(jù)傳輸。解決辦法是定期對關(guān)鍵表執(zhí)行 ANALYZE以及在大批量數(shù)據(jù)導(dǎo)入后立刻做一次統(tǒng)計信息更新。另外MPP 查詢中常見的高成本操作是“帶 ORDER BY 的聚合”和“窗口函數(shù)”。窗口函數(shù)在 MPP 下的執(zhí)行往往需要把數(shù)據(jù)按窗口字段重分布這是一個全量數(shù)據(jù)洗牌的過程。如果窗口函數(shù)用得太隨意比如 OVER (PARTITION BY 某個高基數(shù)字段)那代價極高。優(yōu)化思路是提前過濾數(shù)據(jù)、只在所需的數(shù)據(jù)范圍上做窗口計算或者拆分成更小的數(shù)據(jù)集分別處理再合并結(jié)果。4.4 資源管理隊列與并發(fā)控制MPP 集群的資源不是一個無限平攤的資源池每個查詢都會消耗一定配額。Greenplum 里的資源隊列Resource Queue就是用來控制并發(fā)的它定義了每個隊列的 CPU、內(nèi)存、并發(fā)數(shù)量限制。生產(chǎn)環(huán)境里常犯的錯誤是把所有查詢都放進默認(rèn)隊列也不限制并發(fā)數(shù)結(jié)果幾個大查詢同時跑內(nèi)存直接耗盡集群狀態(tài)瞬間變得不可用。合適的做法是把查詢按業(yè)務(wù)優(yōu)先級分成幾個隊列實時報表一個隊列并發(fā)數(shù)限制在 5 個以內(nèi)內(nèi)存配額給足批量任務(wù)一個隊列并發(fā)數(shù) 2-3 個執(zhí)行時間長也沒關(guān)系臨時查詢一個隊列優(yōu)先級最低。這樣即使有人提交了一個跑 2 小時的大查詢也不會把實時報表的通道堵死。Redshift 里也有對應(yīng)的 WLMWorkload Management隊列配置原理完全一致。還有一個實踐中很有效的做法是設(shè)置 statement_mem 或類似的查詢內(nèi)存限制防止單個查詢吃掉整個節(jié)點內(nèi)存。大查詢?nèi)绻麅?nèi)存不足可以接受它落磁盤來換穩(wěn)定性但絕不能讓一個失控查詢把整個集群搞掛。4.5 常見問題與排查技巧實錄MPP 集群的常見故障我按大類整理了一份速查表現(xiàn)象可能原因排查手段解決思路查詢整體變慢但無報錯數(shù)據(jù)分布傾斜查看各節(jié)點 CPU/IO 負(fù)載調(diào)整分布鍵增加隨機前綴執(zhí)行計劃中的 Motion 行數(shù)異常大分布鍵不匹配或統(tǒng)計信息過期EXPLAIN ANALYZE 對比估算與真實行數(shù)更新統(tǒng)計信息拆分子查詢單節(jié)點內(nèi)存溢出OOM并發(fā)過高或查詢中間結(jié)果過大查看資源隊列活躍查詢限制并發(fā)拆分大查詢集群擴容后數(shù)據(jù)長期不均衡擴縮容后數(shù)據(jù)重分布未完成查看系統(tǒng)表 rebalance 狀態(tài)手動執(zhí)行數(shù)據(jù)重分布任務(wù)高并發(fā)點查性能差未遵循 MPP 設(shè)計規(guī)則查看是否觸發(fā)了全表掃描在維度表和主鍵上建立索引或更換為 OLTP 類數(shù)據(jù)庫跨庫關(guān)聯(lián)頻繁出現(xiàn) Broadcast維度表未用 ALL 分布查看執(zhí)行計劃中的 Broadcast Motion小維度表改為 ALL 分布這里面最值得強調(diào)的是第一個問題——數(shù)據(jù)傾斜。傾斜問題的隱蔽性強集群看起來所有節(jié)點都在工作但只有一個節(jié)點負(fù)載接近 100%其他節(jié)點閑得發(fā)呆。排查起來也簡單Ganglia、Prometheus 這類監(jiān)控工具看節(jié)點負(fù)載圖對比各節(jié)點 CPU 曲線的差異如果一條線豎得老高而兩側(cè)都是平線基本就是傾斜無疑了。之前在生產(chǎn)環(huán)境處理過一個問題一個按商品維度統(tǒng)計銷量的查詢某個頭部商品的數(shù)據(jù)占了全表 35%這一個值讓單節(jié)點負(fù)載比平均高出 4 倍查詢從預(yù)期的 30 秒拖到了 5 分鐘。后來把分布鍵改成了“商品ID 一個城市字段”的復(fù)合鍵讓大數(shù)據(jù)量的商品也能在不同節(jié)點上散開查詢恢復(fù)到了 40 秒以內(nèi)。第二個要提的坑是“MPP 未必比單機快”。當(dāng)數(shù)據(jù)量不大、單機完全能放下時MPP 的網(wǎng)絡(luò)通信開銷反而會讓性能更差。我有一次在同一套數(shù)據(jù)上對比測試數(shù)據(jù)量 200GBMPP 集群是 4 節(jié)點單機是 64 核大內(nèi)存。一個中等復(fù)雜度的 join 聚合查詢MPP 跑了 45 秒單機 PostgreSQL 只跑了 28 秒。原因很簡單MPP 執(zhí)行計劃里有兩處 Redistribute Motion數(shù)據(jù)傳輸占了大半時間而這個查詢在單機上完全不需要移動數(shù)據(jù)。所以MPP 的“快”是有前提的數(shù)據(jù)量足夠大到單機無法合理承載或者查詢本身能通過并行化受益。數(shù)據(jù)量小的時候不要迷信分布式。第三個是關(guān)于并發(fā)和慢查詢互相干擾的典型事故。某個周五晚上一條數(shù)據(jù)清洗 SQL 和線上報表查詢同時運行清洗任務(wù)一次性 UPDATE 了全表 80% 的行這個 UPDATE 在 MPP 里會生成巨大的中間結(jié)果并且鎖定大量行導(dǎo)致線上報表查詢被阻塞。最終的結(jié)果是清洗任務(wù)運行了 3 小時期間線上報表一直超時。事后復(fù)盤下來核心問題是沒做資源隔離和鎖管理。后來把清洗任務(wù)放到專門的維護窗口并且提交前加上超時控制和鎖等待時間限制這類問題就再沒出現(xiàn)過。5. 繼續(xù)深挖的兩個方向其實聊到這里MPP 的基本盤已經(jīng)說完了架構(gòu)上理解 Shared-Nothing 和分布鍵平臺上理解各家的差異實操上理解執(zhí)行計劃和資源管理。但如果真想在這一塊繼續(xù)深入還有兩個方向值得花時間。第一個方向是“MPP 和 NewSQL”的邊界。MPP 在分析型場景里有統(tǒng)治力但在高并發(fā)事務(wù)場景里表現(xiàn)不理想。TiDB、OceanBase 這類 NewSQL 數(shù)據(jù)庫雖然也用了分布式存儲和計算分離的思路但它們的目標(biāo)是兼顧 OLTP 和 OLAP執(zhí)行引擎的設(shè)計和 MPP 有本質(zhì)差異。理解這個邊界對做技術(shù)選型的人非常重要——不是說分布式數(shù)據(jù)庫就能解決所有問題選型的關(guān)鍵前提要厘清“這個系統(tǒng)處理的是什么類型的查詢”。第二個方向是“湖倉一體”里的 MPP 角色。數(shù)據(jù)湖和數(shù)據(jù)倉庫的界限在模糊像 Trino、Hive 這類引擎已經(jīng)可以把數(shù)據(jù)湖文件當(dāng)作源來做 MPP 查詢Doris、StarRocks 也把數(shù)據(jù)湖聯(lián)邦查詢做成了常態(tài)化能力。在這個背景下MPP 的定位不再局限于數(shù)倉內(nèi)部它正在變成一個統(tǒng)一查詢計算層。這個演進非?？熘档贸掷m(xù)跟蹤。從我個人實際應(yīng)用的角度來說最好的學(xué)習(xí)方式不是在文檔里背概念而是找一個真實的業(yè)務(wù)場景拿一套小規(guī)模的 MPP 環(huán)境親手建表、設(shè)計分布鍵、跑 EXPLAIN ANALYZE 去觀察 Motion再故意選錯一次分布鍵感受一下性能回退。這個過程走一遍你對 MPP 的理解會遠超讀十篇文章。最后再分享一個小經(jīng)驗MPP 集群里執(zhí)行計劃里的 Motion 數(shù)量永遠和性能成反比優(yōu)化目標(biāo)就是盡可能減少數(shù)據(jù)移動所有的分布鍵設(shè)計、SQL 改寫、統(tǒng)計信息更新本質(zhì)上都是圍繞這一件事在轉(zhuǎn)。