“企業(yè)信息集成（EII）：實用方式”于2005年發(fā)布，描述了一套集成不同數(shù)據(jù)源的方法論，利用了當時的先進技術，如面向服務架構（SOA）、Web Services、XML、資源描述架構（RDF）、基于XML的元數(shù)據(jù)格式以及數(shù)據(jù)提取、轉換和加載（ETL）。EII能夠基本為關系型數(shù)據(jù)元素提供統(tǒng)一視角，但在性能效率上缺乏能夠替代數(shù)據(jù)倉庫和多維數(shù)據(jù)庫的能力。五年之后技術已經(jīng)得到了顯著提升，不僅在于對于分散數(shù)據(jù)的操作，還有簡化了單一容器下不同數(shù)據(jù)的整合，以及對數(shù)據(jù)深入挖掘的能力。
轉變了數(shù)據(jù)管理方式的技術正是虛擬化。低成本存儲、云計算、NoSQL數(shù)據(jù)庫以及Hadoop。當我們提起虛擬化時，已經(jīng)遠遠超出為一臺物理機器提供一套軟件實例這一概念。時至今日，我們可以虛擬化服務器、存儲以及網(wǎng)絡。所有這些虛擬化意味著我們不再被這些物理條件所限制，能夠迅速構建物理環(huán)境以支持我們特定時刻的特定需求。當面對Gb、Tb、Pb等級數(shù)據(jù)量的處理需求時，我們基本能擺脫結構化的數(shù)據(jù)倉庫。我們不在需要僅僅為了發(fā)掘業(yè)務的某一方面而建立一個特殊的環(huán)境了。
低成本存儲在業(yè)務的數(shù)據(jù)存儲方面節(jié)省了開支。高昂的存儲成本會使得企業(yè)尋找在限定規(guī)模的數(shù)據(jù)之上進行關鍵業(yè)務分析的方案，這樣使得如何選擇最重要的數(shù)據(jù)變得十分關鍵，而且還限制了系統(tǒng)能夠處理的數(shù)據(jù)的質量。
負面影響便是業(yè)務最終可能面臨很少的選擇，因為沒有足夠的歷史數(shù)據(jù)提供從而識別一個有效關鍵模式。或者因為高昂的投入使得業(yè)務被停止，而使用常規(guī)慣例來識別模式。
云計算為那些需要通過海量數(shù)據(jù)源在合理時間范圍內(nèi)產(chǎn)生結果的需求提供了一個可用的方式。海量數(shù)據(jù)處理需要兩點：彈性存儲，CPU。高速網(wǎng)絡很有幫助，但是待會我們會看到在發(fā)掘軟件在處理海量數(shù)據(jù)時，它并非是系統(tǒng)的瓶頸。彈性存儲意味著企業(yè)不會在期望操作的數(shù)據(jù)規(guī)模或類型上受到限制，降低了使用數(shù)據(jù)倉庫無法獲取最佳結果的風險。更多的CPU使得結果能夠在期望的時間范圍內(nèi)更快的被交付。
NoSQL提供了海量數(shù)據(jù)的支持，但與傳統(tǒng)的關系型數(shù)據(jù)庫沒有關聯(lián)。而且大部分NoSQL數(shù)據(jù)庫是開源的，無須支付購買證書等費用。NoSQL對于表結構有著驚人的靈活性，無須隨著系統(tǒng)的改進而不斷修改完善定義。NoSQL可以支持不同數(shù)據(jù)源的合并查看，從而成為EII之后另一個備選方案，這或許是NoSQL最重要的方面了。
NoSQL內(nèi)置了數(shù)據(jù)冗余與分布式數(shù)據(jù)存儲機制。海量數(shù)據(jù)的最大問題之一就是磁盤讀寫，NoSQL通過將數(shù)據(jù)分布至一系列節(jié)點來緩解這個問題。當一個查詢請求發(fā)出時，這些節(jié)點能夠并行查詢自身節(jié)點，而不是僅僅依靠一塊磁盤，一個磁盤陣列或一條網(wǎng)絡連接等，數(shù)據(jù)查詢能夠在節(jié)省了讀寫開支之后變得更加迅速。
最終，我們來討論Hadoop，集合了上述所有技術力量與一身的用于檢測和分析數(shù)據(jù)的框架。有些人可能認為Hadoop是一項NoSQL技術，實際上Hadoop是一個分布組件的java框架，用于分解“吃大象”（此處也雙關Hadoop是以創(chuàng)立者的兒子給自己的一個大象玩具起的名字）的工作——每次一口。
Hadoop自身實際上與待處理數(shù)據(jù)是各自獨立的。它將大型查詢?nèi)蝿辗纸鉃樾〉牟⑿胁樵內(nèi)蝿眨缓笫占Y果，并整合出答案返回給用戶。Hadoop相對于NoSQL來說是一個并行查詢框架，通過云計算驅動節(jié)點，運行在低成本存儲及虛擬化技術之上。
Kicking的知識回顧
當EII第一次作為最佳實踐出現(xiàn)于2003-2004年，關鍵要素就是無需再移動數(shù)據(jù)了。當時大部分的數(shù)據(jù)中心仍然運行于低速網(wǎng)絡中，有限的空間用于復制數(shù)據(jù)。之后，EII成為了當時可用技術和問題域中最優(yōu)秀的解決方案。EII的某些方面的優(yōu)秀即使在海量數(shù)據(jù)中也是很顯著的。
EII的優(yōu)點之一就是將處理過程轉移到數(shù)據(jù)所在地。海量數(shù)據(jù)方案的關鍵架構要素之一就是將處理過程轉移到數(shù)據(jù)所在地，而不是轉移數(shù)據(jù)。EII中的一個重要原則就是使用數(shù)據(jù)歸屬地的查詢功能。這項實踐就是構建靠近數(shù)據(jù)源網(wǎng)絡的Web Service，能夠建立起通用查詢接口，但只針對本地數(shù)據(jù)庫進行查詢。我們通過開放的基于Web的接口解決了數(shù)據(jù)的專有格式的問題，從而使得多個數(shù)據(jù)子集能夠迅速的整合并以統(tǒng)一模式展示。
有了低成本存儲和10G網(wǎng)絡之后，我們就不必那么擔心數(shù)據(jù)冗余與數(shù)據(jù)遷移，但還是有其他問題存在的，數(shù)據(jù)倉庫無法確保數(shù)據(jù)的原始性便是其中之一。在EII中，我們將從原始數(shù)據(jù)源獲取數(shù)據(jù)視為“黃金準則”，這樣就能夠保證信息未被修改過，且是準確的。
Big Data要求數(shù)據(jù)必須轉移到新的物理位置，這樣可信任度又成為了問題。EII的那些獲取基線數(shù)據(jù)的最佳實踐仍然是相關而且重要的。實際上，那些為EII設計開發(fā)的Web Services接口最終在Big Data的啟用中扮演主要角色。
當然，討論數(shù)據(jù)管理不能不涉及到安全問題。EII在安全領域中還是超過了Big Data。技術上來說，Big Data在數(shù)據(jù)集成方面更加高效與敏捷，但是大部分缺少了固有的安全性，因為在設計上會加大處理的難度。所以，可能要由源系統(tǒng)來擔任起數(shù)據(jù)訪問安全方面的責任。因為EII直接在源系統(tǒng)中查詢數(shù)據(jù)，所以必須要求有適當?shù)氖跈啵駝t查詢就將失敗。
上述關于安全討論描述的是內(nèi)在的安全控制情況。將訪問權限控制列表集成進數(shù)據(jù)庫是非常合理的，這將確保安全能夠作為查詢的一部分進行維護。然后，一旦能夠直接查詢NoSQL數(shù)據(jù)源，就意味著能夠自由的訪問你所有的數(shù)據(jù)。
總結
引用老的Virginia Slims的廣告中的臺詞：“我們已經(jīng)歷很長的路途了，寶貝兒！”文中討論到的技術的發(fā)展已經(jīng)對21世紀第二個10年中的的數(shù)據(jù)解決方案產(chǎn)生了巨大的影響。商業(yè)化與小型化掃除了一些思想體系上的障礙，使得架構師能夠專注于問題本身，而不是尋找一些實用及可實現(xiàn)的問題解決方案。構建10000個節(jié)點的處理引擎，能夠在數(shù)秒內(nèi)處理Pb級別的數(shù)據(jù)量，卻只消耗每小時幾便士，這就是數(shù)據(jù)處理的美好前景。
有了這些新工具，我們就要重新考慮如何推進數(shù)據(jù)管理。為何數(shù)據(jù)無法被很好地被維護整合，并且需要花費數(shù)萬美元。數(shù)據(jù)管理幾乎是每個大中型企業(yè)的心病。數(shù)據(jù)管理曾經(jīng)在存儲、管理、訪問、整合以及查詢上花費巨大，但是今后不再會是這樣了。
關于作者
JP Morgenthal 是在IT策略與云計算方面的世界級專家之一。他在企業(yè)復雜問題域的解決方案實施上有著25年的經(jīng)驗。JP Morgenthal以其在技術方面的深度和廣度，有利的支持他在企業(yè)問題域中的敏感度。他在集成、軟件開發(fā)和云計算是一位讓人尊敬的作者，同時也是InfoQ在引領云計算方面的編輯，并且參與了“云計算：評估風險”項目。
原文鏈接：http://www.infoq.com/articles/DataIntegrationFromEIItoBigData