由於從各光伏電站採集的數據量較大，必須解決海量數據的查詢、分析的問題。目前主要考慮兩種方式：1. Hadoop大數據技術；2. Oracle（數據倉庫）+BI； 本文僅介紹hadoop的技術要應用特征。 Hadoop 基本介紹 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主要應用於數據量大的離線場景。特征為：
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 這個高性能的消息通訊庫,不能持久化數據。