Aidan 的部落格 —— 用圖像加精簡的文字,把資料工程與技術領導講清楚。https://blog.aidan.tw/zh-Hanthttps://blog.aidan.tw/blog/sql-index/https://blog.aidan.tw/blog/sql-index/加了索引查詢快幾百倍,但有時加了卻沒用——關鍵在懂它的資料結構 B-tree。沒索引是全表掃 O(n),有索引是沿樹往下 O(log n)。但索引不是免費的(拖慢寫入),複合索引有最左前綴的規矩,而把欄位包進函式、用前導萬用字元,都會讓它悄悄失效。Sat, 11 Jul 2026 00:00:00 GMTsqlperformancehttps://blog.aidan.tw/blog/sql-time-scd/https://blog.aidan.tw/blog/sql-time-scd/時間在 SQL 裡有兩個很多人踩的坑,而且都跟『區間』有關。一是分桶:GROUP BY date_trunc 只會產出有資料的桶,沒事件的時段整列悄悄消失,時間序列就斷了。二是維度會變:客戶搬家、產品改分類,你得用 SCD Type 2 把歷史的樣子記下來,而不是直接覆蓋。Fri, 10 Jul 2026 00:00:00 GMTsqldata-engineeringhttps://blog.aidan.tw/blog/sql-gaps-islands/https://blog.aidan.tw/blog/sql-gaps-islands/連續登入幾天、把連續日期收成一段區間、偵測序號斷點——這些看似不同的需求,骨子裡都是同一個經典難題:gaps and islands。名字嚇人,但有一招極優雅的解法:value 減掉 ROW_NUMBER,同一段連續區間會得到固定的常數,GROUP BY 它就切出每一座島。Fri, 10 Jul 2026 00:00:00 GMTsqldata-engineeringhttps://blog.aidan.tw/blog/sre-monitoring/https://blog.aidan.tw/blog/sre-monitoring/監控不是『收集一堆數字』,是回答兩個問題:壞了嗎?快壞了嗎?但該量什麼?Google 把它精煉到只剩四個——延遲、流量、錯誤、飽和度。如果一個服務只能盯四個指標,就盯這四個。另外一個關鍵:別看平均,平均會把長尾藏起來,要看 p99。Fri, 10 Jul 2026 00:00:00 GMTsremonitoringhttps://blog.aidan.tw/blog/sre-toil/https://blog.aidan.tw/blog/sre-toil/Toil 不是『辛苦工作』的同義詞,而是一類有明確特徵、該被消滅的工作:手動、重複、可自動化、做完系統卻沒變更好、還會隨服務規模線性成長。它最可怕的地方是會自然膨脹到吃光你做工程的時間——所以 Google 設了一條 50% 的護欄。Fri, 10 Jul 2026 00:00:00 GMTsrereliabilityhttps://blog.aidan.tw/blog/sql-dedup/https://blog.aidan.tw/blog/sql-dedup/資料重複太常見——重複匯入、CDC 多版本、JOIN fan-out。但去重不是只有 DISTINCT,而且資料工程最常要的那種去重,DISTINCT 根本解不了。關鍵是先分清兩種『重複』:完全相同的列,和同一個 key 有多筆版本——後者要用 ROW_NUMBER 挑代表那筆。Thu, 09 Jul 2026 00:00:00 GMTsqldata-engineeringhttps://blog.aidan.tw/blog/sql-window/https://blog.aidan.tw/blog/sql-window/會不會 window function,幾乎是判斷一個人 SQL 深不深的分水嶺。它跟 GROUP BY 只差一個字:不收合——保留每一列,同時在每列旁邊算一個「看整組」的值。搞懂 OVER 的三個旋鈕(PARTITION BY、ORDER BY、frame),排名、環比、累計、每組前 N 名就全部解鎖。Thu, 09 Jul 2026 00:00:00 GMTsqlconceptwindow-functionhttps://blog.aidan.tw/blog/sre-slo/https://blog.aidan.tw/blog/sre-slo/上一篇說 error budget = 1 − SLO,但 SLO 到底是什麼?它跟幾乎人人混用的 SLI、SLA 差在哪?一句話:SLI 是你量到的數字、SLO 是你內部拚的目標、SLA 是你對客戶的合約。而且 SLA 一定比 SLO 寬鬆——這個『對內嚴、對外鬆』的 buffer,是可靠度工程最成熟的一手。Thu, 09 Jul 2026 00:00:00 GMTsrereliabilityhttps://blog.aidan.tw/blog/sre-intro/https://blog.aidan.tw/blog/sre-intro/SRE 常被誤解成『高級維運』或『會寫程式的 SysAdmin』。它的靈魂其實是一個轉念加一個機制:100% 可靠不是對的目標,而 Error Budget(= 1 − SLO)把『開發要快 vs 系統要穩』這場沒完沒了的戰爭,變成一道大家一起算的數學題。這是整個系列的脊椎。Thu, 09 Jul 2026 00:00:00 GMTsrereliabilityhttps://blog.aidan.tw/blog/sql-group-by/https://blog.aidan.tw/blog/sql-group-by/幾乎每個人都被『column must appear in the GROUP BY clause』這個錯誤擋過。真正的原因很簡單:GROUP BY 把每一組的多列收合成一列,聚合函數再把『一組多值』壓成一個數——收合之後,非 key 的欄位有好幾個值,SQL 不知道要吐哪一個。懂這個收合模型,bare column、WHERE vs HAVING、ROLLUP 就都通了。Wed, 08 Jul 2026 00:00:00 GMTsqlconcepthttps://blog.aidan.tw/blog/sql-null/https://blog.aidan.tw/blog/sql-null/把 NULL 當成 0 或空字串,是無數 SQL bug 的源頭。NULL 不是一個值,是「不知道」——任何跟它比較的結果不是 TRUE 也不是 FALSE,而是第三種:UNKNOWN。搞懂三值邏輯,NOT IN 回空、AVG 分母不對、= NULL 篩不到這些坑會一次通。Wed, 08 Jul 2026 00:00:00 GMTsqlconcepthttps://blog.aidan.tw/blog/sql-joins/https://blog.aidan.tw/blog/sql-joins/很多人把 JOIN 想成「把兩張表黏起來」,還得背 INNER/LEFT/RIGHT 各是什麼。其實只要一個模型:所有 JOIN 都是先列出兩表所有列的組合(笛卡爾積),再用 ON 過濾。懂這句,連幾乎人人踩過的『LEFT JOIN 被 WHERE 悄悄變回 INNER』都一次看穿。Wed, 08 Jul 2026 00:00:00 GMTsqlconcepthttps://blog.aidan.tw/blog/spark-explain/https://blog.aidan.tw/blog/spark-explain/前面幾篇一直叫你「相信 Catalyst」「打開 Spark UI 找瓶頸」,卻沒教你怎麼看。這篇補上這塊:你的一行 code 怎麼變成執行計畫、.explain() 怎麼讀、以及讀計畫時最該盯的三個字——Exchange、BroadcastHashJoin、PushedFilters。Tue, 07 Jul 2026 00:00:00 GMTsparkdata-engineeringperformancehttps://blog.aidan.tw/blog/k8s-service/https://blog.aidan.tw/blog/k8s-service/Pod 隨時會被換掉、IP 會變,那別的服務怎麼穩定找到它?答案是 Service——一個固定的 IP 與 DNS 名字,擋在一群生生死死的 Pod 前面,並自動把流量分到健康的那些。這篇把 Service、背後的 Endpoints 名單、以及對外的幾種類型講清楚。Tue, 07 Jul 2026 00:00:00 GMTkubernetesconceptnetworkinghttps://blog.aidan.tw/blog/sql-execution-order/https://blog.aidan.tw/blog/sql-execution-order/大家寫 SQL 都是 SELECT 開頭,於是以為它從 SELECT 開始跑——但其實 SELECT 幾乎最後才執行。搞懂真正的邏輯執行順序 FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT,一票「為什麼這樣寫會錯」的謎題會一次解開。這是整個系列的脊椎。Tue, 07 Jul 2026 00:00:00 GMTsqlconcepthttps://blog.aidan.tw/blog/fode-11/https://blog.aidan.tw/blog/fode-11/系列完結篇。資料工程的未來是什麼?這篇拆《Fundamentals of Data Engineering》最後一章——工具會一直變、還越來越簡單,但生命週期與暗流不變。押地基,別押工具。Mon, 06 Jul 2026 00:00:00 GMTdata-engineeringbook-noteshttps://blog.aidan.tw/blog/k8s-deployment/https://blog.aidan.tw/blog/k8s-deployment/你幾乎不會手動建 Pod——真正宣告的是 Deployment。這篇看 reconcile loop 最實用的化身:Deployment → ReplicaSet → Pod 怎麼自我修復、又怎麼零停機滾動更新與一鍵回滾。Mon, 06 Jul 2026 00:00:00 GMTkubernetesconcepthttps://blog.aidan.tw/blog/k8s-pod-node-scheduler/https://blog.aidan.tw/blog/k8s-pod-node-scheduler/上一篇的 reconcile loop 幫你維持「我要 3 個」,但那 3 個到底是什麼、落在哪台機器、誰決定?這篇講 K8s 最基本的三個原子——Pod、Node、Scheduler,並解釋為什麼 Pod 是短命的。Mon, 06 Jul 2026 00:00:00 GMTkubernetesconcepthttps://blog.aidan.tw/blog/k8s-intro/https://blog.aidan.tw/blog/k8s-intro/K8s 難學,常常是因為先背 API 再學觀念。這篇從頭講:它到底解決什麼問題,以及讓一切都串起來的那一個核心觀念——宣告式的期望狀態 + reconcile loop。這是整個系列的地基。Mon, 06 Jul 2026 00:00:00 GMTkubernetesconcepthttps://blog.aidan.tw/blog/fode-10/https://blog.aidan.tw/blog/fode-10/書把安全排在很後面,卻說它最重要也最常被忽略。這篇拆《Fundamentals of Data Engineering》Ch.10——安全其實是人的問題不是工具問題,以及「資料是資產也是負債」這個會改變你收資料態度的反轉。Sun, 05 Jul 2026 00:00:00 GMTdata-engineeringbook-notessecurityhttps://blog.aidan.tw/blog/fode-9/https://blog.aidan.tw/blog/fode-9/前面辛苦擷取、儲存、建模,全都是為了這一站:把資料送到有人真的用的地方。這篇拆《Fundamentals of Data Engineering》Ch.9——服務資料的最高原則是信任,以及 BI、嵌入式分析、ML、Reverse ETL 各自怎麼被餵。Sat, 04 Jul 2026 00:00:00 GMTdata-engineeringbook-notesdata-servinghttps://blog.aidan.tw/blog/fode-8/https://blog.aidan.tw/blog/fode-8/資料進來、存好之後,怎麼變成好用的東西?這篇拆《Fundamentals of Data Engineering》Ch.8 的三支柱——查詢、建模、轉換,用 star schema 與正規化↔寬表兩張圖,講清楚分析型資料模型怎麼設計。Fri, 03 Jul 2026 00:00:00 GMTdata-engineeringbook-notesdata-modelinghttps://blog.aidan.tw/blog/dbt-intro/https://blog.aidan.tw/blog/dbt-intro/dbt 是什麼?一篇搞懂它如何用一堆 SQL SELECT,把倉儲裡的原始資料轉成乾淨可信的模型,並把版控、測試、血緣、文件這套工程紀律帶進 ELT 的 T。Fri, 03 Jul 2026 00:00:00 GMTdbtdata-engineeringanalytics-engineeringhttps://blog.aidan.tw/blog/fode-7/https://blog.aidan.tw/blog/fode-7/資料工程生命週期的第二站:把資料從源頭搬進系統。批次還是串流?push、pull 還是 poll?用光譜圖與三種取數模式講清楚,並說明為什麼批次到今天仍是預設。Thu, 02 Jul 2026 00:00:00 GMTdata-engineeringbook-notesingestionhttps://blog.aidan.tw/blog/fode-6/https://blog.aidan.tw/blog/fode-6/上一篇講資料從源頭生出來。生出來之後第一件事就是:存去哪? 這章談儲存 —— 而它最反直覺的一點是:儲存不是「一個東西」,而是一整條從奈秒到小時、從天價到白菜價的階層。 看懂這條階層,後面所有「該放哪、放多久、花多少」的決定才有依據。 書從最底層的物理材料往上疊:CPU 快取、R…Wed, 01 Jul 2026 00:00:00 GMTdata-engineeringbook-noteshttps://blog.aidan.tw/blog/airflow-spark-on-k8s/https://blog.aidan.tw/blog/airflow-spark-on-k8s/Airflow 負責「什麼時候、用什麼順序」跑作業,Spark 負責「把大資料算完」。當這兩個東西都搬到 Kubernetes 上,最常見的困惑是:到底有哪些東西在跑、它們各自是不是一個 pod、又被丟到哪一台機器上? 這篇用兩張圖把它畫清楚 —— K8s 上不同的 node 怎…Tue, 30 Jun 2026 00:00:00 GMTkubernetesairflowsparkdata-engineeringhttps://blog.aidan.tw/blog/fode-5/https://blog.aidan.tw/blog/fode-5/前四章在講大方向 —— 生命週期、架構、選技術。從這章開始,書一階一階走進生命週期的每個環節。第一站是最前面、也最容易被工程師輕看的一段:資料到底是怎麼、在哪裡被生出來的? 這章最該記住的一句話是 —— 資料生在你不擁有的系統裡,你永遠是下游。 資料工程師很少生資料,我們接資料 …Tue, 30 Jun 2026 00:00:00 GMTdata-engineeringbook-noteshttps://blog.aidan.tw/blog/fode-4/https://blog.aidan.tw/blog/fode-4/上一篇講架構(why);這一章接著問:在那個架構底下,技術(how)到底該怎麼選? 這章最該先釘進腦袋的一句話是 —— 先有架構,才選技術,不是反過來。 工具是手段,被架構的取捨牽著走;一上來就問「要用哪個工具」,順序就已經錯了。 很多團隊的決策長這樣:看到一個當紅的工具 → 決…Tue, 30 Jun 2026 00:00:00 GMTdata-engineeringbook-noteshttps://blog.aidan.tw/blog/spark-streaming/https://blog.aidan.tw/blog/spark-streaming/前四篇都在講批次的 Spark —— 是什麼、DataFrame 實戰、shuffle 調校、怎麼跑起來。但資料不會等你湊成一批才來:訂單、點擊、日誌是持續流進來的。這篇講 Spark 處理串流的方式 —— Structured Streaming,而它最聰明的一步,是叫你根本不…Mon, 29 Jun 2026 00:00:00 GMTsparkdata-engineeringstream-processinghttps://blog.aidan.tw/blog/fode-3/https://blog.aidan.tw/blog/fode-3/上一篇給了生命週期的全貌(資料在做什麼);這一章問的是 —— 怎麼把承載它的系統設計得「好」? 這章最反直覺、也最該記住的一句話是:好的架構不是一張固定的藍圖,而是一個「用權衡換取彈性與可逆」的決策過程。 沒有最好的架構,只有在這個脈絡下相對好的取捨。 書的定義值得抄下來:資料架…Mon, 29 Jun 2026 00:00:00 GMTdata-engineeringbook-notesarchitecturehttps://blog.aidan.tw/blog/airflow-control-flow/https://blog.aidan.tw/blog/airflow-control-flow/到目前為止,我們的 DAG 都是「固定的幾個 task、照線跑完」。但真實流程沒這麼乖:有時要依條件走不同分支、某個 task 失敗了清理工作還是得跑、幾十個相似 task 要收整齊、甚至執行期才知道要跑幾個 task。這篇講 Airflow 的四個流程控制工具,把 DAG 從玩…Sun, 28 Jun 2026 00:00:00 GMTairflowdata-engineeringdag-designhttps://blog.aidan.tw/blog/fode-2/https://blog.aidan.tw/blog/fode-2/上一篇給了定義,這一章給的是全書的骨架 —— 資料工程生命週期(data engineering lifecycle)。這本書最有價值的貢獻,就是用這個框架把「資料工程在做什麼」講清楚:五個階段 + 六條暗流(undercurrents)。讀懂這張圖,後面九章都只是在它上面長細節…Sun, 28 Jun 2026 00:00:00 GMTdata-engineeringbook-noteslifecyclehttps://blog.aidan.tw/blog/fode-1/https://blog.aidan.tw/blog/fode-1/我開一個新系列,讀 Joe Reis 與 Matt Housley 的 Fundamentals of Data Engineering。這本書最大的價值,是把「資料工程」這個常被講得很模糊的職能,收斂成一套清楚的框架與語言。第一章先回答最根本的問題:資料工程到底是什麼、資料工程…Sun, 28 Jun 2026 00:00:00 GMTdata-engineeringbook-noteshttps://blog.aidan.tw/blog/pain-before-power/https://blog.aidan.tw/blog/pain-before-power/這是一篇概念筆記 —— 一個我反覆在用的判斷,獨立成篇,讓其他文章可以連回來。 一句話:在引入任何重型工具或架構之前,先確認你的痛點真的到了需要它的量級。 沒到,就別上 —— 因為重武器的成本不在「裝起來」,在「之後每天要餵養它」。 我指的是那些威力強、但維運成本也高的東西:Ai…Sun, 28 Jun 2026 00:00:00 GMTconceptdata-engineeringhttps://blog.aidan.tw/blog/kafka-ops/https://blog.aidan.tw/blog/kafka-ops/前四篇講的是「Kafka 怎麼用」—— 可重播的 log、核心模型、投遞保證、生態系。這篇收尾,換個視角:當 Kafka 真的上線、要長期穩定跑,維運面得懂哪些事?四塊 —— KRaft(叢集怎麼管自己)、retention 與 compaction(log 怎麼不爆又留得住)、…Fri, 26 Jun 2026 00:00:00 GMTkafkadata-engineeringoperationshttps://blog.aidan.tw/blog/kafka-ecosystem/https://blog.aidan.tw/blog/kafka-ecosystem/前三篇都在講 Kafka broker 本身 —— 可重播的 log、核心模型、投遞保證。但真實世界裡你幾乎不會「只用 broker」:資料要從別的系統搬進來、事件的長相要有人管、流上還得做轉換與聚合。這些 broker 都不做 —— 它們由一圈生態元件補上。這篇講最核心的三個:…Fri, 26 Jun 2026 00:00:00 GMTkafkadata-engineeringstream-processinghttps://blog.aidan.tw/blog/airflow-providers/https://blog.aidan.tw/blog/airflow-providers/前面幾篇都在講 Airflow 的內部機制 —— 排程、任務間傳資料。但真正的 pipeline 一定得碰外面的世界:查一個資料庫、丟檔案到 S3、打一支 HTTP API、等一個檔案到齊。這篇講 Airflow 連外部系統的四個積木 —— Provider、Operator、H…Thu, 25 Jun 2026 00:00:00 GMTairflowdata-engineeringintegrationhttps://blog.aidan.tw/blog/kafka-delivery/https://blog.aidan.tw/blog/kafka-delivery/第二篇講完事件「怎麼擺、誰來讀」,留了一個更尖銳的問題:崩潰重啟後,一筆事件到底會被重複處理、還是漏掉?這篇把 Kafka 的可靠性講透 —— acks、複本與 ISR、commit 時機,以及 at-most-once / at-least-once / exactly-onc…Thu, 25 Jun 2026 00:00:00 GMTkafkadata-engineeringreliabilityhttps://blog.aidan.tw/blog/kafka-topics/https://blog.aidan.tw/blog/kafka-topics/第一篇把 Kafka 的心智模型定成一句話:一條可重播的事件 log。但那條 log 實際上怎麼擺、怎麼平行化、一群消費者又怎麼分工?這篇把 Kafka 的四個核心名詞講透 —— Topic、Partition、Offset、Consumer Group —— 它們合起來決定了吞…Wed, 24 Jun 2026 00:00:00 GMTkafkadata-engineeringmessaginghttps://blog.aidan.tw/blog/kafka-intro/https://blog.aidan.tw/blog/kafka-intro/一句話:Apache Kafka 是一個分散式的「事件串流平台」—— 它把系統之間流動的事件,以高吞吐、可持久化、可重播的 log 形式集中起來,讓很多生產者一直寫、很多消費者各自獨立讀。它源自 LinkedIn(2011),後來成為 Apache 頂級專案,如今是幾乎所有「即時…Wed, 24 Jun 2026 00:00:00 GMTkafkadata-engineeringevent-streaminghttps://blog.aidan.tw/blog/spark-running/https://blog.aidan.tw/blog/spark-running/前三篇都在講 Spark 怎麼寫、怎麼跑得快(是什麼、DataFrame 實戰、shuffle 調校)。但同一段程式碼,在你筆電上跑、跟在一個幾十台機器的叢集上跑,中間到底發生什麼事?這篇講 runtime 與部署 —— 從本機單機,一路到 spark-submit、cluste…Tue, 23 Jun 2026 00:00:00 GMTsparkdata-engineeringdeploymenthttps://blog.aidan.tw/blog/medallion-architecture/https://blog.aidan.tw/blog/medallion-architecture/一句話:Medallion(獎牌)架構是一種把資料按「品質與精煉程度」分成三層的設計慣例 —— Bronze(原始)、Silver(清洗)、Gold(商業)—— 資料一層一層往上洗,愈往上愈乾淨、愈貼近業務。它由 Databricks 推廣,在 lakehouse 場景特別常見,…Tue, 23 Jun 2026 00:00:00 GMTdata-engineeringdata-modelinglakehousehttps://blog.aidan.tw/blog/airflow-xcom/https://blog.aidan.tw/blog/airflow-xcom/上一篇講完排程,這篇處理一個很實際的問題:一個 task 算出來的東西,怎麼交給下一個 task? Airflow 的答案是 XCom,而 TaskFlow 把它包得幾乎看不見。順帶也講 params —— 在觸發時把參數塞進整個 DAG run。 XCom(cross-comm…Sun, 21 Jun 2026 00:00:00 GMTairflowdata-engineeringxcomhttps://blog.aidan.tw/blog/spark-shuffle/https://blog.aidan.tw/blog/spark-shuffle/第一篇和 上一篇都丟下同一句結論:Spark 的效能本體就是 shuffle。這篇把它講透 —— 為什麼 shuffle 貴、它怎麼把作業切成 stage,以及四個實際能少 shuffle、跑更快的手段。 groupBy、join、distinct 這類 wide 轉換,需要把「…Sun, 21 Jun 2026 00:00:00 GMTsparkdata-engineeringperformancehttps://blog.aidan.tw/blog/spark-dataframe/https://blog.aidan.tw/blog/spark-dataframe/上一篇把 Spark 的概念講完了:Driver / Executor、分區、惰性求值、shuffle。這篇動手用 DataFrame 實際轉一份資料 —— 讀進來、清洗、彙總、寫出去,並看看 Spark SQL 怎麼和 DataFrame API 殊途同歸。 上一篇提過 RDD…Sun, 21 Jun 2026 00:00:00 GMTsparkdata-engineeringpysparkhttps://blog.aidan.tw/blog/airflow-scheduling/https://blog.aidan.tw/blog/airflow-scheduling/上一篇我們把 DAG 跑起來了,還特別把 catchup 設成 False「保平安」。這篇就來拆解 Airflow 最反直覺、也最多人卡住的部分:排程到底怎麼運作。搞懂這一段,你才真的會用 Airflow。 新手最大的誤解,是以為「@daily 的 DAG 在每天 00:00 觸…Fri, 19 Jun 2026 00:00:00 GMTairflowdata-engineeringschedulinghttps://blog.aidan.tw/blog/airflow-first-dag/https://blog.aidan.tw/blog/airflow-first-dag/上一篇把 Airflow 的概念與架構講清楚了;這篇動手把它在本機跑起來,寫出第一個 DAG,並在 Web UI 上看著它跑完。目標很單純:從零到「我親眼看到自己的 DAG 在介面上變綠」。 方式 指令 適合 --------- airflow standalone pip in…Tue, 16 Jun 2026 00:00:00 GMTairflowdata-engineeringdockerhttps://blog.aidan.tw/blog/airflow-intro/https://blog.aidan.tw/blog/airflow-intro/一句話:Apache Airflow 是用 Python 把「一連串有相依關係、要定時執行、失敗要能重試與監控」的工作編排起來的工具。它最初由 Airbnb 在 2014 年開發,現在是 Apache 的頂級專案,核心理念是 workflows as code —— 你的流程不是…Sun, 14 Jun 2026 00:00:00 GMTairflowdata-engineeringorchestrationhttps://blog.aidan.tw/blog/spark-intro/https://blog.aidan.tw/blog/spark-intro/一句話:Apache Spark 是一個把「大到單台機器裝不下、算不完」的資料,切成很多份、分散到一整個叢集上平行運算的引擎。它源自 UC Berkeley(2009),2014 成為 Apache 專案;最大的賣點是把資料放在記憶體裡運算,對需要反覆讀同一份資料的工作(報表彙總…Sun, 14 Jun 2026 00:00:00 GMTsparkdata-engineeringpysparkhttps://blog.aidan.tw/blog/btl-6/https://blog.aidan.tw/blog/btl-6/上一篇談到，「看不到自己」是創新的第一道障礙——你改不掉一個你沒看見的東西。作者給的解法意外地簡單：每天花五分鐘寫日記。而且最有意思的是，光是「開始寫」這個動作本身，就能同時訓練與觀察好幾件事。 聽到「每天寫日記」這個任務時，先別急著做，先注意自己的第一反應：是覺得排斥、麻煩？還…Fri, 26 Dec 2025 00:00:00 GMTleadershipinnovationhttps://blog.aidan.tw/blog/btl-5/https://blog.aidan.tw/blog/btl-5/創新不是少數天才的靈光，而是一種「環境允許你提出不同想法」的能力（呼應 MOI 裡的 Innovation）。但有三種心態會在源頭就把創新擋下來——而且它們往往是無意識的。 第一道牆是看不清自己的行為。如果你意識不到自己現在是怎麼做事的、有哪些習慣與盲點，就沒有任何改進的施力點—…Fri, 19 Dec 2025 00:00:00 GMTleadershipinnovationhttps://blog.aidan.tw/blog/btl-4/https://blog.aidan.tw/blog/btl-4/在真正成為 Leader 之前，有些想法會先把自己擋在門外。 很多人抱著「不在其位、不謀其政」的心態，認為只有頭銜掛著 Leader 的人才有資格管事。問題是，抱這種心態的人真的當上 Leader 之後，往往會把自己當成團隊裡「最重要的那個人」——彷彿少了他，團隊就轉不動。 但好…Fri, 12 Dec 2025 00:00:00 GMTleadershiphttps://blog.aidan.tw/blog/btl-3/https://blog.aidan.tw/blog/btl-3/成長模型描述的是「技能隨時間怎麼變化」。同一條成長曲線，在不同的觀察尺度下，會呈現完全不同的形狀。下面從最遠的宏觀、一路拉近到最貼近真實的微觀。 只要每天持續進步，把時間尺度拉得夠遠來看，技能的成長速度看起來就是一條穩定上升的線性直線——投入多少、就累積多少。 但把時間尺度縮小、…Tue, 09 Dec 2025 00:00:00 GMTleadershiphttps://blog.aidan.tw/blog/btl-2/https://blog.aidan.tw/blog/btl-2/領導方式模型就是透過幾項指標來描述一個環境，MOI模型就是其中一種描述方式 MOI 模型包含三個構面：Motivation（激勵）、Organization（組織）、Innovation（創新）。每個構面都代表領導者塑造環境的方式。 1. Motivation 激勵 - Moti…Sun, 30 Nov 2025 00:00:00 GMTleadershiphttps://blog.aidan.tw/blog/btl-1/https://blog.aidan.tw/blog/btl-1/「Leadership」這個詞常被誤解成「職位高」、「會下命令」、「有人聽話」——但實際上，Leadership的核心並不是權力或控制，而是影響力。 Leadership應該有其影響範圍，每個人在不同團體內的Leadership各自不同，傳統上最快分辨出Leadership的方式…Sun, 12 Oct 2025 00:00:00 GMTleadershiphttps://blog.aidan.tw/blog/braised-pork-rice/https://blog.aidan.tw/blog/braised-pork-rice/滷肉飯的固體物偏少，醬汁味道偏甜，油豆腐味道很好口感紮實，滷白菜好吃，整體來說不貴，路過沒人排隊的話可以考慮Sat, 20 Sep 2025 00:00:00 GMThttps://blog.aidan.tw/blog/lottery/https://blog.aidan.tw/blog/lottery/前陣子幫目前社區實作了一個簡單的車位抽籤頁面，後來其他管理委員們認為可能會被住戶質疑這程式不可信任，可能有黑箱疑慮，藉此研究了一下如何證明這個抽籤流程沒有黑箱。 - 複雜的說是抽籤的過程可受某方控制達到特定人士的定義 - 簡單說就是有利的我讓我自己必中籤，不利的我不會被抽中 要達…Sat, 20 Sep 2025 00:00:00 GMThttps://blog.aidan.tw/blog/ramen/https://blog.aidan.tw/blog/ramen/口味介於台式和日式中間，麵體是細麵，叉燒是全熟那種超讚，個人認為應該是林口區最讚的，推薦雞豚或辛麻Fri, 19 Sep 2025 00:00:00 GMT