掌握 Hadoop，第 3 部分：Hadoop 生態系統：充分利用您的叢集

我們已經看到Hadoop生態系統的基本組件（第一部分，第二部分），這個生態系統不斷演變並優化以適應新的應用需求。因此，隨著時間的推移，各種工具和技術發展起來，使Hadoop變得更強大，並且應用範圍更廣。這使得它超越了純粹的HDFS和MapReduce平台，並提供了例如SQL、NoSQL查詢或即時串流的功能。

Hive/HiveQL

Apache Hive是一個數據倉儲系統，允許在Hadoop集群上進行類似SQL的查詢。傳統的關聯數據庫在處理大型數據集時，面臨水平擴展和ACID屬性的挑戰，而Hive在這方面表現出色。它使得通過類似SQL的查詢語言HiveQL查詢Hadoop數據成為可能，而無需編寫複雜的MapReduce作業，這使得商業分析師和開發者都能輕鬆使用。

因此，Apache Hive使得可以使用類似SQL的查詢語言查詢HDFS數據系統，而無需在Java中編寫複雜的MapReduce過程。這意味著商業分析師和開發者可以使用HiveQL（Hive查詢語言）來創建簡單的查詢，並根據Hadoop數據架構構建評估。

Hive最初是由Facebook開發的，用於處理大量的結構化和半結構化數據。它特別適合批量分析，並且可以與常見的商業智能工具，如Tableau或Apache Superset一起使用。

元數據存儲庫是存儲元數據的中央庫，包括表定義、列名稱和HDFS位置信息。這使得Hive能夠管理和組織大型數據集。執行引擎則將HiveQL查詢轉換為Hadoop可以處理的任務。根據所需的性能和基礎設施，可以選擇不同的執行引擎：

• MapReduce：經典的、較慢的方法。
• Tez：比MapReduce更快的替代方案。
• Spark：最快的選擇，能夠在內存中運行查詢以獲得最佳性能。

在實際使用Hive時，應考慮多個方面以最大化性能。例如，它基於分區，這樣數據不會存儲在一個巨大的表中，而是存儲在可以更快查詢的分區中。例如，一家公司的銷售數據可以按年和月進行分區：

CREATE TABLE sales_partitioned (

    customer_id STRING,

    amount DOUBLE

) PARTITIONED BY (year INT, month INT);

這意味著在查詢過程中，只能訪問所需的特定分區。在創建分區時，創建經常查詢的分區是有意義的。還可以使用桶來確保聯接運行得更快，並且數據均勻分佈。

CREATE TABLE sales_bucketed (

    customer_id STRING,

    amount DOUBLE

) CLUSTERED BY (customer_id) INTO 10 BUCKETS;

總之，Hive是一個有用的工具，如果要對大量數據進行結構化查詢，這是非常必要的。它還提供了一種簡單的方式來將常見的BI工具（如Tableau）與Hadoop中的數據連接起來。然而，如果應用需要許多短期的讀取和寫入訪問，那麼Hive就不是合適的工具。

Pig

Apache Pig更進一步，能夠在Hadoop中並行處理大量數據。與Hive相比，它不專注於數據報告，而是專注於半結構化和非結構化數據的ETL過程。對於這些數據分析，不需要使用複雜的Java MapReduce過程；相反，可以使用專有的Pig Latin語言編寫簡單的過程。

此外，Pig可以處理各種文件格式，如JSON或XML，並執行數據轉換，如合併、過濾或分組數據集。整體過程如下：

• 加載信息：數據可以從不同的數據源中提取，如HDFS或HBase。
• 轉換數據：然後根據應用需求修改數據，以便可以過濾、聚合或聯接。
• 保存結果：最後，處理後的數據可以存儲在各種數據系統中，如HDFS、HBase或甚至關聯數據庫。

Apache Pig在許多基本方面與Hive不同。最重要的區別包括：

Apache Pig是Hadoop的一個組件，通過其基於腳本的Pig Latin語言簡化了數據處理，並依賴於並行處理加速轉換。它特別受數據工程師的歡迎，因為他們希望在Hadoop上工作，而無需開發複雜的Java MapReduce程序。

HBase

HBase是一個基於鍵值的NoSQL數據庫，存儲在Hadoop中，以列為導向。與傳統的關聯數據庫相比，它可以進行水平擴展，並且在需要時可以添加新的伺服器。數據模型由多個表組成，每個表都有一個唯一的行鍵，可以用來唯一識別它們。這可以想像成關聯數據庫中的主鍵。

每個表又由屬於所謂列族的列組成，並且在創建表時必須定義。鍵值對然後存儲在列的單元格中。通過專注於列而不是行，可以特別高效地查詢大量數據。

這種結構在創建新數據記錄時也可以看到。首先創建一個唯一的行鍵，然後可以將單個列的值添加到這個行鍵中。

Put put = new Put(Bytes.toBytes("1001"));

put.addColumn(Bytes.toBytes("Personal"), Bytes.toBytes("Name"), Bytes.toBytes("Max"));

put.addColumn(Bytes.toBytes("Bestellungen"), Bytes.toBytes("Produkt"), Bytes.toBytes("Laptop"));

table.put(put);

首先命名列族，然後定義鍵值對。查詢時，首先通過行鍵定義數據集，然後調用所需的列及其包含的鍵。

Get get = new Get(Bytes.toBytes("1001"));

Result result = table.get(get);

byte[] name = result.getValue(Bytes.toBytes("Personal"), Bytes.toBytes("Name"));

System.out.println("Name: " + Bytes.toString(name));

這種結構基於主從設置。HMaster是HBase的高級控制單元，管理底層的RegionServers。它還負責負載分配，通過集中監控系統性能並將所謂的區域分配給RegionServers。如果一個RegionServer失敗，HMaster還確保數據分配到其他RegionServers，以便保持操作。如果HMaster本身失敗，集群也可以有額外的HMasters，這些HMasters可以從待機模式中恢復運行。在運行期間，集群中只有一個HMaster在運行。

RegionServers是HBase的工作單元，因為它們在集群中存儲和管理表數據。它們還回答讀取和寫入請求。為此，每個HBase表被劃分為幾個子集，即所謂的區域，然後由RegionServers管理。一個RegionServer可以管理多個區域，以便在節點之間管理負載。

RegionServers直接與客戶端工作，因此直接接收讀取和寫入請求。這些請求最終進入所謂的MemStore，其中進來的讀取請求首先從MemStore中提供，如果所需的數據不再可用，則使用HDFS中的永久內存。一旦MemStore達到一定大小，則其包含的數據將存儲在HDFS中的HFile中。

因此，HBase的存儲後端是HDFS，作為永久存儲使用。如前所述，HFiles用於此，可以分佈在多個節點上。這樣的優勢是水平擴展，因為數據量可以分佈在不同的機器上。此外，使用不同的數據副本以確保可靠性。

最後，Apache Zookeeper作為HBase的上層實例，協調分佈式應用。它監控HMaster和所有RegionServers，並在HMaster失敗時自動選擇新的領導者。它還存儲有關集群的重要元數據，並防止多個客戶端同時訪問數據時的衝突。這使得即使在更大的集群中也能順利運行。

因此，HBase是一個強大的NoSQL數據庫，適合大數據應用。得益於其分佈式架構，即使在伺服器故障的情況下，HBase仍然可訪問，並提供了在MemStore中支持的RAM處理與HDFS中數據的永久存儲的組合。

Spark

Apache Spark是MapReduce的進一步發展，通過使用內存計算，速度快達100倍。它已經發展成為一個全面的平台，支持各種工作負載，如批處理、數據串流，甚至機器學習，這得益於許多組件的添加。它還兼容各種數據源，包括HDFS、Hive和HBase。

這些組件的核心是Spark Core，提供分佈式處理的基本功能：

• 任務管理：計算可以在多個節點之間分配和監控。
• 容錯性：在單個節點出現錯誤時，可以自動恢復。
• 內存計算：數據存儲在伺服器的RAM中，以確保快速處理和可用性。

Apache Spark的中央數據結構是所謂的彈性分佈數據集（RDDs）。它們使得在不同節點之間的分佈式處理成為可能，並具有以下特性：

• 彈性（容錯）：在節點故障時，可以恢復數據。RDD不會存儲數據本身，而是僅存儲變換的序列。如果一個節點失敗，Spark可以簡單地重新執行事務以恢復RDD。
• 分佈式：信息分佈在多個節點上。
• 不可變：一旦創建，RDD無法更改，只能重新創建。
• 延遲評估（延遲執行）：操作僅在執行時執行，而不是在定義時執行。

Apache Spark還由以下組件組成：

• Spark SQL提供了Spark的SQL引擎，運行在數據集和DataFrames上。由於它在內存中工作，處理速度特別快，因此適合所有效率和速度至關重要的應用。
• Spark Streaming提供了實時處理連續數據流的可能性，並將其轉換為小批量。它可以用於分析社交媒體帖子或監控物聯網數據。它還支持許多常見的串流數據源，如Kafka或Flume。
• 通過MLlib，Apache Spark提供了一個廣泛的庫，包含多種機器學習算法，可以直接應用於存儲的數據集。這包括分類、回歸或整個推薦系統的模型。
• GraphX是一個強大的工具，用於處理和分析圖數據。這使得對數據點之間的關係進行高效分析成為可能，並可以以分佈式方式同時計算。還有專門的PageRank算法用於分析社交網絡。

Apache Spark無疑是Hadoop的一個新興組件，因為它使得快速的內存計算成為可能，而這在以前的MapReduce中是不可想像的。雖然Spark不是Hadoop的專屬組件，因為它也可以使用其他文件系統，如S3，但在實踐中，這兩個系統經常一起使用。由於其通用性和多種功能，Apache Spark的受歡迎程度也在不斷上升。

Oozie

Apache Oozie是一個工作流管理和調度系統，專門為Hadoop開發，計劃各種Hadoop作業的執行和自動化，例如MapReduce、Spark或Hive。這裡最重要的功能是Oozie定義作業之間的依賴關係，並按特定順序執行它們。此外，可以定義調度或特定事件，以便執行作業。如果在執行過程中發生錯誤，Oozie還具有錯誤處理選項，可以重新啟動作業。

工作流以XML格式定義，以便工作流引擎可以讀取並以正確的順序啟動作業。如果某個作業失敗，可以簡單地重複執行或啟動其他步驟。Oozie還具有數據庫後端系統，如MySQL或PostgreSQL，用於存儲狀態信息。

Presto

Apache Presto提供了另一種選擇，可以對大量數據應用分佈式SQL查詢。與其他Hadoop技術（如Hive）相比，查詢是實時處理的，因此它針對運行在大型分佈式系統上的數據倉庫進行了優化。Presto廣泛支持所有相關數據源，並且不需要定義模式，因此可以直接從數據源查詢數據。它還經過優化，可以在分佈式系統上運行，因此可以用於PB級數據集。

Apache Presto使用所謂的大規模並行處理（MPP）架構，這使得在分佈式系統中的處理特別高效。一旦用戶通過Presto CLI或BI前端發送SQL查詢，協調器將分析查詢並創建可執行的查詢計劃。然後工作節點執行查詢並將其部分結果返回給協調器，協調器將其合併為最終結果。

Presto與Hadoop中的相關系統的區別如下：

這使得Presto成為在像Hadoop這樣的分佈式大數據環境中快速SQL查詢的最佳選擇。

Hadoop的替代方案是什麼？

特別是在2010年代初，Hadoop長期以來一直是分佈式數據處理的領先技術。然而，自那以後出現了幾種替代方案，在某些情況下提供了更多優勢，或者更適合當今的應用。

雲原生Hadoop替代方案

許多公司已經不再托管自己的伺服器和本地系統，而是將其大數據工作負載轉移到雲端。在那裡，他們可以顯著受益於自動擴展、較低的維護成本和更好的性能。此外，許多雲提供商還提供比Hadoop更易於管理的解決方案，因此也可以由較少訓練的員工操作。

Amazon EMR（彈性MapReduce）

Amazon EMR是AWS的一個管理大數據服務，提供Hadoop、Spark和其他分佈式計算框架，這樣這些集群就不再需要在本地托管。這使得公司不再需要主動關心集群的維護和管理。除了Hadoop，Amazon EMR還支持許多其他開源框架，如Spark、Hive、Presto和HBase。這種廣泛的支持意味著用戶可以輕鬆地將現有集群轉移到雲端，而不會遇到重大問題。

在存儲方面，Amazon使用EMR S3作為主要存儲，而不是HDFS。這不僅使存儲成本更低，因為不需要永久集群，還因為數據在多個AWS區域中冗餘存儲而具有更好的可用性。此外，計算和存儲可以獨立擴展，而不是像Hadoop那樣只能通過集群進行擴展。

EMR文件系統（EMRFS）有一個專門優化的接口，允許Hadoop或Spark直接訪問S3。它還支持一致性模型，並啟用元數據緩存以提高性能。如果需要，HDFS也可以使用，例如在集群節點上需要本地臨時存儲時。

Amazon EMR相較於傳統Hadoop集群的另一個優勢是能夠使用動態自動擴展，不僅可以降低成本，還可以提高性能。集群的大小和可用硬體會根據CPU利用率或作業隊列大小自動調整，因此只對所需的硬體產生費用。

所謂的現貨指數可以在需要時臨時添加。例如，在公司中，夜間添加它們是有意義的，因為需要將生產系統中的數據存儲到數據倉庫中。而在白天，則運行較小的集群，從而節省成本。

因此，Amazon EMR為本地使用Hadoop提供了幾個優化。對S3的優化存儲訪問、動態集群擴展以提高性能並同時優化成本，以及節點之間改進的網絡通信都是特別有利的。總體而言，數據可以在較少的資源需求下更快地處理，而不是在運行在其伺服器上的傳統Hadoop集群中。

Google BigQuery

在數據倉儲領域，Google BigQuery提供了一個完全管理且無伺服器的數據倉庫，能夠對大量數據進行快速SQL查詢。它依賴於列式數據存儲，並使用Google Dremel技術更高效地處理大量數據。同時，它可以在很大程度上省去集群管理和基礎設施維護。

與原生Hadoop相比，BigQuery使用列式導向，因此可以通過使用高效的壓縮方法節省大量存儲空間。此外，查詢速度加快，因為只需讀取所需的列，而不是整行。這使得工作效率大大提高，特別是在處理非常大量的數據時。

BigQuery還使用Dremel技術，能夠在並行層次中執行SQL查詢，並將工作負載分佈到不同的機器上。由於這種架構在合併部分結果時往往會失去性能，BigQuery使用樹聚合來高效地組合部分結果。

對於專注於SQL查詢的應用，如數據倉庫或商業智能，BigQuery是Hadoop的更好替代方案。另一方面，對於非結構化數據，Hadoop可能是更合適的替代方案，儘管必須考慮集群架構和相關成本。最後，BigQuery還提供了良好的連接到Google的各種機器學習產品，如Google AI或AutoML，這在選擇時也應考慮。

Snowflake

如果你不想依賴Google Cloud的BigQuery，或者已經在追求多雲策略，Snowflake可以成為建立雲原生數據倉庫的有效替代方案。它通過將計算能力和存儲需求分開來提供動態擴展，因此可以獨立調整。

與BigQuery相比，Snowflake是雲中立的，因此可以在AWS、Azure或甚至Google Cloud等常見平台上運行。儘管Snowflake也提供根據需求擴展硬體的選項，但與BigQuery不同，沒有自動擴展的選項。另一方面，可以創建多個集群，將數據倉庫分佈在其中，從而最大化性能。

在成本方面，由於架構的不同，提供商之間存在差異。由於BigQuery的完全管理和自動擴展，Google Cloud可以按查詢計算成本，並且不會對計算能力或存儲收取直接費用。而Snowflake則自由選擇提供商，因此在大多數情況下，最終會採用所謂的按需付費模式，提供商會收取存儲和計算能力的費用。

總體而言，Snowflake提供了一個更靈活的解決方案，可以由各種提供商托管，甚至作為多雲服務運行。然而，這需要更大的系統操作知識，因為資源必須獨立調整。相比之下，BigQuery具有無伺服器模型，這意味著不需要基礎設施管理。

Hadoop的開源替代方案

除了這些完整且大型的雲數據平台外，還有幾個強大的開源程序專門作為Hadoop的替代方案，特別針對其弱點，如實時數據處理、性能和管理複雜性。正如我們已經看到的，Apache Spark非常強大，可以用作Hadoop集群的替代品，我們不再重複這一點。

Apache Flink

Apache Flink是一個開源框架，專門為分佈式流處理而開發，以便可以持續處理數據。與Hadoop或Spark相比，後者以所謂的微批次處理數據，Flink可以以非常低的延遲近乎實時地處理數據。這使得Apache Flink成為需要持續生成信息並需要實時反應的應用的替代方案，例如來自機器的傳感器數據。

雖然Spark Streaming以所謂的小批次處理數據，從而模擬流處理，但Apache Flink提供了真正的流處理，使用事件驅動模型，可以在數據到達後幾毫秒內處理數據。這可以進一步減少延遲，因為不會因為微批次或其他等待時間而造成延遲。基於這些原因，Flink更適合高頻數據源，如傳感器或金融市場交易，因為每一秒都至關重要。

Apache Flink的另一個優勢是其先進的有狀態處理。在許多實時應用中，事件的上下文起著重要作用，例如客戶的先前購買用於產品推薦，因此必須保存。使用Flink，這種存儲已經在應用中進行，因此可以高效地進行長期和有狀態的計算。

當實時分析機器數據時，這一點尤為明顯，因為必須將先前的異常（如過高的溫度或故障零件）納入當前報告和預測中。使用Hadoop或Spark，必須首先訪問單獨的數據庫，這會導致額外的延遲。而使用Flink，機器的歷史異常已經存儲在應用中，因此可以直接訪問。

總之，Flink是更好的選擇，適合高度動態和基於事件的數據處理。而Hadoop則基於批處理，因此無法實時分析數據，因為總是需要等待完成的數據塊。

現代數據倉庫

長期以來，Hadoop是處理大量數據的標準解決方案。然而，今天的公司也依賴現代數據倉庫作為替代方案，因為這些倉庫為結構化數據提供了優化的環境，從而實現更快的SQL查詢。此外，還有各種雲原生架構，這些架構也提供自動擴展，從而減少管理工作並節省成本。

在本節中，我們將重點介紹Hadoop的最常見數據倉庫替代方案，並解釋為什麼它們可能比Hadoop更好。

Amazon Redshift

Amazon Redshift是一個基於雲的數據倉庫，專為使用SQL進行結構化分析而開發。這優化了大型關聯數據集的處理，並允許使用快速的列式查詢。

與傳統數據倉庫的主要區別之一是數據以列而不是行的方式存儲，這意味著查詢時只需加載相關的列，這顯著提高了效率。而Hadoop，特別是HDFS，則針對半結構化和非結構化數據進行了優化，並不原生支持SQL查詢。這使得Redshift非常適合需要聚合和過濾大量數據的OLAP分析。

另一個提高查詢速度的特徵是使用大規模並行處理（MPP）系統，其中查詢可以分佈到多個節點並並行處理。這實現了極高的並行化能力和處理速度。

此外，Amazon Redshift與Amazon現有系統的集成非常良好，可以無縫集成到AWS環境中，而無需使用開源工具，如Hadoop。經常使用的工具包括：

• Amazon S3提供對雲存儲中大量數據的直接訪問。
• AWS Glue可用於ETL過程，其中數據被準備和轉換。
• Amazon QuickSight是一個可用於數據可視化和分析的工具。
• 最後，可以使用各種AWS ML服務實現機器學習應用。

對於尋找管理和可擴展數據倉庫解決方案的用戶，尤其是對於關聯查詢，Amazon Redshift是一個真正的Hadoop替代方案，特別是如果你已經有一個現有的AWS集群或想在其上構建架構。由於其列式存儲和大規模並行處理系統，它在查詢速度和大量數據方面也能提供真正的優勢。

Databricks（湖倉平台）

Databricks是一個基於Apache Spark的雲平台，專門優化了數據分析、機器學習和人工智慧。它擴展了Spark的功能，提供易於理解的用戶界面和優化的集群管理，還提供所謂的Delta Lake，與基於Hadoop的系統相比，提供數據一致性、可擴展性和性能。

Databricks提供了一個完全管理的環境，可以輕鬆運行和自動化使用雲中的Spark集群。這消除了像Hadoop集群那樣需要手動設置和配置的需求。此外，Apache Spark的使用經過優化，因此批處理和串流處理可以更快、更高效地運行。最後，Databricks還包括自動擴展，這在雲環境中非常有價值，因為它可以節省成本並提高可擴展性。

傳統Hadoop平台的問題在於它們不符合ACID屬性，因此，由於分佈在不同伺服器上的數據一致性並不總是得到保證。使用Databricks，這個問題通過所謂的Delta Lake得到了解決：

• ACID事務：Delta Lake確保所有事務符合ACID準則，允許即使是複雜的管道也能完全和一致地執行。這確保了在大數據應用中的數據完整性。
• 模式演變：數據模型可以動態更新，這樣現有工作流就不必進行調整。
• 優化的存儲和查詢：Delta Lake使用索引、緩存或自動壓縮等過程，使查詢速度比傳統Hadoop或HDFS環境快得多。

最後，Databricks超越了傳統的大數據框架，還提供了集成的機器學習和AI平台。最常見的機器學習平台，如TensorFlow、scikit-learn或PyTorch，都得到支持，這樣存儲的數據就可以直接處理。因此，Databricks提供了一個簡單的端到端管道，用於機器學習應用。從數據準備到完成的模型，所有過程都可以在Databricks中進行，所需的資源可以靈活地在雲中預訂。

因此，如果需要具有ACID事務和模式靈活性的大數據湖，Databricks是一個有效的Hadoop替代方案。它還提供其他組件，例如機器學習應用的端到端解決方案。此外，雲中的集群不僅可以更輕鬆地運行，通過自動調整硬體以滿足需求來節省成本，還能提供比傳統Hadoop集群更高的性能。

在這部分中，我們探討了Hadoop生態系統，突出了關鍵工具，如Hive、Spark和HBase，每個工具都旨在增強Hadoop在各種數據處理任務中的能力。從使用Hive進行類似SQL的查詢到使用Spark進行快速的內存處理，這些組件為大數據應用提供了靈活性。雖然Hadoop仍然是一個強大的框架，但雲原生解決方案和現代數據倉庫等替代方案在不同需求下值得考慮。

本系列介紹了Hadoop的架構、組件和生態系統，為您提供了構建可擴展、定制的大數據解決方案的基礎。隨著該領域的持續發展，您將能夠選擇合適的工具，以滿足數據驅動項目的需求。