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