前面已經分享了：
現在要分享在專案中實際使用的範例。
地端架構
- Web Application：共有兩組 Micro Service，處理不同的請求，並將需要的資料寫入本地檔案。
- 上傳到 Dropbox：在 Web Application 伺服器上設定 CronJob，定期將檔案上傳至 Dropbox。
- 下載到 Hadoop 並分析。
AWS 架構
整組地端服務遷移至 AWS 後，新架構如下：
- Web Application：遷移至 EKS，透過 SDK 呼叫 Firehose。
- Firehose：即時收集 Event，並輸出至 S3。
- Hadoop：改在 EMR 上執行，並從 S3 下載檔案。
監控機制
- CloudWatch：設置 CloudWatch Alert，監測 Firehose 錯誤。
- SNS：當發生錯誤時，透過 SNS 發送 Email 通知 Slack，Slack 會即時收到警報。
決策考量與經驗
一個還是兩個 Firehose？
最初考慮建立單一 Firehose Streaming，並透過 Dynamic Partitioning 將資料分類至同一個 S3，但不同的 Folder。
然而，考量到 Firehose 的計價方式是依據處理數據量，因此開啟一個 Firehose 和兩個 Firehose 的價格相差不大。此外，Dynamic Partitioning 需額外付費，並且需要維護 Lambda Function。因此，最終選擇了較單純的雙 Firehose 架構。
Firehose Buffer Hints 設定
Firehose 可設定 Buffer Hints，以下為 S3 目標的設定範圍（其他目標請參考官方文件）：
- Buffer Size：1 – 128 MiB
- Buffer Interval：0 – 900 秒
Firehose 在滿足以下任一條件時，便會將 Buffer 內的資料輸出至 S3：
- 達到設定的 Buffer Size（例如 128 MiB）。
- 達到設定的 Buffer Interval（例如 900 秒）。
舉例來說，若流量較大，則可能在 15 分鐘內達到 128 MiB，進而提前產生檔案。反之，若流量較小，則 Firehose 會每 15 分鐘產生一個檔案。
在地端架構時，檔案是每天上傳一次。然而，遷移至 Firehose 後，因為 Buffer Hints 機制，需特別注意跨日檔案的處理。第一個跨日檔案可能包含前一天的部分資料，因此，需抓取當日與跨日的第一個檔案，才能確保完整的數據。
時區考量
Firehose 預設使用 UTC 時間格式來寫入 S3 Prefix。
若系統依據日期切割檔案，則時區設定非常重要。我們最終選擇使用 'Asia/Taipei'，確保檔案時間與業務需求對應。
這些經驗分享希望能幫助到有類似需求的開發者！
評論