Housing Crisis Analysis System

Housing Crisis Analysis System 是一個分析 Reddit 與 Mastodon 上澳洲住房危機討論的大學團隊雲端專案。系統透過 Kubernetes、Fission 與 Elasticsearch，串起定期資料蒐集、處理、儲存與分析；Jupyter Notebook 再透過 API 取得分析結果。

我負責部署與系統整合，包括 Fission 設定、自訂 Docker runtime、分析 API、Elasticsearch 資料匯入與效能調校。資料蒐集、NLP 處理、Elasticsearch mapping 與視覺化主要由其他團隊成員負責。

團隊需要把分別開發的資料蒐集、處理、可搜尋的資料儲存、分析 API 與 Notebook 呈現串成一套能運作的雲端系統。初次將約 33 萬筆文件寫入 Elasticsearch 時，耗時超過 4 小時，拖慢後續驗證與分析迭代。

專案使用 NeCTAR 提供的課程環境。我負責讓既有平台、functions、runtime 依賴、資料流與 API route 能接起來並穩定運作。

我在 NeCTAR 提供的環境中，主要負責 Kubernetes 與 Fission 的部署設定、服務整合與除錯、自訂 Docker image、分析 API 部署，以及 Elasticsearch 匯入效能調校；也使用 CronJob 執行排程工作，並以 Kubernetes Secrets 注入服務憑證。

我的工作範圍限於課程提供的環境，不包含 Kubernetes 叢集佈建、autoscaling、SRE 維運或完整的 production security architecture。

我設定 Fission 部署環境與 HTTP routing，讓 Jupyter Notebook 能呼叫分析 functions。為了讓 NLP 與 API 工作負載使用一致的依賴，我建立自訂 Docker image 並整合到 function 的部署流程。

針對 Elasticsearch 初次匯入，我調整成 bulk ingestion、批次寫入與平行化處理。部署與效能觀察時，我使用 kubectl top 與 Kibana 協助除錯，並以 GitLab 集中管理整合後的程式碼與部署資源。

定期資料蒐集透過 Kubernetes CronJob 與 Fission functions 執行；Python 工作負載使用自訂 Docker runtime；Elasticsearch 負責儲存與聚合；Fission HTTP routes 提供分析 API，最後由 Jupyter Notebook 透過 API 取得分析結果。平台部署在 Melbourne Research Cloud（NeCTAR）的 Kubernetes 環境。

• 在 NeCTAR Kubernetes 環境整合 Fission functions、Docker runtime、Elasticsearch 與分析 API。
• 以 CronJob 排程定期工作，並以 Kubernetes Secrets 注入服務憑證。
• 將約 33 萬筆資料的初次索引時間由超過 4 小時降至約 1 小時。