ETL、ELT 和反向 ETL
如何將多個來源的資料導入您的資料倉儲，然後如何透過將您的見解推送到您可以使用的位置來將該資料營運化。
我們將廣泛討論如何著手將您收集的所有資料放入您可以使用的位置。這裡的想法是為您提供一些詞彙和基本概念，讓您了解什麼是 ELT 字母湯。
具體來說，我們將討論擷取、轉換和載入資料。隨著您的組織成長，您將新增更多資料來源，雖然您可以隔離分析這些資料孤島（例如報告收入），但最終您會想要整合這些資料，並將其放在一個您可以根據其做出決策的位置。
我們將從一個問題開始，如何將您的資料放入使其易於提出有關該資料 (ETL) 的問題的結構中，然後討論如何利用您獲得的答案 (反向 ETL)，我們將深入探討沿途涉及的工具。
擷取、轉換、載入
首先，先繞道定義術語並區分 ELT 與 ETL。廣義而言，這些術語指的是在資料倉儲或資料超市中準備用於分析的資料，但具體來說，這些字母代表
- 擷取：從您的應用程式和您使用的其他服務取得資料。
- 轉換：清理、篩選、格式化、彙總、合併、豐富，以及一般來說組織該資料，使其更易於在您的資料庫中建立模型（例如客戶建模）。
- 載入：將該資料儲存在資料倉儲中（或在反向 ETL 的情況下，將其推送到第三方服務）。
ETL vs ELT
更複雜的是，當人們說 ETL 時，他們通常指的是 ETL 或 ELT，或兩者兼而有之。這些首字母縮寫詞（您說出每個字母；它是 E.T.L.，而不是「ettle」）指的是從來源取得資料、對其執行某些操作，然後將其儲存在某處以便人們可以查詢的一般過程。ETL 和 ELT 之間的主要區別在於，使用 ETL 時，資料轉換步驟發生在資料倉儲外部。
從歷史上看，您會使用單一工具（例如 Informatica）來擷取、轉換資料，並將資料載入您的資料倉儲，但隨著世界走向 ELT 範例，您會看到更多針對流程每個部分量身打造的工具。
典型 ETL 管線
資料來源 -> 像 Hadoop、Spark 或 Informatica 這樣的分散式處理軟體 -> 像 Redshift、BigQuery 或 Snowflake 這樣的資料倉儲。
在伺服器叢集上執行的 Hadoop、Spark 或 Informatica 工作會清理資料、豐富資料、彙總資料，並以其他方式組織資料，然後再將其載入資料倉儲。
典型 ELT 管線
資料來源 -> 像 Fivetran 這樣的擷取工具 -> 資料倉儲 (Redshift、BigQuery、Snowflake) -> 由像 DBT 這樣的軟體在您的資料倉儲中定義和排程的轉換工作。
隨著資料倉儲的改進，越來越多人只是擷取資料，並將原始、未轉換的資料載入資料倉儲。進入資料倉儲後，他們會轉換資料，將原始資料組織成更易於分析的表格：例如，收集記錄的事實表格，以及收集彙總的摘要表格。
一般來說，世界正朝著 ELT 方法發展，主要有三個原因
- 資料倉儲已改進；它們現在可以處理傳統上由 Hadoop 叢集等完成的運算工作。
- 您也可以將原始資料儲存在資料倉儲中，這讓您可以在未來執行不同的轉換，以回答有關資料的新問題。
- 資料倉儲也變得更便宜（這很好）。
何時偏好 ETL
話雖如此，ETL 仍然有很好的用例（Metabase 公司同時使用這兩種方法）。當您符合以下條件時，ETL 是不錯的選擇
- 您有特別複雜的資料轉換（有時稱為轉換），
- 或者您想在將資料載入資料倉儲之前對資料執行機器學習，
- 或者您需要變更資料格式以符合資料庫的規格。
從 ETL 到反向 ETL 的範例資料流程
讓我們保持簡單，假設您僅從三個來源收集資料
現在，假設您想知道客戶支援如何影響續約率。若要分析此影響，您需要檢閱來自 Stripe 的訂閱資料，並將其與來自 Zendesk 的支援資料進行比較。
擷取資料
雖然您可以自行開發工具來擷取資料，但通常您會想要使用可以為您處理該複雜性的服務（例如，跟上每個 API、排程工作、處理錯誤等等）。
在評估擷取工具時，您會想要尋找以下選項
- 擁有您需要的所有連接器。一旦您使用某個工具，請務必在評估其他相關工具時考慮其連接器庫。例如，如果您使用 Fivetran，然後稍後發現自己正在為電子郵件行銷平台購物，請考慮使用 Fivetran 支援的平台。
- 可以增量擷取資料（而不是簡單的批次處理）。您可能不需要即時資料，但您可能希望在幾分鐘內而不是每天一次取得更新。
- 不要變更資料，或至少不要大幅變更。您應該是轉換資料的人，而不是擷取服務。
此領域有很多選項：Airbyte、Peliqan、Fivetran、Segment、Singer 和 Stitch。
將資料載入資料倉儲
在此上下文中，載入僅表示您正在將資料放入儲存體（有時稱為接收器）。此資料儲存體可以是標準交易資料庫（例如 PostgreSQL 或 MySQL）、簡單的檔案系統（例如 S3，搭配像 Presto 這樣的查詢引擎），或是針對分析查詢最佳化的資料倉儲（例如 BigQuery、Redshift 或 Snowflake）。
資料倉儲概觀不在本文的範圍內，因此我們僅將您轉介至 您應該使用哪種資料倉儲？。對於本文，您可以更廣泛地（理想情況下）將您的資料倉儲視為您的事實來源。
轉換資料
有很多不同的方法可以清理、篩選、格式化、豐富或以其他方式轉換您的資料，包括將其與其他資料結合。您也可以彙總資料，例如，判斷流程的開始和停止時間以計算其持續時間。
在 ELT 世界中，您會想要一個與您的資料倉儲搭配使用的工具，以取得原始資料、轉換資料，然後將轉換後的資料插入到您資料倉儲中的其他表格。這樣，您將保留從各種來源擷取的原始資料，以及此已清理、準備好用於建模和分析的資料，所有這些都在一個資料倉儲中。
在評估用於轉換資料的工具時，您會想要以下軟體
- 以 SQL 作為其主要語言。堅持使用單一語言會更容易，而且大多數資料庫都了解 SQL。
- 讓您可以對 SQL 進行版本控制。如果您變更查詢且資料看起來不正確，您會想要回溯到該查詢的先前版本，以找出問題所在。
- 可以測試您的程式碼，例如，確認輸出中的所有 ID 都是唯一的。
- 讓您可以記錄這些工作，最好擷取欄位資料和譜系（以便您知道資料來自何處）。
現在您已深入了解您的資料，您要如何使用它？
回到我們的範例，找出客戶支援是否能提高續約率。假設您得知，在客戶年度訂閱的最後九十天內關閉支援工單可以將續約率提高顯著的百分比。那麼您接下來想要做的是標記由即將結束年度訂閱的客戶提交的 Zendesk 幫助工單，以及在續約日期臨近時與他們聯絡，看看您是否可以協助他們充分利用您的服務。
您可以透過幾種方式將此見解插入您的幫助工單系統
- 您可以手動執行報告，查看哪些公司即將續約，在 Zendesk 中新增一個欄位，顯示客戶是否為
UP_FOR_RENEWAL，並優先處理這些工單。 - 建立一個自訂工具以每晚執行，然後使用其 API 更新 Zendesk 中的欄位。
- 使用像 Zapier 這樣的工具來協調 Stripe 和 Zendesk 之間的資料。
- 使用像 Census 這樣的工具，將此資料點從您的資料倉儲推送到相關應用程式（在本例中為 Zendesk）。
反向 ETL 或資料營運化
將資料推送到內部或第三方工具的工具採用兩種基本方法之一。它們要麼透過監聽應用程式中的事件來自動化工作流程，並更新其他應用程式以使其保持同步，要麼它們從單一事實來源將資料推送到相關應用程式。
我們將強烈建議採用單一事實來源方法，因為它可以大幅降低讓您的應用程式保持最新狀態並取得所需資料的複雜性。像 Zapier 這樣的工具必須努力使您的各種應用程式保持同步，而像 Census 這樣的工具只是定期從您的資料倉儲讀取資料，並將更新推送到需要它們的位置。
這裡的主要想法是，靜態資料比您必須協調的資料更易於維護。隨著您的組織成長，您將使用更多服務，這將需要更多協調。Census 採用的單一事實來源方法避開了協調挑戰，並且當您嘗試處理複雜邏輯時，它的優勢非常明顯。
假設您得知，當公司在九十天窗口期內且每年向您支付超過 X 金額且他們位於三個地理區域之一且他們在去年提交了 X 張工單等等時，續約率效應最強。使用 Zapier，您必須與其他應用程式協調，以同步篩選您想要客戶成功團隊優先處理的客戶所需的資料。使用 Census（可以執行 DBT 工作來計算資料點），您只需要查詢資料倉儲，然後將該查詢的結果推送到幫助工單軟體。如果您想要將大量資料插入像 Tensor Flow 分類器這樣的工具中，並讓它只吐出分類器認為您應該優先處理的客戶，情況也是如此。
從這個意義上說，「反向 ETL」一詞有點用詞不當，因為 Census 並未轉換資料；它只是從資料倉儲讀取資料，並告訴其他應用程式它們需要知道的內容；在本例中，是您的成功團隊應優先處理哪些客戶。
延伸閱讀
如需資料如何在組織中流動的概觀，請查看我們關於 現代資料堆疊 的文章。