泰为基于EMR的考量与实践
编程中的点滴体验 2016-11-08
关于作者：武基鹏，主要从事大数据平台产品的技术工作；负责设计、构建和优化基于HDFS/HBase的存储平台架构；负责整体提升Hadoop/Hbase等集群的高可用性、高性能、高扩展特性；负责对公司的Apache Hadoop1.2、CDH4及CDH5集群的部署、监控、调优和运维；此外,还精通Java、Shell、Python编程和管理SQL数据库及熟悉NOSQL的经验。
1.58元/小时起快速体验 Hadoop & Spark ，为你助力大数据计算
阿里云EMR是基于 Hadoop 的生态环境来搭建，同时可以跟阿里云的对象存储服务OSS等云服务进行无缝数据交换，方便用户将数据在存储平台和计算平台之间进行输入输出，以满足不同业务类型的需要，所以对阿里云EMR充满期待。
在登录和打开阿里云 EMR的console web界面时，被阿里这种简约扁平化设计风格深深吸引着。
其中阿里云EMR的”概览、集群、作业、执行计划、报警、帮助”六大模块，操作起来简单易上手，但其底层实现的架构设计必定很复杂。其中阿里云EMR的各种文档很齐全，很方便我们能够快速了解和迅速部署我们自己的EMR集群。
深究ETL业务逻辑
在计划迁移Rundeck上的Product Job到阿里云EMR上，一定要先充分地了解现有业务的处理逻辑、Job脚本代码以及集群组件Hadoop、Hive环境等。为了不影响现有产品环境的稳定性，所以一般要先选择Stage的Job进行迁移，调试。其ETL业务在ETL Cluster的基本架构如图所示：
调研阿里云EMR产品
在接下来的工作中，仔细调研阿里云EMR产品，发现有这么四点优势吧。
有易用性 ;
有和OSS、RDS等产品深度结合；
有较高的安全性，主要整合了阿里云 RAM 资源权限管理系统，通过主子账号对服务权限进行隔离；
其实还有更重要一点，在 [2016云栖大会] 上，其价格再次降低，更加受企业青睐。
由于我们的Product Job是每天凌晨run，所以阿里云EMR的按需创建方案很适合我们当前的ETL 业务，而且当Job run结束时，无论执行计划是否成功，都会释放集群资源，降低企业的cost。
定制化所属自己的集群环境
当前我们的业务是Log ETL 离线处理，当前集群环境是CDH5.4.8(Hadoop2.6 + Hive1.1.0)，其中在阿里云EMR集群中，只提供Apache Hadoop2.7.2+Hive2.0.0组合，由于业务环境的jar包和hive sql的某些特性是Hive低版本特有的，高版本现在处于bug中，所以与阿里云EMR的Hive2.0.0兼容效果不是很好。
所以这里要感谢@阿里封神提供一个非常赞的idea给我，是将EMR集群自带Hive2.0.0给替换成我们特定hive-1.2.1-emr版本。需将该版本打包存放在OSS存储上，因为OSS到EMR集群，下载速度无带宽限制，非常迅速，最终我们选择Apache Hive版本为1.2.1,接下来就是调试踩坑和打补丁编译版本。所以这块时间花费整个迁移项目时间的1/2。
迁移Stage Job至阿里云EMR的流程
其具体流程：
在作业tab页，创建4组共16个job；
在执行计划tab页，创建执行计划，其中需要配置如下 •调度策略为每天凌晨运行 •关联集群为按需创建集群 •作业配置为按顺序绑定16个job •启动报警模块，推送消息给Administrator
在迁移过程，有几点建议：
先选择按量付费创建好集群，切不可在执行计划中按需创建集群；
开启 运行日志，方便跟踪查看log；
在创建作业时，注意oss与ossref功能上区别；
在shell脚本，每行是要加”;”作为结尾；
在shell脚本，假如最后一行假如有 chown/chmod命令，虽然log日志显示错误和该作业状态为失败，但其实 该命令是执行成功的。所以我们一般在最后一行添加”echo “end script.”;”；
在创建执行计划时，按照作业的功能，分组来配置作业计划，便于更加好的调试；
可以直接ssh登录header(master)主机上，手工执行脚本或者命令来调试。
验证阿里云EMR Job Run数据的准确性
当迁移好Stage job，那么接下来要验证rundeck job跑的数据结果和阿里云EMR 的job跑的结果，一般我们的开发人员或者Owner采取两种方法来验证。
对比结果文件的数据行数；
使用Beyond Compare 4工具，将结果文件的数据内容对比； （一般抽检第一行和最后一行数据）
迁移Product Job 至阿里云EMR和验证结果数据准确性
接下来迁移Rundeck Product Job至阿里云EMR上，其实主要修改两点:
将脚本的传入参数由stage改为prod；
修改作业的名称、参数路径由stage改为prod。 然后每个项目的job run一次和rundeck的job数据进行严格的验证准确性。
停止前身Rundeck Job，正式调度阿里云EMR的执行计划
将Rundeck的Product Job暂停调度，停止集群服务，释放CPU和Memory资源。
然后正式配置、调度阿里云EMR的ETL Product的 执行计划XXX_Product-EMR_ETL。
其ETL业务在EMR的基本架构如图所示:
未来规划
目前，泰为信息科技（上海）有限公司的中国区项目资源基本都使用了阿里云的ECS机器资源，OSS存储资源，负载均衡，专有网路VPC等；在未来，我司会根据项目的需求和管理性等，会继续调研迁移项目，上云数据库RDS、Redis和数加等产品。
小小总结
从公司方面来说:
减少运维人员的维护成本，更加易用；
释放集群机器资源，降低成本；
可以弹性调整集群规模；
可靠性和可用性得到了保证（SLA为99.999%）；
加强用户作业信息的安全性；
提高管理控制，并建立战略继续提高生产力；
从个人方面来说:
对业务逻辑有着深刻了解；
Hive手工打补丁和编译版本；
对大数据这块有着更深刻的理解；
从我们对阿里云EMR希望方面来说:
我们的作业由于数据依赖关系，应该为并行配置，但当前配置只为串行配置；
作业失败，能够有retry机制；
作业数量太多，能够时间点备份（导出）和恢复；
作业列表提供 project来分组，毕竟数量太多，现在只能在作业名称上加stage，product来区别；
能够提供邮件预警通知；
增加对EMR不同版本的选择；
最后总结一下，阿里云EMR从2015年11月发布EMR-1.0.0版本以来，至今才1年不到，已经升级为EMR-2.1.0版本，增加了许多的功能，如用户作业信息加密、与OSS存储无私接缝等等。无论是在开发者社区还是在微信阿里云大数据群组里，EMR的开发者们积极与我们沟通，及时认真回答我们提出的每一个问题，及时听取我们用户的需求。所以我们有理由地相信，阿里云EMR在未来，会越走越远，越做越好!
泰为公司成立于1999年，总部坐落于美国硅谷所在地加利福尼亚的桑尼维尔市。泰为公司是全球无线位置领域的领跑者之一，其手机导航产品曾服务于无线运营商AT&T, Sprint, CMCC等。Telenav自有品牌Scout产品，是当今能与Google map和Apple map竞争的为数不多的产品。也是全球车载导航产品的供应商，目前其导航产品正在Ford等世界顶级车厂中进行商用服务。
