大數據平臺上的數據倉庫是許多組織正在探索的標準用例。采用這種方法的原因可能是大數據平臺提供的許多靈活性之一。

• 適用于企業范圍分析的大數據-許多組織正在轉變為擁有數據中心或數據湖的概念，在該數據中心或數據湖中，數據是根據源系統而不是基于項目或基于主題領域的數據倉庫來收集和存儲的。該方法的優點是可以根據需要隨時進行市場改造和設計。
• 成本-Hadoop已成為便宜的替代存儲介質。
• 更快的分析-大數據平臺或Hadoop通用的大數據別名可以處理傳統的批處理系統以及近乎實時的決策支持(從數據交付到采取行動所需的時間為2秒至2分鐘)或接近實際時間事件處理(從數據傳送到執行此操作所花費的時間，從100毫秒到2秒)
• 傳統倉庫無法支持的異構數據源
• 高數據量-關系數據庫無法處理的海量數據
• 數據探索的靈活性-希望發現/探索以前未充分利用或未使用的數據

該頁面顯示了一種方法，可以將傳統倉庫轉換為BigData平臺上的倉庫。由于Hadoop生態系統非常廣泛，并且生態系統內可用的技術范圍很廣，因此很難選擇在用例中必須使用哪種工具。但是，另一方面，這提供了靈活性，可以根據用例和其他考慮因素(例如性能，操作和支持等)來嘗試工具。

該演示將利用HDFS和Hive等Hadoop堆棧上可用的開源技術。

HDFS-是Hadoop的核心，這是一個分布式文件系統，它使Hadoop可以完成所有的任務。還有許多其他分布式文件系統，例如Amazon S3，但是當我們談論Hadoop HDFS時，它就是文件系統的代名詞。像Cloudera，IBM BigInsights，Hortonworks等大多數Hadoop營銷供應商都將HDFS用作其文件系統。

Hive -Hive是一個Apache項目，它將數據庫，表和SQL的概念引入了大數據世界。蜂巢正在進行中。Hive使用HDFS來存儲數據。Hive不僅為文件系統增加了SQL的靈活性，還用于HDFS的元數據存儲。元數據存儲庫不過是一個數據庫，它存儲有關HDFS中存儲的文件，文件結構，分區，存儲區，序列化，讀取和寫入文件所需的反序列化等信息。這將使Hive能夠基于存儲在其中的元數據查詢文件蜂巢元商店。綜上所述，Hive為文件提供了數據抽象和數據發現層。

“ Hive的性能如何”

Hive的性能基于許多因素。它包括關系數據庫世界中通常遵循的最佳實踐，它們具有優化的性能以及諸如文件存儲，壓縮技術等Hadoop注意事項。為簡化起見，讓我們檢查在Hive上運行查詢時會發生什么。

1. 通過UI提交給Hive的查詢
2. Hive驅動程序-在執行和獲取模型上工作
3. Hive的編譯器讀取元存儲，并獲取讀取和寫入文件所需的表詳細信息，結構，序列化和反序列化等信息。編譯器隨后創建執行計劃。遵循已建立的DBMS Hive的足跡，使用基于成本的執行(也提供基于規則和相關性優化器)。它會根據每次操作的成本生成一個包含多個階段的計劃。
4. Hive的執行引擎執行由編譯器創建的計劃。它計劃和管理不同階段之間的依賴關系。每個階段不過是Hadoop的map and reduce操作“ MapReduce”。各個階段的輸出被寫入臨時文件，并由后續階段使用。最后階段的輸出將寫入表的文件位置。

綜觀以上執行模式，Hive表可以通過多種方式進行設計以優化性能。但是每種方法各有利弊。考慮到需求的優先級，必須做出決定。

數據存儲選項

1. 文件格式 -Hadoop支持多種文件格式選項。文件可以存儲為平面文件，Hadoop支持的序列文件，其他復雜但選項豐富的格式，例如ORC，RC，Parquet等。Hive支持上述所有存儲格式。但是，也應該考慮對該數據的其他訪問技術。如果Hive是唯一的訪問選項，則任何存儲都可以使用。這將確保更快的查詢執行。但是，如果使用其他工具(如ETL工具)來訪問文件，則不能保證該工具支持所有格式。
2. 壓縮：壓縮是優化查詢的另一種方法。Hive提供了多種壓縮編解碼器，例如Gzip，snappy等。GZIP的缺點是無法拆分文件。此處使用的壓縮編解碼器具有不同的屬性，某些壓縮工作速度更快，需要較少的CPU，而其他壓縮文件在壓縮過程中需要更多的CPU。Hadoop上文件的可拆分性是提高性能的重要因素。
3. 如何存儲或組織數據-在Hadoop中組織數據是一門學科。數據的安排對查詢有重大影響。如果查詢要定位到數據的一部分，我們需要確保查詢僅擊中該部分，而不是整個可用數據集。可以根據事務級別對數據進行排序，例如事件發生時的數據類型或時間戳

數據中心文件夾結構

在數據中心中存儲數據的通用文件夾模式基于源系統。數據中心也可以基于主題區域而不是源系統來構建。必須在企業級別上做出此決定，因為需要在計劃和項目之間進行協同才能在企業規模上實現這一目標。讓我們看一下如何基于源系統創建文件和文件夾。例如，我們有一個文件，其中包含電影信息，例如movie_id，movie_name，year_of_release(2016)，爛番茄的評級和imDB文件都可以通過這種方式安排。同樣，如果我們從這些供應商處獲得電影評論，其中包含movie_id，review_id，individual_rating，評論等信息，則可以將其存儲為現在，讓我們檢查一些可能的情況，如何使用此數據。

• 取得評分超過3的電影
• 獲取評論最多的電影ID
• 獲取2014年之后發行的電影數量

這些方案一次只能訪問一個文件，而無需在文件之間聯接。現在讓我們看看其他情況。

• 獲得電影的名稱和與電影相關的其他信息，以取得最大的評價

這是一個必須在文件之間合并數據的示例。了解聯接和查詢將使您更好地了解如何存儲數據。但是要使其通用，可以將上述文件夾結構改進為此文件夾模式將幫助訪問與2016年有關的所有電影和評論。在這種情況下，可以訪問2016年的數據而無需讀取其他年份的數據。在上面的示例技術中，我們使用了基于年份的分區數據。這種數據安排不僅對Hive有所幫助，而且對將Hive的元存儲用于元數據的其他工具(例如impala，spark等)也有幫助。可以將這種文件夾安排與關系數據庫上的分區進行比較，因為Hive知道在哪里查找數據而不是進行完整的數據掃描。Hadoop上的數據中心可避免構建傳統數據倉庫所需要的額外arcHive系統。在傳統的DWH中，ETL曾經使用過的源文件會被備份，并在保留一段時間后脫機。使數據重新聯機是一項巨大的工作，大多數情況下，隨著時間的推移，這些數據將不再使用。上面討論的折疊機構避免了需要單獨的arcHive機構。由于與關系數據庫相比，Hadoop上的空間便宜，因此此選項效果很好。

我們可以在Hadoop上進行關系數據建模嗎?

當選擇Hadoop作為企業數據倉庫的平臺時，關系數據建模是一個非常常見的用例。問題的答案是，借助Hive元存儲，在技術上可以在Hadoop平臺上實現。如果我們退后一步，看看設計的文件夾模式，很明顯，可以按照RDBMS上的關系數據建模來設計和安排文件夾。HDFS上的數據訪問是“讀取模式”。無論數據存儲的方式和位置如何，都可以按照我們希望的方式對其進行讀取。與傳統的RDBMS不同，在傳統的RDBMS中，必須對模式進行建模并將數據加載到表中。這需要對數據進行大量分析，并在優化的數據模型上花費精力和時間。使用Hadoop，由于模型更改不需要重新加載數據，因此可以大大減少這種工作。為了解釋這一點，客戶名稱，客戶ID，客戶電子郵件，客戶電話號碼，購買的商品，商品數量，商品價格。在關系數據庫中，可以將這些數據規范化并分為客戶信息，產品信息和銷售信息，并與客戶ID，銷售ID和商品ID鏈接回去。這種模型減少了冗余，這是RDBMS中的一個主要因素，因為存儲成本很高。通過建立正確的索引類型，聯接的查詢將產生更好的結果。

客戶信息

• 顧客ID
• 顧客姓名
• 電子郵件
• 電話

Items_Info

• 物品ID
• 商品描述
• 項目名
• 商品價格

銷售事實

• 銷售編號
• 顧客ID
• 商品編號
• 項目數量
• 銷售日期

Hadoop的優勢在于，我們仍然可以擁有相同的邏輯模型，并且可以通過多種方式在物理上實現而不用移動數據。

 

上面的視圖顯示了數據的非規范化格式，這是在表示層或語義層上需要運行基于事實的分析功能的便捷格式。例如，找到在一種產品上出售的物品總數或在第二種產品上的總收入等等。在規范化建模的數據模型中，這將需要連接至少3個表。在Hadoop中，由于混洗和多個磁盤IO，我們知道聯接數據是一項昂貴的操作。在Hadoop平臺中，考慮到性能要比存儲更重要，因為存儲更便宜。

方法1-歸一化模型

標準化邏輯模型的物理實現讓我們嘗試用相同的物理實現來實現標準化形式。用這種方法創建了3個表

根據表上的customerID，Item ID對數據進行存儲。桶裝是一種基于分發密鑰上的哈希來分發數據的技術。選擇分發密鑰至關重要，因為我們需要確保數據在數據節點之間均勻分布。您可以看到銷售數據是根據銷售日期劃分的，這將有助于查詢僅在特定日期或幾天范圍內訪問數據的查詢。例如，其中salesDate = '01 / 31/2016'。在加入時將數據存儲在同一分發密鑰上會有所幫助。在上述模型中，需要連接的大多數查詢連接謂詞將是ItemId或customerID。由于數據是基于這些字段分配的，因此可以確保在密鑰上加入的數據將不需要在網絡上進行混洗或移動。這將大大減少加入時間。在Hadoop上，與在reducer端進行連接相比，在map端進行reduce范例連接可以節省時間。Hive自動檢測到存儲桶，并應用此優化。在以上示例中，存儲區大小的256是一個數字，必須根據數據量和可用節點來確定。正常的存儲桶大小必須是幾個hdfs塊大小，并且可以容納到內存中。不建議使用太多的小桶尺寸的桶。

優點

• 當數據是確定性的并且數據模型可以很好地滿足需求時很有用
• 當使用的查詢是靜態且可預測時有用
• 從關系數據庫輕松遷移

缺點

• 不能用于動態查詢或其他分析目的
• 更改模型將需要更改ETL，并且需要重新加載數據
• 隨著數據的增長和傾斜，性能將成為問題。如果存儲桶的密鑰不夠好，則需要對數據進行恒定的重新分配。

當數據被規范化并以星型模式存儲時，我們也必須考慮對事務維護ACID。從技術上講，我們應該能夠插入，更新或刪除數據。如您所知，在HDFS中進行數據修改并不容易。但是可以使用其他技術來解決此問題

• 用last_updated_ts附加數據，而不是更新記錄
• 將歷史數據和最新數據保存在兩組文件中。
• 使用Hive使用如何使用Hive進行CRUD更新數據- 在Hive上運行更新和刪除
• 在歷史數據的頂部創建一個視圖，以僅提取最新數據，而不使用上述技術來實現

方法2-歸一化數據

第二種方法討論在添加查詢中所需的所有可能屬性后對數據進行展平。可以將其與帶有列族的平面Hbase表進行比較。在這種方法中，我們只有一張表可以滿足我們的所有需求。歸一化數據的優點是代碼可以讀取更大的數據塊，而不是從多個小塊中讀取相同的數據。

數據被分區以進行搜索/選擇以進行部分訪問。此類分區的邏輯列將是時間戳記或日期。選擇分區時，唯一需要考慮的是文件大小。文件的分區信息存儲在名稱節點中。小文件上的分區過多將在名稱節點上繁重。從每個分區讀取小文件將不會很好地利用讀取器操作以及內存。如果文件很少，HDFS塊大小分區將很好地工作。如果文件太小，可以將其合并在一起以具有合理的分區。例如，每日文件只有幾千字節。可以根據數據量將許多此類文件放在一個月分區或每周分區中。

優點

• 更快的查詢執行
• 適用于開箱即用的分析

缺點

• 數據冗余-您可以看到客戶和物料數據在銷售信息中重復出現。在Hadoop上，存儲不是主要的考慮因素，如果您決定避免冗余，那么就要在空間和性能之間進行權衡。
• 這不是一個必須不斷更新數據的好用例。

何時選擇對方法1(標準化數據/星型模式)進行De Normalization?

• 如果聯接的表很小，并且聯接時一對一匹配。
• 當列寬(列數)較小時。如果表很寬，則會占用更多空間，并且塊讀取大小會變大
• 數據更新不多時。如果您每次必須返回并更新一些隨機字段，則反規范化技術將不起作用。例如，對于age，如果age字段是交易的一部分，我們知道每年必須對其進行修改。

在非規范化數據上實現相同的邏輯模型

該組織的大多數人都使用haddop來補充現有的完善的EDW。這些模型與該平臺無關，但是正如我們所看到的，與RDBMS相比，Hadoop需要一種不同的物理實現。不管相同的邏輯模型如何，都可以通過多種方式實現。

拆分為尺寸/子表

上面的非規范化銷售數據可以分為維度和事實，我們已經討論過了。

1. 在Sales_Fact_Flat表的頂部構建非實現視圖，可以使用視圖重新創建客戶信息 創建視圖Customer_Info作為選擇不同customerId BIGINT，CustomerName STRING，Email STRING，從Sales_Fact_Flat向STRING打電話同樣，可以重新創建其他視圖。視圖的不利之處在于，每次在查詢中使用視圖時，地圖都會減少在后臺運行以實現結果。
2. 代替視圖，使用CTAS將數據具體化為表(創建表作為選擇)創建表Customer_Info作為選擇不同 customerId BIGINT，CustomerName STRING，Email STRING，從Sales_Fact_Flat向STRING打電話這些方法的優點是，這些視圖/表可以用作其他分析的獨立實體。

總而言之，討論了在Hadoop平臺上實現數據倉庫的各種可行選擇。我們還將討論基于訪問模式，優化和存儲技術的各種文件和文件夾創建選項。