XuGang

 

由于從各光伏電站采集的數據量較大，必須解決海量數據的查詢、分析的問題。目前主要考慮兩種方式：
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主要應用于數據量大的離線場景。特征為：
1、數據量大。一般真正線上用Hadoop的，集群規模都在上百臺到幾千臺的機器。這種情況下，T級別的數據也是很小的。Coursera上一門課了有句話覺得很不錯：Don’t use hadoop, your data isn’t that big.
2、離線。Mapreduce框架下，很難處理實時計算，作業都以日志分析這樣的線下作業為主。另外，集群中一般都會有大量作業等待被調度，保證資源充分利用。
3、數據塊大。由于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，前期準備：官網下載“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。