Jo

Data Platform 筆記#02：從可行到可承接

學習心得

Data Platform 筆記#02：從可行到可承接

在初版架構逐漸成形後，時間也差不多過了一年。 架構可以跑、資料可以流動，但我仍然不確定它能不能真正落地。這條路必須要團隊可以承接、可以擴展，數據才有機會真正發揮價值。 很慶幸的是，我的主管願意投資時間，讓這個方向能繼續推進。也正是在那段時間，我的思考開始出現轉變... 前一篇的重點，是讓流程從「能跑」走向「能持續」。 而接下來我開始思考：如果這件事要由團隊一起做下去，現在的做法夠不夠讓人接手？ 轉變的核心 回頭看那一年，大多數時間其實是在解問題。 但接下來，我該解的是另一個問題：怎麼讓別人不用再解一次同樣的問題？ 於是投入了約莫三個月、壓力值很高的一段時間，開始把原本依賴個人經驗與記憶的做法，收斂成可以被團隊理解與複製的形式。 這個收斂，後來具體落在幾個方向上： * 把 Data Center 的部署方式收斂成一致做法，降低環境轉換成本 * 把資料整理作業轉變為配置驅動，讓流程與部署有規則可循 * 整理 DDL 轉換規則與範本，讓團隊能共用同一套方法 * 把知識系統化交付出去 這些事情的唯一核心是 讓方法大於個人。 從個人經驗，到規則明確 第一個改變：

By Jo
Data Platform 筆記#01：初版技術架構成形

學習心得

Data Platform 筆記#01：初版技術架構成形

在上篇的 POC 之後，我們整理了一份內部報告，將問題拆成資料蒐集、基礎資料定義、資料量與查詢效能、資料治理、技術架構等幾個面向。 這份整理的目的是先建立邊界，讓我們從發散與模糊，逐步走向具體且聚焦。 在這個基礎上，我開始把關注重點轉向資料流： 如何讓資料自動、穩定、乾淨地進到分析效能較好的資料庫？ 同時，也剛好迎來一個契機：與技術能量較高的團隊合作發展數據中台。這讓 Data Center 的推進獲得更多資源與支援，讓我們能更系統化地思考架構問題。 思考階段 這個階段，我們主要思考幾個問題： * 不同來源的資料，能不能用相對一致的方法接進來？ * 資料會持續累積，是否有合適的儲存與管理方案？ * 資料進來後，分層應該怎麼定義？ * 查詢分析時，是否有更適合的查詢引擎？ 各資料源的特性不同，接收方式很難完全一致。但若每種來源都設計一套專屬流程，維運成本會快速上升。因此初步的想法是先用一種主要方式處理大多數的情境，讓資料流先跑起來，再逐步優化。 過去常見的分層方式，是將資料分成： * 可追溯的原始資料（Stage） * 清洗整理後的乾淨資料（Data） *

By Jo
Data Platform 筆記#00：在變得具體之前

學習心得

Data Platform 筆記#00：在變得具體之前

目標要做資料平台(Data Platform) 一開始我不是很能夠想像這件事該長成什麼樣子，既有的認知只有前期參與的團隊有實作過 HR 資料中心，顧問曾指導資料分層為 Stage、Data、Mart，除此之外，我沒有更多掌握，有很多疑問需要找到答案。 做到什麼程度算是Data Platform？ 我們期待它能解決什麼、幫助到誰？ 它是不是應該包含一套接收資料的方法、能儲存大量資料的資料庫、提供資料服務的能力？   那麼，它是一個平台嗎？該用什麼技術？有哪些其實現在不需要？又該怎麼做，才能保留未來需要的彈性？ 這些問題在當下其實都沒有辦法很快有肯定又具體的答案。好像每一個點都應該被考慮到，但同時又覺得過於理想。那段時間，我甚至開始嘗試透過與 AI 的對話，把模糊的想法拆解成可以被檢視的問題。它沒有辦法替我做決定，但確實加速我釐清問題。 只是，在理解問題的過程，即使把想法轉化輸出成一張張架構圖，進展卻不是太明顯，反而有一種無法落地的感覺，沒有讓事情真正往前走，我們仍然缺少可以被驗證的起點。 開始有切入點的時機，是我們在尋找能夠讓用戶自助調整所需報表的工具，剛好從前的工作曾小量接觸

By Jo
筆記 | 自架 Ghost 的 SMTP 設定

部落格相關

筆記 | 自架 Ghost 的 SMTP 設定

部落格荒廢了好一段時間，近期終於想用手機登入管理介面留下些草稿，突然發現無法登入，登入鈕下方出現了如下的一段訊息 EmailError: Failed to send email. Please check your site configuration and try again. 結論先行，原因是我安裝的 ghost 版本，在首次使用新裝置登入時需要 2FA (二階段驗證)，也就是說，除了帳號密碼登入之外，還會有一層驗證機制，而這層驗證機制需要輸入 6 碼驗證碼 (Ghost 站台發給登入者註冊信箱的 mail 會提供)。我當時建置 Ghost 時認為自己不會發送電子報，就忽略了 SMTP 的設定，導致 Ghost 站台不能正常發信，在配置好 SMTP 設定後，從新裝置就能正常登入了。 前一篇文章提到我的 Ghost 是架設在

By Jo
部落格遷移紀錄

部落格相關

部落格遷移紀錄

是的，又搬家了。 這次搬家像是一種重新開始，遷移的範圍稍微大些，大致上有三段變動： * 從功能豐富的 WordPress 到簡潔高效的 Ghost * 從 SugarHosts 搬遷到 Google Cloud Platform (GCP)，最後搬移到 zeabur Wordpress 的功能非常豐富，只是我使用到的部分極少，總想找個簡潔的服務使用，但忙碌的工作很快就澆熄了動力。一次在輸出小組群組中的討論，注意到 Ghost 這個部落格平台，試裝操作看看，體驗還不賴，想著我的文章數也很少 (心虛)，就搬吧！ 推進這個改變的契機，一部分也來自於 SugarHosts 自 2024 年底在網路社群中的討論，其中也包含了客服過久沒有回應的議題，SugarHosts 的價格真的很有吸引力，只是客服回應效率突然的落差，讓我開始擔心這是否對影響到部落格，開始思考搬家的可能，實際上身邊的朋友也愈來愈多人遇到類似情況，甚至站台無法再使用，措手不及使得只能使用較早期的備份來拯救文章。 我在年假期間利用 GCP 的試用額度來架設

By Jo
筆記 | Ubuntu 掛載磁碟

軟體技術

筆記 | Ubuntu 掛載磁碟

最近在 GCP 試玩 Compute Engine (VM)，建立時另外新增了一顆磁碟，實際運行了才發現，原來需要自行掛載，記錄執行的指令與過程。 以 Ubuntu 22.04 為例 (多數的 Linux 應該也可以使用) 確認新增的磁碟是否存在 lsblk 大多情況應該會看到新的磁碟還沒有掛載任何分區 格式化 (如果硬碟還沒有格式化) sudo mkfs.ext4 /dev/sdb 配置自動掛載 取得新磁碟的 UUID sudo blkid /dev/sdb 一般會顯示類似以下的結果 /dev/sdb: UUID="一串由-符號串接的英數字" BLOCK_SIZE="4096" TYPE="ext4&

By Jo
筆記 | PostgreSQL v12 CTEs 行為改變

軟體技術

筆記 | PostgreSQL v12 CTEs 行為改變

前段時間，工作環境將 PostgreSQL v10 升級到 v15，升級後發現報表的執行效率從 1 秒變成了 2 分多鐘，也剛好變因太多，排查了很多項後才開始面對 SQL 執行計畫，同一段 SQL v10 跟 v15 有很大的差別，許多人花了一番功夫調整，速度才回到水準，接著進一步從調整方向的線索，再爬網路文章，才發現原來在 PostgreSQL v12 有一項對我們來說蠻重要的改變：CTEs 行為改變。 過去經驗裡，SQL 使用 CTE (Common Table Expression) 能將一段查詢的結果暫存起來，在主查詢語句中使用，能有提升查詢效率的效果 例如： WITH temp AS ( SELECT col1, col2, col3 FROM

By Jo
筆記 | 在 Ubuntu 22.04 安裝 Kubernetes Cluster

軟體技術

筆記 | 在 Ubuntu 22.04 安裝 Kubernetes Cluster

許多網路文章中都有安裝 kubernetes cluster 的教學，也因為版本更迭，爬了很多的文章、裝了非常多次，整理以下的筆記，幫自己防忘記。 實作環境 * 主機 (VM) 3 台，一台 master、兩台 node * pve-master * pve-node1 * pve-node2 * 作業系統 Ubuntu 22.04 * Container Runtime 選擇 containerd.io 筆記的幾個大步驟，有些是所有節點都要做，有些則否，整理如底下的表格： Step pve-master pve-node1 pve-node2 安裝前置 V V V 安裝 Container Runtime V V V 安裝 kubeadm

By Jo
心得 | 溝通 - 與下屬講話時的 Checklist

學習心得

心得 | 溝通 - 與下屬講話時的 Checklist

筆記摘自蔡恩全老師在 Master Cheers 的系列課程，章節片段不長，大約 12 分鐘，但有許多讓人省思的地方，也包含了一部分對過去自己答案的肯定，雖然是談管理、對部屬溝通，但除了 coaching 的部分比較屬於帶人的層面，其他的提點也很適用各種溝通場景。 筆記裡已經包含課程大多數內容，我比較想就這個課程中所回憶起的經驗或曾經踩的雷做個回顧，也當成是一次覆盤。 首次擔任管理職是從無到有建立團隊，一一面試選擇團隊夥伴，我想我們應該都同意，不論哪一方，面試時的想像和期待，通常和實際是有些落差的。夥伴的個性不盡相同，對於「了解對方」的能力，我有很多努力的空間，我可以做的，是在每一次的 1 on 1 中，視對方的反應來調整，但仍然是有許多故事。 有一回，和一位剛加入團隊三個月的成員討論工作狀況，我很直接地說：「我發現你的工作進展與我期待的不同，我們過去也定期在檢視跟討論，我想知道是不是有遇到什麼問題，或者需要我協助的地方？」 眼前的大男生回應不到幾句就開始稀裡嘩啦地哭了，一時之間我也有些不知如何是好，遞給他一盒面紙，請他先收拾好情緒後我們再談，在等待的時間裡我是忐忑的，

By Jo
一次對談的歸納

生活閒聊

一次對談的歸納

一次與朋友相聚閒聊，彼此交流著生活中發生的事，可能聊著聊著進入了某程度的心流，在感性與理性間穿梭，意外地發現面臨到的課題雖然不同，卻可以歸納出相近的脈絡。 選擇與後悔 做了一個決定，如果很順利沒什麼不開心，就會覺得自己做了對的決定，反之，就會覺得當時做錯決定了，產生「也許我當初做另一個選擇會比較好」的想法。我們在做決定的當下，通常都會是儘可能考量清楚，也因此心理上會覺得事情應該如預期般地順利獲得期待的結果，事實上是時間在走，會遇到不一樣的人和事，故事線會一直長新的出來，過去已做的決定不會再改變了，可以改變的是應對現在而做出選擇。 不說出口的期待 有些人習慣不說或話中有話，預期對方應該要/應該會懂，然後抱有期待，對方可能為了符合期待(先不論為什麼)，用自己的理解作出回應，答對了皆大歡喜，沒答對卻是一方失望一方委屈，都覺得莫名其妙。 發生這類事情的情境很多，有些情境有一再的機會讓你覺察、調整，逐漸懂得該持續溝通和傾聽，而有些情境你只有一次機會，也許錯失了就失去了，但更需要把握的是這個失去的經驗讓你獲得了什麼。 表達≠溝通 有的人說話習慣貶低對方或字字帶刀，拿「我個性就這樣

By Jo
在 Mac 安裝 Docker Desktop

軟體技術

在 Mac 安裝 Docker Desktop

換了新的 Mac，趁著是乾淨的環境，把安裝過程記錄下來，方便未來查找。 使用 brew 進行安裝，所以開始前需要先為 mac 安裝 brew，在 terminal 執行以下指令： /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 接著就可以安裝 Docker 了 brew install --cask docker (安裝過程中可能需要輸入當前登入帳號的密碼) 正常安裝成功，應該會看到如底下圖片的 "docker was successfully installed! 接著將 docker desktop 打開

By Jo
See all