Hadoop 面試中 6 個常見的問題及答案

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

你準備好面試了嗎？呀，需要Hadoop的知識！！？不要慌！這裡有一些可能會問到的問題以及你應該給出的答案。

Q1.什麼是Hadoop？

Hadoop是一個開源軟體框架，用於儲存大量資料，併發處理/查詢在具有多個商用硬體（即低成本硬體）節點的叢集上的那些資料。總之，Hadoop包括以下內容：

HDFS（Hadoop Distributed File System，Hadoop分散式檔案系統）：HDFS允許你以一種分散式和冗餘的方式儲存大量資料。例如，1 GB（即1024 MB）文字檔案可以拆分為16 * 128MB檔案，並儲存在Hadoop叢集中的8個不同節點上。每個分裂可以複製3次，以實現容錯，以便如果1個節點故障的話，也有備份。HDFS適用於順序的“一次寫入、多次讀取”的型別訪問。

MapReduce：一個計算框架。它以分散式和並行的方式處理大量的資料。當你對所有年齡> 18的使用者在上述1 GB檔案上執行查詢時，將會有“8個對映”函式並行執行，以在其128 MB拆分檔案中提取年齡> 18的使用者，然後“reduce”函式將執行以將所有單獨的輸出組合成單個最終結果。

YARN（Yet Another Resource Nagotiator，又一資源定位器）：用於作業排程和叢集資源管理的框架。

Hadoop生態系統，擁有15多種框架和工具，如Sqoop，Flume，Kafka，Pig，Hive，Spark，Impala等，以便將資料攝入HDFS，在HDFS中轉移資料（即變換，豐富，聚合等），並查詢來自HDFS的資料用於商業智慧和分析。某些工具（如Pig和Hive）是MapReduce上的抽象層，而Spark和Impala等其他工具則是來自MapReduce的改進架構/設計，用於顯著提高的延遲以支援近實時（即NRT）和實時處理。

Q2.為什麼組織從傳統的資料倉儲工具轉移到基於Hadoop生態系統的智慧資料中心？

Hadoop組織正在從以下幾個方面提高自己的能力：

現有資料基礎設施：

• 主要使用儲存在高階和昂貴硬體中的“structured data，結構化資料”
• 主要處理為ETL批處理作業，用於將資料提取到RDBMS和資料倉儲系統中進行資料探勘，分析和報告，以進行關鍵業務決策。
• 主要處理以千兆位元組到兆位元組為單位的資料量

基於Hadoop的更智慧的資料基礎設施，其中

• 結構化（例如RDBMS），非結構化（例如images，PDF，docs ）和半結構化（例如logs，XMLs）的資料可以以可擴充套件和容錯的方式儲存在較便宜的商品機器中。
• 可以通過批處理作業和近實時（即，NRT，200毫秒至2秒）流（例如Flume和Kafka）來攝取資料。
• 資料可以使用諸如Spark和Impala之類的工具以低延遲（即低於100毫秒）的能力查詢。
• 可以儲存以兆兆位元組到千兆位元組為單位的較大資料量。

這使得組織能夠使用更強大的工具來做出更好的業務決策，這些更強大的工具用於獲取資料，轉移儲存的資料（例如聚合，豐富，變換等），以及使用低延遲的報告功能和商業智慧。

Q3.更智慧&更大的資料中心架構與傳統的資料倉儲架構有何不同？

傳統的企業資料倉儲架構

基於Hadoop的資料中心架構

Q4.基於Hadoop的資料中心的好處是什麼？

隨著資料量和複雜性的增加，提高了整體SLA（即服務水平協議）。例如，“Shared Nothing”架構，並行處理，記憶體密集型處理框架，如Spark和Impala，以及YARN容量排程程式中的資源搶佔。

縮放資料倉儲可能會很昂貴。新增額外的高階硬體容量以及獲取資料倉儲工具的許可證可能會顯著增加成本。基於Hadoop的解決方案不僅在商品硬體節點和開源工具方面更便宜，而且還可以通過將資料轉換解除安裝到Hadoop工具（如Spark和Impala）來補足資料倉儲解決方案，從而更高效地並行處理大資料。這也將釋放資料倉儲資源。

探索新的渠道和線索。Hadoop可以為資料科學家提供探索性的沙盒，以從社交媒體，日誌檔案，電子郵件等地方發現潛在的有價值的資料，這些資料通常在資料倉儲中不可得。

更好的靈活性。通常業務需求的改變，也需要對架構和報告進行更改。基於Hadoop的解決方案不僅可以靈活地處理不斷髮展的模式，還可以處理來自不同來源，如社交媒體，應用程式日誌檔案，image，PDF和文件檔案的半結構化和非結構化資料。

Q5.大資料解決方案的關鍵步驟是什麼？

提取資料，儲存資料（即資料建模）和處理資料（即資料加工，資料轉換和查詢資料）。

提取資料

從各種來源提取資料，例如：

1. RDBM（Relational Database Management Systems）關聯式資料庫管理系統，如Oracle，MySQL等。
2. ERPs（Enterprise Resource Planning）企業資源規劃（即ERP）系統，如SAP。
3. CRM（Customer Relationships Management）客戶關係管理系統，如Siebel，Salesforce等
4. 社交媒體Feed和日誌檔案。
5. 平面檔案，文件和影像。

並將其儲存在基於“Hadoop分散式檔案系統”（簡稱HDFS）的資料中心上。可以通過批處理作業（例如每15分鐘執行一次，每晚一次，等），近實時（即100毫秒至2分鐘）流式傳輸和實時流式傳輸（即100毫秒以下）去採集資料。

Hadoop中使用的一個常用術語是“Schema-On-Read”。這意味著未處理（也稱為原始）的資料可以被載入到HDFS，其具有基於處理應用的需求在處理之時應用的結構。這與“Schema-On-Write”不同，後者用於需要在載入資料之前在RDBM中定義模式。

儲存資料

資料可以儲存在HDFS或NoSQL資料庫，如HBase。HDFS針對順序訪問和“一次寫入和多次讀取”的使用模式進行了優化。HDFS具有很高的讀寫速率，因為它可以將I / O並行到多個驅動器。HBase在HDFS之上，並以柱狀方式將資料儲存為鍵/值對。列作為列家族在一起。HBase適合隨機讀/寫訪問。在Hadoop中儲存資料之前，你需要考慮以下幾點：

1. 資料儲存格式：有許多可以應用的檔案格式（例如CSV，JSON，序列，AVRO，Parquet等）和資料壓縮演算法（例如snappy，LZO，gzip，bzip2等）。每個都有特殊的優勢。像LZO和bzip2的壓縮演算法是可拆分的。
2. 資料建模：儘管Hadoop的無模式性質，模式設計依然是一個重要的考慮方面。這包括儲存在HBase，Hive和Impala中的物件的目錄結構和模式。Hadoop通常用作整個組織的資料中心，並且資料旨在共享。因此，結構化和有組織的資料儲存很重要。
3. 後設資料管理：與儲存資料相關的後設資料。
4. 多使用者：更智慧的資料中心託管多個使用者、組和應用程式。這往往導致與統治、標準化和管理相關的挑戰。

處理資料

Hadoop的處理框架使用HDFS。它使用“Shared Nothing”架構，在分散式系統中，每個節點完全獨立於系統中的其他節點。沒有共享資源，如CPU，記憶體以及會成為瓶頸的磁碟儲存。Hadoop的處理框架（如Spark，Pig，Hive，Impala等）處理資料的不同子集，並且不需要管理對共享資料的訪問。 “Shared Nothing”架構是非常可擴充套件的，因為更多的節點可以被新增而沒有更進一步的爭用和容錯，因為每個節點是獨立的，並且沒有單點故障，系統可以從單個節點的故障快速恢復。

Q6.你會如何選擇不同的檔案格式儲存和處理資料？

設計決策的關鍵之一是基於以下方面關注檔案格式：

1. 使用模式，例如訪問50列中的5列，而不是訪問大多數列。
2. 可並行處理的可分裂性。
3. 塊壓縮節省儲存空間vs讀/寫/傳輸效能
4. 模式演化以新增欄位，修改欄位和重新命名欄位。

CSV檔案

CSV檔案通常用於在Hadoop和外部系統之間交換資料。CSV是可讀和可解析的。 CSV可以方便地用於從資料庫到Hadoop或到分析資料庫的批量載入。在Hadoop中使用CSV檔案時，不包括頁首或頁尾行。檔案的每一行都應包含記錄。CSV檔案對模式評估的支援是有限的，因為新欄位只能附加到記錄的結尾，並且現有欄位不能受到限制。CSV檔案不支援塊壓縮，因此壓縮CSV檔案會有明顯的讀取效能成本。

JSON檔案

JSON記錄與JSON檔案不同；每一行都是其JSON記錄。由於JSON將模式和資料一起儲存在每個記錄中，因此它能夠實現完整的模式演進和可拆分性。此外，JSON檔案不支援塊級壓縮。

序列檔案

序列檔案以與CSV檔案類似的結構用二進位制格式儲存資料。像CSV一樣，序列檔案不儲存後設資料，因此只有模式進化才將新欄位附加到記錄的末尾。與CSV檔案不同，序列檔案確實支援塊壓縮。序列檔案也是可拆分的。序列檔案可以用於解決“小檔案問題”，方式是通過組合較小的通過儲存檔名作為鍵和檔案內容作為值的XML檔案。由於讀取序列檔案的複雜性，它們更適合用於在飛行中的（即中間的）資料儲存。

注意：序列檔案是以Java為中心的，不能跨平臺使用。

Avro檔案

適合於有模式的長期儲存。Avro檔案儲存具有資料的後設資料，但也允許指定用於讀取檔案的獨立模式。啟用完全的模式進化支援，允許你通過定義新的獨立模式重新命名、新增和刪除欄位以及更改欄位的資料型別。Avro檔案以JSON格式定義模式，資料將採用二進位制JSON格式。Avro檔案也是可拆分的，並支援塊壓縮。更適合需要行級訪問的使用模式。這意味著查詢該行中的所有列。不適用於行有50+列，但使用模式只需要訪問10個或更少的列。Parquet檔案格式更適合這個列訪問使用模式。

Columnar格式，例如RCFile，ORC

RDBM以面向行的方式儲存記錄，因為這對於需要在獲取許多列的記錄的情況下是高效的。如果在向磁碟寫入記錄時已知所有列值，則面向行的寫也是有效的。但是這種方法不能有效地獲取行中的僅10％的列或者在寫入時所有列值都不知道的情況。這是Columnar檔案更有意義的地方。所以Columnar格式在以下情況下工作良好

• 在不屬於查詢的列上跳過I / O和解壓縮
• 用於僅訪問列的一小部分的查詢。
• 用於資料倉儲型應用程式，其中使用者想要在大量記錄上聚合某些列。

RC和ORC格式是專門用Hive寫的而不是通用作為Parquet。

Parquet檔案

Parquet檔案是一個columnar檔案，如RC和ORC。Parquet檔案支援塊壓縮並針對查詢效能進行了優化，可以從50多個列記錄中選擇10個或更少的列。Parquet檔案寫入效能比非columnar檔案格式慢。Parquet通過允許在最後新增新列，還支援有限的模式演變。Parquet可以使用Avro API和Avro架構進行讀寫。

所以，總而言之，相對於其他，你應該會更喜歡序列，Avro和Parquet檔案格式；序列檔案用於原始和中間儲存，Avro和Parquet檔案用於處理。