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

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

根據企業構建數據倉庫的主要應用場景不同，我們可以將數據倉庫分為以下四種類型，每一種類型的數據倉庫系統都有不同的技術指標與要求。
傳統數據倉庫

圖1：傳統數據倉庫的架構

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

實時處理數據倉庫

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

關聯發現數據倉庫

在一些場景下，企業可能不知道數據的內聯規則，而是需要通過數據挖掘的方式找出數據之間的關聯關系，隱藏的聯系和模式等，從而挖掘出數據的價值。很多行業的新業務都有這方面的需求，如金融行業的風險控制，反欺詐等業務。上下文無關聯的數據倉庫一般需要在架構設計上支持數據挖掘能力，并提供通用的算法接口來操作數據。

數據集市

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

數據倉庫架構的挑戰

到了移動互聯時代，傳統架構的數據倉庫遇到了非常多的挑戰，因此也需要對它的架構做更多的一些演變。

首先最大的問題是數據增長速度非常迅速，導致原有的數據倉庫在處理這些數據存在架構上的問題，無法通過業務層面的優化來解決。譬如，一個省級農信社的數據審計類的數據通常在十幾TB，現有基于關系數據庫或者MPP的數據倉庫方案已經無法處理這么大數據，亟需一種新的更強計算能力的架構設計來解決問題。
其次，隨著業務的發展，數據源的類型也越來越多。很多行業的非結構化數據的產生速度非常快，使用傳統Oracle/DB2的數據倉庫并不能很好的處理這些非結構化數據，往往需要額外構建一些系統作為補充。

再次，在一家比較大的企業內部，因為業務不同企業內部可能會有幾百個數據庫，各自建設方案也不同，沒有一個簡單的辦法將數據統一到一個數據平臺上。因此需要一個數據庫虛擬化技術，能夠通過有效的方式將各個數據庫統一化，有效的進行數據分析和批處理。而在過去，這個技術并不存在。

最后，過去的數據庫沒有提供搜索和數據挖掘的能力，而這些需求已經是企業的剛需。譬如金融行業需要使用復雜的數據挖掘方法代替傳統的規則引擎來做風險控制，而這無法在基于關系數據庫的方案中得到解決。隨著Hadoop以及Spark技術的快速成熟，基于Hadoop/Spark的數據倉庫解決方案能有效的解決這些問題和挑戰。

基于大數據的數據倉庫關鍵技術

圖2：基于Hadoop的數據倉庫架構設計

上圖是一個典型的基于Hadoop的數據倉庫的架構設計。

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

其次就是幾個不同的應用的場景，通過資源管理層動態分配出來的邏輯集群。各個業務集群獲取模型層加工的數據，并結合自身的業務使用相關的數據，同時各個業務之間也可以通過數據庫聯邦等技術在計算中共享數據。這類業務包含各種查詢與檢索業務，數據集市以及關聯發現數據倉庫。

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

因此，基于Hadoop的解決方案能夠用一套系統實現企業對傳統數據倉庫，實時處理數據倉庫，關聯發現數據倉庫以及數據集市的需求，并通過邏輯劃分的方法使用一套資源來實現，無需多個項目重復建設。

從技術層面上，現有的一些SQL on Hadoop引擎（如SparkSQL，CDH等）能夠部分實現數據倉庫的需求，但是離完整覆蓋還有一些距離。一些關鍵的技術特點必須實現突破，才能符合企業的數據倉庫建設的業務指標。主要有以下技術指標：

分布式計算引擎

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

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

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

標準化的編程模型

目前大部分在生產的數據倉庫是基于關系數據庫或者MPP數據庫來實現的，一般系統規模都比較大，代碼量級是數萬到數十萬行SQL或者存儲過程。SQL 99是數據倉庫領域的事實標準編程模型，因此支持SQL 99標準是大數據平臺構建數據倉庫的必備技術，而如果能夠支持一些常見的SQL模塊化擴展（如Oracle PL/SQL, DB2 SQL PL）等，將非常有利于企業將數據倉庫系統從原有架構上平滑遷移到基于Hadoop的方案上來。使用非標準化的編程模型，會導致數據倉庫實際建設的成本和風險無法控制。

數據操作方式的多樣性

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

數據一致性保證

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

OLAP交互式統計分析能力

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

一些開源項目嘗試通過額外的存儲構建Cube來加速HBase中數據的統計分析能力，不過存在構建成本高，易出錯，不能支持Ad-Hoc查詢等問題，此外需要提高穩定性滿足商業上的需求。

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

多類型數據的處理能力

在大數據系統中，結構化數據和非結構化數據的比例在2:8左右，文檔，影像資料，協議文件，以及一些專用的數據格式等在內的非結構化數據在企業業務中非常重要，大數據平臺需要提供存儲和快速檢索的能力。

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

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

實時計算與企業數據總線

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

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

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

Database Federation

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

在這一領域有兩個流派，傳統的數據廠商希望用自己的SQL引擎來覆蓋Hadoop，把Hadoop隱藏在他們的引擎下面，這種方式沒有把計算完全分布出來。另外一種策略是利用Hadoop的SQL引擎來覆蓋原來的關聯數據，使原來的關聯數據庫能夠與Hadoop作為同一種數據源來進行完全分布式的計算。這種方式會更符合未來的技術趨勢，分布式計算，擴展性增強。

數據探索與挖掘能力

企業經營經常需要做出預測性分析，但預測的準確率卻都保持在低水平。這由兩大方面原因造成，一方面是因為過去分析的數據都是采樣數據，沒有大規模的軟件系統來存放數據，也無法對大的數據進行分析。另一方面是計算的模型過于簡單，計算能力遠遠不夠，無法進行復雜大規模的計算分析，這使得過去的預測都相當不準確。

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

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

安全性和權限管理

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

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

混合負載管理

統一的數據倉庫平臺需要能夠支持混合工作負載的管理方式，能夠對多個租戶進行資源的配額，同時也能實現資源共享，閑置資源分給其他客戶，并且也能支持搶占。其次，它還需要能夠支持資源和數據的隔離性，使多個租戶之間互不干擾。再者，它需要具備能力把批處理任務和實時任務分開處理，對一些實時任務進行優化，從而可以支持多用戶多部門多種混合復雜的應用場景。

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

微服務架構

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

對未來的展望

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

數據平臺市場每年創造的價值巨大，但大部分被Oracle、IBM、Teradata等國外巨頭瓜分。因此我們希望更多的國內同行能夠投入到基于Hadoop的數據倉庫平臺的研發之中，打造出大數據時代的杰出數據倉庫產品，擺脫國外巨頭對這個行業的壟斷，幫助中國科技在企業服務領域實現質的突破。

轉載于:https://www.cnblogs.com/davidwang456/articles/9731682.html

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。