數(shù)據(jù)中心相關(guān)技術(shù)與應(yīng)用39.ppt

1、數(shù)據(jù)中心相關(guān)技術(shù)與應(yīng)用,2013-12-02,目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(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ù)倉(cāng)庫(kù)的架構(gòu),數(shù)據(jù)源,抽取、轉(zhuǎn)換、加載,業(yè)務(wù)數(shù)據(jù)集市,企業(yè)數(shù)據(jù)倉(cāng)庫(kù),ETL,元數(shù)據(jù),前端分析展現(xiàn)工具,查詢工具、應(yīng)用,新一代數(shù)據(jù)中心定義,企業(yè)數(shù)據(jù)中心是指建立在數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)倉(cāng)庫(kù)之上的決策分析應(yīng)用，應(yīng)包括數(shù)據(jù)源、數(shù)據(jù)ETL、ODS數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)集市、商務(wù)智能應(yīng)用、數(shù)據(jù)管理等功能。 數(shù)據(jù)中心應(yīng)該具備常見(jiàn)數(shù)據(jù)的處理與管理能力，具備對(duì)結(jié)構(gòu)化、半結(jié)構(gòu)化、非

2、結(jié)構(gòu)化等數(shù)據(jù)的處理能力，同時(shí)支持RDB、MPP、NoSQL，同時(shí)具備數(shù)據(jù)的通用管理能力，以數(shù)據(jù)為中心進(jìn)行平臺(tái)建設(shè)。 數(shù)據(jù)中心數(shù)據(jù)平臺(tái)在接口層要豐富又簡(jiǎn)單，可以提供各種應(yīng)用所需接口，最大程度匹配已有接口，對(duì)應(yīng)用改動(dòng)需求力求最低。,一個(gè)合理的數(shù)據(jù)平臺(tái)，不能等同于Hadoop或者其他某項(xiàng)單一技術(shù)建設(shè)；整體數(shù)據(jù)中心的建設(shè)，從數(shù)據(jù)采集層、存儲(chǔ)層、應(yīng)用層都有完整的解決方案，同時(shí)具備平臺(tái)運(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ù)平臺(tái)必須針對(duì)數(shù)據(jù)提供完整方案，同時(shí)兼顧應(yīng)用接口、其他平臺(tái)

3、接入，系統(tǒng)管理、系統(tǒng)調(diào)度等功能。 任何一種單一技術(shù)都難以適應(yīng)數(shù)據(jù)中心數(shù)據(jù)采集、存儲(chǔ)、處理和對(duì)外服務(wù)的需求，多種技術(shù)并存才是發(fā)展趨勢(shì)。RDB、MPP、Hadoop,新一代數(shù)據(jù)中心功能視圖,數(shù)據(jù)中心整體功能視圖可以分為數(shù)據(jù)服務(wù)功能模塊、平臺(tái)管理功能模塊，數(shù)據(jù)管理功能模塊，共同數(shù)據(jù)中心的應(yīng)用。,采集 處理層,數(shù)據(jù)抽取/加載/檢查,ETL調(diào)度,數(shù)據(jù)交互、轉(zhuǎn)換,數(shù)據(jù)映射,數(shù)據(jù)層,數(shù)據(jù) 存儲(chǔ),數(shù)據(jù)聚合服務(wù),數(shù)據(jù)處理服務(wù),數(shù)據(jù)查詢服務(wù),數(shù)據(jù)集市、OLAP,接口層,服務(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ù)可

4、視化管理,數(shù)據(jù)質(zhì)量管理,采集層數(shù)據(jù)質(zhì)量管理,數(shù)據(jù)質(zhì)量規(guī)則、知識(shí)庫(kù),數(shù)據(jù)質(zhì)量稽核指標(biāo)運(yùn)維,數(shù)據(jù)安全管理,4A認(rèn)證,隱私信息保護(hù),權(quán)限管控、審計(jì)追蹤,元數(shù)據(jù)管理,元數(shù)據(jù)獲取管理,元數(shù)據(jù)存儲(chǔ)與模型管理,元數(shù)據(jù)分析、展現(xiàn)、服務(wù),技術(shù)、業(yè)務(wù)元數(shù)據(jù)管理,DW-RDB,DW-MPP,分布式文件系統(tǒng),非關(guān)系數(shù)據(jù)庫(kù),分布式計(jì)算,數(shù)據(jù)分發(fā)同步處理,數(shù)據(jù)服務(wù)功能,用戶管理,權(quán)限管理,備份與恢復(fù),日志管理,設(shè)備監(jiān)控指標(biāo),資源池指標(biāo),數(shù)據(jù)庫(kù)指標(biāo),分布式系統(tǒng)指標(biāo),指標(biāo)匯總,存儲(chǔ)管理,資源池管理,設(shè)備管理,作業(yè)調(diào)度管理,事件自動(dòng)化,規(guī)則配置,執(zhí)行引擎,性能預(yù)警,調(diào)度異常控制,北向接口管理,數(shù)據(jù)采集接口管理,數(shù)據(jù)共享配置,通

5、用接口配置,平臺(tái)管理功能,應(yīng)用展示層,企業(yè)數(shù)據(jù)中心,元數(shù)據(jù)獲取,采集層數(shù)據(jù)質(zhì)量定義、稽核,存儲(chǔ)庫(kù)模型定義,采集數(shù)據(jù)分發(fā),目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(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ù)源的引入以及分析需求對(duì)分析深度和廣度的增加，以移動(dòng)運(yùn)營(yíng)商行業(yè)為例，越來(lái)越需要大數(shù)據(jù)。主要包括如下： 1、數(shù)據(jù)規(guī)模方面：GPRS流量話單的條數(shù)和數(shù)據(jù)量已經(jīng)超過(guò)了語(yǔ)音詳單，而位置信令、Gn信令、客服語(yǔ)音、互聯(lián)網(wǎng)外部數(shù)

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

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

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

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

10、系統(tǒng)互動(dòng)的數(shù)據(jù)庫(kù)以及提供流量詳單查詢的數(shù)據(jù)庫(kù)。這些查詢?nèi)蝿?wù)不能很好地運(yùn)行在OLAP類數(shù)據(jù)庫(kù)之上，可以遷移到大數(shù)據(jù)平臺(tái)上。 針對(duì)這些應(yīng)用場(chǎng)景，可以看到，主要需要引入的是Hadoop和MPP技術(shù)，然后逐步考慮NoSQL、流計(jì)算和內(nèi)存計(jì)算等技術(shù)的引入。,Hadoop技術(shù)與MPP技術(shù)的比較,Hadoop 在處理非結(jié)構(gòu)數(shù)據(jù)和半結(jié)構(gòu)數(shù)據(jù)上具備優(yōu)勢(shì)，尤其適合海量數(shù)據(jù)批處理等應(yīng)用需求。當(dāng)然隨著Hadoop技術(shù)的成熟，基于Hadoop的即席查詢技術(shù)也逐漸嶄露頭角。比如仿照Dremel的開(kāi)源項(xiàng)目Apache Drill以及Cloudera Impala。 MPP適合替代現(xiàn)有關(guān)系數(shù)據(jù)結(jié)構(gòu)下的大數(shù)據(jù)處理，具有較高的效

11、率，但其在大規(guī)模集群（超過(guò)100個(gè)節(jié)點(diǎn)）下的可用性還有待試點(diǎn)證實(shí)。 MPP數(shù)據(jù)庫(kù)場(chǎng)景下經(jīng)常需要掃描大量的數(shù)據(jù)，所以對(duì)磁盤(pán)存儲(chǔ)系統(tǒng)的I/O性能要求非常高，在測(cè)試和日常運(yùn)行中，I/O多大情況下是瓶頸，這點(diǎn)與Hadoop平臺(tái)可以明顯區(qū)分開(kāi)來(lái)。,目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(shù)據(jù)中心定義,數(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ù)庫(kù)在數(shù)據(jù)中心的應(yīng)用場(chǎng)景,MPP數(shù)據(jù)庫(kù)適合結(jié)構(gòu)化數(shù)據(jù)的深度分析、復(fù)雜查詢以及多變的自助分析類應(yīng)用。它提供了統(tǒng)一的標(biāo)準(zhǔn)訪問(wèn)接口（SQL），而無(wú)需像Hadoop一樣需要定

12、制開(kāi)發(fā)。MPP數(shù)據(jù)庫(kù)一般構(gòu)建在X86平臺(tái)上，并使用本地盤(pán)而不用陣列，而且產(chǎn)品眾多，因?yàn)榭梢越档蛽碛谐杀尽?MPP數(shù)據(jù)庫(kù)產(chǎn)品在數(shù)據(jù)中心中可以用于以下場(chǎng)景（包括但不限于）： 數(shù)據(jù)集市： 數(shù)據(jù)集市定位于以企業(yè)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)為基礎(chǔ)，結(jié)合其他相關(guān)數(shù)據(jù)，支撐特定業(yè)務(wù)場(chǎng)景或者業(yè)務(wù)部門(mén)需求的IT平臺(tái)。 目前運(yùn)營(yíng)商數(shù)據(jù)中心中已經(jīng)存在地市數(shù)據(jù)集市和部門(mén)數(shù)據(jù)集市。隨著新業(yè)務(wù)平臺(tái)分析需求的出現(xiàn)、不同分析特征的需求的出現(xiàn)，還有一些分析需求可以通過(guò)數(shù)據(jù)集市的方式進(jìn)行承載，比如深度分析（Advanced Analysis）和自助分析（Self-Service Analysis）。 數(shù)據(jù)分級(jí)存儲(chǔ)（歷史庫(kù)或者明細(xì)庫(kù)）： 數(shù)據(jù)中心

13、中數(shù)據(jù)存儲(chǔ)周期分為在線數(shù)據(jù)、近線數(shù)據(jù)、歸檔數(shù)據(jù)。目前在線數(shù)據(jù)及近線數(shù)據(jù)存放在數(shù)據(jù)倉(cāng)庫(kù)，歸檔數(shù)據(jù)使用磁帶庫(kù)存放。帶來(lái)的問(wèn)題是在線數(shù)據(jù)中不常訪問(wèn)的數(shù)據(jù)占據(jù)數(shù)據(jù)倉(cāng)庫(kù)寶貴的資源，針對(duì)歸檔數(shù)據(jù)的數(shù)據(jù)分析需求增加，而數(shù)據(jù)從磁帶庫(kù)恢復(fù)的時(shí)間無(wú)法滿足需求。 數(shù)據(jù)中心數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)在完成近期數(shù)據(jù)支撐任務(wù)后，轉(zhuǎn)移到歷史庫(kù)中進(jìn)行長(zhǎng)周期存儲(chǔ)，支持后續(xù)數(shù)據(jù)訪問(wèn)和長(zhǎng)周期數(shù)據(jù)分析需求，同時(shí)可作為核心數(shù)據(jù)倉(cāng)庫(kù)的備份，提升整體架構(gòu)及數(shù)據(jù)的高可用性。MPP架構(gòu)基于x86平臺(tái)構(gòu)建，可高效低成本的實(shí)現(xiàn)歷史庫(kù)的建設(shè)需求。 ETL： 通過(guò)將數(shù)據(jù)的關(guān)聯(lián)匯總卸載到MPP數(shù)據(jù)庫(kù)上，可降低數(shù)據(jù)倉(cāng)庫(kù)的負(fù)載，提高數(shù)據(jù)關(guān)聯(lián)匯總的性能，同時(shí)可以滿足后續(xù)

14、數(shù)據(jù)量增長(zhǎng)情況下的平滑擴(kuò)容的需求。 這部分的計(jì)算任務(wù)可以定位于數(shù)據(jù)倉(cāng)庫(kù)外的復(fù)雜數(shù)據(jù)加工、數(shù)據(jù)匯總?cè)蝿?wù)，其源數(shù)據(jù)可以來(lái)自業(yè)務(wù)系統(tǒng)，也可以來(lái)自ETL（專業(yè)ETL工具或者Hadoop）清洗、轉(zhuǎn)換后的話單或者經(jīng)過(guò)ETL輕度匯總過(guò)的數(shù)據(jù)。其結(jié)果數(shù)據(jù)導(dǎo)入到基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)中供上層應(yīng)用訪問(wèn)。,MPP平臺(tái)選型建議,當(dāng)前構(gòu)建在X86平臺(tái)上的新型MPP數(shù)據(jù)庫(kù)產(chǎn)品眾多，Garnter每年會(huì)發(fā)布一版數(shù)據(jù)倉(cāng)庫(kù)魔力象限可以供參考。在大陸地區(qū)可以獲得技術(shù)支持的MPP產(chǎn)品及其特性如下（包括但不限于）：,不同架構(gòu)的數(shù)據(jù)倉(cāng)庫(kù)各有優(yōu)缺點(diǎn)。比如帶主控節(jié)點(diǎn)（Master）的數(shù)據(jù)庫(kù)會(huì)存在單點(diǎn)故障，但各節(jié)點(diǎn)分工明確；無(wú)主控節(jié)點(diǎn)的數(shù)據(jù)庫(kù)不存在單

15、點(diǎn)故障，但可能某各節(jié)點(diǎn)承擔(dān)的任務(wù)不平均。行存儲(chǔ)裝載數(shù)據(jù)快、壓縮率低、查詢速度稍慢；列存儲(chǔ)裝載數(shù)據(jù)滿、壓縮率高、查詢速度快，但部分產(chǎn)品的列存儲(chǔ)方式無(wú)法支持更新、刪除數(shù)據(jù)。 硬件平臺(tái)的選型參考各廠家的指導(dǎo)文檔。,MPP數(shù)據(jù)分布規(guī)劃,得益于ShareNothing的架構(gòu)，MPP數(shù)據(jù)庫(kù)的所有表都是分布式存儲(chǔ)的，所以在創(chuàng)建表時(shí)都需要指定分布鍵，分布鍵可以是單一字段，也可以是復(fù)合字段，然后通過(guò)Hash方式去分布。合理的分布鍵設(shè)計(jì)可以使得大部分的表關(guān)聯(lián)操作在一個(gè)節(jié)點(diǎn)內(nèi)完成，不需要跨節(jié)點(diǎn)進(jìn)行數(shù)據(jù)交互，這是MPP數(shù)據(jù)庫(kù)產(chǎn)品（按行Hash分布）與Hadoop（選擇按照塊隨機(jī)分布）的根本差別。,注意： 在某個(gè)節(jié)點(diǎn)發(fā)

16、生故障無(wú)法為整個(gè)MPP數(shù)據(jù)庫(kù)集群提供服務(wù)的情況下，數(shù)據(jù)庫(kù)會(huì)自動(dòng)切換到副本機(jī)制，利用副本所在的服務(wù)器來(lái)提供服務(wù)。但是副本所在的服務(wù)器本身就要承擔(dān)自己正常的工作任務(wù)，這樣一來(lái)相當(dāng)于負(fù)荷加重了一倍。所以故障情況下雖然整個(gè)數(shù)據(jù)庫(kù)集群可用，但是理論上的性能將下降到原來(lái)的一半，而不是按照退服節(jié)點(diǎn)比例的性能下降。,目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(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)用場(chǎng)景分析,Hadoop在數(shù)據(jù)中心的應(yīng)用場(chǎng)景-ETL,Hadoop平臺(tái)負(fù)責(zé)從接口機(jī)采

17、集數(shù)據(jù)入HDFS分布式文件系統(tǒng)，并進(jìn)行清洗、關(guān)聯(lián)、轉(zhuǎn)換、匯總、邏輯增強(qiáng)等，實(shí)現(xiàn)原始數(shù)據(jù)、明細(xì)數(shù)據(jù)和匯總數(shù)據(jù)的處理加工工作。具體實(shí)現(xiàn)上可以采用Hive或Pig用腳本來(lái)實(shí)現(xiàn)數(shù)據(jù)處理，也可以編寫(xiě)Java或其他語(yǔ)言的程序（用到Hadoop流的功能），直接利用MapReduce框架來(lái)進(jìn)行處理。,Hadoop在數(shù)據(jù)中心的應(yīng)用場(chǎng)景-詳單查詢,清單云平臺(tái)采用基于大數(shù)據(jù)的Hadoop云架構(gòu)，以PC服務(wù)器搭建大規(guī)模存儲(chǔ)集群。 在數(shù)據(jù)處理方面：引入數(shù)據(jù)抽取、轉(zhuǎn)換、加載工具ETL，在入庫(kù)前對(duì)詳單中的各個(gè)字段含義進(jìn)行翻譯，服務(wù)接口不再進(jìn)行翻譯，提升查詢效率； 在分布式存儲(chǔ)方面：引入基于x86服務(wù)器的分布式存儲(chǔ)技術(shù)，主要

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

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

20、進(jìn)行壓縮、糾刪碼（HDFS Raid）或者降低副本個(gè)數(shù)，例如2。冷數(shù)據(jù)例如： 超過(guò)一定周期的（12個(gè)月以上）的詳單信息。 上網(wǎng)日志信息和原始網(wǎng)頁(yè)信息。 其他價(jià)值低、優(yōu)先級(jí)低、數(shù)據(jù)量大的數(shù)據(jù)。,Hadoop選型建議,總體來(lái)看，目前Apache Hadoop開(kāi)源社區(qū)主要在Hadoop 1.0和2.0 兩個(gè)版本上分別進(jìn)行持續(xù)更新優(yōu)化。而Cloudera公司的Hadoop版本CDH3和CDH4也分別基于Hadoop 1.0和2.0版本進(jìn)行封裝。下圖開(kāi)源社區(qū)發(fā)布的各個(gè)版本以及與Cloudera發(fā)布的CDH軟件包的對(duì)應(yīng)關(guān)系如下圖所示，以及對(duì)應(yīng)CDH4.3版本的描述：,Hadoop服務(wù)器配置建議,Hadoo

21、p被設(shè)計(jì)運(yùn)行在大規(guī)模通用X86硬件平臺(tái)之上，使用本地存儲(chǔ)（DAS）來(lái)實(shí)現(xiàn)Scale Out。所以其對(duì)硬件的要求較低，一般的PC服務(wù)器也可以運(yùn)行，只要滿足發(fā)行版所要求的操作系統(tǒng)和JDK需求即可。 但是在實(shí)際使用中需要根據(jù)Hadoop的應(yīng)用環(huán)境來(lái)合理配置硬件，充分發(fā)揮每個(gè)部件的效率。在前期試點(diǎn)中，發(fā)現(xiàn)如果執(zhí)行MapReduce，特別是在壓縮文件上執(zhí)行，其對(duì)CPU的消耗較高，CPU成為了瓶頸；而在運(yùn)行Hbase的時(shí)候，更多的內(nèi)存會(huì)緩存更多的數(shù)據(jù)，提高查詢吞吐率并縮短響應(yīng)時(shí)間。所以建議這兩種情況下，可以考慮按照如右表格配比來(lái)配置硬件：,Hbase配置建議,Rowkey設(shè)計(jì)： HBase表的rowkey

22、設(shè)計(jì)，一般是將關(guān)系數(shù)據(jù)庫(kù)中的候選key拼接形成。但是要注意熱點(diǎn)問(wèn)題，比如rowkey開(kāi)始的幾位是時(shí)間排序，那么在插入的時(shí)候，最近幾天的數(shù)據(jù)很可能是熱點(diǎn)數(shù)據(jù)，這樣所有的查詢可能都指向了一個(gè)region server導(dǎo)致了HBase的性能瓶頸。盡量避免使用單調(diào)遞增的rowkey，因?yàn)樵谔砑訑?shù)據(jù)的時(shí)候，所有的新數(shù)據(jù)都添加到最后一個(gè)region，前面的region沒(méi)有或者很少有請(qǐng)求，也是熱點(diǎn)問(wèn)題。 熱點(diǎn)問(wèn)題的處理方式一般是加鹽，即在rowkey前面添加hash數(shù)，來(lái)對(duì)數(shù)據(jù)進(jìn)行hash劃分。 列簇設(shè)計(jì)： HBase表的Column Family最好少于4，一般少于3，對(duì)于一般數(shù)據(jù)放入一個(gè)列簇中即可。對(duì)于

23、一些強(qiáng)關(guān)聯(lián)，頻繁訪問(wèn)的數(shù)據(jù)可以放一列，這樣在取數(shù)據(jù)時(shí)，熱點(diǎn)訪問(wèn)只用取這一列數(shù)據(jù)，可以節(jié)省IO。多個(gè)列簇有各自memstore，memstore 開(kāi)銷大，而且flush一個(gè)列簇，其他的類簇也會(huì)flush，會(huì)造成不必要的開(kāi)銷。 Region劃分： HBase在導(dǎo)入大量數(shù)據(jù)前最好預(yù)先劃分region，這樣可以加快導(dǎo)入效率。同時(shí)也要避免使用HBase自動(dòng)劃分region，在一種情況下，HBase面臨大量寫(xiě)入或者scan請(qǐng)求，同時(shí)它的region中的數(shù)據(jù)又達(dá)到了閥值，那么它會(huì)啟動(dòng)自動(dòng)劃分region，有可能導(dǎo)致region劃分風(fēng)暴，大量的請(qǐng)求會(huì)使region server和name node的壓力過(guò)大而

24、導(dǎo)致region dead或者name node dead。 TTL設(shè)計(jì)： TTL（time to live），它一般可以用來(lái)控制數(shù)據(jù)的生存時(shí)間。一些數(shù)據(jù)比如客戶幾年以前的數(shù)據(jù)，幾年以后已經(jīng)不關(guān)心這些數(shù)據(jù)，可以使用TTL刪除。如果數(shù)據(jù)沒(méi)有這些要求，可以不使用。,目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(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ù)中心系統(tǒng)集成建議,在引入Hadoop和MPP數(shù)據(jù)庫(kù)后，數(shù)據(jù)中心建設(shè)將會(huì)在現(xiàn)有傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)平臺(tái)與新技術(shù)之間形成混搭。經(jīng)典數(shù)據(jù)倉(cāng)庫(kù)中的One Sing

25、le View of Truth將難以維持。主要會(huì)面臨如下的問(wèn)題： 數(shù)據(jù)互通：數(shù)據(jù)需要跨Hadoop和多個(gè)數(shù)據(jù)庫(kù)進(jìn)行交互，如何實(shí)現(xiàn)高效的數(shù)據(jù)同步或數(shù)據(jù)調(diào)用？ 透明訪問(wèn)：是否有必要對(duì)上層應(yīng)用屏蔽底層不同數(shù)據(jù)平臺(tái)的細(xì)節(jié)，提供統(tǒng)一的數(shù)據(jù)訪問(wèn)方式？ 統(tǒng)一管理：如何進(jìn)行多套數(shù)據(jù)平臺(tái)的元數(shù)據(jù)、數(shù)據(jù)質(zhì)量管理，如何實(shí)現(xiàn)統(tǒng)一的調(diào)度和運(yùn)維監(jiān)控？ 數(shù)據(jù)互通機(jī)制是多個(gè)數(shù)據(jù)庫(kù)與Hadoop之間的橋梁。通過(guò)數(shù)據(jù)互通，我們可以將數(shù)據(jù)快速?gòu)囊粋€(gè)平臺(tái)遷移到另外一個(gè)平臺(tái)或從一個(gè)平臺(tái)方便地訪問(wèn)另外一個(gè)平臺(tái)中的數(shù)據(jù)。 數(shù)據(jù)互通機(jī)制的主要難點(diǎn)是要保障數(shù)據(jù)在兩個(gè)平臺(tái)間流轉(zhuǎn)時(shí)的高效性和可靠性。,數(shù)據(jù)中心系統(tǒng)互通的建議,實(shí)現(xiàn)數(shù)據(jù)互通機(jī)制有2

26、種方法：數(shù)據(jù)同步、數(shù)據(jù)調(diào)用 數(shù)據(jù)同步： 數(shù)據(jù)同步的主要是實(shí)現(xiàn)數(shù)據(jù)庫(kù)與Hadoop之間雙向數(shù)據(jù)復(fù)制功能，數(shù)據(jù)同步的目的包括這些的場(chǎng)景：不同系統(tǒng)上的數(shù)據(jù)需要進(jìn)行關(guān)聯(lián)分析、數(shù)據(jù)生命周期管理要求進(jìn)行數(shù)據(jù)歸檔或備份、ETL分節(jié)點(diǎn)部署需要同步數(shù)據(jù)等。 可以采取如下數(shù)據(jù)同步方案： 在Hadoop端發(fā)起的雙向數(shù)據(jù)同步 在數(shù)據(jù)庫(kù)端發(fā)起的雙向數(shù)據(jù)同步 在第三方發(fā)起的雙向數(shù)據(jù)同步 數(shù)據(jù)調(diào)用： 數(shù)據(jù)調(diào)用指的是：不移動(dòng)數(shù)據(jù)，通過(guò)接口調(diào)用實(shí)現(xiàn)對(duì)另外一個(gè)平臺(tái)上數(shù)據(jù)的訪問(wèn)，被調(diào)用平臺(tái)承擔(dān)運(yùn)算任務(wù)。數(shù)據(jù)調(diào)用方法根據(jù)調(diào)用方的不同，又分為“從數(shù)據(jù)庫(kù)側(cè)調(diào)用Hadoop數(shù)據(jù)”及“從Hadoop側(cè)調(diào)用數(shù)據(jù)庫(kù)數(shù)據(jù)”兩種情況。 數(shù)據(jù)調(diào)用方法

27、適用的場(chǎng)景原則：低頻度（如：每月/季度/年一次）或臨時(shí)（如：臨時(shí)訪問(wèn)5次以下）需要使用其他平臺(tái)中存儲(chǔ)的數(shù)據(jù)。,數(shù)據(jù)中心互通的技術(shù)實(shí)現(xiàn),連接器方式 通過(guò)設(shè)計(jì)專用的軟件或硬件連接器模塊，實(shí)現(xiàn)數(shù)據(jù)庫(kù)與Hadoop之間高速的數(shù)據(jù)傳輸，其一般具備以下特點(diǎn)： 雙向連接器 并行連接數(shù)據(jù)庫(kù)節(jié)點(diǎn)到的Hadoop數(shù)據(jù)節(jié)點(diǎn) 支持UTF-8編碼和常見(jiàn)的數(shù)據(jù)類型 通過(guò)動(dòng)態(tài)工作負(fù)載管理的資源控制 融合系統(tǒng)中的角色/用戶提供認(rèn)證 為數(shù)據(jù)庫(kù)域提供的數(shù)據(jù)節(jié)點(diǎn)，主要實(shí)現(xiàn)以下按照源表進(jìn)行任務(wù)分工，可以為表間并行以及表內(nèi)并行 建立分區(qū)、索引及裝載，根據(jù)分區(qū)原則以及索引等策略，裝載節(jié)點(diǎn)將數(shù)據(jù)直接發(fā)送給相應(yīng)的MPP數(shù)據(jù)庫(kù)節(jié)點(diǎn)上 裝載節(jié)點(diǎn)

28、處理過(guò)程中數(shù)據(jù)不落地 裝載節(jié)點(diǎn)可以是MPP數(shù)據(jù)庫(kù)中的部分節(jié)點(diǎn)也可以獨(dú)立設(shè)置 通過(guò)連接器的方式，可以實(shí)現(xiàn)數(shù)據(jù)庫(kù)與Hadoop系統(tǒng)之間的高速和可靠的數(shù)據(jù)互通，非常適合數(shù)據(jù)同步的計(jì)算場(chǎng)景。 外部表方式： 數(shù)據(jù)庫(kù)可以通過(guò)外部表的方式，直接訪問(wèn)存儲(chǔ)在HDFS上的文件。在使用外部表時(shí)，數(shù)據(jù)庫(kù)可以像訪問(wèn)內(nèi)部數(shù)據(jù)一樣，將文件當(dāng)作表insert到數(shù)據(jù)庫(kù)內(nèi)其他表中，或?qū)DFS上的文件和數(shù)據(jù)庫(kù)內(nèi)的表進(jìn)行關(guān)聯(lián)操作。同時(shí)也可以將RDBMS內(nèi)的數(shù)據(jù)，通過(guò)外部表的形式，寫(xiě)入到HDFS上去。例如如下操作: Select count(*) from HDFS_data h, RDBMS_data g where h.key

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

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

31、中心定義,數(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集成工具選型問(wèn)題,這些眾多的BI項(xiàng)目從規(guī)模和對(duì)BI系統(tǒng)支撐的完善程度上來(lái)說(shuō)，大體可以分為Framework、Stand-alone Tools和BI Suite三種類型。 Framework：開(kāi)源框架，這是在商業(yè)BI系統(tǒng)中所沒(méi)有的。我們可以使用它們來(lái)構(gòu)建自己的BI工具，或者增強(qiáng)和擴(kuò)展我們的BI解決方案。 Stand-alone Tools：獨(dú)立的BI工具，這是開(kāi)源項(xiàng)目中數(shù)量最多的一類。很多工具只側(cè)重BI系統(tǒng)中的某個(gè)環(huán)節(jié)和方面，如ETL、Report、

32、OLAP和Database等等。 BI Suite：在統(tǒng)一的架構(gòu)下提供了多種BI系統(tǒng)的特性的工具集合。就目前的情況看，不管是商業(yè)軟件還是開(kāi)源軟件，還沒(méi)有任何一個(gè)套件提供了完整的端到端的BI解決方案。這些開(kāi)源的BI Suit是通過(guò)連接多個(gè)其他的組件和工具的方式形成套件的，由于BI系統(tǒng)涉及到的工具是非常多的，所以整合一套完整的BI解決方案是很困難的。 開(kāi)源BI的重要項(xiàng)目： Pentaho、spagoBi是兩個(gè)比較大的框架，集成了相當(dāng)多的開(kāi)源項(xiàng)目，JfreeReport、Mondrian、Kettle、Weka基本都使用。適合大型復(fù)雜項(xiàng)目的開(kāi)發(fā)。 Pentaho：是一個(gè)以工作流為核心的、強(qiáng)調(diào)面向解決

33、方案而非工具組件的BI套件，整合了多個(gè)開(kāi)源項(xiàng)目，目標(biāo)是和商業(yè)BI相抗衡。 SpagoBI 集成了OLAP ServerMondrain和OLAP展示JProvit，能夠通過(guò)OpenLaszlo產(chǎn)生實(shí)時(shí)報(bào)表。SpagoBI使用java開(kāi)發(fā)，不依賴于具體的操作系統(tǒng)，有很強(qiáng)的擴(kuò)展能力。,開(kāi)源BI工具之Spago BI,SpagoBI 集成了Mondrain和JProvit，能夠通過(guò)OpenLaszlo產(chǎn)生實(shí)時(shí)報(bào)表。SpagoBI使用java開(kāi)發(fā)，不依賴于具體的操作系統(tǒng)，有很強(qiáng)的擴(kuò)展能力。它主要包括： 1、 報(bào)表工具：JasperReports /Eclipse BIRT/ iReport 2、 OL

34、AP Server：Mondrian 3、 OLAP展示：JPivot 4、 數(shù)據(jù)挖掘組件：Weka 5、 Map引擎：Geo 6、 ETL：BIE 7、 搜索引擎：Lucene 8、 Dashboard：OpenLaszlo 9、 Portal Server：JBoss/ Tomcat/ JOnAS,Spago BI展現(xiàn)層也使用了AJAX特性，另外它在DashBoard也使用了openlaszlo，（一個(gè)用Java code 生成Flash的框架，主頁(yè)是/。新版的4.0好像也要支持生成DHTML) 所以spagoBI的DashBoard界面很友

35、好。,開(kāi)源BI工具之Pentaho,Pentaho是一個(gè)以工作流為核心的、強(qiáng)調(diào)面向解決方案而非工具組件的BI套件，整合了多個(gè)開(kāi)源項(xiàng)目，目標(biāo)是和商業(yè)BI相抗衡。它包括如下開(kāi)源組件： 1、 工作流引擎：Shark and JaWE 2、 數(shù)據(jù)庫(kù)：Firebird RDBMS 3、 集成管理和開(kāi)發(fā)環(huán)境：Eclipse 4、 報(bào)表工具：Eclipse BIRT 5、 ETL工具：Enhydra/Kettle 6、 OLAP Server：Mondrian 7、 OLAP展示：JPivot 8、 數(shù)據(jù)挖掘組件：Weka 9、 應(yīng)用服務(wù)器和Portal服務(wù)器：JBoss 10、 單點(diǎn)登陸服務(wù)及LDap認(rèn)證

36、：JOSSO 11、 自定義腳本支持：Mozilla Rhino Javascript腳本處理器,Pentaho是一個(gè)很完善的BI解決方案。Pentaho偏向于與業(yè)務(wù)流程相結(jié)合的BI解決方案，側(cè)重于大中型企業(yè)應(yīng)用。,Pentaho與Spago對(duì)比,From張軼總：目前看Pentaho基本符合我們對(duì)數(shù)據(jù)平臺(tái)功能的要求。其中，Pentaho Data Intergration （PDI）可以用作我們的數(shù)據(jù)平臺(tái)集成，并且其支持與Hadoop及周邊軟件集成。同時(shí)也支持絕大多數(shù)NoSQL。還有，對(duì)于Map/Reduce job也有很好支持。Pentaho Business Analytics （PBA）

37、是一個(gè)數(shù)據(jù)分析、展示平臺(tái)，可以生成報(bào)表，做數(shù)據(jù)可視化，具有數(shù)據(jù)挖掘功能。Pentaho集成了很多第三方開(kāi)源項(xiàng)目，這種集成是無(wú)縫的。Pentaho也有很好的Metadata管理功能。總之，它是一個(gè)很好的BI系統(tǒng)框架且完全開(kāi)源。相信通過(guò)Pentaho，我們可以搭出一個(gè)PoC演示環(huán)境。后續(xù)我們還會(huì)做更進(jìn)一步的研究。,目錄,MPP數(shù)據(jù)庫(kù)在數(shù)據(jù)中心的應(yīng)用,企業(yè)級(jí)數(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ù)和服務(wù)的一種應(yīng)用技術(shù)。它解決無(wú)限

38、的問(wèn)題，解決方案也幾乎沒(méi)有窮盡。目前常見(jiàn)的四種集成風(fēng)格： 1.文件傳輸：兩個(gè)系統(tǒng)生成文件，文件的有效負(fù)載就是由另一個(gè)系統(tǒng)處理的消息。該類風(fēng)格的例子之一是針對(duì)文件輪詢目錄或FTP目錄，并處理該文件。 2.共享數(shù)據(jù)庫(kù)：兩個(gè)系統(tǒng)查詢同一個(gè)數(shù)據(jù)庫(kù)以獲取要傳遞的數(shù)據(jù)。一個(gè)例子是你部署了兩個(gè)EAR應(yīng)用，它們的實(shí)體類（JPA、Hibernate等）共用同一個(gè)表。 3.遠(yuǎn)程過(guò)程調(diào)用：兩個(gè)系統(tǒng)都暴露另一個(gè)能調(diào)用的服務(wù)。該類例子有EJB服務(wù)，或SOAP和REST服務(wù)。 4.消息：兩個(gè)系統(tǒng)連接到一個(gè)公用的消息系統(tǒng)，互相交換數(shù)據(jù)，并利用消息調(diào)用行為。該風(fēng)格的例子就是眾所周知的中心輻射式的（hub-and-spoke）

39、JMS架構(gòu)。 這些風(fēng)格迥然不同，因?yàn)闆](méi)有一種解決辦法能在任何情況下都良好運(yùn)轉(zhuǎn)。這導(dǎo)致整個(gè)中間件領(lǐng)域都在基于這些模式尋求可用的解決辦法，通常被稱為企業(yè)服務(wù)總線（ESB）。ESB是最終的中間人：它知道如何使用各種語(yǔ)言在各種協(xié)議上調(diào)解傳遞的消息。 ESB定義與主要功能： ESB全稱為Enterprise Service Bus，即企業(yè)服務(wù)總線。它是傳統(tǒng)中間件技術(shù)與XML、Web服務(wù)等技術(shù)結(jié)合的產(chǎn)物。ESB提供了網(wǎng)絡(luò)中最基本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。 Invocation同步和異步的傳輸協(xié)議的支持、服務(wù)的定位和綁定 Routing靜態(tài)和動(dòng)態(tài)路由、基于內(nèi)容路由、基于策略路由、基于規(guī)則路由

40、 Mediation適配、協(xié)議轉(zhuǎn)換、服務(wù)映射 Messaging 消息處理、轉(zhuǎn)換、增強(qiáng) Process choreography負(fù)責(zé)業(yè)務(wù)邏輯的實(shí)現(xiàn) Service orchestration服務(wù)編排 Complex event processing事件解釋、事件關(guān)聯(lián)、模式適配 Other quality of service安全、可靠傳輸、事務(wù) Management監(jiān)視、audit、日志、計(jì)量、管理、BAM,ESB實(shí)施探討,不推薦的實(shí)施： 1、用ESB實(shí)現(xiàn)大數(shù)據(jù)傳輸：ESB并不適合完成該項(xiàng)功能，雖然它可以實(shí)現(xiàn)這一功能，但這并非最佳實(shí)踐。ESB作為企業(yè)級(jí)的服務(wù)聯(lián)通、管理平臺(tái)，需要穿透ESB的服務(wù)

41、應(yīng)該是企業(yè)內(nèi)重用可能最大、價(jià)值最大的那些服務(wù)，應(yīng)用程序?qū)@類服務(wù)的訪問(wèn)應(yīng)該非常頻繁，因此同一時(shí)刻需要ESB支撐的業(yè)務(wù)可能非常繁重。所以，ESB產(chǎn)品的設(shè)計(jì)初衷是實(shí)現(xiàn)一個(gè)無(wú)狀態(tài)、高吞吐的服務(wù)總線，為企業(yè)內(nèi)重要的業(yè)務(wù)服務(wù)提供透明、標(biāo)準(zhǔn)、開(kāi)放的接入能力。這種實(shí)踐的原因是過(guò)分放大了ESB對(duì)數(shù)據(jù)的傳輸能力，如果在ESB傳輸巨大的信息，可能會(huì)導(dǎo)致ESB整體性能的下降，損害其他重要服務(wù)的QoS。 2、挾ESB以令外圍應(yīng)用：ESB的架構(gòu)師在ESB上設(shè)計(jì)一套標(biāo)準(zhǔn)的數(shù)據(jù)接口（通用的XML格式），規(guī)定使用統(tǒng)一的協(xié)議（如Web Service/HTTP）。所有的ESB服務(wù)消費(fèi)者和接入ESB的服務(wù)必須符合該標(biāo)準(zhǔn)。其目的是

42、為了簡(jiǎn)化ESB上的開(kāi)發(fā)工作。這就是一種“挾天子以令諸侯”的做法。ESB針對(duì)的是一個(gè)個(gè)功能各異的整合邏輯，服務(wù)之間的整合邏輯也是迥異的。所以，一勞永逸的ESB之上的架構(gòu)是不存在的。 3、用ESB實(shí)現(xiàn)業(yè)務(wù)流程：有些架構(gòu)師看到ESB支持服務(wù)組合（Service Composition）模式，進(jìn)而認(rèn)為可用該模式來(lái)實(shí)現(xiàn)業(yè)務(wù)流程。因此，ESB產(chǎn)品就演變成了BPM產(chǎn)品。讓ESB實(shí)現(xiàn)BPM，特別是長(zhǎng)運(yùn)行的流程時(shí)，雖然在技術(shù)上可以實(shí)現(xiàn)，但是這違背了ESB產(chǎn)品的設(shè)計(jì)理念，會(huì)大大影響其ESB運(yùn)行時(shí)的整體運(yùn)行效率。 推薦的實(shí)施： 1、服務(wù)要管理起來(lái)：ESB的一個(gè)重要功能是將企業(yè)內(nèi)/合作伙伴處的服務(wù)以開(kāi)放的、標(biāo)準(zhǔn)的服務(wù)

43、方式暴露出來(lái)，使得服務(wù)消費(fèi)者能夠便利地查找到服務(wù)，以促進(jìn)服務(wù)的重用、管理。 2、復(fù)雜的動(dòng)態(tài)路由規(guī)則應(yīng)服務(wù)化：路由是ESB中非常重要的仲裁邏輯之一。路由場(chǎng)景是非常普遍的。譬如，針對(duì)不同的客戶提供不同QoS的場(chǎng)景，執(zhí)行時(shí)需根據(jù)客戶的類型將其路由到不同執(zhí)行能力的服務(wù)提供者；再比如當(dāng)響應(yīng)消息到達(dá)ESB時(shí)，總是需要將該響應(yīng)消息送回最初的服務(wù)請(qǐng)求者處。對(duì)于復(fù)雜的路由，推薦將路由規(guī)則的邏輯外部化，并將它服務(wù)化。,開(kāi)源ESB之ServiceMix（SM）,產(chǎn)品簡(jiǎn)介：它是JBI規(guī)范的一種實(shí)現(xiàn)；包含很熟JBI組件。這些組件支持多種協(xié)議，比如JMS,HTTP,FTP,FILE等。同時(shí)也實(shí)現(xiàn)了EIP，規(guī)則和調(diào)度。SM也整合了其他的開(kāi)源項(xiàng)目，比如Apache、ActiveMQ CXF,Apahe Camel,Apache ODE以及Apache Geronimo。 優(yōu)點(diǎn)： 1、無(wú)縫集成CXF,ActiveMQ,Camel和ODE，因?yàn)镾erviceMix,ActiveMQ,CXF,Camel都是FUSE的開(kāi)源產(chǎn)品 2、JBI的優(yōu)勢(shì)，組件BC,SE可以在任何JBI容器中直接運(yùn)行，復(fù)用性強(qiáng) 3、基于OSGi，具備OSGi的優(yōu)勢(shì)：模塊化，熱部署，易擴(kuò)展 缺點(diǎn)： 1、基于JBI但JBI規(guī)范太復(fù)雜，已被主流中間件廠商拋棄,沒(méi)有受到業(yè)界的青睞，前途未卜。 2、架構(gòu)復(fù)雜，由于JBI的復(fù)雜性所致，其架構(gòu)并非