本场视频地址：助力云上开源生态 - 阿里云开源大数据平台的发展
PPT资料：助力云上开源生态 - 阿里云开源大数据平台的发展
本次分享的内容主要分为四个部分：
- 发展历程
- 云上现状
- 云上开源生态的最佳实践
- 开源大数据平台的发展展望
一、发展历程
在2015年，阿里巴巴刚开始做开源大数据平台的时候，摆在面前的有三种选择，分别是使用开源的Hadoop体系、CDH和HDP，以及当时的ODPS（现在的MaxCompute）。在那个时候，在大洋彼岸的AWS有一款大数据产品叫做EMR，因此阿里云当时也希望借鉴AWS的经验来做开源大数据平台，希望将大数据能力和云原生能力进行深度结合。
阿里云在2015年6月份的时候就开始研发自己的开源大数据平台并实现了第一个“镜像+脚本”的版本，这个版本可以实现在最短的时间内将Spark环境搭建起来，而且这个版本很快上线并且发布到GitHub上。当时使用的API很像现在的编排服务，但是这样服务的缺点是只能一次性搭建，因此维护起来非常麻烦。
在2015年11月份，阿里云正式将E-MapReduce独立云产品推出市场。大家都知道MapReduce的思想来自于谷歌，其代表了大数据理论，因此阿里巴巴将这款大数据产品命名为E-MapReduce，使得大家看到名字就知道其产品的主要作用。
阿里云E-MapReduce上线之后经过四年的时间发展到现在，E-MapReduce 4.0即将发布版本，并且在新版本中将会支持Hadoop 3.0以及其他新功能。
发展到今天，阿里云E-MapReduce将会为开源生态提供基础平台，在这个平台上能够让大家选择各种各样的开源产品，并且不会限制大家使用自定义的能力。此外，阿里云E-MapReduce也希望能够将阿里巴巴整个云智能平台的计算能力输出给大家，为大家提供云原生能力和弹性调度能力。未来，E-MapReduce会陆续集成各种开源技术和能力，并且会在这些开源技术之上为大家提供更好的优化的技术，一方面提高稳定性，另外一方面也提升性能，并且也会进行能力的适配。最后一点就是实现云原生的结合，大家使用开源或者自建的大数据方案往往难以和云原生技术或者基础设施进行结合或者难以获得较高的性能，因此阿里巴巴希望通过E-MapReduce能够更好地和云原生技术进行结合。
总结阿里巴巴E-MapReduce的发展历程，最开始就是实现了一个AWS EMR Like的产品，运行一年之后发现AWS的纯动态方式并不适合国内的场景，因此实现了第一次调整，更加重视常驻集群，并且强化作业合度调度能力。经过第一次调整之后，阿里云发现E-MapReduce的能力还是无法满足需求，因此在第二次调整中提供了完善的Web控制台能力，并且支持了集群的高可用和高安全，也在外围支持了Impala、Kafka、Druid等各个场景下的软件，进而可以更好地支持各个业务场景。除此之外，还支持了深度学习的场景，将经过阿里巴巴自身优化的机器学习算法提供到平台之上。如今，E-MapReduce仍在继续调整，希望能够提供更加完善的大数据平台，更加智能化的服务能力，并且使得底层更加轻量，也使得计算平台整体能力能够对外输出出去。
二、云上现状
云上的生态概览
下图展示了阿里云的大数据生态概览。在数据来源方面，开源方面有HDFS和Kafka，阿里巴巴则提供了OSS、SLS、RDS以及消息队列等服务。所有数据可以通过开源的Hive、Spark、Flink、Rresto、TensorFlow以及阿里巴巴的MaxCompute、Flink/TensorFlow等服务进行计算，并且还可以与阿里的自身体系如DataWorks、DataV以及QuickBI进行融合。目前，云上大数据方案可以认为是半托管的服务，阿里云能够帮助客户进行运维并且提供运维支撑服务。
多样的存储选择
在阿里云上，大数据存储主要有三种选择，分别为Hadoop HDFS、Alibaba HDFS和OSS。Hadoop HDFS有三种存储方式，EBS云盘存储数据可靠，但是后台有多个数据副本，因此成本较高，同时通过网络获取数据性能较低；D1本地磁盘以及I1/I2本地词盘性能比较高，成本也比较低，但是数据容易丢失，并且运维成本较高。另外一种选择是Alibaba HDFS，这种方式数据可靠，成本中等，并且数据全部通过网络传输，没有本地计算。OSS标准存储经过阿里巴巴的改造和优化之后可以直接在Hadoop中进行读写，这就是所谓的NativeOSS，NativeOSS存储数据可靠，成本较低，并且通用性比较好，但是性能比较低。因此，进一步在NativeOSS上进行了强化，实现了JindoFS，JindoFS做到了数据可靠，成本较低，性能高并且通用性较好，但是需要额外的存储成本。
弹性实践
云上做计算需要充分发挥出弹性能力，否则就无法发挥出云的真正价值。而为了发挥出云弹性能力，各大云产商的所有大数据能力都会有Master节点以及一组工作节点Task，Task节点只进行计算但是不会进行数据存储，因此在云上执行计算任务时，Task节点可以进行弹性伸缩，还可以通过Stop Instance来降低成本。在计算任务的高峰期购买Task节点，当高峰期过去之后，就可以释放Task节点。阿里云还为客户提供了一套伸缩机制，既可以按照时间伸缩，也可以按照负载伸缩。
集群架构
下图展示的是阿里云比较推荐的云上集群架构。如图中左侧所示的是建立的Hadoop集群，其底层全部使用OSS做数据存储，而在OSS之上存在几个独立的计算集群，比如Hive、Spark以及Presto等，而且这些集群全部都是灵活可销毁的。右侧同样建立Hadoop集群，而外侧则提供了Gateway以及Client来接受请求。此外，很多客户可能在云上没有使用OSS或者混合使用OSS和HDFS，借助这种集群架构，可以帮助用户跨越数据存储的障碍。
三、云上开源生态的最佳实践
存储的选择和优化
在2015年的时候，想要在阿里云上部署大数据平台只有云盘存储可以选择，比如使用SSD等高效存储盘，因此这样的成本会非常高。到2017年左右，阿里云智能团队和ECS团队合作做了本地盘机型，后来还和ECS团队合作做了D1，并且适配了一些国内更能够适应的场景。在2016年，E-MapReduce实现了和OSS的结合，当时因为带宽限制，因此使用的客户较少。到如今，针对之前的发展和合作经验，E-MapReduce可以选择使用JindoFS、Alibaba HDFS等进行存储。
IaaS层升级
为了让客户更好地使用E-MapReduce，IaaS层也经历了多次升级。第一代是D1和I1，第二代是D2和I2，提供了更高的网络带宽，本地磁盘提供了极高的性能，但同时也带来了运维成本的增加。而通过磁盘的热更换，提供了更好的体验整套的运维的支持链路，并且提供了整套硬件的监测、预警、通知、更换等操作完成主动运维流程。
存储访问优化方案JindoFS
JindoFS的目的在于让大家更好地使用存储与计算分离的架构。在JindoFS的架构之下，所有数据都会存储在OSS上面，所有的计算都放在动态集群上面进行，并且可以随时进行计算伸缩，JindoFS为客户提供了高性能的数据存取能力，和高性价比、无限扩展的弹性存储能力。这里面临的最大挑战就是OSS和计算集群之间的网络带宽，而JindoFS方案中通过本地缓存技术大大降低了时延，提升了性能效率。同时，因为JindoFS采用了基于存储计算分离的架构，因此客户不用担心缓存数据的丢失问题。
更多的产品的融合和增强
阿里云E-MapReduce融合了更多的产品，比如Spark、Flink、TensorFlow、Elaticsearch、Dataworks等，并在这些产品的基础之上做了增强。
四、开源大数据平台的发展展望
阿里云E-MapReduce希望基于平台实现更多的方案，希望能够更好地赋能客户的业务场景。比如在实时数仓方案和Spark Streaming SQL中，实现了将业务数据库的数据实时同步到kudo中，可以实现对业务数据库中的数据进行实时OLAP分析的能力。
未来，EMR将会实现与K8S的融合，希望能够帮助客户更好地节约成本，让用户在阿里云内部可以腾挪自己的资源来完成各种工作，支持客户在业务低峰时将K8S节点加入到Hadoop节点中作为计算补充，在业务高峰时将集群还给业务，这样在不增加额外成本的情况下增加计算能力，更加充分地利用资源。
很多的用户希望实现多云和混合云，因此阿里巴巴希望为客户提供在线下IDC用法不变的情况下，将冷数据通过专线传输到动态存储，并且使用E-MapReduce等进行动态赋能和线下集群结合起来使用的能力，并且与此同时充分利用线下和线上的能力。
阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区，定期推送精彩案例，技术专家直播，问答区数个Spark技术同学每日在线答疑，只为营造纯粹的Spark氛围，欢迎钉钉扫码加入！
