http://www.uspeed.com.cn/958.html

數(shù)據(jù)倉庫是企業(yè)統(tǒng)一的數(shù)據(jù)管理的方式，將不同的應(yīng)用中的數(shù)據(jù)匯聚，然后對這些數(shù)據(jù)加工和多維度分析，并最終展現(xiàn)給用戶。它幫助企業(yè)將紛繁浩雜的數(shù)據(jù)整合加工，并最終轉(zhuǎn)換為關(guān)鍵流程上的KPI，從而為決策/管理等提供最準(zhǔn)確的支持，并幫助預(yù)測發(fā)展趨勢。因此，數(shù)據(jù)倉庫是企業(yè)IT系統(tǒng)中非常核心的系統(tǒng)。

根據(jù)企業(yè)構(gòu)建數(shù)據(jù)倉庫的主要應(yīng)用場景不同，我們可以將數(shù)據(jù)倉庫分為以下四種類型，每一種類型的數(shù)據(jù)倉庫系統(tǒng)都有不同的技術(shù)指標(biāo)與要求。
傳統(tǒng)數(shù)據(jù)倉庫

圖1：傳統(tǒng)數(shù)據(jù)倉庫的架構(gòu)

企業(yè)會把數(shù)據(jù)分成內(nèi)部數(shù)據(jù)和外部數(shù)據(jù)，內(nèi)部數(shù)據(jù)通常分為兩類，OLTP交易系統(tǒng)以及OLAP分析系統(tǒng)數(shù)據(jù)，他們會把這些數(shù)據(jù)全部集中起來，經(jīng)過轉(zhuǎn)換放到數(shù)據(jù)庫當(dāng)中，這些數(shù)據(jù)庫通常是Teradata、Oracle、DB2數(shù)據(jù)庫等。然后在這上面對數(shù)據(jù)進(jìn)行加工，建立各種主題模型，再提供報表分析業(yè)務(wù)。一般來說，數(shù)據(jù)的處理和加工是通過離線的批處理來完成的，通過各種應(yīng)用模型實(shí)現(xiàn)具體的報表加工。

實(shí)時處理數(shù)據(jù)倉庫

隨著業(yè)務(wù)的發(fā)展，一些企業(yè)客戶需要對一些實(shí)時的數(shù)據(jù)做一些商業(yè)分析，譬如零售行業(yè)需要根據(jù)實(shí)時的銷售數(shù)據(jù)來調(diào)整庫存和生產(chǎn)計(jì)劃，風(fēng)電企業(yè)需要處理實(shí)時的傳感器數(shù)據(jù)來排查故障以保障電力的生產(chǎn)等。這類行業(yè)用戶對數(shù)據(jù)的實(shí)時性要求很高，傳統(tǒng)的離線批處理的方式不能滿足需求，因此他們需要構(gòu)建實(shí)時處理的數(shù)據(jù)倉庫。數(shù)據(jù)可以通過各種方式完成采集，然后數(shù)據(jù)倉庫可以在指定的時間窗口內(nèi)對數(shù)據(jù)進(jìn)行處理，事件觸發(fā)和統(tǒng)計(jì)分析等工作，再將數(shù)據(jù)存入數(shù)據(jù)倉庫以滿足其他一些其他業(yè)務(wù)的需求。因此，實(shí)時數(shù)據(jù)倉庫增強(qiáng)了對實(shí)時性數(shù)據(jù)的處理能力要求，也要求系統(tǒng)的架構(gòu)在技術(shù)層面上需要革命性的調(diào)整。

關(guān)聯(lián)發(fā)現(xiàn)數(shù)據(jù)倉庫

在一些場景下，企業(yè)可能不知道數(shù)據(jù)的內(nèi)聯(lián)規(guī)則，而是需要通過數(shù)據(jù)挖掘的方式找出數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，隱藏的聯(lián)系和模式等，從而挖掘出數(shù)據(jù)的價值。很多行業(yè)的新業(yè)務(wù)都有這方面的需求，如金融行業(yè)的風(fēng)險控制，反欺詐等業(yè)務(wù)。上下文無關(guān)聯(lián)的數(shù)據(jù)倉庫一般需要在架構(gòu)設(shè)計(jì)上支持?jǐn)?shù)據(jù)挖掘能力，并提供通用的算法接口來操作數(shù)據(jù)。

數(shù)據(jù)集市

數(shù)據(jù)集市一般是用于某一類功能需求的數(shù)據(jù)倉庫的簡單模式，往往是由一些業(yè)務(wù)部門構(gòu)建，也可以構(gòu)建在企業(yè)數(shù)據(jù)倉庫上。一般來說數(shù)據(jù)源比較少，但往往對數(shù)據(jù)分析的延時有很高的要求，并需要和各種報表工具有很好的對接。

數(shù)據(jù)倉庫架構(gòu)的挑戰(zhàn)

到了移動互聯(lián)時代，傳統(tǒng)架構(gòu)的數(shù)據(jù)倉庫遇到了非常多的挑戰(zhàn)，因此也需要對它的架構(gòu)做更多的一些演變。

首先最大的問題是數(shù)據(jù)增長速度非常迅速，導(dǎo)致原有的數(shù)據(jù)倉庫在處理這些數(shù)據(jù)存在架構(gòu)上的問題，無法通過業(yè)務(wù)層面的優(yōu)化來解決。譬如，一個省級農(nóng)信社的數(shù)據(jù)審計(jì)類的數(shù)據(jù)通常在十幾TB，現(xiàn)有基于關(guān)系數(shù)據(jù)庫或者M(jìn)PP的數(shù)據(jù)倉庫方案已經(jīng)無法處理這么大數(shù)據(jù)，亟需一種新的更強(qiáng)計(jì)算能力的架構(gòu)設(shè)計(jì)來解決問題。
其次，隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)源的類型也越來越多。很多行業(yè)的非結(jié)構(gòu)化數(shù)據(jù)的產(chǎn)生速度非常快，使用傳統(tǒng)Oracle/DB2的數(shù)據(jù)倉庫并不能很好的處理這些非結(jié)構(gòu)化數(shù)據(jù)，往往需要額外構(gòu)建一些系統(tǒng)作為補(bǔ)充。

再次，在一家比較大的企業(yè)內(nèi)部，因?yàn)闃I(yè)務(wù)不同企業(yè)內(nèi)部可能會有幾百個數(shù)據(jù)庫，各自建設(shè)方案也不同，沒有一個簡單的辦法將數(shù)據(jù)統(tǒng)一到一個數(shù)據(jù)平臺上。因此需要一個數(shù)據(jù)庫虛擬化技術(shù)，能夠通過有效的方式將各個數(shù)據(jù)庫統(tǒng)一化，有效的進(jìn)行數(shù)據(jù)分析和批處理。而在過去，這個技術(shù)并不存在。

最后，過去的數(shù)據(jù)庫沒有提供搜索和數(shù)據(jù)挖掘的能力，而這些需求已經(jīng)是企業(yè)的剛需。譬如金融行業(yè)需要使用復(fù)雜的數(shù)據(jù)挖掘方法代替?zhèn)鹘y(tǒng)的規(guī)則引擎來做風(fēng)險控制，而這無法在基于關(guān)系數(shù)據(jù)庫的方案中得到解決。隨著Hadoop以及Spark技術(shù)的快速成熟，基于Hadoop/Spark的數(shù)據(jù)倉庫解決方案能有效的解決這些問題和挑戰(zhàn)。

基于大數(shù)據(jù)的數(shù)據(jù)倉庫關(guān)鍵技術(shù)

圖2：基于Hadoop的數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)

上圖是一個典型的基于Hadoop的數(shù)據(jù)倉庫的架構(gòu)設(shè)計(jì)。

首先有一個傳統(tǒng)數(shù)據(jù)倉庫層，它包含一個集中的數(shù)據(jù)存儲平臺，以及元數(shù)據(jù)管理，數(shù)據(jù)稽查和數(shù)據(jù)處理的工作調(diào)度層。數(shù)據(jù)存儲平臺包含多種數(shù)據(jù)源，有結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。結(jié)構(gòu)化數(shù)據(jù)的處理分為三層，按照數(shù)據(jù)模型分成貼源層、基礎(chǔ)明細(xì)層和公共主題模型層，數(shù)據(jù)加工業(yè)務(wù)按照模型進(jìn)行切分成不同的批處理業(yè)務(wù)，通過分布式計(jì)算引擎來執(zhí)行離線的批處理計(jì)算。同時為了滿足多個模型層的業(yè)務(wù)需求，有一個統(tǒng)一的資源調(diào)度層和工作流調(diào)度系統(tǒng)，保證每個業(yè)務(wù)能夠得到給定配額的資源，確保資源分配的合理性和有效性。

其次就是幾個不同的應(yīng)用的場景，通過資源管理層動態(tài)分配出來的邏輯集群。各個業(yè)務(wù)集群獲取模型層加工的數(shù)據(jù)，并結(jié)合自身的業(yè)務(wù)使用相關(guān)的數(shù)據(jù)，同時各個業(yè)務(wù)之間也可以通過數(shù)據(jù)庫聯(lián)邦等技術(shù)在計(jì)算中共享數(shù)據(jù)。這類業(yè)務(wù)包含各種查詢與檢索業(yè)務(wù)，數(shù)據(jù)集市以及關(guān)聯(lián)發(fā)現(xiàn)數(shù)據(jù)倉庫。

此外，上述方案還包括一個實(shí)時處理數(shù)據(jù)倉庫。實(shí)時的數(shù)據(jù)源通過消息隊(duì)列傳入系統(tǒng)，按照數(shù)據(jù)的時間戳進(jìn)行基于時間窗口的數(shù)據(jù)處理，如進(jìn)行一些實(shí)時窗口上的數(shù)據(jù)統(tǒng)計(jì)，基于規(guī)則引擎的數(shù)據(jù)處理，甚至是數(shù)據(jù)挖掘模型的預(yù)測等。經(jīng)過處理后的數(shù)據(jù)統(tǒng)一輸入企業(yè)數(shù)據(jù)總線，其他邏輯數(shù)據(jù)倉庫通過訂閱服務(wù)獲取相關(guān)數(shù)據(jù)。如數(shù)據(jù)集市可以從總線下訂閱窗口數(shù)據(jù)直接插入內(nèi)存后者SSD中，從而可以對這部分?jǐn)?shù)據(jù)做實(shí)時的統(tǒng)計(jì)分析。此外，其他的應(yīng)用也可以在企業(yè)數(shù)據(jù)總線上訂閱相關(guān)的數(shù)據(jù)，從而實(shí)時的獲取業(yè)務(wù)需要的數(shù)據(jù)。

因此，基于Hadoop的解決方案能夠用一套系統(tǒng)實(shí)現(xiàn)企業(yè)對傳統(tǒng)數(shù)據(jù)倉庫，實(shí)時處理數(shù)據(jù)倉庫，關(guān)聯(lián)發(fā)現(xiàn)數(shù)據(jù)倉庫以及數(shù)據(jù)集市的需求，并通過邏輯劃分的方法使用一套資源來實(shí)現(xiàn)，無需多個項(xiàng)目重復(fù)建設(shè)。

從技術(shù)層面上，現(xiàn)有的一些SQL on Hadoop引擎（如SparkSQL，CDH等）能夠部分實(shí)現(xiàn)數(shù)據(jù)倉庫的需求，但是離完整覆蓋還有一些距離。一些關(guān)鍵的技術(shù)特點(diǎn)必須實(shí)現(xiàn)突破，才能符合企業(yè)的數(shù)據(jù)倉庫建設(shè)的業(yè)務(wù)指標(biāo)。主要有以下技術(shù)指標(biāo)：

分布式計(jì)算引擎

基于關(guān)系數(shù)據(jù)庫的數(shù)據(jù)倉庫一個最大的痛點(diǎn)在于計(jì)算和處理能力不足，當(dāng)數(shù)據(jù)量到達(dá)TB量級后完全無法工作。因此，分布式的計(jì)算引擎是保證新數(shù)據(jù)倉庫建設(shè)的首要關(guān)鍵因素。這個分布式引擎必須具備以下特點(diǎn)：

健壯穩(wěn)定，必須能夠7*24小時運(yùn)行高負(fù)載業(yè)務(wù)
高可擴(kuò)展性，能夠隨著硬件資源的增加帶來處理能力的線性增長
處理能力強(qiáng)，能夠處理從GB到幾百TB量級的復(fù)雜SQL業(yè)務(wù)
目前開源的Map Reduce計(jì)算引擎滿足健壯穩(wěn)定和高可擴(kuò)展性特點(diǎn)，但是處理能力很弱，無法有效的滿足企業(yè)的性能需求；Spark在最近幾年迅速發(fā)展，處理能力和擴(kuò)展性都不錯，但是在穩(wěn)定性和健壯性方面還存在問題；其他一些SQL on Hadoop方案如Flink還處在發(fā)展的早期，還不適合商用。MPP的方案都存在一些可擴(kuò)展性的問題，當(dāng)數(shù)據(jù)量很大的情況下（如100TB級別）無法通過硬件資源的增加來解決，只能處理特定數(shù)據(jù)量級別的需求。

因此從技術(shù)選擇的角度，Spark引擎如果能夠有效的解決穩(wěn)定性和健壯性問題，是分布式計(jì)算引擎的最佳選擇。

標(biāo)準(zhǔn)化的編程模型

目前大部分在生產(chǎn)的數(shù)據(jù)倉庫是基于關(guān)系數(shù)據(jù)庫或者M(jìn)PP數(shù)據(jù)庫來實(shí)現(xiàn)的，一般系統(tǒng)規(guī)模都比較大，代碼量級是數(shù)萬到數(shù)十萬行SQL或者存儲過程。SQL 99是數(shù)據(jù)倉庫領(lǐng)域的事實(shí)標(biāo)準(zhǔn)編程模型，因此支持SQL 99標(biāo)準(zhǔn)是大數(shù)據(jù)平臺構(gòu)建數(shù)據(jù)倉庫的必備技術(shù)，而如果能夠支持一些常見的SQL模塊化擴(kuò)展（如Oracle PL/SQL, DB2 SQL PL）等，將非常有利于企業(yè)將數(shù)據(jù)倉庫系統(tǒng)從原有架構(gòu)上平滑遷移到基于Hadoop的方案上來。使用非標(biāo)準(zhǔn)化的編程模型，會導(dǎo)致數(shù)據(jù)倉庫實(shí)際建設(shè)的成本和風(fēng)險無法控制。

數(shù)據(jù)操作方式的多樣性

不同模型的數(shù)據(jù)加工過程要求平臺具備多種數(shù)據(jù)操作的方式，可能是從某一文件或者數(shù)據(jù)庫插入數(shù)據(jù)，也可能是用某些增量數(shù)據(jù)來修改或者更新某一報表等等。因此數(shù)據(jù)平臺需要提供多種方式的數(shù)據(jù)操作，譬如能通過SQL的INSERT/UPDATE/DELETE/MERGE等DML來操作數(shù)據(jù)，或者能夠從文件或者消息隊(duì)列等數(shù)據(jù)源來加載源數(shù)據(jù)等。同時，這些操作必須支持高并發(fā)和高吞吐量的場景，否則無法滿足多個業(yè)務(wù)同時服務(wù)的需求。

數(shù)據(jù)一致性保證

在各個模型層的數(shù)據(jù)加工過程中，數(shù)據(jù)表可能會有多種數(shù)據(jù)源同時來加工。以某銀行的貼源層為例，一個銀行的某個總數(shù)據(jù)表可能同時被各個分行的數(shù)據(jù)，以及外部數(shù)據(jù)源（如央行數(shù)據(jù)）來加工。做并發(fā)的對統(tǒng)一數(shù)據(jù)源加工的過程中，數(shù)據(jù)的一致性必須得到保障。因此，基于大數(shù)據(jù)平臺的數(shù)據(jù)倉庫也必須提供事務(wù)的保證，確保數(shù)據(jù)的修改操作滿足一致性，持久性，完整性和原子性等特點(diǎn)。

OLAP交互式統(tǒng)計(jì)分析能力

對于數(shù)據(jù)集市類的應(yīng)用，用戶對于報表的生成速度和延時比較敏感，一般要求延時在10秒以內(nèi)。傳統(tǒng)的數(shù)據(jù)倉庫需要配合一些BI工具，將一些報表提前通過計(jì)算生成，因此需要額外的計(jì)算和存儲空間，并且受限于內(nèi)存大小，能夠處理的報表存在容量限制，因此不能完全適用于大數(shù)據(jù)的應(yīng)用場景。

一些開源項(xiàng)目嘗試通過額外的存儲構(gòu)建Cube來加速HBase中數(shù)據(jù)的統(tǒng)計(jì)分析能力，不過存在構(gòu)建成本高，易出錯，不能支持Ad-Hoc查詢等問題，此外需要提高穩(wěn)定性滿足商業(yè)上的需求。

另外一些商業(yè)公司開始提供基于內(nèi)存或者SSD的交互式統(tǒng)計(jì)分析的解決方案，通過將數(shù)據(jù)直接建立在SSD或者內(nèi)存里，并通過內(nèi)置索引，Cube等方式加速大數(shù)據(jù)量上統(tǒng)計(jì)分析速度，能夠在10秒內(nèi)完成十億行級別的數(shù)據(jù)統(tǒng)計(jì)分析工作。這種方案通用性更強(qiáng)，且支持Ad-Hoc查詢，是更合理的解決方案。

多類型數(shù)據(jù)的處理能力

在大數(shù)據(jù)系統(tǒng)中，結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)的比例在2:8左右，文檔，影像資料，協(xié)議文件，以及一些專用的數(shù)據(jù)格式等在內(nèi)的非結(jié)構(gòu)化數(shù)據(jù)在企業(yè)業(yè)務(wù)中非常重要，大數(shù)據(jù)平臺需要提供存儲和快速檢索的能力。

開源HBase提供MOB技術(shù)來存儲和檢索非結(jié)構(gòu)化數(shù)據(jù)，基本可以滿足及本地的圖像、文檔類數(shù)據(jù)的檢索，但是也存在一些問題，如Split操作IO成本很高，不支持Store File的過濾等；此外不能很好支持JSON/XML等常用數(shù)據(jù)文件的操作也是一個缺點(diǎn)。另外一些數(shù)據(jù)庫如MongoDB對JSON等的支持非常好，但是對視頻影像類非結(jié)構(gòu)化數(shù)據(jù)支持不夠好。

一個可行的技術(shù)方案是在HBase等類似方案中增加對JSON/XML的原生編碼和解碼支持，通過SQL層進(jìn)行計(jì)算；同時改變大對象在HBase中的存儲方式，將split級別從region級別降低到column family級別來減少IO成本等優(yōu)化方式，來提供更有效的大對象的處理能力。

實(shí)時計(jì)算與企業(yè)數(shù)據(jù)總線

實(shí)時計(jì)算是構(gòu)建實(shí)時處理數(shù)據(jù)倉庫的基本要求，也是企業(yè)各種新業(yè)務(wù)的關(guān)鍵。以銀行業(yè)信貸為例，以前的信貸流程是業(yè)務(wù)人員在客戶申請后去工商、司法等部門去申請征信數(shù)據(jù)后評分，周期長效率低。而如果采用實(shí)時數(shù)據(jù)倉庫的方案，每個客戶請求進(jìn)入企業(yè)數(shù)據(jù)總線后，總線上的相關(guān)的微服務(wù)就可以實(shí)時的去接入征信、司法、工商等數(shù)據(jù)，通過總線上的一些挖掘算法對客戶進(jìn)行評分，再進(jìn)入信貸系統(tǒng)后就已經(jīng)完成了必要的評分和信貸額度的計(jì)算等工作，業(yè)務(wù)人員只需要根據(jù)這些數(shù)據(jù)來做最終的審批，整體的流程幾乎可以做到實(shí)時，極大的簡化流程和提高效率。

Spark Streaming和Storm都是不錯的實(shí)時計(jì)算框架，相比較而言，Spark Streaming可擴(kuò)展性更佳，此外如果分布式引擎使用Spark的話，還可以實(shí)現(xiàn)引擎和資源共享。因此我們更加推薦使用Spark Streaming來構(gòu)建實(shí)時計(jì)算框架。目前開源的Spark Streaming存在一些穩(wěn)定性問題，需要有一些產(chǎn)品化的改造和打磨，或者可以選擇一些商業(yè)化的Spark Streaming版本。

實(shí)時計(jì)算的編程模型是另外一個重要問題，目前Spark Streaming或者Storm還主要是通過API來編程，而不是企業(yè)常用的SQL，因此很多的線下業(yè)務(wù)無法遷移到流式計(jì)算平臺上。從應(yīng)用開發(fā)角度，提供SQL開發(fā)實(shí)時計(jì)算應(yīng)用也是構(gòu)建實(shí)時數(shù)據(jù)倉庫的一個重要因素。目前一些商業(yè)化的平臺已經(jīng)具備通過SQL開發(fā)實(shí)時計(jì)算應(yīng)用的能力。

Database Federation

由于企業(yè)內(nèi)部存在很多套系統(tǒng)，加上一些數(shù)據(jù)敏感等原因，不可能所有的數(shù)據(jù)都可以匯總到數(shù)據(jù)倉庫里面，因此Database Federation技術(shù)在很多場景下就是必須的功能。Database Federation技術(shù)讓平臺可以穿透到各個數(shù)據(jù)源，在計(jì)算過程中把數(shù)據(jù)從其他數(shù)據(jù)源中拉到集群當(dāng)中來進(jìn)行分布式計(jì)算，同時也把常見的數(shù)據(jù)源所具備的特性推到數(shù)據(jù)源中，減少數(shù)據(jù)的傳輸量。一推一拉，使得其性能表現(xiàn)的十分顯著，對多重?cái)?shù)據(jù)源進(jìn)行交叉分析。

在這一領(lǐng)域有兩個流派，傳統(tǒng)的數(shù)據(jù)廠商希望用自己的SQL引擎來覆蓋Hadoop，把Hadoop隱藏在他們的引擎下面，這種方式?jīng)]有把計(jì)算完全分布出來。另外一種策略是利用Hadoop的SQL引擎來覆蓋原來的關(guān)聯(lián)數(shù)據(jù)，使原來的關(guān)聯(lián)數(shù)據(jù)庫能夠與Hadoop作為同一種數(shù)據(jù)源來進(jìn)行完全分布式的計(jì)算。這種方式會更符合未來的技術(shù)趨勢，分布式計(jì)算，擴(kuò)展性增強(qiáng)。

數(shù)據(jù)探索與挖掘能力

企業(yè)經(jīng)營經(jīng)常需要做出預(yù)測性分析，但預(yù)測的準(zhǔn)確率卻都保持在低水平。這由兩大方面原因造成，一方面是因?yàn)檫^去分析的數(shù)據(jù)都是采樣數(shù)據(jù)，沒有大規(guī)模的軟件系統(tǒng)來存放數(shù)據(jù)，也無法對大的數(shù)據(jù)進(jìn)行分析。另一方面是計(jì)算的模型過于簡單，計(jì)算能力遠(yuǎn)遠(yuǎn)不夠，無法進(jìn)行復(fù)雜大規(guī)模的計(jì)算分析，這使得過去的預(yù)測都相當(dāng)不準(zhǔn)確。

除此以外，做預(yù)測性分析還應(yīng)具備三方面特征，要具有完成的工具。第一個工具就是要有完整的特征抽取的方式，從大量的數(shù)據(jù)當(dāng)中找出特征。即使在今天擁有工具的條件下，也仍然需要人來識別這些特征，做特征抽取。第二個是要有分布式機(jī)器學(xué)習(xí)的算法。目前，這種算法的數(shù)量仍然不夠全面，我們需要有更完整的機(jī)器學(xué)習(xí)算法的列表。第三點(diǎn)是我們要有應(yīng)用的工具來幫我們建造一個完整的機(jī)器學(xué)習(xí)算法的pipeline，從而更方便的做出分析。

目前市場上有多種數(shù)據(jù)挖掘的解決方案和開發(fā)商，主要分成兩類：以提供模型和可視化編程為主的方案，如SAS；以及以提供算法和標(biāo)準(zhǔn)化開發(fā)接口為主的方案，如Spark MlLib等。圖形化的方案在開發(fā)商更容易，但是這些系統(tǒng)多數(shù)和Hadoop的兼容比較差，需要有專用系統(tǒng)。而類似Spark Mllib的方案能更好的和大數(shù)據(jù)結(jié)合，以及比較多的被工業(yè)界接受。

安全性和權(quán)限管理

數(shù)據(jù)的安全重要性無須贅述，安全問題在最近幾年已經(jīng)上升到國家層面。對于大數(shù)據(jù)平臺，基于LDAP協(xié)議的訪問控制和基于Kerberos的安全認(rèn)證技術(shù)是比較通用的解決方案。

此外，數(shù)據(jù)的權(quán)限管理目前在Hadoop業(yè)界還處于完善階段，應(yīng)該提供一套基于SQL的數(shù)據(jù)庫/表的權(quán)限控制，管理員可以設(shè)置用戶對表的查詢，修改，刪除等權(quán)限，并包含一整套的角色設(shè)定，可以通過角色組的設(shè)置來便捷的實(shí)現(xiàn)用戶權(quán)限控制。此外，一些應(yīng)用場合需要提供對表的精確行級別控制。

混合負(fù)載管理

統(tǒng)一的數(shù)據(jù)倉庫平臺需要能夠支持混合工作負(fù)載的管理方式，能夠?qū)Χ鄠€租戶進(jìn)行資源的配額，同時也能實(shí)現(xiàn)資源共享，閑置資源分給其他客戶，并且也能支持搶占。其次，它還需要能夠支持資源和數(shù)據(jù)的隔離性，使多個租戶之間互不干擾。再者，它需要具備能力把批處理任務(wù)和實(shí)時任務(wù)分開處理，對一些實(shí)時任務(wù)進(jìn)行優(yōu)化，從而可以支持多用戶多部門多種混合復(fù)雜的應(yīng)用場景。

利用容器技術(shù)可以有效的實(shí)現(xiàn)資源和數(shù)據(jù)的隔離性，再加上一個資源調(diào)度框架，可以實(shí)現(xiàn)工作負(fù)載和租戶資源的配置。目前這個領(lǐng)域是創(chuàng)新的熱點(diǎn)，涌現(xiàn)了很多解決方案，大概也有幾個流派，一種是基于Mesosphere的技術(shù)路線，讓Hadoop的應(yīng)用可以在Mesosphere資源框架上運(yùn)行。這個方案的弱點(diǎn)首先是不具備通用性，所有的大數(shù)據(jù)和數(shù)據(jù)庫的框架都需要定制和改造，無法標(biāo)準(zhǔn)化。第二個弱點(diǎn)在于隔離性太弱。另外一種是使用Kubernetes + Docker的方式，所有應(yīng)用容器化，由Kubernetes提供資源調(diào)度和多租戶管理，因此更加標(biāo)準(zhǔn)化，方便統(tǒng)一化部署和運(yùn)維，目前我們認(rèn)為是更好的解決方案。

微服務(wù)架構(gòu)

隨著平臺技術(shù)的進(jìn)步，應(yīng)用系統(tǒng)的設(shè)計(jì)也將發(fā)生重大變化。以前一套系統(tǒng)包括前端、中間件、數(shù)據(jù)庫都多個模塊，系統(tǒng)耦合性高，構(gòu)建復(fù)雜。未來的數(shù)據(jù)倉庫上的應(yīng)用系統(tǒng)可以微服務(wù)化，所有的功能由小的服務(wù)模塊組建的，依靠依賴性讓系統(tǒng)自動把應(yīng)用打包集裝，極大地促進(jìn)了應(yīng)用遷移的便捷性。有了這樣一個系統(tǒng)之后，我們可以輕易的建造有幾萬個容器組成的應(yīng)用系統(tǒng)，在上面可以運(yùn)行幾千個應(yīng)用，它的擴(kuò)展性可以在幾分鐘之內(nèi)擴(kuò)展到上千容器的規(guī)模。同時，它的資源隔離性也很好，滿足對多租戶的要求，進(jìn)行資源的隔離、共享、搶占。

對未來的展望

這篇文章介紹了數(shù)據(jù)倉庫的一些特性，以及構(gòu)建基于Hadoop的數(shù)據(jù)倉庫的關(guān)鍵技術(shù)。隨著近年來大數(shù)據(jù)技術(shù)的高速演變，我們預(yù)計(jì)未來三年當(dāng)中數(shù)據(jù)庫以及數(shù)據(jù)倉庫技術(shù)會發(fā)生的巨大變化。正如Gartner所預(yù)計(jì)的，我們的大部分企業(yè)客戶會把數(shù)據(jù)倉庫從以前的傳統(tǒng)數(shù)據(jù)倉庫轉(zhuǎn)移到邏輯數(shù)據(jù)倉庫中，Hadoop在其中會扮演非常重要的角色，很多企業(yè)應(yīng)用也已經(jīng)開始把Hadoop作為數(shù)據(jù)倉庫的重要組成部分。2016年2月Gartner即將發(fā)布數(shù)據(jù)倉庫的魔力象限，屆時可以看到Hadoop技術(shù)作為數(shù)據(jù)倉庫的技術(shù)方案被市場的接受程度。

數(shù)據(jù)平臺市場每年創(chuàng)造的價值巨大，但大部分被Oracle、IBM、Teradata等國外巨頭瓜分。因此我們希望更多的國內(nèi)同行能夠投入到基于Hadoop的數(shù)據(jù)倉庫平臺的研發(fā)之中，打造出大數(shù)據(jù)時代的杰出數(shù)據(jù)倉庫產(chǎn)品，擺脫國外巨頭對這個行業(yè)的壟斷，幫助中國科技在企業(yè)服務(wù)領(lǐng)域?qū)崿F(xiàn)質(zhì)的突破。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9731682.html

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的基于SQL on Hadoop的数据仓库技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。