什麼是 ETL？

當企業需要從多個來源提取資料並將其儲存在集中位置時，資料倉儲的擷取、轉換和載入（ETL）是重要的流程。流程邏輯和基礎架構設計將取決於業務需求、儲存的資料，以及格式是結構化還是非結構化。

什麼是 ETL？

從各種來源提取的資料必須以特定形式儲存，以便應用程式、機器學習、人工智慧和分析能配合使用。ETL 流程是一組業務規則，用於確定用來提取資料的資料來源，將其轉換為特定格式，然後將其載入資料庫。資料可以結構化或非結構化，也可以兩者兼得。

ETL 流程完成後，資料會儲存在資料倉儲中，管理員可以在這裡進一步管理資料。負責儲存 ETL 資料管理記錄、稽核和備份的資料庫的管理員。ETL 事件的記錄資料也可以先經過自己的資料管道，再儲存在資料倉儲中進行管理分析。

ETL 流程

ETL 有三個步驟：擷取、轉換和載入。資料庫管理員、開發人員和雲端架構師通常會使用業務規則和應用程式需求來設計 ETL 流程。ETL 流程的設計解決了以下三個步驟：

• 擷取：擷取的原始資料可能來自一個或多個來源。來源可能來自 API、網站、其他資料庫、IoT 日誌、檔案、電子郵件或任何其他可擷取的資料格式。因為來源可能有多種格式，所以 ETL 的第一步會從來源提取資料，以供下一步使用。
• 轉換：業務規則和目的地儲存位置定義了轉型設計。資料必須經過格式化、篩選和驗證，才能傳送至資料倉儲。重複的資料可能會使分析結果偏誤，因此在儲存重複的明細項目之前，會將其移除。資料經過格式化，以便儲存。舉例來說，電話號碼可能儲存有連字號或沒有連字號，因此轉換過程會在傳送至儲存區之前新增或移除連字號。
• 載入：轉型後，資料會傳送至資料倉儲進行儲存。資料必須保存並避免重複，因此每次 ETL 流程執行時，負載步驟必須考量增量變更。ETL 通常每天運行數次，因此只有新資料被添加，而不會影響資料庫內儲存的當前應用程式資料。

ETL 的優勢

一旦設計好 ETL 流程，就會全天自動運行。部分 ETL 流程可能為每週或每月發生一次，而且大多數資料庫引擎都提供排程器，可在伺服器上運行，以在設定的時間執行任務。精心設計的 ETL 流程不需要太多變更，而且無需手動互動即可從各種來源匯入資料。

未進行任何轉換的原始資料通常不會用於分析，尤其是當您的企業使用來自多個來源的類似資料時。例如，與交通分析合作的企業可能會從數個不同的政府來源取得資料。所有來源都很有可能會建立重複的記錄，但 ETL 流程會取得資料、移除重複資料，並為內部分析應用程式格式化資料。企業可以從多個位置提取資料，並自動為內部分析做好準備，這也推動了未來的業務決策和產品發佈。

ETL 加快資料更新的速度，讓需要處理目前或即時資料的企業受益。傳統上，資料匯入已分批處理，而 ETL 速度緩慢。企業在幾個小時內可能不會看到資料的變化，但目前的 ETL 技術提供資料更新，以便分析能反映近期趨勢的變化。

ETL 工具與技術

對於大型資料管道，大多數組織都為 ETL 使用自訂工具和指令碼。資料庫引擎通常具有自己的 ETL 功能，以便企業能夠匯入資料。儲存資料的方式取決於您是否需要非結構化或結構化資料。結構化資料比非結構化資料需要更多的格式，因此任何現成的工具都必須與您選擇的資料庫平台整合。

ETL 的一些工具：

• 結盟：為拖放式資料管道整合提供開源 GUI
• Informatica PowerCenter：為終端使用者提供工具，以匯入資料，並為商業專案設計自己的資料管道
• AWS 膠水：可讓您從非結構化和結構化資料設計 ETL，以儲存在 S3 儲存桶中
• Google Cloud 資料流：可讓您建立無伺服器 ETL 流程，將資料儲存在 Google Cloud Platform（GCP）

ETL 實作的最佳做法

ETL 設計優良的關鍵在於效能與準確度。效能通常依賴於底層基礎架構，因此擁有一個能夠擴展並跟上負載增加的資料倉儲至關重要。結構式資料通常需要更多時間才能進行轉換，但 FlashArray 的架構是專為大型資料匯入所設計，並確保就地部署的管線能持續快速運行。

始終為規模和未知因素設計 ETL 流程。您最終有可能匯入無法轉換的記錄。任何錯誤都應記錄並儲存，以供進一步審查。這可能意味著您的 ETL 中存在錯誤，或者設計錯失邊緣案例，該案例可透過 ETL 程式碼的變更進行補救。

並非所有 ETL 流程都適用於實體伺服器，因此 Portworx 等解決方案可處理虛擬化和容器化資料庫和分析。容器化服務必須隨著匯入更多資料而擴展，並使用常見的調度工具。Portworx 與調度工具整合，包括 Kubernetes，用於動態且持續更新的管道。

ETL 的挑戰與解決方案

由於資料來源和業務需求不斷變化，負責設計 ETL 的管理員面臨與規模、更新和品質控制相關的挑戰。擴充挑戰通常來自於儲存空間的限制，因此管理員可以透過隨著資料儲存需求增加而擴充的儲存來修復此問題。

業務需求不斷變化的挑戰通常都屬於維護工作。資料來源可能會改變資料儲存的方式，或者開發人員可能會變更應用程式，而需要變更轉換或負載結構。如果沒有來自第三方資料來源的任何文件來提醒管理員，在 ETL 流程中發生錯誤之前，資料儲存或負載要求的變更不會自行出現。記錄和警示有助於管理員及早發現問題，以便變更 ETL 編碼。早期的改變可降低錯誤對業務生產力和營收的影響。

ETL 流程的設計是最困難的任務之一，但當管理人員與利害關係人討論並確保業務規則被納入時，會比較容易。重新設計和重構 ETL 設計可能會延遲部署，並增加不必要的開銷。記錄所有業務規則，以便將每個案例納入 ETL 設計中，以避免重寫過多。

將各種 ETL 流程分開，彼此獨立。此解決方案可確保單一元件故障時，整個 ETL 流程不會發生故障。例如，如果外部 API 損毀，則從所有其他來源擷取的資料仍然會完成，直到 API 再次可用為止。如有需要，也可以建立多個 ETL 排程。如果您使用多個雲端平台，Pure Storage 雲端儲存支援 AWS、Azure、GCP 和其他主要平台。

ETL 與 ELT 

值得注意的是，ETL 可能佔用大量資源，並可能導致資料可用性延遲，特別是在處理大型資料集時。如果即時或近乎即時的資料處理是關鍵需求，其他資料整合方法，如變更資料擷取（CDC）或串流資料管道可能更合適。

此外，近年來 ELT（擷取、載入、轉換）已成為 ETL 的熱門替代方案，尤其是在雲端資料環境中，可在目標資料儲存系統內進行資料轉換。ELT 對於某些使用案例可能更具成本效益和可擴充性，但 ETL 和 ELT 的選擇取決於您的特定需求和使用的技術。

結論

設計 ETL 解決方案需要時間，但別忘了建立一個隨著資料儲存的增加而擴展的系統。要解決最簡單的挑戰之一是資料儲存容量，Pure Storage 解決方案專為非結構化和結構化資料的資料倉儲而打造。

其他挑戰可以透過良好的設計標準、文件記錄和品質保證測試來解決。您可能會發現有些工具有助於設計，但 ETL 通常為企業量身訂做。在預備階段環境中測試少量資料，並期望在引進新業務需求時持續維持 ETL 編碼。