开发者学堂课程【E-MapReduce入门：走进开源大数据平台 EMR】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/329/detail/3700
走进开源大数据平台 EMR
内容介绍：
一、 EMR 产品的介绍和特点
二、 EMR 的发展历程
三、 现状
四、 为什么选择 EMR
五、 展望
一、EMR 产品的介绍和特点
在当前大数据技术是非常热门的技术趋势，其中开源大数据技术在解决互联网公司传统的企业大数据问题，包括大数据分析、 BI 报表、实时的数据处理、人工智能等问题方面发挥了非常大的作用。
阿里云从2015年开始在云上构建大数据产品 EMR ，主要是将大数据的组件跟云相结合，来解决传统的 IDC 构建、自建大数据的系统向云上的牵引。
EMR 产品主要包含以下几个方面的特点:
1）整个系统的组建与开源大数据组件完全兼容，其中包括常用的大数据组件 HDS ，YARN ，Hive ，Spark 等等，能够暂时解决客户的各种大数据问题。
2） EMR 产品是基于阿里云非常先进的 ISC 基础底座 ECS 来构建，具备极度的弹性性能，能够根据用户业务的需求以及业务的成长和缩减来进行弹性升缩
3） EMR 支持计算存储分离的价格，计算存储两种资源能够分别截偶，这样可以极大地降低客户的这个成本。
4） EMR 整体的组件性能包括 Hive 、 Spark 在全球处于领先地位，在常见的 TPC 的标准 benchmark 中，EMR 的性能长期处于前列，在最新的 EMR 版本中也支持了阿里云的数据湖解决方案，数据湖能够做到打破数据孤岛、原数据共享、计算容器化等最佳的用户实践。
本次训练营包括理论和实践两个部分。
二、EMR 的发展历程
主要讲述产生 EMR的原因和 EMR 过去四年时间的变化
1、早期大数据平台
早期在阿里云使用大数据平台拥有三种选择：
(1) 采用阿帕奇log社区开源版本去构建一个大数据平台，不仅包含Hadoop，还包括 Hive 、HBase、Kudu、 Impala 组件。采用此版本去构建开源大数据平台，对个人的要求比较高，一方面要考虑到组件之间的兼容性，第二方面社区并没有提供一个比较清晰的控制台界面，所以很多命令以及运维工作都需要在黑屏的方式下去操作，比较大的限制了Hadoop 这个平台的利用性，以及使用的门槛。
(2) 采用基于 Hadoop 社区的很多发行版厂商提供的一些发行版软件，相对来说提供了比较完善的组件的兼容性测试，以及控台界面的功能，对用户来说是比较友好的。
(3) 使用阿里云自研的一款开源大数据平台 MaxCompute ，以前简称叫做 ODPS ， MaxCompute 是名称修改之后的称呼，它是一个完全基于自研的超大规模的大数据分析平台，用法跟 Hive 非常类似。
2、发展历程
这个产品最早的时候是在2015年6月份在云上发布上线的，当时不叫 EMR ，只是 Spark 的一个镜像，在早期的时候只可以通过使用这个镜像把这个镜像下载到 ECS 上，快速搭建一个 Hadoop 和 Spark 集群，使用 Spark on Yarn 方式来运行，Spark命令，在2015年的11月份产品正式立项，作为一个正式的独立产品对外发布，2016年6月开始公测，产品正式商业化，达到 SAR 的要求，然后开始对外提供服务。目前EMR作为阿里云上非常重要的一款云上开源大数据生态级的产品，已经经历了一个商业化的历程。
(1) 在最早期国外的厂商上有类似 EMR 的产品，但是发现这种产品的一个特点是云原生的面向于临时集群，一个任务其中一个集群用这种方式来做的一款产品，产品在最早期的时候拥有很多用，需求也比较简单，就仅仅是运行一个大数据的任务，通过这种临时集群能比较好的满足要求。任务运行完毕进行释放，对于比较简单的分析场景是完全能够满足的。
(2) 随着国内市场的发展和一些更多客户的交流发现，更多的是需要一种长储集群，不仅是因为任务数比较多还比较难准确的预估出资源消耗的一个情况，所以在IDC里面建立一个集群，然后跑着大量的任务，当迁移上云的时候，这个 Gap 是比较大的，从一个能全量的一个集群转到云上完成任务，通过任务来集群，然后再评估需要多少资源，在这种情况下发现用户在上云的时候要求一个比较强的运维能力和相应的集群管理能力，同时也希望一个更好的工作流调度的一个工具来帮助他更好地管理集群、运维集群，降低开源大数据的一个使用门槛，在这种情况下产品有了一系列的转化，增加了很多组件管理的功能，增强了工作流管理1.0的开发，最早是在2017、2018年上线的。经过一段时间产品的打磨之后发现它大大降低了用户的一个试用门槛，不仅运行一个任务，在这种情况下能够承载更多的大客户，从IDC搬占上云任务工作流比较复杂，面临着一个多样化的组件选择的时候产品有满足这种需求。
(3) 开源大数据的场景不断丰富，技术也不断的演进和向前迭代，在这种情况下对于集群的稳定性、安全性提出了更高的要求，所以在这个阶段把 Kubers 和 Runner 集成进来作为统一的集群权限管理和统一的健全管理的一个工具和组件。
基本上主要的组件都已经实现了高可用的架构，包括像 HDFS 的 NameNode、 ER 的 Softmanager、 HBase 、Hmaster 服务都可以做到 HAR 降低了用户自己去配置 HU 的复杂度和管理成本。同时不断的去拓展开源大数据的使用场景，在不断的迭代过程中加入了很多像 Kafka 、 Impala 的开源大数据组件，同时机器学习、深度学习技术成长非常迅速，机器学习和深度学习与大数据分析是一个上下游的关系，机器学习、深度学习的数据要依赖于大数据分析的这个ETL或者舒畅的一个产出。这种情况下把机器学习的集群加入到独立的集群类型来进行统一的管理。
(4) 随着产品的不断成熟到了第四个阶段，更好的去串联云上的大数据生态，这种情况下要求集群的组织更加的轻量级，智能化。在这个阶段寻找如何更好的去串联云上的各种生态，目前已经实现了 PAI - EMR 的产品结合。
在创建集群使用 ESC 集群类型，使用 tendsor 组件、A link no组件，都是完全从 PAI 这个产品里导入过来的，它使用的不仅是开源，而是对开源技术的增强，同时很多用户希望在开源大数据生态里使用 DataWorks 这一比较成熟的工作流调度，权限管理、数据治理、数据地图的一块工具来构建自己的数据状态，帮助自己快速的上手，在这种背景下也跟 DataWorks 做深度的集成，目前向数据学、数据治理、数据质量已经陆陆续续的上线，后面会把 DataWorks 的权限管理跟 EMR 进一步打通，实现了 DataWorks 、EMR 能够有一个更好的更完整的用户体验，目前另外一个趋势就是很多用户在使用开源大数据的时候，不仅是 Unisys ，还有一些对于 k8s 的需求，所以目前也上线了 k8s 集群类型，也是能够更好的帮助用户去管理集群，底层的资源。
三、现状
1、EMR 开源软件栈
这是云上的开源大数据生态的软件站，这套软件站分为四个部分：
(1)深蓝色的部分主要是开源大数据生态的组建，基本上没有太多的修改而且纯粹是基于社区开源的一个集成，在这种情况下使用开源是完全没有差别的.
(2)另外针对用户一些使用的场景会对开源组件进行一系列的修改和增强，这就是浅绿色的一个组件啊比如说像 Spark 这块做了一系列的性能增强而且是比开源的性能有大幅的提升，但是这种增强完全不影响对于开源的一种使用体验。也就是说使用 Spark 组件完全可以和开源一样而且优化也是采用插件的机制，可以通过参数的方式打开或者关闭，对于浅绿色部分来说就是基于开源对开源有一系列的性能增强。
(3)橙色部分是自研的组件比如说像 EMR Agent 是一套集群管理的组件，这套并不是开源大数据的组件但是属于对集群管理必备的一个组件，另外一方面比如说像 JinduFS 是从去年正式对外发布了一块数据湖构建的重要组件，今年性能有了大幅度的提升、功能有了快速的增强和完善目前有大量的用户是通过使用 JinduFS 快速构建云上的数据湖，实现了数据的分层存储，达到了社作业性能的提升。
(4)浅蓝色的部分是利用开源大数据生态跟阿里云现有的产品，产品保护下，刚才提到了 DataWorks 、PAI、OSS、ECS、SLS这些产品。
2、开源软件栈发展
开源软件栈从一六年这个产品诞生以来不断的去丰富和增强，这几年的发展基本上还是按照开源大数据的组件和场景上的应用的拓展，软件站也不断的丰富，比如在一七年加入了 Presto、Impala ，在一八年加入 Flink 属于科学集群，在一九年对 Hadoop 版本做了比较大的版本升级，不只是支持好多二点几的版本，同时也支持很多三点几的版本，目前 EMR 软件站有两个分支，一个是 EMR 3.x 的版本，对应的就是 Hadoop 2.x 的版本，另一个分支对应的 EMR 4.x 的开源组件对应的是 Hadoop 3.x 的版本。
Hadoop 3.x 的版本，同时支持Hadoop 3、Hive 3、HBS 2。 Hadoop 2.x 的版本，对应的就是 Hadoop 2.、2.8、2.5、 Hive 3.1.3，Hive 2.4.5以及HBase 1.4.9版本，同时根据不断的场景，数据仓库建设的场景，介绍一下 Presto、Impala ，用来做交互式分析和收藏数据查询，同时针对在一八年开始比较流行的Flink也加入到软件站来，用流失计算以及围绕大数据和AI的融合，上线了数据科学集群，里边就支持 TF on YARN 、Spark 这些计算框架，这些计算框架的引入能够帮助用户实现从大数据分析到机器学习一体化的架构。
云上数据湖的不断的发展也加入了 Delta Lake、Kudo 组件，能够帮助用户快速的去构建影像数据库的一个平台，能够支持对数据的更新、查询、快速的一个实时数仓的构建。
3、EMR 集群类型
Data Science集群， Alink 是基于Flink 的继续学习组件， Data Science集群最大的一个优势在于它是一个半托管的架构，它跟 EMR 其他的集群类型一样，都是一个半托管的架构，在这种情况下可以更加方便简单的去安装，继续学习，深度学习常用的一些包更加灵活透明，用户可以自定义的去部署自己的软件环境，更加容易把继续学习、深度学习和大数据串联在一起。
kafka 消息队列集群类型，目前采用两个版本，一个是 EMR 3.x的版本，主要用 kafka 1.x 的版本， EMR 4.x的版本，采用 kafka 2.x 的版本。除了提供 kafka 这个组件，做了一系列包括源数据管理的增强。
Data Flow 集群类型，采用 Flink on YARN 这种架构，Flink 用的不是开源 Flink ，而是用的 wrkperform 组件。如果需要一个比较轻量级的一个机器学习的流失计算的引擎，可以采用Data Flow 集群类型，它相对于开源来说有更好的性能以及更加完善的用户体验，继承了 Alink 组件，可以实现流失的继续学习的功能和能力，浅层的算法是完全足够的。
当集群规模非常大的时候可以考虑把主集本从主集群里面拿出来作为一个独立的分布式的一个能力，这种情况下你可以选择 Zookeeper 类型集群。
实时 OLAP 集群类型，独立的 Druid 集群，数据平台： Hadoop、JinduFS、OSS、 depstor存储，最新版本0.18，非常新的版本。
四、为什么选择 EMR
1、EMR 有四个比较重要的产品特性：
(1)第一个是开源，所有的组件都是基于开源组件来做的，而且会跟着开源社区的发展不断的去迭代演进，同时因为这个不仅是对开源软件的集成，而且会对一些组件的版本进行适配确保这个组件的兼容性，相对来说有着更好的稳定性。
(2)第二个因为基于开源社区做了一系列的性能优化，所以它的性能会比开源的版本有比较大的提升。
EMR 会基于开源大数据的生态在阿里云上针对阿里云的环境去做一系列的弹性能力，按量付费的能力，不需要去预估基金规模到底有多大，到底需要多少的数据存储，只需要根据按量使用，按需去统括弹性扩展，能够迅速满足对资源的需求，也就是比如这块的业务爆发的非常迅速，在这种情况下，可能会需要快速的去部署一些云商的资源，用 EMR 就能实现分钟级别的创建集群，分钟级别的去扩展集群，同时面临大数据计算是一个典型的有波峰波谷的特性。就像，可能在晚上12点以后会有一个比较大的任务，把日报这种任务提交上来，在这种情况下，这个任务需要比较高的 SLA 保障，在白天这个任务跑完之后，可能会面临资源的低谷，这种情况下，通过 EMR 弹性伸缩的能力，可以很好的去配合弹性资源的计算，从而达到一个成节省成本的效果。
(4)第四个主要是可以更好去对接云上的这个生态，相对于社区的组件，它更多的是一个通理上的考虑， EMR 产品会更好跟云上的一些产品的集成适配，云上更多的场景比如说像数据状态、数据、管理，在云上都有工具和一系列的这个产品， EMR 产品可以更加容易的去跟这些平台做集成和打通。
2、计算弹性资源
计算的弹性方面， EMR 的集群部署分为三种角色, Master 类型的集群、Core 类型的集群、Task 集群的类型。
(1) Master集群主要是部署 Master 服务，包括 HDS 的 Namenode、Resource manager 、HBase 的 HMaster 服务。
(2) Core 节点部署的除了存储还有计算的sleeve的服务，包括比如 HDFS 的DataNode 、ER 的Node Manager 。这些服务都部署在Core节点上。
(3) Task 节点仅仅用来部署计算服务，包括 YAD、nodemanager ，这种服务是部署在 Task 节点上。因为Care节点不属于像 DataNode 、HBase 、Resource 服务，所以在集群模型里面是不允许弹性伸缩的，而 Task 节点因为它是一个纯计算节点，所以弹性伸缩起来是相对比较方便，而且对任务的影响、对业务的影响都是比较小的，在这种目前的这种集群架构下 Task 节点是可以灵活的去做弹性的。
这个集群可以包年包月的去买，也可以用按量付费的方式去买，同时也可以在一个集群下面， Master 和 Core 采用的是包年包月的方式因为这种资源相对来说是固定的，同时用包年包月的方式去购买，也可以节省成本， Task 节点因为它是一个只需要做计算的一个节点，所以它可以用来做弹性伸缩，可以用按量付费的方式去购买，同时 Task 节点在用弹性伸缩的时候，也支持使用 spot ，就是抢占式实例去对资源进行成本的降低， spot 目前的成本仅仅是按量付费的一到两周，但是因为 spot 它的 SLA 是比较低的仅仅能保证每个小时是可以正常使用的，一个小时之后会重新竞价，由于库存或者竞价的原因无法进价的话，可能会对任务的运行产生一些影响，所以在任务运行选择范围的实力的时候，需要考虑到总体的政务的 SLA 的要求，弹性伸缩的方式支持包年包月，也是支持按时间弹性伸缩或者反复的进行弹性伸缩的两种方式，或者可以设置一个按时间伸缩的规则，比如在每天晚上12点开始做弹性伸缩的动作，然后这个任务比如能精确的预估出这个任务会在六点或者七点跑完，到了七点，再进行一个收容动作，确保这个任务能够实现一个成本的节省，也可以实现按负载伸缩，目前 YARN 的负载指标主要是采用了 YARN 的一些 mature 信息，包括 YARN 的一些比如 application running ，APPpending，Never usage，Cpuusage 这些指标来进行 YARN 的触发的一个trigger，这个指标达到一个需要设定的预警值或者弹性伸缩的门槛的时候，开始做一个弹性的动作，扩容或者缩容。
3、多样化存储解决方案
云上存储有多样化的解决方案，可以使用和线下 IDC 一样的 HDFS ，也可以使用Alibaba HDFS 服务或者使用 OSS (Standard) 类型，每种服务都有不同的特点和特显，重点介绍 HDFS 和 OSS.
当使用 HDFS 服务时，有两种选择一种是使用快存储 EBS ，另一种使用实例存储（本地盘实例/ I 系列/本地 SSD 实例） D1、D2 系列，本地盘实例特点为成本低，但是数据壳为应用层来保障，比如 HDFS 三副本策略来保证数据的应用。
数据量比较小的情况下建议使用云盘，数据小于10tb以下，因为本地盘购买是一块物理盘，存储空间比较大。所以数据小于10tb或者20tb时建议使用块存储 EBS、HDFS。这种情况的优势为比较灵活、随着数据量增长不断的更加灵活扩单排容量，问题为成本相对来说较高。因为它的数据可靠性是通过产品上的冗余或者数据化来实现的，所以它在性能上比本地盘的实力会相对来说更低一些，但是它的可靠性会更高一些。
总体来说，运维成本也会更低，因为它的数据可靠性是由 EBS 产品来保障的，当选择本地盘实例，也就是 D 系列或者 I 系列它的数据因为应用层是来保障数据可靠性，所以运维成本会相对来说更高，但是因为它本地是一块物理盘，所以它的购买成本是更低的，需要根据具体业务上的考量来选择合适的存储方式，来构建 HDFS 。 D 系列、I 系列使用 HDFS 的数据是三副本，因为应用层来保障数据可靠性，当采用 EBS 块存储的时候， EMR 副本数会默认设置为R，因为本身 EBS 就有数据可靠性的保障。
当选择使用 OSS 的时候，优势是 OSS 的本身就是服务化的存储产品，所以使用成本和维护成本是更低的。但是，因为本身对象存储并不是针对大数据来设计开发，所以使用的性能会存在一个相较于 HDFS 在做 relief 操作、做 list 源数据操作的时候，性能会比HDFS要低一些。但是，总体来说能实现很好的按量使用，比如 10tb的存储使用 OSS 需要支付 10tb 存储空间的成本就可以。 JinduFS 可以更好的去帮助用户使用 OSS ，它是基于 OSS 之上做的一系列的分装，能够实现更好的性能，经过一系列的测试 JinduFS 的性能比 HDFS 性能更优，同时，有更好的数据可靠性和更低的成本管理，能很好地实现数据的分层存储，可以手动的指定通过调用 HDFS 、 JinduFS 的接口实现数据分层存储形式为标准型、低频型、归档型，根据数据的价值选择数据的存储的介质。但问题为 JinduFS 本身是采用了 cache 的模式， 把一系列的热数据 cache 到本地，所以成本需要付出一部分额外的本地 cache 的存储。
4、灵活的集群架构
通过计算和存储的结构可以采用 OSS 或者 JinduFS 的方式来实现计算和存储的金额，可以实现更灵活的经营架构，比如所有的原数据都存储在 RDS 或者类似于 RDS 的政府工程建设的时候，集群可以实现更灵活的创建、释放、弹性伸缩的动作，也可以综合集群共享一个GB 来实现源数据统一的管理和治理。顶上的集群比如有个 hadoop 集群啊，但是点到的 hadoop 集群上面可能有多种计算引擎，像 spark 引擎、Presto 引擎、Hive 引擎、Flink引擎，都去访问同一个 Matstore 的时候就可以实现源数据共享。
同时因为数据都保存在一个 HDFS 或者 OSS 里，因为数据也可以实现跨集群共享的，计算引擎可以实现灵活的弹性的方式。有任务的时候可以实现弹性伸缩，没有任务时可以实现缩容把集群释放掉都是可以的，数据持久性的保存在 hadoop 集群里。
五、展望
第一， EMR 是一个有深入的产品，因为它的产品会随着开源社区的技术演进以及开源大数据的场景拓展不断的去丰富自己的场景和边界，同时也可以根据社区的版本来迭代连接测试版本。之后发布 Spark 3.0 版本，相对来说是包含了很多 Spark 3 的特性，希望用户体验最新的 EMR 版本的产品。
同时产品也会根据阿里云做基础设施的升级，去不断的让客户利用。比如最近 ECS 即将发布的 AMD 的实力也会在今年完成对 AMD 实力的适配。AMD相对于英特尔的芯片的实力, 都是 X86 架构的,但是它的成本会更低，用在做 Task 节点、Master 节点的时候可以大幅有效的降低存储的计算成本，随着大数据容器化发展方向的不断成熟，比如 Spark 、on keep as技术实例的不断成熟，也会跟进技术方向去推进相应的集训类型，让更多的用户去探索新的大数据、技术发展，给用户带来产品上、功能上的体验和成本的节省。
第三个方向会在基于阿里云平台去对接更加灵活的购买方式，目前 EMR 已经支持按量付费、包年包月、抢占式实例三种，去年阿里云发布了预留实例，在购买 EMR 的时候也可以预留实例，随着阿里云不断的推出新的购买形态也是可以随时更加灵活的去支持这种购买形态，实现用户红利，可以拿到这部分硬件的红利和一部分云生态的红利。
第四部分会在数据湖场景，对于计算存储分离的场景在使用的时候去做一系列大量的优化，能够更好地实现在云上按量付费，按量使用的方式，不用再去做资源的预估，而是根据业务的发展方向，更好的去实现根据所需的容量去付费的方法方向。
