etl數據倉庫做什麼任務

A. ETL的特色功能

ETL過程在很大程度上受企業對源數據的理解程度的影響，也就是說從業務的角度看數據集成非常重要。一個優秀的ETL設計應該具有如下功能： 合理的業務模型設計對ETL至關重要。數據倉庫是企業唯一、真實、可靠的綜合數據平台。數據倉庫的設計建模一般都依照三範式、星型模型、雪花模型，無論哪種設計思想，都應該最大化地涵蓋關鍵業務數據，把運營環境中雜亂無序的數據結構統一成為合理的、關聯的、分析型的新結構，而ETL則會依照模型的定義去提取數據源，進行轉換、清洗，並最終載入到目標數據倉庫中。
模型的重要之處在於對數據做標准化定義，實現統一的編碼、統一的分類和組織。標准化定義的內容包括：標准代碼統一、業務術語統一。ETL依照模型進行初始載入、增量載入、緩慢增長維、慢速變化維、事實表載入等數據集成，並根據業務需求制定相應的載入策略、刷新策略、匯總策略、維護策略。 對業務數據本身及其運行環境的描述與定義的數據，稱之為元數據（metadata）。元數據是描述數據的數據。從某種意義上說，業務數據主要用於支持業務系統應用的數據，而元數據則是企業信息門戶、客戶關系管理、數據倉庫、決策支持和B2B等新型應用所不可或缺的內容。
元數據的典型表現為對象的描述，即對資料庫、表、列、列屬性（類型、格式、約束等）以及主鍵/外部鍵關聯等等的描述。特別是現行應用的異構性與分布性越來越普遍的情況下，統一的元數據就愈發重要了。「信息孤島」曾經是很多企業對其應用現狀的一種抱怨和概括，而合理的元數據則會有效地描繪出信息的關聯性。
而元數據對於ETL的集中表現為：定義數據源的位置及數據源的屬性、確定從源數據到目標數據的對應規則、確定相關的業務邏輯、在數據實際載入前的其他必要的准備工作，等等，它一般貫穿整個數據倉庫項目，而ETL的所有過程必須最大化地參照元數據，這樣才能快速實現ETL。

B. etl是什麼

對於做過 BI 開發的朋友，ETL 並不陌生，只要涉及到數據源的數據抽取、數據的計算和處理過程的開發，都是 ETL，ETL 就這三個階段，Extraction 抽取，Transformation 轉換，Loading 載入。

從不同數據源抽取數據 EXTRACTION ，按照一定的數據處理規則對數據進行加工和格式轉換 TRASFORMATION，最後處理完成的輸出到目標數據表中也有可能是文件等等，這個就是 LOADING。

再通俗一點講，ETL 的過程就跟大家日常做菜一樣，需要到菜市場的各個攤位買好菜，把菜買回來要摘一下，洗一洗，切一切最後下鍋把菜炒好端到飯桌上。菜市場的各個攤位就是數據源，做好的菜就是最終的輸出結果，中間的所有過程像摘菜、洗菜、切菜、做菜就是轉換。

在開發的時候，大部分時候會通過 ETL 工具去實現，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微軟 SQL SERVER 裡面的 SSIS 等等，在結合基本的 SQL 來實現整個 ETL 過程。

也有的是自己通過程序開發，然後控制一些數據處理腳本跑批，基本上就是程序加 SQL 實現。

哪種方式更好，也是需要看使用場景和開發人員對那種方式使用的更加得心應手。我看大部分軟體程序開發人員出身的，碰到數據類項目會比較喜歡用程序控制跑批，這是程序思維的自然延續。純 BI 開發人員大部分自然就選擇成熟的 ETL 工具來開發，當然也有一上來就寫程序腳本的，這類 BI 開發人員的師傅基本上是程序人員轉過來的。

用程序的好處就是適配性強，可擴展性強，可以集成或拆解到到任何的程序處理過程中，有的時候使用程序開發效率更高。難就難在對維護人員有一定的技術要求，經驗轉移和可復制性不夠。

用 ETL 工具的好處，第一是整個 ETL 的開發過程可視化了，特別是在數據處理流程的分層設計中可以很清晰的管理。第二是鏈接到不同數據源的時候，各種數據源、資料庫的鏈接協議已經內置了，直接配置就可以，不需要再去寫程序去實現。第三是各種轉換控制項基本上拖拉拽就可以使用，起到簡化的代替一部分 SQL 的開發，不需要寫代碼去實現。第四是可以非常靈活的設計各種 ETL 調度規則，高度配置化，這個也不需要寫代碼實現。

所以在大多數通用的項目中，在項目上使用 ETL 標准組件開發會比較多一些。

ETL 從邏輯上一般可以分為兩層，控制流和數據流，這也是很多 ETL 工具設計的理念，不同的 ETL 工具可能叫法不同。

控制流就是控制每一個數據流與數據流處理的先後流程，一個控制流可以包含多個數據流。比如在數據倉庫開發過程中，第一層的處理是ODS層或者Staging 層的開發，第二層是 DIMENSION維度層的開發，後面幾層就是DW 事實層、DM數據集市層的開發。通過ETL的調度管理就可以讓這幾層串聯起來形成一個完整的數據處理流程。

數據流就是具體的從源數據到目標數據表的數據轉換過程，所以也有 ETL 工具把數據流叫做轉換。在數據流的開發設計過程中主要就是三個環節，目標數據表的鏈接，這兩個直接通過 ETL 控制項配置就可以了。中間轉換的環節，這個時候就可能有很多的選擇了，調 SQL 語句、存儲過程，或者還是使用 ETL 控制項來實現。

有的項目上習慣使用 ETL 控制項來實現數據流中的轉換，也有的項目要求不使用標準的轉換組件使用存儲過程來調用。也有的是因為數據倉庫本身這個資料庫不支持存儲過程就只能通過標準的SQL來實現。

我們通常講的BI數據架構師其實指的就是ETL的架構設計，這是整個BI項目中非常核心的一層技術實現，數據處理、數據清洗和建模都是在ETL中去實現。一個好的ETL架構設計可以同時支撐上百個包就是控制流，每一個控制流下可能又有上百個數據流的處理過程。之前寫過一篇技術文章，大家可以搜索下關鍵字 BIWORK ETL 應該在網上還能找到到這篇文章。這種框架設計不僅僅是ETL框架架構上的設計，還有很深的ETL項目管理和規范性控制器思想，包括後期的運維，基於BI的BI分析，ETL的性能調優都會在這些框架中得到體現。因為大的BI項目可能同時需要幾十人來開發ETL，框架的頂層設計就很重要。

C. ETL工程師是做什麼的

ETL工程師又叫資料庫工程師。

ETL工程師的主要工作內容有：從事系統編程、資料庫編程與設計。ETL是數據倉庫中的非常重要的一環。它是承前啟後的必要的一步。相對於關系資料庫，數據倉庫技術沒有嚴格的數學理論基礎，它更面向實際工程應用。

所以從工程應用的角度來考慮，按著物理數據模型的要求載入數據並對數據進行一些系列處理，處理過程與經驗直接相關，同時這部分的工作直接關系數據倉庫中數據的質量，從而影響到聯機分析處理和數據挖掘的結果的質量。

職業前景

從業務角度講，隨著數據應用的日益豐富，不同平台、系統的相互大批量數據交互成常態，僅僅滿足於採集數據已經不適應業務需要，還需要能夠為數據的目的端落地提供支撐，ETL工程師需要一個端到端的更適應業務需要的數據交換系統。

從技術角度講，ETL做一定的擴展可以升級為兼具交換能力，兩者有傳承，可以實現平滑過渡，但交換卻要考慮用另一個工具實現，同時未來大數據平台組件將異常豐富，相互之間的數據交換將是常態，必要要有更高級別的交換工具滿足這些需求。

D. ETL是什麼意思

ETL是指獲取原始大數據流，然後對其進行解析，並產生可用輸出數據集的過程。

從數據源中提取（E）數據，然後經過各種聚合、函數、組合等轉換（T），使其變為可用數據。最終，數據會被載入（L）到對它進行具體分析的環境中，這就是ETL流程。

全寫是Extract-Transform-Load。

1、E：Extract數據抽取

2、T：Transform轉換

3、L：Load裝載

(4)etl數據倉庫做什麼任務擴展閱讀：

作用

ETL是構建數據倉庫的重要一環，用戶從數據源抽取出所需的數據，經過數據清洗,最終按照預先定義好的數據倉庫模型，將數據載入到數據倉庫中去。

以電信為例，A系統按照統計代碼管理數據，B系統按照賬目數字管理，C系統按照語音ID管理，當ETL需要對這三個系統進行集成以獲得對客戶的全面視角時，這一過程需要復雜的匹配規則、名稱/地址正常化與標准化，而ETL在處理過程中會定義一個關鍵數據標准，並在此基礎上，制定相應的數據介面標准。

E. ETL究竟是什麼呢

ETL 其實是在數據倉庫的這領域，就單字面意思而已 就是一個對數據抽取、轉換和載入的過程。用文字表示原理：源數據——轉換——目標數據
如果不用ETL 則需要用程序去實現，如果是規模的的系統，代碼實現是很繁重的，而且容易出錯，不容易維護。所以就採用了ETL 這樣可以保證數據的完整性和可拓展性

F. 深入探討數據倉庫建模與ETL的實踐技巧[5]

ETL是數據抽取(Extract) 轉換(Transform) 載入(Load )的簡寫 它是指 將OLTP系統中的數據抽取出來 並將不同數據源的數據進行轉換和整合 得出一致性的數據 然後載入到數據倉庫中 例如 下圖就向我們展示了ETL的數據轉換效果 (圖七 pic bmp)

那麼 在這一轉換過程中 我們就完成了對數據格式的更正 對數據欄位的合並 以及新增指標的計算三項操作 類似地 我們也可以根據其他需求 完善數據倉庫中的數據

簡而言之 通過ETL 我們可以基於源系統中的數據來生成數據倉庫 ETL為我們搭建了OLTP系統和OLAP系統之間的橋梁

四 項目實踐技巧

(一) 准備區的運用

在構建數據倉庫時 如果數據源位於一台伺服器上 數據倉庫在另一台伺服器端 考慮到數據源Server端訪問頻繁 並且數據量大 需要不斷更新 所以可以建立准備區資料庫(圖八 pic bmp) 先將數據抽取到准備區中 然後基於准備區中的數據進行處理 這樣處理的好處是防止了在原OLTP系統中頻繁訪問 進行數據運算或排序等操作

例如我們可以按照天將數據抽取到准備區中 基於數據准備區 我們將進行數據的轉換 整合 將不同數據源的數據進行一致性處理 數據准備區中將存在原始抽取表 轉換中間表和臨時表以及ETL日誌表等

(二) 時間戳的運用

時間維度對於某一事實主題來說十分重要 因為不同的時間有不同的統計數據信息 那麼按照時間記錄的信息將發揮很重要的作用 在ETL中 時間戳有其特殊的作用 在上面提到的緩慢變化維度中 我們可以使用時間戳標識維度成員;在記錄資料庫和數據倉庫的操作時 我們也將使用時間戳標識信息 例如 在進行數據抽取時 我們將按照時間戳對OLTP系統中的數據進行抽取 比如在午夜 取前一天的數據 我們將按照OLTP系統中的時間戳取GETDATE到GETDATE減一天 這樣得到前一天數據

G. 萬字詳解ETL和數倉建模

ETL是數據抽取（Extract）、轉換（Transform）、載入（Load ）的簡寫，它是將OLTP系統中的數據經過抽取，並將不同數據源的數據進行轉換、整合，得出一致性的數據，然後載入到數據倉庫中。簡而言之ETL是完成從 OLTP系統到OLAP系統的過程

數據倉庫（Data Warehouse DW）是基於OLTP系統的數據源，為了便於多維分析和 多角度展現將其數據按特定的模式進行存儲而建立的關系型資料庫，它不同於多維資料庫，數據倉庫中的數據是細節的，集成的，數據倉庫是面向主題的，是以 OLAP系統為分析目的。它包括星型架構與雪花型架構，其中星型架構中間為事實表，四周為維度表， 類似星星；雪花型架構中間為事實表，兩邊的維度表可以再有其關聯子表，而在星型中只允許一張表作為維度表與事實表關聯，雪花型一維度可以有多張表，而星型 不可以。考慮到效率時，星型聚合快，效率高，不過雪花型結構明確，便於與OLTP系統交互。在實際項目中，我們將綜合運用星型架構與雪花型架構。

即 確定數據分析或前端展現的某一方面的分析主題，例如我們分析某年某月某一地區的啤酒銷售情況，就是一個主題。主題要體現某一方面的各分析角度（維度）和統 計數值型數據（量度），確定主題時要綜合考慮，一個主題在數據倉庫中即為一個數據集市，數據集市體現了某一方面的信息，多個數據集市構成了數據倉庫。

在 確定了主題以後，我們將考慮要分析的技術指標，諸如年銷售額此類，一般為數值型數據，或者將該數據匯總，或者將該數據取次數，獨立次數或取最大最小值 等，這樣的數據稱之為量度。量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵性能指標（KPI）等的計算。

在 確定了量度之後我們要考慮到該量度的匯總情況和不同維度下量度的聚合情況，考慮到量度的聚合程度不同，我們將採用「最小粒度原則」，即將量度的粒度設置 到最小，例如我們將按照時間對銷售額進行匯總，目前的數據最小記錄到天，即資料庫中記錄了每天的交易額，那麼我們不能在ETL時將數據進行按月或年匯總， 需要保持到天，以便於後續對天進行分析。而且我們不必擔心數據量和數據沒有提前匯總帶來的問題，因為在後續的建立CUBE時已經將數據提前匯總了。

維 度是要分析的各個角度，例如我們希望按照時間，或者按照地區，或者按照產品進行分析，那麼這里的時間、地區、產品就是相應的維度，基於不同的維度我們可 以看到各量度的匯總情況，我們可以基於所有的維度進行交叉分析。這里我們首先要確定維度的層次（Hierarchy）和級別（Level）（圖 四：pic4.jpg），維度的層次是指該維度的所有級別，包括各級別的屬性；維度的級別是指該維度下的成員，例如當建立地區維度時我們將地區維度作為一 個級別，層次為省、市、縣三層，考慮到維度表要包含盡量多的信息，所以建立維度時要符合「矮胖原則」，即維度表要盡量寬，盡量包含所有的描述性信息，而不 是統計性的數據信息。

還有一種常見的情況，就是父子型維度，該維度一般用於非葉子節點含有成員等情況，例如公司員工 的維度，在統計員工的工資時，部 門主管的工資不能等於下屬成員工資的簡單相加，必須對該主管的工資單獨統計，然後該主管部門的工資等於下屬員工工資加部門主管的工資，那麼在建立員工維度 時，我們需要將員工維度建立成父子型維度，這樣在統計時，主管的工資會自動加上，避免了都是葉子節點才有數據的情況。

另外，在建立維度表時要充 分使用代理鍵，代理鍵是數值型的ID號碼，好處是代理鍵唯一標識了每一維度成員信息，便於區分，更重要的是在聚合時由於數值型匹 配，JOIN效率高，便於聚合，而且代理鍵對緩慢變化維度有更重要的意義，它起到了標識 歷史 數據與新數據的作用，在原數據主鍵相同的情況下，代理鍵起到了 對新數據與 歷史 數據非常重要的標識作用。

有時我們也會遇到維度緩慢變化的情況，比如增加了新的產品，或者產品的ID號碼修改了，或者產品增加了一個新的屬性，此時某一維度的成員會隨著新的數據的加入而增加新的維度成員，這樣我們要考慮到緩慢變化維度的處理，對於緩慢變化維度，有三種情況：

在確定好事實數據和維度後，我們將考慮載入事實表。

在公司的大量數據堆積如山時，我們想看看裡面究竟是什麼，結果發現裡面是一筆筆生產記錄，一筆筆交易記錄… 那麼這些記錄是我們將要建立的事實表的原始數據，即關於某一主題的事實記錄表。

我 們的做法是將原始表與維度表進行關聯，生成事實表（圖六：pic6.jpg）。注意在關聯時有為空的數據時（數據源臟），需要使用外連接，連接後我們將 各維度的代理鍵取出放於事實表中，事實表除了各維度代理鍵外，還有各量度數據，這將來自原始表，事實表中將存在維度代理鍵和各量度，而不應該存在描述性信 息，即符合「瘦高原則」，即要求事實表數據條數盡量多（粒度最小），而描述性信息盡量少。

如果考慮到擴展，可以將事實表加一唯一標識列，以為了以後擴展將該事實作為雪花型維度，不過不需要時一般建議不用這樣做。

事 實數據表是數據倉庫的核心，需要精心維護，在JOIN後將得到事實數據表，一般記錄條數都比較大，我們需要為其設置復合主鍵和索引，以為了數據的完整性和 基於數據倉庫的查詢性能優化，事實數據表與維度表一起放於數據倉庫中，如果前端需要連接數據倉庫進行查詢，我們還需要建立一些相關的中間匯總表或物化視圖，以方便查詢。

在構建數據倉庫時，如果數據源位於一伺服器上，數據倉庫在另一 伺服器端，考慮到數據源Server端訪問頻繁，並且數據量大，需要不斷更新，所以可以建立准備區資料庫（圖七：pic7.jpg）。先將數據抽取到准備 區中，然後基於准備區中的數據進行處理，這樣處理的好處是防止了在原OLTP系統中中頻繁訪問，進行數據運算或排序等操作。例如我們可以按照天將數據抽取 到准備區中，基於數據准備區，我們將進行數據的轉換，整合，將不同數據源的數據進行一致性處理。數據准備區中將存在原始抽取表，一些轉換中間表和臨時表以 及ETL日誌表等。

時間維度對於某一事實主題來說十分重要，因為不同的時間有不同的統計數據信息，那麼按照時間記錄 的信息將發揮很重要的作用。在ETL中，時間戳有其特殊的 作用，在上面提到的緩慢變化維度中，我們可以使用時間戳標識維度成員；在記錄資料庫和數據倉庫的操作時，我們也將使用時間戳標識信息，例如在進行數據抽取 時，我們將按照時間戳對OLTP系統中的數據進行抽取，比如在午夜0：00取前一天的數據，我們將按照OLTP系統中的時間戳取GETDATE到 GETDATE減一天，這樣得到前一天數據。

在對數據進行處理時，難免會發生數據處理錯誤，產生出錯信息，那麼我們 如何獲得出錯信息並及時修正呢? 方法是我們使用一張或多張Log日誌表，將出錯信息記錄下來，在日誌表中我們將記錄每次抽取的條數，處理成功的條數，處理失敗的條數，處理失敗的數據，處 理時間等等，這樣當數據發生錯誤時，我們很容易發現問題所在，然後對出錯的數據進行修正或重新處理。

在對數據倉庫進行 增量更新時必須使用調度（圖八：pic8.jpg），即對事實數據表進行增量更新處理，在使用調度前要考慮到事實數據量，需要多長時間更 新一次，比如希望按天進行查看，那麼我們最好按天進行抽取，如果數據量不大，可以按照月或半年對數據進行更新，如果有緩慢變化維度情況，調度時需要考慮到 維度表更新情況，在更新事實數據表之前要先更新維度表。

調度是數據倉庫的關鍵環節，要考慮縝密，在ETL的流程搭建好後，要定期對其運行，所以 調度是執行ETL流程的關鍵步驟，每一次調度除了寫入Log日誌表 的數據處理信息外，還要使用發送Email或報警信息等，這樣也方便的技術人員對ETL流程的把握，增強了安全性和數據處理的准確性。

ETL構建數據倉庫需要簡單的五步，掌握了這五步的方法我們將構建一個強大的數據倉庫，不過每一步都有很深的需要研究與挖掘，尤其在實際項目中，我們要綜合考慮，例如如果數據源的臟數據很多，在搭建數據倉庫之前我們首先要進行數據清洗，以剔除掉不需要的信息和臟數據。

總之，ETL是數據倉庫的核心，掌握了ETL構建數據倉庫的五步法，就掌握了搭建數據倉庫的根本方法。不過，我們不能教條，基於不同的項目，我們還將要進行 具體分析，如父子型維度和緩慢變化維度的運用等。在數據倉庫構建中，ETL關繫到整個項目的數據質量，所以馬虎不得，必須將其擺到重要位置，將ETL這一 大廈根基築牢。

如果ETL和SQL來說，肯定是SQL效率高的多。但是雙方各有優勢，先說ETL，ETL主要面向的是建立數據倉庫來使用的。ETL更偏向數據清洗，多數據源數據整合，獲取增量，轉換載入到數據倉庫所使用的工具。比如我有兩個數據源，一個是資料庫的表，另外一個是excel數據，而我需要合並這兩個數據，通常這種東西在SQL語句中比較難實現。但是ETL卻有很多現成的組件和驅動，幾個組件就搞定了。還有比如跨伺服器，並且伺服器之間不能建立連接的數據源，比如我們公司系統分為一期和二期，存放的資料庫是不同的，數據結構也不相同，資料庫之間也不能建立連接，這種情況下，ETL就顯得尤為重要和突出。通過固定的抽取，轉換，載入到數據倉庫中，即可很容易實現。

那麼SQL呢？SQL事實上只是固定的腳本語言，但是執行效率高，速度快。不過靈活性不高，很難跨伺服器整合數據。所以SQL更適合在固定資料庫中執行大范圍的查詢和數據更改，由於腳本語言可以隨便編寫，所以在固定資料庫中能夠實現的功能就相當強大，不像ETL中功能只能受組件限制，組件有什麼功能，才能實現什麼功能。

所以具體我們在什麼時候使用ETL和SQL就很明顯了，當我們需要多數據源整合建立數據倉庫，並進行數據分析的時候，我們使用ETL。如果是固定單一資料庫的數據層次處理，我們就使用SQL。當然，ETL也是離不開SQL的。

主要有三大主流工具，分別是Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation.還有其他開源工具，如PDI(Kettle)等。

DW系統以事實發生數據為基礎，自產數據較少。

一個企業往往包含多個業務系統，均可能成為DW數據源。

業務系統數據質量良莠不齊，必須學會去偽存真。

業務系統數據紛繁復雜，要整合進數據模型。

源數據之間關系也紛繁復雜，源數據在加工進DW系統時，有些必須遵照一定的先後次序關系;

流水事件表：此類源表用於記錄交易等動作的發生，在源系統中會新增、大部分不會修改和刪除，少量表存在刪除情況。如定期存款登記簿;

常規狀態表：此類源表用於記錄數據信息的狀態。在源系統中會新增、修改，也存在刪除的情況。如客戶信息表;

代碼參數表：此類源表用於記錄源系統中使用到的數據代碼和參數;

數據文件大多數以1天為固定的周期從源系統載入到數據倉庫。數據文件包含增量，全量以及待刪除的增量。

增量數據文件：數據文件的內容為數據表的增量信息，包含表內新增及修改的記錄。

全量數據文件：數據文件的內容為數據表的全量信息，包含表內的所有數據。

帶刪除的增量：數據文件的內容為數據表的增量信息，包含表內新增、修改及刪除的記錄，通常刪除的記錄以欄位DEL_IND='D'標識該記錄。

可劃分為： 歷史 拉鏈演算法、追加演算法(事件表)、Upsert演算法(主表)及全刪全加演算法(參數表);

歷史 拉鏈：根據業務分析要求，對數據變化都要記錄，需要基於日期的連續 歷史 軌跡;

追加(事件表)：根據業務分析要求，對數據變化都要記錄，不需要基於日期的連續 歷史 軌跡;

Upsert(主表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據有影響;

全刪全加演算法(參數表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據無影響;

所謂拉鏈，就是記錄 歷史 ，記錄一個事務從開始，一直到當前狀態的所有變化信息(參數新增開始結束日期);

一般用於事件表，事件之間相對獨立，不存在對 歷史 信息進行更新;

是update和insert組合體，一般用於對 歷史 信息變化不需要進行跟蹤保留、只需其最新狀態且數據量有一定規模的表，如客戶資料表;

一般用於數據量不大的參數表，把 歷史 數據全部刪除，然後重新全量載入;

歷史 拉鏈，Upsert,Append,全刪全加;載入性能：全刪全加，Append，Upsert， 歷史 拉鏈;

APPEND演算法，常規拉鏈演算法，全量帶刪除拉鏈演算法;

APPEND演算法，MERGE演算法，常規拉鏈演算法，基於增量數據的刪除拉鏈演算法，基於全量數據的刪除拉鏈演算法，經濟型常規拉鏈演算法，經濟型基於增量數據的刪除拉鏈演算法，經濟型基於全量數據的刪除拉鏈演算法，PK_NOT_IN_APPEND演算法，源日期欄位自拉鏈演算法;

此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日最新數據取過來直接附加到目標表即可，此類表在近源模型層的欄位與技術緩沖層、源系統表基本上完全一致，不會額外增加物理化處理欄位，使用時也與源系統表的查詢方式相同;

此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新的增量數據作為開鏈數據插入到目標表即可。

此類表再近源模型層比技術緩沖層、源系統的相應表額外增加兩個物理化處理欄位START_DT(開始日期)和END_DT(結束日期)，使用時需要先選定視覺日期，通過START_DT和END_DT去卡視覺日期，即START_DT'視覺日期';

此演算法通常用於有刪除操作的常規狀態類表，並且要求全量的數據文件，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增，修改，刪除，每天將當日末最新全量數據取過來外，分別找出真正的增量數據(新增，修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據中真正的增量及刪除數據作為開鏈數據插入到目標表即可，注意刪除記錄的刪除標志DEL_IND會設置為『D』;

此類表在近源模型層比技術緩沖層，源系統的相應表額外增加三個物理化處理欄位START_DT(開始日期)，ENT_DT(結束日期)，DEL_IND(刪除標准)。使用方式分兩類：一時一般查詢使用，此時需要先選定視角日期，通過START_DT和END_DT去卡視角日期，即START_DT『視角日期』，同時加上條件DEL_IND 'D';另一種是下載或獲取當日增量數據，此時就是需要START_DT'視角日期' 一個條件即可，不需要加DEL_IND 'D'的條件。

此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日的最新數據取過來直接附加到目標表即可;

通常建一張名為VT_NEW_編號的臨時表，用於將各組當日最新數據轉換加到VT_NEW_編號後，再一次附加到最終目標表;

此演算法通常用於無刪除操作的常規狀態表，一般是無需保留 歷史 而只保留當前最新狀態的表，適合這類演算法的源表在源系統中會新增，修改，但不刪除，所以需獲取當日末最新數據(增量或全量均可)，用於MERGE IN或UPSERT目標表;為了效率及識別真正增量的要求，通常先識別出真正的增量數據(新增及修改數據)，然後再用這些真正的增量數據向目標表進行MERGE INTO操作;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再用VT_INC_編號對最終目標表進行MERGE INTO或UPSERT。

此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據作為開鏈數據插入到目標表即可;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再將最終目標表的開鏈數據中的PK出現在VT_INT_編號中進行關鏈處理，然後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可。

此演算法通常用於有刪除操作的常規狀態表，並且要求刪除數據是以DEL_IND='D'刪除增量的形式提供;適合這類演算法的源表再源系統中會新增、修改、刪除，除每天獲取當日末最新數據(增量或全量均可)外，還要獲取當日刪除的數據，根據找出的真正增量數據(新增和修改)以及刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將增量(不含刪除數據)作為開鏈數據插入到目標表中即可;

通常建三張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據 (不含刪除數據)轉換載入到VT_NEW_編號;第二張表名為VT_INC_編號，用VT_NEW_編號與目標表中的昨日的數據進行對比後找出真正的增量數據放入VT_INC_編號;第三張表名為VT_DEL_編號，將刪除增量數據轉換載入到VT_DEL_編號;最後再將最終目標表的開鏈數據中PK出現在VT_INC_編號或VT_DEL_編號中的進行關鏈處理，最後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可;

此演算法通常用於有刪除操作的常規狀態表，並且要求提供全量數據，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增、修改、每天將當日末的最新全量數據取過來外，分別找出真正的增量數據(新增、修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效記錄)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將最新數據中真正的增量數據(不含刪除數據)作為開鏈數據插入到目標表即可;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新全量數據轉換到VT_NEW_編號;另一張表名為VT_INC_編號,將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增、修改)和刪除增量數據放入VT_INC_編號，注意將其中的刪除增量數據的END_DT置以最小日期(借用);最後再將最終目標表的開鏈數據中PK出現再VT_INC_編號或VT_DEL_編號中的進行關鏈處理，然後將VT_INC_編號中所有的END_DT不等於最小日期數據(非刪除數據)作為開鏈數據插入最終目標表即可;

此演算法基本等同與常規拉演算法，只是在最後一步只將屬性非空即非0的記錄才作為開鏈數據插入目標表;

此演算法基本等同於基於增量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;

此演算法基本等同於基於全量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;

此演算法是對每一組只將PK在當前VT_NEW_編號表中未出現的數據再插入VT_NEW_編號表，最後再將PK未出現在目標表中的數據插入目標表，以保證只進那些PK未進過的數據;

此演算法是源表中有日期欄位標識當前記錄的生效日期，本演算法通過對同主鍵記錄按這個生效日期排序後，一次首尾相連行形成一條自然拉鏈的演算法

H. etl工程師是做什麼的工作內容是什麼

etl工程師是從事系統編程、資料庫編程與設計，要掌握各種常用的編程語言的專業技術人員。也叫資料庫工程師。x0dx0a工作內容：x0dx0a見崗位職責：x0dx0a 1. 海量數據的ETL開發，抽取成各種數據需求。x0dx0a 2. 參與數據倉庫架構的設計及開發 。x0dx0a3. 參與數據倉庫ETL流程優化及解決ETL相關技術問題。x0dx0a4、熟悉主流資料庫技術，如oracle、Sql server、PostgeSQL等。x0dx0a 4、精通etl架構，有一定的etl開發經驗，了解日常作業的部署和調度。x0dx0a 5、會數據etl開發工具，如Datastage,Congos,Kettle等。

I. etl是什麼

ETL全稱Extract & Transformation & Loading，即數據抽取，轉換，載入。是建立數據倉庫的一個必備過程

J. 數據倉庫ETL

當然是做數據倉庫ETL有前途，毫無可比性，數據倉庫工資開的不低哦，你見過java有多少開到月薪10000以上的？

java起點低，找個培訓班培訓幾個月就可以開發了

數據倉庫沒幾年積累，搞不出什麼成果

我本人就是搞數據倉庫和數據挖掘的，要知道以後的大數據的天下，數據倉庫的建立需要的知識量很大很大，你的路還很遠

淘寶阿里騰訊和 華為都在做數據倉庫和數據挖掘，都有對應的商務智能項目。

給你傳一個我當初學習的書籍，非常的不錯，我也希望自己多一個同行，一起討論