//基于SQL on Hadoop的數(shù)據(jù)倉庫技術(shù)
Transwarp - 新聞詳情
http://www.transwarp.io/news/detail?id=131

//由星環(huán)大數(shù)據(jù)產(chǎn)品剖析基于SQL on Hadoop的數(shù)據(jù)倉庫技術(shù)
Transwarp - 新聞詳情
http://www.transwarp.io/news/detail?id=153

數(shù)據(jù)倉庫簡介

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

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

傳統(tǒng)數(shù)據(jù)倉庫

企業(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ù)庫當中，這些數(shù)據(jù)庫通常是Teradata、Oracle窘面、DB2數(shù)據(jù)庫等翠语。然后在這上面進行數(shù)據(jù)的加工，建立各種主題模型财边，再提供報表分析業(yè)務肌括。一般來說，數(shù)據(jù)的處理和加工是通過離線的批處理來完成的酣难，通過各種應用模型實現(xiàn)具體的報表加工谍夭。

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

隨著業(yè)務的發(fā)展，一些企業(yè)客戶需要對一些實時的數(shù)據(jù)做一些商業(yè)分析憨募，譬如零售行業(yè)需要根據(jù)實時的銷售數(shù)據(jù)來調(diào)整庫存和生產(chǎn)計劃紧索，風電企業(yè)需要處理實時的傳感器數(shù)據(jù)來排查故障以保障電力的生產(chǎn)等。這類行業(yè)用戶對數(shù)據(jù)的實時性要求很高菜谣，傳統(tǒng)的離線批處理的方式不能滿足需求齐板，因此他們需要構(gòu)建實時處理的數(shù)據(jù)倉庫。數(shù)據(jù)可以通過各種方式完成采集葛菇，然后數(shù)據(jù)倉庫可以在指定的時間窗口內(nèi)對數(shù)據(jù)進行處理，事件觸發(fā)和統(tǒng)計分析等工作橡羞，再將數(shù)據(jù)存入數(shù)據(jù)倉庫以滿足其他一些其他業(yè)務的需求眯停。因此，實時數(shù)據(jù)倉庫增強了對實時性數(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è)務都有這方面的需求措拇，如金融行業(yè)的風險控制，反欺詐等業(yè)務慎宾。上下文無關(guān)聯(lián)的數(shù)據(jù)倉庫一般需要在架構(gòu)設(shè)計上支持數(shù)據(jù)挖掘能力丐吓，并提供通用的算法接口來操作數(shù)據(jù)。

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

數(shù)據(jù)集市一般是用于某一類功能需求的數(shù)據(jù)倉庫的簡單模式趟据，往往是由一些業(yè)務部門構(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ù)增長速度非常迅速，導致原有的數(shù)據(jù)倉庫在處理這些數(shù)據(jù)存在架構(gòu)上的問題枷莉，無法通過業(yè)務層面的優(yōu)化來解決娇昙。譬如一個省級農(nóng)信社的數(shù)據(jù)審計類的數(shù)據(jù)通常在十幾TB，現(xiàn)有基于關(guān)系數(shù)據(jù)庫或者MPP的數(shù)據(jù)倉庫方案已經(jīng)無法處理這么大數(shù)據(jù)笤妙，亟需一種新的更強計算能力的架構(gòu)設(shè)計來解決問題冒掌。

其次，隨著業(yè)務的發(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)作為補充。

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

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

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

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

首先有一個傳統(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ǔ)明細層和公共主題模型層窑多，數(shù)據(jù)加工業(yè)務按照模型進行切分成不同的批處理業(yè)務，通過分布式計算引擎來執(zhí)行離線的批處理計算洼滚。同時為了滿足多個模型層的業(yè)務需求埂息，有一個統(tǒng)一的資源調(diào)度層和工作流調(diào)度系統(tǒng)，保證每個業(yè)務能夠得到給定配額的資源遥巴，確保資源分配的合理性和有效性千康。

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

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

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

從技術(shù)層面上疏橄，現(xiàn)有的一些SQL on Hadoop引擎（如SparkSQL占拍，CDH等）能夠部分實現(xiàn)數(shù)據(jù)倉庫的需求略就，但是離完整覆蓋還有一些距離。一些關(guān)鍵的技術(shù)特點必須實現(xiàn)突破晃酒，才能符合企業(yè)的數(shù)據(jù)倉庫建設(shè)的業(yè)務指標表牢。主要有以下技術(shù)指標：
分布式計算引擎

基于關(guān)系數(shù)據(jù)庫的數(shù)據(jù)倉庫一個最大的痛點在于計算和處理能力不足，當數(shù)據(jù)量到達TB量級后完全無法工作贝次。因此崔兴，分布式的計算引擎是保證新數(shù)據(jù)倉庫建設(shè)的首要關(guān)鍵因素。這個分布式引擎必須具備以下特點：
健壯穩(wěn)定蛔翅，必須能夠7*24小時運行高負載業(yè)務
高可擴展性敲茄，能夠隨著硬件資源的增加帶來處理能力的線性增長
處理能力強，能夠處理從GB到幾百TB量級的復雜SQL業(yè)務

目前開源的Map Reduce計算引擎滿足健壯穩(wěn)定和高可擴展性特點搁宾，但是處理能力很弱折汞，無法有效的滿足企業(yè)的性能需求；Spark在最近幾年迅速發(fā)展盖腿，處理能力和擴展性都不錯爽待，但是在穩(wěn)定性和健壯性方面還存在問題；其他一些SQL on Hadoop方案如Flink還處在發(fā)展的早期翩腐，還不適合商用鸟款。MPP的方案都存在一些可擴展性的問題，當數(shù)據(jù)量很大的情況下（如100TB級別）無法通過硬件資源的增加來解決茂卦，只能處理特定數(shù)據(jù)量級別的需求何什。

因此從技術(shù)選擇的角度，Spark引擎如果能夠有效的解決穩(wěn)定性和健壯性問題等龙，是分布式計算引擎的最佳選擇处渣。星環(huán)科技自研的Spark引擎已經(jīng)有效的解決穩(wěn)定性方面問題，已經(jīng)在100多個商業(yè)項目中實際生產(chǎn)蛛砰，也證明選擇Spark進行產(chǎn)品化是一個行之有效的方法罐栈。

標準化的編程模型

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

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

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

數(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ù)倉庫也必須提供事務的保證两波，確保數(shù)據(jù)的修改操作滿足一致性瞳步，持久性，完整性和原子性等特點腰奋。

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

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

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

另外一些商業(yè)公司開始提供基于內(nèi)存或者SSD的交互式統(tǒng)計分析的解決方案藕帜，通過將數(shù)據(jù)直接建立在SSD或者內(nèi)存里，并通過內(nèi)置索引惜傲，Cube等方式加速大數(shù)據(jù)量上統(tǒng)計分析速度洽故，能夠在10秒內(nèi)完成十億行級別的數(shù)據(jù)統(tǒ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è)務中非常重要咽扇，大數(shù)據(jù)平臺需要提供存儲和快速檢索的能力。

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

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

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

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

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

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

Database Federation

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

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

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

企業(yè)經(jīng)營經(jīng)常需要做出預測性分析，但預測的準確率卻都保持在低水平覆山。這由兩大方面原因造成竹伸，一方面是因為過去分析的數(shù)據(jù)都是采樣數(shù)據(jù)泥栖，沒有大規(guī)模的軟件系統(tǒng)來存放數(shù)據(jù)簇宽，也無法對大的數(shù)據(jù)進行分析勋篓。另一方面是計算的模型過于簡單，計算能力遠遠不夠魏割，無法進行復雜大規(guī)模的計算分析譬嚣，這使得過去的預測都相當不準確。

除此以外钞它，做預測性分析還應具備三方面特征拜银，要具有完成的工具。第一個工具就是要有完整的特征抽取的方式遭垛，從大量的數(shù)據(jù)當中找出特征尼桶。即使在今天擁有工具的條件下，也仍然需要人來識別這些特征锯仪，做特征抽取泵督。第二個是要有分布式機器學習的算法。目前庶喜，這種算法的數(shù)量仍然不夠全面小腊，我們需要有更完整的機器學習算法的列表。第三點是我們要有應用的工具來幫我們建造一個完整的機器學習算法的pipeline久窟，從而更方便的做出分析秩冈。

目前市場上有多種數(shù)據(jù)挖掘的解決方案和開發(fā)商，主要分成兩類：以提供模型和可視化編程為主的方案斥扛，如SAS入问；以及以提供算法和標準化開發(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的安全認證技術(shù)是比較通用的解決方案张肾。

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

混合負載管理

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

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

微服務架構(gòu)

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

對未來的展望

這篇文章介紹了數(shù)據(jù)倉庫的一些特性恶座，以及構(gòu)建基于Hadoop的數(shù)據(jù)倉庫的關(guān)鍵技術(shù)。隨著近年來大數(shù)據(jù)技術(shù)的高速演變沥阳，我們預計未來三年當中數(shù)據(jù)庫以及數(shù)據(jù)倉庫技術(shù)會發(fā)生的巨大變化跨琳。正如Gartner所預計的，我們的大部分企業(yè)客戶會把數(shù)據(jù)倉庫從以前的傳統(tǒng)數(shù)據(jù)倉庫轉(zhuǎn)移到邏輯數(shù)據(jù)倉庫中桐罕，Hadoop在其中會扮演非常重要的角色脉让，很多企業(yè)應用也已經(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è)服務領(lǐng)域?qū)崿F(xiàn)質(zhì)的突破眶掌。