索引為什麼快 —— 也為什麼會失效
· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9
進入第三幕:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 500 …
· tech · 約 2 分鐘 · 📚 SQL 我以為我懂 #9
進入第三幕:引擎與效能。第一個要懂的就是索引——為什麼加了它查詢快幾百倍,又為什麼有時加了卻好像沒用。這兩個問題的答案,都藏在它的資料結構裡:B-tree。 沒有索引時,WHERE id = 500 …
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #8
接著上一篇的「區間」,這篇收尾第二幕,講時間在 SQL 裡的兩個坑——它們都源自同一件事:時間是連續的,但你的資料是離散的事件。 中間必然有「什麼都沒發生」的空隙,以及「值變了但你沒記」的變化。SQL…
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #7
Window function 學會之後,這篇是它最漂亮的一個實戰。「連續登入幾天」「把連續的日期收成一段段區間」「找出序號的斷點」——這些看起來各不相同的需求,其實是同一個經典題:gaps and …
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #4
上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案…
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #3
第一篇說 SRE 的內核是「維運可以被工程化」。這篇講的 toil,就是那個要被工程化掉的東西。很多人以為 toil 就是「辛苦的工作」,其實不是——它是一類有明確特徵的工作,而且如果你不主動砍它,它…
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #6
資料重複幾乎是資料工程的日常:pipeline 重跑重複匯入、CDC 把同一筆的多個版本都撈進來、JOIN 的 fan-out 把列複製。很多人一講到去重就 DISTINCT——但去重根本不只 DIS…
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #5
上一篇的 GROUP BY 把每組收合成一列。但你一定遇過這種需求:「我想要整組的計算,又想保留每一列。」 例如——在每一筆訂單旁邊,標上它佔該客戶總額的比例;或在每個月的營收旁,標上跟上個月的差。收…
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #2
上一篇說 error budget = 1 − SLO。但 SLO 是什麼?它跟另外兩個幾乎人人混用的縮寫——SLI、SLA——又差在哪?這三個字分不清,可靠度就無從談起。一句話先記住:SLI 是你「…
· tech · 約 4 分鐘 · 📚 Google SRE 讀書筆記 #1
「SRE」這個詞很紅,但很常被誤解成「高級一點的維運」或「會寫程式的 SysAdmin」。讀完 Google 這本書我的體會是:它的靈魂根本不在職稱,而在一個轉念 + 一個機制——「100% 可靠不是…
· tech · 約 5 分鐘 · 📚 SQL 我以為我懂 #4
GROUP BY 每個人都會寫,但幾乎每個人也都被那句 column "..." must appear in the GROUP BY clause 擋過,而且常常搞不懂「我就選個欄位,為什麼不行?…
· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #3
上一篇的 LEFT JOIN,會幫沒配到的列補上 NULL。那個 NULL 就是這篇的主角——它是無數 SQL bug 的源頭,而根本原因只有一句:NULL 不是一個值,是「不知道」。 一旦你把它讀成…
· tech · 約 6 分鐘 · 📚 SQL 我以為我懂 #2
上一篇把「你寫的順序不是它跑的順序」講清楚了。這篇用同一把鑰匙拆穿 JOIN。很多人把 JOIN 想成「把兩張表黏在一起」,然後死背 INNER/LEFT/RIGHT/FULL 各自的行為。但其實它們…
· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #6
這個系列一路講下來,有兩句話反覆出現:「相信 Catalyst 最佳化器」、「打開 Spark UI 找瓶頸」。但我一直沒回答一個問題:你到底要怎麼看 Spark 做了什麼? 相信最佳化器不該是盲信—…
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #4
第二篇留了一個問題:既然 Pod 是短命的、被換掉就有新的 IP,那別的服務要怎麼穩定找到它?你總不能把某顆 Pod 的 IP 寫死在設定裡——它下一秒可能就不在了。這篇的主角 Service,就是 …
· tech · 約 4 分鐘 · 📚 SQL 我以為我懂 #1
你寫 SQL,幾乎都是 SELECT 開頭。寫久了很自然會以為:它就是從 SELECT 開始跑的。但不是——SQL 是宣告式的,你寫的是「要什麼」,引擎自己決定「怎麼跑、照什麼順序跑」,而它跑的順序跟…
· tech · 約 3 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #11
十一章走到這裡,最後一個問題:資料工程的未來會長怎樣? 書的答案既讓人安心、又有點反直覺 —— 工具會一直變、而且越來越簡單;但底下那套生命週期與暗流,不會變。 這一篇,也是這個系列的完結。 這章把整…
· tech · 約 4 分鐘 · 📚 Kubernetes 學習筆記 #3
第一篇給了靈魂(reconcile loop),第二篇給了原子(Pod)。但實務上你幾乎不會手動去建一個 Pod —— 你宣告的是 Deployment,而它正是 reconcile loop 最實用…
· tech · 約 4 分鐘 · 📚 Kubernetes 學習筆記 #2
上一篇講了 K8s 的靈魂:你宣告期望,reconcile loop 不斷把現實拉過去。但那句「我要 3 個」——3 個什麼?落在哪台機器上?誰決定放哪? 這篇把叢集最基本的三個原子講清楚:Pod、N…
· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #1
很多人學 Kubernetes(K8s)覺得難,是因為一上來就被 kubectl、一堆 YAML 欄位、幾十種資源名詞淹沒。但其實 K8s 只有一個核心觀念,抓住它,後面全部都是同一句話的變形。這個系…
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #10
走完服務,生命週期還有一條貫穿全程的暗流沒單獨講:安全與隱私。書把它排在很後面,卻直說這是最重要、也最常被忽略的一章。而它最反直覺的第一句話是 —— 安全主要是「人」的問題,不是「工具」的問題。 大多…
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #9
前面幾章一路走過源頭、儲存、擷取、建模 —— 但這些辛苦,只有在有人真的拿去用的那一刻才變現。這章講生命週期的最後一站:服務(Serving)。而它的第一原則,只有兩個字。 書把話講得很重:沒人會用他…
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #8
資料擷取進來、存好了,接下來的問題是:怎麼把它變成真正好用的東西? 這章給了三支柱 —— 查詢(Query)、建模(Modeling)、轉換(Transformation)。它們合起來,把「一堆原始資…
· tech · 約 5 分鐘
一句話:dbt(data build tool)是一個讓你「用一堆 SQL SELECT 把資料倉儲裡的原始資料,轉換成乾淨、可信、可重用的模型表」的框架 —— 而且把寫程式的紀律(版控、模組化、測試…
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #7
源頭生出資料、儲存準備好接,中間那條把資料搬進來的動作,就是這章的主角:Ingestion(擷取)。它是生命週期的第二站,也是最多人一上來就糾結「要不要即時」的地方。這章最該先想清楚的一句話是 —— …
· tech · 約 7 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #6
上一篇講資料從源頭生出來。生出來之後第一件事就是:存去哪? 這章談儲存 —— 而它最反直覺的一點是:儲存不是「一個東西」,而是一整條從奈秒到小時、從天價到白菜價的階層。 看懂這條階層,後面所有「該放哪…
· tech · 約 11 分鐘 · 📚 Kubernetes 學習筆記 #8
Airflow 負責「什麼時候、用什麼順序」跑作業,Spark 負責「把大資料算完」。當這兩個東西都搬到 Kubernetes 上,最常見的困惑是:到底有哪些東西在跑、它們各自是不是一個 pod、又被…
· tech · 約 6 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #5
前四章在講大方向 —— 生命週期、架構、選技術。從這章開始,書一階一階走進生命週期的每個環節。第一站是最前面、也最容易被工程師輕看的一段:資料到底是怎麼、在哪裡被生出來的? 這章最該記住的一句話是 —…
· tech · 約 5 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #4
上一篇講架構(why);這一章接著問:在那個架構底下,技術(how)到底該怎麼選? 這章最該先釘進腦袋的一句話是 —— 先有架構,才選技術,不是反過來。 工具是手段,被架構的取捨牽著走;一上來就問「要…
· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #5
前四篇都在講批次的 Spark —— 是什麼、DataFrame 實戰、shuffle 調校、怎麼跑起來。但資料不會等你湊成一批才來:訂單、點擊、日誌是持續流進來的。這篇講 Spark 處理串流的方式…
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #3
上一篇給了生命週期的全貌(資料在做什麼);這一章問的是 —— 怎麼把承載它的系統設計得「好」? 這章最反直覺、也最該記住的一句話是:好的架構不是一張固定的藍圖,而是一個「用權衡換取彈性與可逆」的決策過…
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #6
到目前為止,我們的 DAG 都是「固定的幾個 task、照線跑完」。但真實流程沒這麼乖:有時要依條件走不同分支、某個 task 失敗了清理工作還是得跑、幾十個相似 task 要收整齊、甚至執行期才知道…
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #2
上一篇給了定義,這一章給的是全書的骨架 —— 資料工程生命週期(data engineering lifecycle)。這本書最有價值的貢獻,就是用這個框架把「資料工程在做什麼」講清楚:五個階段 + …
· tech · 約 4 分鐘 · 📚 Fundamentals of Data Engineering 讀書筆記 #1
我開一個新系列,讀 Joe Reis 與 Matt Housley 的 Fundamentals of Data Engineering。這本書最大的價值,是把「資料工程」這個常被講得很模糊的職能,收…
· tech · 約 2 分鐘
這是一篇概念筆記 —— 一個我反覆在用的判斷,獨立成篇,讓其他文章可以連回來。 一句話:在引入任何重型工具或架構之前,先確認你的痛點真的到了需要它的量級。 沒到,就別上 —— 因為重武器的成本不在「裝…
· tech · 約 7 分鐘 · 📚 Kafka 學習筆記 #5
前四篇講的是「Kafka 怎麼用」—— 可重播的 log、核心模型、投遞保證、生態系。這篇收尾,換個視角:當 Kafka 真的上線、要長期穩定跑,維運面得懂哪些事?四塊 —— KRaft(叢集怎麼管自…
· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #4
前三篇都在講 Kafka broker 本身 —— 可重播的 log、核心模型、投遞保證。但真實世界裡你幾乎不會「只用 broker」:資料要從別的系統搬進來、事件的長相要有人管、流上還得做轉換與聚合…
· tech · 約 6 分鐘 · 📚 Airflow 學習筆記 #5
前面幾篇都在講 Airflow 的內部機制 —— 排程、任務間傳資料。但真正的 pipeline 一定得碰外面的世界:查一個資料庫、丟檔案到 S3、打一支 HTTP API、等一個檔案到齊。這篇講 A…
· tech · 約 8 分鐘 · 📚 Kafka 學習筆記 #3
第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at…
· tech · 約 6 分鐘 · 📚 Kafka 學習筆記 #2
第一篇把 Kafka 的心智模型定成一句話:一條可重播的事件 log。但那條 log 實際上怎麼擺、怎麼平行化、一群消費者又怎麼分工?這篇把 Kafka 的四個核心名詞講透 —— Topic、Part…
· tech · 約 4 分鐘 · 📚 Kafka 學習筆記 #1
一句話:Apache Kafka 是一個分散式的「事件串流平台」—— 它把系統之間流動的事件,以高吞吐、可持久化、可重播的 log 形式集中起來,讓很多生產者一直寫、很多消費者各自獨立讀。它源自 Li…
· tech · 約 6 分鐘 · 📚 Spark 學習筆記 #4
前三篇都在講 Spark 怎麼寫、怎麼跑得快(是什麼、DataFrame 實戰、shuffle 調校)。但同一段程式碼,在你筆電上跑、跟在一個幾十台機器的叢集上跑,中間到底發生什麼事?這篇講 runt…
· tech · 約 5 分鐘
一句話:Medallion(獎牌)架構是一種把資料按「品質與精煉程度」分成三層的設計慣例 —— Bronze(原始)、Silver(清洗)、Gold(商業)—— 資料一層一層往上洗,愈往上愈乾淨、愈貼…
· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #4
上一篇講完排程,這篇處理一個很實際的問題:一個 task 算出來的東西,怎麼交給下一個 task? Airflow 的答案是 XCom,而 TaskFlow 把它包得幾乎看不見。順帶也講 params…
· tech · 約 4 分鐘 · 📚 Spark 學習筆記 #3
第一篇和 上一篇都丟下同一句結論:Spark 的效能本體就是 shuffle。這篇把它講透 —— 為什麼 shuffle 貴、它怎麼把作業切成 stage,以及四個實際能少 shuffle、跑更快的手…
· tech · 約 4 分鐘 · 📚 Spark 學習筆記 #2
上一篇把 Spark 的概念講完了:Driver / Executor、分區、惰性求值、shuffle。這篇動手用 DataFrame 實際轉一份資料 —— 讀進來、清洗、彙總、寫出去,並看看 Spa…
· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #3
上一篇我們把 DAG 跑起來了,還特別把 catchup 設成 False「保平安」。這篇就來拆解 Airflow 最反直覺、也最多人卡住的部分:排程到底怎麼運作。搞懂這一段,你才真的會用 Airfl…
· tech · 約 4 分鐘 · 📚 Airflow 學習筆記 #2
上一篇把 Airflow 的概念與架構講清楚了;這篇動手把它在本機跑起來,寫出第一個 DAG,並在 Web UI 上看著它跑完。目標很單純:從零到「我親眼看到自己的 DAG 在介面上變綠」。 方式 指…
· tech · 約 6 分鐘 · 📚 Airflow 學習筆記 #1
一句話:Apache Airflow 是用 Python 把「一連串有相依關係、要定時執行、失敗要能重試與監控」的工作編排起來的工具。它最初由 Airbnb 在 2014 年開發,現在是 Apache…
· tech · 約 5 分鐘 · 📚 Spark 學習筆記 #1
一句話:Apache Spark 是一個把「大到單台機器裝不下、算不完」的資料,切成很多份、分散到一整個叢集上平行運算的引擎。它源自 UC Berkeley(2009),2014 成為 Apache …
· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #6
上一篇談到,「看不到自己」是創新的第一道障礙——你改不掉一個你沒看見的東西。作者給的解法意外地簡單:每天花五分鐘寫日記。而且最有意思的是,光是「開始寫」這個動作本身,就能同時訓練與觀察好幾件事。 聽到…
· tech · 約 2 分鐘 · 📚 成為 Tech Leader 讀書筆記 #5
創新不是少數天才的靈光,而是一種「環境允許你提出不同想法」的能力(呼應 MOI 裡的 Innovation)。但有三種心態會在源頭就把創新擋下來——而且它們往往是無意識的。 第一道牆是看不清自己的行為…
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #4
在真正成為 Leader 之前,有些想法會先把自己擋在門外。 很多人抱著「不在其位、不謀其政」的心態,認為只有頭銜掛著 Leader 的人才有資格管事。問題是,抱這種心態的人真的當上 Leader 之…
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #3
成長模型描述的是「技能隨時間怎麼變化」。同一條成長曲線,在不同的觀察尺度下,會呈現完全不同的形狀。下面從最遠的宏觀、一路拉近到最貼近真實的微觀。 只要每天持續進步,把時間尺度拉得夠遠來看,技能的成長速…
· tech · 約 5 分鐘 · 📚 成為 Tech Leader 讀書筆記 #2
領導方式模型就是透過幾項指標來描述一個環境,MOI模型就是其中一種描述方式 MOI 模型包含三個構面:Motivation(激勵)、Organization(組織)、Innovation(創新)。每個…
· tech · 約 3 分鐘 · 📚 成為 Tech Leader 讀書筆記 #1
「Leadership」這個詞常被誤解成「職位高」、「會下命令」、「有人聽話」——但實際上,Leadership的核心並不是權力或控制,而是影響力。 Leadership應該有其影響範圍,每個人在不同…
· tech · 約 5 分鐘
前陣子幫目前社區實作了一個簡單的車位抽籤頁面,後來其他管理委員們認為可能會被住戶質疑這程式不可信任,可能有黑箱疑慮,藉此研究了一下如何證明這個抽籤流程沒有黑箱。 - 複雜的說是抽籤的過程可受某方控制達…