資料倉儲、資料集市、資料湖，你的企業更適合哪種資料管理架構？

建設企業級資料平臺，首先需要了解企業資料，確認管理需求，並選擇一個資料管理架構。那麼面對紛繁複雜的資料來源，多元化的資料結構，以及他們的管理使用需求，企業資料平臺建設該從何處入手呢？哪個資料管理架構適合自己的企業呢？本篇將介紹資料倉儲、資料集市、資料湖。

—  資料倉儲（Data Warehouse） —

資料倉儲是Bill Inmon在1991年出版的“Building the Data Warehouse”一書中所提出的定義被廣泛接受：資料倉儲（Data Warehouse）是一個面向主題的（Subject Oriented）、整合的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的資料集合，用於支援管理決策（Decision Making Support）。

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

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

• 企業資料倉儲

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

 

• 實時資料倉儲

隨著業務的發展，一些企業客戶需要對一些實時的資料做一些商業分析，譬如零售行業需要根據實時的銷售資料來調整庫存和生產計劃，風電企業需要處理實時的感測器資料來排查故障以保障電力的生產等。這類行業使用者對資料的實時性要求很高，傳統的離線批處理的方式不能滿足需求，因此他們需要構建實時處理的資料倉儲。資料可以透過各種方式完成採集，然後資料倉儲可以在指定的時間視窗內對資料進行處理，事件觸發和統計分析等工作，再將資料存入資料倉儲以滿足其他一些其他業務的需求。因此，實時資料倉儲增強了對實時性資料的處理能力要求，核心的計算引擎需要基於實時計算平臺，如開源的Flink或星環科技自研的Slipstream，透過實時引擎來對接機器學習、視覺化分析和實時排程類應用。

—  資料集市（Data Mart ） —

資料集市是一個有針對性的資料倉儲版本，它包含一個較小的資料子集，這些資料對組織內的單個團隊或選定使用者組很重要且是必需的。由於資料集市包含較小的資料子集，因此在使用更廣泛的資料倉儲資料集時，資料集市使部門或業務線能夠更快地發現更有針對性的洞察。最初建立資料集市的目的是應對組織在20世紀90年代建立資料倉儲的困難。當時整合來自整個組織的資料需要進行大量手動編碼，而且非常耗時。與集中式資料倉儲相比， 資料集市的範圍更有限，使其實現起來更容易且更快速。到了大資料時代，雖然企業資料倉儲和資料湖在各個企業都已經普及，但是每個部門自身也有對業務資料進行處理分析統計的需求，而且不涉及到和其他資料互動，因此特定的部門不希望在資料量大的資料倉儲進行操作（因為操作慢，而且可能影響到其他人處理資料），所以建立一個新的儲存系統，把資料倉儲裡關聯自己的資料儲存到這個系統，本質上算是資料倉儲的一個子集。這個系統叫做資料集市。

相比較資料倉儲，由於資料集市涉及的資料來源集中於某個部門或者業務線的主體，因此其處理的資料會小很多，業務構建比較敏捷，對使用者需求的響應也會更加迅速。 對集市的使用者來說，由於僅開放給某個部門或業務主體，其對多租戶隔離的需求也不是很強，使用者可以更加簡單方便的獲取資料，可以簡單的透過資料包表工具或Excel等工具來做資料分析，因此對基礎設施的依賴就相對比較低，建設成本也相對更低。此外，對集市的實施人員來說，涉及到要加工處理的資料比較少，資料加工時間會短很多，安全管理的要求也比較低，因此建設和運維相對更低。總體上說，因為資料集市都是集中在某個單一的業務領域，對實施人員和業務使用者來說都比較敏捷和靈活。

按照集市和資料倉儲或資料庫的關係，資料集市也可以分為三種型別：

• 獨立資料集市 ：  獨立的資料集市系統，不依賴資料倉儲或資料湖，一般直接從資料來源系統載入必要的資料做加工後按照業務主體提供業務分析結果；

 

•   關聯資料集市： 是資料倉儲或資料湖的一個部分，一般對應資料倉儲的資料集市層，相關的資料加工處理由資料倉儲的批處理任務完成；

 

• 混合資料集市：  主題資料的來源包括了資料倉儲、資料湖，也包括了其他的資料庫。這種集市的好處是既能包含企業自頂而下設計的從資料倉儲中加工而來的業務主題資料，又能滿足自下而上的一線分析師的靈活提出的業務需求。

 資料集市的底層一般是一個獨立的資料庫，並且一般提供高併發的統計分析和檢索服務，因此對資料庫的併發計算效能要求比較高。為了保證資料集市的併發效能，關鍵技術包括這兩種：一是資料庫層採用支援高併發訪問的分散式資料庫來支撐，二是採用OLAP Cube技術。

分散式資料庫由於其可擴充套件效能的優勢，能夠支撐更高併發的連線訪問，並且分散式計算引擎的統計分析SQL的效能更強，還可以透過增加硬體資源來擴充套件效能，因此針對一些使用者規模較大、或者BI報表涉及的報表計算非常複雜的部門或業務線，可以採用分散式資料庫。

OLAP Cube技術是將一些資料建模結果預先計算出來，這樣分析人員使用資料的時候就可以靈活的做各種深入分析，如資料下鑽、切片等，就可以透過預計算的資料來訪問，而無需去查詢底層資料庫或重新計算資料，因此如果訪問資料能夠命中Cube，業務的併發訪問效能將得到極大的提升。OLAP Cube本身是採用空間換時間的最佳化策略，它需要使用者來指定預計算的schema，此外Cube建模工具會有最佳化方法來減少需要持久化的Cube資料，從而減少預計算需要的處理時間和儲存空間。OLAP Cube技術根據其持久化資料的方式又分為ROLAP和MOLAP，簡單理解ROLAP是將建模的Cube資料持久化在資料庫中，而MOLAP一般是將Cube資料持久化在報表工具或建模工具中。

—  資料湖（Data Lake） —

資料湖是一種企業資料架構的實現方式，在物理實現上是一個儲存庫， 允許使用者以任意規模儲存所有結構化和非結構化資料，並支援對資料進行快速加工和分析。使用者可以按原樣儲存資料（無需先對資料進行結構化處理），並執行不同型別的分析（從控制皮膚和視覺化到大資料處理、實時分析和機器學習，以指導做出更好的決策。

最初建立資料湖的目的是 應對資料倉儲無法處理數量、速度和種類不斷增加的大資料的情況。雖然資料湖比資料倉儲慢，但它們的價格也更低廉，因為在採集之前幾乎不需要資料準備。 與資料倉儲或資料集市不同的是， 資料湖上儲存原始資料，通常為PB級別，一般沒有複雜的業務建模，主要做一些基礎的資料治理或者基礎性的模型建設工作， 更多的為企業內部提供一個公共的資料儲存和探索能力，併為下游的集市、倉庫或者中臺提供資料與計算能力。很多企業會同時建設資料湖和資料倉儲，從而保證更好的資料架構與使用者體驗。

資料湖支援廣泛的用例，因為在收集資料時不需要定義資料的業務目標。 資料湖可以儲存結構化和非結構化資料，這種靈活的儲存需求對於資料科學家、資料工程師和開發人員尤其有用，讓他們能夠訪問資料 進行資料發現練習和機器學習專案。資料科學家可以使用資料湖進行概念驗證。機器學習應用程式可以從能夠在 同一個地方儲存結構化和非結構化資料中受益，這是使用關聯式資料庫系統無法實現的。資料湖也可以 用於測試和開發大資料分析專案。當應用程式開發完成並識別出有用資料後，可以將資料匯出到資料倉儲以供操作使用，並且可以利用自動化來實現應用程式擴充套件。資料湖還可以 用於資料備份和恢復，因為它們能夠 以低成本進行擴充套件。資料湖非常 適合儲存尚未定義業務需求的“以備不時之需”資料，現在儲存這些資料意味著可以在以後出現新計劃時使用。

從實現方式上看，目前Hadoop是最常用的部署資料湖的技術，也有采用MPP+Hadoop的混合架構，近年也有一些基於公有云儲存的資料湖方案出現和落地。

為了滿足多樣化的資料儲存與分析的需求，在資料湖的建設中， 我們需要設計確保落地後的資料湖具備以下4個關鍵能力：

• 資料整合能力

資料湖需要提供相關的工具或能力，可以整合包括各種關聯式資料庫儲存的結構化資料，以及從各個其他渠道（包括網際網路、內部文件、感測器）等收集和儲存非結構化資料，並且具備多樣化的資料整合策略，包括實時、準實時、離線整合等，允許整合過程中的資料轉換等能力。

• 資料計算能力

由於資料湖中積累了企業內部的多樣化的資料，因為使用者可以打通內部各種資料，從而分析其中的資料規律，從而進一步指導和預測分析。因此，資料湖需要給使用者提供強大的資料計算能力，能夠快速地從海量資料中檢索到關鍵資訊，或是能夠做大量資料的碰撞找到關聯關係，或是對非結構化資料進行深度的識別分析等，這些都需要資料湖的平臺提供完善的資料計算能力。

• 資料治理能力

由於資料湖中彙集了原始資料，未做複雜的資料模型加工，因此可能存在湖內的資料本身有較多質量問題的情況，或者各個資料來源頭的標準不統一，因此不能很好地用於指導資料分析業務。因此，資料湖的建設者需要提供工具或計算能力給使用者，可以在資料湖內做進一步的資料治理，從而提高資料質量和價值。

• 資料服務能力

資料湖在設計的時候，需要充分考慮如何提供給更多的資料需求者來自助服務，使用者可以在資料湖上發現資料、分析資料、改進資料以及最終貢獻資料，從而形成一個從資料到價值鏈路的閉環。在這個過程中，有效的資料資產目錄可以有效地幫助使用者來打通資料鏈路，而多租戶服務能力是核心的技術要求。

 除了以上4個核心的功能性需求以外，還需要關注一些 重要的非功能性需求，包括：

• 互操作性

資料湖本身需要跟企業內部的各個資料系統有很好的互操作性，因此資料整合的工具或系統需要有良好的連線互通性，可以與關聯式資料庫、NoSQL、實時資料系統、企業級物件儲存等各個系統建立高效的資料互動通道。

• 有效的成本控制

由於資料湖本身的特點，儲存的資料量一般比較大，資料價值密度低，因此需要非常關注本身的成本控制，總體方案上需要較低的硬體成本和運維成本，以及較好的資源使用效率，有較好的彈性伸縮，能夠支援計量計費等。

• 多租戶

資料湖一般會開放給企業內多個部門或組織共用，而每個使用者本身執行的業務各自有特殊性，譬如機器學習的任務計算複雜度高，CPU消耗大，而檢索類任務磁碟IO密集使用，面向多個使用者同時提供服務，如果要保證使用者體驗，資料湖底層需要提供良好的資源共享與隔離能力。

• 業務連續性

此外，高可用與災備能力也是資料湖的一個關鍵要素，在技術的設計上需要充分考慮相關的技術要求，從而實現極端故障下的業務快速恢復能力。

—  小結 —

本篇介紹了資料倉儲、資料集市、資料庫等資料管理架構。那麼對於平臺建設落地，該如何根據企業數字化程度，建立一個可持續演進技術架構呢？在接下來的幾篇中，我們將根據企業數字化程度，分五個階段來介紹。下一篇：儲存與算力基礎建設