關於ETL

大多數據倉庫的數據架構能夠歸納爲：

數據源-->ODS(操做型數據存儲)-->DW-->DM(data mart)

ETL貫穿其各個環節。

1、數據抽取：

      能夠理解爲是把源數據的數據抽取到ODS或者DW中。

      1. 源數據類型：

          關係型數據庫，如Oracle,Mysql,Sqlserver等;

          文本文件，如用戶瀏覽網站產生的日誌文件，業務系統以文件形式提供的數據等；

          其餘外部數據，如手工錄入的數據等；

      2. 抽取的頻率：

          大可能是天天抽取一次，也能夠根據業務需求每小時甚至每分鐘抽取，固然得考慮源數據庫系統可否承受；

      3. 抽取策略：

          我的感受這是數據抽取中最重要的部分，可分爲全量抽取和增量抽取。

          全量抽取適用於那些數據量比較小，而且不容易判斷其數據發生改變的諸如關係表，維度表，配置表等；

          增量抽取，通常是因爲數據量大，不可能採用全量抽取，或者爲了節省抽取時間而採用的抽取策略；

              如何判斷增量，這是增量抽取中最難的部分，通常包括如下幾種狀況：

              a) 經過時間標識字段抽取增量；源數據表中有明確的能夠標識當天數據的字段的流水錶，

                  如createtime，updatetime等；

              b) 根據上次抽取結束時候記錄的自增加ID來抽取增量；無createtime,但有自增加類型字段的流水錶，

                  如自增加的ID，抽取完以後記錄下最大的ID，

                  下次抽取可根據上次記錄的ID來抽取；

              c)  經過分析數據庫日誌獲取增量數據，無時間標識字段，無自增加ID的關係型數據庫中的表；

              d)  經過與前一天數據的Hash比較，比較出發生變化的數據，這種策略比較複雜，在這裏描述一下，

                    好比一張會員表，它的主鍵是memberID,而會員的狀態是有可能天天都更新的，

                    咱們在第一次抽取以後，生成一張備用表A，包含兩個字段，第一個是memberID,

                    第二個是除了memberID以外其餘全部字段拼接起來，再作個Hash生成的字段，

                    在下一次抽取的時候，將源表一樣的處理,生成表B,將B和A左關聯，Hash字段不相等的

                    爲發生變化的記錄，另外還有一部分新增的記錄，

                    根據這兩部分記錄的memberID去源表中抽取對應的記錄；

              e) 由源系統主動推送增量數據；例如訂單表，交易表，

                  有些業務系統在設計的時候，當一個訂單狀態發生變化的時候，是去源表中作update，

                  而咱們在數據倉庫中須要把一個訂單的全部狀態都記錄下來，

                  這時候就須要在源系統上作文章，數據庫觸發器通常不可取。我能想到的方法是在業務系統上作些變更，

                  當訂單狀態發生變化時候，記一張流水錶，能夠是寫進數據庫，也能夠是記錄日誌文件。

              固然確定還有其餘抽取策略，至於採起哪一種策略，須要考慮源數據系統狀況，

              抽取過來的數據在數據倉庫中的存儲和處理邏輯，抽取的時間窗口等等因素。

2、數據清洗：

      顧名思義，就是把不須要的，和不符合規範的數據進行處理。數據清洗最好放在抽取的環節進行，

      這樣能夠節約後續的計算和存儲成本；

      當源數據爲數據庫時候，其餘抽取數據的SQL中就能夠進行不少數據清洗的工做了。

      數據清洗主要包括如下幾個方面：

      1. 空值處理；根據業務須要，能夠將空值替換爲特定的值或者直接過濾掉；

      2. 驗證數據正確性；主要是把不符合業務含義的數據作一處理，好比，把一個表示數量的字段中的字符串

          替換爲0，把一個日期字段的非日期字符串過濾掉等等；

      3. 規範數據格式；好比，把全部的日期都格式化成YYYY-MM-DD的格式等；

      4. 數據轉碼；把一個源數據中用編碼表示的字段，經過關聯編碼表，轉換成表明其真實意義的值等等；

      5. 數據標準，統一；好比在源數據中表示男女的方式有不少種，在抽取的時候，直接根據模型中定義的值作轉化，

          統一表示男女；

      6. 其餘業務規則定義的數據清洗。。。

3、數據轉換和加載：

      不少人理解的ETL是在通過前兩個部分以後，加載到數據倉庫的數據庫中就完事了。

      數據轉換和加載不只僅是在源數據-->ODS這一步，ODS-->DW, DW-->DM包含更爲重要和複雜的ETL過程。

      1. 什麼是ODS？

          ODS（Operational Data Store）是數據倉庫體系結構中的一個可選部分，

          ODS具有數據倉庫的部分特徵和OLTP系統的部分特徵，

          它是「面向主題的、集成的、當前或接近當前的、 不斷變化的」數據。---摘自百度百科

          其實大多時候，ODS只是充當了一個數據臨時存儲，數據緩衝的角色。通常來講，

          數據由源數據加載到ODS以後，會保留一段時間，當後面的數據處理邏輯有問題，須要從新計算的時候，

          能夠直接從ODS這一步獲取，而不用再從源數據再抽取一次，減小對源系統的壓力。

          另外，ODS還會直接給DM或者前端報表提供數據，好比一些維表或者不須要通過計算和處理的數據；

          還有，ODS會完成一些其餘事情，好比，存儲一些明細數據以備不時之需等等；

      2. 數據轉換(刷新)：

          數據轉換，更多的人把它叫作數據刷新，就是用ODS中的增量或者全量數據來刷新DW中的表。

          DW中的表基本都是按照事先設計好的模型建立的，如事實表，維度表，彙總表等，

          天天都須要把新的數據更新到這些表中。

          更新這些表的過程(程序)都是剛開始的時候開發好的，天天只須要傳一些參數,如日期，來運行這些程序便可。

      3. 數據加載：

          我的認爲，每insert數據到一張表，均可以稱爲數據加載，至因而delete+insert、truncate+insert、

          仍是merge，這個是由業務規則決定的，這些操做也都是嵌入到數據抽取、轉換的程序中的。