“整整8小時?！薄@是我接手那個夜間批處理任務時，它每次運行所需的時長。團隊已經(jīng)二話不說給它塞了兩次更大的集群，運行時間紋絲不動。等我把一切搞定，同一個集群、同一套算法，跑完全程只花了47分鐘。我連管道里那些“聰明”的部分都沒碰，全部收益都來自數(shù)據(jù)進入系統(tǒng)的第一道關口：解析器。

兩周前，我接過來一個每晚定時運行的批量作業(yè)，單次耗時8小時。團隊之前已經(jīng)兩次升級計算資源，投入了更大的集群，結(jié)果卻像把石頭扔進棉花堆，幾乎沒泛起水花。我的直覺是去看看數(shù)據(jù)入口那幾行代碼——那些因為看起來太枯燥而從來沒人愿意做性能剖析的階段。之后的改動緊緊圍繞解析環(huán)節(jié)展開，最終在不改變?nèi)魏无D(zhuǎn)換、聚合邏輯的情況下，把整體運行時間壓縮到了47分鐘。

為了解釋清楚這件事，我們得先對齊一個基礎概念：什么是數(shù)據(jù)管道里的“層”？管道就是一條處理鏈，原始數(shù)據(jù)從一端流進，另一端流出可用的結(jié)果。典型鏈路是：
原始文件 → 解析 → 轉(zhuǎn)換 → 聚合/建模 → 輸出。
其中解析（也叫攝取或反序列化）就是把原始文本——比如一行JSON、一個CSV、一條日志——變成程序可以直接操作的對象。磁盤上的字節(jié){"id": 7}，在內(nèi)存里成為字典{"id": 7}。這筆轉(zhuǎn)換不是免費的。轉(zhuǎn)換做的是清洗、變形、連接、特征計算；而聚合或建模，才是大多數(shù)人眼里的“正經(jīng)工作”——算法、SQL、數(shù)學運算。

這里有一個幾乎沒人早早內(nèi)化的真相：排在最前面的那個小方框“解析”，經(jīng)常比后面所有步驟加起來都貴。而且因為它堵在入口，下游每一個環(huán)節(jié)都得替它交稅。解析器一慢，管道里等它輸出的所有階段全被拖慢。于是，一旦管道跑得慢，下意識的反應就是去加速那些“智能”部分。可事實往往是，那些聰明部分從來就不是問題的根源。

所以，這條經(jīng)驗必須擺在第一條：永遠不要優(yōu)化你還沒測量的東西。在改動哪怕一行代碼之前，先搞清楚時間到底花在了哪。這個習慣比任何優(yōu)化技巧都重要，而實現(xiàn)它的代碼只需三行：

import timefrom contextlib import contextmanager@contextmanagerdef stage(name):    start = time.perf_counter()    yield    print(f"{name:<18} {time.perf_counter() - start:6.2f}s")

用這個上下文管理器把管道的每個階段包裹起來，比如：

import jsonwith stage("read + parse"):    records = [json.loads(line) for line in open("events.jsonl")]with stage("transform"):    rows = [transform(r) for r in records]with stage("aggregate"):    result = aggregate(rows)

你會看到類似這樣的輸出，而這一小段打印就是故事的全部：

read + parse     372.10stransform          48.30saggregate          12.05s

解析環(huán)節(jié)吃掉了86%的運行時間。所有人想優(yōu)化的“數(shù)據(jù)科學”部分，不過是上面那兩行不起眼的數(shù)字。要是你需要更細的粒度——比如想搞清楚解析內(nèi)部哪個函數(shù)最慢——可以直接祭出Python自帶的剖析器：

import cProfilecProfile.run("run_pipeline()", sort="cumulative")

看輸出前幾行。如果loads、decode、raw_decode或scanstring這些名字高高掛起，那你找到的，就是那個拖慢一切的JSON解析器。

整個故事回溯下來，一個8小時的夜間作業(yè)，兩次加集群沒帶來的加速，最后靠的是對一個沒人想多看一眼的環(huán)節(jié)做了一次精準測量和針對性修理。47分鐘，同集群、同算法，只因為數(shù)據(jù)進門的方式變了。別急著去動后面的重頭戲，先問問你的解析器在干什么，答案可能比多要幾臺機器值錢得多。