据阿里云EMR快速搭建数据平台

2019独角兽企业重金招聘Python工程师标准>>>

EMR的完整技术堆栈及测试选型：

emr选用主流lambda架构，兼顾hadoop,spark两大引擎，并做了跨引擎整合，从分步式计算，调度等多方面做了高度统一化和抽象化，上层应用和开发几乎是透明无感知的（当然这是对于开发人员来说的，架构和资深研发看见小心触电字样，依然还是要打开保险，抻手进去的 ^^）

选用原因：

1.部署这么一套完备的基础平台还是很费劲的，自己搭也只会选其中的几块做整合，未来有需求才会增加，如果大的技术堆栈在未来发展依然主流，那一步到位必然省事，但现在spark大有以一盖全的可能，但市面人力不一定都能找到，综合考虑全选有备无患，反正也不多收费，空间留着也浪费

2.平台运维，故障解决，技术支持，扩容，灾备等云的人力财力智力优势不多说
3.单说引擎他们还是做了些安全稳定性优化和性能增强的，还有和自家的oss，sls,或是采集和MaxcCompute的产品对接提供原生支持和更优化方案

缺点与遇到的坑：

1.Emr并不是maxCompute（官网大多介绍的是后者）,像是个中间实验版本(目前只收集群资源的费用，而emr本身免费),有的Emr版本并不成熟，如我们选最新版3.0.0，他选择的spark2.0版本(不支持版本定制、切换、升迁等)，流处理竟有bug未解决，不支持就发布出来了

2.集群网络环境一会精典一会vpc，还有各种对应endpoint的访问方式，让个不懂运维或网络知识的人操作还是有点头疼

3.切换回2.4.1，spark1.6.3，sql速度据说比2.0差十倍不说，原3.0.0交互环境可以支持阿里自家的oss的，现2.4.1版本竟不支持，用Zeppelin自己加jar包才可以

4.Zeppelin的整合并未像其它产品一样积成的如何好，像个开源包放那而于，如oss,sls，还有rds的连接驱动等要手功配置才可以使用；加依赖也有问题不能识别到spark进程classpath，要改zeppelin-env submit-option项目中加—jar参数，还要手动集群环境重启zeppelin才能支持；且spark的conf配置改动可能会使zeppelin不可用；其它的如hbase群里反映还是有很多问题，还没继续测试，总之兼容性稳定性改进空间还有很大

转载于:https://my.oschina.net/hblt147/blog/871014