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