开发者学堂课程【E-MapReduce 入门课程：走进开源大数据平台 EMR】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/759/detail/13333
走进开源大数据平台 EMR
内容介绍
一、引言
二、发展历程
三、现状
四、为什么选 EMR
五、展望
一、引言
大数据技术在当前是非常热门的技术趋势，其中开源大数据技术在解决互联网公司传统的企业的大数据问题，包括大数据分析、 Bi 报表、实时的数据处理、人工智能等问题方面发挥了非常大的作用。
阿里云从2015年开始在云上构建大数据产品 EMR ，这个产品主要是将大数据的组件跟云相结合来解决传统的产品构建自大数据的系统上的迁移，产品主要包含以下几个方面的特点，第一整个系统的组件与开源大数据组件完全兼容，其中包括常用的大众曲线 hds 、yang 等等，能以暂时解决客户的各种大数据问题；
另外 EMR 产品是基于阿里云非常先进的 s 基础底座 ECS 来构建的，具备极度的弹性性能，能够根据用户业务的需求以及业务的成长和缩减来进行弹性伸缩， EMR 支持计算存储分离的价格，计算存储两种资源能够分别解耦，这样可以极大的降低客户的成本；
第四点 EMR 整体的组件性能包括 hive，spark 在全球也是处于领先地位，在常见的 tbc 等标准的 性能 EMR 长期处于前列，在最新的 EMR 版本中也支持了阿里云的数据库景观，数据服务能够做到打破数据孤岛、语言数据共享、计算容器化等最佳的用户实践。本次训练包括理论和实践两个部分，希望大家能够在 EMR 训练中有所收获，有所成长，领略大数据的魅力。
今天为大家介绍关于 EMR 的发展历程、产品功能以及未来的发展一个展望。在这节课程之后还会有其他的同事来帮忙分享关于这个产品具体的详细的功能介绍以及关于存储解决方案的一些选择和优劣势分析以及关于 EMR 产品的简单功能演示。
第一部分是简单介绍一下产品的发展历程，第二部分是介绍一下产品的现状，第三部分介绍一下在什么场景下应该选择 EMR 以及 EMR 带来的这个价值是什么？第四部分就是可能会做一个简单的展望。
二、发展历程
发展历程这部分会简单介绍为什么会有这么一个产品？这个产品在过去四年多的时间里产生了哪些变化？在这档期的时候，如果希望在阿里云上使用大数据平台会面临三种选择，第一是采用阿卡奇 Hadoop 社区开源版本去构建开源大数据平台，这里面包括很多的组件，所以采用这个版本去构建对个人的要求是是比较高的，因为一方面要考虑到组建之间的兼容性，第二方面因为社区并没有提供一个比较清晰的一个控台界面，所以说很多命令都需要在黑屏的方式下去操作，这个比较大的限制了 Hadoop 平台的易用性以及使用的一个门槛，另外一个选择就是采用 Hadoop 的发行版本，好多发行版厂商提供了一个发现版软件，那这些发现版软件相对来说提供了比较完善的组件的兼容性的测试以及控台界面的功能，对用户来说相对来说也是比较友好的。
那还有一种选择就是使用阿里云自研的一款开源大数据平台，叫做 max compute ，简称 ODPS ，max compute 是最近名称修改后对它的一个称呼，它是一个完全基于自研的超大规模的大数据分析平台，使用法上也是跟 help 是非常类似的， EMR 产品是在15年6月份，最早收入是15年6月份在云上发布上线的，这个产品当时的名称还不是 EMR ，它只是一个镜像。
那在早期的时候只是可以通过使用镜像，把这个镜像下载到 ECS 上，快速搭建一个 Spark集群，使用这种方式来运行 Spark 命令，在15年的11月份，产品的正式立项，它作为一个正式的独立产品对外发布开始公测。
在16年的6月，也就是说距今已经有四年多的时间了，产品正式商业化，达到一个相关的要求，然后开始对外提供的服务，目前 EMR作为阿里云上非常重要的一款云上开源大数据生态级的产品，它已经经历了四年多商业化的一个历程。 EMR其实在最早期发现是在国外的相应厂商上有类似的这种产品，但是发现像这种产品的一个特点是云原生的，面向于临时集群，一个任务其中一个集群这种方式来自这么一个产品，这个产品在最早期的时候，有很多用户，它的需求也比较简单，就仅仅是运行一个大数据的任务，它通过这种临时集训的方式能够比较好的满足需求。
任务运行完毕，然后进行释放，，这种情况下对于比较简单的分析场景是完全能够满足的，但是随着国内市场的发展和一些更多客户的交流，发现其实他们更多的是需要一种长期集训，不仅是因为任务数比较多，而且比较难准确的预估出资源消耗的情况，所以说往往就是建立一个集群，然后跑着大量的任务，但迁移上云的时候，这个 gap 是比较大，从一个比较全量的一个集群转到云上拆分成任务，通过任务来去集训，然后再评估需要多少资源，所以说在这种情况下就发现用户在上云的时候，发现它要求一个比较强的运维能力和相应的集群管理能力，同时也希望有个更好的工作流调度的一个工具来帮助更好的管理集群和运维集群，降低开源大数据的一个使用门槛，那在这个时间这个产品有了一系列的转化，增加了很多组建管理的功能，增强了工作流管理的1.0的开发，最早是在17年、18年上线的，经过这段时间一段产品的打磨之后就发现其实大大降低了用户的使用门槛，而不仅仅是说运行一个任务，在这种情况下能够承载更多的大客户，它在工作流比较复杂的时候，面临着组件多样化选择的时候，这个产品慢慢地有了各种的需求。
到了第三步的时候发现开源大数据的场景不断丰富，开源大数据的技术也不断的引进和显现迭代，在这种情况对于集群的稳定性、安全性提出了更高的要求，所以在这个阶段就把相关的组件集成进来作为集群管理，统一的集群权限管理和统一的健全管理的工具和组件，同时基本上主要组件都已经实现了高可用的架构，这些服务都可以做到HA ，降低了用户自己去配置 HA 的复杂度和管理成本，同时也不断地去拓展开源大数据的使用场景，不断的迭代过程中加入了很多开源大数据的组件，同时看到在过去两年间深度学习技术成长非常迅速，而继续学习与和声的学习和大数据分析其实是一个上下游的关系，继续学习和深入学习的数据要依赖于大数据分析的 ETL 或者它的产出，这种情况下也把继续学习的技术加入到一种独立的集训类型，之后再进行统一的管理。
随着产品的不断成熟到了第四个阶段，就是更好的去串联云上的大数据生态，这种情况下要求这个集群的组织更加的轻量级和智能化，这个阶段目前也在不断地去看怎么去更好的串联云上的各种生态，目前已经实现了 PAI 这么一个产品的结合，目前在创建集群的时候，它使用的组件都是从 PAI 这个产品组件导入过来的，它使用的不仅仅是开源，而是对开源技术的一个增强，同时看到有很多用户希望在开源大数据生态里边使用比较成熟的工作流调度、权限管理、数据治理、数据地图的一款工具，它主要用来构建自己的数据状态，帮助自己快速的上手，开源大数据在这种背景下在过去的一年里也跟 Dataworks 做了深度的继承，目前数据学院、数据治理以及数据质量也已经陆陆续续的上线，后面会把 Dataworks 
权限管理跟 EMR 进一步打通，实现 Dataworks 和 EMR 能够有一个更好的更完整的用户体验，目前另外一个趋势就是看到很多的用户，在使用开源大数据的时候，还有一些对于 K8s 的这么一个需求，所以说目前也上线了 K8s的数据类型，它也是能够更更好的帮助用户去管理集成低层的资源。
三、现状
介绍这个产品过去的一个发展经历，那再看一下目前集群一个现状的情况。
EMR是云上主打的一款开源大数据生态的软件站，这套软件站分为四个部分，深蓝色的部分主要是开源大数据生态的组件，基本上没有太多的修改，还是纯粹基于社区开源版本来做的一个继承，在这种情况下其实使用起来是和开源完全没有差别的，另外针对用户的一些使用的场景，会对开源组件进行激烈的修改和增强，这个就是浅绿色这块的一个组件，比如说像spark这块做了很多系列的性能增强，而且是比开源的性能是有大幅提升的，但是这种增强完全不影响对开源的一个使用体验，意思就是说如果你使用八个组件，可以说和开源完全一样，而且这种优化也是采用插件的机制，这样就可以通过参数的方式打开或者关闭，所以说对于浅绿色的部分来说就基于开源有一系列的行动增强。
对于橙色的部分就是自研的组件，比如一套集群管理的组件，这套其实并不是开源大数据的一个组件，但是它在集群管理方面属于必备的组件，另外一方面就是比如说像 Jindo FS 在后面的训练营上也会有介绍到， Jindo FS 是从去年开始正式对外发布一款数据构建的重要组件，今年性能有了大幅度的提升，功能有了快速的增强和完善。目前有大量的用户使用 Jindo FS 快速构建数据库实现了数据的分层存储，达到了一个性能的提升，这里边显示色的部分是跟开源大数据生态，跟阿里云现有产品的一个继承的一些产品，这里的产品包括刚才提到的 Dataworks 、PAI、OSS、ESS以及SLS 这些产品。
EMR 开源软件栈从16年产品诞生以来，它不断的去丰富和增强，这几年的发展基本上还是按照开源社区不断的往开源大数据的组件上和场景应用的一个拓展，同时也不断的去丰富这个软件栈，比如说在17年加入了 impala 和 Presto，在18年加入了 Fink数据科学流式计算，在19年对 Hadop 版本做了一个比较大的版本升级，不仅是支持好多2.0的版本，同时也支持好多3.0的版本。
目前这个 EMR 软件栈有两个分支，一个是 EMR3.0的版本对应的是 Hadop 2.0的版本，另外一个分支对应的是 EMR4.0的版本对应的是Hadop 3.0的版本，开源这个3.0的版本同时支持很多版本。同时也根据不断的场景，比如刚才提到一下数据仓库建设的场景，用来做交互式分析和数据查询，同时针对这几个在18年开始比较流行的 Fink 加入到软件栈来，用一个流失计算以及围绕大数据的融合上线了数据科学集群，引入数据框架能够帮助用户从大数据分析到继续学习一体化的这么一个架构。
随着云上数据湖的不断的发展，也加入了 Kudu、Delta Lake的组件，它们能够帮助组件快速的去构建运上数据库的一个平台，也能够支持对数据的一些更新和查询，快速的一个实时数仓的构建。
目前在购买 EMR 数据集群的时候有六种类型，一种是大数据平台类型（hadoop），这里面包括数据仓库（Hive ）、 离线计算（MR,Spark ）、流式计算（Flink, Spark Streaming）、Ad hoc查询（Impala, Presto）、NoSQL（HBase ）以及大数据工具(HUE,Zeppelin)。另外一种是 Data Science 集群,它除了一些常用的大数据组件,还集成了一些企业版本,同时也支持数据科学家常用的组件和工具, Data Science的最大的一个优势在于说是一个半托管的架构，它和 EMR 等其他的集群类型都是半托管的架构，那这种情况下可以更加方便简单的去安装进学习、深度学习常用的一些包。这样就会更加灵活和透明。
用户可以自定义去部署自己的软件环境，那这样就更加容易把继续学习、深度学习和大数据串联在一起。
第三种集群类型是 Kafka 消息队列这个集群类型,这个主要也是采用两个版本，一个是EMR 3.0的版本主要用的是Kafka1.0 的版本，EMR 4.0的版本采用的是Kafka2.0 的版本,它提供 Kafka 这个组件之外还做了一系列包括源数据管理的增强，集群的管理采用了 Kafka 开源 manager 这个组件。
第四种集群类型是 Data Flow,这个集群类型采用的是 Hadoop 这种架构，但是它不是用的开源的,如果这块需要一个比较轻量级的一个继续学习的流式计算的类型,那就可以采用 Data Flow 这种数据类型,它相对于开源来说有更好的性能以及更加完善的一个用户体验，同时也因为继承了 Alink 这个组件，所以可以实现流失的继续学习这么一个功能和能力，做一些浅层的算法是完全足够的，当集群规模非常大的时候，可能会考虑说把补批本从主题群里拿出来作为一个独立的分布式的一个协调分布式的这么一个能力，这种情况下可以选择类型 ZooKeeper 的集群,同时如果选择需要这种独立的一个 druid集群,这可以可以选择实时的 OLAP这个集群,它上面用的计算引擎是一个druid,数据可视化工具的用的是superset，当然这块的位置可以选择很多组件作为后端的位置存储。目前druid集群最新的版本也是0.18的，这个版本是一个非常新的一个版本。
四、为什么选 EMR
第三部分给大家简单介绍一下为什么应该选择 EMR 作为云上的开源大数据平台，也就说在什么场景下可能会用到 EMR ， EMR 有几个比较重要的产品特性，第一个是开源,就是所有的组件都是基于开源组件来做的，而且会跟开源社区的发展不断的去迭代引进，同时因为不仅仅是对一个开源软件的一个集成，而且会对一些逐渐的版本进行适配，确保组件的兼容性是没有问题的，所以说这相对来说它有着更好的稳定性;
第二部分,基于开源社区做了一系列的性能优化，所以说它的性能会比开源的这个版本有了比较大的提升,同时 EMR 会基于开源这个大数据的生态，针对阿里云的环境去做一系列的弹性能力和按量付费的能力，不需要去预估说这个经营规模到底有多大，到底需要多少个数据存储啊，这只需要根据按量使用，按需谈过弹性扩展，然后这样能够迅速满足对资源的需求，也就是说比如说业务发展非常迅速，那在这种情况下可能会需要快速的去部署一些营商的资源，那需要 EMR就能实现分钟级别的创建集群和分钟级别的去扩展集群,同时面临大数据计算是一个典型的有波峰和波谷的一个特性，也就是说可能在晚上12点以后会有一个比较大的任务，在这种情况下这个任务需要比较高的 SLA 保障，那在白天这个任务跑完之后可能会面临资源的一个低谷,这种情况下通过 EMR 弹性收缩的能力可以很好去配合这种算例的弹性资源的计算，从而达到一个成节省成本的效果;第四个部分主要是可以更好去对接云上的生态，相对于社区而言，它更多的是一个通用上的考虑，而 EMR
产品会更好去跟云上的一些产品基层适配云上更多的一些场景，比如说数据状态和数据管理，在云上其实都有一系列的工具和一系列的产品,那 EMR这个产品可以更加容易的去跟这些品牌基层去打通。
下面简单介绍一下刚才提到的计算的弹性方面，这个 EMR 的集群部署分为三种角色，分别是 Master 类型、 core 类型和 Task 类型的, Master 集群主要是部署 master 服务，而core 节点部署的是除了存储还有计算的一些 slive 的服务，这些服务都部署在 core 节点上,而 Task 节点仅仅用来部署计算服务，所以说它在集群模型里面是不允许弹性伸缩的，而 Task 节点因为它是一个纯计算节点，所以说它弹性伸缩起来是相对来说比较方便，而且对任务的影响，对业务的影响都是比较小的，所以说在目前的这种集群架构下面， Task 的节点是可以灵活去做弹性的,这个集群可以包年包月的去买，也可以用按量付费的方式去买,那同时也可以在一个集群下面，master和core 采用的是包年包月的这种方式，因为这些资源的相对来说是固定的，同时用包年包月的方式去购买也可以节省成本,而Task 是一个只需要做计算的一个节点，所以说它可以用来做弹性伸缩,它可以用按量付方式去购买，同时 Task 点在用弹性伸缩的时候也支持使用 sport ，去对资源做成本的一个降低,目前 sport 的成本仅仅是按量付费的一到两周，但是因为它的LV 是比较低，竞技能保证每个小时是可以正常使用一个小时之后会重新进价，如果由于库存或者进价的原因无法进到，可能会对任务的运行产生一些影响，所以说在任务运行选择 sport 的实力的时候，需要考虑到 SLV 的要求,这种弹性伸缩的方式也是支持包年包月,也是支持按时间弹性伸缩或者按负载进行弹性这两种方式，可以设置一个按时间伸缩的规则，比如说在每天晚上12点开始做弹性伸缩的动作，然后可以精确预估出这个任务会在6点或者7点跑完，那到了7点再进行一个缩容动作，确保这个任务能够实现一个成本的节省,也可以实现按负载伸缩，目前这个伸缩指标主要是采用了CPU usage 这些个指标来作为 yang 出发的一个 trigger ,这个指标达到一个设定的预警值或者设定的弹性伸缩门槛的时候,它就开始做一个弹性伸缩的一个动作。
在云上存储又有多样化的解决方案，这里的解决方案可以使用和线下一样的 HDFS ，也可以使用阿里巴巴的 HDFS 服务或者使用 OSS 标准型，每一种服务都有不同的特点和特性，这里重点介绍一下 HDFS 和 OSS ，当使用 HDFS 服务的时候可能会有两种选择，一种是使用 EDS 快存储，另外一种是使用 D 系列存储，这种本地盘存储的特点是成本低，但是它的数据可靠性是由应用层保证的，那如果数据量比较小的情况下建议是推荐使用云盘，这个小是数据小于10tb 以下，其实它的存储空间是比较大的，所以说当数据是小于10 tb 或者27tb 的时候，建议都是使用 EDS 存储，这种情况它的优势是更加灵活，当随着成本可以不断去增额，可以随着数据量的不断增加更加灵活的去排容量，但是问题在于成本是相对来说比较高的，因为它的数据可考性是通过产品上的一些心理化来实现的，所以说它在性能上是比本地盘的实力会相对来说更低一些，但是它的可靠性会更高一些。
那运维成本也会更低，因为它的数据可靠性是由 EBS 产品来保障的。当选择本地盘也就是 D 系列或者 Y 系列的时候，因为应用层是用这个来保障数据可靠性，所以说这个运维成本会相对来说更高好，但是因为本地是一块物理盘，所以说它的购买成本是更低的，这个需要根据具体的一个业务上的考量来选择合适的存储方式。这里还可以说一下的就是 D 系列和 I 系列需要应用层来保障数据可靠性，这块可以看到一个优势是说 OSS 本身就是一个服务化的一个存储产品，所以说它使用成本和维护成本是更低的，但是因为本身对象存储并不是针对大数据来设计开发的，所以说它的使用的性能会存在一个相较于 HDFS 会再做一些内部操作，做一些 list 源数据操作的时候，性能会比 HDFS 要低一些，但是它总体来说能实现很好的按量使用，比如说有10tb的存储，使用 HDFS 就需要支付10tb的存储空间的成本就可以了， Jindo FS 可以更好的去帮助用户使用 OSS ，它是基于 OSS 之上做了一系列的封装，能够实现更好的一个性能。经过一系列的测试， Jindo FS 的性能是比 HDFS 更优的，同时它有着一个更好的一个数据可靠性和更低的成本管理，它能很好的实现一个数据的分层存储，这里可以手动的指定，要根据数据的价值来选择数据的存储的介质，但它的一个问题就是说Jindo FS本身是采用了一种看似的模式，它把一系列的热数据放到了本地，所以说它需要付出一部分额外的到本地的存储成本，通过计算和存储的一个结构，可以看出就是可以采用 OSS 或者 HDFS 的方式来实现计算存储的结果，同时可以实现一个更灵活的经营架构，就是比如说所有的元数据都存储在一个 RDS 或者一个类似于 RDS 的存储介质里面的时候，那这个集群就可以实现更灵活的一个创建示释放和弹性伸缩的动作，而且也可以综合集群共享一个基地来实现元素统一的管理和治理。
就是比如说有一个 hodoop集群，但是这个集群点上面可能有多种计算引擎，可以实现元素数据共享，同时因为数据都保存在一个 HDFS 或者 OSS 里面，那因为数据也是可以去实现一个话题群共享的，那这些计算引擎就可以实现一个灵活的弹性的方式，有任务的时候就可以实现一个弹性伸缩，没有任务的时候可以实现缩容，把集群释放掉都是可以的。而数据持久保存在多个集群里面。
五、展望
最后来对这个产品做一个简单的展望，就是 EMR 是一个有声的产品，就是说因为这个产品会随着开源社区的一些技术的演进以及开源大数据的一个场景的拓展，不断的去丰富自己的场景和边界，同时也可以根据社区的版本来迭代演进设置版本，最近会在 11之后发布 Spark3.0的版本，这个版本相对来说是一个包含了很多特性，希望用户来体验这个最新 EMR 这个版本的产品。
同时也会根据基础设施的升级去不断地让利于用户，比如说可以看到就是说最近 ECS 实验室即将发布的md的实力，也会在今年完成对amd实力的一个适配，amd相对于英特芯片的实力都是X86架构的，但是它的成本会更低，它用在做 task 的节点时候是可以大幅有效的降低存储的计算成本，那同时随着大数据的容器化的一个发展方向的不断成熟，比如 spark的技术实力的不断成熟，那也会跟进这个技术方向去推进相应的集群类型，然后让更多的用户去探索新的大数据技术发展，给用户带来了一个产品功能上的体验和一个企业成本的节省。第三个方向会在基于阿里云的平台去对接更加灵活的购买方式，目前的 EMR 已经支持了按量付费、包年包月、抢占式实例三种，那在去年阿里云发布了一个预留实力产品，目前在购买20年 EMR 的时候也可以同样支持预留实力，所以随着阿里云不断更新的购买形态，也是可以随时更加灵活的去支持这种购买形态，从而实现用户红利，可以拿到部分硬件的红利和一部分云生态的红利。第四部分会在数据湖场景对于计算存储分离的场景，在使用的时候去做一系列大量的优化，然后更好的实现在云上按量付费、按量使用的方式，不再去做资源的预估，而是根据业务的发展方向更好的去实现根据所需的容量去付费。
