大數據hadoop實訓總結

1. 技術干貨：SQL on Hadoop在快手大數據平台的實踐與優化

快手大數據架構工程師鍾靚近日在 A2M 人工智慧與機器學習創新峰會分享了題為《SQL on Hadoop 在快手大數據平台的實踐與優化》的演講，主要從 SQL on Hadoop 介紹、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用經驗和改進分析、快手 SQL on Hadoop 的未來計劃四方面介紹了 SQL on Hadoop 架構。

SQL on Hadoop，顧名思義它是基於 Hadoop 生態的一個 SQL 引擎架構，我們其實常常聽到 Hive、SparkSQL、Presto、Impala 架構。接下來，我會簡單的描述一下常用的架構情況。

HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，通過 SQL 對大規模的分布式存儲數據進行讀、寫、管理。

根據定義的數據模式，以及輸出 Storage，它會對輸入的 SQL 經過編譯、優化，生成對應引擎的任務，然後調度執行生成的任務。

HIVE 當前支持的引擎類型有：MR、SPARK、TEZ。

基於 HIVE 本身的架構，還有一些額外的服務提供方式，比如 HiveServer2 與 MetaStoreServer 都是 Thrift 架構。

此外，HiveServer2 提供遠程客戶端提交 SQL 任務的功能，MetaStoreServer 則提供遠程客戶端操作元數據的功能。

Spark，一個快速、易用，以 DAG 作為執行模式的大規模數據處理的統一分析引擎，主要模塊分為 SQL 引擎、流式處理 、機器學習、圖處理。

SPARKSQL 基於 SPARK 的計算引擎，做到了統一數據訪問，集成 Hive，支持標准 JDBC 連接。SPARKSQL 常用於數據交互分析的場景。

SPARKSQL 的主要執行邏輯，首先是將 SQL 解析為語法樹，然後語義分析生成邏輯執行計劃，接著與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯為物理執行計劃，即 RDD lineage，並執行任務。

PRESTO，一個互動式分析查詢的開源分布式 SQL 查詢引擎。

因為基於內存計算，PRESTO 的計算性能大於有大量 IO 操作的 MR 和 SPARK 引擎。它有易於彈性擴展，支持可插拔連接的特點。

業內的使用案例很多，包括 FaceBook、AirBnb、美團等都有大規模的使用。

我們看到這么多的 SQL on Hadoop 架構，它側面地說明了這種架構比較實用且成熟。利用 SQL on Hadoop 架構，我們可以實現支持海量數據處理的需求。

查詢平台每日 SQL 總量在 70 萬左右，DQL 的總量在 18 萬左右。AdHoc 集群主要用於交互分析及機器查詢，DQL 平均耗時為 300s；AdHoc 在內部有 Loacl 任務及加速引擎應用，所以查詢要求耗時較低。

ETL 集群主要用於 ETL 處理以及報表的生成。DQL 平均耗時為 1000s，DQL P50 耗時為 100s，DQL P90 耗時為 4000s，除上述兩大集群外，其它小的集群主要用於提供給單獨的業務來使用。

服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL 平台、AdHoc 平台以及用戶程序。在調度上層，同樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到 HDFS 里，我們後續會再對它進行清洗處理；服務打點的數據以及資料庫信息，則會通過同步服務入到對應的數據源里，且我們會將元數據信息存在後端元數據系統中。

網頁爬取的數據會存入 hbase，後續也會進行清洗與處理。

HUE、NoteBook 主要提供的是互動式查詢的系統。報表系統、BI 系統主要是 ETL 處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手現在的引擎支持 MR、Presto 及 Spark。

管理系統主要用於管理我們當前的集群。HiveServer2 集群路由系統，主要用於引擎的選擇。監控系統以及運維系統，主要是對於 HiveServer2 引擎進行運維。

我們在使用 HiveServer2 過程中，遇到過很多問題。接下來，我會詳細的為大家闡述快手是如何進行優化及實踐的。

當前有多個 HiveServer2 集群，分別是 AdHoc 與 ETL 兩大集群，以及其他小集群。不同集群有對應的連接 ZK，客戶端可通過 ZK 連接 HiveServer2 集群。

為了保證核心任務的穩定性，將 ETL 集群進行了分級，分為核心集群和一般集群。在客戶端連接 HS2 的時候，我們會對任務優先順序判定，高優先順序的任務會被路由到核心集群，低優先順序的任務會被路由到一般集群。

BeaconServer 服務為後端 Hook Server 服務，配合 HS2 中的 Hook，在 HS2 服務之外實現了所需的功能。當前支持的模塊包括路由、審計、SQL 重寫、任務控制、錯誤分析、優化建議等。

•無狀態，BeaconServer 服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。

•配置動態載入，BeaconServer 服務支持動態配置載入。各個模塊支持開關，服務可動態載入配置實現上下線。比如路由模塊，可根據後端加速引擎集群資源情況，進行路由比率調整甚至熔斷。

•無縫升級，BeaconServer 服務的後端模塊可單獨進行下線升級操作，不會影響 Hook 端 HS2 服務。

•Hive 支持 SPARK 與 TEZ 引擎，但不適用於生產環境。

•SQL on Hadoop 的 SQL 引擎各有優缺點，用戶學習和使用的門檻較高。

•不同 SQL 引擎之間的語法和功能支持上存在差異，需要大量的測試和兼容工作，完全兼容的成本較高。

•不同 SQL 引擎各自提供服務會給數倉的血緣管理、許可權控制、運維管理、資源利用都帶來不便。

•在 Hive 中，自定義實現引擎。

•自動路由功能，不需要設置引擎，自動選擇適合的加速引擎。

•根絕規則匹配 SQL，只將兼容的 SQL 推給加速引擎。

•復用 HiveServer2 集群架構。

基於 HiveServer2，有兩種實現方式。JDBC 方式是通過 JDBC 介面，將 SQL 發送至後端加速引擎啟動的集群上。PROXY 方式是將 SQL 下推給本地的加速引擎啟動的 Client。

JDBC 方式啟動的後端集群，均是基於 YARN，可以實現資源的分時復用。比如 AdHoc 集群的資源在夜間會自動回收，作為報表系統的資源進行復用。

路由方案基於 HS2 的 Hook 架構，在 HS2 端實現對應 Hook，用於引擎切換；後端 BeaconServer 服務中實現路由 服務，用於 SQL 的路由規則的匹配處理。不同集群可配置不同的路由規則。

為了保證後算路由服務的穩定性，團隊還設計了 Rewrite Hook，用於重寫 AdHoc 集群中的 SQL，自動添加 LIMIT 上限，防止大數據量的 SCAN。

•易於集成，當前主流的 SQL 引擎都可以方便的實現 JDBC 與 PROXY 方式。再通過配置，能簡單的集成新的查詢引擎，比如 impala、drill 等。

•自動選擇引擎，減少了用戶的引擎使用成本，同時也讓遷移變得更簡單。並且在加速引擎過載 的情況下，可以動態調整比例，防止因過載 對加速性能的影響。

•自動降級，保證了運行的可靠性。SQL 路由支持 failback 模塊，可以根據配置選擇是否再路由引擎執行失敗後，回滾到 MR 運行。

•模塊復用，對於新增的引擎，都可以復用 HiveServer2 定製的血緣採集、許可權認證、並發鎖控制等方案，大大降低了使用成本。

•資源復用，對於 adhoc 查詢佔用資源可以分時動態調整，有效保證集群資源的利用率。

當查詢完成後，本地會輪詢結果文件，一直獲取到 LIMIT 大小，然後返回。這種情況下，當有大量的小文件存在，而大文件在後端的時候，會導致 Bad Case，不停與 HDFS 交互，獲取文件信息以及文件數據，大大拉長運行時間。

在 Fetch 之前，對結果文件的大小進行預排序，可以有數百倍的性能提升。

示例：當前有 200 個文件。199 個小文件一條記錄 a，1 個大文件混合記錄 a 與 test 共 200 條，大文件名 index 在小文件之後。

Hive 中有一個 SimpleFetchOptimizer 優化器，會直接生成 FetchTask，減小資源申請時間與調度時間。但這個優化會出現瓶頸。如果數據量小，但是文件數多，需要返回的條數多，存在能大量篩掉結果數據的 Filter 條件。這時候串列讀取輸入文件，導致查詢延遲大，反而沒起到加速效果。

在 SimpleFetchOptimizer 優化器中，新增文件數的判斷條件，最後將任務提交到集群環境，通過提高並發來實現加速。

示例：讀取當前 500 個文件的分區。優化後的文件數閾值為 100。

一個表有大量的子分區，它的 DESC 過程會與元數據交互，獲取所有的分區。但最後返回的結果，只有跟表相關的信息。

與元數據交互的時候，延遲了整個 DESC 的查詢，當元數據壓力大的時候甚至無法返回結果。

針對於 TABLE 的 DESC 過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。

示例：desc 十萬分區的大表。

•復用 split 計算的數據，跳過 rece 估算重復統計輸入過程。輸入數據量大的任務，調度速率提升 50%。

•parquetSerde init 加速，跳過同一表的重復列剪枝優化，防止 map task op init 時間超時。

•新增 LazyOutputFormat，有 record 輸出再創建文件，避免空文件的產生，導致下游讀取大量空文件消耗時間。

•statsTask 支持多線程聚合統計信息，防止中間文件過多導致聚合過慢，增大運行時間。

•AdHoc 需要打開並行編譯，防止 SQL 串列編譯導致整體延遲時間增大的問題。

HS2 啟動時會對物化視圖功能進行初始化，輪詢整個元資料庫，導致 HS2 的啟動時間非常長，從下線狀態到重新上線間隔過大，可用性很差。

將物化視圖功能修改為延遲懶載入，單獨線程載入，不影響 HS2 的服務啟動。物化視圖支持載入中獲取已緩存信息，保證功能的可用性。

HS2 啟動時間從 5min+提升至<5s。

HS2 本身上下線成本較高，需要保證服務上的任務全部執行完成才能進行操作。配置的修改可作為較高頻率的操作，且需要做到熱載入。

在 HS2 的 ThriftServer 層我們增加了介面，與運維系統打通後，配置下推更新的時候自動調用，可實現配置的熱載入生效。

HiveServer2 的 scratchdir 主要用於運行過程中的臨時文件存儲。當 HS2 中的會話創建時，便會創建 scratchdir。在 HDFS 壓力大的時候，大量的會話會阻塞在創建 scratchdir 過程，導致連接數堆積至上限，最終 HS2 服務無法再連入新連接，影響服務可用性。

對此，我們先分離了一般查詢與 create temporay table 查詢的 scratch 目錄，並支持 create temporay table 查詢的 scratch 的懶創建。當 create temporay table 大量創建臨時文件，便會影響 HDFS NameNode 延遲時間的時候，一般查詢的 scratchdir HDFS NameNode 可以正常響應。

此外，HS2 還支持配置多 scratch，不同的 scratch 能設置載入比率，從而實現 HDFS 的均衡負載。

Hive 調度其中存在兩個問題。

一、子 Task 非執行狀態為完成情況的時候，若有多輪父 Task 包含子 Task，導致子 Task 被重復加入調度隊列。這種 Case，需要將非執行狀態修改成初始化狀態。

二、當判斷子 Task 是否可執行的過程中，會因為狀態檢測異常，無法正常加入需要調度的子 Task，從而致使查詢丟失 Stage。而這種 Case，我們的做法是在執行完成後，加入一輪 Stage 的執行結果狀態檢查，一旦發現有下游 Stage 沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。

•HS2 實現了介面終止查詢 SQL。利用這個功能，可以及時終止異常 SQL。

•metastore JDOQuery 查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。

•增加開關控制，強制覆蓋外表目錄，解決 insert overwrite 外表，文件 rename 報錯的問題。

•hive parquet 下推增加關閉配置，避免 parquet 異常地下推 OR 條件，導致結果不正確。

•executeForArray 函數 join 超大字元串導致 OOM，增加限制優化。

•增加根據 table 的 schema 讀取分區數據的功能，避免未級聯修改分區 schema 導致讀取數據異常。

•部分用戶並沒有開發經驗，無法處理處理引擎返回的報錯。

•有些錯誤的報錯信息不明確，用戶無法正確了解錯誤原因。

•失敗的任務排查成本高，需要對 Hadoop 整套系統非常熟悉。

•用戶的錯誤 SQL、以及需要優化的 SQL，大量具有共通性。人力維護成本高，但系統分析成本低。

SQL 專家系統基於 HS2 的 Hook 架構，在 BeaconServer 後端實現了三個主要的模塊，分別是 SQL 規則控制模塊、SQL 錯誤分析模塊，與 SQL 優化建議模塊。SQL 專家系統的知識庫，包含關鍵字、原因說明、處理方案等幾項主要信息，存於後端資料庫中，並一直積累。

通過 SQL 專家系統，後端可以進行查詢 SQL 的異常控制，避免異常 SQL 的資源浪費或者影響集群穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減少了使用成本。

示例：空分區查詢控制。

SQL 專家系統能解決一部分 HS2 的任務執行的錯誤診斷需求，但是比如作業 健康 度、任務執行異常等問題原因的判斷，需要專門的系統來解決，為此我們設計了作業診斷系統。

作業診斷系統在 YARN 的層面，針對不同的執行引擎，對搜集的 Counter 和配置進行分析。在執行層面，提出相關的優化建議。

作業診斷系統的數據也能通過 API 提供給 SQL 專家系統，補充用於分析的問題原因。

作業診斷系統提供了查詢頁面來查詢運行的任務。以下是命中 map 輸入過多規則的任務查詢過程：

2. 大數據應用的實訓目的萬能版怎麼寫

分塊書寫。大數據實訓教學大綱一、實訓目標 基於Hadoop為核心，通過實猜橘訓，達成以下目的，認識大數據，認識大數據技術在新時代對企業的重要性。大數據應用，是指大數據價值創造的關鍵在於大數據的應用，隨著大數畢兆帶據技術飛速發展，大手蘆數據應用已經融入各行各業。

3. 什麼是大數據分析Hadoop

要了解什麼是Hadoop，我們必須首先了解與大數據和傳統處理系統有關的問題。前進，我們將討論什麼是Hadoop，以及Hadoop如何解決與大數據相關的問題。我們還將研究CERN案例研究，以突出使用Hadoop的好處。

在之前的博客「 大數據教程」中，我們已經詳細討論了大數據以及大數據的挑戰。在此博客中，我們將討論：

1、傳統方法的問題

2、Hadoop的演變

3、Hadoop的

4、Hadoop即用解決方案

5、何時使用Hadoop?

6、什麼時候不使用Hadoop?

一、CERN案例研究

大數據正在成為組織的機會。現在，組織已經意識到他們可以通過大數據分析獲得很多好處，如下圖所示。他們正在檢查大型數據集，以發現所有隱藏的模式，未知的相關性，市場趨勢，客戶偏好和其他有用的業務信息。

這些分析結果正在幫助組織進行更有效的營銷，新的收入機會，更好的客戶服務。他們正在提高運營效率，與競爭對手組織相比的競爭優勢以及其他業務利益。

什麼是Hadoop –大數據分析的好處

因此，讓我們繼續前進，了解在兌現大數據機會方面與傳統方法相關的問題。

二、傳統方法的問題

在傳統方法中，主要問題是處理數據的異構性，即結構化，半結構化和非結構化。RDBMS主要關注於銀行交易，運營數據等結構化數據，而Hadoop則專注於文本，視頻，音頻，Facebook帖子，日誌等半結構化，非結構化數據。RDBMS技術是一種經過驗證的，高度一致，成熟的系統許多公司的支持。另一方面，由於大數據(主要由不同格式的非結構化數據組成)對Hadoop提出了需求。

現在讓我們了解與大數據相關的主要問題是什麼。因此，繼續前進，我們可以了解Hadoop是如何成為解決方案的。

什麼是Hadoop –大數據問題

第一個問題是存儲大量數據。

無法在傳統系統中存儲大量數據。原因很明顯，存儲將僅限於一個系統，並且數據正在以驚人的速度增長。

第二個問題是存儲異構數據。

現在，我們知道存儲是一個問題，但是讓我告訴您，這只是問題的一部分。由於我們討論了數據不僅龐大，而且還以各種格式存在，例如：非結構化，半結構化和結構化。因此，您需要確保您擁有一個系統來存儲從各種來源生成的所有這些種類的數據。

第三個問題是訪問和處理速度。

硬碟容量正在增加，但磁碟傳輸速度或訪問速度並未以相似的速度增加。讓我以一個示例為您進行解釋：如果您只有一個100 Mbps I / O通道，並且正在處理1TB數據，則大約需要2.91個小時。現在，如果您有四台具有一個I / O通道的計算機，則對於相同數量的數據，大約需要43分鍾。因此，與存儲大數據相比，訪問和處理速度是更大的問題。

在了解什麼是Hadoop之前，讓我們首先了解一下Hadoop在一段時間內的發展。

Hadoop的演變

2003年，道格·切特(Doug Cutting)啟動了Nutch項目，以處理數十億次搜索並為數百萬個網頁建立索引。2003年10月下旬– Google發布帶有GFS(Google文件系統)的論文。2004年12月，Google發布了MapRece論文。在2005年，Nutch使用GFS和MapRece進行操作。2006年，雅虎與Doug Cutting及其團隊合作，基於GFS和MapRece創建了Hadoop。如果我告訴您，您會感到驚訝，雅虎於2007年開始在1000個節點的群集上使用Hadoop。

2008年1月下旬，雅虎向Apache Software Foundation發布了Hadoop作為一個開源項目。2008年7月，Apache通過Hadoop成功測試了4000個節點的集群。2009年，Hadoop在不到17小時的時間內成功整理了PB級數據，以處理數十億次搜索並為數百萬個網頁建立索引。在2011年12月，Apache Hadoop發布了1.0版。2013年8月下旬，發布了2.0.6版。

當我們討論這些問題時，我們發現分布式系統可以作為解決方案，而Hadoop提供了相同的解決方案。現在，讓我們了解什麼是Hadoop。

三、什麼是Hadoop?

Hadoop是一個框架，它允許您首先在分布式環境中存儲大數據，以便可以並行處理它。 Hadoop中基本上有兩個組件：

1、大數據Hadoop認證培訓

2、講師指導的課程現實生活中的案例研究評估終身訪問探索課程

什麼是Hadoop – Hadoop即解決方案

第一個問題是存儲大數據。

HDFS提供了一種分布式大數據存儲方式。您的數據存儲在整個DataNode的塊中，您可以指定塊的大小。基本上，如果您擁有512MB的數據，並且已經配置了HDFS，那麼它將創建128MB的數據塊。 因此，HDFS將數據分為512/128 = 4的4個塊，並將其存儲在不同的DataNode上，還將在不同的DataNode上復制數據塊。現在，由於我們正在使用商品硬體，因此存儲已不是難題。

它還解決了縮放問題。它著重於水平縮放而不是垂直縮放。您始終可以根據需要隨時在HDFS群集中添加一些額外的數據節點，而不是擴展DataNodes的資源。讓我為您總結一下，基本上是用於存儲1 TB的數據，您不需要1 TB的系統。您可以在多個128GB或更少的系統上執行此操作。

下一個問題是存儲各種數據。

藉助HDFS，您可以存儲各種數據，無論是結構化，半結構化還是非結構化。由於在HDFS中，沒有預轉儲模式驗證。並且它也遵循一次寫入和多次讀取模型。因此，您只需寫入一次數據，就可以多次讀取數據以尋找見解。

Hird的挑戰是訪問和處理數據更快。

是的，這是大數據的主要挑戰之一。為了解決該問題，我們將處理移至數據，而不是將數據移至處理。這是什麼意思?而不是將數據移動到主節點然後進行處理。在MapRece中，處理邏輯被發送到各個從屬節點，然後在不同的從屬節點之間並行處理數據。然後，將處理後的結果發送到主節點，在該主節點上合並結果，並將響應發送回客戶端。

在YARN架構中，我們有ResourceManager和NodeManager。ResourceManager可能會或可能不會與NameNode配置在同一台機器上。 但是，應該將NodeManager配置在存在DataNode的同一台計算機上。

YARN通過分配資源和安排任務來執行您的所有處理活動。

什麼是Hadoop – YARN

它具有兩個主要組件，即ResourceManager和NodeManager。

ResourceManager再次是主節點。它接收處理請求，然後將請求的各個部分相應地傳遞到相應的NodeManager，什麼是大數據分析Hadoop在此進行實際處理。NodeManager安裝在每個DataNode上。它負責在每個單個DataNode上執行任務。

我希望現在您對什麼是Hadoop及其主要組件有所了解。讓我們繼續前進，了解何時使用和何時不使用Hadoop。

何時使用Hadoop?

Hadoop用於：

1、搜索 – Yahoo，亞馬遜，Zvents

2、日誌處理 – Facebook，雅虎

3、數據倉庫 – Facebook，AOL

4、視頻和圖像分析 –紐約時報，Eyealike

到目前為止，我們已經看到了Hadoop如何使大數據處理成為可能。但是在某些情況下，不建議使用Hadoop。

4. 大數據 hadoop 三種運行模式的區別、及詳細配置講解

基於Hadoop進行開發時，有時候會被Hadoop的運行模式弄得暈頭轉向，傻傻分不清各種運行模式的區別，給日常開發帶來很多困惑，不同集群配置文件也各不相不同。弄明白Hadoop的運行模式和對配置文件的作用要做到心中明了，在工作中才能得手順心。

hadoop的配置文件均以XML文件進行配置，它有四個最常見的配置文件，分別為：

core-site.xml文件主要用於配置通用屬性。

hdfs-site.xml文件用於配置Hdfs的屬性。

mapred-site.xml文件用於配置Maprece的屬性。

yarn-site.xml文件用於配置Yarn的屬性。

一般來說，這四種配置文件都存儲在hadoop默認的安裝目錄etc/hadoop子目錄中。 不過我們也可以在搭建集群時根據實際需求，把etc/hadoop目錄和其下的文件復制到另外一個位置。這樣可以把配置文件和安裝文件分離開來，方便管理。

注意：如果把etc/hadoop目錄和其下的文件復制到另外一個位置。
我們需要在環境變數中將hadoop_conf_dir設置成指向新目錄。

1、本地運行模式

無需任何守護進程 ，所有的程序都運行在同一個JVM上執行。在本地模式下調試MR程序非常高效方便，一般該模式主要是在學習或者開發階段調試使用 。

2、偽分布式模式

Hadoop守護進程運行在本地機器上 ，模擬一個小規模的集群，換句話說，可以配置一台機器的Hadoop集群，偽分布式是完全分布式的一個特例。

3、完全分布式模式

Hadoop守護進程運行在一個集群上 。這種運行模式也就是我們常見的各種雲，主要用於大規模的生產環境中。

注意：分布式要啟動守護進程 ，是指在使用分布式hadoop時，要先啟動一些准備程序進程，然後才能使用。 比如start-dfs.sh start-yarn.sh，而本地模式不需要啟動這些守護進程。

注意：在本地模式下，將使用本地文件系統和本地MapRece運行器。在分布式模式下，將啟動HDFS和YARN守護進程。

5. Hadoop常見問題解答

Hadoop常見問題解答
（1）Hadoop適不適用於電子政務？為什麼？
電子政務是利用互聯網技術實現政府組織結構和工作流程的重組優化，建成一個精簡、高效、廉潔、公平的政府運作信息服務平台。因此電子政務肯定會產生相關的大量數據以及相應的計算需求，而這兩種需求涉及的數據和計算達到一定規模時傳統的系統架構將不能滿足，就需要藉助海量數據處理平台，例如Hadoop技術，因此可以利用Hadoop技術來構建電子政務雲平台。

總結一下，任何系統沒有絕對的適合和不適合，只有當需求出現時才可以決定，在一個非常小的電子政務系統上如果沒有打數據處理以及計算分析需求時就不需要hadoop這樣的技術，而實際上，商用的電子政務平台往往涉及到大規模的數據和大量的計算分析處理需求，因此就需要Hadoop這樣的技術來解決。（2）hadoop對於實時在線處理有優勢嗎？
直接使用hadoop進行實時處理時沒有優勢的，因為Hadoop主要解決的是海量批處理作業計算問題，但是可以使用基於Hadoop的分布式NOSQL系統HBase系統以及相關實時處理系統：
1. 基於Hadoop的HBase可以做到實時處理以及相關需求的實時計算，主要解決海量<key,value>相關查詢計算等需求。
2. 可以考慮Spark計算，Spark是基於共現內存RDD的系統，比Hadoop更快，時候迭代式計算，例如數據挖掘，機器學習演算法等。
3. 還有Storm，Storm是一個免費開源、分布式、高容錯的實時計算系統，Storm經常用於在實時分析、在線機器學習、持續計算、分布式遠程調用和ETL等領域。
4. 考慮S4， S4是Yahoo!在2010年10月開源的一套通用、分布式、可擴展、部分容錯、具備可插拔功能的平台。這套平台主要是為了方便開發者開發處理流式數據（continuous unbounded streams of data）的應用。
你可以依據實際的需求來選擇合適的系統。
（3）Hadoop存儲海量數據沒有問題，但是如何能夠做到海量數據的實時檢索？
1,可以結合開源的搜索引擎Apache Lucene，Solr 或ElasticSearch
2,海量數據的實時檢索可以考慮HBase，建議可以使用hadoop將數據構建成以查詢key為鍵的數據集，然後將<key, value>集合寫入Hbase表中，Hbase會自動以key為鍵進行索引，在數十億甚至以上的級別下，查詢key的value響應時間也估計再10毫秒內。
如果檢索條件是多個組合的情況下，可以適當的設計多個hbase表格，這樣的檢索也是很快的，同時Hbase也是支持二級索引。在符合條件下查詢，Hbase也是支持MapRece的，如果對響應時間要求不高的情況下，可以考慮將hive和Hbase系統結合來使用。
如果數據量不是很大的情況下也可以考慮支持類似SQL的NOSLQ系統。
（4）能不能給點hadoop的學習方法以及學習規劃，hadoop系統有點龐大，感覺無從學起?
首先搞清楚什麼是hadoop以及hadoop可以用來做什麼？
然後，可以從最經典的詞頻統計程序開始，初步了解MapRece的基本思路和處理數據的方式。
接著，就可以正式學習hadoop的基本原理，包括HDFS和MapRece，先從整體，宏觀核心原理看，先別看源碼級別。
進一步，就可以深入HDFS和MapRece和模塊細節，這個時候可以結合源碼深入理解，以及實現機制。
最後就是需要實戰了，可以結合自己的項目或者相關需求來完成一些hadoop相關應用。
（5） 大的文件拆分成很多小的文件後，怎樣用Hadoop進行高效的處理這些小文件？以及怎樣讓各個節點盡可能的負載均衡？
1. 怎樣用Hadoop進行高效的處理這些小文件？
你這個問題提的很好，hadoop在處理大規模數據時是很高效的，但是處理大量的小文件時就會因為系統資源開銷過大而導致效率較低，針對這樣的問題，可以將小文件打包為大文件，例如使用SequcenFile文件格式，例如以文件簽名為key，文件內容本身為value寫成SequcenFile文件的一條記錄，這樣多個小文件就可以通過SequcenFile文件格式變為一個大文件，之前的每個小文件都會映射為SequcenFile文件的一條記錄。
2. 怎樣讓各個節點盡可能的負載均衡？
在hadoop集群中負載均衡是非常關鍵的，這種情況的導致往往是因為用戶的數據分布的並不均衡，而計算資源槽位數確實均衡分布在每個節點，這樣在作業運行時非本地任務會有大量的數據傳輸，從而導致集群負載不均衡，因此解決不均衡的要點就是將用戶的數據分布均衡，可以使用hadoop內置的balancer腳本命令。
對於因為資源調度導致的不均衡則需要考慮具體的調度演算法和作業分配機制。
(6)c/c++ 程序員如何入門Hadoop到深入了解，並在linux伺服器上布置運用，有沒有方向性的指導?
針對C/C++用戶，Hadoop提供了hadoop streaming介面和pipes介面，hadoop streaming介面以標准輸入和標准輸出作為用戶程序和hadoop框架交互的中間件，pipes這是專門針對C/C++語言的介面，以socket作為同學中介。
從使用上建議從streaming入手，pipes相比streaming問題比較多，而且pipes調試不容易。
(7)現在企業中使用Hadoop版本主要是1.x還是2.x？
目前網路，騰訊，阿里為主的互聯網公司都是以hadoop 1.X為基準版本的，當然每個公司都會進行自定義的二次開發以滿足不同的集群需求。
2.X在網路內部還沒有正式使用，還是以1.X為主，不過網路針對1.X的問題開發了HCE系統（Hadoop C++ Expand系統）
補充，Hadoop2.x在其他公司應用的很多，比如京東
(8)以後想從事大數據方面工作，演算法要掌握到什麼程度，演算法佔主要部分嗎?
首先，如果要從事大數據相關領域的話，hadoop是作為工具來使用的，首先需要掌握使用方法。可以不用深入到hadoop源碼級別細節。
然後就是對演算法的理解，往往需要設計到數據挖掘演算法的分布式實現，而演算法本身你還是需要理解的，例如常用的k-means聚類等。
(9)現在spark，storm越來越火，谷歌也發布了Cloud Dataflow，是不是Hadoop以後主要應該學習hdfs和yarn，而且以後Hadoop程序員的主要做的就是把這些東西打包，只提供介面讓普通的程序員也能使用，就像Cloudera和Google一樣?
這位同學，你多慮了，hadoop和spark, strom是解決不同的問題，不存在哪個好那個壞，要學習Hadoop還是以主流的hadoop-1.X為版本，2.X最主要的就是多了yarn框架，很好理解的。
如果你是hadoop本身研發建議都看，如果你是hadoop應用相關研發，看主流的1.X就行，我的書《Hadoop核心技術》是以主流的1.X為版本講解的，有興趣可以看看。
(10)小白問一句，大數據處理都是伺服器上安裝相關軟體嗎，對程序有什麼影響呢，集群、大數據是屬於運維的工作內容還是攻城獅的呢?
傳統的程序只能運行在單機上，而大數據處理這往往使用分布式編程框架編寫，例如hadoop maprece，只能運行在hadoop集群平台上。
運維的責任：保證集群，機器的穩定性和可靠性
hadoop系統本身研發：提高Hadoop集群的性能，增加新功能。
大數據應用：把hadoop作為工具，去實現海量數據處理或者相關需求。
(11)學習hadoop該怎麼入手呢？應該做一些什麼樣的項目呢？
可以參考我上面的幾個回答，可以從最簡單詞頻統計程序入手，然後學習理解HDFS和MapRece的基本原理和核心機制，如果僅僅把Hadoop作為一個工具來使用的話這樣就可以了，最重要的就是實戰了，可以嘗試使用Hadoop處理一些數據，例如做日誌分析，數據統計，排序，倒排索引等典型應用。
(12)100個以上hadoop節點，一般怎麼開發，運維？任務很多的情況下任務資源怎麼分配，任務執行順序是定時腳本還是別的什麼方式控制?
1. 首先大數據的應用開發和hadoop集群的規模是沒有關系，你指的是集群的搭建和運維嗎，對於商用的hadoop系統來說涉及到很多東西，建議參考《hadoop核心技術》實戰篇 「第10章Hadoop集群搭建 」 章節。
2. 任務的分配是有hadoop的調度器的調度策略決定的，默認為FIFO調度，商業集群一般使用多隊列多用戶調度器，可以參考參考《hadoop核心技術》高級篇 「第9章Hadoop作業調度系統」 章節。
3. 任務的執行順序是有用戶控制的，你自然可以定時啟動，也可以手動啟動。
(13)基於Hadoop做開發，是否必須會使用java，使用其他開發語言是否無法更好的融入整個Hadoop的開發體系?
基於Hadoop做開發可以使用任何語言，因為hadoop提高了streaming編程框架和pipes編程介面，streaming框架下用戶可以使用任何可以操作標准輸入輸出的計算機語言來開發hadoop應用。
(14)在rece階段老是卡在最後階段很長時間，在網上查的說是有可能是數據傾斜，我想問這個有啥解決方法嗎?
1,你這個就是數據傾斜啊 好多數據都集中在一個rece里 其他rece里分配的數據比較少 默認情況下決定哪些數據分配到哪個rece是由rece個數和partiiton分區決定的 默認是對key進行hash運算 一般情況下用mapreuce傾斜很少 除非你用的HIVE
2,rece分為3個子階段：shuffle、sort和rece，如果rece整個過程耗時較長，建議先看一下監控界面是卡在哪個階段，如果是卡在shuffle階段往往是網路阻塞問題，還有就是某rece數據量太大，也就是你所說的數據傾斜問題，這種問題往往因為某個key的value太多，解決方法是：第一，默認的partiiton可能不適合你的需求，你可以自定義partiiton；第二就是在map端截斷，盡量讓達到每個rece端的數據分布均勻。
(15)非大數據的項目能否用hadoop?
非大數據項目是否可以用Hadoop的關鍵問題在於是否有海量數據的存儲，計算，以及分析挖掘等需求，如果現有系統已經很好滿足當前需求那麼就沒有必要使用Hadoop，沒有必要使用並不意味這不能使用Hadoop，很多傳統系統能做的Hadoop也是可以做的，例如使用HDFS來代替LINUX NFS，使用MapRece來代替單伺服器的統計分析相關任務，使用Hbase代替Mysql等關系資料庫等，在數據量不大的情況下通常Hadoop集群肯定比傳統系統消耗更多的資源。
(16)hadoop maprece 和第三方資源管理調度系統如何集成？
Hadoop的調度器設計的一個原則就是可插拔式調度器框架，因此是很容易和第三方調度器集成的，例如公平調度器FairScheler和容量調度器CapacityScheler，並配置mapred-site.xml的maprece.jobtracker.taskscheler以及調度器本身的配置參數，例如公平調度器控制參數則需要編輯fair- scheler.xml進行配置，具體可以參考我的新書《Hadoop核心技術》實戰篇第十章節10.11的集群搭建實例中的10.10.9 配置第三方調度器，同時可以進一步深入學習第9章 Hadoop作業調度系統，在這一章中會詳細介紹各種第三方調度器以及使用配置方法。

6. 大數據初學者需要看看哪些Hadoop問題及解決方案

相信大家在學習大數據hadoop的時候肯定會遇到各種各樣的問題，這篇文章就是介紹一些常的問題及如何解決的辦法。
1、namenode無法啟動，不報錯
可能原因是：之前用root啟動過，導致current文件夾的許可權和所屬更改了，需要更改回來
解決：current文件夾位於hadoop安裝目錄同級目錄的tmp/dfs/namesecondary
2、WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platfo
原因：查看本地文件：
[root@db96 hadoop]# file /usr/local/hadoop/lib/native/libhadoop.so.1.0.0
/usr/local/hadoop/lib/native/libhadoop.so.1.0.0: ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), dynamically linked, not stripped
是32位的hadoop，安裝在了64位的linux系統上。lib包編譯環境不一樣，所以不能使用。
解決：重新編譯hadoop.就是重新編譯hadoop軟體。
3、Hadoop 報錯be replicated to 0 nodes, instead of 1
原因（1）namespaceid不相同（2）沒有足夠的硬碟
解決（1）停止datanode（2）刪除datadir下所有數據。（3）重啟datanode
4、The ratio of reported blocks 0.0000 has not reached the threshold 0.9990. Safe mode will be turned off automatically.
原因：由日誌可以看出無法刪除/home/hadoop/tmp/mapred/system.(其實這只是一種假象，往往我們會去糾結於這個目錄，其實不然)
解決：
（1）：終極辦法強制退出安全模式(safemode)
hadoop dfsadmin -safemode leave
這種方式雖然快，但會有遺留問題，我在用habse的時候就遇到過，很麻煩,然後你就用「hadoop fsck /」工具慢慢恢復吧。
（2）：刪除namenode下/home/hadoop/tmp下的所有文件，重新format，當然這種方式非常暴力，因為你的數據完全木有了
（3）：參考源碼可發現這個錯誤是在檢查file的時候拋出來的，基本也就是file的block丟失、錯誤等原因造成的。
這種情況在副本數為1的情況下會很棘手，其他的時候hadoop基本能自行解決，錯誤數很多的情況下就會一直處於safemode下，當然你關於集群修改配置文件後的分發，本人寫了一個配置文件分發工具可以強制離開安全模式，先保證正常讀寫，然後再啟用「hadoop fsck /」工具慢慢修復。
5、Access denied for user 'root'@'hadoop1master' (using password: YES)
原因：沒有除本地用戶的其他用戶遠程連接
解決：修改mysql表，將localhost修改為%
6、運行本地的wordcount報錯
該錯誤是缺少hadoop.dll(hadoop2.6.0編譯的版本)文件，需要將hadoop.dll拷貝到hadoop2.6.0/bin目錄下。
再次運行沒有報錯。
7、運行api的時候報了許可權問題，使用的是hadoop，而我們想使用root
原因：配置環境變數中設置了HADOOP_USER_NAME=hadoop或者在run configuration中設置的-DHADOOP_USER_NAME=hadoop
解決：將配置環境變數中設置成HADOOP_USER_NAME=root或者在run configuration中設置的-DHADOOP_USER_NAME=root
8、org.apache.hadoop.dfs.SafeModeException:Name node is in safe mode安全模式
解決方法：bin/hadoop dfsadmin -safemode leave也就是關閉Hadoop的安全模式，這樣問題就解決了。
9、用java -jar執行hadoop的job報錯
原因：用hadoop的maprece變成，在執行的時候需要依賴hadoop的大部分依賴，所以上述錯誤是缺少hadoop的依賴包
解決：（1）建議使用hadoop -jar 執行job（2）如果使用java -jar，需要使用java -cp 把hadoop依賴的所有jar拼接到路徑裡面去（3）如果使用java -jar，另一種是在打包的時候把hadoop依賴的jar一起打包進去
10、運行mr程序報UnsatisfiedLinkError:nativeio.NativeIO$Windows.access0(Ljava/lang/String
一般這個問題是由本地hadoop環境變數照成的。需要設置hadoop_home變數的值。注意hadoop安裝目錄下，bin目錄中缺少hadoop.dll和winutils.exe等動態庫。還要增加bin目錄到path路徑。另外編輯器需要添加hadoop環境 還要注意jdk等是否正確安裝。
11、在使用hdfs的fromlocal上傳文件到hdfs時，爆出本地文件找不到異常，但是查看本地文件確實存在
原因：windows設置了隱藏已知文件的擴展名功能，導致上傳的文件沒有寫擴展名
解決：在上傳文件的地方添加上擴展名即可。
12、在執行hadoop-deamon.sh start xxx時報錯
原因：啟動的時候，節點名寫錯了
解決：修改名字，名字有， namenode datanode等
13、hadoop 8088 看不到maprece 任務的執行狀態，無數據顯示
解決方法：
（1）首先檢查自己的集群中配置$HADOOP_HOME/conf/mapred-site.xml是否存在。
其中的maprece.framework.name是否配置。
（2）如果還不行的話，請在$HADOOP_HOME/conf/mapred-site.xml中原來的配置文件基礎之上再添加下面

maprece.jobhistory.addressname>
master:10020value>
property>

maprece.jobhistory.webapp.addressname>
master:19888value>
property>
14、security.AccessControlException: Access denied for user sunqw. Superuser privilege is required
解決方法：
方式一：
在系統環境變數中增加HADOOP_USER_NAME，其值為root;
或者 通過java程序動態添加，如下：
?1System.setProperty("HADOOP_USER_NAME", "root");
方式二：
使用Eclipse在非hadoop運行下進行寫入hdfs文件系統中時，由於sunqw對"/"目錄沒有寫入許可權，所以導致異常的發生。解決方法即開放hadoop中的HDFS目錄的許可權，命令如下：hadoop fs -chmod 777 / 。
方式三：
修改hadoop的配置文件：conf/hdfs-core.xml，添加或者修改 dfs.permissions 的值為 false。
方式四：
將Eclipse所在機器的名稱修改為root，即與伺服器上運行hadoop的名稱一致。