Skip to main content

問題一:資料分析數據整合困難?

以下是一般搭建數據渠道的複雜流程,數據團隊需要建置從資料源到 ETL (Extract, Transform, Load) 再到 Database/Data warehouse 最後到數據分析、BI 或者 AI 軟體中。

現在的數據流程通常由 Databases > ETL > Data Warehouse > Data Mart > End User

在這個流程裡會花費很多時間是在做資料的搬移與落地,像是數據需要從 Database ETL 到 Data Warehouse,或是從 Data Warehouse 把特定的欄位搬移到 Data Mart 上最後會再給應用單位使用。資料不斷拉取與落地會造成數據的延遲性以及會讓數據不斷的在各個地方有許多重複的資料,照成未來數據維護上也變得更加困難。

當數據分析團隊,需要得到一個應用端所請求的數據需要建立像是以下的數據架構,隨著資料複雜度增長日益複雜。

flow

企業決定要搭建 ETL 後,我們常看到第一件錯誤就是直接開始撰寫 ETL 相關程式碼,事實上開發 ETL 的解決方案跟軟體開發是一樣的,企業需要在事前的規劃與思考企業至少中期在 ETL 架構上要怎麼維護以及更新等需求。除了這些問題之外我們也會在這邊分享,在一些細部的導入撰寫 ETL 所需要的注意項目。

當你在準備開發 ETL 時你需要先了解幾個基本項目

  1. 資料要從哪裡進來?
  2. 資料要處理完後需要放到哪裡?
  3. 收到的單位有什麼使用上的需求以及他的分析技術到哪裡?
  4. 整個公司對於未來長期的 ETL 架構規劃與設計為何?

建置 ETL 有常見以下挑戰:

1. 資料樣貌依據不同應用需求不一

在要開始建立 ETL 前,您必須先要瞭解到企業內部的數據應用以及需求,以下有幾點需要注意

  1. 資料來源:資料來源是在哪些單位,未來資料要如何中期長期合作與更新數據?新的需求的時候合作模式要如何跟上需求?在很多企業中資料來源的複雜度增加速度是非常快的,一開始幾個到後來需求單位變多資料來源也會增加非常快速。
  2. 資料使用狀況:資料量級會多大?未來是否會持續增長?增長速度多快?新需求的使用需要多快滿足?
  3. 資料延遲性:對於有些業務需要更快更即時的數據,而有些業務並不需要這麼快的速度。速度與延遲性跟成本與費用都有相關性,所以必須要了解的是企業內部對於各個資料的要求程度為何?可以接受的延遲性為何?

2. 審查與追蹤數據治理

來源數據都可能改變與變化,要如何追蹤來源數據以及即時的更動數據變更是一大挑戰!要如何追蹤源頭的數據源以及能夠讓企業內部的人員了解異動都是需要一個流程的建立與追蹤。

3. 萃取資料時間效能取捨

如何萃取資料以及萃取資料方式需要確定,因為各個系統有自己的驗證機制,需要去符合所有的企業是具的驗證機制得到所需要的數據來源是一個需要注意的地方。

還有像是有些資料萃取來源也有 bandwidth, 資料量以及速度等等限制企業也需要就這些應用場景的需求做萃取的策略因應。

4. 資料清理與轉換變更

在資料清理與轉換這個階段要注意幾個地方

  1. 資料結構的重構
  2. 資料型別的變化
  3. 資料 schema 的追蹤與監控

以上這三個在做資料轉換時都需要注意資料進來後需要變成什麼資料格式、型別為何以及資料 schema 的追蹤與監控都是重要的環節企業要注意的地方。

5. 未來管理以及營運隱藏成呠

ETL 建構完成之後才是挑戰的開始,需要確保

  1. 資料更新的自動化:在未來新數據進來之後要如何自動化的處理與管理?
  2. 監控:能夠最即時的資料企業數據現在的處理階段,並且監控所有數據流動的效能。
  3. 回溯與追蹤:如果資料在這個版本發生問題,要如何立即的回溯與追蹤錯誤來源?
  4. ETL 測試:建置新的需求的 ETL 測試流程為何,要更換已經運行已久的 ETL 要如何確保能夠做正確的更換?
  5. 安全:由於資料會透過 ETL 轉換許多階層,需要確保在每個環節數據安全性是達到企業的要求。

總結建置 ETL 的挑戰有哪些?

  1. 從數據來源到商業應用,會需要花費非常大的時間與人力成本投入才能達到。
  2. 以現在的系統建置,建置 Data warehouse, data mart 在數據配送上還是會遇到許多挑戰,更多請查看
  3. 應用端還是遇到很多數據應用瓶頸,不論是在效能、資源分配、建置成本等。
  4. 雲端要建置這樣的架構,需要專業人員、複雜度高。
  5. 數據治理與管理框架。