EDC - 廣告受眾資料處理中心
目錄
一、技術一覽
二、開發功能特色介紹
三、技術詳細說明（各功能網站端、資料端）
一、技術一覽
- 前端：Vue3, ElementPlus, Tailwind, EChart, Xlsx, Axios, Echarts, Vite, Pinia, etc.
- 前端模板：Admin-one.
- 後端：Laravel, Inertia, Laravel-Permission, JWT-Auth, Horizon（Queue）, Migration, Commands, Testing, etc.
- 資料庫：Mysql, MongoDB, Redis, BigQuery.
- 環境：AWS EC2, Docker（使用 Laradock 為主）.
- CI/CD：Jenkins, Ansible.
- 版控：Git.
- 資料處理：Python
設計規範：
- 後端：以 PSR1, PSR2 為主
- 前端：JavaScript Standard Style
- 資料處理：遵循 PEP 8 (Python Enhancement Proposal 8) 風格
二、開發功能特色介紹
【網站端】
- 全站點（自家產品及合作媒體）全載具（App, Web, CTV）數據統計
- 提供不同期間＆各平台、載具多圖表（eg: 長條圖, 圓餅圖, etc.）數據統計
- 定義活躍用戶＆活躍用戶數據統計功能（=活躍用戶意味著有較大信心可以被投遞出廣告的用戶資料）
- 家戶受眾打包
- 任務狀況寄信通報
- 用戶權限管理
- 資料緩存
【資料端】
- 全站點（自家產品及合作媒體）全載具（App, Web, CTV）資料處理
- 整合並建構用戶流量 Demographic
- 整合並建構註冊會員 Demographic
- 建構 Household 資料
- 定期清洗無效的用戶流量資料（約 7億筆儲存其它系統的 Mysql 的資料）
- 程式錯誤時回報＆重新運行機制
三、技術詳細說明（各功能網站端、資料端）
EDC 從 0 開始構建，主負責廣告投遞前用戶數據的分析 與 統計，呈現結果或者需要廣告業務操作的部分會在網站上呈現。
資料部分一律在背景以 Python 程式方式運行，處理後的資料立於呈現於網站上，或者用於報告及部分資料需求需要進行的分析及整理呈現。
1. 全站點載具數據統計：
【網站端】
前端：以 Admin-one 作為UI模板（主要使用 Tailwind CSS），並且額外再導入 ElementPlus 與 EChart 即可因應日常業務的 UI 需求，並 Component 化，如此一來圖表可重複利用，排版部分則使用 Tailwind 上的 Grid。
由於採前後端分離開發，所以使用 Inertia 來整合前後端的 Router，便於維運，前端封裝常用的功能，例如 Axios, 請求的API等，封裝與我個人專案AI 工作數據分析儀表板一致，可前往查閱。
後端：資料部分以 Python 處理為主，部分程式則以 Php 來處理，並透過 Commands 撰寫成指令，立於直接執行與測試。
資料取出部分有些需要特別注意成本，由於有些資料儲存在 BigQuery，每次查詢需要支付一定費用，故有兩個方法來降低成本，第一是透過緩存，例如將資料儲存在MongoDB等；第二是記錄每次查詢耗費的容量，來計算出大約的價格（因為 IT 與 RD 權責分離，故只能根據官網定價簡易進行推算，並確保與當月價格差異不大）。
後端開發方式除了三層架構，也有部分 Class 需要額外設計，例如使用策略、抽象工廠模式等，來確保可維護性及易讀性。
【資料端】
因為資料處理與網站端在同一台 VM 上，且要處理所有平台全載具（Web, App, CTV）每日上百萬的用戶流量，所以在資料端需要特別注意事項就在「資源運用」上，與高併發有異曲同工之妙，都是要在有限的資源上來達到高效的運用，同時確保高穩定性，不能讓程式時常發生錯誤，否則就會造成當天的資料不正確，後續若有業務需求也會導致延宕。
正因為如此，要確何時何地有幾隻程式會運行，以及這些程式的資源分配為何？舉例來說，假設今天有些運行的程式不是 Python，而是 PHP，那麼就可以透過 Docker 的 yml 來設定 CPU 及記憶體的用量上限，確保 Server 上始終保持足夠的吞吐量，不會因為吞吐量不夠，導致網站端提供給用戶的服務延宕甚至出錯。
若程式有順序關係也需注意，整個資料端的作業其實就是 ETL，但這塊處理方式尚較原始，並無使用任何 ETL 的工具（這也是未來應當導入的方向），純粹以 Python 及 Crontab 完成。
於2024年後的構建的新系統 BCS 中，我也導入 Prefect 來各直觀處理工作流，詳細請看 BCS-廣告預算控制系統 的介紹。
這一塊的 ETL 處理的事務諸多，有些不一定會呈現在網站上，而是為了未來投遞廣告使用而儲存的資料，例如給用戶流量貼標（年齡、興趣、觀看節目、媒體等）、家戶資料製作等，很多時候遇到的技術難題都在於資料量大下的資源運用，如何能高穩定且高效率（可在時間內完成）來讓程式執行完成，諸如程式算法的改善（BigO(1)）、資料庫選型（OLTP, OLAP）、Query 優化等等。
2. 家戶受眾打包：
【網站端】
前端：UI 交互程式開發（以 ElementPlus 為主），因為是前後端分離，所以呼叫 Api 後，前端即完成，任務較為簡單，主要就是細節，例如點擊按鈕後鎖定按鈕並出現 Loading 圖示，讓用戶知道不能再點擊，實現上並無難點，最後有開會同時提供教學文檔給用戶。
後端：使用 Laravel 的 Queue 來進行開發，同時透過 Horizon 來管理 Queue 與 Job，Driver 使用 Redis，Horizon 的監控面板則透過 Laravel-permission 設立一個 horizon viewer 的角色，擁有該角色的帳號才有權限來查閱 Horizon 面板中每個 Queue 中 Jobs 的執行概況，權限判定在 HorizonServiceProvider 中處理。
用 Queue 來開發就是為了避免前端的 I/O 堵塞，因應業務需求同一使用者可能會在同一時段打包大量的受眾包，所以使用 Queue 來解決這個問題。
【資料端】
家戶資料的建立同樣由我先建立一套準則，爾後經過多次開會及修繕最終定案。
這些資料亦是為了廣告投遞所用，也是公司業務主要銷售產品之一，於 2024-07 後，產品的曝光量是不錯的（會議上得知）。
透過多種將用戶組成家戶資料，過程需要排除極端值，極端值可以用 IQR（四分位距）方式排除，或者在有一定資料且經過一段時間後資料被貼上標籤，透過監督式學習來預測哪些家戶是無效，來確保有更精確的資料，舉例來說一個有十萬ID的受眾包，曝光量只有500；跟一個有一千ID的受眾包，曝光量有500，很顯然前者的受眾包會更加廉價，因為大多ID並沒有廣告的曝光的機會。
3. 環境配置
