大數據技術核心之ETL

      前幾篇文章都是根據自己所見所知，在前人的基礎上加以整合，對大數據概念有了初步的了解。接下來的四篇文章，拋開大數據的概念與基本知識，進入核心。我們從：數據采集、數據存儲、數據管理、數據分析與挖掘，四個方面討論大數據在實際應用中涉及的技術與知識點。

核心技術

架構挑戰：

1、對現有數據庫管理技術的挑戰。

2、經典數據庫技術并沒有考慮數據的多類別（variety）、SQL（結構化數據查詢語言），在設計的一開始是沒有考慮到非結構化數據的存儲問題。

3、實時性技術的挑戰：一般而言，傳統數據倉庫系統，BI應用，對處理時間的要求并不高。因此這類應用通過建模，運行1-2天獲得結果依然沒什么問題。但實時處理的要求，是區別大數據應用和傳統數據倉庫技術、BI技術的關鍵差別之一。

4、網絡架構、數據中心、運維的挑戰：隨著每天創建的數據量爆炸性的增長，就數據保存來說，我們能改進的技術卻不大，而數據丟失的可能性卻不斷增加。如此龐大的數據量存儲就是首先面臨的非常嚴峻的問題，硬件的更新速速將是大數據發展的基石，但效果確實不甚理想。

分析技術：

1、數據處理：自然語言處理技術（NLP）

2、統計和分析：A/B test、top N排行榜、地域占比、文本情感分析

3、數據挖掘：關聯規則分析、分類、聚類

4、模型預測：預測模型、機器學習、建模仿真

存儲：

1、結構化數據：海量數據的查詢、統計、更新等操作效率低

2、非結構化數據：圖片、視頻、word、PDF、PPT等文件存儲、不利于檢索，查詢和存儲

3、半結構化數據：轉換為結構化數據存儲、按照非結構化存儲

解決方案：

1、存儲：HDFS、HBASE、Hive、MongoDB等

2、并行計算：MapReduce技術

3、流計算：twitter的storm和yahoo的S4

大數據與云計算：

1、云計算的模式是業務模式，本質是數據處理技術

2、數據是資產，云為數據資產提供存儲、訪問和計算

3、當前云計算更偏重海量存儲和計算，以及提供的云服務，運行云應用。但是缺乏盤活數據資產的能力，挖掘價值性信息和預測性分析，為國家、企業、個人提供決策方案和服務，是大數據核心議題，也是云計算的最終方向。

大數據平臺架構：

      我想這幅架構圖，對大數據處理的人來說，應該不是很陌生。

      IaaS:：基礎設施即服務?；?Internet 的服務（如存儲和數據庫）。

      PaaS：平臺即服務。提供了用戶可以訪問的完整或部分的應用程序。

      SaaS：軟件即服務。則提供了完整的可直接使用的應用程序，比如通過 Internet管理企業資源。

 

      這里也不多涉及這方面的概念，在接下來的幾篇文章中，會對下圖中相關的部分（主要介紹PaaS模塊中涉及的部分）以及上面提及的技術挑戰和相關技術的介紹。

提綱：

數據采集：ETL

數據存儲：關系數據庫、NoSql、SQL等

數據管理：（基礎架構支持）云存儲、分布式文件系統

數據分析與挖掘：（結果展現）數據的可視化

本文章的目的，不是為了讓大家對ETL的詳細過程有徹底的了解。只需要知道，這是數據處理的第一步，一切的開端。

大數據技術之數據采集ETL：

      這里不過多的說數據采集的過程，可以簡單的理解：有數據庫就會有數據。

      這里我們更關注數據的ETL過程，而ETL前期的過程，只需要了解其基本范疇就OK。

      在數據挖掘的范疇了，數據清洗的前期過程，可簡單的認為就是ETL的過程。ETL的發展過程伴隨著數據挖掘至今，其相關技術也已非常成熟。這里我們也不過多的探討ETL過程，日后如有涉及，在細分。

概念：

      ETL（extract提取、transform轉換、load加載）。ETL負責將分散的、異構數據源中的數據如關系數據、平面數據文件等抽取到臨時中間層后，進行清洗、轉換、集成，最后加載到數據倉庫或數據集市中，成為聯機分析處理、數據挖掘提供決策支持的數據。

        ETL是構建數據倉庫的重要的一環，用戶從數據源抽取所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中。其定義域來源也不下于十幾年，技術發展也應相當成熟?？烧а垡豢?，似乎并沒有什么技術可言，也沒有什么深奧之處，但在實際的項目中，卻常常在這個環節上耗費太多的人力，而在后期的維護上，往往更費腦筋。導致上面的原因，往往是在項目初期沒有正確的估計ETL的工作，沒有認真的考慮其與工具支撐有很大的關系。

      在做ETL產品選型的時候，任然必不可少的要面臨四點（成本、人員經驗、案例和技術支持）來考量。在做ETL的過程中，也隨之產生于一些ETL工具，如Datastage、Powercenter、ETLAutomation。而在實際ETL工具應用的對比上，對元數據的支持、對數據質量的支持、維護的方便性、定制開發功能的支持等方面是我們選擇的切入點。一個項目，從數據源到最終目標表，多則達上百個ETL過程，少則也十幾個。這些過程之間的依賴關系、出錯控制以及恢復的流程處理，都是工具需要重點考慮。這里不再多討論，具體應用再具體說明。

過程：

      在整個數據倉庫的構建中，ETL工作占整個工作的50%-70%。下面有人給出團隊之間的ETL過程是如何實現的。在面臨耗費絕大時間的分析過程中，要求第一點就是：團隊協作性要好。ETL包含E，T，L還有日志的控制，數據模型，原數據驗證，數據質量等等方面。

      例如我們要整合一個企業亞太區的數據，但是每個國家都有自己的數據源，有的是ERP，有的是Access，而且數據庫都不一樣，好要考慮網絡的性能問題， 如果直接用ODBC去連接兩地的數據源，這樣的做法很顯然是不合理的，因為網絡不好，經常連接，很容易數據庫鏈接不能釋放導致死機。如果我們在各地區的服 務器放置一個數據導出為access或者flat file的程序，這樣文件就比較方便的通過FTP的方式進行傳輸。

下面我們指出上述案例需要的幾項工作： 
      1、有人寫一個通用的數據導出工具，可以用java，可以用腳本，或其他的工具，總之要通用，可以通過不同的腳本文件來控制，使各地區的不同數據庫導出的文件格式是一樣的。而且還可以實現并行操作。
      2、有人寫FTP的程序，可以用bat，可以用ETL工具，可以用其他的方式，總之要準確，而且方便調用和控制。 
      3、有人設計數據模型，包括在1之后導出的結構，還有ODS和DWH中的表結構。
      4、有人寫SP，包括ETL中需要用到的SP還有日常維護系統的SP，比如檢查數據質量之類的。
      5、有人分析原數據，包括表結構，數據質量，空值還有業務邏輯。
      6、有人負責開發流程，包括實現各種功能，還有日志的記錄等等。 
      7、有人測試真正好的ETL，都是團隊來完成的，一個人的力量是有限的。

      其實上述的7步，再給我們強調的是什么：一個人，很難成事。團隊至上。

這里我們簡述ETL的過程：主要從E、T、L和異常處理簡單的說明，這里不再細說明。如果用到，我想大家一定會有更深的調研。

1、 數據清洗：

      ·數據補缺：對空數據、缺失數據進行數據補缺操作，無法處理的做標記。

      ·數據替換：對無效數據進行數據的替換。

      ·格式規范化：將源數據抽取的數據格式轉換成為便于進入倉庫處理的目標數據格式。

      ·主外鍵約束：通過建立主外鍵約束，對非法數據進行數據替換或導出到錯誤文件重新處理。

2、 數據轉換

      ·數據合并：多用表關聯實現，大小表關聯用lookup，大大表相交用join（每個字段家索引，保證關聯查詢的效率）

      ·數據拆分：按一定規則進行數據拆分

      ·行列互換、排序/修改序號、去除重復記錄

      ·數據驗證：loolup、sum、count

實現方式：

      ·在ETL引擎中進行（SQL無法實現的）

      ·在數據庫中進行（SQL可以實現的）

3、 數據加載

方式：

      ·時間戳方式：在業務表中統一添加字段作為時間戳，當OLAP系統更新修改業務數據時，同時修改時間戳字段值。

      ·日志表方式：在OLAP系統中添加日志表，業務數據發生變化時，更新維護日志表內容。

      · 全表對比方式：抽取所有源數據，在更新目標表之前先根據主鍵和字段進行數據比對，有更新的進行update或insert。

      ·全表刪除插入方式：刪除目標表數據，將源數據全部插入。

異常處理

    在ETL的過程中，必不可少的要面臨數據異常的問題，處理辦法：

    1、將錯誤信息單獨輸出，繼續執行ETL，錯誤數據修改后再單獨加載。中斷ETL，修改后重新執行ETL。原則：最大限度接收數據。

    2、對于網絡中斷等外部原因造成的異常，設定嘗試次數或嘗試時間，超數或超時后，由外部人員手工干預。

      3、 例如源數據結構改變、接口改變等異常狀況，應進行同步后，在裝載數據。

      在這里涉及到ETL中，我們只要有一個清晰的認識，它不是想象中的簡單一蹴而就，在實際的過程，你可以會遇到各種各樣的問題，甚至是部門之間溝通的問題。在給它定義到占據整個數據挖掘或分析的過程中50%-70%是不足為過的。

      后期項目如有涉及ETL過程，會細細討論。