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

转：http://www.cnblogs.com/OnlyXP/archive/2009/10/14/1583450.html

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