基于SQL on Hadoop的數(shù)據(jù)倉庫技術(shù)

1、基于SQL on Hadoop 的數(shù)據(jù)倉庫技術(shù)數(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ù)倉庫 傳統(tǒng)數(shù)據(jù)倉庫 交易系統(tǒng)以及OLAP 分析系統(tǒng)數(shù)據(jù)，他們會把這些數(shù)據(jù)全部集中起來， 數(shù)據(jù)庫等。然后在這上面對數(shù)據(jù)進(jìn)行加工，建立各種主題模型，再提供 報表分析業(yè)務(wù)。一般來說，數(shù)據(jù)的處理和加工是通過離線的批處理來完 成的，通過各種應(yīng)用模型實(shí)現(xiàn)具體的報表加工。實(shí)時處理數(shù)據(jù)倉庫 業(yè)需要處理實(shí)時的傳感器數(shù)據(jù)

2、來排查故障以保障電力的生產(chǎn)等。這類行 務(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è)務(wù)。上下文無關(guān)聯(lián)的數(shù)據(jù)倉庫一般需要在架構(gòu)設(shè)計上 支持?jǐn)?shù)據(jù)挖掘能力，并提供通用的算法接口來操作數(shù)據(jù)。數(shù)據(jù)集市 較少，但往往對數(shù)據(jù)分析的延時有很高的要求，并需要和各種報表工具 數(shù)據(jù)倉庫架構(gòu)的挑戰(zhàn) 需要對它的架構(gòu)做更多的一些演變。 這些數(shù)據(jù)存在架構(gòu)上的問題，無法通過業(yè)務(wù)層面的優(yōu)化來解決。譬如， 一個省級農(nóng)信社的數(shù)據(jù)審計類的數(shù)據(jù)通常在十幾TB，現(xiàn)有基于關(guān)系數(shù) 據(jù)庫或者M(jìn)PP 的數(shù)據(jù)倉庫方案已經(jīng)無法處理這么大數(shù)據(jù)，亟需一種新

3、 的更強(qiáng)計算能力的架構(gòu)設(shè)計來解決問題。其次，隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)源的類型也越來越多。很多行業(yè)的非結(jié)構(gòu) 化數(shù)據(jù)的產(chǎn)生速度非?？欤褂脗鹘y(tǒng)Oracle/DB2 的數(shù)據(jù)倉庫并不能很 好的處理這些非結(jié)構(gòu)化數(shù)據(jù)，往往需要額外構(gòu)建一些系統(tǒng)作為補(bǔ)充。 將各個數(shù)據(jù)庫統(tǒng)一化，有效的進(jìn)行數(shù)據(jù)分析和批處理。而在過去，這個 倉庫解決方案能有效的解決這些問題和挑戰(zhàn)?；诖髷?shù)據(jù)的數(shù)據(jù)倉庫關(guān)鍵技術(shù) 上圖是一個典型的基于Hadoop 的數(shù)據(jù)倉庫的架構(gòu)設(shè)計。 數(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ù)的處理分為三層， 源，確保資源分配的合理性和有效性。 此外，

4、上述方案還包括一個實(shí)時處理數(shù)據(jù)倉庫。實(shí)時的數(shù)據(jù)源通過消息 窗口數(shù)據(jù)直接插入內(nèi)存后者SSD 中，從而可以對這部分?jǐn)?shù)據(jù)做實(shí)時的 從而實(shí)時的獲取業(yè)務(wù)需要的數(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)數(shù)據(jù)倉庫的需求，但是離完整覆蓋還有一些距離。一分布式計算引擎基于關(guān)系數(shù)據(jù)庫的數(shù)據(jù)倉庫一個最大的痛點(diǎn)在于計算和處理能力不足，當(dāng)數(shù)據(jù)量到達(dá)TB 量級后完全無法工作。因此，分布式的計算引擎是保健壯穩(wěn)定，必須能夠7*24 小時運(yùn)行高負(fù)載業(yè)務(wù)高可擴(kuò)展性，能夠隨著硬件資源的增加帶來處理能力的線性增長處理能力強(qiáng)，能夠處

5、理從GB 到幾百TB 量級的復(fù)雜SQL業(yè)務(wù) 大的情況下（如100TB 級別）無法通過硬件資源的增加來解決，只能 處理特定數(shù)據(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 或者 99 標(biāo)準(zhǔn)是大數(shù)據(jù)平臺構(gòu)建數(shù)據(jù)倉庫的必備技術(shù)，而如果能夠支持一些 常有利于企業(yè)將數(shù)據(jù)倉庫系統(tǒng)從原有架構(gòu)上平滑遷移到基于Hadoop 的 數(shù)據(jù)操作方式的多樣性 或者能夠從文件或者消息隊(duì)列等數(shù)據(jù)源來加載源數(shù)據(jù)等。同時，這些操 數(shù)據(jù)一致性保證 分行的數(shù)據(jù)，以及外部數(shù)據(jù)源（如央行數(shù)據(jù)

6、）來加工。做并發(fā)的對統(tǒng)一 數(shù)據(jù)源加工的過程中，數(shù)據(jù)的一致性必須得到保障。因此，基于大數(shù)據(jù) 性，持久性，完整性和原子性等特點(diǎn)。OLAP 交互式統(tǒng)計分析能力 一些開源項(xiàng)目嘗試通過額外的存儲構(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)置索引， 多類型數(shù)據(jù)的處理能力 影像資料，協(xié)議文件，以及一些專用的數(shù)據(jù)格式等在內(nèi)的非結(jié)構(gòu)化數(shù)據(jù) 在企業(yè)業(yè)務(wù)中非常重要，大數(shù)據(jù)平臺需要提供存

7、儲和快速檢索的能力。開源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)行計算；同時改變大對象在HBase 減少IO 成本等優(yōu)化方式，來提供更有效的大對象的處理能力。實(shí)時計算與企業(yè)數(shù)據(jù)總

8、線 關(guān)鍵。以銀行業(yè)信貸為例，以前的信貸流程是業(yè)務(wù)人員在客戶申請后去 工商、司法等部門去申請征信數(shù)據(jù)后評分，周期長效率低。而如果采用 關(guān)的微服務(wù)就可以實(shí)時的去接入征信、司法、工商等數(shù)據(jù)，通過總線上 Spark Streaming和Storm 都是不錯的實(shí)時計算框架，相比較而言， 還可以實(shí)現(xiàn)引擎和資源共享。因此我們更加推薦使用Spark Streaming Storm 還主要是通過API來編程，而不是企業(yè)常用的SQL，因此很多 的線下業(yè)務(wù)無法遷移到流式計算平臺上。從應(yīng)用開發(fā)角度，提供SQL 業(yè)化的平臺已經(jīng)具備通過SQL 開發(fā)實(shí)時計算應(yīng)用的能力。 的數(shù)據(jù)都可以匯總到數(shù)據(jù)倉庫里面，因此Database

9、 Federation技術(shù)在 進(jìn)行分布式計算，同時也把常見的數(shù)據(jù)源所具備的特性推到數(shù)據(jù)源中， 減少數(shù)據(jù)的傳輸量。一推一拉，使得其性能表現(xiàn)的十分顯著，對多重數(shù) 在這一領(lǐng)域有兩個流派，傳統(tǒng)的數(shù)據(jù)廠商希望用自己的SQL 引擎來覆 蓋Hadoop，把Hadoop 隱藏在他們的引擎下面，這種方式?jīng)]有把計算 完全分布出來。另外一種策略是利用Hadoop 的SQL 引擎來覆蓋原來 數(shù)據(jù)探索與挖掘能力 這由兩大方面原因造成，一方面是因?yàn)檫^去分析的數(shù)據(jù)都是采樣數(shù)據(jù)，沒有大規(guī)模的軟件系統(tǒng)來存放數(shù)據(jù)，也無法對大的數(shù)據(jù)進(jìn)行分析。另一 的計算分析，這使得過去的預(yù)測都相當(dāng)不準(zhǔn)確。除此以外，做預(yù)測性分析還應(yīng)具備三方面特征，

10、要具有完成的工具。第 即使在今天擁有工具的條件下，也仍然需要人來識別這些特征，做特征 抽取。第二個是要有分布式機(jī)器學(xué)習(xí)的算法。目前，這種算法的數(shù)量仍 要有應(yīng)用的工具來幫我們建造一個完整的機(jī)器學(xué)習(xí)算法的pipeline，從 安全性和權(quán)限管理 對于大數(shù)據(jù)平臺，基于LDAP 協(xié)議的訪問控制和基于Kerberos 的安全 認(rèn)證技術(shù)是比較通用的解決方案。 一套基于SQL 的數(shù)據(jù)庫/表的權(quán)限控制，管理員可以設(shè)置用戶對表的查 詢，修改，刪除等權(quán)限，并包含一整套的角色設(shè)定，可以通過角色組的 混合負(fù)載管理 使多個租戶之間互不干擾。再者，它需要具備能力把批處理任務(wù)和實(shí)時 任務(wù)分開處理，對一些實(shí)時任務(wù)進(jìn)行優(yōu)化，從而可以支持多用戶多部門 多種混合復(fù)雜的應(yīng)用場景。 熱點(diǎn)，涌現(xiàn)了很多解決方案，大概也有幾個流派，一種是基于 據(jù)庫的框架都需要定制和改造，無法標(biāo)準(zhǔn)化。第二個弱點(diǎn)在于隔離性太 由Kubernetes 提供資源調(diào)度和多租戶管理，因此更加標(biāo)準(zhǔn)化，方便統(tǒng) 一化部署和運(yùn)維，目前我們認(rèn)為是更好的解決方案。微服務(wù)架構(gòu) 統(tǒng)包括前端、中間件、數(shù)據(jù)庫都多個模塊，系統(tǒng)耦合性高，構(gòu)建復(fù)雜。 塊組建的，依靠依賴性讓系統(tǒng)自動把應(yīng)用打包集裝，極大地促進(jìn)了應(yīng)用 容器組成的應(yīng)用系統(tǒng)，在上面可以運(yùn)行幾千個應(yīng)用，它的擴(kuò)展性可以在 幾分鐘之內(nèi)擴(kuò)展到上千容器的規(guī)模。同時，它的資源隔離性也很好，滿 足對多租戶的要求，進(jìn)行