大數(shù)據(jù)平臺(tái)上的數(shù)據(jù)倉(cāng)庫是許多組織正在探索的標(biāo)準(zhǔn)用例。采用這種方法的原因可能是大數(shù)據(jù)平臺(tái)提供的許多靈活性之一。

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

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

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

HDFS-是Hadoop的核心，這是一個(gè)分布式文件系統(tǒng)，它使Hadoop可以完成所有的任務(wù)。還有許多其他分布式文件系統(tǒng)，例如Amazon S3，但是當(dāng)我們談?wù)揌adoop HDFS時(shí)，它就是文件系統(tǒng)的代名詞。像Cloudera，IBM BigInsights，Hortonworks等大多數(shù)Hadoop營(yíng)銷供應(yīng)商都將HDFS用作其文件系統(tǒng)。

Hive -Hive是一個(gè)Apache項(xiàng)目，它將數(shù)據(jù)庫，表和SQL的概念引入了大數(shù)據(jù)世界。蜂巢正在進(jìn)行中。Hive使用HDFS來存儲(chǔ)數(shù)據(jù)。Hive不僅為文件系統(tǒng)增加了SQL的靈活性，還用于HDFS的元數(shù)據(jù)存儲(chǔ)。元數(shù)據(jù)存儲(chǔ)庫不過是一個(gè)數(shù)據(jù)庫，它存儲(chǔ)有關(guān)HDFS中存儲(chǔ)的文件，文件結(jié)構(gòu)，分區(qū)，存儲(chǔ)區(qū)，序列化，讀取和寫入文件所需的反序列化等信息。這將使Hive能夠基于存儲(chǔ)在其中的元數(shù)據(jù)查詢文件蜂巢元商店。綜上所述，Hive為文件提供了數(shù)據(jù)抽象和數(shù)據(jù)發(fā)現(xiàn)層。

“ Hive的性能如何”

Hive的性能基于許多因素。它包括關(guān)系數(shù)據(jù)庫世界中通常遵循的最佳實(shí)踐，它們具有優(yōu)化的性能以及諸如文件存儲(chǔ)，壓縮技術(shù)等Hadoop注意事項(xiàng)。為簡(jiǎn)化起見，讓我們檢查在Hive上運(yùn)行查詢時(shí)會(huì)發(fā)生什么。

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

綜觀以上執(zhí)行模式，Hive表可以通過多種方式進(jìn)行設(shè)計(jì)以優(yōu)化性能。但是每種方法各有利弊?？紤]到需求的優(yōu)先級(jí)，必須做出決定。

數(shù)據(jù)存儲(chǔ)選項(xiàng)

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

數(shù)據(jù)中心文件夾結(jié)構(gòu)

在數(shù)據(jù)中心中存儲(chǔ)數(shù)據(jù)的通用文件夾模式基于源系統(tǒng)。數(shù)據(jù)中心也可以基于主題區(qū)域而不是源系統(tǒng)來構(gòu)建。必須在企業(yè)級(jí)別上做出此決定，因?yàn)樾枰谟?jì)劃和項(xiàng)目之間進(jìn)行協(xié)同才能在企業(yè)規(guī)模上實(shí)現(xiàn)這一目標(biāo)。讓我們看一下如何基于源系統(tǒng)創(chuàng)建文件和文件夾。例如，我們有一個(gè)文件，其中包含電影信息，例如movie_id，movie_name，year_of_release(2016)，爛番茄的評(píng)級(jí)和imDB文件都可以通過這種方式安排。同樣，如果我們從這些供應(yīng)商處獲得電影評(píng)論，其中包含movie_id，review_id，individual_rating，評(píng)論等信息，則可以將其存儲(chǔ)為現(xiàn)在，讓我們檢查一些可能的情況，如何使用此數(shù)據(jù)。

• 取得評(píng)分超過3的電影
• 獲取評(píng)論最多的電影ID
• 獲取2014年之后發(fā)行的電影數(shù)量

這些方案一次只能訪問一個(gè)文件，而無需在文件之間聯(lián)接?，F(xiàn)在讓我們看看其他情況。

• 獲得電影的名稱和與電影相關(guān)的其他信息，以取得最大的評(píng)價(jià)

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

我們可以在Hadoop上進(jìn)行關(guān)系數(shù)據(jù)建模嗎?

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

客戶信息

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

Items_Info

• 物品ID
• 商品描述
• 項(xiàng)目名
• 商品價(jià)格

銷售事實(shí)

• 銷售編號(hào)
• 顧客ID
• 商品編號(hào)
• 項(xiàng)目數(shù)量
• 銷售日期

Hadoop的優(yōu)勢(shì)在于，我們?nèi)匀豢梢該碛邢嗤倪壿嬆Ｐ?，并且可以通過多種方式在物理上實(shí)現(xiàn)而不用移動(dòng)數(shù)據(jù)。

上面的視圖顯示了數(shù)據(jù)的非規(guī)范化格式，這是在表示層或語義層上需要運(yùn)行基于事實(shí)的分析功能的便捷格式。例如，找到在一種產(chǎn)品上出售的物品總數(shù)或在第二種產(chǎn)品上的總收入等等。在規(guī)范化建模的數(shù)據(jù)模型中，這將需要連接至少3個(gè)表。在Hadoop中，由于混洗和多個(gè)磁盤IO，我們知道聯(lián)接數(shù)據(jù)是一項(xiàng)昂貴的操作。在Hadoop平臺(tái)中，考慮到性能要比存儲(chǔ)更重要，因?yàn)榇鎯?chǔ)更便宜。

方法1-歸一化模型

標(biāo)準(zhǔn)化邏輯模型的物理實(shí)現(xiàn)讓我們嘗試用相同的物理實(shí)現(xiàn)來實(shí)現(xiàn)標(biāo)準(zhǔn)化形式。用這種方法創(chuàng)建了3個(gè)表

根據(jù)表上的customerID，Item ID對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)。桶裝是一種基于分發(fā)密鑰上的哈希來分發(fā)數(shù)據(jù)的技術(shù)。選擇分發(fā)密鑰至關(guān)重要，因?yàn)槲覀冃枰_保數(shù)據(jù)在數(shù)據(jù)節(jié)點(diǎn)之間均勻分布。您可以看到銷售數(shù)據(jù)是根據(jù)銷售日期劃分的，這將有助于查詢僅在特定日期或幾天范圍內(nèi)訪問數(shù)據(jù)的查詢。例如，其中salesDate = '01 / 31/2016'。在加入時(shí)將數(shù)據(jù)存儲(chǔ)在同一分發(fā)密鑰上會(huì)有所幫助。在上述模型中，需要連接的大多數(shù)查詢連接謂詞將是ItemId或customerID。由于數(shù)據(jù)是基于這些字段分配的，因此可以確保在密鑰上加入的數(shù)據(jù)將不需要在網(wǎng)絡(luò)上進(jìn)行混洗或移動(dòng)。這將大大減少加入時(shí)間。在Hadoop上，與在reducer端進(jìn)行連接相比，在map端進(jìn)行reduce范例連接可以節(jié)省時(shí)間。Hive自動(dòng)檢測(cè)到存儲(chǔ)桶，并應(yīng)用此優(yōu)化。在以上示例中，存儲(chǔ)區(qū)大小的256是一個(gè)數(shù)字，必須根據(jù)數(shù)據(jù)量和可用節(jié)點(diǎn)來確定。正常的存儲(chǔ)桶大小必須是幾個(gè)hdfs塊大小，并且可以容納到內(nèi)存中。不建議使用太多的小桶尺寸的桶。

優(yōu)點(diǎn)

• 當(dāng)數(shù)據(jù)是確定性的并且數(shù)據(jù)模型可以很好地滿足需求時(shí)很有用
• 當(dāng)使用的查詢是靜態(tài)且可預(yù)測(cè)時(shí)有用
• 從關(guān)系數(shù)據(jù)庫輕松遷移

缺點(diǎn)

• 不能用于動(dòng)態(tài)查詢或其他分析目的
• 更改模型將需要更改ETL，并且需要重新加載數(shù)據(jù)
• 隨著數(shù)據(jù)的增長(zhǎng)和傾斜，性能將成為問題。如果存儲(chǔ)桶的密鑰不夠好，則需要對(duì)數(shù)據(jù)進(jìn)行恒定的重新分配。

當(dāng)數(shù)據(jù)被規(guī)范化并以星型模式存儲(chǔ)時(shí)，我們也必須考慮對(duì)事務(wù)維護(hù)ACID。從技術(shù)上講，我們應(yīng)該能夠插入，更新或刪除數(shù)據(jù)。如您所知，在HDFS中進(jìn)行數(shù)據(jù)修改并不容易。但是可以使用其他技術(shù)來解決此問題

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

方法2-歸一化數(shù)據(jù)

第二種方法討論在添加查詢中所需的所有可能屬性后對(duì)數(shù)據(jù)進(jìn)行展平?？梢詫⑵渑c帶有列族的平面Hbase表進(jìn)行比較。在這種方法中，我們只有一張表可以滿足我們的所有需求。歸一化數(shù)據(jù)的優(yōu)點(diǎn)是代碼可以讀取更大的數(shù)據(jù)塊，而不是從多個(gè)小塊中讀取相同的數(shù)據(jù)。

數(shù)據(jù)被分區(qū)以進(jìn)行搜索/選擇以進(jìn)行部分訪問。此類分區(qū)的邏輯列將是時(shí)間戳記或日期。選擇分區(qū)時(shí)，唯一需要考慮的是文件大小。文件的分區(qū)信息存儲(chǔ)在名稱節(jié)點(diǎn)中。小文件上的分區(qū)過多將在名稱節(jié)點(diǎn)上繁重。從每個(gè)分區(qū)讀取小文件將不會(huì)很好地利用讀取器操作以及內(nèi)存。如果文件很少，HDFS塊大小分區(qū)將很好地工作。如果文件太小，可以將其合并在一起以具有合理的分區(qū)。例如，每日文件只有幾千字節(jié)?？梢愿鶕?jù)數(shù)據(jù)量將許多此類文件放在一個(gè)月分區(qū)或每周分區(qū)中。

優(yōu)點(diǎn)

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

缺點(diǎn)

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

何時(shí)選擇對(duì)方法1(標(biāo)準(zhǔn)化數(shù)據(jù)/星型模式)進(jìn)行De Normalization?

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

在非規(guī)范化數(shù)據(jù)上實(shí)現(xiàn)相同的邏輯模型

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

拆分為尺寸/子表

上面的非規(guī)范化銷售數(shù)據(jù)可以分為維度和事實(shí)，我們已經(jīng)討論過了。

1. 在Sales_Fact_Flat表的頂部構(gòu)建非實(shí)現(xiàn)視圖，可以使用視圖重新創(chuàng)建客戶信息 創(chuàng)建視圖Customer_Info作為選擇不同customerId BIGINT，CustomerName STRING，Email STRING，從Sales_Fact_Flat向STRING打電話同樣，可以重新創(chuàng)建其他視圖。視圖的不利之處在于，每次在查詢中使用視圖時(shí)，地圖都會(huì)減少在后臺(tái)運(yùn)行以實(shí)現(xiàn)結(jié)果。
2. 代替視圖，使用CTAS將數(shù)據(jù)具體化為表(創(chuàng)建表作為選擇)創(chuàng)建表Customer_Info作為選擇不同 customerId BIGINT，CustomerName STRING，Email STRING，從Sales_Fact_Flat向STRING打電話這些方法的優(yōu)點(diǎn)是，這些視圖/表可以用作其他分析的獨(dú)立實(shí)體。

總而言之，討論了在Hadoop平臺(tái)上實(shí)現(xiàn)數(shù)據(jù)倉(cāng)庫的各種可行選擇。我們還將討論基于訪問模式，優(yōu)化和存儲(chǔ)技術(shù)的各種文件和文件夾創(chuàng)建選項(xiàng)。