數(shù)據(jù)中心相關(guān)技術(shù)應(yīng)用和科學(xué)應(yīng)用

1、目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成傳統(tǒng)的數(shù)據(jù)倉庫的架構(gòu)數(shù)據(jù)源抽取、轉(zhuǎn)換、加載業(yè)務(wù)數(shù)據(jù)集市企業(yè)數(shù)據(jù)倉庫ETL元數(shù)據(jù)前端分析展現(xiàn)工具查詢工具、應(yīng)用新一代數(shù)據(jù)中心定義企業(yè)數(shù)據(jù)中心是指建立在數(shù)據(jù)倉庫與數(shù)據(jù)倉庫之上的決策分析應(yīng)用，應(yīng)包括數(shù)據(jù)源、數(shù)據(jù)ETL、ODS數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)集市、商務(wù)智能應(yīng)用、數(shù)據(jù)管理等功能。數(shù)據(jù)中心應(yīng)該具備常見數(shù)據(jù)的處理與管理能力，具備對結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化等數(shù)據(jù)的處理能力，同時支持RDB、MPP、NoSQL，同時具備數(shù)據(jù)的通用管理能

2、力，以數(shù)據(jù)為中心進(jìn)行平臺建設(shè)。數(shù)據(jù)中心數(shù)據(jù)平臺在接口層要豐富又簡單，可以提供各種應(yīng)用所需接口，最大程度匹配已有接口，對應(yīng)用改動需求力求最低。一個合理的數(shù)據(jù)平臺，不能等同于Hadoop或者其他某項單一技術(shù)建設(shè)；整體數(shù)據(jù)中心的建設(shè)，從數(shù)據(jù)采集層、存儲層、應(yīng)用層都有完整的解決方案，同時具備平臺運(yùn)維管理、接口管理、數(shù)據(jù)管理功能；數(shù)據(jù)中心數(shù)據(jù)管理能力至少應(yīng)包含：1.元數(shù)據(jù)管理，2.數(shù)據(jù)質(zhì)量管理，3.數(shù)據(jù)平安管理，4.數(shù)據(jù)可視化管理，5.數(shù)據(jù)生命周期管理。數(shù)據(jù)平臺必須針對數(shù)據(jù)提供完整方案，同時兼顧應(yīng)用接口、其他平臺接入，系統(tǒng)管理、系統(tǒng)調(diào)度等功能。任何一種單一技術(shù)都難以適應(yīng)數(shù)據(jù)中心數(shù)據(jù)采集、存儲、處理和對外

3、效勞的需求，多種技術(shù)并存才是開展趨勢。RDB、MPP、Hadoop采集處理層數(shù)據(jù)抽取/加載/檢查ETL調(diào)度數(shù)據(jù)交互、轉(zhuǎn)換數(shù)據(jù)映射數(shù)據(jù)層數(shù)據(jù)存儲數(shù)據(jù)聚合服務(wù)數(shù)據(jù)處理服務(wù)數(shù)據(jù)查詢服務(wù)事件通知服務(wù)信息子層KPI報表統(tǒng)一視圖知識庫接口層服務(wù)管理資料類數(shù)據(jù)服務(wù)指標(biāo)類數(shù)據(jù)服務(wù)配置類數(shù)據(jù)服務(wù)清單累數(shù)據(jù)服務(wù)日志類數(shù)據(jù)服務(wù)OPEN API數(shù)據(jù)管理功能數(shù)據(jù)生命周期管理數(shù)據(jù)可視化管理數(shù)據(jù)質(zhì)量管理采集層數(shù)據(jù)質(zhì)量管理數(shù)據(jù)質(zhì)量規(guī)則、知識庫數(shù)據(jù)質(zhì)量稽核指標(biāo)運(yùn)維數(shù)據(jù)安全管理4A認(rèn)證隱私信息保護(hù)權(quán)限管控、審計追蹤元數(shù)據(jù)管理元數(shù)據(jù)獲取管理元數(shù)據(jù)存儲與模型管理元數(shù)據(jù)分析、展現(xiàn)、服務(wù)技術(shù)、業(yè)務(wù)元數(shù)據(jù)管理ODW-RDBODW-MPP分

4、布式文件系統(tǒng)分布式關(guān)系數(shù)據(jù)庫分布式計算數(shù)據(jù)分發(fā)同步處理用戶管理權(quán)限管理備份與恢復(fù)日志管理設(shè)備監(jiān)控指標(biāo)資源池指標(biāo)數(shù)據(jù)庫指標(biāo)分布式系統(tǒng)指標(biāo)指標(biāo)匯總存儲管理資源池管理設(shè)備管理作業(yè)調(diào)度管理事件自動化規(guī)則配置執(zhí)行引擎性能預(yù)警調(diào)度異?？刂票毕蚪涌诠芾頂?shù)據(jù)采集接口管理數(shù)據(jù)共享配置通用接口配置平臺管理功能數(shù)據(jù)服務(wù)功能綜合分析系統(tǒng)A+ABIS應(yīng)用無線網(wǎng)優(yōu)綜合監(jiān)控系統(tǒng)信令監(jiān)測系統(tǒng)日志上層應(yīng)用其他應(yīng)用新一代數(shù)據(jù)中心功能視圖數(shù)據(jù)中心整體功能視圖可以分為數(shù)據(jù)效勞功能模塊、平臺管理功能模塊，數(shù)據(jù)管理功能模塊，共同數(shù)據(jù)中心的應(yīng)用。采集處理層數(shù)據(jù)抽取/加載/檢查ETL調(diào)度數(shù)據(jù)交互、轉(zhuǎn)換數(shù)據(jù)映射數(shù)據(jù)層數(shù)據(jù)存儲數(shù)據(jù)聚合效勞數(shù)據(jù)處

5、理效勞數(shù)據(jù)查詢效勞數(shù)據(jù)集市、OLAP接口層效勞管理資料類數(shù)據(jù)效勞指標(biāo)類數(shù)據(jù)效勞配置類數(shù)據(jù)效勞清單累數(shù)據(jù)效勞日志類數(shù)據(jù)效勞OPEN API數(shù)據(jù)管理功能數(shù)據(jù)生命周期管理數(shù)據(jù)可視化管理數(shù)據(jù)質(zhì)量管理采集層數(shù)據(jù)質(zhì)量管理數(shù)據(jù)質(zhì)量規(guī)那么、知識庫數(shù)據(jù)質(zhì)量稽核指標(biāo)運(yùn)維數(shù)據(jù)平安管理4A認(rèn)證隱私信息保護(hù)權(quán)限管控、審計追蹤元數(shù)據(jù)管理元數(shù)據(jù)獲取管理元數(shù)據(jù)存儲與模型管理元數(shù)據(jù)分析、展現(xiàn)、效勞技術(shù)、業(yè)務(wù)元數(shù)據(jù)管理DW-RDBDW-MPP分布式文件系統(tǒng)非關(guān)系數(shù)據(jù)庫分布式計算數(shù)據(jù)分發(fā)同步處理數(shù)據(jù)效勞功能用戶管理權(quán)限管理備份與恢復(fù)日志管理設(shè)備監(jiān)控指標(biāo)資源池指標(biāo)數(shù)據(jù)庫指標(biāo)分布式系統(tǒng)指標(biāo)指標(biāo)匯總存儲管理資源池管理設(shè)備管理作業(yè)調(diào)度管理

6、事件自動化規(guī)那么配置執(zhí)行引擎性能預(yù)警調(diào)度異常控制北向接口管理數(shù)據(jù)采集接口管理數(shù)據(jù)共享配置通用接口配置平臺管理功能應(yīng)用展示層企業(yè)數(shù)據(jù)中心元數(shù)據(jù)獲取采集層數(shù)據(jù)質(zhì)量定義、稽核存儲庫模型定義采集數(shù)據(jù)分發(fā)目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成數(shù)據(jù)中心引入大數(shù)據(jù)的意義與原那么隨著半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)、互聯(lián)網(wǎng)數(shù)據(jù)等新型數(shù)據(jù)源的引入以及分析需求對分析深度和廣度的增加，以移動運(yùn)營商行業(yè)為例，越來越需要大數(shù)據(jù)。主要包括如下：1、數(shù)據(jù)規(guī)模方面：GPRS流量話單的條數(shù)和數(shù)據(jù)量已經(jīng)超過

7、了語音詳單，而位置信令、Gn信令、客服語音、互聯(lián)網(wǎng)外部數(shù)據(jù)等規(guī)模更大，且還處在不斷增長的趨勢。2、數(shù)據(jù)類型方面：逐步從OLTP系統(tǒng)中獲得的結(jié)構(gòu)化數(shù)據(jù)，過渡到結(jié)構(gòu)化數(shù)據(jù)和互聯(lián)網(wǎng)網(wǎng)頁、上網(wǎng)日志等非結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)共存。3、對數(shù)據(jù)的使用方面：不僅有批量的數(shù)據(jù)加工和前臺界面的訪問，臨時統(tǒng)計、數(shù)據(jù)挖掘等訪問需求也逐步增多。對歷史明細(xì)數(shù)據(jù)的訪問增多。對數(shù)據(jù)訪問的及時性增強(qiáng)。隨著數(shù)據(jù)中心越來越具備大數(shù)據(jù)平臺的特征，利用傳統(tǒng)的單一數(shù)據(jù)倉庫技術(shù)就難以滿足高效低本錢的需求，需要引入相應(yīng)的大數(shù)據(jù)技術(shù)。新技術(shù)的引入不能影響原有的使用感知，需要按照分階段逐步引入的方式?？梢詤⒖既缦碌膸讉€引入原那么：1、先增量后

8、存量。現(xiàn)有的數(shù)據(jù)處理系統(tǒng)引入大數(shù)據(jù)處理技術(shù)，面臨著模型改造、流程改造等一系列的問題，可以首先在新上線應(yīng)用引入大數(shù)據(jù)處理技術(shù)。2、先邊緣后核心。對于原有功能的遷移，可以先遷移非關(guān)鍵的應(yīng)用。這些應(yīng)用不涉及到關(guān)鍵生產(chǎn)任務(wù)，可以忍受數(shù)據(jù)處理延遲和故障修復(fù)時間較高等可能出現(xiàn)的風(fēng)險。3、先簡單后復(fù)雜。數(shù)據(jù)處理邏輯較簡單的應(yīng)用也可以首先嘗試引入大數(shù)據(jù)處理技術(shù)，降低實施的復(fù)雜度，積累運(yùn)維經(jīng)驗。通過在大數(shù)據(jù)處理技術(shù)的規(guī)劃、實施及運(yùn)維過程中積累經(jīng)驗及教訓(xùn)，不斷提升和完善大數(shù)據(jù)技術(shù)的應(yīng)用水平，逐步拓展大數(shù)據(jù)技術(shù)應(yīng)用領(lǐng)域。大數(shù)據(jù)在數(shù)據(jù)中心的應(yīng)用場景大數(shù)據(jù)技術(shù)可以應(yīng)用在以下場景包括但不限于：1、原數(shù)據(jù)倉庫底層結(jié)構(gòu)化數(shù)據(jù)

9、處理ETL或ELT。底層結(jié)構(gòu)化數(shù)據(jù)處理計算任務(wù)重但復(fù)雜性不高，不涉及多表關(guān)聯(lián)，適合引入大數(shù)據(jù)技術(shù)實現(xiàn)高效低本錢。例如：對運(yùn)營商的清單語音詳單、GPRS清單、WLAN清單等的清洗、轉(zhuǎn)換、匯總等。2、半結(jié)構(gòu)和非結(jié)構(gòu)數(shù)據(jù)處理與分析。例如對上網(wǎng)日志、網(wǎng)絡(luò)信令、客服語音等數(shù)據(jù)的處理和分析，這些數(shù)據(jù)難以利用傳統(tǒng)數(shù)據(jù)倉庫技術(shù)進(jìn)行處理和分析。3、數(shù)據(jù)集市。地數(shù)據(jù)集市應(yīng)用較為獨立，且對可靠性的要求并不是十分嚴(yán)格，適合作為引入大數(shù)據(jù)技術(shù)形成資源池，以移動運(yùn)營商為例，可實現(xiàn)各地市、各部門數(shù)據(jù)集市的云化、池化和虛擬化，最終實現(xiàn)資源動態(tài)調(diào)配，到達(dá)高效低本錢。4、數(shù)據(jù)倉庫數(shù)據(jù)分級存儲。對低價值的細(xì)節(jié)數(shù)據(jù)以及長周期的歷史數(shù)

10、據(jù)冷數(shù)據(jù)訪問頻率較低，也能容忍相對較長的響應(yīng)時間，可以存儲在本錢更低的平臺上。5、數(shù)據(jù)挖掘。某些數(shù)據(jù)挖掘設(shè)計長周期的數(shù)據(jù)，計算時間很長數(shù)天，占用很多數(shù)據(jù)倉庫資源。還有一些數(shù)據(jù)挖掘算法超出了關(guān)系代數(shù)計算范疇，需要抽取數(shù)據(jù)到獨立的計算平臺例如SAS統(tǒng)計分析系統(tǒng)中進(jìn)行計算。這些數(shù)據(jù)挖掘任務(wù)可以遷移到大數(shù)據(jù)平臺之上進(jìn)行計算。例如交往圈的計算，因其僅涉及單一數(shù)據(jù)，但數(shù)據(jù)量非常大，且需要屢次迭代計算。6、對外查詢。數(shù)據(jù)中心不僅僅是數(shù)據(jù)處理，也需要將數(shù)據(jù)處理的結(jié)果對外提供查詢，而這些查詢一局部是海量的OLAP性質(zhì)的查詢，另外還有一局部OLTP性質(zhì)的查詢，即數(shù)量眾多但每次查詢量較少的。比方數(shù)據(jù)中心前端庫、與生

11、產(chǎn)系統(tǒng)互動的數(shù)據(jù)庫以及提供流量詳單查詢的數(shù)據(jù)庫。這些查詢?nèi)蝿?wù)不能很好地運(yùn)行在OLAP類數(shù)據(jù)庫之上，可以遷移到大數(shù)據(jù)平臺上。針對這些應(yīng)用場景，可以看到，主要需要引入的是Hadoop和MPP技術(shù)，然后逐步考慮NoSQL、流計算和內(nèi)存計算等技術(shù)的引入。Hadoop技術(shù)與MPP技術(shù)的比較HadoopMPP 傳統(tǒng)數(shù)據(jù)倉庫平臺開放性高低低運(yùn)維復(fù)雜度高，與運(yùn)維人員能力相關(guān)中中擴(kuò)展能力高中低擁有成本低中高系統(tǒng)和數(shù)據(jù)管理成本高中中應(yīng)用開發(fā)維護(hù)成本高中中SQL支持低高高數(shù)據(jù)規(guī)模PB級別部分PBTB級別計算性能對非關(guān)系型操作效率高對關(guān)系型操作效率高對關(guān)系型操作效率中數(shù)據(jù)結(jié)構(gòu)結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)

12、化數(shù)據(jù)Hadoop 在處理非結(jié)構(gòu)數(shù)據(jù)和半結(jié)構(gòu)數(shù)據(jù)上具備優(yōu)勢，尤其適合海量數(shù)據(jù)批處理等應(yīng)用需求。當(dāng)然隨著Hadoop技術(shù)的成熟，基于Hadoop的即席查詢技術(shù)也逐漸嶄露頭角。比方仿照Dremel的開源工程Apache Drill以及Cloudera Impala。MPP適合替代現(xiàn)有關(guān)系數(shù)據(jù)結(jié)構(gòu)下的大數(shù)據(jù)處理，具有較高的效率，但其在大規(guī)模集群超過100個節(jié)點下的可用性還有待試點證實。MPP數(shù)據(jù)庫場景下經(jīng)常需要掃描大量的數(shù)據(jù)，所以對磁盤存儲系統(tǒng)的I/O性能要求非常高，在測試和日常運(yùn)行中，I/O多大情況下是瓶頸，這點與Hadoop平臺可以明顯區(qū)分開來。目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義

13、數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)規(guī)劃選型Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用場景MPP數(shù)據(jù)庫適合結(jié)構(gòu)化數(shù)據(jù)的深度分析、復(fù)雜查詢以及多變的自助分析類應(yīng)用。它提供了統(tǒng)一的標(biāo)準(zhǔn)訪問接口SQL，而無需像Hadoop一樣需要定制開發(fā)。MPP數(shù)據(jù)庫一般構(gòu)建在X86平臺上，并使用本地盤而不用陣列，而且產(chǎn)品眾多，因為可以降低擁有本錢。MPP數(shù)據(jù)庫產(chǎn)品在數(shù)據(jù)中心中可以用于以下場景包括但不限于：數(shù)據(jù)集市：數(shù)據(jù)集市定位于以企業(yè)數(shù)據(jù)倉庫數(shù)據(jù)為根底，結(jié)合其他相關(guān)數(shù)據(jù)，支撐特定業(yè)務(wù)場景或者業(yè)務(wù)部門需求的IT平臺。目前運(yùn)營商數(shù)據(jù)中心中已經(jīng)存在地市數(shù)據(jù)

14、集市和部門數(shù)據(jù)集市。隨著新業(yè)務(wù)平臺分析需求的出現(xiàn)、不同分析特征的需求的出現(xiàn)，還有一些分析需求可以通過數(shù)據(jù)集市的方式進(jìn)行承載，比方深度分析Advanced Analysis和自助分析Self-Service Analysis。數(shù)據(jù)分級存儲歷史庫或者明細(xì)庫：數(shù)據(jù)中心中數(shù)據(jù)存儲周期分為在線數(shù)據(jù)、近線數(shù)據(jù)、歸檔數(shù)據(jù)。目前在線數(shù)據(jù)及近線數(shù)據(jù)存放在數(shù)據(jù)倉庫，歸檔數(shù)據(jù)使用磁帶庫存放。帶來的問題是在線數(shù)據(jù)中不常訪問的數(shù)據(jù)占據(jù)數(shù)據(jù)倉庫珍貴的資源，針對歸檔數(shù)據(jù)的數(shù)據(jù)分析需求增加，而數(shù)據(jù)從磁帶庫恢復(fù)的時間無法滿足需求。數(shù)據(jù)中心數(shù)據(jù)倉庫的數(shù)據(jù)在完成近期數(shù)據(jù)支撐任務(wù)后，轉(zhuǎn)移到歷史庫中進(jìn)行長周期存儲，支持后續(xù)數(shù)據(jù)訪問和長

15、周期數(shù)據(jù)分析需求，同時可作為核心數(shù)據(jù)倉庫的備份，提升整體架構(gòu)及數(shù)據(jù)的高可用性。MPP架構(gòu)基于x86平臺構(gòu)建，可高效低本錢的實現(xiàn)歷史庫的建設(shè)需求。ETL：通過將數(shù)據(jù)的關(guān)聯(lián)匯總卸載到MPP數(shù)據(jù)庫上，可降低數(shù)據(jù)倉庫的負(fù)載，提高數(shù)據(jù)關(guān)聯(lián)匯總的性能，同時可以滿足后續(xù)數(shù)據(jù)量增長情況下的平滑擴(kuò)容的需求。這局部的計算任務(wù)可以定位于數(shù)據(jù)倉庫外的復(fù)雜數(shù)據(jù)加工、數(shù)據(jù)匯總?cè)蝿?wù)，其源數(shù)據(jù)可以來自業(yè)務(wù)系統(tǒng)，也可以來自ETL專業(yè)ETL工具或者Hadoop清洗、轉(zhuǎn)換后的話單或者經(jīng)過ETL輕度匯總過的數(shù)據(jù)。其結(jié)果數(shù)據(jù)導(dǎo)入到根底數(shù)據(jù)倉庫中供上層應(yīng)用訪問。MPP平臺選型建議對比項目TeradataEMC南大通用IBMHPAster

16、 DataGreenPlumGBase 8ADB2 DPF Over GPFSVertica無共享MPP架構(gòu)-無主控節(jié)點*無共享MPP架構(gòu)-有主控節(jié)點支持行存儲支持列存儲（10.5版本發(fā)布后）當(dāng)前構(gòu)建在X86平臺上的新型MPP數(shù)據(jù)庫產(chǎn)品眾多，Garnter每年會發(fā)布一版數(shù)據(jù)倉庫魔力象限可以供參考。在大陸地區(qū)可以獲得技術(shù)支持的MPP產(chǎn)品及其特性如下包括但不限于：不同架構(gòu)的數(shù)據(jù)倉庫各有優(yōu)缺點。比方帶主控節(jié)點Master的數(shù)據(jù)庫會存在單點故障，但各節(jié)點分工明確；無主控節(jié)點的數(shù)據(jù)庫不存在單點故障，但可能某各節(jié)點承擔(dān)的任務(wù)不平均。行存儲裝載數(shù)據(jù)快、壓縮率低、查詢速度稍慢；列存儲裝載數(shù)據(jù)滿、壓縮率高、查詢

17、速度快，但局部產(chǎn)品的列存儲方式無法支持更新、刪除數(shù)據(jù)。硬件平臺的選型參考各廠家的指導(dǎo)文檔。MPP數(shù)據(jù)分布規(guī)劃得益于ShareNothing的架構(gòu)，MPP數(shù)據(jù)庫的所有表都是分布式存儲的，所以在創(chuàng)立表時都需要指定分布鍵，分布鍵可以是單一字段，也可以是復(fù)合字段，然后通過Hash方式去分布。合理的分布鍵設(shè)計可以使得大局部的表關(guān)聯(lián)操作在一個節(jié)點內(nèi)完成，不需要跨節(jié)點進(jìn)行數(shù)據(jù)交互，這是MPP數(shù)據(jù)庫產(chǎn)品按行Hash分布與Hadoop選擇按照塊隨機(jī)分布的根本差異。注意：在某個節(jié)點發(fā)生故障無法為整個MPP數(shù)據(jù)庫集群提供效勞的情況下，數(shù)據(jù)庫會自動切換到副本機(jī)制，利用副本所在的效勞器來提供效勞。但是副本所在的效勞器本

18、身就要承擔(dān)自己正常的工作任務(wù)，這樣一來相當(dāng)于負(fù)荷加重了一倍。所以故障情況下雖然整個數(shù)據(jù)庫集群可用，但是理論上的性能將下降到原來的一半，而不是按照退服節(jié)點比例的性能下降。目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成Hadoop在數(shù)據(jù)中心的應(yīng)用場景分析場景為什么采用Hadoop采用的組件ETL1、降低原始數(shù)據(jù)存儲壓力2、降低數(shù)據(jù)倉庫處理壓力3、降低存儲和處理成本Hive/MR/Pig清單查詢1、快速響應(yīng)海量數(shù)據(jù)查詢2、降低查詢成本HBase機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘1、降低海量數(shù)

19、據(jù)挖掘成本2、縮短計算時間3、實現(xiàn)更加靈活的算法mahout/R/MR冷數(shù)據(jù)存儲降低冷數(shù)據(jù)存儲成本降低冷數(shù)據(jù)查詢成本Hive Over HDFSHadoop在數(shù)據(jù)中心的應(yīng)用場景-ETLHadoop平臺負(fù)責(zé)從接口機(jī)采集數(shù)據(jù)入HDFS分布式文件系統(tǒng)，并進(jìn)行清洗、關(guān)聯(lián)、轉(zhuǎn)換、匯總、邏輯增強(qiáng)等，實現(xiàn)原始數(shù)據(jù)、明細(xì)數(shù)據(jù)和匯總數(shù)據(jù)的處理加工工作。具體實現(xiàn)上可以采用Hive或Pig用腳本來實現(xiàn)數(shù)據(jù)處理，也可以編寫Java或其他語言的程序用到Hadoop流的功能，直接利用MapReduce框架來進(jìn)行處理。Hadoop在數(shù)據(jù)中心的應(yīng)用場景-詳單查詢Oracle/DB2用戶詳單文件庫數(shù)據(jù)存儲服務(wù)接口話單查詢數(shù)據(jù)抽

20、取數(shù)據(jù)解析數(shù)據(jù)翻譯用戶詳單統(tǒng)計分析收入保障呼叫中心飛信短信彩信WAPEmail網(wǎng)廳統(tǒng)一接入網(wǎng)關(guān)平臺用戶賬單HBase 分布式數(shù)據(jù)庫（基于HDFS) Hive分布式數(shù)據(jù)倉庫(基于HDFS) 前端查詢業(yè)務(wù)服務(wù)器集群 ETL服務(wù)器集群 清賬單數(shù)據(jù)抽取和轉(zhuǎn)換計費(fèi)數(shù)據(jù)庫清賬單數(shù)據(jù)裝載入HBase歷史清賬單數(shù)據(jù)可從HBase導(dǎo)出裝載入Hive (可選)負(fù)載均衡設(shè)備查詢清單互聯(lián)網(wǎng)用戶 清單云平臺采用基于大數(shù)據(jù)的Hadoop云架構(gòu)，以PC效勞器搭建大規(guī)模存儲集群。在數(shù)據(jù)處理方面：引入數(shù)據(jù)抽取、轉(zhuǎn)換、加載工具ETL，在入庫前對詳單中的各個字段含義進(jìn)行翻譯，效勞接口不再進(jìn)行翻譯，提升查詢效率；在分布式存儲方面：引

21、入基于x86效勞器的分布式存儲技術(shù)，主要由Hbase、Hive、數(shù)據(jù)庫集成等功能組成，在提高系統(tǒng)的擴(kuò)展性和彈性的同時，可以方便、快速地為應(yīng)用增加或減少資源。某運(yùn)營商省份的應(yīng)用效果：應(yīng)用前數(shù)據(jù)導(dǎo)入性能指標(biāo)1M/秒，應(yīng)用后到達(dá)45M/秒，性能提升44倍。應(yīng)用前數(shù)據(jù)加載性能指標(biāo)3萬條/秒，應(yīng)用后到達(dá)17萬條/秒，性能提升4.67倍。應(yīng)用前用戶查詢性能指標(biāo)30個并發(fā)查詢/秒，應(yīng)用后到達(dá)100個并發(fā)查詢/秒，性能提升233%。應(yīng)用前并發(fā)查詢性能指標(biāo)35.81毫秒/筆，應(yīng)用后到達(dá)8.09毫秒/筆，性能提升77.4%。Hadoop在數(shù)據(jù)中心的應(yīng)用場景-機(jī)器學(xué)習(xí)與數(shù)據(jù)挖掘、冷數(shù)據(jù)存儲Hadoop可以承載數(shù)據(jù)量

22、較大、需要屢次迭代關(guān)聯(lián)、涉及數(shù)據(jù)對象較為單一的數(shù)據(jù)挖掘計算。Hadoop上開源數(shù)據(jù)挖掘分析專題工具有mahout和R，也可通過MR接口編程實現(xiàn)所需的挖掘算法，可以實現(xiàn)以下數(shù)據(jù)挖掘：互聯(lián)網(wǎng)內(nèi)容分析專題：客戶上網(wǎng)行為分析，關(guān)鍵詞排序，爬蟲，非結(jié)構(gòu)化數(shù)據(jù)識別WLAN運(yùn)營分析專題：WLAN終端分析，WLAN位置分析，WLAN與GPRS關(guān)聯(lián)分析，WLAN用戶群分析用戶交友圈分析專題：用戶個人語音交友圈分析，用戶個人短信交友圈分析，交友圈特征分析Hadoop可以承載歷史性、訪問頻率較低的數(shù)據(jù)，存放在Hadoop上仍然能夠?qū)崿F(xiàn)通過Hive或者其他軟件，實現(xiàn)類SQL或者其他API的數(shù)據(jù)訪問。而在配置策略時，為

23、了節(jié)省空間，可選擇進(jìn)行壓縮、糾刪碼HDFS Raid或者降低副本個數(shù)，例如2。冷數(shù)據(jù)例如：超過一定周期的12個月以上的詳單信息。上網(wǎng)日志信息和原始網(wǎng)頁信息。其他價值低、優(yōu)先級低、數(shù)據(jù)量大的數(shù)據(jù)。Hadoop選型建議產(chǎn)品包基線版本產(chǎn)品包基線版本Hadoop2.0.0HBase0.94.6Hive0.10.0Cloudera Impala1.0ZooKeeper3.4.3總體來看，目前Apache Hadoop開源社區(qū)主要在Hadoop 1.0和2.0 兩個版本上分別進(jìn)行持續(xù)更新優(yōu)化。而Cloudera公司的Hadoop版本CDH3和CDH4也分別基于Hadoop 1.0和2.0版本進(jìn)行封裝。以下

24、圖開源社區(qū)發(fā)布的各個版本以及與Cloudera發(fā)布的CDH軟件包的對應(yīng)關(guān)系如以下圖所示，以及對應(yīng)CDH4.3版本的描述：Hadoop效勞器配置建議項目主節(jié)點配置建議數(shù)據(jù)處理（MR/hive）的數(shù)據(jù)節(jié)點數(shù)據(jù)查詢（HBase）的數(shù)據(jù)節(jié)點，可以與數(shù)據(jù)處理的數(shù)據(jù)節(jié)點合設(shè)zk節(jié)點CPU個數(shù)及核心數(shù)2路8核以上2路8核以上，如果壓縮數(shù)據(jù)或者處理比較復(fù)雜，可以考慮更多路多核的2路6核以上2路8核以上硬盤數(shù)硬盤數(shù)可以不同太多，4-6塊6、8或者12塊，數(shù)據(jù)處理時IO一般不是瓶頸，但更多的磁盤可以存儲更多的數(shù)據(jù)6、8或者12塊，取決于存儲量（主要靠緩存）硬盤數(shù)2-4塊內(nèi)存128G或更高48G或更高64G或更高，

25、太高GC可能成為負(fù)擔(dān)48G或更高網(wǎng)絡(luò)雙口萬兆或千兆網(wǎng)卡雙口萬兆或千兆網(wǎng)卡，主要影響裝載速度和節(jié)點間數(shù)據(jù)交換效率雙口千兆網(wǎng)卡雙口萬兆或千兆網(wǎng)卡，對網(wǎng)絡(luò)延時有高要求，如果可以，建議單獨設(shè)立奇數(shù)個集群，3-5個Hadoop被設(shè)計運(yùn)行在大規(guī)模通用X86硬件平臺之上，使用本地存儲DAS來實現(xiàn)Scale Out。所以其對硬件的要求較低，一般的PC效勞器也可以運(yùn)行，只要滿足發(fā)行版所要求的操作系統(tǒng)和JDK需求即可。但是在實際使用中需要根據(jù)Hadoop的應(yīng)用環(huán)境來合理配置硬件，充分發(fā)揮每個部件的效率。在前期試點中，發(fā)現(xiàn)如果執(zhí)行MapReduce，特別是在壓縮文件上執(zhí)行，其對CPU的消耗較高，CPU成為了瓶頸；而

26、在運(yùn)行Hbase的時候，更多的內(nèi)存會緩存更多的數(shù)據(jù)，提高查詢吞吐率并縮短響應(yīng)時間。所以建議這兩種情況下，可以考慮按照如右表格配比來配置硬件：Hbase配置建議Rowkey設(shè)計：HBase表的rowkey設(shè)計，一般是將關(guān)系數(shù)據(jù)庫中的候選key拼接形成。但是要注意熱點問題，比方rowkey開始的幾位是時間排序，那么在插入的時候，最近幾天的數(shù)據(jù)很可能是熱點數(shù)據(jù)，這樣所有的查詢可能都指向了一個region server導(dǎo)致了HBase的性能瓶頸。盡量防止使用單調(diào)遞增的rowkey，因為在添加數(shù)據(jù)的時候，所有的新數(shù)據(jù)都添加到最后一個region，前面的region沒有或者很少有請求，也是熱點問題。熱點問

27、題的處理方式一般是加鹽，即在rowkey前面添加hash數(shù)，來對數(shù)據(jù)進(jìn)行hash劃分。列簇設(shè)計：HBase表的Column Family最好少于4，一般少于3，對于一般數(shù)據(jù)放入一個列簇中即可。對于一些強(qiáng)關(guān)聯(lián)，頻繁訪問的數(shù)據(jù)可以放一列，這樣在取數(shù)據(jù)時，熱點訪問只用取這一列數(shù)據(jù)，可以節(jié)省IO。多個列簇有各自memstore，memstore 開銷大，而且flush一個列簇，其他的類簇也會flush，會造成不必要的開銷。Region劃分：HBase在導(dǎo)入大量數(shù)據(jù)前最好預(yù)先劃分region，這樣可以加快導(dǎo)入效率。同時也要防止使用HBase自動劃分region，在一種情況下，HBase面臨大量寫入或者s

28、can請求，同時它的region中的數(shù)據(jù)又到達(dá)了閥值，那么它會啟動自動劃分region，有可能導(dǎo)致region劃分風(fēng)暴，大量的請求會使region server和name node的壓力過大而導(dǎo)致region dead或者name node dead。TTL設(shè)計：TTLtime to live，它一般可以用來控制數(shù)據(jù)的生存時間。一些數(shù)據(jù)比方客戶幾年以前的數(shù)據(jù)，幾年以后已經(jīng)不關(guān)心這些數(shù)據(jù)，可以使用TTL刪除。如果數(shù)據(jù)沒有這些要求，可以不使用。目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳

29、統(tǒng)數(shù)據(jù)中心的集成數(shù)據(jù)中心系統(tǒng)集成建議在引入Hadoop和MPP數(shù)據(jù)庫后，數(shù)據(jù)中心建設(shè)將會在現(xiàn)有傳統(tǒng)數(shù)據(jù)倉庫平臺與新技術(shù)之間形成混搭。經(jīng)典數(shù)據(jù)倉庫中的One Single View of Truth將難以維持。主要會面臨如下的問題：數(shù)據(jù)互通：數(shù)據(jù)需要跨Hadoop和多個數(shù)據(jù)庫進(jìn)行交互，如何實現(xiàn)高效的數(shù)據(jù)同步或數(shù)據(jù)調(diào)用？透明訪問：是否有必要對上層應(yīng)用屏蔽底層不同數(shù)據(jù)平臺的細(xì)節(jié)，提供統(tǒng)一的數(shù)據(jù)訪問方式？統(tǒng)一管理：如何進(jìn)行多套數(shù)據(jù)平臺的元數(shù)據(jù)、數(shù)據(jù)質(zhì)量管理，如何實現(xiàn)統(tǒng)一的調(diào)度和運(yùn)維監(jiān)控？數(shù)據(jù)互通機(jī)制是多個數(shù)據(jù)庫與Hadoop之間的橋梁。通過數(shù)據(jù)互通，我們可以將數(shù)據(jù)快速從一個平臺遷移到另外一個平臺或從一

30、個平臺方便地訪問另外一個平臺中的數(shù)據(jù)。數(shù)據(jù)互通機(jī)制的主要難點是要保障數(shù)據(jù)在兩個平臺間流轉(zhuǎn)時的高效性和可靠性。數(shù)據(jù)中心系統(tǒng)互通的建議實現(xiàn)數(shù)據(jù)互通機(jī)制有2種方法：數(shù)據(jù)同步、數(shù)據(jù)調(diào)用數(shù)據(jù)同步：數(shù)據(jù)同步的主要是實現(xiàn)數(shù)據(jù)庫與Hadoop之間雙向數(shù)據(jù)復(fù)制功能，數(shù)據(jù)同步的目的包括這些的場景：不同系統(tǒng)上的數(shù)據(jù)需要進(jìn)行關(guān)聯(lián)分析、數(shù)據(jù)生命周期管理要求進(jìn)行數(shù)據(jù)歸檔或備份、ETL分節(jié)點部署需要同步數(shù)據(jù)等?？梢圆扇∪缦聰?shù)據(jù)同步方案：在Hadoop端發(fā)起的雙向數(shù)據(jù)同步在數(shù)據(jù)庫端發(fā)起的雙向數(shù)據(jù)同步在第三方發(fā)起的雙向數(shù)據(jù)同步數(shù)據(jù)調(diào)用：數(shù)據(jù)調(diào)用指的是：不移動數(shù)據(jù)，通過接口調(diào)用實現(xiàn)對另外一個平臺上數(shù)據(jù)的訪問，被調(diào)用平臺承擔(dān)運(yùn)算任

31、務(wù)。數(shù)據(jù)調(diào)用方法根據(jù)調(diào)用方的不同，又分為“從數(shù)據(jù)庫側(cè)調(diào)用Hadoop數(shù)據(jù)及“從Hadoop側(cè)調(diào)用數(shù)據(jù)庫數(shù)據(jù)兩種情況。數(shù)據(jù)調(diào)用方法適用的場景原那么：低頻度如：每月/季度/年一次或臨時如：臨時訪問5次以下需要使用其他平臺中存儲的數(shù)據(jù)。數(shù)據(jù)中心互通的技術(shù)實現(xiàn)連接器方式通過設(shè)計專用的軟件或硬件連接器模塊，實現(xiàn)數(shù)據(jù)庫與Hadoop之間高速的數(shù)據(jù)傳輸，其一般具備以下特點：雙向連接器并行連接數(shù)據(jù)庫節(jié)點到的Hadoop數(shù)據(jù)節(jié)點支持UTF-8編碼和常見的數(shù)據(jù)類型通過動態(tài)工作負(fù)載管理的資源控制融合系統(tǒng)中的角色/用戶提供認(rèn)證為數(shù)據(jù)庫域提供的數(shù)據(jù)節(jié)點，主要實現(xiàn)以下按照源表進(jìn)行任務(wù)分工，可以為表間并行以及表內(nèi)并行建立分

32、區(qū)、索引及裝載，根據(jù)分區(qū)原那么以及索引等策略，裝載節(jié)點將數(shù)據(jù)直接發(fā)送給相應(yīng)的MPP數(shù)據(jù)庫節(jié)點上裝載節(jié)點處理過程中數(shù)據(jù)不落地裝載節(jié)點可以是MPP數(shù)據(jù)庫中的局部節(jié)點也可以獨立設(shè)置 通過連接器的方式，可以實現(xiàn)數(shù)據(jù)庫與Hadoop系統(tǒng)之間的高速和可靠的數(shù)據(jù)互通，非常適合數(shù)據(jù)同步的計算場景。外部表方式：數(shù)據(jù)庫可以通過外部表的方式，直接訪問存儲在HDFS上的文件。在使用外部表時，數(shù)據(jù)庫可以像訪問內(nèi)部數(shù)據(jù)一樣，將文件當(dāng)作表insert到數(shù)據(jù)庫內(nèi)其他表中，或?qū)DFS上的文件和數(shù)據(jù)庫內(nèi)的表進(jìn)行關(guān)聯(lián)操作。同時也可以將RDBMS內(nèi)的數(shù)據(jù)，通過外部表的形式，寫入到HDFS上去。例如如下操作:Select count

33、(*) from HDFS_data h, RDBMS_data g where h.key = g.key;Insert into HDFS_data select * from RDBMS_data;數(shù)據(jù)中心透明訪問HADOOP+MPP的混搭架構(gòu)在解決大數(shù)據(jù)處理問題的同時也加大了上層應(yīng)用的數(shù)據(jù)訪問復(fù)雜度。主要問題表達(dá)在：多種數(shù)據(jù)實例：數(shù)據(jù)可能分布在關(guān)系型數(shù)據(jù)庫、Hadoop分布式計算集群以及HBase庫中。多種訪問接口：不同類型的數(shù)據(jù)實例的技術(shù)實現(xiàn)方式差異大，如關(guān)系型數(shù)據(jù)提供了標(biāo)準(zhǔn)SQL，Hadoop、HBase提供開放API或Hive方式訪問，這同樣對上層訪問增加了難度?？鐢?shù)據(jù)實例的數(shù)據(jù)

34、計算：不同類型的數(shù)據(jù)實例的底層數(shù)據(jù)存儲結(jié)構(gòu)不同，如關(guān)系型數(shù)據(jù)庫存儲結(jié)構(gòu)化數(shù)據(jù)，而Hadoop計算集群多存儲半結(jié)構(gòu)化數(shù)據(jù)，如果需要涉及到兩種類型數(shù)據(jù)實例中的數(shù)據(jù)關(guān)聯(lián)join計算，目前還難以直接實現(xiàn)，需要做一系列數(shù)據(jù)互通調(diào)度，然后在單實例上完成關(guān)聯(lián)計算，整個過程復(fù)雜度高、工作量大。針對目前出現(xiàn)的這些問題，可以考慮構(gòu)建數(shù)據(jù)透明訪問能力。也就是提供統(tǒng)一的數(shù)據(jù)訪問接口，對上層屏蔽底層數(shù)據(jù)處理實現(xiàn)細(xì)節(jié)，提升上層應(yīng)用的開發(fā)效率。主要需要解決兩個方面的問題：1、通過統(tǒng)一的語言或效勞接口訪問到不同的數(shù)據(jù)庫實例，包括數(shù)據(jù)查詢、數(shù)據(jù)處理操作等。2、針對跨數(shù)據(jù)實例的數(shù)據(jù)互通、關(guān)聯(lián)操作等，可以通過統(tǒng)一的的語言、效勞接口

35、或管理工具等技術(shù)來實現(xiàn)。目錄MPP數(shù)據(jù)庫在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成BI集成工具選型問題這些眾多的BI工程從規(guī)模和對BI系統(tǒng)支撐的完善程度上來說，大體可以分為Framework、Stand-alone Tools和BI Suite三種類型。Framework：開源框架，這是在商業(yè)BI系統(tǒng)中所沒有的。我們可以使用它們來構(gòu)建自己的BI工具，或者增強(qiáng)和擴(kuò)展我們的BI解決方案。Stand-alone Tools：獨立的BI工具，這是開源工程中數(shù)量最多的一類。很多工具只側(cè)重BI

36、系統(tǒng)中的某個環(huán)節(jié)和方面，如ETL、Report、OLAP和Database等等。BI Suite：在統(tǒng)一的架構(gòu)下提供了多種BI系統(tǒng)的特性的工具集合。就目前的情況看，不管是商業(yè)軟件還是開源軟件，還沒有任何一個套件提供了完整的端到端的BI解決方案。這些開源的BI Suit是通過連接多個其他的組件和工具的方式形成套件的，由于BI系統(tǒng)涉及到的工具是非常多的，所以整合一套完整的BI解決方案是很困難的。開源BI的重要工程：Pentaho、spagoBi是兩個比較大的框架，集成了相當(dāng)多的開源工程，JfreeReport、Mondrian、Kettle、Weka根本都使用。適合大型復(fù)雜工程的開發(fā)。Pentah

37、o：是一個以工作流為核心的、強(qiáng)調(diào)面向解決方案而非工具組件的BI套件，整合了多個開源工程，目標(biāo)是和商業(yè)BI相抗衡。SpagoBI 集成了OLAP ServerMondrain和OLAP展示JProvit，能夠通過OpenLaszlo產(chǎn)生實時報表。SpagoBI使用java開發(fā)，不依賴于具體的操作系統(tǒng)，有很強(qiáng)的擴(kuò)展能力。開源BI工具之Spago BISpagoBI 集成了Mondrain和JProvit，能夠通過OpenLaszlo產(chǎn)生實時報表。SpagoBI使用java開發(fā)，不依賴于具體的操作系統(tǒng)，有很強(qiáng)的擴(kuò)展能力。它主要包括：1、 報表工具：JasperReports /Eclipse BIR

38、T/ iReport2、 OLAP Server：Mondrian3、 OLAP展示：JPivot4、 數(shù)據(jù)挖掘組件：Weka5、 Map引擎：Geo6、 ETL：BIE7、 搜索引擎：Lucene8、 Dashboard：OpenLaszlo9、 Portal Server：JBoss/ Tomcat/ JOnAS開源BI工具之PentahoPentaho是一個以工作流為核心的、強(qiáng)調(diào)面向解決方案而非工具組件的BI套件，整合了多個開源工程，目標(biāo)是和商業(yè)BI相抗衡。它包括如下開源組件：1、 工作流引擎：Shark and JaWE2、 數(shù)據(jù)庫：Firebird RDBMS3、 集成管理和開發(fā)環(huán)境

39、：Eclipse4、 報表工具：Eclipse BIRT5、 ETL工具：Enhydra/Kettle6、 OLAP Server：Mondrian7、 OLAP展示：JPivot8、 數(shù)據(jù)挖掘組件：Weka9、 應(yīng)用效勞器和Portal效勞器：JBoss10、 單點登陸效勞及LDap認(rèn)證：JOSSO11、 自定義腳本支持：Mozilla Rhino Javascript腳本處理器Pentaho是一個很完善的BI解決方案。Pentaho偏向于與業(yè)務(wù)流程相結(jié)合的BI解決方案，側(cè)重于大中型企業(yè)應(yīng)用。Pentaho與Spago比照From張軼總：目前看Pentaho根本符合我們對數(shù)據(jù)平臺功能的要求。

40、其中，Pentaho Data Intergration PDI可以用作我們的數(shù)據(jù)平臺集成，并且其支持與Hadoop及周邊軟件集成。同時也支持絕大多數(shù)NoSQL。還有，對于Map/Reduce job也有很好支持。Pentaho Business Analytics PBA是一個數(shù)據(jù)分析、展示平臺，可以生成報表，做數(shù)據(jù)可視化，具有數(shù)據(jù)挖掘功能。Pentaho集成了很多第三方開源工程，這種集成是無縫的。Pentaho也有很好的Metadata管理功能?？傊且粋€很好的BI系統(tǒng)框架且完全開源。相信通過Pentaho，我們可以搭出一個PoC演示環(huán)境。后續(xù)我們還會做更進(jìn)一步的研究。目錄MPP數(shù)據(jù)庫

41、在數(shù)據(jù)中心的應(yīng)用企業(yè)級數(shù)據(jù)中心定義數(shù)據(jù)中心中的大數(shù)據(jù)數(shù)據(jù)中心BI技術(shù)選型描述Hadoop在數(shù)據(jù)中心的應(yīng)用數(shù)據(jù)中心ESB技術(shù)研究大數(shù)據(jù)技術(shù)與傳統(tǒng)數(shù)據(jù)中心的集成企業(yè)應(yīng)用集成EAI與ESB企業(yè)應(yīng)用集成EAI是集成應(yīng)用之間數(shù)據(jù)和效勞的一種應(yīng)用技術(shù)。它解決無限的問題，解決方案也幾乎沒有窮盡。目前常見的四種集成風(fēng)格：1.文件傳輸：兩個系統(tǒng)生成文件，文件的有效負(fù)載就是由另一個系統(tǒng)處理的消息。該類風(fēng)格的例子之一是針對文件輪詢目錄或FTP目錄，并處理該文件。2.共享數(shù)據(jù)庫：兩個系統(tǒng)查詢同一個數(shù)據(jù)庫以獲取要傳遞的數(shù)據(jù)。一個例子是你部署了兩個EAR應(yīng)用，它們的實體類JPA、Hibernate等共用同一個表。3.遠(yuǎn)程

42、過程調(diào)用：兩個系統(tǒng)都暴露另一個能調(diào)用的效勞。該類例子有EJB效勞，或SOAP和REST效勞。4.消息：兩個系統(tǒng)連接到一個公用的消息系統(tǒng)，互相交換數(shù)據(jù)，并利用消息調(diào)用行為。該風(fēng)格的例子就是眾所周知的中心輻射式的hub-and-spokeJMS架構(gòu)。這些風(fēng)格迥然不同，因為沒有一種解決方法能在任何情況下都良好運(yùn)轉(zhuǎn)。這導(dǎo)致整個中間件領(lǐng)域都在基于這些模式尋求可用的解決方法，通常被稱為企業(yè)效勞總線ESB。ESB是最終的中間人：它知道如何使用各種語言在各種協(xié)議上調(diào)解傳遞的消息。ESB定義與主要功能：ESB全稱為Enterprise Service Bus，即企業(yè)效勞總線。它是傳統(tǒng)中間件技術(shù)與XML、Web效

43、勞等技術(shù)結(jié)合的產(chǎn)物。ESB提供了網(wǎng)絡(luò)中最根本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。Invocation同步和異步的傳輸協(xié)議的支持、效勞的定位和綁定 Routing靜態(tài)和動態(tài)路由、基于內(nèi)容路由、基于策略路由、基于規(guī)那么路由Mediation適配、協(xié)議轉(zhuǎn)換、效勞映射 Messaging 消息處理、轉(zhuǎn)換、增強(qiáng) Process choreography負(fù)責(zé)業(yè)務(wù)邏輯的實現(xiàn) Service orchestration效勞編排 Complex event processing事件解釋、事件關(guān)聯(lián)、模式適配 Other quality of service平安、可靠傳輸、事務(wù) Management監(jiān)視、au

44、dit、日志、計量、管理、BAMESB實施探討不推薦的實施：1、用ESB實現(xiàn)大數(shù)據(jù)傳輸：ESB并不適合完成該項功能，雖然它可以實現(xiàn)這一功能，但這并非最正確實踐。ESB作為企業(yè)級的效勞聯(lián)通、管理平臺，需要穿透ESB的效勞應(yīng)該是企業(yè)內(nèi)重用可能最大、價值最大的那些效勞，應(yīng)用程序?qū)@類效勞的訪問應(yīng)該非常頻繁，因此同一時刻需要ESB支撐的業(yè)務(wù)可能非常繁重。所以，ESB產(chǎn)品的設(shè)計初衷是實現(xiàn)一個無狀態(tài)、高吞吐的效勞總線，為企業(yè)內(nèi)重要的業(yè)務(wù)效勞提供透明、標(biāo)準(zhǔn)、開放的接入能力。這種實踐的原因是過分放大了ESB對數(shù)據(jù)的傳輸能力，如果在ESB傳輸巨大的信息，可能會導(dǎo)致ESB整體性能的下降，損害其他重要效勞的QoS。

45、2、挾ESB以令外圍應(yīng)用：ESB的架構(gòu)師在ESB上設(shè)計一套標(biāo)準(zhǔn)的數(shù)據(jù)接口通用的XML格式，規(guī)定使用統(tǒng)一的協(xié)議如Web Service/HTTP。所有的ESB效勞消費(fèi)者和接入ESB的效勞必須符合該標(biāo)準(zhǔn)。其目的是為了簡化ESB上的開發(fā)工作。這就是一種“挾天子以令諸侯的做法。ESB針對的是一個個功能各異的整合邏輯，效勞之間的整合邏輯也是迥異的。所以，一勞永逸的ESB之上的架構(gòu)是不存在的。3、用ESB實現(xiàn)業(yè)務(wù)流程：有些架構(gòu)師看到ESB支持效勞組合Service Composition模式，進(jìn)而認(rèn)為可用該模式來實現(xiàn)業(yè)務(wù)流程。因此，ESB產(chǎn)品就演變成了BPM產(chǎn)品。讓ESB實現(xiàn)BPM，特別是長運(yùn)行的流程時，

46、雖然在技術(shù)上可以實現(xiàn)，但是這違背了ESB產(chǎn)品的設(shè)計理念，會大大影響其ESB運(yùn)行時的整體運(yùn)行效率。推薦的實施：1、效勞要管理起來：ESB的一個重要功能是將企業(yè)內(nèi)/合作伙伴處的效勞以開放的、標(biāo)準(zhǔn)的效勞方式暴露出來，使得效勞消費(fèi)者能夠便利地查找到效勞，以促進(jìn)效勞的重用、管理。2、復(fù)雜的動態(tài)路由規(guī)那么應(yīng)效勞化：路由是ESB中非常重要的仲裁邏輯之一。路由場景是非常普遍的。譬如，針對不同的客戶提供不同QoS的場景，執(zhí)行時需根據(jù)客戶的類型將其路由到不同執(zhí)行能力的效勞提供者；再比方當(dāng)響應(yīng)消息到達(dá)ESB時，總是需要將該響應(yīng)消息送回最初的效勞請求者處。對于復(fù)雜的路由，推薦將路由規(guī)那么的邏輯外部化，并將它效勞化。開源ESB之ServiceMixSM產(chǎn)品簡介：它是JBI標(biāo)準(zhǔn)的一種實現(xiàn)；包含很熟JBI組件。這些組件支持多種協(xié)議，比方JMS,HTTP,FTP,FILE等。同時也實現(xiàn)了EIP，規(guī)那么和調(diào)度。SM也整合了其他的開源工程，比方Apache、ActiveMQ CXF,Apahe Camel,Apache ODE以及Apache Geronimo。優(yōu)點：1、無縫集成CXF,ActiveMQ,Camel和ODE，因為ServiceMix,ActiveMQ,CXF,Camel都是F