準確地來說，在大數據裏很多時候是ELTL，但是我們仍然保留歷史的稱呼用ETL來描述從抽數到提供應用之間的所有數據處理步驟。
ETL的第一步總是避不開從業務源系統抽取數據到落地層(Staging)。實踐中，大部分時候大廠都用ODS來命名，歪果仁通常稱爲STG，這裏只是叫法不同，作用是一樣的——一次讀取以緩衝對源系統數據的訪問。
EL工具市面上比較常用的是sqoop和dataX，也有通過binlog消費日誌再轉成增量文件的，還有用flink做實時數倉落地層的同步方案。但不論用什麼方式，最終落地層的表結構基本上和業務源系統的表結構保持一致（偶爾也會有不一致的情況），而數據上看可能存在兩種情況：全量和增量。
全量同步的方式比較簡單粗暴，搭配使用sqoop或者datax的同步方式。在同步數據線程數有限且對產出時間有要求的情況下，適合量級上限在大約幾千萬行左右的表。因爲數據量多意味着抽取時間的線性增長，一般超過一小時都無法全量同步的情況下，會考慮採用增量同步的方式。
同步過程中的源數據變化是全量同步需要引起注意的地方。如果在導入數據的時候，業務系統有DML，是有引起數據不一致的潛在可能的。這與DML的操作是否事務級別無關，與幻讀也無關。假設業務有個事務操作是要標記一條記錄爲delete並新增一條記錄。但是導入數據可能是個漫長的過程，在事務發生之前就讀入了該條要標記爲delete的數據，但是在事務提交之後纔讀到新增的記錄，此時就會出現兩條記錄同時存在的情況。sqoop搭配-Doraoop.import.consistent.read=true的時候對Oracle的SCN(system change number)可以做到讀取同個位點。
增量同步沒有數據不一致的潛在風險，但它的一個先決條件是能夠完整獲取增量部分。對於只有追加沒有更新和刪除操作的日誌型數據，只需要一個created_time就可以進行增量同步。稍微複雜點，對於沒有物理刪除的數據庫設計，只需要有created_time和updated_time夠了。對於同時還有物理刪除操作的數據，需要通過類似MySQL的binlog或者Oracle的GoldenGate獲取完整的操作記錄，再用這份數據對前一份數據進行合併（新增、更新和刪除）以獲得一份當天的數據。
存在HBase裏的數據往往都是超大表，全量同步需要很長時間。對於HBase的增量同步機制，可以開啓一個設置TTL的增量表，在此增量表的基礎上，構建一個Hive的外部表映射到該HBase增量表。最後再對舊數據和增量進行合併。但是這種機制要求HBase沒有物理刪除的操作。因爲物理刪除的記錄無法通過被同步到TTL表裏而表現出來。
用flink同步落地層是一個很有價值的方案，flink的exactly-once使得通過實時方式同步有了數據一致性的保障。姑且不論flink能不能滿足完整的實時數倉，單從簡單的落地層實時同步能縮小數據倉庫在整體產出時間方面的提高，它就是值得嘗試的。在ETL出現意外的時候，通過縮短數據同步而壓縮整個鏈路的運行時間，能給數據的產出時間提供有力保障。