Thinking in BigDate（六）大資料技術核心之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、StreamCompute：twitter的storm和yahoo的S4

大資料與雲端運算：

1、雲端運算的模式是業務模式，本質是資料處理技術

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

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

大資料平台架構：

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

       IaaS:：基礎設施即服務。基於 Internet 的服務（如儲存和資料庫）。

       PaaS：平台即服務。提供了使用者可以訪問的完整或部分的應用程式。

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

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

提綱：

資料擷取：ETL

資料存放區：關聯式資料庫、NoSql、SQL等

資料管理：（基礎架構支援）雲端儲存、Distributed File System

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

 

本文章的目的，不是為了讓大家對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過程，會細細討論。

CopyrightBUAA