#book-notes

instance 專屬設定 應用與它的設定 烘烤線 agent・共用設定 套件與 runtime 基底 OS 線以上:開機時才灌(fry) 彈性、改了馬上生效; 但開機慢、開機時可能失敗 線以下:烤進 image(bake) 每台一模一樣、開機即用; 但改一行要重建 image 線可以移:往上移=開機快、變更慢;往下移=變更快、開機慢——沒有免費的方向

Servers as Code:烘烤線畫在哪,決定你開機多快、改動多痛

· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #8

Stack 那層管的是「有哪些資源」;這篇往下鑽進資源裡最有內容物的那種——伺服器本身。一台 server 從開機到能服務,身上堆了一整疊東西,而 IaC 在這層要回答兩個問題:這疊東西什麼時候放上去…

#iac#devops#book-notes

複製貼上 一包全裝 可重用 stack code A code A' code A'' dev staging prod ✗ 三份 code 各自漂移 改三次,忘一次就失真 一份 code 同一個 stack(同一份 state) dev stg prod ✗ 環境共用爆炸半徑 改 dev 的失誤可能炸到 prod 一份定義 dev staging prod 各自的 state,差異只在參數檔 ✓ 測過的那份定義 就是上線的那份

Stack 與環境:staging 不該是另一份 code,是同一份的另一個 instance

· tech · 約 5 分鐘 · 📚 Infrastructure as Code 讀書筆記 #7

進入書的第二部分:stack。前面講切割時一直在說「一個 stack」怎樣怎樣,這篇先把這個詞站穩,再處理它最日常的應用場景——同一包基礎設施,要生出 dev、staging、prod 好幾份。這件事…

#iac#devops#book-notes

單體:爆炸半徑 = 全部 小元件:爆炸半徑 = 一塊 網路 資料庫 服務 A ← 改這 服務 B 監控 權限 改一行,整包一起 plan、一起冒險 網路 stack 資料 stack 服務 A ← 改這 服務 B 只 plan、只動這一塊;其他透過介面往來

小而簡單的元件:爆炸半徑決定你敢不敢改

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #6

三個核心實踐的最後一個。上一篇說變更批次要小,這篇補上它的前提:批次小得起來,元件先要小——如果整個系統是一包巨大的 stack,再小的改動也會被迫帶著整包一起上路。這章講的就是怎麼把基礎設施切成「小…

#iac#devops#book-notes

端到端・整合 起一個真的測試 stack 單元測試・plan 預覽 靜態分析:lint・validate・policy as code 回饋:秒 → 分 → 十分鐘

持續測試與交付:品質來自快回饋,不是守關卡

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #5

三個核心實踐的第二個。上一篇把一切變成程式碼之後,下一個問題自然是:程式碼會錯,怎麼知道這次變更是安全的?書的答案跟傳統直覺相反——不是在上線前設一道更嚴的關卡,而是把驗證拆碎、塞進工作的每一步。品質…

#iac#devops#book-notes

定義檔(想要的終點) web 伺服器 × 3 現況 web 伺服器 × 2 比對(plan) 差異:+1 台 執行(apply) 只補差異的部分 把現況推向定義 跑第二次?比對差異 = 0 → 什麼都不做。這就是冪等

一切皆程式碼:宣告式寫終點,程序式寫路徑

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #4

前三章鋪完為什麼、原則、平台,從這章開始進入三個核心實踐,第一個就是招牌:把所有東西定義成程式碼——不只伺服器,網路、pipeline、監控、權限,全部。好處書裡列得很整齊(可重用、一致、透明、可測試…

#iac#devops#book-notes

應用層 你的產品與服務 應用執行環境 Kubernetes、PaaS、資料庫叢集 基礎設施平台 運算 VM · 容器 · FaaS 儲存 block · object · DB 網路 VPC · LB · DNS 可程式化(API) 隨需(分鐘級) 自助(不用開票)

基礎設施平台:你家的雲,是真的雲嗎?

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #3

前兩章講完 為什麼和原則,第三章回頭補一個地基問題:IaC 要有東西可以 code——你的定義檔寫得再漂亮,也要有一個收到 API 呼叫就能生出資源的平台在下面接著。這章就在講這個「動態基礎設施平台」…

#iac#devops#book-notes

前提:任何元件隨時會壞(便宜的 commodity 硬體) 流程可重複 + 變異最小化 一切可重現 從定義檔重建任何東西 一切可拋棄 牛,不是寵物 故障=例行重建 不再是災難 可靠性從「硬體不會壞」搬到「軟體重建得快」 鏈條由左往右:上游做不到,下游全是空談

雲時代基礎設施的原則:壞了就重建,可靠性來自軟體

· tech · 約 4 分鐘 · 📚 Infrastructure as Code 讀書筆記 #2

第一章說雲時代該擁抱變更,這章回答「憑什麼敢」。前提先翻轉:鐵器時代的可靠性是用錢買硬體——更貴的機器、雙電源、RAID、原廠保固;雲跑在海量便宜的 commodity 硬體上,供應商直白告訴你:任何…

#iac#devops#book-notes

鐵器時代 · Iron Age 雲時代 · Cloud Age 實體硬體:變更以週、月計 最佳化方向:減少變更 重審批、重文件、凍結窗口 軟體定義:變更是 API 呼叫 最佳化方向:擁抱變更 自動化 + 快速回饋顧品質 錯不起 → 少改 改得快又安全 → 常改、用變更學習

Infrastructure as Code 是什麼?從「變更」的成本翻轉講起

· tech · 約 7 分鐘 · 📚 Infrastructure as Code 讀書筆記 #1

開一個新系列:讀 Kief Morris 的 Infrastructure as Code,用的是第三版(2025)——副標從第二版的 Dynamic Systems for the Cloud Ag…

#iac#devops#book-notes

傳統:一個盒子,全部捆在一起 儲存引擎 索引 快取 mat. view log ↓ 拆開(unbundle),每個功能交給一個特化系統 ↓ log 當中樞(Kafka)— 定順序的膠水 OLTP DB儲存 + 交易 Elasticsearch= 索引 Redis= 快取 數倉 / Gold 層= materialized view 每個系統都是 log 的 follower,照同一順序消費 → 各自一致 你的資料平台 = 一台「由內翻外」的資料庫;讓它不散架的,是那條 log

資料系統的未來:拆開的資料庫、Kappa,與端到端的正確性(完結)

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #12

終章。前面十一章把儲存、複製、分區、交易、共識、批次、串流一塊塊講完,Kleppmann 在這章把它們收攏成一個大膽的視角:別再把「資料庫」當成一個盒子——把它拆開。 而讀到這裡你會發現,這個「未來」…

#distributed-systems#book-notes#data-engineering

✗ 雙寫:應用自己寫三份 應用程式 DB 快取 搜尋索引 病一:寫到一半當掉 → 有的寫了有的沒寫 沒有交易能跨三個系統回滾 病二:並行寫抵達順序不同 DB 收到先A後B、快取先B後A → 收斂到不同值 → 三個系統永久分歧,無聲無息 ✓ log 先行:只寫一個地方 應用程式 只寫這裡 一條有順序的 log(source of truth) DB 快取 搜尋索引 全部照「同一順序」消費 → 順序一致、掉了可重放 下游全是 follower,最終收斂到同一狀態 一份資料要進 N 個系統?選一個當 source of truth,其他全部當 follower

串流:雙寫的陷阱、CDC,與流表二象性

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #11

批次處理「已經齊了」的資料;串流處理「一直來」的資料。這章很多地基我在別處鋪過了:log 與 offset 在 Kafka 系列、投遞保證在 delivery 那篇、視窗與 event time 在 …

#distributed-systems#book-notes#streaming

輸入(不可變) log 分片 1 log 分片 2 log 分片 3 ① map(就地、平行) (/a,1)(/b,1)… (/a,1)(/c,1)… (/b,1)(/a,1)… 逐筆抽 (key, value),不搬資料 ② shuffle(按 key 重分發) 同 key 跨網路聚到同一台+排序 唯一大搬家的一步=最貴 ③ reduce(整組聚合) /a:(1,1,1)→ /a=3 /b:(1,1)→ /b=2 … 輸出:寫成「新」檔案 map 就地跑(把運算搬到資料旁)· shuffle 是唯一的大搬家,也是一切成本所在 groupBy、join、去重……凡是「同 key 要相聚」的操作,背後都是一次 shuffle

批次處理:MapReduce 的精神、join 的兩條路,與不可變輸入的美德

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #10

Part II 在單一系統內把一致性守住了;Part III 的主題換成資料在系統之間流動——而最古老、也最可靠的流動方式,是批次(batch)。DDIA 講 MapReduce 的切入點很別緻:先講…

#distributed-systems#book-notes#data-engineering

終場哨響:結果寫入,但兩個 replica 進度不同 leader:2 : 1 終場 replica 1(已同步):2:1 終場 replica 2(落後):1:1 進行中 ① Alice 查到「終場 2:1」→ 告訴 Bob ② Bob 重新整理 → 「還在踢」?! 發生在「後」的讀,讀到「更舊」的狀態 → 「單一資料」的幻覺破滅 = 不 linearizable

一致性與共識:linearizability、CAP 的誠實版,與全序廣播

· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #9

上一篇的結論是:任何單一節點的判斷都不可信,真相只能由多數決定。這章講的就是「多數怎麼安全地決定」——DDIA 全書的理論高潮。演算法細節(Raft、Paxos、Zab 怎麼投票換屆)我在 SRE 共…

#distributed-systems#book-notes#consistency

你的節點 送出請求,等待… ① 請求在網路上丟了對方根本沒收到 ② 對方當掉了真的死了 ③ 對方只是很慢(過載、GC 暫停中)等一下它會處理——甚至正在處理 ④ 對方做完了,但「回應」在路上丟了動作已經發生,你卻以為沒有 在你這端: 四種一模一樣 = 沒有回應 timeout 到了,只代表「你決定不等了」,不代表「你知道發生了什麼」

分散式系統的麻煩:不可靠的網路、不可信的時鐘,與半死不活的節點

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #8

上一篇結尾埋了個鉤子:當系統跨到多台機器,連「鎖」和「驗證」本身都變得不可靠。這章就是那個「不可靠」的總清算——也是我認為全書最該精讀的一章。核心一句話:單機世界是確定性的,要嘛全好、要嘛全壞;分散式…

#distributed-systems#book-notes#reliability

不變量:值班醫生 ≥ 2(目前:Alice、Bob 都在) Alice 的交易 ① 查值班人數 → 讀到 2 ≥ 2 ✓ ② 把「自己」改成請假 Bob 的交易 ① 查值班人數 → 也讀到 2 ✓ ② 把「自己」改成請假 (快照隔離:兩人看到的都是「舊快照」的 2) (改的是「不同列」→ 沒有寫入衝突,都放行) 結果:值班人數 = 0,不變量被打破 💥 每筆交易「單獨看」都對;錯在:你檢查所依據的條件,被對方的寫入悄悄改掉了 同款劇本:會議室重複預訂、帳號搶同一個 username、餘額分兩筆同時扣

交易:快照隔離擋不住的 write skew,與可串行化的三條路

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #7

交易的地基我在 SQL 系列鋪過了:ACID 的重點是 I、髒讀/不可重複讀/幻讀三種怪事、四個隔離層級的光譜、MVCC 怎麼讀不擋寫——那些這篇不重複。DDIA Ch7 真正的加值在後半:兩個連「快…

#distributed-systems#book-notes#transactions

按 key 範圍切(range) A–F G–R S–Z 像百科全書分冊,key 有序 ✓ 範圍掃描高效(讀連續一段) ✗ key 是時間戳 → 今天的寫入 全砸最後一區(熱點) HBase / 早期 Bigtable 按 key 的 hash 切 分區 0 分區 1 分區 2 hash 把相鄰 key 均勻噴散 ✓ 負載攤平,熱點被打散 ✗ 順序沒了 → 範圍掃描 得問「所有」分區 Cassandra / Redis Cluster(CRC16)/ Kafka 折衷:複合主鍵(第一欄 hash 選分區,其餘欄位在「分區內」照樣排序)—— Cassandra 的招牌 而 hash 救不了「單一超熱 key」(名人問題)—— 那得在應用層加鹽,把一把 key 拆成多把

分區:range 還是 hash、二級索引擺哪、以及怎麼重新平衡

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #6

複製是同一份資料放多台;分區(partitioning,也叫 sharding)是把資料切開,每台只放一部分——當資料量一台裝不下、或寫入 throughput 一台吃不消,這是唯一的出路。兩者幾乎總…

#distributed-systems#book-notes#partitioning

單主 single-leader Leader follower follower 所有寫入 衝突:源頭消滅(單一寫入點) 代價:failover 難(誰接任?) MySQL / Postgres / Redis / Kafka 多主 multi-leader Leader A Leader B 資料中心 1資料中心 2 兩邊同時改同一筆 → 衝突! 得利:各地就近寫、斷網照收 代價:寫入衝突要事後解 跨資料中心 / 離線編輯 / 協作文件 無主 leaderless 副本 副本 副本 client 同時寫 n 份 quorum:w + r > n 得利:沒有 leader,無 failover 代價:讀寫路徑複雜、read repair Dynamo / Cassandra 同一道題的三種答案:寫入衝突,你想在「源頭擋、事後解、還是讀時調和」?

複製:單主、多主、無主,與延遲的三個怪象

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #5

進入 Part II,資料開始跨機器。第一招是複製(replication):同一份資料放多台,為的是三件事——一台掛了還能服務(高可用)、資料放得離使用者近(低延遲)、讀流量攤出去(擴讀)。如果資料…

#distributed-systems#book-notes#replication

滾動更新中:新舊版同時在跑,資料雙向流動 新版程式 v2已升級的那幾台 舊版程式 v1還沒輪到的那幾台 同一個資料庫 / topic 兩邊都在寫、也都在讀 向後相容 backward 新程式,讀得懂「舊資料」 大家都記得(migration 思維) 向前相容 forward 舊程式,讀得懂「新資料」 最常被忘,但滾動與回滾窗口天天發生 schema 每一次變更,兩種相容都要顧——少一邊,滾動到一半就開始噴錯

編碼與演化:讓新舊程式碼,讀得懂彼此的資料

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #4

上一篇講資料怎麼放上磁碟,這篇講一個更容易被輕視的問題:資料寫出去時,是用什麼格式編碼的? 你可能覺得「JSON 就好了啊」——直到 schema 要改的那一天。這章的重量,來自兩個躲不掉的事實:資料…

#distributed-systems#book-notes#data-engineering

LSM-tree:append-only,事後整理 memtable記憶體,先接住寫入 寫滿→整批順序刷盤 SSTable(新,不可變) SSTable(較舊) SSTable(更舊) compaction背景合併去重 寫:永遠順序 append → 快 讀:可能翻好幾層 SSTable(bloom filter 救) B-tree:page 樹,就地更新 root page page page ✎ 就地覆寫 leaf page WAL:改 page 前先順序記一筆(防當機) 讀:沿樹走 3~4 層就到 → 穩 寫:隨機 I/O 就地改 + 先寫 WAL LSM 寫優(RocksDB / Cassandra / HBase)· B-tree 讀穩(幾乎所有關聯式 DB)

儲存引擎:LSM-tree、B-tree,與欄式儲存

· tech · 約 4 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #3

上一篇選好了資料模型,這篇往最底層鑽:資料庫到底怎麼把資料放上磁碟、又怎麼找回來? DDIA 這章從一個兩行 bash 的「全世界最簡單資料庫」開場——dbset 就是往檔案尾巴 append 一行,…

#distributed-systems#book-notes#storage

關聯式 Relational users orders FK 表 + 外鍵,SQL 查 多對多、join 強 文件 Document 姓名、email 經歷 [ … ](巢狀) 學歷 [ … ](巢狀) 巢狀 JSON,一對多自然 局部性好(讀一次拿整份) 圖 Graph 節點 + 邊,高度連結 關係本身是主角

資料模型:關聯式、文件、圖,你在選什麼

· tech · 約 3 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #2

第一篇講了資料系統要追求什麼(可靠、可擴展、可維護)。這篇往下一層:你要用什麼「資料模型」來裝資料? 關聯式、文件、還是圖——這個選擇不是小事,它是你把現實映射成資料的底層抽象,決定了你怎麼建模、怎麼…

#distributed-systems#book-notes#data-modeling

Reliability 可靠 出錯也能正常運作 · 容錯,不是無錯 · fault ≠ failure · 主動製造故障來測 硬體 / 軟體 / 人為錯誤 Scalability 可擴展 負載增加也扛得住 · 先描述「負載長相」 · 用 percentile 看效能 · scale up vs scale out 加機器前,先懂負載 Maintainability 可維護 讓人好好在上面工作 · Operability 好維運 · Simplicity 少意外複雜 · Evolvability 易演進 複雜的代價是別人來付 三個「非功能需求」——功能決定能不能用,這三個決定長期活不活得下去

可靠、可擴展、可維護:資料系統的三個目標

· tech · 約 5 分鐘 · 📚 Designing Data-Intensive Applications 讀書筆記 #1

開一個新系列:讀 Martin Kleppmann 的 Designing Data-Intensive Applications(簡稱 DDIA)。它跟 FoDE 互補——FoDE 是資料工程的實務…

#distributed-systems#book-notes

會變的工具 —— 一直換、越來越簡單 當紅框架 託管服務 新平台 明年的工具 ↑ 三年後可能沒人用 ↓ 押三十年不太會錯 不變的地基 源頭 擷取 儲存 轉換 服務 暗流 安全 · 資料管理 · 編排 · 軟體工程 · DataOps

資料工程的未來:工具會變、地基不變,讀《Fundamentals of Data Engineering》Ch.11(完結)

· tech · 約 3 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #11

十一章走到這裡,最後一個問題:資料工程的未來會長怎樣? 書的答案既讓人安心、又有點反直覺 —— 工具會一直變、而且越來越簡單;但底下那套生命週期與暗流,不會變。 這一篇,也是這個系列的完結。 這章把整…

#data-engineering#book-notes

敏感資料 PII・金流… 當資產 · 價值 分析洞察 訓練 ML 模型 支撐決策 當負債 · 風險 外洩 合規罰款 勒索軟體 信任崩壞 每一筆敏感資料都同時是這兩面 —— 所以:只收該收的、該刪就刪

最該重視卻最被忽略的一章:安全與隱私,讀《Fundamentals of Data Engineering》Ch.10

· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #10

走完服務,生命週期還有一條貫穿全程的暗流沒單獨講:安全與隱私。書把它排在很後面,卻直說這是最重要、也最常被忽略的一章。而它最反直覺的第一句話是 —— 安全主要是「人」的問題,不是「工具」的問題。 大多…

#data-engineering#book-notes#security

建模好的資料 Warehouse · Lakehouse 商業分析 BI・儀表板 嵌入式分析 產品內給客戶看 機器學習 特徵・訓練資料 Reverse ETL 回灌 CRM・廣告平台

資料的最後一哩:服務給分析與 ML,讀《Fundamentals of Data Engineering》Ch.9

· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #9

前面幾章一路走過源頭、儲存、擷取、建模 —— 但這些辛苦,只有在有人真的拿去用的那一刻才變現。這章講生命週期的最後一站:服務(Serving)。而它的第一原則,只有兩個字。 書把話講得很重:沒人會用他…

#data-engineering#book-notes#data-serving

正規化 Normalized orders customers products 少重複・寫入一致 但查詢要多次 join 反正規化 · 寬表 one big table(寬表) 重複多,但查詢少 join 適合欄式倉儲分析 OLTP 交易(寫多) OLAP 分析(讀多)

把資料變好用:查詢、建模與轉換,讀《Fundamentals of Data Engineering》Ch.8

· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #8

資料擷取進來、存好了,接下來的問題是:怎麼把它變成真正好用的東西? 這章給了三支柱 —— 查詢(Query)、建模(Modeling)、轉換(Transformation)。它們合起來,把「一堆原始資…

#data-engineering#book-notes#data-modeling

批次 Batch 小時 ~ 天 定時/定量・成熟(預設) 微批次 Micro-batch 秒 ~ 分 每一小批處理一次 串流 Streaming 毫秒 ~ 秒 逐筆事件・即時 高延遲・低複雜・便宜 低延遲・高複雜・貴 每往即時走一步,就多付一分複雜度與成本

把資料搬進來:批次還是串流?讀《Fundamentals of Data Engineering》Ch.7

· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #7

源頭生出資料、儲存準備好接,中間那條把資料搬進來的動作,就是這章的主角:Ingestion(擷取)。它是生命週期的第二站,也是最多人一上來就糾結「要不要即時」的地方。這章最該先想清楚的一句話是 —— …

#data-engineering#book-notes#ingestion

↑ 越上面:越快、越貴、容量越小 CPU 快取~1 ns RAM 記憶體~100 ns · 揮發 SSD~0.1 ms HDD 磁碟(轉盤)~10 ms 物件儲存(S3 / GCS)~100 ms · 超便宜 封存 / 冷儲存分鐘~小時 · 最便宜 ↓ 越下面:越慢、越便宜、容量越大

資料要存在哪:儲存的階層與抽象,讀《Fundamentals of Data Engineering》Ch.6

· tech · 約 7 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #6

上一篇講資料從源頭生出來。生出來之後第一件事就是:存去哪? 這章談儲存 —— 而它最反直覺的一點是:儲存不是「一個東西」,而是一整條從奈秒到小時、從天價到白菜價的階層。 看懂這條階層,後面所有「該放哪…

#data-engineering#book-notes

源頭系統 — 別人擁有、會自己改變 應用資料庫(OLTP) API / SaaS 檔案 / 日誌 IoT / 感測器 訊息佇列 / 串流 你的邊界 Ingestion 擷取 你的生命週期從這開始 下游

資料從哪來:源頭系統與資料生成,讀《Fundamentals of Data Engineering》Ch.5

· tech · 約 6 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #5

前四章在講大方向 —— 生命週期、架構、選技術。從這章開始,書一階一階走進生命週期的每個環節。第一站是最前面、也最容易被工程師輕看的一段:資料到底是怎麼、在哪裡被生出來的? 這章最該記住的一句話是 —…

#data-engineering#book-notes

易變的表層 — 框架・函式庫・當紅工具 當紅框架 新潮工具 函式庫 平台 SDK 會隨潮流來來去去 → 設計成可抽換 不變的地基 物件儲存 · SQL · 網路 · Unix / bash

技術到底該怎麼選:讀《Fundamentals of Data Engineering》Ch.4

· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #4

上一篇講架構(why);這一章接著問:在那個架構底下,技術(how)到底該怎麼選? 這章最該先釘進腦袋的一句話是 —— 先有架構,才選技術,不是反過來。 工具是手段,被架構的取捨牽著走;一上來就問「要…

#data-engineering#book-notes

雙向門(可逆) 現狀 新方案 回得來 → 決策可以快 單向門(不可逆) 現狀 新方案 ✕ 回不去 → 決策要慎重

好的資料架構怎麼設計:讀《Fundamentals of Data Engineering》Ch.3

· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #3

上一篇給了生命週期的全貌(資料在做什麼);這一章問的是 —— 怎麼把承載它的系統設計得「好」? 這章最反直覺、也最該記住的一句話是:好的架構不是一張固定的藍圖,而是一個「用權衡換取彈性與可逆」的決策過…

#data-engineering#book-notes#architecture

Generation 生成 Ingestion 攝取 Transformation 轉換 Serving 服務 Storage 儲存(橫跨中間三階段) Undercurrents — 撐起整條生命週期的六條暗流 Security 安全 Data Management DataOps Data Architecture Orchestration 編排 Software Engineering

資料工程生命週期:讀《Fundamentals of Data Engineering》Ch.2

· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #2

上一篇給了定義,這一章給的是全書的骨架 —— 資料工程生命週期(data engineering lifecycle)。這本書最有價值的貢獻,就是用這個框架把「資料工程在做什麼」講清楚:五個階段 + …

#data-engineering#book-notes#lifecycle

AI / 深度學習 學習・最佳化(A/B、ML) 彙整・標註(分析、指標) 搬運・儲存(pipeline、ETL) 收集(紀錄、感測、外部資料) ML / AI 資料工程

資料工程是什麼:讀《Fundamentals of Data Engineering》Ch.1

· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #1

我開一個新系列,讀 Joe Reis 與 Matt Housley 的 Fundamentals of Data Engineering。這本書最大的價值,是把「資料工程」這個常被講得很模糊的職能,收…

#data-engineering#book-notes