Hadoop 調研筆記

 

因爲從各光伏電站採集的數據量較大，必須解決海量數據的查詢、分析的問題。目前主要考慮兩種方式：
1.  Hadoop大數據技術；
2.  Oracle（數據倉庫）+BI；
    本文僅介紹hadoop的技術要應用特徵。

 

Hadoop 基本介紹

hadoop是一個平臺，是一個適合大數據的分佈式存儲和計算的平臺。什麼是分佈式存儲？這就是後邊咱們要講的hadoop核心之一HDFS(Hadoop Distributed File System)；什麼是分佈式計算？這是咱們後邊要講的hadoop另一個重要的核心MapReduce。
hadoop的優勢一：低成本
hadoop自己是運行在普通PC服務器組成的集羣中進行大數據的分發及處理工做的，這些服務器集羣是能夠支持數千個節點的。
hadoop優勢二：高效性
這也是hadoop的核心競爭優點所在，接受到客戶的數據請求後，hadoop能夠在數據所在的集羣節點上併發處理。
hadoop優勢三：可靠性
經過分佈式存儲，hadoop能夠自動存儲多份副本，當數據處理請求失敗後，會自動從新部署計算任務。
hadoop優勢四：擴展性
hadoop的分佈式存儲和分佈式計算是在集羣節點完成的，這也決定了hadoop能夠擴展至更多的集羣節點。
hadoop安裝方式|hadoop部署方式
hadoop安裝方式只有三種：本地安裝；僞分佈安裝；集羣安裝。

Hadoop 適應的場景

1：超大文件
     能夠是幾百M，幾百T這個級別的文件。
2：流式數據訪問
     Hadoop適用於一次寫入，屢次讀取的場景，也就是數據複製進去以後，長時間在這些數據上進行分析。
3：商業硬件
     也就是說大街上處處都能買到的那種硬件，這樣的硬件故障率較高，因此要有很好的容錯機制。

 

Hadoop 不適用的場景

1：低延遲數據訪問
     Hadoop設計的目的是大吞吐量，因此並無針對低延遲數據訪問作一些優化，若是要求低延遲， 能夠看看Hbase。
2：大量的小文件
     因爲NameNode把文件的MetaData存儲在內存中，因此大量的小文件會產生大量的MetaData。這樣的話百萬級別的文件數目仍是可行的，再多的話就有問題了。
3：多用戶寫入，任意修改
     Hadoop如今還不支持多人寫入，任意修改的功能。也就是說每次寫入都會添加在文件末尾。

Hadoop 業務場景 1

在大數據背景下，Apache Hadoop已經逐漸成爲一種標籤性，業界對於這一開源分佈式技術的瞭解也在不斷加深。但誰纔是Hadoop的最大用戶呢？首先想到的固然是它的「發源 地」,像Google這樣的大型互聯網搜索引擎，以及Yahoo專門的廣告分析系統。也許你會認爲，Hadoop平臺發揮做用的領域是互聯網行業，用來改 善分析性能並提升擴展性。其實Hadoop的應用場景遠不止這一點，深刻挖掘的話你會發現Hadoop可以在許多地方發揮巨大的做用。
美國着名科技博客GigaOM的專欄做家Derrick Harris跟蹤雲計算和Hadoop技術已有多年時間，他也在最近的一篇文章中總結了10個Hadoop的應用場景，下面分享給你們：

在線旅遊：目前全球範圍內80%的在線旅遊網站都是在使用Cloudera公司提供的Hadoop發行版，其中SearchBI網站曾經報道過的Expedia也在其中。

移動數據：Cloudera運營總監稱，美國有70%的智能手機數據服務背後都是由Hadoop來支撐的，也就是說，包括數據的存儲以及無線運營商的數據處理等，都是在利用Hadoop技術。

電子商務：這一場景應該是很是肯定的，eBay就是最大的實踐者之一。國內的電商在Hadoop技術上也是儲備頗爲雄厚的。

能源開採：美國Chevron公司是全美第二大石油公司，他們的IT部門主管介紹了Chevron使用Hadoop的經驗，他們利用Hadoop進行數據的收集和處理，其中這些數據是海洋的地震數據，以便於他們找到油礦的位置。

節能：另一家能源服務商Opower也在使用Hadoop,爲消費者提供節約電費的服務，其中對用戶電費單進行了預測分析。

基礎架構管理：這是一個很是基礎的應用場景，用戶能夠用Hadoop從服務器、交換機以及其餘的設備中收集並分析數據。

圖像處理：創業公司Skybox Imaging 使用Hadoop來存儲並處理圖片數據，從衛星中拍攝的高清圖像中探測地理變化。

詐騙檢測：這個場景用戶接觸的比較少，通常金融服務或者政府機構會用到。利用Hadoop來存儲全部的客戶交易數據，包括一些非結構化的數據，可以幫助機構發現客戶的異常活動，預防欺詐行爲。

IT安全：除企業IT基礎機構的管理以外，Hadoop還能夠用來處理機器生成數據以便甄別來自惡意軟件或者網絡中的攻擊。

醫療保健：醫療行業也會用到Hadoop,像IBM的Watson就會使用Hadoop集羣做爲其服務的基礎，包括語義分析等高級分析技術等。醫療機構能夠利用語義分析爲患者提供醫護人員，並協助醫生更好地爲患者進行診斷。

 

Hadoop 業務場景 2

其實咱們要知道大數據的實質特性：針對增量中海量的結構化，非結構化，半結構數據，在這種狀況下，如何快速反覆計算挖掘出高效益的市場數據？
帶着這個問題滲透到業務中去分析，就知道hadoop須要應用到什麼業務場景了！！！若是關係型數據庫都能應付的工做還須要hadoop嗎？
好比：
1.銀行的信用卡業務，當你正在刷卡完一筆消費的那一瞬間，假如在你當天消費基礎上再消費滿某個額度，你就能夠免費得到某種令你很是滿意的利益等 等，你可能就會心動再去消費，這樣就可能提升銀行信用卡業務，那麼這個消費額度是如何從海量的業務數據中以秒級的速度計算出該客戶的消費記錄，並及時反饋 這個營銷信息到客戶手中呢？這時候關係型數據庫計算出這個額度或許就須要幾分鐘甚至更多時間，就須要hadoop了，這就是所謂的「秒級營銷」. 針對真正的海量數據，通常不主張多表關聯。
2. 在淘寶，當你瀏覽某個商品的時候，它會及時提示出你感興趣的同類商品的產品信息和實時銷售狀況，這或許也須要用到hadoop。
3. 就是報表用到的年度報告或者年度環比數據報告的時候也會用到hadoop去計算。
4.搜索引擎分析的時候應該也會用到。一個網友說過，其實仍是看big data可否帶來多大的效益！好比銀行在躺着都賺錢的狀況下，big data不必定是銀行的項目. 何況hadoop是新興技術，銀行業對新技術仍是相對保守的。

hadoop 主要用於大數據的並行計算，並行計算按計算特徵分爲：
•    數據密集型並行計算：數據量極大，可是計算相對簡單的並行處理。如：大規模Web信息搜索；
•    計算密集型並行計算：數據量相對不是很大，可是計算較爲複雜的並行計算。如：3-D建模與渲染，氣象預報，科學計算；
•    數據密集與計算密集混合型的並行計算。如：3－D電影的渲染；

hadoop比較擅長的是數據密集的並行計算，它主要是對不一樣的數據作相同的事情，最後再整合。
我知道以及曾經實驗過的hadoop的例子有：
•    wordCount （至關於hadoop的HelloWorld的程序）；
•    文檔倒排索引；
•    PageRank；
•    K-Means 算法；
這些程序均可以從網上找到相應的解決方案。
hadoop的是根據Google MapReduce 提出的開源版本。可是它的性能不是很好。

hadoop主要應用於數據量大的離線場景。特徵爲：
一、數據量大。通常真正線上用Hadoop的，集羣規模都在上百臺到幾千臺的機器。這種狀況下，T級別的數據也是很小的。Coursera上一門課了有句話以爲很不錯：Don’t use hadoop, your data isn’t that big.
二、離線。Mapreduce框架下，很難處理實時計算，做業都以日誌分析這樣的線下做業爲主。另外，集羣中通常都會有大量做業等待被調度，保證資源充分利用。
三、數據塊大。因爲HDFS設計的特色，Hadoop適合處理文件塊大的文件。大量的小文件使用Hadoop來處理效率會很低。舉個例子，百度天天都會有用戶對側邊欄廣告進行點擊。這些點擊都會被記入日誌。而後在離線場景下，將大量的日誌使用Hadoop進行處理，分析用戶習慣等信息。

 

MapReduce 的經典案例

MapReduce的一個經典實例是Hadoop。用於處理大型分佈式數據庫。因爲Hadoop關聯到雲以及雲部署，大多數人忽略了一點，Hadoop有些屬性不適合通常企業的需求，特別是移動應用程序。下面是其中的一些特色：

    Hadoop的最大價值在於數據庫，而Hadoop所用的數據庫是移動應用程序所用數據庫的10到1000倍。對於許多人來講，使用Hadoop就是殺雞用牛刀。
    Hadoop有顯著的設置和處理開銷。 Hadoop工做可能會須要幾分鐘的時間，即便相關數據量不是很大。
    Hadoop在支持具備多維上下文數據結構方面不是很擅長。例如，一個定義給定地理變量值的記錄，而後使用垂直鏈接，來連續定義一個比hadoop使用的鍵值對定義更復雜的數據結構關係。
    Hadoop必須使用迭代方法處理的問題方面用處不大，尤爲是幾個連續有依賴性步驟的問題。

MapReduce (EMR)，這是一項Hadoop服務。Hadoop旨在同期文件系統工做，以HDFS著稱。
當用戶用EMR建立了一個Hadoop集羣，他們能夠從AWS S3（亞馬遜簡單儲存服務）或者一些其餘的數據存儲複製數據到集羣上的HDFS，或者也能夠直接從S3訪問數據。HDFS使用本地存儲，並且一般提供了比從S3恢復更好的性能，可是在運行Hadoop工做以前，也須要時間從S3複製數據到HDFS。若是EMR集羣要運行一段時間，且針對多項工做使用相同的數據，可能值得額外的啓動時間來從S3複製數據到HDFS。

爲何hadoop不適合處理實時數據

 1. 概述　

　　Hadoop已 被公認爲大數據分析領域無可爭辯的王者，它專一與批處理。這種模型對許多情形（好比：爲網頁創建索引）已經足夠，但還存在其餘一些使用模型，它們須要來自 高度動態的來源的實時信息。爲了解決這個問題，就得藉助Twitter推出得Storm。Storm不處理靜態數據，但它處理預計會連續的流數據。考慮到 Twitter用戶天天生成1.4億條推文，那麼就很容易看到此技術的巨大用途。

　　但Storm不僅是一個傳統的大數據分析系統：它是復瑣事件處理（CEP）系統的一個示例。CEP系統一般分類爲計算和麪向檢測，其中每一個系統都是經過用戶定義的算法在Storm中實現。舉例而言，CEP可用於識別事件洪流中有意義的事件，而後實時的處理這些事件。

 

2. 爲何Hadoop不適合實時計算

　　這裏說的不適合,是一個相對的概念。若是業務對時延要求較低,那麼這個 問題就不存在了;但事實上企業中的有些業務要求是對時延有高要求的。下面我 就來講說: 

2.1時延

　　Storm 的網絡直傳與內存計算,其時延必然比 Hadoop 的 HDFS 傳輸低得多;當計算模型比較適合流式時,Storm 的流試處理,省去了批處理的收集數據的時 間;由於 Storm 是服務型的做業,也省去了做業調度的時延。因此從時延的角 度來看,Storm 要快於 Hadoop,於是 Storm 更適合作實時流水數據處理。下面用一個業務場景來描述這個時延問題。

2.1.1業務場景 

 　　幾千個日誌生產方產生日誌文件,須要對這些日誌文件進行一些 ETL 操做存 入數據庫。

　　我分別用 Hadoop 和 Storm 來分析下這個業務場景。假設咱們用 Hadoop 來 處理這個業務流程,則須要先存入 HDFS,按每一分鐘(達不到秒級別,分鐘是最小緯度)切一個文件的粒度來計算。這個粒度已經極端的細了,再小的話 HDFS 上會一堆小文件。接着 Hadoop 開始計算時,一分鐘已通過去了,而後再開始 調度任務又花了一分鐘,而後做業運行起來,假設集羣比較大,幾秒鐘就計算完 成了,而後寫數據庫假設也花了不多時間(理想情況下);這樣,從數據產生到 最後可使用已通過去了至少兩分多鐘。

　　而咱們來看看流式計算則是數據產生時,則有一個程序一直監控日誌的產生, 產生一行就經過一個傳輸系統發給流式計算系統,而後流式計算系統直接處理, 處理完以後直接寫入數據庫,每條數據從產生到寫入數據庫,在資源充足(集羣 較大)時能夠在毫秒級別完成。 

2.1.2吞吐

　　在吞吐量方面,Hadoop 倒是比 Storm 有優點;因爲 Hadoop 是一個批處理計算,相比 Storm 的流式處理計算,Hadoop 的吞吐量高於 Storm。 

2.2應用領域

　　Hadoop 是基於 MapReduce 模型的,處理海量數據的離線分析工具,而 Storm是分佈式的,實時數據流分析工具,數據是源源不斷產生的,好比:Twitter 的 Timeline。另外,M/R 模型在實時領域很難有所發揮,它自身的設計特色決定了 數據源必須是靜態的。 

2.3硬件

　　Hadoop 是磁盤級計算,進行計算時,數據在磁盤上,須要讀寫磁盤;Storm是內存級計算,數據直接經過網絡導入內存。讀寫內存比讀寫磁盤速度快 N 個 數量級。根據行業結論,磁盤訪問延遲約爲內存訪問延遲的 7.5w 倍,因此從這 個方面也能夠看出,Storm 從速度上更快。 

 

3.詳細分析 

　　在分析以前,咱們先看看兩種計算框架的模型，首先咱們看下MapReduce的模型，以WordCount爲例，以下圖所示：

 

 

　　閱讀過Hadoop源碼下的hadoop-mapreduce-project工程中的代碼應該對這個流程會熟悉，我這裏就不贅述這個流程了。

　　接着咱們在來看下Storm的模型，以下圖所示：

　　而後下面咱們就會涉及到2個指標問題：延時和吞吐。

• 延時:指數據從產生到運算產生結果的時間。與「速度」息息相關。
• 吞吐:指系統單位時間處理的數據量。

　　另外,在資源相同的狀況下;通常 Storm 的延時要低於 MapReduce,可是

　　吞吐吞吐也要低於 MapReduce,下面我描述下流計算和批處理計算的流程。 整個數據處理流程來講大體能夠分爲三個階段:

　　1. 數據採集階段
　　2. 數據計算(涉及計算中的中間存儲)

　　3. 數據結果展示(反饋) 

3.1.1數據採集階段

　　目前典型的處理策略:數據的產生系統通常出自 Web 日誌和解析 DB 的 Log,流計算數據採集是獲取的消息隊列(如:Kafka,RabbitMQ)等。批處理系統一 般將數據採集到分佈式文件系統(如:HDFS),固然也有使用消息隊列的。咱們 暫且把消息隊列和文件系統稱爲預處理存儲。兩者在這個階段的延時和吞吐上沒 太大的區別,接下來從這個預處理存儲到數據計算階段有很大的區別。流計算一 般在實時的讀取消息隊列進入流計算系統(Storm)的數據進行運算,批處理系 統通常回累計大批數據後,批量導入到計算系統(Hadoop),這裏就有了延時的 區別。

3.1.2數據計算階段 

　　流計算系統(Storm)的延時主要有如下幾個方面:

·         Storm 進程是常駐的,有數據就能夠進行實時的處理。MapReduce 數據累 計一批後由做業管理系統啓動任務,Jobtracker 計算任務分配,Tasktacker 啓動相關的運算進程。

·         Storm 每一個計算單元之間數據經過網絡(ZeroMQ)直接傳輸。MapReduce Map 任務運算的結果要寫入到 HDFS,在 Reduce 任務經過網絡拖過去運算。 相對來講多了磁盤讀寫,比較慢。

·         對於複雜運算,Storm的運算模型直接支持DAG(有向無環圖,多個應用程 序存在依賴關係,後一個應用程序的 輸入爲前一個的輸出),MapReduce 須要多個 MR 過程組成,並且有些 Map 操做沒有意義。 

3.1.3數據展示 

　　流計算通常運算結果直接反饋到最終結果集中(展現頁面,數據庫,搜索引擎的索引)。而 MapReduce 通常須要整個運算結束後將結果批量導入到結果集中。 

 

4.總結

　　Storm 能夠方便的在一個計算機集羣中編寫與擴展複雜的實時計算,Storm 之於實時,就比如 Hadoop 之於批處理。Storm 保證每一個消息都會獲得處理,而 且速度很快,在一個小集羣中,每秒能夠處理數以百萬計的消息。

Storm 的主要特色以下:

·   簡單的編程模型。相似於MR下降了並行批處理的複雜行,Storm下降了實時處理的複雜行。

·   可使用各類編程語言。只要遵照實現Storm的通訊協議便可。

·   容錯性。Storm會管理工做進程和節點故障。

·   水平擴展。計算是在多個線程,進程和服務器之間並行進行的。

·   可靠的消息處理。Storm保證每一個消息至少能獲得處理一次完整的處理,使用 MQ 做爲其底層消息隊列。

·   本地模式。Storm 有一個「本地模式」,能夠在處理過程當中徹底模擬Storm集羣。這讓你能夠快速進行開發和單元測試。

 

　　最後總結：Hadoop 的 MR 基於 HDFS,須要切分輸入數據,產生中間數據文件,排序,數據壓縮,多分複製等,效率地下。而 Storm 基於 ZeroMQ 這個高性能的消息通信庫,不能持久化數據。

 

專家說

雅虎雲平臺組的副總裁Hari Vasudev解釋說，Hadoop在處理大量結構與非結構數據上是「很是有效的」。它適用於在傳統數據倉庫中對即時查詢需求的支持，但不能取代針對有低潛在因素需求的傳統商業智能（BI）功能的關係型數據庫管理系統（RDBMS）的部署。

Vasudev曾指出Hadoop的工做量很大，注意到網絡是最難肯定的變量。「關鍵是要購買足夠的網絡容量，讓全部節點在集羣以合理的速度和合理的成本上互相交流，」他說。

Hoosenally還指出，企業在利用Hadoop上面臨着「急劇上升的學習曲線」，而這將使與遺留的IT系統的整合「較爲困難」。

更有甚者，當前在如何啓動和確保有效使用開源框架上缺少文檔和信息，他補充說。

他又指出，招聘具備該領域專業知識的合適人才是另外一種挑戰。

互聯網數據中心（IDC）亞太區聯合副總裁Philip Carter在早先的一份報告中強調了數據人才的缺少。他舉例說，在亞洲的公司對大數據以及IT部門應該如何接近它的理解上層次較低。即便在這個領域有更多知識的IT領導人也不能肯定管理信息採集所需技能的種類，該分析師說。

 

C# Hadoop

1、安裝環境

1，前期準備：官網下載「NuGet Package Manager」，按本身已有的VS環境下載對應版本；

2，利用NuGet下載Hadoop For .NET SDK,地址「http://hadoopsdk.codeplex.com/」

3，安裝。

4，經過HDInsight，安裝Windows Azure，目前是預覽版本。

5，參照網址「http://blogs.msdn.com/b/data_otaku/archive/2013/08/14/hadoop-for-net-developers.aspx」 系統學習API。