Reduce对Pig作业性能的影响

很多用户在使用HDInsight的Pig功能时,发现有时很简单一个Pig Latin的relation会花费很长时间执行,当HDI使用MR框架时,由于Pig会根据具体的relation拆分成相应的Map和Reduce任务。根据Hadoop的MR框架如下特点,针对Reduce并行度的优化,会对Pig的作业有很大的性能影响。 Hadoop的MR框架中有以下特点: Map的并行度个数是由输入文件来决定,而Reduce并行度的个数是由Parallel关键字来决定。 当不指定parallel关键字时, Reduce task仅有一个。 Reduce的并行度依赖于cluster的规模。 具体内容看如下文档:http://wiki.apache.org/pig/PigLatin   当我们使用Get-AzureHDInsightJobOutput来进一步分析Pig作业的具体执行情况,我们可以通过Pig作业执行的具体日志来查看Map和Reduce的效率。如下为当使用group by的Pig作业的日志信息: =================================================== 测试1:默认一个Reduce的Pig 作业,执行Pig作业花费了74分钟: —————————– 2015-02-10 09:01:27,937 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher- 0% complete 2015-02-10 09:02:43,446 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher- 4% complete … 2015-02-10 10:15:18,029 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher- 100% complete … JobId     Maps    Reduces              MaxMapTime   MinMapTIme    AvgMapTime              MedianMapTime            MaxReduceTime             MinReduceTime              AvgReduceTime              MedianReducetime        Alias      Feature              Outputs job_1423547880282_0013          482        1            418        23         …


在Azure HDInsight HBase集群中使用Thrift接口

Apache Thrift 是一种可扩展的跨语言服务接口,可以通过内置的代码生成引擎帮助创建跨语言服务类库,Apache HBase 也是通过Thrift sever与Python,Ruby等其他程序开发语言进行交互。但是默认情况下Thrift Server默认不是启动的,需要手工处理一下。在Azure HDInight HBase中这种处理的方式有2种,我们可以根据使用场景来进行配置。 第一种方法相对简单,我们可以通过RDP远程连接到HeadNode0上,通过命令行hbase thrift2 start的方法启动thrift server进程。这种方法很简单,但是并不能能满足高可用的要求,只能用于开发测试环境。 第二种方法会复杂很多,但是可以提供生产级别的可用性,可扩展性要求。 创建2个Linux VM并将Azure HDInsight HBase集群部署到相同的虚拟网络上 在VM中设置$JAVA_HOME 在VM中配置repositories wget -nv http://public-repo-1.hortonworks.com/HDP/centos6/2.x/GA/2.2.0.0/hdp.repo -O /etc/yum.repos.d/hdp.repo 在VM中安装HBase sudo yum install hbase 在VM中修改hbase-site.xml,主要是提供zookeeper的地址,可以通过DNS或者host文件的方法提供这些zookeeper及workernode的名字解析,zookeeper以及workernode的名称可以通过Ambari API得到  <configuration>   <property>     <name>hbase.cluster.distributed</name>     <value>true</value>   </property>   <property>     <name>hbase.zookeeper.quorum</name>     <value>zookeeper0.hbase.hdicluster.local,zookeeper1.hbase.hdicluster.local,zookeeper2.hbase.hdicluster.local</value>   </property>   <property>     <name>hbase.zookeeper.property.clientPort</name>     <value>2181</value>   </property> </configuration> 配置服务进程,我们需要在/etc/init.d目录下添加一个名称为hbase-thrift2的服务启动脚本 #!/bin/sh #chkconfig :2345 90 60 #description : hbase thrift gateway service,…


基于VPN搭建混合云架构需要考虑的网络因素

很多用户在搭建混合云架构时,会使用到微软Azure虚拟网络中的 VPN功能,来实现Azure中的虚拟网络与用户本地数据中心的网络连接。由于Azure VPN连接是基于公网Internet建立,而公网偶尔丢包的现象普遍存在,比如由于某台交换机繁忙或者物理线路不稳定等各种因素导致丢包。根据很多使用Azure VPN客户的网络监控经验来看,基于互联网的连接,偶尔的网络丢包会造成Azure和用户数据中心两边的服务器可能暂时通讯无响应的现象,比如Ping request timed out ,注意这并不代表VPN链路的中断,且通常也会在最长1-2分钟内自行恢复。 如需要判断VPN链接是否真的中断,则通常需要通过网络抓包及日志的分析,确认在问题发生前后IPSEC是否有进行rekey,在IPSEC日志中确认是否有VPN re-negotiation的动作。如果问题发生前后SPI ID 没有变化这代表着VPN使用的是同一Session。而如果VPN的IPSEC发生过中断,那么SPI ID是一定会有变化的。 由于网络丢包偶尔会造成VPN两端服务器暂时通讯无响应的现象,我们对基于VPN的混合云在应用层面的架构有以下几点建议: 1. 应用架构中对于数据传输或交互的实时性、响应速度、带宽、延时等因素要求很高的组件,比如一个典型交易系统的web 应用层和其对应的数据库,建议要放置在同一个数据中心里,而不是基于internet的VPN通道通讯。 2. 对于在Azure数据中心和用户本地数据中心需要通过VPN通道进行交互的系统,比如数据的访问或同步等需求,建议应用层面需要具备异步通讯以及重试的机制,这样即便是网络偶尔丢包造成请求失败,应用层面也会有所准备而不会由于一次连接不上就直接报错。比如SQL Server的高可用技术如Always On, 数据库镜像等都是支持这种异步的数据同步以及重试机制的,在网络偶尔丢包然后又恢复后,SQL Server会自动恢复继续后台的数据同步。