1. 1.58元/小时起快速体验 Hadoop & Spark ，为你助力大数据计算    
      阿里云EMR是基于 Hadoop 的生态环境来搭建，同时可以跟阿里云的对象存储服务OSS等云服务进行无缝数据交换，方便用户将数据在存储平台和计算平台之间进行输入输出，以满足不同业务类型的需要，所以对阿里云EMR充满期待。

      在登录和打开阿里云 EMR的console web界面时，被阿里这种简约扁平化设计风格深深吸引着。
      其中阿里云EMR的”概览、集群、作业、执行计划、报警、帮助”六大模块，操作起来简单易上手，但其底层实现的架构设计必定很复杂。其中阿里云EMR的各种文档很齐全，很方便我们能够快速了解和迅速部署我们自己的EMR集群。

2.深究ETL业务逻辑

    在计划迁移Rundeck上的Product Job到阿里云EMR上，一定要先充分地了解现有业务的处理逻辑、Job脚本代码以及集群组件Hadoop、Hive环境等。为了不影响现有产品环境的稳定性，所以一般要先选择Stage的Job进行迁移，调试。其ETL业务在ETL Cluster的基本架构如图所示：

3.调研阿里云EMR产品

   在接下来的工作中，仔细调研阿里云EMR产品，发现有这么四点优势吧。

• 有易用性 ;
• 有和OSS、RDS等产品深度结合；
• 有较高的安全性，主要整合了阿里云 RAM 资源权限管理系统，通过主子账号对服务权限进行隔离；
• 其实还有更重要一点，在 [2016云栖大会] 上，其价格再次降低，更加受企业青睐。

由于我们的Product Job是每天凌晨run，所以阿里云EMR的按需创建方案很适合我们当前的ETL 业务，而且当Job run结束时，无论执行计划是否成功，都会释放集群资源，降低企业的cost。

4.定制化所属自己的集群环境

    当前我们的业务是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。

5.迁移Stage Job至阿里云EMR的流程

EMR集群的机器配置：

• 4 核 16GB / SSD云盘 / 40G X 1 / series II 1台(Master)
• 4 核 16GB / SSD云盘 / 40G X 4 / series II 3台(Core)

其具体流程：

• 在作业tab页，创建4组共16个job；
• 在执行计划tab页，创建执行计划，其中需要配置如下 ?调度策略为每天凌晨运行 ?关联集群为按需创建集群 ?作业配置为按顺序绑定16个job ?启动报警模块，推送消息给Administrator 
  

在迁移过程，有几点建议：

• 先选择按量付费创建好集群，切不可在执行计划中按需创建集群；
• 开启 运行日志，方便跟踪查看log；
• 在创建作业时，注意oss与ossref功能上区别；
• 在shell脚本，每行是要加”;”作为结尾；
• 在shell脚本，假如最后一行假如有 chown/chmod命令，虽然log日志显示错误和该作业状态为失败，但其实 该命令是执行成功的。所以我们一般在最后一行添加”echo “end script.”;”；
• 在创建执行计划时，按照作业的功能，分组来配置作业计划，便于更加好的调试；
• 可以直接ssh登录header(master)主机上，手工执行脚本或者命令来调试。

6.验证阿里云EMR Job Run数据的准确性
   当迁移好Stage job，那么接下来要验证rundeck job跑的数据结果和阿里云EMR 的job跑的结果，一般我们的开发人员或者Owner采取两种方法来验证。

• 对比结果文件的数据行数；
• 使用Beyond Compare 4工具，将结果文件的数据内容对比； （一般抽检第一行和最后一行数据）

7.迁移Product Job 至阿里云EMR和验证结果数据准确性
   接下来迁移Rundeck Product Job至阿里云EMR上，其实主要修改两点:

• 将脚本的传入参数由stage改为prod；
• 修改作业的名称、参数路径由stage改为prod。 然后每个项目的job run一次和rundeck的job数据进行严格的验证准确性。

8.停止前身Rundeck Job，正式调度阿里云EMR的执行计划
    将Rundeck的Product Job暂停调度，停止集群服务，释放CPU和Memory资源。
然后正式配置、调度阿里云EMR的ETL Product的 执行计划XXX_Product-EMR_ETL。

其ETL业务在EMR的基本架构如图所示:

9.未来规划
   目前，泰为信息科技（上海）有限公司的中国区项目资源基本都使用了阿里云的ECS机器资源，OSS存储资源，负载均衡，专有网路VPC等；在未来，我司会根据项目的需求和管理性等，会继续调研迁移项目，上云数据库RDS、Redis和数加等产品。

10.小小总结
从公司方面来说:

• 减少运维人员的维护成本，更加易用；
• 每天调度EMR的Product执行计划，每月共只需约295元，而之前搭建ETL集群环境的5台ECS机器资源，每月共需3625元，大大降低地公司的项目费用；
• 释放集群机器资源，降低成本；
• 可以弹性调整集群规模；
• 可靠性和可用性得到了保证（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在未来，会越走越远，越做越好!

11.参考文档

• 创建集群: https://help.aliyun.com/document_detail/28088.html?spm=5176.product28066.4.33.D1FEdf
• 作业配置(shell): https://help.aliyun.com/document_detail/42597.html?spm=5176.doc32468.6.145.8zFTmu
• 创建执行计划: https://help.aliyun.com/document_detail/28101.html?spm=5176.product28066.4.35.D1FEdf
• oss与ossref区别: oss:// 的前缀代表数据路径指向一个 OSS 路径，当要读写该数据的时候，这个指明了操作的路径，与 hdfs:// 类似。 ossref:// 同样是指向一个 OSS 的路径，不同的是它会将对应的代码资源下载到本地，然后将命令行 中的路径替换为本地路径。它是用于更方便地运行一些本地代码，而不需要登录到机器上去上传代码和依赖的资源包。 注意： ossref 不可以用来下载过大的数据资源，否则会导致集群作业的失败。
• Apache Hive-1.2.1 Manual Patch and Compile https://yq.aliyun.com/articles/62488?spm=5176.8091938.0.0.Je0Yn6
• 记录ALiYun EMR常用服务的手动启动和停止命令(hdfs/yarn/mr-jobhistory/zk/spark-history)https://yq.aliyun.com/articles/62499?spm=5176.8091938.0.0.Je0Yn6

泰为公司成立于1999年，总部坐落于美国硅谷所在地加利福尼亚的桑尼维尔市。泰为公司是全球无线位置领域的领跑者之一，其手机导航产品曾服务于无线运营商AT&T, Sprint, CMCC等。Telenav自有品牌Scout产品，是当今能与Google map和Apple map竞争的为数不多的产品。也是全球车载导航产品的供应商，目前其导航产品正在Ford等世界顶级车厂中进行商用服务。

说明: 该文为博主亲自撰写，委托阿里运营部发表
阿里运营部发表出处: https://yq.aliyun.com/articles/62933 
关于作者：主要从事大数据平台产品的技术工作；负责设计、构建和优化基于HDFS/HBase的存储平台架构；负责整体提升Hadoop/Hbase等集群的高可用性、高性能、高扩展特性；负责对公司的Apache Hadoop1.2、CDH4及CDH5集群的部署、监控、调优和运维；此外,还精通Java、Shell、Python编程和管理SQL数据库及熟悉NOSQL的经验。