數據與智能 本公衆号關注大數據與人工智能技術。由一批具備多年實戰經驗的技術極客參與運營管理，持續輸出大數據、數據分析、推薦系統、機器學習、人工智能等方向的原創文章，每周至少輸出10篇精品原創。同時，我們會關注和分享大數據與人工智能行業動态。歡迎關注。

ETL ，是三個英文單詞Extract-Transform-Load的首字母縮寫，用來描述将數據從來源端經過萃取（extract）、轉化（transform）、加載（load）至目的端的過程。ETL通常用于數據倉庫的構建過程，它的主要作用是将企業中分散、非完全結構化、标準不統一的各種數據，整合到一起，形成企業級統一數據倉庫，為企業的分析決策提供有質量保證的數據源。

02

ETL的一般過程

從ETL的字面來看，就知道它主要包含三大階段，分别是數據抽取、數據轉換、數據加載。接下來我們将依次對這三個階段進行詳細的介紹。

這個階段的主要目标是彙總多種數據源，為下一步的轉換做準備。在動手做抽取之前，你需要充分了解你的各種數據源，理解并利用他們的特性，結合實際分析業務需求，選擇合适的抽取方式。下面我們針對常見的幾種數據源，談下他們常用的抽取方式。

這種數據源的特性是數據高度結構化、數據量不算特别大、數據更新相對頻繁、數據質量較高、數據獲取比較方便。根據分析業務需求的不同，一般分為離線抽取和實時抽取。

離線抽取，應用場景是對短時間内的更新不敏感，隻關心一段時間後的最終狀态，一般是固定周期定時抽取。抽取方法，可以采用快照的方式，對整個表做全表快照；或者是采用基于時間字段的增量抽取，但是需要對這個字段的更新場景非常了解。

實時抽取，通常的應用場景是對數據的最新狀态非常敏感，當有新數據插入或者舊數據更新時，需要及時抽取。抽取方法有很多，其中常用的一種是基于消費數據庫binlog的方式，如阿裡開源的canal。

這種數據源的特性是各種日志數據混雜在一起（需要過濾出自己需要的）、數據格式比較多樣（格式可能不統一）、數據量相對較大。對于這類數據，通常的方法就是過濾抽取。抽取方法，可以使用flume監控文件目錄，或者使用FileBeat實時監控文件内容變化。

在上一篇文章裡，我們講到了客戶端用戶操作日志的數據收集方案，其實也算是一種抽取方式。這種數據源的特點是數據量非常大、數據源非常分散、數據質量參差不齊、數據結構化程度高。針對這種數據，通常的抽取方法，就是專門設計一個數據收集系統來處理收集數據的問題，不清楚的同學可以看下上篇文章《大數據分析工程師入門15-數據收集》。

實際工作中，我們可能還會有其他數據源，如NoSQL數據庫、人工整理的數據（例如Excel）、消息隊列中的數據、系統運行數據、時序數據庫等。這些都需要根據具體數據源的特性和具體分析業務的需要，來設計抽取方式，篇幅有限，這裡就不一一舉例了。

這個階段是ETL的核心環節，也是最複雜的環節。它的主要目标是将抽取到的各種數據，進行數據的清洗、格式的轉換、缺失值填補、剔除重複等操作，最終得到一份格式統一、高度結構化、數據質量高、兼容性好的數據，為後續的分析決策提供可靠的數據支持。下面對其主要過程做下簡單說明。

這個環節的主要作用是清洗掉髒數據，以免混入正常數據中，造成數據質量下降，引導有偏差的錯誤決策。通常的做法有，md5校驗、關鍵字段檢查、格式類型一緻性檢查、無效性檢查等。

md5校驗通常用于通過公網傳輸的數據，為防止數據被篡改，需要比對md5值來保證數據的安全性，沒能通過md5檢驗比對的數據将被視為髒數據過濾掉。

關鍵字段檢查，是指在一條數據記錄中，非常關鍵的字段，如果其值不合法，或者類型不對，将被視為非法數據。比如，識别用戶行為的字段，其值不在規定取值範圍内時，将無法識别具體是做了什麼操作，将被視為非法數據清洗掉。

格式類型一緻性檢查，就是檢查一條數據記錄的整體格式或者重要字段的類型是否符合規範，如果不符合，同樣也是沒辦法處理，隻能作為髒數據處理掉。例如，不合法的日期格式。

無效性檢查，通常是比較嚴格的過濾方法，它主要目的是為了保證數據的高可靠性，通常是事先規定好數據的可信範圍，不滿足的将被視為不可信的無效數據。

這個環節的主要作用是對數據格式做統一化規範化處理，方便後續的分析作業能夠更好地使用數據。一般根據源數據格式和目标格式的不同，會有不同的實現。一般包含記錄格式轉換和字段格式轉換。記錄格式轉換，就是最終将一條記錄轉換成什麼格式，例如轉成json格式或csv格式。字段格式轉換是對字段值進行格式的統一化處理，如将長整型時間戳全部轉化為人類可讀的日期格式。

這個環節是針對數據中缺失的空位進行填充，以保證數據類型的一緻性或完整性。例如，對于一個數量類的整數型字段，當其值缺失時，可以考慮填充0。這裡要注意的是缺失值填充要相對謹慎一些才行，因為這個過程相當于是在修改原始數據，一定要确保填充的值對後續的分析不會造成誤導性的影響。

這個環節的主要作用是防止數據重複上傳，造成誤判。例如，一個用戶播放一個視頻，産生一條播放數據，如果由于某種原因，數據重複上傳了3次。在服務端看來這個用戶就看了3次這個視頻，可能就會誤以為這個用戶非常喜歡這個節目。因此，剔除重複數據，是非常有必要的，也是保證數據質量的前提。

這個環節通常的作用是對數據增加一些追蹤信息或者是生成一些必要的标識字段。有些字段是和具體的業務強相關的，也有一些通用的字段。比如，源數據裡隻有長整型時間戳字段，可以增加可讀性比較高的日期時間字段，還可以增加數據來源字段便于追蹤數據血緣關系。

有些公司根據自己公司的具體業務，可能會增加數據抽樣、數據聚合、指标合并等環節，這和公司的分析訴求是強相關的，這裡就不展開講了。

這部分的主要目标是把數據加載至目的地，比如數據倉庫中。通常的做法是，将處理好的數據寫成特定格式（如parquet、csv等）的文件，然後再把文件挂載到指定的表分區上。也有些表的數據量很小，不會采用分區表，而是直接生成最終的數據表。

可能有些同學聽說過ELT的概念，這裡我們也簡單介紹下，并說下它和ETL的區别。

ELT，從字面上看，就是把L（加載）放在了T（轉換）前面，也就是說處理過程是萃取（extract）、加載（load）、轉化（transform）。實際上，稱為ELTL更合适，先把數據抽取出來，之後加載到目的地，然後再進行數據轉化，最後再把轉化後的結果加載到新的數據表中。

它和ETL的最大區别就是，處理上的順序略有不同。ELT這樣做的好處，是為了将數據先轉移到另一個體系中，之後就可以利用新體系下的一些框架完成對數據的高效處理（數據轉換）。

筆者公司就是采用的這種方式，我們會把收集到的用戶數據，首先以原始文件的形式加載至數據倉庫的原始層，之後再調用spark處理框架對數據做各種處理轉換，最後再把轉換後的結果加載到數據倉庫的新的表中。在這個過程中，就是先把數據轉移到分布式存儲（HDFS）上，然後才能利用分布式的數據處理框架（spark）完成高效的數據轉換操作。

03

ETL的運行過程

前面幾個部分我們介紹了ETL的概念，以及它的各個環節。本小節我們來說下，ETL的實際運行過程。ETL不是一個一勞永逸的過程，因為數據會源源不斷地來，因此ETL需要定時或實時地對新來的數據進行數據。這裡我們就簡單介紹下用戶行為數據的離線ETL的大緻運行過程。

第一步，需要客戶端SDK和數據收集服務的配合，不斷地抽取客戶端上發生的用戶行為，并以文件的形式寫入磁盤。

第二步，會有一個定時調度程序，負責将收集到的大量行為日志文件，切割并上傳至HDFS上，并在指定位置寫入上傳完成的标記文件。

第三步，另一個定時調度程序會啟動一個數據處理作業，去讀取上傳完成标記，待上傳完成後，讀入原始數據，開始進行數據轉換處理，并将處理好的結果寫入HDFS特定的位置。

第四步，通過特定腳本或者SDK将第三步産生的文件加載到對應的數據的特定分區上，至此一次完整的過程就完成了。

有些同學可能會有疑問，為什麼第二步和第三步不放在一個工作流中調度？這是因為第二步是發生在數據收集服務端集群上的，是一個多台并行的調度，而第三步是調度起一個spark處理程序，是提交一個作業到yarn集群上，兩個過程是無法組成一個工作流的。

ETL程序的開發是一個非常複雜的過程，筆者公司也是經過了很久的叠代才趨于穩定的。以下羅列其中一些注意事項，希望對相關開發同學有所幫助：

1. 數據清洗一定要慎重。因為清洗操作稍有不慎，就可能把正常的數據給過濾掉了。因此，比較好的實踐方式是，在處理過程中增加計數機制，即記錄整個批次的原始數據量，以及每個特定邏輯清洗掉了多少數據，這樣不僅能做到心中有數，同時也可以将這些計數結果監控起來，如果某個數值異常升高，可能是業務數據發生了變化或某個邏輯出了問題。
2. 缺失值填充要結合具體業務。前面提到了關于缺失值的填充，這裡強調一點是要結合具體業務和分析需求來對缺失值進行填充，如果無法明确該如何填充，其實存Null值比填充更好。因為錯誤的填充缺失值，可能會破壞原有的數據。
3. 設計好數據組織規範。是否有一個比較好的數據組織規範，決定了數據加載環節實現的難易程度。建議大家要從後向前設計，先設計好存儲規範，然後再進行前面的數據轉換設計。
4. 統一實時ETL和離線ETL。有些業務場景會出現一份數據既用于實時業務，也用于離線分析。那麼，值得注意的是，最好離線和實時的ETL處理邏輯要能夠統一，避免由此導緻出現不一緻的統計口徑。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!