🌐 This page hasn't been translated yet — showing the original Chinese. Translated posts

#infrastructure

① 觸發webhook / PR ② 佇列等一個空格子 ③ 依 label 媒合Jenkinsfile 說:linux && docker agent-alabel: linux docker3 個 executor,還剩 1 格 → 派這台 agent-blabel: linux全空,但沒有 docker → 輪不到它 agent-maclabel: mac簽 iOS 用的,別的工作不派來 排隊等的是 executor 格子,不是機器 一台 agent 有幾個 executor,就能同時跑幾個 build——格子開太多,大家一起搶 CPU 與硬碟 而 label 不符的 agent,就算整台閒著也不會被派工:你的 build 在等的往往不是「機器」,是「對的機器」

Controller 與 Agent:工作到底在哪台機器上跑

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #3

上一篇那份 Jenkinsfile 裡有一行 sh './scripts/ci-build.sh'。它到底在哪台機器上執行? 這個問題聽起來很基本,但它決定了三件事:你的 build 要等多久、失敗時…

#jenkins#ci-cd#infrastructure

一個資料平台的分層 監控 LGTM:一塊玻璃看全平台Grafana · Loki(logs)· Tempo(traces)· Prometheus / Mimir(metrics) Stateful 核心 — StatefulSet + PV KafkaRedis RabbitMQMetadata DB 少動・保護狀態・HA 過半・傾向 managed Stateless 運算 — Deployment + autoscale Spark executor Airflow worker Kafka Connect worker 可拋・隨開隨關・借外部狀態・傾向 self-host Kubernetes 底座control plane + etcd —— 所有東西都跑在這上面 一條軸決定分層:有狀態的沉在核心層少動;無狀態的浮在運算層隨開隨關

把它們兜成一個資料平台

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #9

前面八篇,一個一個工具看。這篇把它們兜成一個平台。而「兜」的方法,不是把七個工具的細節背起來——是抓住那條從第一篇就在講的軸:stateful ↔ stateless。這條軸一句話決定了每個工具在平台…

#infrastructure#platform

worker 無狀態,狀態全存回 Kafka Connector(一份 config)→ 拆成 N 個 task Worker 1(無狀態・可拋) task-1task-2 Worker 2(無狀態・可拋) task-3task-4 狀態存回 Kafka Kafka 叢集(Connect 的 state store) configsoffsetsstatus worker 掛 → task rebalance 到別台,一則不丟(狀態在 Kafka);命門 = Kafka 本身

Kafka Connect:連接器的執行時

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #8

收尾 stateless 這一批的最後一個:Kafka Connect。它是一套專門在 Kafka 與外部系統(資料庫、S3、Elasticsearch)之間搬資料的框架——你不用每次都手寫消費者/生…

#infrastructure#kafka

看似無狀態的組件,真狀態藏在一顆 metadata DB Scheduler解析 DAG、排 task無狀態・可重啟 Webserver那個 UI無狀態 Worker × N執行 task可多開・可重啟 Metadata DB(Postgres)真狀態・命門 組件掛了都能換;DB 掉了 = 整個系統的記憶歸零(哪些跑過、誰在跑、誰失敗) 連多個 scheduler 的 HA,都靠對這顆 DB 上鎖(row lock)來協調

Airflow:排程器、worker 與那個藏起來的狀態

· tech · 約 6 分鐘 · 📚 從 Infra 角度看資料工具 #7

上一篇埋了個伏筆:每個系統都有一塊逃不掉的狀態,認出它就掌握了命門。 Airflow 是這句話最好的示範。它表面上全是看似無狀態、可重啟的組件——scheduler、webserver、worker,…

#infrastructure#airflow

無狀態運算:算在叢集內,狀態在叢集外 資料源S3/DB/Kafka 輸出 sink寫回結果 Spark app(叢集內) Driver 協調 · 單點命門 Executor短命可拋 Executor短命可拋 Executor短命可拋 讀 寫 executor 掛 → 靠 lineage 重算那一塊,不丟資料;真正 durable 的資料全在叢集外 對比前三篇:狀態 = 服務本體;Spark:狀態借外部,自己近乎無狀態

Spark:短命 executor 的彈性運算

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #6

前三篇(Kafka、Redis、RabbitMQ)都在光譜的 stateful 那一端——狀態綁在自己的磁碟或記憶體,擴縮要搬資料、故障要救資料。這篇翻到光譜的另一端:Spark,系列第一個 stat…

#infrastructure#spark

Kafka:log m1m2m3m4m5 B 讀到 m2 A 讀到 m4 訊息留著 · 各自用 offset 讀 可重播 · 多消費者 fan out RabbitMQ:queue m4m3m2 consumer m1 已被取走 + ack → 消失 消費即移除 · broker 追蹤 ack 複雜路由 · per-message 控制 狀態:Kafka = 一條「消費留痕」的 log(磁碟為王)　·　RabbitMQ = queue 裡待處理的訊息(消費即減少) 取捨:事件流 / 可重播 / High-throughput → Kafka　·　任務佇列 / 複雜路由 / per-message → RabbitMQ

RabbitMQ:訊息 broker 的叢集與流控

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #5

收尾「有狀態的重量級」這一批,第三個是 RabbitMQ。它跟 Kafka 都是訊息中介,但 infra 形狀差很多,而差別可以濃縮成一個字:Kafka 是 log,RabbitMQ 是 queue。…

#infrastructure#rabbitmq

記憶體為界:硬牆在 RAM(對照 Kafka 磁碟為王) fork headroom(持久化時可能翻倍)實體 RAM 頂 ↑ ← maxmemory 硬牆 可成長空間 已用資料(在記憶體) 資料在記憶體→ 容量硬上限 = RAM 撞牆 → evict或 noeviction 報錯 磁碟 RDB/AOF 重啟回暖 對照:Kafka 瓶頸=磁碟 throughput / 容量　·　Redis 瓶頸=記憶體容量

Redis:記憶體為界的有狀態服務

· tech · 約 4 分鐘 · 📚 從 Infra 角度看資料工具 #4

第二個有狀態的重量級是 Redis,而它跟 上一篇的 Kafka 剛好是一組完美對照:Kafka 磁碟為王,Redis 記憶體為界。兩者都有狀態,但體檢表第②題「狀態放哪」的答案不同——一個在磁碟、一…

#infrastructure#redis

磁碟為王:資料就躺在 broker 磁碟上 Producer Broker 1P0 · leaderappend logon disk Broker 2P0 · followerappend logon disk Broker 3P0 · followerappend logon disk 寫 replicate → ISR(3 副本) 瓶頸是磁碟(throughput + 容量),不是 CPU / 記憶體 Kafka 靠 sequential 順序寫 + page cache + zero-copy,讓「磁碟」也能跑很快

Kafka:磁碟為王的有狀態叢集

· tech · 約 4 分鐘 · 📚 從 Infra 角度看資料工具 #3

進入有狀態的重量級,第一個是 Kafka。用體檢表看它,一切都從第②題「狀態」展開——Kafka 的資料(那條可重播的 log)不是抽象概念,它實實在在躺在 broker 的磁碟上。這一個事實,決定了…

#infrastructure#kafka

底座解剖:大腦、工人,與命門 etcd Control Plane(大腦) API Server唯一入口 Scheduler排 pod 放哪 Controller Mgrreconcile loop etcd ★命門狀態真相 · Raft唯一 stateful Worker Nodes(工人) kubelet + Pods kubelet + Pods kubelet + Pods etcd 掛了 → 整個叢集「失明」(現有 pod 還跑,但不能排程 / 更新 / 自癒) 所以 etcd 要:奇數台過半、定期備份、低延遲磁碟——它是你最該小心的東西

Kubernetes:所有東西跑的底座,它自己怎麼站穩

· tech · 約 6 分鐘 · 📚 從 Infra 角度看資料工具 #2

這系列第一個要體檢的,是 Kubernetes——但它很特殊:別的工具都跑在它上面。它是底座,所以它自己的可靠度,就是後面 Kafka、Spark、Redis 全部的地基。用上一篇的體檢表看它,會發現…

#infrastructure#kubernetes

Infra 體檢表:看任何工具都問這 8 題 ① 部署拓撲由哪些角色組成?幾台?誰是大腦誰是工人? ② 狀態與儲存 ★樞紐有狀態嗎?資料放哪?掉了能重建嗎? ③ 擴展水平(加機器)還是垂直(加規格)? ④ HA / 故障轉移掛一台誰接手?有沒有單點? ⑤ 容量規劃瓶頸是 CPU / 記憶體 / 磁碟 / 網路? ⑥ 監控該盯哪些指標?怎麼知道它快不行了? ⑦ 調校旋鈕哪些設定會決定生死? ⑧ 故障模式它最常怎麼壞?壞了長什麼樣?

從 Infra 角度看一個工具,要問哪些問題

· tech · 約 3 分鐘 · 📚 從 Infra 角度看資料工具 #1

學一個工具、和把它放進 Production,是兩種完全不同的問題。學的時候你問「這個 API 怎麼用、這個概念是什麼」;上 Production 時你問的是另一組問題——它會怎麼掛?怎麼長大?半夜壞…

#infrastructure#concept