你準(zhǔn)備好面試了嗎?呀，需要 Hadoop 的知識!!?不要慌!這里有一些可能會問到的問題以及你應(yīng)該給出的答案。

Q1.什么是 Hadoop?

Hadoop 是一個(gè)開源軟件框架，用于存儲大量數(shù)據(jù)，并發(fā)處理/查詢在具有多個(gè)商用硬件(即低成本硬件)節(jié)點(diǎn)的集群上的那些數(shù)據(jù)?？傊?，Hadoop 包括以下內(nèi)容：

HDFS(Hadoop Distributed File System，Hadoop 分布式文件系統(tǒng))：HDFS 允許你以一種分布式和冗余的方式存儲大量數(shù)據(jù)。例如，1 GB(即 1024 MB)文本文件可以拆分為 16 * 128MB 文件，并存儲在 Hadoop 集群中的 8 個(gè)不同節(jié)點(diǎn)上。每個(gè)分裂可以復(fù)制 3 次，以實(shí)現(xiàn)容錯，以便如果 1 個(gè)節(jié)點(diǎn)故障的話，也有備份。HDFS 適用于順序的“一次寫入、多次讀取”的類型訪問。

MapReduce：一個(gè)計(jì)算框架。它以分布式和并行的方式處理大量的數(shù)據(jù)。當(dāng)你對所有年齡> 18 的用戶在上述 1 GB 文件上執(zhí)行查詢時(shí)，將會有“8 個(gè)映射”函數(shù)并行運(yùn)行，以在其 128 MB 拆分文件中提取年齡> 18 的用戶，然后“reduce”函數(shù)將運(yùn)行以將所有單獨(dú)的輸出組合成單個(gè)最終結(jié)果。

YARN(Yet Another Resource Nagotiator，又一資源定位器)：用于作業(yè)調(diào)度和集群資源管理的框架。

Hadoop 生態(tài)系統(tǒng)，擁有 15 多種框架和工具，如 Sqoop，F(xiàn)lume，Kafka，Pig，Hive，Spark，Impala 等，以便將數(shù)據(jù)攝入 HDFS，在 HDFS 中轉(zhuǎn)移數(shù)據(jù)(即變換，豐富，聚合等)，并查詢來自 HDFS 的數(shù)據(jù)用于商業(yè)智能和分析。某些工具(如 Pig 和 Hive)是 MapReduce 上的抽象層，而 Spark 和 Impala 等其他工具則是來自 MapReduce 的改進(jìn)架構(gòu)/設(shè)計(jì)，用于顯著提高的延遲以支持近實(shí)時(shí)(即 NRT)和實(shí)時(shí)處理。

Q2.為什么組織從傳統(tǒng)的數(shù)據(jù)倉庫工具轉(zhuǎn)移到基于 Hadoop 生態(tài)系統(tǒng)的智能數(shù)據(jù)中心?

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

現(xiàn)有數(shù)據(jù)基礎(chǔ)設(shè)施：

1. 主要使用存儲在高端和昂貴硬件中的“structured data，結(jié)構(gòu)化數(shù)據(jù)”
2. 主要處理為 ETL 批處理作業(yè)，用于將數(shù)據(jù)提取到 RDBMS 和數(shù)據(jù)倉庫系統(tǒng)中進(jìn)行數(shù)據(jù)挖掘，分析和報(bào)告，以進(jìn)行關(guān)鍵業(yè)務(wù)決策。
3. 主要處理以千兆字節(jié)到兆字節(jié)為單位的數(shù)據(jù)量

基于 Hadoop 的更智能的數(shù)據(jù)基礎(chǔ)設(shè)施：

1. 其中結(jié)構(gòu)化(例如 RDBMS)，非結(jié)構(gòu)化(例如 images，PDF，docs )和半結(jié)構(gòu)化(例如 logs，XMLs)的數(shù)據(jù)可以以可擴(kuò)展和容錯的方式存儲在較便宜的商品機(jī)器中。
2. 可以通過批處理作業(yè)和近實(shí)時(shí)(即，NRT，200 毫秒至 2 秒)流(例如 Flume 和 Kafka)來攝取數(shù)據(jù)。
3. 數(shù)據(jù)可以使用諸如 Spark 和 Impala 之類的工具以低延遲(即低于 100 毫秒)的能力查詢。
4. 可以存儲以兆兆字節(jié)到千兆字節(jié)為單位的較大數(shù)據(jù)量。

這使得組織能夠使用更強(qiáng)大的工具來做出更好的業(yè)務(wù)決策，這些更強(qiáng)大的工具用于獲取數(shù)據(jù)，轉(zhuǎn)移存儲的數(shù)據(jù)(例如聚合，豐富，變換等)，以及使用低延遲的報(bào)告功能和商業(yè)智能。

Q3.更智能&更大的數(shù)據(jù)中心架構(gòu)與傳統(tǒng)的數(shù)據(jù)倉庫架構(gòu)有何不同?

傳統(tǒng)的企業(yè)數(shù)據(jù)倉庫架構(gòu)

基于 Hadoop 的數(shù)據(jù)中心架構(gòu)

Q4.基于 Hadoop 的數(shù)據(jù)中心的好處是什么?

隨著數(shù)據(jù)量和復(fù)雜性的增加，提高了整體 SLA(即服務(wù)水平協(xié)議)。例如，“Shared Nothing”架構(gòu)，并行處理，內(nèi)存密集型處理框架，如 Spark 和 Impala，以及 YARN 容量調(diào)度程序中的資源搶占。

縮放數(shù)據(jù)倉庫可能會很昂貴。添加額外的高端硬件容量以及獲取數(shù)據(jù)倉庫工具的許可證可能會顯著增加成本?；?Hadoop 的解決方案不僅在商品硬件節(jié)點(diǎn)和開源工具方面更便宜，而且還可以通過將數(shù)據(jù)轉(zhuǎn)換卸載到 Hadoop 工具(如 Spark 和 Impala)來補(bǔ)足數(shù)據(jù)倉庫解決方案，從而更高效地并行處理大數(shù)據(jù)。這也將釋放數(shù)據(jù)倉庫資源。

探索新的渠道和線索。Hadoop 可以為數(shù)據(jù)科學(xué)家提供探索性的沙盒，以從社交媒體，日志文件，電子郵件等地方發(fā)現(xiàn)潛在的有價(jià)值的數(shù)據(jù)，這些數(shù)據(jù)通常在數(shù)據(jù)倉庫中不可得。

更好的靈活性。通常業(yè)務(wù)需求的改變，也需要對架構(gòu)和報(bào)告進(jìn)行更改?；?Hadoop 的解決方案不僅可以靈活地處理不斷發(fā)展的模式，還可以處理來自不同來源，如社交媒體，應(yīng)用程序日志文件，image，PDF 和文檔文件的半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

Q5.大數(shù)據(jù)解決方案的關(guān)鍵步驟是什么?

提取數(shù)據(jù)，存儲數(shù)據(jù)(即數(shù)據(jù)建模)和處理數(shù)據(jù)(即數(shù)據(jù)加工，數(shù)據(jù)轉(zhuǎn)換和查詢數(shù)據(jù))。

提取數(shù)據(jù)

從各種來源提取數(shù)據(jù)，例如：

RDBM(Relational Database Management Systems)關(guān)系數(shù)據(jù)庫管理系統(tǒng)，如 Oracle，MySQL 等。

ERPs(Enterprise Resource Planning)企業(yè)資源規(guī)劃(即 ERP)系統(tǒng)，如 SAP。

CRM(Customer Relationships Management)客戶關(guān)系管理系統(tǒng)，如 Siebel，Salesforce 等

社交媒體 Feed 和日志文件。

平面文件，文檔和圖像。

并將其存儲在基于“Hadoop 分布式文件系統(tǒng)”(簡稱 HDFS)的數(shù)據(jù)中心上?？梢酝ㄟ^批處理作業(yè)(例如每 15 分鐘運(yùn)行一次，每晚一次，等)，近實(shí)時(shí)(即 100 毫秒至 2 分鐘)流式傳輸和實(shí)時(shí)流式傳輸(即 100 毫秒以下)去采集數(shù)據(jù)。

Hadoop 中使用的一個(gè)常用術(shù)語是“Schema-On-Read”。這意味著未處理(也稱為原始)的數(shù)據(jù)可以被加載到 HDFS，其具有基于處理應(yīng)用的需求在處理之時(shí)應(yīng)用的結(jié)構(gòu)。這與“Schema-On-Write”不同，后者用于需要在加載數(shù)據(jù)之前在 RDBM 中定義模式。

存儲數(shù)據(jù)

數(shù)據(jù)可以存儲在 HDFS 或 NoSQL 數(shù)據(jù)庫，如 HBase。HDFS 針對順序訪問和“一次寫入和多次讀取”的使用模式進(jìn)行了優(yōu)化。HDFS 具有很高的讀寫速率，因?yàn)樗梢詫?I / O 并行到多個(gè)驅(qū)動器。HBase 在 HDFS 之上，并以柱狀方式將數(shù)據(jù)存儲為鍵/值對。列作為列家族在一起。HBase 適合隨機(jī)讀/寫訪問。在 Hadoop 中存儲數(shù)據(jù)之前，你需要考慮以下幾點(diǎn)：

1. 數(shù)據(jù)存儲格式：有許多可以應(yīng)用的文件格式(例如 CSV，JSON，序列，AVRO，Parquet 等)和數(shù)據(jù)壓縮算法(例如 snappy，LZO，gzip，bzip2 等)。每個(gè)都有特殊的優(yōu)勢。像 LZO 和 bzip2 的壓縮算法是可拆分的。
2. 數(shù)據(jù)建模：盡管 Hadoop 的無模式性質(zhì)，模式設(shè)計(jì)依然是一個(gè)重要的考慮方面。這包括存儲在 HBase，Hive 和 Impala 中的對象的目錄結(jié)構(gòu)和模式。Hadoop 通常用作整個(gè)組織的數(shù)據(jù)中心，并且數(shù)據(jù)旨在共享。因此，結(jié)構(gòu)化和有組織的數(shù)據(jù)存儲很重要。
3. 元數(shù)據(jù)管理：與存儲數(shù)據(jù)相關(guān)的元數(shù)據(jù)。
4. 多用戶：更智能的數(shù)據(jù)中心托管多個(gè)用戶、組和應(yīng)用程序。這往往導(dǎo)致與統(tǒng)治、標(biāo)準(zhǔn)化和管理相關(guān)的挑戰(zhàn)。

處理數(shù)據(jù)

Hadoop 的處理框架使用 HDFS。它使用“Shared Nothing”架構(gòu)，在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)完全獨(dú)立于系統(tǒng)中的其他節(jié)點(diǎn)。沒有共享資源，如 CPU，內(nèi)存以及會成為瓶頸的磁盤存儲。Hadoop 的處理框架(如 Spark，Pig，Hive，Impala 等)處理數(shù)據(jù)的不同子集，并且不需要管理對共享數(shù)據(jù)的訪問。 “Shared Nothing”架構(gòu)是非?？蓴U(kuò)展的，因?yàn)楦嗟墓?jié)點(diǎn)可以被添加而沒有更進(jìn)一步的爭用和容錯，因?yàn)槊總€(gè)節(jié)點(diǎn)是獨(dú)立的，并且沒有單點(diǎn)故障，系統(tǒng)可以從單個(gè)節(jié)點(diǎn)的故障快速恢復(fù)。

Q6.你會如何選擇不同的文件格式存儲和處理數(shù)據(jù)?

設(shè)計(jì)決策的關(guān)鍵之一是基于以下方面關(guān)注文件格式：

使用模式，例如訪問 50 列中的 5 列，而不是訪問大多數(shù)列。

可并行處理的可分裂性。

塊壓縮節(jié)省存儲空間 vs 讀/寫/傳輸性能

模式演化以添加字段，修改字段和重命名字段。

CSV 文件

CSV 文件通常用于在 Hadoop 和外部系統(tǒng)之間交換數(shù)據(jù)。CSV 是可讀和可解析的。 CSV 可以方便地用于從數(shù)據(jù)庫到 Hadoop 或到分析數(shù)據(jù)庫的批量加載。在 Hadoop 中使用 CSV 文件時(shí)，不包括頁眉或頁腳行。文件的每一行都應(yīng)包含記錄。CSV 文件對模式評估的支持是有限的，因?yàn)樾伦侄沃荒芨郊拥接涗浀慕Y(jié)尾，并且現(xiàn)有字段不能受到限制。CSV 文件不支持塊壓縮，因此壓縮 CSV 文件會有明顯的讀取性能成本。

JSON 文件

JSON 記錄與 JSON 文件不同;每一行都是其 JSON 記錄。由于 JSON 將模式和數(shù)據(jù)一起存儲在每個(gè)記錄中，因此它能夠?qū)崿F(xiàn)完整的模式演進(jìn)和可拆分性。此外，JSON 文件不支持塊級壓縮。

序列文件

序列文件以與 CSV 文件類似的結(jié)構(gòu)用二進(jìn)制格式存儲數(shù)據(jù)。像 CSV 一樣，序列文件不存儲元數(shù)據(jù)，因此只有模式進(jìn)化才將新字段附加到記錄的末尾。與 CSV 文件不同，序列文件確實(shí)支持塊壓縮。序列文件也是可拆分的。序列文件可以用于解決“小文件問題”，方式是通過組合較小的通過存儲文件名作為鍵和文件內(nèi)容作為值的 XML 文件。由于讀取序列文件的復(fù)雜性，它們更適合用于在飛行中的(即中間的)數(shù)據(jù)存儲。

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

Avro 文件

適合于有模式的長期存儲。Avro 文件存儲具有數(shù)據(jù)的元數(shù)據(jù)，但也允許指定用于讀取文件的獨(dú)立模式。啟用完全的模式進(jìn)化支持，允許你通過定義新的獨(dú)立模式重命名、添加和刪除字段以及更改字段的數(shù)據(jù)類型。Avro 文件以 JSON 格式定義模式，數(shù)據(jù)將采用二進(jìn)制 JSON 格式。Avro 文件也是可拆分的，并支持塊壓縮。更適合需要行級訪問的使用模式。這意味著查詢該行中的所有列。不適用于行有 50+ 列，但使用模式只需要訪問 10 個(gè)或更少的列。Parquet 文件格式更適合這個(gè)列訪問使用模式。

Columnar 格式，例如 RCFile，ORC

RDBM 以面向行的方式存儲記錄，因?yàn)檫@對于需要在獲取許多列的記錄的情況下是高效的。如果在向磁盤寫入記錄時(shí)已知所有列值，則面向行的寫也是有效的。但是這種方法不能有效地獲取行中的僅 10% 的列或者在寫入時(shí)所有列值都不知道的情況。這是 Columnar 文件更有意義的地方。所以 Columnar 格式在以下情況下工作良好

在不屬于查詢的列上跳過 I / O 和解壓縮

用于僅訪問列的一小部分的查詢。

用于數(shù)據(jù)倉庫型應(yīng)用程序，其中用戶想要在大量記錄上聚合某些列。

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

Parquet 文件

Parquet 文件是一個(gè) columnar 文件，如 RC 和 ORC。Parquet 文件支持塊壓縮并針對查詢性能進(jìn)行了優(yōu)化，可以從 50 多個(gè)列記錄中選擇 10 個(gè)或更少的列。Parquet 文件寫入性能比非 columnar 文件格式慢。Parquet 通過允許在最后添加新列，還支持有限的模式演變。Parquet 可以使用 Avro API 和 Avro 架構(gòu)進(jìn)行讀寫。

所以，總而言之，相對于其他，你應(yīng)該會更喜歡序列，Avro 和 Parquet 文件格式;序列文件用于原始和中間存儲，Avro 和 Parquet 文件用于處理。