👾 Hi, 我是 Bevis 👾

歷經培訓班與兩個多月艱辛的求職，我終於順利轉職。儘管最終職位與最初預期有所落差，但實務上卻是更適合我的發展。若你正準備或已在轉職工程師的路上，本文總結了我的真實經歷與實務觀點，希望能為你帶來具體協助。 目錄 前言 個人簡介 轉職經歷 培訓過程 求職過程 轉職前建議 1. 轉職前評估 2. 轉職難易度評估 培訓期建議 1. 報名轉職培訓班 2. 付費使用 AI 工具 3. 提前預習和嘗試 結訓後建議 1. 持續優化履歷 2. 準備自製履歷 3. 持續學習 4. 調整求職策略 5. 保持心態健康 結語 前言 我是在 2025 年底至 2026 年初，從非資訊領域轉入軟體業。這篇文章主要分享轉職前、中、後期的實戰建議與心得，內容通用，適合處於轉職任一階段的朋友閱讀。 考量篇幅，未來我會另闢專文探討「資料工程領域」的現況，以及大環境變動下的轉職建議。若你正在考慮轉職資料工程師，建議屆時搭配閱讀，以更全面地評估產業生態。 個人簡介 每個人的學經歷不同，面臨的轉職挑戰也大相徑庭。如果沒有交代個人背景便容易失去參考價值。以下是我的簡歷，背景與我越相似，或許就越容易遇到類似的挑戰與瓶頸： 學歷：東吳大學 中文系與政治系 學士畢業。 工作經驗：過去 7 至 8 年皆從事影像拍攝、直播與剪輯，最高擔任剪輯組主管，管理 3 至 4 人。 轉職前自學：從 2025 年 2 月開始接觸，自學 Python 及資料科學相關基礎。 培訓班種：雲端資料工程師 技術棧：專題開發涵蓋 Python、MySQL、Airflow、Docker、GCP、Git；課堂有教但未運用於專案的包含 MongoDB、Kafka、Hive。 轉職經歷 以下簡述從報名培訓到成功錄取的時間線。

不久前，一位朋友得知我具備程式開發能力，便詢問能否協助建置一個簡易的會員系統以簡化內部流程。基於其需求，我以 Python 開發後端、Google Sheet 作為資料庫，並搭配 Streamlit 建構前端介面，打造了一套輕量化且可免費部署的會員管理系統，作為內部工具使用已相當足夠。 目錄 相關連結 需求確認 技術選型 資料庫 資料表 系統功能 服務部署 結語 相關連結 GitHub Streamlit（試用） 專案起因 甫結束轉職培訓班的課程不久，一位經營獨立健身工作室的朋友得知我在學習程式開發，便詢問是否能協助開發一套內部使用的會員管理系統。在評估過對方的需求與我目前的能力後，認為這是一個不錯的實戰機會，於是便開啟了這個輕量化會員管理系統的專案。 需求確認 本專案屬於客製化委託，因此所有的技術選擇與開發方向皆需緊扣客戶（對方）的需求。以下為客戶的背景與具體需求： 無技術背景：團隊內無技術開發人員，原先僅使用 Excel 或雲端試算表進行紀錄。 內部使用：系統僅供員工內部紀錄，不對外開放給會員使用。 核心功能：需包含會員登記、交易行為記錄、金額結算等基本功能。 低維運成本：屬於試驗性質的專案，維運方面並無多餘預算。 技術選型 基於上述需求，我為專案規劃了以下的基本架構： 後端：Python 我目前最熟悉的程式語言，擁有豐富的套件支援。 資料庫：Excel 或 Google Sheet 這是客戶團隊最熟悉的工具。即便系統發生意外，他們仍能直接開啟檔案進行編輯與修正。 操作彈性：即使因操作失誤導致系統報錯，客戶也能手動修正資料，保持營運彈性。 合適優於完美：作為資料工程人員，我深知試算表並非正規的資料庫。但考量客戶缺乏 SQL 操作能力，選擇正規資料庫反而可能因技術門檻造成額外困擾。在此情境下，選擇合適的工具比追求技術上的完美更為恰當。 前端：Streamlit 目前最輕量、易於開發與部署的 Python 前端框架。作為內部工具，其功能與介面質感已相當足夠。 部署：地端或低價（免費）雲端平台 考量客戶幾無維運預算，且應用場景多為上班時間的辦公室環境，將系統建置於地端或免費的雲端服務（PaaS）是較合理的選擇。 資料庫 雖然透過 Python 程式能靈活地調整功能，但資料庫作為系統的核心，承載了客戶最重要的資產。因此，資料庫的建置與規劃應在初期就定案，避免後續修改牽一髮而動全身，增加維護成本。 地端資料庫 由於客戶習慣使用 Excel 記錄，開發初期我優先採用地端檔案作為資料庫。針對此專案性質，地端部署有其合理性： 使用時間固定：僅在營業時間使用，無需 24 小時運作。 安全性考量：因無專職人員維護，非使用時間關閉資料庫，反而能物理性地避免未授權的修改。 我採用以下邏輯建立資料庫連線： 在專案目錄中建立 Excel 檔，並設定檔名。 將檔名設為全域常數，透過函式在專案目錄中搜尋，進行路徑定位。 取得絕對路徑後讀取檔案。 Fitness-Studio-Member-System/ ├── codes/ # 集中存放程式碼 │ ├── mod/ # 存放模組化程式 │ └── main.py # 測試用主程式 ├── database.xlsx # 地端資料庫 (Excel 檔案) ├── streamlit_app.py # Streamlit 主程式入口 ├── requirements.txt # 專案依賴套件清單 └── README.md # 專案說明文件 此設計的考量點在於：

作為第一個經過完整開發流程的專案，我已經撰寫兩篇文章說明專案的特點與開發遇到的困難與挑戰。最後我想更細節的分享這個專案的各個環節，我們所做的決定和一些細節。我想這篇文章會更偏向「紀錄」，所以並未有太多的技術價值，但若你正好有需要可以作為參考。 目錄 相關連結 概述 專案選題 資料爬蟲 資料庫 資料表 ETL/ELT流程 自動化 雲端部署 資料分析與視覺化 相關連結 GitHub Tableau Dashboard 01 Tableau Dashboard 02 概述 本專案（相關閱讀：《六都寵物資源分析開發實錄》、困難與挑戰）旨在透過蒐集六都寵物店家資訊，分析資源分布與商業潛力，並以視覺化儀表板呈現。 作為一個 End-to-End 的資料工程專案，我們建立了一套自動化的 Data Pipeline，涵蓋爬蟲、ETL、資料倉儲、分析到視覺化。 技術棧 領域 工具/技術 用途 資料獲取 Python Script, Google Maps API 網站爬蟲與 API 串接 ETL/ELT Python (Pandas) 資料清洗、轉換與格式化 資料庫 MySQL (GCP Cloud SQL/VM) 關聯式資料庫儲存 自動化排程 Apache Airflow 工作流調度與監控 雲端 & DevOps GCP (Compute Engine), Docker 雲端基礎設施與容器化部署 CI/CD GitHub Actions 自動化部署 BI 視覺化 Tableau 互動式儀表板製作

在學習資料工程的過程中，雖然沒有特別區分，但從講師的敘述和某些技術中，隱隱可以察覺「大數據」和一般的資料工程是有區隔的，不單單只是「資料變多」而已。所以雖然不在課程內，但我另外又搜尋了一些與大數據有關的資料，包括大數據下的資料庫設計、大數據下的資料工程等。除了分享也作為筆記，讓自己可以重複複習關於大數據的相關知識。 目錄 簡介 資料庫設計模型 大數據的資料工程：反正規化與效能優化 大數據的資料檢驗工程 結語 簡介 在軟體工程的世界裡，資料庫往往是系統的瓶頸所在。當資料規模從 GB 成長至 TB 甚至 PB 等級，我們面臨的不僅是儲存空間的挑戰，更是計算能力的典範轉移 (Paradigm Shift)。 1. 大數據的特殊性 (Volume, Velocity, Variety) 傳統單機資料庫（RDBMS）依賴 Vertical Scaling (Scale-up)，透過升級 CPU 和記憶體來提升效能。然而，硬體升級有其物理極限。大數據架構的核心在於 Horizontal Scaling (Scale-out)，利用數百甚至數千台商用伺服器組成叢集，共同處理龐大的資料集。 2. 分散式架構的本質 在大數據領域（如 Hadoop 生態系、Spark、Cloud Data Warehouses），我們遵循 「分而治之 (Divide and Conquer)」 的哲學： 儲存與計算分離 (Storage-Compute Separation)：現代架構傾向將資料存在物件儲存（如 S3, GCS, HDFS），計算資源（如 Spark Executors）則是動態調配的。 移動計算而非移動數據：由於網路 I/O 是最大的效能瓶頸，我們盡可能將程式碼派發到存放資料的節點上執行，而非將資料拉回中心節點處理。 資料庫設計模型 理解資料模型的適用場景，是架構師進行技術選型（Tech Stack Selection）的第一步。 1. 一般資料庫模型 (General Purpose / OLTP) 這些模型通常應用於應用程式後端，強調交易的即時性與一致性。 Relational Model (RDBMS) 代表：MySQL, PostgreSQL, Oracle。 特性：嚴格 Schema、ACID 交易保證、使用 SQL。 適用：核心業務系統（Core Banking, ERP），資料一致性要求極高的場景。 Document Model 代表：MongoDB。 特性：Schema-less (BSON/JSON)、支援巢狀結構、開發迭代快。 適用：內容管理系統 (CMS)、產品目錄 (Catalog)、屬性高度動態的資料。 Key-Value Model 代表：Redis, DynamoDB。 特性：Hash Table 結構、O(1) 讀寫延遲。 適用：快取 (Cache)、Session Store、高併發計數器。 Graph Model 代表：Neo4j。 特性：以節點 (Node) 與邊 (Edge) 儲存關係，解決遞迴查詢效能問題。 適用：社交網絡分析、推薦引擎、路徑演算法。 2. 大數據與資料倉儲模型 (Analytical / OLAP) 當場景轉向數據分析時，寫入效能不再是首要考量，查詢吞吐量 (Throughput) 與 歷史資料整合 才是重點。