數(shù)據(jù)工程:ELT 工作流中的 6 個步驟
數(shù)據(jù)轉換過程可以分為六個步驟:提取extraction和加載loading、探索exploration、轉換transformation、測試testing、文檔documentation和部署deployment。

數(shù)據(jù)轉換是獲取原始數(shù)據(jù)并從中獲取意義的過程;它構成了所有分析工作的基礎,并代表了數(shù)據(jù)從業(yè)者如何從他們的公司創(chuàng)造有形的價值。
數(shù)據(jù)轉換過程通常可以分解為六個常規(guī)定義的步驟:提取和加載、探索、轉換、測試、文檔和部署。執(zhí)行這些步驟后,原始數(shù)據(jù)將采用一種有意義的新形式,為公司的商業(yè)智能工作提供支持。
我們將使用此頁面來描述典型 ELT 工作流的數(shù)據(jù)轉換過程。
步驟 1:提取和加載
如果您的團隊遵循 ELT 工作流,其中在轉換數(shù)據(jù)之前提取原始數(shù)據(jù)源并將其加載到數(shù)據(jù)倉庫中,則需要在開始轉換工作之前實際完成這些提取和加載步驟!
提取
在提取過程中,從與您的業(yè)務相關的多個數(shù)據(jù)源中提取數(shù)據(jù)。提取的數(shù)據(jù)大部分是團隊最終希望用于分析工作的數(shù)據(jù)。數(shù)據(jù)源的一些示例可以包括:后端應用程序數(shù)據(jù)庫、營銷平臺、電子郵件和銷售 CRM 等。
這些數(shù)據(jù)通常是通過自定義腳本與應用程序編程接口(API)交互,或者依靠使用開源或軟件即服務(SaaS)ETL工具來消除一些技術提升,從而從其系統(tǒng)中提取的。
加載
在加載階段,提取的數(shù)據(jù)將加載到目標數(shù)據(jù)倉庫中?,F(xiàn)代數(shù)據(jù)倉庫的一些示例包括Snowflake,Amazon Redshift和Google BigQuery。其他數(shù)據(jù)存儲平臺的例子包括數(shù)據(jù)湖,如Databricks的數(shù)據(jù)湖。大多數(shù)從數(shù)據(jù)源中提取數(shù)據(jù)的 SaaS 應用程序也會將其加載到目標數(shù)據(jù)倉庫中。自定義或內(nèi)部提取和加載過程通常需要強大的數(shù)據(jù)工程和技術技能。
第 2 步:數(shù)據(jù)探索
原始數(shù)據(jù)進入數(shù)據(jù)倉庫后,就該了解這些數(shù)據(jù)的外觀了。在此階段,您會發(fā)現(xiàn)自己:
查看可用的 ERD(實體關系圖)和連接鍵,以了解數(shù)據(jù)如何將自身連接在一起
確定哪些列可能缺少值或具有誤導性列名稱
編寫即席查詢以對數(shù)據(jù)執(zhí)行一些簡單的分析或匯總統(tǒng)計信息 - 有多少行?主鍵是唯一的嗎?有主鍵嗎?
了解不同數(shù)據(jù)源的貨幣、時區(qū)和數(shù)據(jù)類型有何不同
如何探索原始數(shù)據(jù)沒有完美的方法;執(zhí)行數(shù)據(jù)源需要的操作。如果您對原始數(shù)據(jù)的準確性和完整性有很高的信心,那么與質疑數(shù)據(jù)的完整性相比,此步驟可能會變得不那么費力(如果您是數(shù)據(jù)從業(yè)者,這可能是您的自然傾向??)。
步驟三:數(shù)據(jù)轉換
在實際的轉換步驟中,已加載到數(shù)據(jù)倉庫中的原始數(shù)據(jù),您熟悉該數(shù)據(jù)的結構,并且您有一個關于如何處理它的大致計劃 - 它終于準備好開始您的建模過程了!當您在數(shù)據(jù)探索階段首次查看此數(shù)據(jù)時,您可能已經(jīng)注意到了一些有關它的事情......
列名稱可能清晰,也可能不清晰
表未聯(lián)接到其他表
時間戳可能采用不正確的報告時區(qū)
JSON 資源豐富,可能需要解嵌套
表可能缺少主鍵
...因此需要轉型!在實際轉換過程中,數(shù)據(jù)源中的數(shù)據(jù)通常是:
輕度轉換:正確轉換字段、統(tǒng)一時間戳字段的時區(qū)、適當重命名表和字段等。在 dbt 中,這通常發(fā)生在用于為數(shù)據(jù)創(chuàng)建干凈、統(tǒng)一的石板的暫存模型中。
大量轉換:添加業(yè)務邏輯,建立適當?shù)木唧w化,將數(shù)據(jù)連接在一起,創(chuàng)建聚合和指標等。在 dbt 中,這通常發(fā)生在中間模型和市場模型中,創(chuàng)建最終向最終用戶和商業(yè)智能 (BI) 工具公開的表。
轉換數(shù)據(jù)的常見方法包括利用 dbt 等現(xiàn)代技術使用 SQL 和 Python 編寫模塊化和版本控制的轉換。其他解決方案包括編寫自定義 SQL 和 Python 腳本,這些腳本由某種類型的調度程序自動執(zhí)行或利用存儲過程。
第 4 步:數(shù)據(jù)測試
您的數(shù)據(jù)現(xiàn)在已建模,感覺大致正確,但如何確認轉換后數(shù)據(jù)的質量?您如何確保向下游用戶公開的關鍵指標和數(shù)據(jù)值得信賴和可靠?
在此階段,應執(zhí)行符合組織標準的數(shù)據(jù)測試。這可能看起來像:
測試主鍵的唯一性和非空性
確保列值在預期范圍內(nèi)
檢查模型關系陣容
等等。
使用 dbt 等產(chǎn)品(您可以在其中定義基于代碼的測試以針對數(shù)據(jù)轉換運行),您可以創(chuàng)建一個系統(tǒng),在該系統(tǒng)中,您可以根據(jù)您建立的標準輕松且定期地測試轉換。
第 5 步:數(shù)據(jù)文檔
您的數(shù)據(jù)將轉換為有意義的業(yè)務實體,根據(jù)您的標準進行測試,并向最終用戶公開。您期望那些沒有直接參與轉型過程的人如何瀏覽它們?您正在創(chuàng)建哪些文檔來闡明轉換中的業(yè)務邏輯并描述核心指標和列?
在這個階段,轉型已經(jīng)完成,但在某種程度上,工作才剛剛開始。為了使數(shù)據(jù)轉換對最終用戶有意義且有影響力,創(chuàng)建和維護可靠的文檔非常重要。
我們建議您在轉換過程中首先記錄以下內(nèi)容:
轉換或數(shù)據(jù)模型的主要用途 - 創(chuàng)建此轉換的主要原因是什么?它為您的 BI 工具提供了哪些重要的報告支持?
在其中實現(xiàn)了業(yè)務邏輯或列名稱不明確的鍵列
聚合和指標
數(shù)據(jù)轉換過程的文檔通常應該以未參與原始過程的人員可以理解的方式編寫,而不是專注于如何為更多技術用戶進行轉換。精心編寫的轉換文檔歡迎業(yè)務用戶參與分析工作,并且是確保您的最終用戶感到舒適并有權使用團隊努力構建的數(shù)據(jù)的基本方法。
步驟 6:部署:計劃和自動化
您的數(shù)據(jù)轉換已創(chuàng)建、測試和記錄,現(xiàn)在是時候將它們推向世界了。在此階段,數(shù)據(jù)工程師、數(shù)據(jù)分析師或分析工程師會將這些轉換推向生產(chǎn)環(huán)境,即在數(shù)據(jù)倉庫的生產(chǎn)環(huán)境中運行它們的過程。這些生產(chǎn)就緒表是分析師將查詢進行分析的內(nèi)容,也是 BI 工具將讀取的內(nèi)容。
需要使用某種類型的計劃程序或業(yè)務流程協(xié)調程序,以滿足業(yè)務需求的節(jié)奏刷新或更新這些數(shù)據(jù)轉換。使用 dbt Cloud 等產(chǎn)品,您可以在協(xié)作集成開發(fā)環(huán)境 (IDE) 中創(chuàng)建數(shù)據(jù)轉換和測試,然后使用 dbt Cloud 作業(yè)計劃程序定期運行它們。通常需要更多技術提升的其他解決方案包括依賴自定義 cron 計劃程序或外部業(yè)務流程協(xié)調程序。
開始運行!
構建基礎數(shù)據(jù)轉換后,您的重點可能會轉移到優(yōu)化、治理和民主化工作上;對于所需的每個新數(shù)據(jù)源、業(yè)務問題或實體,總會有更多的數(shù)據(jù)轉換工作需要完成。因此,一個好的數(shù)據(jù)轉換過程既嚴格又靈活 - 該過程允許足夠的護欄,使分析工作有價值和有條理,有足夠的空間來有趣、具有挑戰(zhàn)性和針對您的業(yè)務進行定制。