个人总结的一套基于hadoop的海量数据挖掘的开源解决方案.
BI系统: Pentaho
pentaho是开源的BI系统中做得算顶尖的了.
提供的核心功能如下:
报表功能: 可视化(client, web)的报表设计.
分析功能: 可以生成分析视图，作数据作动态分析.
Dashboard功能: 可以定制动态图表(image/flash)页面.
调度功能: 可对指定的任务进行crontab式调度. e.g.: 定期发送日/周/月报
工作流: 任意组合复杂的任务流程.
ETL: 原生提供在各种数据库之间进行数据提取/转换/导入,可以自行扩展数据源.
webservice接口: 可由任意外部程序进行调用.可以很好的结合进SOA架构.
海量数据收集系统
推荐我的开源项目Cloudscribe: /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传输协议.加速高带宽时延积下的网络传输.
