Hadoop生态系统的局限性和最佳实践

[panfei]

各位，Hadoop生态系统经过这么多年的发展已经成熟了许多，相信大家在使用的过程中也积累了不少经验。萌生一个想法，就是大家可以将自己的一些认识以及自己遇到的一些问题和相应的解决方案或最佳实践分享出来，大家可以相互取长补短，共同提升。

讨论的议题也可以扩展到海量数据处理的范围内，这样我们的目光也不至于那么局限。

--
不学习，不知道

[panfei]

我先分享一个在实际应用过程中的经验吧：

组件：Hiveserver 1

版本： CentOS 6.4 / CDH4.5.0 （hive-server-0.10.0+214-1.cdh4.5.0.p0.25.el6.noarch）

问题：并行提交多个任务时，hiveserver的日志会莫名其妙地报出OOM的异常，即使是增加hiveserver启动的JVM堆内存或者启动多个hiveserver做负载均衡也不见好转。

问题原因： hiveserver的并发线程数量超过系统默认的最大线程数（1024），导致hiveserver出现不稳定的状态。其实这个问题在部署系统的时候已经考虑到并统一设置了系统的最大线程数（通过修改/etc/security/limits.conf文件），在CentOS 5的情况下，这种统一修改的方法可以生效，但是在CentOS 6.4的环境下，却必须指定特定用户的最大线程数才可以生效，这样：

hive   - nofile 1024000
hive   - nproc  1024000

--
不学习，不知道

[panfei]

再分享一个集群系统管理的组件——saltstack

组件：整个集群服务器的统一管理

问题：　很明显，一台一台操作服务器，效率太低了

问题原因以及解决方案：Hadoop权威指南上也推荐了几种集群管理的软件架构，包括Puppet，Chef等，其中只试过Puppet，但是感觉上手太麻烦，并没有坚持使用。最后尝试了Python开发的SaltStack集群管理框架，感觉很清新，Puppet所具有的功能，SaltStack都可以胜任，并且通过SaltStack可以即时批量处理一批服务器，总体来说非常容易上手，并执行效率非常高。比如你要在所有datanode上执行 df -h命令来查看系统的磁盘使用情况，可以简单地这样写：

salt 'datanode*' cmd.run 'df -h'

当然，SaltStack还提供了大量的扩展接口，可以根据不同服务器的硬件配置，设定不同配置参数，不过那涉及的就比较多了，如果有同学对其感兴趣，还是要自己多多探索才是。

项目地址： http://www.saltstack.com/

--
不学习，不知道

[panfei]

再分享一下关于ETL框架的一些看法

组件：数据仓库ETL组件

问题：为了建立数据仓库模型，肯定需要一个ETL过程，工具的选择问题

问题原因以及解决方案（这个问题可能是没有对所使用的工具做到深入理解导致的）： 开始的时候，选取了Kettle这个图形组件化的ETL引擎来做ETL。其优势就是图形化、组件化的设计模式，ETL开发人员可以通过拖拽的方式完成对ETL流程的组织和构建。不过，对于不同产品数据的隔离，却是没有较好的解决方案，比如我有N个产品的数据需要做一次数据的聚合过程，那为了不同产品数据之间不会产生相互影响，必须分开跑这个逻辑，这样我们就没有在Kettle中找到一个优雅的解决方案来达成。致使后来不同产品数据混合在一起，查询效率降低。

为了解决这个问题，最终还是自己开发了一个多层的执行控制引擎来完成相应的目标，这样在赋予了目标数据更合适的粒度的同时，也为今后的不同产品ETL过程的优先级控制实现提供了便利的基础结构。

当然，如果数据仓库只有一个产品的数据，并不需要复杂的隔离和流程以及优先级控制的话，Kettle还是不错的选择的。

--
不学习，不知道

[panfei]

再分享一下关于Hive元数据的一些经验教训。

组件： Hive数据数据分区过多的问题

版本： CentOS 5/ CDH3u4 hive 0.7

问题：Hive数据分区过多导致用户作业提交太慢！

问题原因以及解决方案：Hive元数据保存在MySQL的数据库中，相信很多同学也都是这样做的，当然这样做一点问题都没有。但是当表中分区信息过多的时候，会导致用户提交作业时，MySQL的查询效率会成为瓶颈，甚至会影响到Hive语句的正常执行。从另一个角度看，这实际上是一个设计上的问题，也是一个权衡的问题——数据存储的粒度与执行效率之间。

对于HDFS来说，不建议有太多的小文件存储，如果有巨量的小文件，不仅仅会占据NameNode的内存空间，而且也会在DataNode上占用更多的内存空间，这时其一；其次，对于一个MapReduce作业来说，假如我们需要操作的数据是一天的数据，我们肯定希望此作业只会涉及到这一天的数据，而不是这一天所在的那一周的全部数据以期获得理想的执行效率。因此就要仔细考虑分区字段的设计问题，考虑到避免存储太多的小文件，我们希望存储粒度大一些；考虑到MR作业的IO效率，我们又希望降低数据的存储粒度。此时就应该对自己的业务模型有一个深入的理解，才能做出合适的决策。

从我们的经验看，当拥有400w个数据分区的时候，MySQL元数据存储在内存为24GB，CPU为16核心的服务器上已经成为瓶颈，以致我们将元数据库转移到一个具有64GB和24核心CPU的服务器上之后，才能从一定程度上解决作业提交过慢的问题。当然，MySQL的瓶颈主要是在IO层面上。

在升级硬件配置之后，对于MySQL的优化，主要涉及以下三个参数，核心的目标就是——减少磁盘IO过程，多利用内存：

innodb_buffer_pool_size=16384MB # innodb缓存数据占用内存大小上限
max_heap_table_size=522715200 # 和下一个一起起作用
tmp_table_size=335544320 # 数据量超过这个大小的时候，tmp table的数据就要向磁盘写入，将默认值35M扩大10倍至350MB。

再次，这是一个数据粒度的设计问题，MySQL服务器的升级和配置优化只是权宜之计，我们已经计划对数据结构做一次较大的调整，以期从根本上解决这个问题。将这个分享出来，希望对后来的同学有些帮助！

--
不学习，不知道

[高清元]

填过同样坑的路过。

在 2014年4月29日 上午9:58，panfei <cnw...@gmail.com>写道：

--
您收到此邮件是因为您订阅了Google网上论坛中的“Hadoop中国用户组(CHUG)”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到hadoopors+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[高清元]

集市都算不上，更不用说调度了，凑乎用吧。

在 2014年4月29日 上午10:21，panfei <cnw...@gmail.com>写道：

--

[panfei]

老高，有什么经验可以分享一下啊

--
不学习，不知道

[高清元]

Puppet 还好吧，萝卜青菜各有所爱。

在 2014年4月29日 上午10:06，panfei <cnw...@gmail.com>写道：

--

[panfei]

这种东西就是熟悉哪种用哪种，无所谓好坏的，选个能用的就好

--
不学习，不知道

[高清元]

坑不少，一路走一路坑，哈哈

[panfei]

老高， 可以把几个深坑亮出来啊， 让大家都能从中获益，哈

[高清元]

实时计算平台那块咋样了现在，有啥突破性的进展吗？

[panfei]

已经上线了，有专门的同学负责。目前storm表现还行。

[高清元]

整理整理再说，乱的很。

[panfei]

好的，期待中。。。

[北斗七]

分享的不错啊

[panfei]

qixing 有什么也可以分享一下啊

[北斗七]

我梳理下看看

[panfei]

还有一个需要强调的经验就是，对于老版本的HDFS一定要做好元数据的备份——NFS， 如果不用NFS至少要启动一个SecondaryNameNode进程。

在 2014年4月29日 上午9:48，panfei <cnw...@gmail.com>写道：

--
不学习，不知道