隨著現代企業對於數據需求的驟增,資料管道的設計與實施變得至關重要。在此,我們將探索一個完整的資料管道,並比較其不同實施方法的優缺點。
目錄
範例介紹
在這個例子中,我們的假設企業叫做Garden Supplies’r’Us,他們需要我們的數據工程支持。他們希望我們將數據進行更多的清理工作,例如消除空白、移除貨幣符號及逗號等等。
資料清理步驟
首先,我們被要求要替換未知類型的數值為 'null',但現在還需要進行以下額外轉換: 1. 除去所有值的空白。 2. 移除收入資料的貨幣符號及逗號。 3. 標準化數據以確保每個客戶同樣的字段。 4. 結合所有客戶的數據,創建一個標準化的模型。
解決方案一:ETLT
利用 ETLT(Extract, Transform, Load, Transform),我們可以在提取和載入階段進行轉換,然後再在 Snowflake 內進行進一步的轉換。此過程可以通過 AWS Lambda 來實現,自動觸發並執行 Python 腳本來處理數據。
解決方案二:ELT 與 dbt
另一個解決方案是使用 ELT,將數據先載入 Snowflake 分割的客戶資料表,而後利用 dbt 進行清理與標準化。這種方式雖保留系統設計但其複雜度會隨客戶數提升。
數據譜系及其他考量
數據譜系用於瞭解數據的來源及流動,協助決策者快速掌握標準化數據的背景。此外還需考量系統的安保與成本;ETLT避免增加 Lambda 成本,ELT則可能提高 Snowflake 费用。
常見問題
- ETLT有什麼優點?它在處理大量客戶數據時具有穩定的架構。
- dbt的缺點是什麼?dbt的缺點在於對大量客戶數據的支援會增加其複雜度。
- 如何管理數據的安全性?兩種方案在安全性上沒有太大差異。
- 轉換數據應該在哪個階段進行?根據需求可以在載入或轉換階段進行。
- 如何控制成本?ETLT通常不會顯著增加成本,而 ELT可能影響 Snowflake 的運算费用。
三個實際故事展示這類架構的使用情境。故事一講述有一家企業如何利用 ETLT 解決其客戶數據爆增的問題。故事二描述了一家小型企業如何簡化其 dbt 系統以提升效能。最後,故事三探討了某金融機構如何搭建一個符合安全需求的資料管道。