ETL 實作流程SOP

已更新:5月 24

今天文章不談「什麼是ETL」及「定義ETL」,網路上有太多邏輯清楚又易讀的精采文章(e.g. Bryan所寫的Data Pipeline101 ),我們想分享的是真實狀況中,當您身為一位資料工程師,可供實戰的SOP。





Transform(轉置)


ETL流程分別為Extract(萃取)、Transform(轉置)、Load(載入),大部份情況下,Transform所耗心力是最重的,Transform的守備範圍(資料處理),也通常是從業務場景的最終需求,反推回來做:

1. 與業務單位訪談,知道BI要看哪些報表,回推看既有資料欄位是否能滿足,是否需要join、union,甚至進一步的cleansing、mining。

2. 不同的報表觀看者對於資料的顆粒度有不同要求,依使用者需求聚合資料。例如高管僅需要看到週層級銷售額,因此可在此階段將每日銷售資料聚合成較「粗」的週層級資料。


3. 呈上,較粗顆粒度的資料,因資料量較聚合之前小,通常效能表現也較好(大家都希望高管可以滿意報表開啟的速度XD)。



Extract(萃取)、Load(載入)


在開始此段落之前我們先確認現有架構:AP端(收資料的UI, Web, App, etc.…)->AP Server(AP端存資料的地方)

  • AP Server(DB)在哪?雲上?地上?

  • AP Server(DB)架構?e.g. 若ERP用的是SAP B1,Windows環境使用的是Microsoft SQL Server、Linux環境則是SAP HANA。


得知現行架構後,我們就可以回答以下規劃問題:

1. Data Warehouse(DW)想要建在哪?雲上?地上?

註1:DW on cloud 為的是不必耗額外網管資安的心力,也不用找機房來放硬體。

註2:如AP Server(DB)與DW建置在不同環境下,需考慮資料傳輸時間、資料流出費用等議題



2. DW想要的DB架構? 註:我們首推PostgreSQL,一來沒有複雜的授權議題,二來版本單純,三來有些data mining很好用的語法。延伸閱讀:PostgreSQL與MySQL比較


3. 資料庫管理工具推薦Navicat。視DB架構而定,如果只用一個DB架構,那很簡單300美金的事,如果有多個DB架構,則必須買Premium版,1,300美金。

註:Navicat介面宜人,費用合理,絕對是您打怪升級的好幫手


4. 是否有選定好ETL tools?或其他建置方式?若無打算採購ETL tools,建議以Python code建置,有些企業(例如銀行)不允許安裝第三方程式語言,這要多留意。

註:主流工具如informatica、trinity等,皆具有高易用性,但就是需負擔額外的軟體費用。


5. 預計多久更新一次DW資料?(一天、半天、1hr、15min?)


此篇文章提出的檢查清單經大幅簡化過,都是最常應用到的問題,實務上也常遇到組織剛成功導入ERP後,需要另串接BI工具,此情境還會再加上ERP服務商的三方需求訪談會議。


「成功不必在我,苦工我們承擔,掌聲留給你們。」潤謙更專注於資料處理的過程,將最終完善的資料結果或處理技術交還給客戶充分使用 - 這是我們對ETL導入的理念!


如您對我們的服務範圍、導入效益、使用的相關軟硬體感興趣,歡迎至此連結查看更多說明並提交需求,我們的專業夥伴會盡快聯繫您:https://www.runinbase.com/etl


110 次瀏覽0 則留言