Hive-1.1.0的注意事项之transform的坑

曾经为贪图方便使用Hive的tranform来实现了一些对数据的处理逻辑，但是之后发现各种坑啊，，，，，，如下：
      通过大量的数据实验发现：在数据清洗过程中，如果使用的是TransForm而不是UDF的话，因为Python是直接向系统申请资源的，而不是像ResourceManager申请资源，故会导致启动的Python脚本对内存和CPU的使用不可控，尤其是当启动多个Map时，因为一个map将启动一个Python因此，当同时运行的map有几十个时（测试集群较小），同时将尝试启动相同个数的python（资源够用的话仍然会启动几十个），且此时Map占用的内存是不会释放掉的他在一直等待Python的结果，这将导致python可用的资源仅仅是原本分配给系统的很少的资源（注：在安装Hadoop时，对于单个节点，一般仅仅给系统留出很少的内存，其他的内存全部分给了集群。例如32G物理内存的节点给系统和dataNode+nodeManager的内存就4-8个G，同时CPU核数也不足节点的一半，剩余的内存和cpu核数全部划分给集群使用。需要注意的是，这里虽然说是划分给集群使用，仅仅是逻辑上的划分，即规定集群可以使用的最大的物理内存，超过该内存时MR可以认为是不会抢占分配给系统+DataNode+nodeManager的内存的，但是当集群中没有MR在执行，即没有map或者reduce在执行时，划分给集群的这部分资源是可以被系统使用的。而若有map和Reduce在执行时，运行map和reduce的JVM的资源不会因为系统进程需要使用而被释放掉）所以，所有正在执行的Map一直在等待python的运行结果而没有释放掉其自身占用的资源，故python无法使用分配给集群的资源而只能使用预留给系统+nodeManager+DataNode的4-8G的内存和很少的cpu核数。因此会导致集群的资源无法被高效利用。

综上，使用Transform（Python）执行效率低的根本原因在于Python是直接向操作系统申请资源，而不是向YARN的ResourceManager申请资源，故而导致节点的资源无法高效组织和被利用。此外，不要轻易使用transform！不要轻易使用transform！不要轻易使用transform，，，

解决方案：

     1、将Transform的python代码的逻辑改成UDF来实现，因为使用Java来编写的UDF可以直接被运行map和Reduce的JVM所管理，这样整个流程的所有资源的分配个管理就可以全部由ResourceManager统一管理，资源的调度将更加合理，不会在出现不可控的情况。

     2、若之前的逻辑太多，太复杂，，等等各种原因导致只能使用Transform来实现， 那么可以在调用Hive sql 时添加hive参数设置，降低同时启动的map的个数（通常增加一个map需要处理的数据量，默认一个map仅仅处理一个block的数据，可以增大mix的大小），这样同时启动的python也会减少，且因为同时运行的map个数减少且没有达到集群所能使用的内存上限，也就是说此时向系统申请资源的python的个数减少，同时集群也会有空闲的内存借给系统（python）使用,变向的优化了资源的调度，提升 了节点内存的有效利用率。

     3、若所有的业务逻辑都是用TranSform实现的，不能修改，那么为了避免每次都像第2中方案那样修改参数，最有效的方案就是，根据当前情况（map需要处理的逻辑都很简单，需要的内存不太大，更多的逻辑是在python中实现的）重新配置优化集群的参数，即适当增大预留给系统+DataNode+nodeManager的内存和Cpu核数，降低或避免 因系统可支配资源有限，导致的python无法向系统申请到足够资源而运行效率慢的问题。

补充扩展内容：

     关于Hadoop集群的安装的内存分配问题，详情可以参考CDH的官方文档：https://www.cloudera.com/documentation/enterprise/5-3-x/topics/cdh_ig_yarn_tuning.html

首先简单的讲，假设当前物理节点运行DataNode和nodeManager，因为这是Hadoop集群中数量最多的节点也是需要资源配置考虑较多的节点，而控制节点例如安装Namenode或者ResourceManager的节点需要考虑的问题相对单一，故以下资源的配置仅仅是对于同时运行DataNode和NodeManager的节点配置而言，不过通常一般的Hadoop集群安装所有的节点配置是一样的（方便管理和分发）。 当前的物理节点仅仅用于安装Hadoop Hbase 等数据处理常用开源工具（zookeeper集群单独安装），而不会再安装和运行其他除系统服务外的服务，那么当前物理节点的资源（这里仅仅只内存和CPU）分配仅仅只需要考虑划两部分的的划分，各个部分所需要的内存和CPU：

一：系统本身需要的资源+DataNode需要的资源+NodeManager需要的资源

     这部分很简单，根据具体情况确定系统需要的资源+DataNode+NodeManager三个进程需要的资源相加即可。剩下的资源全部是分给集群运行MR

二：当前节点提供给hadoop集群的资源，即该节点的多大的资源分配给Hadoop集群运行MR程序使用。

     这里需要考虑几点，且各个参数的注意事项在官方文档中写的很详细，不再赘述。

1、Contain最小可使用的内存，和最大可以使用内存，以及当最小内存不够用时，在增加Contain内存的时候每次增加内存的步长，注：在启动Contain时默认直接分配给Contain的内存就是最小可使用内存。

2、APPMaster可以使用的核数和内存，

3、单个map和单个reduce需要占用的内存和cpu核数（Reduce内存一般是Map的两倍），以及初始化时分配给Map和Reduce的实际内存（一般是设置的内存的80%）

4、单个

注：对当前节点资源的管理是由NodeManager服务管理的(而整个集群所有可用资源的调度是由ResourceManager负责的)，也就是说配置文件中可以通过配置参数来告诉NodeManager服务可以使用当前节点资源的上限有多大（即当前节点分配给Hadoop运行MR的资源），例如yarn.nodemanager.resource.cpu-vcores=16来告诉运行在当前节点的NodeManager，他可以使用当前节点16个cpu核（这个核不是物理核数而是虚拟核数，通常一个物理核可以虚拟化成4个虚拟核，故这里的16实际上对应的物理核只有4个，且当前节点的物理核需要大于4，毕竟要为操作系统+DataNode+NodeManager留一部分核），yarn.nodemanager.resource.memory-mb=20480告诉运行在当前节点的NodeManager，他可以使用当前机器上的内存上限是20G=2048M（注意这里当前节点的物理内存肯定大于20G，因为需要有一部分内存留给系统和DataNode+NodeManager使用） 用于创建Contain以执行AppMaster,Map,Reduce。