大資料管理：Data Integration的技術、方法與最佳實務 讀書筆記二

標籤：

再來說下Data Integration開發過程，批處理Data Integration和ETL

Data Integration生命週期

1 確定項目的範圍

 2 概要分析

            生命週期的第二個部分常常會被忽略，即概要分析。因為Data Integration被視作一門技術活，而組織通常會對授權
訪問生產資料比較敏感，因此，為了開發資料介面而對當前儲存於可能的源和目標系統的資料進行分析可能是件
比較困難的事情。所以，對實際資料進行概要分析往往成為決定成敗的關鍵。幾乎每個Data Integration項目都會發現存
在於源和目標系統中的實際資料的一些問題，而這些問題往往很大程度上影響了方案的設計。例如：資料是不是
包含了沒有預料到的內容、缺少某些內容或者很差的資料品質甚至在需要某些資料的時候這些資料根本不存在。
和資料擁有者以及安全團隊之間的談判將會持續到達成一個可以接受的方案，可以據此對涉及的源和目標資料進
行概要分析。

3　包含業務知識和專家經驗

       在資料管理領域，Data Integration通常被視為一個技術型非常強的工作，從頭到尾都充斥著技術專家，而與之相反
的另外一個極端——資料治理和資料品質，幾乎完全是面向業務處理過程的。但是，高效的Data Integration也需要從業
務上去理解系統之間傳輸的資料。
很多依賴Data Integration的應用和項目（資料轉換、資料倉儲、主要資料管理）在實施階段都遭遇了延期，這不是因
為缺少技術方案，而是因為缺少業務知識以及業務人員的參與。
作為Data Integration開發中的一個核心過程，定義資料轉換必須經過對資料有深刻業務理解的人員的評審和驗證。
很多工具可以用來嘗試和推導不同系統的資料之間的關係，要麼通過欄位之間的相似性，要麼對實際的資料內容
進行分析。但終，這些推導只是一些猜測，必須經過實際使用這些資料的業務人員的驗證。
真正的挑戰在於，在4-1所示的Data Integration生命週期中，某些步驟不容易被分離出來，並分別指派給一個技
術人員或者一個業務人員。需求分析以及定義映射和轉換規則這些步驟必須由某個精通技術與業務的人員或者由
來自多個團隊的人員協作完成。例如，要定義映射和轉換規則，資料的物理實現的知識以及業務上如何實際使用
該資料的知識都是必需的。

來源資料和目標資料的技術與業務知識，對於Data Integration項目的成功至關重要。因此，在方案開發週期的每一步
都需要來自不同功能領域的資源的緊密協作，而這恰恰是Data Integration項目開發中具挑戰性的一個方面

批處理Data Integration

     絕大多數系統間的介面通常以這種方式存在，即周期性（每天、每周或者每月）地將大資料檔案從一個系統
傳輸到另外一個系統。檔案的內容是結構一致的資料記錄，發送系統和接收系統必須理解檔案的格式並達成一
致。這個處理過程就是所謂的批處理模式，因為資料被組織成“批”並周期性地發送，而不是以個體的方式即時
發送。圖5-1描述了這個標準的批處理Data Integration過程。在兩個系統之間傳送資料，即發送系統將資料轉送到目標接
收系統，這也稱為“點對點”方式。

批處理生命週期

對於成功構建資料介面來說，強烈推薦的佳實踐之一就是對源和目標系統資料結構中的實際資料進行概要
分析。對生產資料的概要分析，有助於理解目標資料應該被設計成什麼樣，以及應當從哪些源中尋找合適的屬
性。基本的概要分析包括瞭解所設計的資料結構的不同方面，而不僅僅是那些文檔記錄下來或者憑空想象的東
西，例如唯一性、密度（空和空白）、格式，以及有效資料。

ETL

Data Integration的核心功能就是從當前儲存資料的地方擷取資料之後，將其轉換為目標系統所相容的格式，後將
其匯入到目標系統中。以上這三個步驟就是所謂的抽取、轉換和載入（Extract、transform and Load，ETL）。

1 概要分析

        

    藉助概要分析工具，可以獲得關於實際來源資料的格式和內容的一些報告：無效或者空資料的百分比、不同值
的數量、高頻率出現的執行個體，以及內容的格式。有些概要分析工具可以根據欄位名或者實際的欄位內容進行關係
推斷，從而可以發現位於不同的資料存放區的資料之間的關係。
在資料概要分析過程中，經常會發現在實施ETL之前需要對來源資料進行更正和清洗。在某些情況下，可以自動
進行更正，但更常見的是，由熟悉資料的業務人員手動對資料進行更正。在來源資料結構中進行更正，還是將發現
的問題帶入目標資料存放區中，這必須由業務人員做出決策。

2抽取

為了實施ETL中的抽取部分，必須訪問當前資料所在的系統或者資料存放區。需要基本瞭解這些資料的格式和內
容，以便選擇複製哪些資料。
對資料進行抽取有兩種基本的方法：從當前系統或者源系統複製一份資料；或者由另外一個系統，即特定的
抽取系統，參與進行並抓取資料。由源系統負責資料幫浦的好處是，儲存資料的當前系統（以及系統技術服務人員）
理解資料的含義，以及包含在資料中的技術方案。但是，由源系統執行資料幫浦會導致多個潛在源的問題。通常
情況下，我們需要抽取資料的源系統是生產系統，因此，我們並不期望因為增加一些抽取資料的額外操作而對它
們的生產效能造成任何負面的影響。而且，源系統的技術服務人員可能由於太繁忙而沒有事件建立抽取任務，或者沒
有經過資料幫浦技術和工具的培訓，抑或沒有把資料幫浦看做他們的工作優先順序。
通過使用某個特定的抽取程式，從當前儲存資料的系統中抓取資料，這一方式對源系統的影響是小的。雖
然對現有的諸如資料庫管理系統或者檔案管理系統等資料存放區引擎的使用，依然會導致一些資源競爭問題。開發
資料幫浦應用的人員也會受過對資料幫浦技術和工具的培訓

        

3暫存

  資料幫浦過程的結果通常是一個“檔案”，這個檔案包含將要被複製並傳輸到另一個地方的資料，通常是另
一個伺服器或者平台。將抽取出的檔案儲存在原始伺服器平台，並將抽取的資料複製到目標伺服器平台或者任何中
間點，都可以稱為“資料暫存”。一般情況下，在原始伺服器平台和目標伺服器上都會有資料暫存點。暫存資料可
以允許對發送和接收的資料進行追蹤與審計，還可以對資料進行定時處理，讓源和目標系統之間松耦合或者非同步
處理，即兩個系統之間不需要在同一時間進行相互協作以處理資料，當然，它們可以這麼做，只要這樣做對於每
個系統的獨立處理來說是合適的，因為總是首先從源系統中開始抽取資料。
但是，相比於記憶體資料處理，從磁碟中讀和寫，也稱為I/O（輸入/輸出），總是非常慢的。在設計ETL方案的
時候，繞過資料暫存點，可以讓整個過程的處理速度快10倍以上，這是在速度至上的場合下大的不同之處，但
這麼做也丟掉了資料的追蹤審計以及系統之間的松耦合等益處。

4訪問層次

為了設計一個抽取方案，通常需要瞭解用於保護待抽取資料所採取的不同的安全訪問層次，雖然某些或者全

部的訪問層次有可能是邏輯上不可見或者虛擬，而對訪問的管理可能是自動進行的。所涉及訪問層次至少包括
組織網路和防火牆層、伺服器層（或者物理層）、作業系統層、應用程式層，以及資料結構層。
當整合需要跨越組織時，為了進入某個組織的關注域之內，就必須跨越一個安全訪問層。大多數情況下，在
邏輯上這是用防火牆實現的，用以保護群組織的網路。

5轉換

將資料進行轉換並與目標資料結構相相容的過程可以非常簡單，也可以非常困難以致需要收集額外資訊。數
據轉換過程需要很詳細的業務需求，這些業務需求通常是資料的業務所有者所開發或者認可的。而抽取和裝載過
程則幾乎全部都是面向技術的，因此，除了確保抽取正確的資料之外，幾乎很少涉及業務評審。

5.1簡易對應

5.2尋找表

5.3彙總和正常化

5.4計算

5.5載入

ETL過程的後一步就是載入，負責將資料終載入到目標資料結構中。經常會看到關於抽取、轉換、再載入
以及抽取、載入、再轉換，這兩種不同順序的處理方式哪種效率更高的一些討論。兩者之間的差別在於轉換步驟
是在原始伺服器上執行，還是在目標伺服器（或者一個單獨的伺服器）上執行。這個話題和大資料量處理過程以及
哪種方式的引擎處理速度快相關。而且，在資料幫浦過程中一個或者多個點上有沒有資料暫存也會極大地影響處
理速度。總之，ETL的後一步都是將資料裝入目標資料結構，無論是物理的還是虛擬。
將資料載入到目標資料存放區中有兩種主要的方法，即通過代碼直接將資料插入，或者利用現有的應用程式代
碼將資料插入目標資料存放區。但是，只要有可能，好使用現有的應用代碼，因為這些代碼融入了關於資料是如
何儲存在目標資料結構中的知識。雖然當前的應用代碼可能不是為了大資料量載入而開發，因此不能使用在載入
視窗中，但是，相對於編寫獨立的代碼來說，最佳化載入過程並使用現有的代碼依然是比較好的選擇

大資料管理：Data Integration的技術、方法與最佳實務 讀書筆記二