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 與延遲載入這些形態進去，並給出每請求查詢次數預算當判讀基準。

讀者定位

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

章節

推導源頭

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

跨分類引用

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

Backlog