1. 先別急著記定義三個(gè)詞回答的是三個(gè)不同的問(wèn)題你大概率是在這幾個(gè)場(chǎng)景里分別遇見它們的前端要搞大文件分塊上傳搜到 lodash 的 chunk刷 SQL 題看到 PARTITION BY 開窗函數(shù)建表時(shí)又被 DBA 提了一嘴這張表要按日期分區(qū)。于是分塊、PartitionBy、分區(qū)三個(gè)詞都被歸到把數(shù)據(jù)拆開這個(gè)印象里問(wèn)出來(lái)才發(fā)現(xiàn)沒(méi)人能一兩句說(shuō)清。我剛工作那幾年也這么懵過(guò)。后來(lái)帶過(guò)一個(gè)訂單數(shù)據(jù)項(xiàng)目三種用法在同一天里全碰上了才徹底想明白這三個(gè)詞根本不是一個(gè)層面的東西。Chunk / 分塊回答的是數(shù)據(jù)怎么按大小切成一段一段PARTITION BY 回答的是計(jì)算時(shí)在哪個(gè)組里算分區(qū)回答的是數(shù)據(jù)按什么規(guī)則存到不同的單元里。1.1 lo Chunk 大概率指的是 lodash 的 chunk 方法這個(gè)標(biāo)題里的 lo Chunk我基本可以斷定就是在說(shuō) lodash 的 chunk。lodash 是國(guó)內(nèi)前端幾乎人手一份的工具庫(kù)縮寫經(jīng)常寫成__.chunk(array, size)就是把一個(gè)數(shù)組按固定長(zhǎng)度切成若干個(gè)子數(shù)組。中文社區(qū)里分塊這個(gè)詞十次有八次是在說(shuō)這個(gè)。需要提醒一下chunk 這個(gè)詞本身是通用的你在不同地方都會(huì)見到。Node 的流里每批讀到的 Buffer 叫 chunk文件分塊上傳的每一片也叫 chunkHTTP 的分塊傳輸編碼也叫 chunked。它們共同的語(yǔ)義都是把一個(gè)連續(xù)的東西切成一段一段和按業(yè)務(wù)鍵分組完全是兩碼事。1.2 PARTITION BY 和分區(qū)藏在完全不同的上下文里PARTITION BY 是 SQL 標(biāo)準(zhǔn)里窗口函數(shù)window function的一部分寫法是OVER(PARTITION BY 列)。它不改變數(shù)據(jù)怎么存只改變 SQL 引擎在計(jì)算時(shí)把結(jié)果集按什么鍵分成邏輯窗口。而分區(qū)在數(shù)據(jù)庫(kù)和大數(shù)據(jù)語(yǔ)境里更多指物理或邏輯上的存儲(chǔ)劃分MySQL 的表分區(qū)、Hive 里的分區(qū)目錄、Kafka 里 topic 的分區(qū)都是數(shù)據(jù)組織方式不是計(jì)算方式。所以別急著把它們混在一起背先把它們各自的生長(zhǎng)土壤分清楚一個(gè)在 JS 工具函數(shù)里一個(gè)在 SQL 查詢語(yǔ)義里一個(gè)在存儲(chǔ)架構(gòu)里。1.3 先給一句可以背下來(lái)的總判斷分塊Chunk按固定大小切切完每一塊沒(méi)有業(yè)務(wù)含義只為了方便搬運(yùn)和處理。PARTITION BY按某個(gè)字段把結(jié)果集分成若干組在組內(nèi)做聚合、排名、對(duì)比行數(shù)不變。分區(qū)Partition按某個(gè)規(guī)則把數(shù)據(jù)分散到不同存儲(chǔ)或并行單元目的是管理、裁剪、擴(kuò)展。記住這三個(gè)目的后面所有細(xì)節(jié)都是圍繞它們展開的。2. Chunk分塊不管內(nèi)容只按固定長(zhǎng)度切2.1 lodash chunk 的用法和它底層做了什么lodash 的 chunk 用法很簡(jiǎn)單import _ from lodash; const list [1, 2, 3, 4, 5, 6, 7, 8]; const groups _.chunk(list, 3); // groups [[1, 2, 3], [4, 5, 6], [7, 8]]注意最后一個(gè)子數(shù)組只有兩個(gè)元素這是正常的。chunk 不會(huì)因?yàn)榍胁积R就丟數(shù)據(jù)也不會(huì)用一個(gè)空值去補(bǔ)位。它底層其實(shí)就是循環(huán)調(diào)用slice邏輯等價(jià)于function chunk(arr, size) { const result []; for (let i 0; i arr.length; i size) { result.push(arr.slice(i, i size)); } return result; }所以它有兩個(gè)與生俱來(lái)的特征第一不修改原數(shù)組第二切分依據(jù)純粹是下標(biāo)位置完全不管數(shù)組里的元素是什么。你要切的是用戶 ID、訂單號(hào)還是字符串對(duì)它來(lái)說(shuō)沒(méi)有任何區(qū)別。還有一個(gè)容易忽略的規(guī)則size小于 1 時(shí) lodash 返回空數(shù)組size為 1 時(shí)數(shù)組被切成 N 個(gè)子數(shù)組每個(gè)子數(shù)組只有一個(gè)元素。這在代碼審查時(shí)偶爾會(huì)變成隱藏的坑尤其是當(dāng)size是從配置或變量傳來(lái)的。2.2 它和 slice、split 的區(qū)別在哪很多人分不清 為什么不用 slice 直接截一段其實(shí)答案很簡(jiǎn)單slice 只給你一段chunk 給你全部切成若干段后的完整集合。const arr [1, 2, 3, 4, 5, 6, 7, 8]; arr.slice(2, 5); // [3, 4, 5]只要其中一段 _.chunk(arr, 3); // [[1,2,3],[4,5,6],[7,8]]全切完打包給你如果你要的是取前 10 個(gè)用 slice如果你要的是把 100 條數(shù)據(jù)分成 10 批去處理用 chunk。字符串的 split 按分隔符切和按固定長(zhǎng)度切也是兩回事如果想把字符串按長(zhǎng)度切成塊可以用str.match(/.{1,2}/g)這種偏門寫法但本質(zhì)上還是按位置切的思路。2.3 實(shí)戰(zhàn)里最典型的兩個(gè)場(chǎng)景第一個(gè)是批量請(qǐng)求。假設(shè)有個(gè)老接口一次最多接受 500 個(gè) ID而你有 2 萬(wàn)個(gè)用戶 ID 要逐個(gè)查詳情。你要是直接循環(huán)發(fā)兩萬(wàn)個(gè)請(qǐng)求接口遲早被打爆要是全塞進(jìn)一個(gè)請(qǐng)求又超出限制。正確做法就是用 chunk 把它切成分批const ids await fetchAllUserIds(); // 假設(shè) 20000 個(gè) const BATCH_SIZE 500; for (const batch of _.chunk(ids, BATCH_SIZE)) { await Promise.all(batch.map(id fetchUserDetail(id))); // 每批之間按需 sleep避免觸發(fā)限流 }第二個(gè)是大文件分塊上傳。瀏覽器端File對(duì)象支持的slice方法可以把文件切成多個(gè) Blob前端逐片上傳、記錄已上傳的下標(biāo)斷點(diǎn)續(xù)傳時(shí)只補(bǔ)傳失敗的那幾片。這個(gè)動(dòng)作在業(yè)務(wù)文檔里經(jīng)常被叫分塊上傳或分片上傳它和分區(qū)沒(méi)有任何關(guān)系——切片只是為了對(duì)抗網(wǎng)絡(luò)不穩(wěn)定和單請(qǐng)求超時(shí)。記住一個(gè)判斷標(biāo)準(zhǔn)只要目的是搬運(yùn)或分批處理基本就是 chunk 的活如果目的是按規(guī)則歸檔或組內(nèi)計(jì)算那就不是 chunk 的事。3. PARTITION BYSQL 窗口函數(shù)里的組內(nèi)視角3.1 和 GROUP BY 的輸出差異這是很多人繞不過(guò)的坎PARTITION BY 最常見的混淆對(duì)象是 GROUP BY因?yàn)閮烧叨际前茨沉蟹纸M。它們最本質(zhì)的區(qū)別是GROUP BY 會(huì)折疊行PARTITION BY 不折疊行只是在每一行旁邊多算出一列組內(nèi)聚合值。先看 GROUP BYSELECT dept_id, AVG(salary) AS avg_salary FROM employee GROUP BY dept_id;這個(gè)查詢返回的是部門列表每個(gè)部門一行你看不到任何員工明細(xì)。再看 PARTITION BYSELECT emp_id, dept_id, salary, AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg_salary FROM employee;這個(gè)查詢返回的是每個(gè)員工一行dept_avg_salary列告訴你在同一個(gè)部門里平均工資是多少。你可以拿salary - dept_avg_salary直接判斷這個(gè)員工在部門內(nèi)是高于平均還是低于平均。這就是窗口的含義窗口函數(shù)把結(jié)果集按PARTITION BY的鍵切成多個(gè)邏輯窗口在每個(gè)窗口內(nèi)部獨(dú)立計(jì)算但輸出時(shí)所有原始行都保留。對(duì)比下來(lái)就很清晰比較維度GROUP BYPARTITION BY輸出行數(shù)分組后每組一行原始行全部保留能否同時(shí)返回明細(xì)字段不能隨便選非分組字段可以典型用途出匯總報(bào)表組內(nèi)排名、組內(nèi)對(duì)比、累計(jì)計(jì)算是否屬于窗口函數(shù)不是是必須配 OVER() 使用3.2 最常用的三種寫法組內(nèi)排名、組內(nèi)聚合列、分組取最新組內(nèi)排名是最經(jīng)典的用法最常見的場(chǎng)景是課程成績(jī)排名SELECT student_id, course_id, score, RANK() OVER (PARTITION BY course_id ORDER BY score DESC) AS course_rank FROM exam_score;分組取最新一條是另一個(gè)高頻場(chǎng)景。比如你有一張登錄日志表想拿每個(gè)用戶最近一次登錄記錄。直覺(jué)寫法是 GROUP BY user_id 再取 max(login_time)但那樣拿不到那一整條記錄的其他字段。窗口函數(shù)一行搞定SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC) AS rn FROM login_log ) t WHERE rn 1;內(nèi)層先給每個(gè)用戶的登錄記錄按時(shí)間倒序編號(hào)外層只要編號(hào)為 1 的那條。這個(gè)寫法在取每個(gè)分組的最新/最大/最早一條場(chǎng)景里是標(biāo)準(zhǔn)答案比做兩次 JOIN 或者用相關(guān)子查詢清晰得多。另外PARTITION BY也可以配合SUM、COUNT、MAX做分組累計(jì)或分組對(duì)比。比如訂單表里想看每一筆訂單金額和該客戶歷史累計(jì)消費(fèi)的差距就能用SUM(amount) OVER (PARTITION BY customer_id ORDER BY create_time)構(gòu)造 running total。這些都是 GROUP BY 做不到的因?yàn)?GROUP BY 一旦折疊行數(shù)明細(xì)就沒(méi)了。3.3 PARTITION BY 不是表分區(qū)這個(gè)誤會(huì)必須拆掉如果面試官問(wèn)PARTITION BY 和表分區(qū)有什么區(qū)別你首先要意識(shí)到這個(gè)問(wèn)題其實(shí)是兩個(gè)層面的東西在打架。PARTITION BY 只是計(jì)算語(yǔ)義它告訴 SQL 引擎計(jì)算的時(shí)候按這個(gè)鍵分組。它不會(huì)改變數(shù)據(jù)落盤方式也不會(huì)生成任何新的文件或目錄。你把它寫在一個(gè)普通表上完全沒(méi)問(wèn)題。表分區(qū)是存儲(chǔ)設(shè)計(jì)。它把一張表的數(shù)據(jù)按照分區(qū)鍵分散到不同的存儲(chǔ)片段里目的是方便管理、減少掃描、便于歸檔。兩者是怎么算和怎么存的區(qū)別。最容易被繞暈的是 Hive 里的寫法建表時(shí)用PARTITIONED BY (dt STRING)這是存儲(chǔ)層面的分區(qū)寫 SELECT 時(shí)又可能用OVER (PARTITION BY dt ...)這是窗口函數(shù)。差了兩個(gè)字一個(gè)在 DDL 里一個(gè)在查詢里。想在 SQL 里快速判斷如果 PARTITION BY 前面沒(méi)有OVER(那你看到的 PARTITION BY 大概率是建表語(yǔ)句里的存儲(chǔ)分區(qū)如果它出現(xiàn)在OVER(PARTITION BY ...)這個(gè)語(yǔ)法里就是窗口函數(shù)。4. 分區(qū)Partition把數(shù)據(jù)按規(guī)則放進(jìn)不同的抽屜4.1 數(shù)據(jù)庫(kù)表分區(qū)RANGE / LIST / HASH 的選型思路數(shù)據(jù)庫(kù)里說(shuō)分區(qū)通常指 MySQL、PostgreSQL 這類關(guān)系型數(shù)據(jù)庫(kù)的表分區(qū)。它的目的是把一張邏輯上完整的表在物理上拆成多個(gè)分區(qū)存儲(chǔ)。以 MySQL 為例常見的有三種切法CREATE TABLE orders ( order_id BIGINT NOT NULL, customer_id INT NOT NULL, amount DECIMAL(12,2), order_date DATE NOT NULL, PRIMARY KEY (order_id, order_date) ) PARTITION BY RANGE (YEAR(order_date)) ( PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025) );這里PARTITION BY RANGE是按年份范圍切2022 年的數(shù)據(jù)落在 p2022 分區(qū)2023 年的落在 p2023 分區(qū)。選 RANGE 一般因?yàn)椴樵兲烊粠r(shí)間范圍比如查上個(gè)月的數(shù)據(jù)引擎可以只掃一個(gè)分區(qū)這種能力叫分區(qū)裁剪partition pruning。列表型字段適合PARTITION BY LIST比如按地區(qū)代碼切要打散熱點(diǎn)、均勻分布適合PARTITION BY HASH。使用表分區(qū)時(shí)有幾個(gè)必須知道的限制。第一分區(qū)鍵需要包含在主鍵或唯一鍵里否則建表會(huì)報(bào)錯(cuò)第二查詢條件如果不帶分區(qū)鍵分區(qū)就是擺設(shè)一樣全表掃第三分區(qū)不是讓單條 SQL 變快的銀彈它只在你可以裁剪分區(qū)時(shí)才有效。我見過(guò)一張按月分區(qū)的表因?yàn)榕挪橐粋€(gè)跨半年的問(wèn)題代價(jià)是掃了六個(gè)分區(qū)還不如建對(duì)索引來(lái)的劃算。4.2 大數(shù)據(jù)和消息系統(tǒng)里的分區(qū)Hive、Spark、Kafka 各有各的脾氣到了大數(shù)據(jù)和消息系統(tǒng)分區(qū)這個(gè)詞的含義稍微擴(kuò)展了但核心還是按規(guī)則分成獨(dú)立單元。Hive 里建表寫PARTITIONED BY (dt STRING, region STRING)底層就是在表目錄下生成dt2024-01-01/regionCN/這樣的子目錄查詢時(shí)過(guò)濾 dt 和 region 能直接跳過(guò)大量文件。Spark 里df.write.partitionBy(dt, region)寫 Parquet 文件也是同一個(gè)思路用分區(qū)鍵來(lái)裁剪讀取量。Kafka 里每個(gè) topic 分成多個(gè) partition每個(gè) partition 是有序日志消費(fèi)者并行度上限就是 partition 數(shù)量同一個(gè) key 的消息會(huì)哈希到同一個(gè) partition。這里的 partition 既是存儲(chǔ)單元也是并行單元和數(shù)據(jù)庫(kù)表分區(qū)在精神上是相通的只是承載的語(yǔ)義不同。4.3 分區(qū)、分片、分塊別再互相代稱分塊我們前面說(shuō)過(guò)了是處理時(shí)的位置切分分區(qū)是按規(guī)則切到不同存儲(chǔ)單元還有一個(gè)詞是分片sharding按規(guī)則把數(shù)據(jù)分布到多臺(tái)機(jī)器上。很多人在方案評(píng)審里混著用反而讓溝通變難。動(dòng)作切分依據(jù)主要目的典型例子分塊 chunk固定大小分批搬運(yùn)/處理文件上傳分片、批量查詢分區(qū) partition分區(qū)鍵/規(guī)則存儲(chǔ)組織、查詢裁剪、管理MySQL RANGE 分區(qū)、Hive 分區(qū)目錄分片 shard分片鍵/規(guī)則水平擴(kuò)展、跨機(jī)分布分庫(kù)分表、分布式數(shù)據(jù)庫(kù)一句話提示分塊是在時(shí)間上分批處理分區(qū)是在空間上分組存放分片是把數(shù)據(jù)攤到多臺(tái)機(jī)器。做架構(gòu)時(shí)先分清你要解決的是一次處理太多還是總量太大前者大概率分塊后者才考慮分區(qū)或分片。5. 一個(gè)訂單系統(tǒng)里三個(gè)概念同時(shí)出現(xiàn)的完整案例5.1 從建表到分析的全過(guò)程拆解前面分開講容易真正難的是它們?cè)谕粋€(gè)系統(tǒng)里同時(shí)出現(xiàn)。我拿一個(gè)訂單系統(tǒng)舉例子你跟著走一遍就通了。第一步建表。訂單表每天新增幾十萬(wàn)行要保留兩年DBA 按月份做了 RANGE 分區(qū)CREATE TABLE orders ( order_id BIGINT NOT NULL, customer_id INT NOT NULL, amount DECIMAL(12,2), order_date DATE NOT NULL, PRIMARY KEY (order_id, order_date) ) PARTITION BY RANGE (YEAR(order_date)) ( PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025) );以后每個(gè)月數(shù)據(jù)落在對(duì)應(yīng)分區(qū)查詢帶了order_date范圍就能走裁剪。第二步同步。業(yè)務(wù)要把訂單數(shù)據(jù)同步到搜索集群不能一次性把一個(gè)月的數(shù)據(jù)全塞進(jìn)內(nèi)存。同步程序每次拉 500 條批次序列化成 JSON 發(fā)給下游拉完一批再拉下一批。這一步用的就是分塊思維——用不著真的調(diào)_.chunk一個(gè)循環(huán)加分頁(yè) offset 就夠但本質(zhì)是同一個(gè)分批搬運(yùn)。第三步分析。運(yùn)營(yíng)想看每個(gè)客戶在當(dāng)月每筆訂單金額和該客戶當(dāng)月平均訂單金額的差距。這個(gè)需求就必須用 PARTITION BYSELECT order_id, customer_id, amount, order_date, AVG(amount) OVER ( PARTITION BY customer_id, EXTRACT(YEAR_MONTH FROM order_date) ) AS customer_month_avg FROM orders WHERE order_date 2024-01-01 AND order_date 2025-01-01;PARTITION BY以客戶 月份作為窗口鍵每一筆訂單都被保留下來(lái)旁邊多一列客戶當(dāng)月均值然后就能算差值。同一個(gè)庫(kù)里建表用的分區(qū)、搬運(yùn)用的分塊、分析用的 PARTITION BY三者互不替代、各管一段。5.2 為什么這里不能用 GROUP BY也不能拿分塊去算如果只想出每個(gè)客戶每個(gè)月平均訂單金額這個(gè)匯總用 GROUP BY 當(dāng)然可以而且更簡(jiǎn)單SELECT customer_id, EXTRACT(YEAR_MONTH FROM order_date), AVG(amount) FROM orders WHERE order_date 2024-01-01 AND order_date 2025-01-01 GROUP BY customer_id, EXTRACT(YEAR_MONTH FROM order_date);但需求里說(shuō)了要每筆訂單金額 vs 當(dāng)月均值也就是既要明細(xì)又要聚合GROUP BY 折疊行之后就回不去了。PARTITION BY 的價(jià)值就在于明細(xì) 組內(nèi)統(tǒng)計(jì)值同時(shí)出現(xiàn)。反過(guò)來(lái)分塊在這里完全派不上用場(chǎng)分塊只是搬運(yùn)方式它不提供任何計(jì)算語(yǔ)義你不可能通過(guò)切塊讓 SQL 算出組內(nèi)均值。5.3 這個(gè)案例里最容易出事的三個(gè)細(xì)節(jié)第一分區(qū)鍵沒(méi)進(jìn)查詢條件。有人寫WHERE customer_id 123忘了帶order_date分區(qū)裁剪直接失效引擎掃了從 p2022 到 p2025 全部分區(qū)慢到懷疑人生。第二分塊大小拍腦袋。同步程序一開始把 batch size 設(shè)成 1 萬(wàn)條結(jié)果單批序列化成 JSON 好幾兆下游接口超時(shí)、內(nèi)存暴漲。后來(lái)改成 500 條穩(wěn)了很多。分塊大小要根據(jù)下游處理能力和單條記錄體積調(diào)不是越大越好。第三ROW_NUMBER 排序不穩(wěn)定。前面取每個(gè)客戶最近一筆訂單的例子里如果ORDER BY create_time DESC遇到同一時(shí)刻多筆訂單編號(hào)順序不確定。線上取數(shù)要穩(wěn)定必須加 tie-breaker比如ORDER BY create_time DESC, order_id DESC。6. 一張對(duì)照總表和一套自查方法6.1 三個(gè)概念的一頁(yè)紙對(duì)照概念按什么切輸出結(jié)果所在層面關(guān)鍵記憶點(diǎn)Chunk / 分塊固定長(zhǎng)度/大小多個(gè)同構(gòu)小集合代碼、數(shù)據(jù)流切多大為了搬PARTITION BY分組鍵字段值原始行保留 組內(nèi)計(jì)算列SQL 計(jì)算語(yǔ)義在哪一組里算分區(qū) Partition分區(qū)鍵/規(guī)則數(shù)據(jù)分散到不同存儲(chǔ)單元存儲(chǔ)、架構(gòu)放哪個(gè)抽屜為了存6.2 寫方案和寫代碼時(shí)怎么用詞才準(zhǔn)確我的建議是在文檔和評(píng)審里盡量把話說(shuō)死如果表達(dá)一批一批處理數(shù)據(jù)就說(shuō)分塊/分批處理不要用分區(qū)如果表達(dá)SQL 里按某個(gè)鍵分組計(jì)算排名、聚合列就寫使用 PARTITION BY 窗口函數(shù)如果表達(dá)按日期/字段把數(shù)據(jù)分散存儲(chǔ)才單獨(dú)用分區(qū)。這三個(gè)詞在口語(yǔ)里混用一時(shí)半會(huì)沒(méi)人追究但在接口設(shè)計(jì)、數(shù)據(jù)庫(kù) DDL 討論、項(xiàng)目復(fù)盤里混用真的會(huì)有人照著錯(cuò)誤理解去實(shí)現(xiàn)。6.3 一個(gè)可以隨身用的判斷問(wèn)題每次遇到要把數(shù)據(jù)拆開的需求先問(wèn)一句我是為了傳、為了算、還是為了存為了傳分塊為了算看需求是出匯總還是保留明細(xì)出匯總用 GROUP BY保留明細(xì)又要在組內(nèi)算就用 PARTITION BY為了存再看數(shù)據(jù)體量和查詢模式?jīng)Q定到底要不要分區(qū)、怎么分。個(gè)人體會(huì)是這個(gè)問(wèn)題在帶新人和評(píng)審代碼時(shí)特別好用。逼他們把拆數(shù)據(jù)的目的說(shuō)清楚之后代碼通常也會(huì)清晰很多。這三個(gè)概念一旦在腦子里有了一致的坐標(biāo)之后再看到 chunk、PARTITION BY、分區(qū) 混在一起的文章和討論基本就不會(huì)亂了。