個人總結的一套基于hadoop的海量數據挖掘的開源解決方案.

?

BI系統:
Pentaho
pentaho是開源的BI系統中做得算頂尖的了.
提供的核心功能如下:

??? 報表功能: 可視化(client, web)的報表設計.
??? 分析功能: 可以生成分析視圖，作數據作動態分析.
??? Dashboard功能: 可以定制動態圖表(image/flash)頁面.
??? 調度功能: 可對指定的任務進行crontab式調度. e.g.: 定期發送日/周/月報
??? 工作流: 任意組合復雜的任務流程.
??? ETL: 原生提供在各種數據庫之間進行數據提取/轉換/導入,可以自行擴展數據源.
??? webservice接口: 可由任意外部程序進行調用.可以很好的結合進SOA架構.

?

?

海量數據收集系統

??? 推薦我的開源項目Cloudscribe: http://code.google.com/p/cloudscribe.

??? 特點: CAP特征: 弱C強A強P.

??? 與zookeeper集成,統一的組管理功能.

?

?

數據倉庫

Hive VS. Cloudbase VS. Pig

Pig:

??? 優點: 特定場景下使用性能較好.發展趨勢良好

??? 缺點: 生僻的語法難以入手.

Cloudbase:

??? 缺點: 設計過于簡單,性能一般.

??? 優點: 完全遵照SQL規范.比較容易上手.適合入門級使用.

Hive:

??? 優點: 設計較好.關注點分離到位.并在不斷演化中．發展趨勢良好

??? 缺點: 稍微有別正統SQL.

?

綜合來講,個人推薦Hive.

?

基礎存儲和計算框架

Hadoop MapReduce:

??? 如果選擇Hive, 就基本綁定了Hadoop MapReduce.

?

Hadoop HDFS VS KFS

??? KFS采用C++實現.HDFS采用Java,與Hadoop整個生態系統結合緊密. 從效率上來講, KFS要略勝一籌.

?

?

綜合考慮，個人還是推薦HDFS.

?

Hadoop當前有3種版本:

??? 官方版本 & Yahoo版本 & Cloudera版本

?

個人推薦熟手研究并采用Cloudera的版本. Cloudera的版本提供了一些很好的拓展機制.并且也是開源的.

?

?

管理平臺

??? 推薦cloudera Hadoop desktop.

??? 它提供了一個針對hadoop的統一管理平臺. 可基于WEB進行文件系統操作，MapReduce Job管理，提交，瀏覽. 還有監控圖表功能.

?

監控平臺

??? 推薦采用Ganglia對hadoop進行監控.結合Nagios進行告警.

?

?

?

?

拓展話題

關于hadoop的部署:

??? 分為兩種情況:

??????????? 即時架構:

??????????????? 可采用捆綁VM的方式，例如Cloudera為Amazon EC2制作的AMI. 此方案適合instant架構, 適合在租用計算的場景. 數據不是locality的.

??????????? 穩定架構:

??????????????? 固定的集群,locality計算.部署方案:

??????????????????? 1). 可以針對不同配置采用帶本地緩存+autofs的NFS統一部署方案.

??????????????????? 2). 軟件分發.

??????????? 配置注意事項:

??????????????? namenode: 帶RAID,多磁盤存儲文件系統元信息.

??????????????? secondary namenode與namenode等同配置(尤其是內存).

??????????????? namenode與jobtracker分離.

??????????????? datanode: 不帶RAID, 雙網卡: 一個用于內部數據傳輸，一個用于外部數據傳輸.

??????????????? tasktracker與datanode配對.

?

?

hadoop的運營核心問題

??? Part1: HDFS系統

??????? namenode:

??????????? 資源限制:

??????????????? 由于文件系統元信息是全量存放在namenode.所以文件數量是有上限的.

??????????????? 同時，某datanode意外失效后,其所有block都會在namenode中待備份隊列中排隊，也會臨時占用很多內存.

?

??????????? 負載限制:

??????????????? 隨著集群規模的增長帶給namenode更多負載:

??????????????????? 1. client與namenode之間的元信息操作;

??????????????????? 2. namenode與datanode之間的通信.

??????????????? 所以說，集群規模也是有上限的.??

???????

??????????? 對于龐大的hadoop集群,重啟恢復時間也會非常緩慢, 所以, 盡量存儲較大的文件.

?

??????????? 解決方案:

??????????????? 垂直擴展:

??????????????????? 1. 配置更好的硬件,網絡. 優化單機程序性能.(Google GFS也做過一段這樣的努力).

??????????????????? 2. 功能垂直分離: 通過功能垂直劃分來構建多個專有master.(Google GFS同樣做過類似方案)

??????????????????? 垂直擴展總終究會面臨極限.

??????????????? 水平擴展:

??????????????????? 通過在master前端引入一個Router, 來虛擬出一個更抽象的文件系統namespace, Router后端掛接多個Hadoop Cluster.(Google GFS也作過類似方案).

?

??????????? namenode的單點失效(SPOF)問題:

??????????????? 解決方案

??????????????????? namenode多元數據目錄, 配備secondary namenode:

??????????????????????? 一致性: 延遲一致.

??????????????????????? 可靠性: 有少許丟失.

??????????????????????? failover: 手工.

??????????????????????? 可用性: 故障恢復時間: 1 ~ 2小時.

??????????????????????? 性能: 無損失

??????????????????????? 復雜性: 低

??????????????????? Linux Heartbeat +?TCP Bonding + DRBD網絡RAID:

????????????一致性: 可調節,可完全一致.

????????????可靠性: 可調節,可完全一致.

????????????failover: 自動.

????????????可用性: 自動切換. 故障恢復時間: 0~30min

????????????性能: 有損

??????????????????????? 復雜性: 中等

??????????????????? Paxos分布式仲裁方案(hadoop + bookkeeper + zookeeper):

??????????????????????? 一致性: 理論完全一致.

????????????可靠性: 理論完全一致.

????????????failover: 自動.

????????????可用性: 自動切換. 故障恢復時間: 0~30min

??????????? 性能: 較少損

????????????????????????復雜性: 高

?

??????? DataNode:

??????????? 文件存儲目錄結構, IO Handler數量, ulimit設置等.

?

??? Part 2: MapReduce

??????? 意外非預期故障導致Job失效:

??????? 磁盤滿，只讀磁盤等. 解決方式是采用0.21之后的health.check腳本進行定期檢測和黑名單上報.

??????????????? Job恢復: 采用0.19之后原生提供的job recover機制.

??????? JobTracker單點問題:

??????? hadoop后續版本準備把JobTracker與zookeeper結合.

?

?

高級優化措施

??? 改造KFS,采用UDT傳輸協議.加速高帶寬時延積下的網絡傳輸.

轉載于:https://www.cnblogs.com/OnlyXP/archive/2009/10/14/1583450.html

總結

以上是生活随笔為你收集整理的Hadoop Ecosystem解决方案---数据仓库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。