Tech

沒索引:Seq Scan(全表掃) 列 1 列 2 列 3 列 4 列 5 ← 目標 列 6 逐列掃過才找到 → O(n),資料越多越慢 有索引:B-tree 節點 節點 目標 沿樹往下幾步就到 → O(log n)

索引為什麼快 —— 也為什麼會失效

· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9

進入第三幕:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 500 …

#sql#performance

直接 GROUP BY date_trunc 日期筆數 7/013 7/025 7/03 沒這列 ✗ 7/042 補洞 generate_series + COALESCE 0 7/013 7/025 7/030 7/042 GROUP BY 只產出「有資料」的桶 —— 沒訂單的 7/03 整列消失,時間序列就斷了

時間分桶與 SCD:SQL 處理時間的兩個坑

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #8

接著上一篇的「區間」,這篇收尾第二幕,講時間在 SQL 裡的兩個坑——它們都源自同一件事:時間是連續的,但你的資料是離散的事件。 中間必然有「什麼都沒發生」的空隙,以及「值變了但你沒記」的變化。SQL…

#sql#data-engineering

你的服務 ① Latency 延遲 請求要多久才回? 分開看「成功」與「失敗」的延遲 ② Traffic 流量 系統現在多忙? QPS / 每秒請求數 ③ Errors 錯誤 多少請求失敗了? 失敗率(含「回 200 但內容是錯的」) ④ Saturation 飽和度 離極限還有多近? 資源用了幾成 → 最能預警 前三個 = 使用者體感(可直接當 SLI);第四個「飽和度」= 還能撐多久的預警

監控:四個黃金訊號

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4

上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…

#sre#monitoring

是不是 toil?看這六個特徵 手動 —— 要人一步步動手做 重複 —— 做過很多次、之後還會再做 可自動化 —— 機器能做,只是還沒有人去寫 無長期價值 —— 做完,系統並沒有變得更好 隨規模線性成長 —— 服務變大,它就跟著變多 被動反應 —— 被觸發才做,不是主動規劃出來的 符合越多 → 越是 toil。注意:開會、規劃、寫文件是 overhead,不算 toil

消除 Toil:把重複的維運當成待消滅的 bug

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3

第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…

#sre#reliability

① 完全相同的列 (1, A, 100) (1, A, 100) (1, A, 100) DISTINCT (1, A, 100) 整列一模一樣 → 去掉多的 DISTINCT / GROUP BY 就能解 ② 同一 key、多筆版本 user1 · 待付 · 2/01 user1 · 已付 · 2/03 user1 · 退款 · 2/05 ROW_NUMBER 留最新 user1 · 退款 · 2/05 列不相同 → DISTINCT 沒用 要挑「代表」那一筆

去重的正確姿勢:DISTINCT 不是唯一解

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #6

資料重複幾乎是資料工程的日常:pipeline 重跑重複匯入、CDC 把同一筆的多個版本都撈進來、JOIN 的 fan-out 把列複製。很多人一講到去重就 DISTINCT——但去重根本不只 DIS…

#sql#data-engineering

輸入(orders):4 列 A · 100 A · 250 B · 80 B · 120 GROUP BY(收合) A · SUM 350 B · SUM 200 4 列 → 2 列(每組收成一列) SUM() OVER(不收合) A · 100組計 350 A · 250組計 350 B · 80組計 200 B · 120組計 200 4 列 → 4 列(每列多一欄看整組的值)

Window Function:不收合的聚合

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #5

上一篇的 GROUP BY 把每組收合成一列。但你一定遇過這種需求:「我想要整組的計算,又想保留每一列。」 例如——在每一筆訂單旁邊,標上它佔該客戶總額的比例;或在每個月的營收旁,標上跟上個月的差。收…

#sql#concept#window-function

99.0% 100% SLA 99.5% 對外合約·違反賠錢 SLO 99.9% 內部目標(拚這個) 違約區 沒達標(但還沒違約) 健康區 ← SLI 99.95% 實際量到的 安全 buffer:內部先痛,別讓客戶先痛 門檻鬆緊:SLA(鬆) < SLO(嚴) ≤ SLI(健康時的實測)

SLI / SLO / SLA:一個量測、一個目標、一個合約

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #2

上一篇說 error budget = 1 − SLO。但 SLO 是什麼?它跟另外兩個幾乎人人混用的縮寫——SLI、SLA——又差在哪?這三個字分不清,可靠度就無從談起。一句話先記住:SLI 是你「…

#sre#reliability

可靠度目標訂在 99.9%,不是 100% 剩下的 0.1% 不是遺憾,是可以花的「預算」 Error Budget = 1 − SLO 服務成功 ≥ 99.9%(SLO 目標) 失敗 ≤ 0.1% (刻意放大顯示) ≈ 一個月約 43 分鐘可壞 追到 100%:成本爆炸、邊際效益趨近零——使用者還分不出 99.9% 和 100% (他手上的網路、手機、Wi-Fi 本來就沒那麼可靠)

SRE 是什麼?從 Error Budget 講起

· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #1

「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是…

#sre#reliability

原始列(orders) A · amount 100 A · amount 250 B · amount 80 B · amount 120 B · amount 50 GROUP BY customer 收合後:每組一列 customer = ACOUNT=2 · SUM=350 customer = BCOUNT=3 · SUM=250 amount 一組有多個值(100/250)→ 不能裸選,要用聚合(SUM/AVG…)壓成一個數

GROUP BY:把多列收合成一列

· tech · 約 5 分鐘 · 📚 SQL 我以為我懂 #4

GROUP BY 每個人都會寫,但幾乎每個人也都被那句 column "..." must appear in the GROUP BY clause 擋過,而且常常搞不懂「我就選個欄位,為什麼不行?…

#sql#concept

SQL 的邏輯有三個值(不是兩個) TRUE 條件成立 FALSE 條件不成立 UNKNOWN 不知道 ↑ 任何跟 NULL 的比較都落這裡 age = NULL、age <> NULL 都是 WHERE / ON / HAVING 只放行 TRUE TRUE → ✓ 保留 FALSE → ✗ 丟 UNKNOWN → ✗ 丟

NULL 不是值,是「不知道」

· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #3

上一篇的 LEFT JOIN,會幫沒配到的列補上 NULL。那個 NULL 就是這篇的主角——它是無數 SQL bug 的源頭,而根本原因只有一句:NULL 不是一個值,是「不知道」。 一旦你把它讀成…

#sql#concept

右表 R:訂單(user 欄) A A B 左表 L:使用者 使用者 A 使用者 B 使用者 C A 配到 2 筆 → 結果 A 出現兩次 B 配到 1 筆 C 配不到 → INNER 丟掉 LEFT 補 (C, NULL) ON 符合(留下) 不符合(丟棄)

JOIN 的真相:先算笛卡爾積,再過濾

· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #2

上一篇把「你寫的順序不是它跑的順序」講清楚了。這篇用同一把鑰匙拆穿 JOIN。很多人把 JOIN 想成「把兩張表黏在一起」,然後死背 INNER/LEFT/RIGHT/FULL 各自的行為。但其實它們…

#sql#concept

你的 code DataFrame API 或 Spark SQL —— 兩者等價 Logical Plan ·「要什麼」 解析出你引用的表與欄位,還沒最佳化 Catalyst 最佳化器 filter 下推 · 剪掉沒用的欄位 · 挑 join 策略 Physical Plan ·「怎麼做」 Exchange(= shuffle)、join 策略都定案 執行 切成 stage / task,丟到 executor 上跑

讀懂 Spark 執行計畫:.explain() 到底在說什麼

· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #6

這個系列一路講下來,有兩句話反覆出現:「相信 Catalyst 最佳化器」、「打開 Spark UI 找瓶頸」。但我一直沒回答一個問題:你到底要怎麼看 Spark 做了什麼? 相信最佳化器不該是盲信—…

#spark#data-engineering#performance

呼叫方 只認 web 這名字 Service:web 固定 IP 10.96.0.10 · DNS web.*.svc selector: app=web 自動負載均衡到健康 Pod Pod · 10.1.2.7 ✓ 健康 Pod · IP 會變 掛了換新:.8 → .31 Pod · 10.1.4.2 ✓ 健康

Service:擋在短命 Pod 前面的固定門牌

· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #4

第二篇留了一個問題:既然 Pod 是短命的、被換掉就有新的 IP,那別的服務要怎麼穩定找到它?你總不能把某顆 Pod 的 IP 寫死在設定裡——它下一秒可能就不在了。這篇的主角 Service,就是 …

#kubernetes#concept#networking

你這樣寫 DB 這樣跑(邏輯順序) SELECT FROM / JOIN WHERE GROUP BY HAVING ORDER BY LIMIT ① FROM / JOIN ② WHERE ③ GROUP BY ④ HAVING ⑤ SELECT ⑥ ORDER BY ⑦ LIMIT

你寫的 SQL 不是照你寫的順序跑

· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #1

你寫 SQL,幾乎都是 SELECT 開頭。寫久了很自然會以為:它就是從 SELECT 開始跑的。但不是——SQL 是宣告式的,你寫的是「要什麼」,引擎自己決定「怎麼跑、照什麼順序跑」,而它跑的順序跟…

#sql#concept

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

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

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

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

#data-engineering#book-notes

Deployment 期望:replicas = 3 · image v1 ReplicaSet 確保永遠有 3 個 Pod Pod ✓ 健康 Pod ✗ 掛了 Pod ✓ 健康 少一個 → ReplicaSet 觀察到落差 → 立刻補一個新的回到 3 個

Deployment 與自我修復:reconcile loop 的實戰

· tech · 約 4 分鐘 · 📚 Kubernetes 學習筆記 #3

第一篇給了靈魂(reconcile loop),第二篇給了原子(Pod)。但實務上你幾乎不會手動去建一個 Pod —— 你宣告的是 Deployment,而它正是 reconcile loop 最實用…

#kubernetes#concept

Pod 最小部署單位・排程與伸縮的單位 容器:app 你的服務 容器:sidecar 選配(log / proxy) 共享:一個 IP(彼此用 localhost 通)· 共享 Volume

Pod、Node、Scheduler:Kubernetes 叢集的三個原子

· tech · 約 4 分鐘 · 📚 Kubernetes 學習筆記 #2

上一篇講了 K8s 的靈魂:你宣告期望,reconcile loop 不斷把現實拉過去。但那句「我要 3 個」——3 個什麼?落在哪台機器上?誰決定放哪? 這篇把叢集最基本的三個原子講清楚:Pod、N…

#kubernetes#concept

期望狀態 你宣告:replicas = 3 Controller 控制迴圈 比較 & 修正 實際狀態 現在只有 2 個 ① 讀期望 ② 動作 ③ 觀察 2 → 建 1 個 → 3 ✓ reconcile loop:不斷比較期望與實際,有落差就修正 —— 這就是 K8s 的靈魂

Kubernetes 是什麼:從「跑容器」到「宣告你要的狀態」

· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #1

很多人學 Kubernetes(K8s)覺得難,是因為一上來就被 kubectl、一堆 YAML 欄位、幾十種資源名詞淹沒。但其實 K8s 只有一個核心觀念,抓住它,後面全部都是同一句話的變形。這個系…

#kubernetes#concept

敏感資料 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

K8s Control Plane · Scheduler 依 resource request / affinity 決定 pod 落哪個 node Node 1 on-demand 池(穩定) Node 2 spot 池 Node 3 spot 池 Airflow Scheduler Airflow Webserver Airflow Triggerer Metadata DBPersistentVolume(有狀態) Spark Driver Spark Executor Spark Executor Spark Executor Spark Executor Driver 申請的 executor 由 Scheduler 散到各 node Executor 讀取來源 / 寫回結果 Business DB叢集外的營運資料源 / 輸出 Airflow pod Spark Driver Spark Executor Metadata DB Business DB

Airflow + Spark 跑在 K8s 上:不同的 node 怎麼跑不同的 pod

· tech · 約 11 分鐘 · 📚 Kubernetes 學習筆記 #8

Airflow 負責「什麼時候、用什麼順序」跑作業,Spark 負責「把大資料算完」。當這兩個東西都搬到 Kubernetes 上,最常見的困惑是:到底有哪些東西在跑、它們各自是不是一個 pod、又被…

#kubernetes#airflow#spark#data-engineering

源頭系統 — 別人擁有、會自己改變 應用資料庫(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

無界輸入表 t1 一批 t2 一批 t3 新到 …持續 append 表一直長高 同一個查詢groupBy/agg… 結果表(持續更新) aggregate result

Structured Streaming 入門:把串流當成一張無界的表

· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #5

前四篇都在講批次的 Spark —— 是什麼、DataFrame 實戰、shuffle 調校、怎麼跑起來。但資料不會等你湊成一批才來:訂單、點擊、日誌是持續流進來的。這篇講 Spark 處理串流的方式…

#spark#data-engineering#stream-processing

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

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

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

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

#data-engineering#book-notes#architecture

branch full_reload ✓ incremental ⊘ skip join none_failed_…

Airflow 複雜流程控制:branching、trigger rules、TaskGroup、動態任務

· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #6

到目前為止,我們的 DAG 都是「固定的幾個 task、照線跑完」。但真實流程沒這麼乖:有時要依條件走不同分支、某個 task 失敗了清理工作還是得跑、幾十個相似 task 要收整齊、甚至執行期才知道…

#airflow#data-engineering#dag-design

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

痛點還沒到 → 輕量解 本機 PySpark · dbt + 倉儲 直接打 API · 兩層架構 成本低、好維護 痛點到了 → 才上重武器 Spark 叢集 · Kafka Airflow · 多層 Medallion 威力強,但每天要餵養 痛點臨界點 痛點量級(資料量 · 來源數 · 編排複雜度)→

先確認痛點,再上重武器

· tech · 約 2 分鐘

這是一篇概念筆記 —— 一個我反覆在用的判斷,獨立成篇,讓其他文章可以連回來。 一句話:在引入任何重型工具或架構之前,先確認你的痛點真的到了需要它的量級。 沒到,就別上 —— 因為重武器的成本不在「裝…

#concept#data-engineering

壓縮前 k1:a k2:x k1:b k3:p k2:y k1:c cleaner:每個 key 留最後一筆 壓縮後 k3:p k2:y k1:c

Kafka 維運與部署:KRaft、retention/compaction 與監控

· tech · 約 7 分鐘 · 📚 Kafka 學習筆記 #5

前四篇講的是「Kafka 怎麼用」—— 可重播的 log、核心模型、投遞保證、生態系。這篇收尾,換個視角:當 Kafka 真的上線、要長期穩定跑,維運面得懂哪些事?四塊 —— KRaft(叢集怎麼管自…

#kafka#data-engineering#operations

Kafka topics / log MySQL / API 來源系統 DW / ES / S3 下游系統 Connect source Connect sink Schema Registry Kafka Streams 讀 → 運算 → 寫回

Kafka 生態系:Connect、Schema Registry 與 Streams

· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #4

前三篇都在講 Kafka broker 本身 —— 可重播的 log、核心模型、投遞保證。但真實世界裡你幾乎不會「只用 broker」:資料要從別的系統搬進來、事件的長相要有人管、流上還得做轉換與聚合…

#kafka#data-engineering#stream-processing

DAG task @task Operator 做一件事 Hook 連線 client 外部系統 DB / S3 / API Connection conn_id:帳密 + 端點 提供帳密

Airflow 怎麼連外部系統:Provider、Operator、Hook、Sensor

· tech · 約 6 分鐘 · 📚 Airflow 學習筆記 #5

前面幾篇都在講 Airflow 的內部機制 —— 排程、任務間傳資料。但真正的 pipeline 一定得碰外面的世界:查一個資料庫、丟檔案到 S3、打一支 HTTP API、等一個檔案到齊。這篇講 A…

#airflow#data-engineering#integration

Producer acks? Broker 複本 / ISR Consumer commit 時機 ① 丟失 / 重複 ② 機器掛了會不會丟 ③ 重做 / 跳過

Kafka 的投遞保證:acks、ISR 與 at-least-once / exactly-once

· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #3

第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at…

#kafka#data-engineering#reliability

Driver 排程 task ① 申請資源 Cluster Manager ② 啟動 Executor task + cache Executor task + cache Executor task + cache ③ 派 task

把 Spark 跑起來:從本機到叢集與 managed 平台

· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #4

前三篇都在講 Spark 怎麼寫、怎麼跑得快(是什麼、DataFrame 實戰、shuffle 調校)。但同一段程式碼,在你筆電上跑、跟在一個幾十台機器的叢集上跑,中間到底發生什麼事?這篇講 runt…

#spark#data-engineering#deployment

task A XCom 訊息板 (metadata DB) task B push pull 只放「小東西」:id、筆數、旗標、檔案路徑… 大資料請寫到 S3 / 檔案,XCom 只傳「路徑」

Airflow 任務間怎麼傳資料:XCom、TaskFlow 進階與 params

· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #4

上一篇講完排程,這篇處理一個很實際的問題:一個 task 算出來的東西,怎麼交給下一個 task? Airflow 的答案是 XCom,而 TaskFlow 把它包得幾乎看不見。順帶也講 params…

#airflow#data-engineering#xcom

narrow filter/select 分區1 分區2 分區3 分區1 分區2 分區3 1對1,不搬 wide groupBy/join 分區1 分區2 分區3 shuffle:跨分區重新分配 輸出1 輸出2 輸出3

Spark DataFrame 實戰:讀取、轉換、寫出與 Spark SQL

· tech · 約 4 分鐘 · 📚 Spark 學習筆記 #2

上一篇把 Spark 的概念講完了:Driver / Executor、分區、惰性求值、shuffle。這篇動手用 DataFrame 實際轉一份資料 —— 讀進來、清洗、彙總、寫出去,並看看 Spa…

#spark#data-engineering#pyspark

6/18 00:00 6/19 00:00 6/20 00:00 資料區間 = 6/18 資料區間 = 6/19 6/18 的 run 在這觸發 6/19 的 run

Airflow 排程的真相:data interval、catchup 與 backfill

· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #3

上一篇我們把 DAG 跑起來了,還特別把 catchup 設成 False「保平安」。這篇就來拆解 Airflow 最反直覺、也最多人卡住的部分:排程到底怎麼運作。搞懂這一段,你才真的會用 Airfl…

#airflow#data-engineering#scheduling

./dags/*.py 你寫的 DAG Scheduler Web UI :8080 Worker 瀏覽器 掛載/解析 顯示 派送任務

跑起第一個 Airflow:Docker 環境 + 你的第一個 DAG

· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #2

上一篇把 Airflow 的概念與架構講清楚了;這篇動手把它在本機跑起來,寫出第一個 DAG,並在 Web UI 上看著它跑完。目標很單純:從零到「我親眼看到自己的 DAG 在介面上變綠」。 方式 指…

#airflow#data-engineering#docker

Driver SparkSession · DAG Cluster Manager YARN / K8s Executor tasks + 分區 Executor tasks + 分區 Executor tasks + 分區 申請資源

Apache Spark 是什麼?一篇搞懂分散式資料處理

· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #1

一句話:Apache Spark 是一個把「大到單台機器裝不下、算不完」的資料,切成很多份、分散到一整個叢集上平行運算的引擎。它源自 UC Berkeley(2009),2014 成為 Apache …

#spark#data-engineering#pyspark

事實 感受 教訓

領導力 - 用日記看見自己

· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #6

上一篇談到,「看不到自己」是創新的第一道障礙——你改不掉一個你沒看見的東西。作者給的解法意外地簡單:每天花五分鐘寫日記。而且最有意思的是,光是「開始寫」這個動作本身,就能同時訓練與觀察好幾件事。 聽到…

#leadership#innovation

想法新觀點 ① 看不到自己 ② 沒問題綜合症 ③ 只有一個正解 創新被擋住

領導力 - 創新的三大障礙

· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #5

創新不是少數天才的靈光,而是一種「環境允許你提出不同想法」的能力(呼應 MOI 裡的 Innovation)。但有三種心態會在源頭就把創新擋下來——而且它們往往是無意識的。 第一道牆是看不清自己的行為…

#leadership#innovation

領導力 - 成長模型

· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #3

成長模型描述的是「技能隨時間怎麼變化」。同一條成長曲線,在不同的觀察尺度下,會呈現完全不同的形狀。下面從最遠的宏觀、一路拉近到最貼近真實的微觀。 只要每天持續進步,把時間尺度拉得夠遠來看,技能的成長速…

#leadership

領導者 M · Motivation激勵讓人願意動起來 O · Organization組織讓人有效率有秩序 I · Innovation創新讓人敢提不同想法 三者合起來 = 領導者塑造的團隊環境

領導力 - MOI

· tech · 約 5 分鐘 · 📚 成為 Tech Leader 讀書筆記 #2

領導方式模型就是透過幾項指標來描述一個環境,MOI模型就是其中一種描述方式 MOI 模型包含三個構面:Motivation(激勵)、Organization(組織)、Innovation(創新)。每個…

#leadership

程式抽籤被質疑黑箱該如何處理

· tech · 約 5 分鐘

前陣子幫目前社區實作了一個簡單的車位抽籤頁面,後來其他管理委員們認為可能會被住戶質疑這程式不可信任,可能有黑箱疑慮,藉此研究了一下如何證明這個抽籤流程沒有黑箱。 - 複雜的說是抽籤的過程可受某方控制達…