技術到底該怎麼選:讀《Fundamentals of Data Engineering》Ch.4
· tech
上一篇講架構(why);這一章接著問:在那個架構底下,技術(how)到底該怎麼選? 這章最該先釘進腦袋的一句話是 —— 先有架構,才選技術,不是反過來。 工具是手段,被架構的取捨牽著走;一上來就問「要用哪個工具」,順序就已經錯了。
一個太常見的錯誤:先愛上工具
很多團隊的決策長這樣:看到一個當紅的工具 → 決定要用 → 再回頭把架構湊上去。書直接把它翻過來:架構決策(為什麼這樣切系統、願意拿什麼換什麼)在前,技術決策(用哪個產品落地)在後。 工具只是服務於取捨的選項,不該是出發點。
那麼,當你站對了順序、要開始選技術時,書給了一整排判準。我把它濃縮成一張表:
| 判準 | 在問什麼 |
|---|---|
| 團隊規模與能力 | 你們養得起、駕馭得了這個東西嗎? |
| 上市速度 | 多快能把價值交出去?(常被低估) |
| 互通性 | 跟既有的東西接得起來嗎? |
| 成本 | TCO、TOCO、FinOps(見下) |
| 現在 vs 未來 | 不變的地基 vs 易變的表層(見下) |
| 位置 | 雲端 / 地端 / 混合 |
| 自建 vs 採購 | 這值得你自己造嗎?(見下) |
| 單體 vs 模組 | 綁成一塊,還是可拆換的元件? |
| 無伺服器 vs 伺服器 | 誰來扛維運? |
這表裡有三條我覺得最該深挖、也最能改變決策方式的:現在 vs 未來、自建 vs 採購、成本。
核心一:不變的地基 vs 易變的表層
書區分兩種技術:不變的(immutable)與易變的(transitory)。不變的,是那些撐了幾十年、短期內不會消失的底層 —— 物件儲存、SQL、網路、Unix / bash;易變的,是來來去去的框架、函式庫、當紅工具,可能三年後就沒人提了。
書的建議很清楚:把架構錨定在不變的地基上,把易變的表層設計成可抽換。 SQL 跟物件儲存你押三十年都不太會錯;某個今年最紅的框架,別讓它滲進系統每個角落、把你綁死。這跟 Ch.3 講的鬆耦合與可逆是同一條神經 —— 賭在穩的東西上,讓會變的東西可以局部換掉。
核心二:自建 vs 採購
第二個關鍵判準:這個東西,你該自己建,還是買 / 用現成的?書給的心法是一個問題 —— 這是不是你的核心差異化?
書的立場(也是我的立場):預設買 / 用現成,自建是例外。 Amazon 那句「不做沒有差異化的粗活(undifferentiated heavy lifting)」就是這意思 —— 沒有差異化的東西自己扛,只是把維運債堆給未來的自己。這跟 Ch.1 的「A 型工程師優先」是同一句話的不同講法:造輪子的時機是規模逼出來的,不是拿來證明技術力的。
順帶一提,「採購」也不是只有「全買商業產品」一種。它是一條光譜:社群版開源 → 商業化開源(有人幫你扛維運的託管版)→ 全託管專有產品。愈往右,你付愈多錢換愈少維運負擔 —— 又是一個取捨。
成本要算兩本帳:TCO 與 TOCO
選技術繞不開成本,但書提醒:成本不只一本帳。
| TCO(總持有成本) | TOCO(總機會成本) | |
|---|---|---|
| 在問 | 用這個要花多少? | 被綁在這、不選別的,放棄了什麼? |
| 算得到的 | 授權、機器、人力、維運 | —— |
| 容易漏的 | 隱性的整合與維運成本 | 鎖定、回不去、錯過更好的選項 |
大多數人只算 TCO(看得到的帳單),但書點出更隱形、也常常更貴的是 TOCO —— 你選了 A,等於放棄了 B、C、D,而且如果 A 把你鎖死,未來想換的代價會高到回不去。這跟 Ch.3 的可逆性是同一件事的成本面:不可逆的選擇,真正的價碼不在帳單上,而在「改不了主意」這件事上。
再加上書一直強調的 FinOps —— 雲端成本不是簽完約就固定的數字,而是一個要持續設計、持續監看的變數。用多少付多少很彈性,但也代表帳單會隨著你寫的每一支爛 query 一起長。
反思
「先架構後工具」是我這半年最該對自己喊的一句
我寫了一整排工具筆記(Airflow、Spark、Kafka、dbt),很清楚那種「學到一個很炫的工具,就很想找地方用它」的衝動。但這章把順序釘死了:先講清楚架構上的取捨,工具才上場。 這跟我那篇 先確認痛點,再上重武器根本是同一條神經 —— 沒有先確認痛點與約束,再潮的工具都是為了用而用。我現在檢視技術選型,第一句都先問「我們是為了解決哪個取捨而選它」,而不是「它有多強」。
我下注的地方,幾乎都在「不變的地基」
回頭看,我做過的選擇裡感覺最安心的,清一色押在 immutable 那一層:堅持用 SQL 當轉換語言、把原始資料攤在 物件儲存 上、在 Medallion 裡守著 Bronze 不可變、可重播。這些東西十年後大概還在。反過來,那些當年覺得「一定要用」的框架,不少已經沒人維護了 —— 慶幸的是我沒讓它們滲進系統的核心。把賭注下在穩的東西上,讓會變的東西可拋棄,是我越來越信的一條原則。
自建 vs 採購,我栽過「為了證明能力而造輪子」的跟頭
「預設用現成」這條,我是付過學費才真的信。早期我有過為了某個其實買得到的功能、硬是自己刻一套的經驗 —— 當下很有成就感,半年後變成沒人想碰的維運包袱。書用「沒有差異化的粗活」一刀切得很準:自建的成本從來不是寫出來那一刻,而是之後每一年的維護。 現在我的預設是買 / 用託管,只有當「這真的是我們能拉開差距的地方」才自己動手 —— 而這種地方,遠比工程師想像的少。