Hadoop Ecosystem解决方案---数据仓库

ship

个人总结的一套基于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传输协议.加速高带宽时延积下的网络传输.