Web 後端：以一次請求用到的幾筆資料為單位

資料的單位是這次請求要用到的那幾筆。使用者按下一個按鈕，程式取出對應的幾列、改幾個欄位、寫回去，然後這次請求就結束了。

工具解的是把那幾筆安全地取出與改回去：ORM 把資料列包成物件、連線池管理與資料庫之間的連線、遷移工具讓表結構跟著程式一起演進。Django 與 FastAPI 這類框架的周邊生態幾乎都繞著這件事。

Web 後端的失敗形態跟著單位走。一次請求裡不小心打了一百次資料庫（每筆各查一次），或是把交易的範圍包得太大而讓鎖持有太久（一段時間內不讓別人動同一批列，範圍越大擋得越久），都是「一次應該只取幾筆」這個前提被破壞的結果。

資料工程與分析：以整張表或整批事件為單位

資料的單位是整張表，或某段期間的全部事件。沒有「這次請求」這種邊界，取而代之的是「這批」。

資料工程與分析的工具鏈因此分成三組，各解一件事：整批資料怎麼算（pandas 在單機記憶體裡算，Spark 把同一件事拆到多台機器上），轉換邏輯怎麼版本控管（dbt 把每一步轉換寫成可以被審閱與測試的模型），以及什麼時候算、失敗了怎麼重跑（Airflow 這類排程器）。

失敗形態也整組換掉：這批裝不裝得進記憶體、同一批會不會因為重跑而被算兩次、上游的欄位改了名字而下游整條流程靜默算出錯的結果。

機器學習：接在批次處理後面的數值矩陣

模型收的是一個數值矩陣。原始資料很少長成那個樣子，所以把它整理成矩陣的那一段仍然是批次處理——合併幾張表、把類別欄位轉成數值、補掉缺值、切出訓練與驗證。

pandas 在這裡是前置作業，PyTorch 這類框架接在它後面。機器學習與資料工程共用工具鏈的前半段，分歧在後半段。

自動化與系統工具：以一個檔案或一次執行為單位

自動化腳本處理的是檔案、程序與外部命令。單位是一個檔案或一次執行，資料本身是被搬運的內容。工具是 pathlib、subprocess、argparse 這一組，也就是 模組三 的內容。

系統與工具開發再往外一層：產出是被別人 import 或執行的程式，資料由使用者帶來。關心的是介面設計、相容性與封裝。

各組工作的失敗形態、判斷材料與檢索關鍵字的差異

單位決定了什麼事情會出錯，而這幾組的單位不同，出錯的形態就沒有交集。

把一次請求的查詢次數壓下來，靠的是理解物件與資料列之間的對應關係；判斷一批資料裝不裝得進記憶體，靠的是估算列數乘欄數乘每格佔幾個位元組。這兩種判斷用的材料完全不同，前一種做得再熟也不會讓後一種變容易。

檢索的結果跟著同一條軸分開。以物件關聯對映與請求生命週期為關鍵字找到的內容，與以 DataFrame 和排程為關鍵字找到的內容幾乎不重疊，因為它們描述的是不同的問題。一個人如果只用其中一組關鍵字搜尋，另一組的內容不會被結果帶到他面前——要看到它得先知道該用哪些詞。

這幾組工作在職務名稱上也各自分開，Python 只是它們共用的語言。

延伸閱讀：運算發生的位置、Web 後端的資料庫議題、商業分析指標、標準庫的檔案與外部命令工具

批次處理再往下切一刀：整批資料要嘛留在資料庫裡算，要嘛搬進程式的記憶體算。8.2 運算發生的位置 寫這條分界怎麼決定工具的形狀，以及 Python 存取資料庫的三種寫法為什麼全部落在資料庫那一側。

Web 後端的資料庫議題：一次請求該打幾次資料庫、交易邊界包到哪裡、ORM 的延遲載入什麼時候變成問題。backend 模組一 從這些形態進去，並給出每請求的查詢次數預算當判讀基準。

批次算出來的結果拿去做什麼：monitoring 模組八 寫留存、分群與轉換率各自怎麼定義，以及事件當初的屬性設計決定了哪些指標事後算得出來。

自動化的工具：模組三 收的是處理檔案與外部命令的標準庫，單位是一個檔案或一次執行。

資料庫端：DB-API、查詢建構器與 ORM 的寫法

程式送出的是一段描述要算什麼的文字，資料庫收下之後自己完成篩選、合併與彙總，把結果送回來。原始資料從頭到尾沒有進入程式。

Python 這一側有三種寫法，差別只在那段 SQL 由誰組出來。

自己寫 SQL 字串：sqlite3、psycopg2 這類套件遵循 DB-API 這個標準介面，程式把 SQL 交給它，它負責送出與取回。

用方法串出 SQL：SQLAlchemy Core 這類查詢建構器提供 Python 的方法對應 SQL 的子句，組出來的仍然是一段 SQL。

用類別描述表：ORM 這一類工具（SQLAlchemy、Django ORM）把資料表對應成類別、把資料列對應成物件，篩選條件寫成屬性比較，框架據此組出 SQL，並把回來的每一列包成物件。

三者的共同點比差異重要：運算在資料庫那一端發生，程式收到的是算完的結果。編譯出來的 SQL 可以直接印出來看：

1from sqlalchemy import select
2stmt = select(Customer).where(Customer.age > 18)
3print(stmt.compile(engine))
4# SELECT customer.id, customer.name, customer.age FROM customer WHERE customer.age > ?

記憶體端：pandas 與 DataFrame

搬進記憶體端的做法是把資料整批載進程式，運算由程式自己完成。pandas 屬於這一側，它的容器是 DataFrame。

1df[df["age"] > 18]

這一行沒有連線、沒有查詢語句、沒有資料庫。df 是一張已經在記憶體裡的表格，這一行做的是對一個布林陣列取值。資料的來源可以是資料庫，也可以是 CSV、日誌檔或某個 API 回傳的內容——載進來之後，接下來的每一步運算都寫成一樣的形式，來源是哪一種不再影響寫法。

兩端分工的條件：資料量、SQL 的表達能力、算完之後的用途

資料量。 記憶體端要把資料整批放進來，所以容量是硬上限；資料庫端沒有這個限制，它一次只需要把符合條件的部分送回來。

要算的運算 SQL 表達得出來嗎。 篩選、合併、分組彙總、排名，SQL 都寫得出來。統計檢定、時間序列的滑動窗口、把資料餵給模型，SQL 寫起來吃力或根本沒有對應語法，這些落在記憶體端。

算完之後還要做什麼。 結果如果只是要回傳給使用者或寫回另一張表，留在資料庫端的路徑最短——資料不必先進記憶體再送出去；如果後面還要接繪圖、統計或模型訓練，資料終究要進記憶體，那就沒有理由分兩段做。

實務上的常見形態是兩端接力：用 SQL 把資料量先壓下來，再把壓縮過的結果搬進記憶體做後面的部分。

1df = pd.read_sql("SELECT * FROM orders WHERE year = 2024", conn)
2# 這一行之後全部在記憶體裡，與資料庫無關

DuckDB：在同一個程序裡用 SQL 查 DataFrame 與檔案

DuckDB 兩邊都站：它接受 SQL，而查詢的對象可以是記憶體裡的 DataFrame，也可以是磁碟上的檔案。

1duckdb.sql("SELECT dept, count(*) c FROM emp GROUP BY dept")  # emp 是一個 DataFrame

它把「資料庫」這個角色從一台獨立的伺服器換成同一個程序裡的運算引擎，而軸本身仍在——差別只在資料要不要複製一份進 Python 的記憶體。

延伸閱讀：ORM 與 DataFrame 的分辨、SQL 與 pandas 的寫法對應、pandas 的記憶體邊界、資料庫端的工程議題

從回傳值認出手上是哪一類：資料庫端的工具回傳的是物件或資料列，記憶體端的工具回傳的是一張新的表。8.3 ORM 與 DataFrame 的分辨：回傳值的形狀、連線物件與查詢送出的時機 寫兩者各自產出什麼，以及外觀相似的方法串接底下差了什麼。

兩端共用的那套抽象：篩選、合併、分組彙總在兩端都有，而且對應得起來。8.4 SQL 子句與 pandas 方法的對應：篩選、連接、分組彙總、視窗函數，以及空值、索引與順序的語意差異 給篩選、連接、分組彙總與視窗函數在兩邊的實測比對，以及空值、索引與順序這幾處對應斷掉的位置。

記憶體端的容量上限：8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給資料量的估算方法、運算過程額外要的空間，以及越過之後三個方向各自付什麼代價。

資料庫端那一側的工程議題：連線池、交易邊界、一次請求該打幾次資料庫，在 backend 模組一。那個模組從 N+1 與延遲載入這些形態進去，並給出每請求查詢次數預算當判讀基準。

ORM 的產出與運算發生的位置

ORM 把資料表對應成類別、把資料列對應成物件。篩選條件寫成屬性的比較式，框架把它翻譯成 SQL 的 WHERE 子句。

 1from sqlalchemy import select
 2from sqlalchemy.orm import Session
 3
 4stmt = select(Customer).where(Customer.age > 18)
 5print(stmt.compile(engine))
 6# SELECT customer.id, customer.name, customer.age FROM customer WHERE customer.age > ?
 7
 8with Session(engine) as s:
 9    rows = s.scalars(stmt).all()
10    print([type(r).__name__ for r in rows], [r.name for r in rows])
11    # ['Customer'] ['A']

stmt 本身還沒有做任何運算，它是一段待送出的查詢。運算在資料庫那一端完成，回來的每一列被包成一個 Customer 實例——所以拿到的是物件，可以呼叫它的方法、走訪它關聯到的其他物件。

DataFrame 的產出與運算發生的位置

pandas 這一側的同一件事：

1df = pd.DataFrame({"id": [1, 2], "name": ["A", "B"], "age": [20, 10]})
2df[df["age"] > 18]
3#    id name  age
4# 0   1    A   20

df["age"] > 18 先算出一個布林陣列 [True, False]，外層的取值用這個陣列挑出要留下的列。整段運算發生在這個程序的記憶體裡，沒有連線、沒有 SQL、沒有另一個系統參與。

回來的是一張新的表格，不是一組物件。它可以繼續被篩選、被合併、被彙總，因為表格正是這些操作接受的輸入。

分辨 ORM 與 DataFrame 的訊號：回傳值的形狀、連線物件、查詢送出的時機

外觀相似的方法串接底下，有三個分得開的訊號。

回傳值的形狀。 一組各自獨立、可以呼叫方法的實例，是 ORM 那一側；一張有欄有列、可以繼續被篩選與彙總的表格，是 DataFrame 那一側。

有沒有連線物件。 資料庫端的工具一定要先有一個連線或 session，因為運算要送去別的地方。pandas 的操作不需要：資料一旦載進 DataFrame，之後每一步都在這份記憶體裡的副本上進行，原本那個資料庫或檔案後來有沒有變動都不影響它。

查詢送出的時機。 ORM 允許先把查詢組好、之後才送出，所以「描述」與「執行」是兩個時刻。pandas 的每一行敘述當場就算完，中間沒有待送出的狀態。

各語言生態的資料庫存取分層：手寫 SQL、查詢建構器、ORM

自己寫 SQL、用建構器組 SQL、用 ORM 對應物件，這三層在多數語言生態裡都找得到對應的套件，名字不同而分層一致。各語言的代表工具，以及手寫 SQL 再細分成驅動、結果對映、從 SQL 產生程式碼的方式，見 1.17 應用程式存取資料庫的工具分層。

DataFrame 這一層則是額外的第四種，它不在上面那條線上——它處理的是已經在記憶體裡的表格，與資料庫的存取方式無關。一般的增刪改查應用不使用它，那是 ORM 的位置。

延伸閱讀：SQL 與 pandas 的寫法對應、運算發生的位置、pandas 的記憶體邊界、ORM 的查詢反模式

這兩側共用的抽象：ORM 產生的 SQL 與 DataFrame 的方法，做的是同一組操作。8.4 SQL 子句與 pandas 方法的對應：篩選、連接、分組彙總、視窗函數，以及空值、索引與順序的語意差異 給篩選、連接、分組彙總與視窗函數在兩邊的實測比對，以及空值、索引與順序這幾處對應斷掉的位置。

分界本身：兩側的差異全部從「運算發生在哪一端」推出來。8.2 運算發生的位置 寫這條軸怎麼決定容量上限與失敗形態，以及選邊時要問的三個條件。

選了記憶體端之後的上限：8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給資料量的估算方法與越過之後的三個方向。

ORM 那一側的失敗形態：延遲載入什麼時候把一次請求變成一百次查詢，在 backend 模組一的查詢反模式。那一篇把 N+1 與長交易列成可診斷的清單，並給出每請求的查詢次數預算。

換介面重寫一次同樣的邏輯因此是划算的練習：邏輯已經想清楚了，剩下的是查另一套語法怎麼寫。

篩選、連接、分組彙總與視窗函數的兩邊寫法

以下的 emp 兩邊是同一份資料，一邊在 SQLite 裡、一邊在記憶體的 DataFrame 裡。

篩選：挑出符合條件的列

1SELECT name FROM emp WHERE salary > 150

1emp[emp["salary"] > 150][["name"]]

連接：把兩張表按鍵值接起來

1SELECT e.name, d.dname FROM emp e JOIN dept d ON e.dept = d.dept

1emp.merge(dept, on="dept")[["name", "dname"]]

分組彙總：每一組收斂成一列

1SELECT dept, MAX(salary) AS m FROM emp GROUP BY dept

1emp.groupby("dept", as_index=False)["salary"].max().rename(columns={"salary": "m"})

視窗函數：算出分組的統計值並保留原本的每一列

1SELECT name, salary - AVG(salary) OVER (PARTITION BY dept) AS d FROM emp

1emp.assign(d=emp["salary"] - emp.groupby("dept")["salary"].transform("mean"))[["name", "d"]]

transform 是這一組裡最值得記的：它與 agg 的差別正是視窗函數與 GROUP BY 的差別——agg 讓每一組收斂成一列，transform 把組的統計值攤回組內的每一列。

這四組在同一份資料上跑出來的結果逐格相同。

對應斷掉的位置：分組時的空值、索引、順序

有三個地方兩邊的語意本來就不同，照著逐句翻譯會在這裡失準。

空值在分組時的去留。 SQL 的 GROUP BY 把 NULL 當成一組，pandas 的 groupby 預設把分組鍵是缺值的那些列排除掉，於是那一組在結果裡整組消失。

1t.groupby("k").size()                 # {'x': 1}          缺值那一組消失了
2t.groupby("k", dropna=False).size()   # {'x': 1, nan: 2}  與 SQL 一致

同一段邏輯照著翻譯過來，統計結果會少掉一整組而且不會報錯。這是篩選、連接、分組彙總與視窗函數這幾組對應之外最容易靜默出錯的一項。

索引。 DataFrame 的每一列有一個索引，它獨立於欄位存在，而且會在 groupby、merge 之後改變。SQL 沒有對應的概念。翻譯過來的程式碼常常需要 reset_index() 或 as_index=False，那幾個呼叫處理的正是索引這個 SQL 沒有的狀態。

順序。 SQL 的查詢結果在沒有 ORDER BY 時不保證順序。DataFrame 的列有位置順序，而且多數操作會保留它。所以「相同的結果」在順序這一維上兩邊本來就不可比——可比的是集合，而集合的比較要先各自排序才成立。

延伸閱讀：運算發生的位置、ORM 與 DataFrame 的分辨、SQL 的視窗函數與語言設計、pandas 的記憶體邊界

這兩個介面為什麼會分家：一邊把運算交給資料庫，一邊在自己的記憶體裡算。8.2 運算發生的位置 寫這條分界怎麼決定容量上限，以及選邊要問的三個條件。

同一個對比在 SQL 那一側怎麼講：transform 對 agg 的差別就是視窗函數對 GROUP BY 的差別。SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列 用輸出的單位當判斷標準，並示範相鄰的定義漏掉分區之後會跨到別的組上。

從產出認出手上是哪一個介面：8.3 ORM 與 DataFrame 的分辨：回傳值的形狀、連線物件與查詢送出的時機 寫兩者的回傳值形狀差在哪，以及分得開它們的三個訊號。

這套代數在 SQL 那一側怎麼設計：關聯代數的組合規則決定了子句的先後、連接的左右與分組的鍵，而那些規則各有一處與直覺相反。SQL：這個語言為什麼長這樣 從語言的宣告式性質推導這一整組規則，並另外處理文字之外的四方（識別字規則、引擎的寬鬆度、權限、最佳化器）。

換介面之後接手的新限制：SQL 那一側沒有記憶體上限的問題，換到 DataFrame 就有了。8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給估算方法與越過之後的三個方向。

資料本身的佔用量估算

數值欄位每一格佔固定的位元組數，所以列數乘欄數乘每格的位元組數就是估算值。int64 與 float64 各佔 8 個位元組。

五百萬列、兩個數值欄的表格實測佔 76 MB，與 5,000,000 × 2 × 8 = 80 MB 相符。這個量級對現在的機器不構成問題，往上推一個量級（五千萬列）到 760 MB 仍然可行，再往上就要看機器。

字串欄位不適用這個乘法，它的佔用取決於實際的字元內容與 pandas 的字串儲存方式——這一欄只能量，不能算，量的方式是 df.memory_usage(deep=True)。

運算過程的中間結果佔用的空間

估算容易漏掉的是中間結果。合併與分組會產生暫時的陣列，而它們與原始資料同時存在於記憶體裡。

實測一次 merge：兩張表本身合計 38 MB，合併結果 46 MB，而合併期間的額外配置峰值是 136 MB——大約是那兩張表合計 38 MB 的三倍半。

所以判斷標準是「資料量的數倍要放得下」，而不是「資料量放得下」。倍數隨操作而變，合併與排序這類要重排全部資料的操作最高。

越過記憶體邊界之後的方向：推回資料庫、換引擎、分散式

把運算推回資料庫。 資料如果本來就在資料庫裡，先用 SQL 把量壓下來再載入。這條路不需要換工具，代價是那段運算必須用 SQL 表達得出來。

換成不需要全部載入的引擎。 DuckDB 接受 SQL，而查詢的對象可以直接是磁碟上的檔案。實測查一個 129 MB 的 CSV 算出列數與平均值，Python 端的配置峰值是 0.0 MB；同一件事用 pandas 先載入再算，峰值 114.5 MB、載入後的 DataFrame 佔 76 MB。

這裡的 0.0 MB 要照字面讀：量的是 Python 自己配置的記憶體，DuckDB 的運算發生在它自己的引擎裡、記憶體不經過 Python 的配置器。它逐段讀檔案，任何時刻只持有其中一段。

Polars 走的是另一條類似的路：介面接近 DataFrame，而它的延遲執行模式讓整段運算先被規劃過再執行，可以只讀用得到的欄位。

換成分散式。 資料量大到單機放不下時才走這個方向。Spark 把同一份運算拆到多台機器上，代價是叢集本身的維運成本與除錯難度，兩者都比單機高一個量級。

記憶體不足與跑得慢的分辨

記憶體不足有它自己的訊號：程序被作業系統終止，或者機器開始把記憶體換出到磁碟而整體速度崩落。這兩種現象都來自同一件事——需要的空間超過實體記憶體，作業系統只能終止程序或改用磁碟頂替。

跑得慢的成因在別處。逐列套用函式而沒有用向量化的操作，慢的是每一列都要繞一趟 Python 直譯器；反覆複製整張表，慢的是記憶體頻寬。這兩種都與容量無關，所以資料量再小它們也照樣發生，換到容量更大的工具上也照樣發生。

分開這兩者的意義在於推回資料庫、換引擎與分散式這幾個方向只解記憶體不足那一種。

延伸閱讀：運算發生的位置、SQL 與 pandas 的寫法對應、商業分析指標

推回資料庫這個方向的另一端：8.2 運算發生的位置 寫兩端的分工由哪三個條件決定，以及 DuckDB 為什麼同時站在兩邊。

推回去之後要用的語法對照：8.4 SQL 子句與 pandas 方法的對應：篩選、連接、分組彙總、視窗函數，以及空值、索引與順序的語意差異 給篩選、連接、分組彙總與視窗函數在兩邊的實測比對，以及翻譯時最容易靜默出錯的空值處理。

這批資料算出來之後拿去做什麼：monitoring 模組八 寫留存、分群與轉換率各自怎麼定義，以及事件當初的屬性設計決定了哪些指標事後算得出來。

讀者定位

有程式經驗、SQL 大致能寫，但沒有做過批次資料處理的工程師。Web 後端背景的讀者會發現這一側的工具跟熟悉的那一套幾乎沒有交集，而模組的第一篇就在解釋這件事。

章節

推導源頭

各篇的判斷標準都折算回 8.2 的那條軸：運算發生在資料庫端還是程式的記憶體端。8.3 是這條軸兩側的產物比對，8.4 是兩側共用的抽象，8.5 是記憶體端那一側的容量上限。8.1 在軸之前，負責說明為什麼會有這條軸要分。

跨分類引用

• → backend 模組一 資料庫：運算留在資料庫端那一側的工程議題，N+1 與交易邊界都在那裡
• → SQL：這個語言為什麼長這樣：資料庫端那一側用的語言本身——子句怎麼切、連接的左右決定誰被保護、代價為什麼不在查詢的文字裡
• → monitoring 模組八 行為資料的商業利用：批次算出來的指標怎麼定義，以及事件屬性決定哪些指標算得出來
• → python 模組三 標準庫實戰：自動化那一格用到的工具，處理的單位是檔案與程序而不是資料集

Backlog

三個分開的地方

列有沒有順序。 DataFrame 的列從頭到尾有一個位置，可以問「第三列是什麼」。關係沒有順序這個屬性，SELECT 回來的列要靠 ORDER BY 才排得出來。

誰在算。 對 DataFrame 的每一個操作在自己的行程裡執行，資料先整批進記憶體；對關係的操作交給資料庫引擎，程式收到的只有結果。上限因此不同——一邊是這台機器的記憶體，一邊是資料庫的儲存。

寫下的是動作還是描述。 DataFrame 的程式碼是一串照順序發生的動作：載入、篩選、合併。SQL 寫下的是要什麼結果，怎麼算由引擎決定。這一條是 SQL 這個分類每一篇的起點。

概念位置

DataFrame 在 SQL 那個分類裡的角色是對照組。宣告式這個性質單獨看不出形狀，跟一段逐步執行的程式並排才清楚——同一件事，一邊每一行指定下一步做什麼，一邊只描述要什麼。

兩邊的底層是同一套 關聯代數，所以多數操作對得上；對不上的地方正好落在上面那三項差別上。

往下走

宣告式與逐步執行的完整對照、以及三種順序的分工，在 SQL.1 宣告式的紅利與代價。同一組操作在兩種介面上的四組對應與對應斷掉的三個位置，在 python 模組八 8.4。