原视频连接：https://www.slidestalk.com/AliSpark/EMapReduce191196?video数据库
编辑：杨仲鲍，北京海致星图科技有限公司服务端开发工程师 ，大数据爱好者，Spark 中文社区志愿者服务器
首先介绍一下阿里云飞天大数据平台(简称飞天平台)，飞天平台由AI-PAI（机器学习和深度学习的平台）和大数据平台组成。 除 EMR 以外，还有像 MaxCompute，DataHub，实时计算，图计算等不一样的计算引擎微信
如上图所示，橙色部分为阿里云自研的计算引擎/平台，灰色部分为对接开源生态的一个计算引擎/平台。EMR为飞天平台内开源的重要组成部分。架构
今天主作三个部分的介绍
1.数据湖介绍app
2.EMR数据湖方案运维
3.客户实践案例机器学习
数据湖
数据湖在15年被提出，最近两三年变的异常火爆，在Gartner的魔力象限中数据湖属于很是有投资和探索价值的技术。分布式
那数据湖是什么呢？以前咱们使用数据仓库来管理结构化数据，在Hadoop兴起后，大量的非结构化、结构化数据被统一存储到HDFS上，但随着数据的积累可能会出现部分数据在采集时并无合适的应用场景，因此咱们可能会对其先进行存储，等到业务有须要了，咱们再去进一步的进行开发和挖掘。ide
在数据量不断增加的状况下，咱们能够用像OSS ，HDFS等对象存储来作统一式的存储。同时咱们可能会面不一样计算场景的选择，好比说Ad hoc查询，离线计算，实时计算，以及机器学习，深度学习的场景。 在不一样的计算场景下，还须要面临不一样引擎的选择，在不一样的场景下要统一监控、受权、审计、帐号体系一系列的工做。工具
第一部分是数据获取(图中最左边的框框)，主要用于采集关系型数据库。日志用户点击流到统一的存储里去，使用不一样的计算服务对数据进行加工和计算，同时把计算结果应用于AI分析平台进行机器学习或深度学习，最终将结果用于业务，使用搜索、源数据管理等能力使数据达到增值的效果。数据除计算和存储外，还须要一系列的管控和审计的手段。
大数据技术诞生已有10 多年了，最开始你们就在本身的IDC上搭建开源软件。随着业务的不断增加，数据快速的积累，业务波动很是快，可能一会儿就出现了爆发性的业务。
线下IDC采购周期很是长，很难以知足计算资源随着业务快速增加的需求，同时业务存在高峰低谷的，白天业务的计算任务可能比较少(大部分为Ad hoc查询)，到了晚上可能就要扩容出一些资源进行离线报表计算。这种状况在IDC模式就出现了算力匹配难的局面。
大概在五六年前，就已经有大量的企业开始迁移上云，在业务数据不断增加的时候，企业能够快速添加实例，经过云供应链的能力知足业务增加需求。若是在云上自建Hadoop集群或者EMR也会存在一些问题，由于本质上都是用hdfs，随着数据的增加存储成本会线性的增加。同时在云上使用本地盘时，其运维流程很是复杂的。
对于大规模集群(几百台几千台的集群)，坏盘是一个常规事件，如何去处理这种常规事件，也是一个很是有挑战的事情，所以逐渐演化成了围绕OSS为核心的这种数据湖架构。借助OSS的分层存储的能力，能够实现不一样的数据，有不一样的存储方式和消耗成本。同时咱们知道HDFS的NameNode在HA场景下的运维是一个很是复杂的事情，当集群规模突破100台以后，怎么去把NameNode搞得比较稳定就成为了很是有挑战的事情，可能要投入大量的精力人力去维护。维护HA架构多是一个长期来看都无法根治的难题，那么使用OSS就是另一种选择，经过使用云服务的存储架构来规避在HDFS架构上无解的问题。
用EMR去构建企业级数据湖服务
EMR的定位是利用阿里云的生态，100%开源，同时向企业提供稳定高可靠的开源大数据服务的产品。EMR在16年6月份上线，不断迭代到EMR4.4，基于EMR，用户能够选择使用数10 余款的 ECS实例，实现分钟级建立弹性伸缩的集群。
EMR支持阿里云的OSS，其自主研发的Jindo FS对OSS性能进行大幅度的提高；同时EMR也集成了阿里云生态，DataWorks，PAI均可以在EMR上进行无缝的衔接。同时对于存储类的产品(如日志服务、MaxCompute等）均可以使用 EMR 来做为计算引擎来计算里边存储的数据。EMR全部的组件都是Apache开源版本，随着社区的版本不断的升级迭代演进，EMR团队会对像Spark、Hadoop、Kafka等组件在应用性和性能上作一系列的优化和提高。
EMR采用半托管架构，在这种架构下，用户使用时能够得到与线下IDC使用很是相似的体验，用户能够实际登录到集群中的ECS服务节点上，去部署管理本身的ECS服务器，同时提供一系列的企业级特性，包括像APM的对主机做业服务层面的告警和诊断，也支持MIT，Kerberos, RAM，HAS做为鉴权平台，而且使用Ranger做为统一的权限管理平台。
下图展现了EMR 的整个开源大数据的生态，其中包含了一些软件以及硬件。
这里分了几个层面。
如JindoFS是在存储层(OSS)之上。JindoFS是EMR团队自研的一套组件，该组件主要用来对OSS数据的读取计算作加速。通过实际的对比测试，JindoFS的性能是要远优于线下的HDFS服务。
Delta Lake是 databricks开源的数据湖的技术计算引擎和平台。EMR团队围绕Delta Lake在Presto,Kudu和Hive的对接上作了一系列优化，同时在性能上也比开源版本有了显著提高。值得一说的还有EMR的Flink，EMR上采用Flink是Ververica的企业版本，其在性能、管理性、易维护性上有更好的表现。
EMR主要分4种节点类型(Master,Core,Task,Gateway)。
Master节点主要部署一些像NameNode，ResourceManager， Hbase的Hmaster等服务，这些服务能够实现集中统一的集群管理，在建立生产集群时打开HA选项，会自动建立一个高可用集群。
Core节点主要部署了Yarn的NodeManager和HDFS的 DataNode。 从这个角度来讲，它既能作计算，又能作存储。对于数据可靠性来讲，考虑到节点上存储的数据，该节点没法进行弹性伸缩和竞价实例。
Task节点仅仅部署了NodeManager，在数据湖场景下可进行弹性伸缩。当用户的数据所有在对象存储中统一存储时，用户就可使用TASK节点的弹性伸缩能力快速的响应业务变化，实现计算资源的弹性扩缩容。同时可采用ECS抢占式实例来下降成本。Task节点也支持GPU实例，在不少机器学习或者深度学习的场景下，场景计算周期是很是短(几天或者几周才计算一次)，但由于GPU实例价格昂贵，采用手动扩缩容的实例能够极大的下降去成本。
Gateway节点主要用于部署Spark,Hive,Flink等各类客户端组件，这样不一样的部门就可使用不一样的Client或者客户端的配置，实现彻底的隔离，同时避免用户频繁去登到集群上进行操做。
JindoFS
HDFS诞生已经有10余年的历史了，其社区配套功能相对来讲比较成熟和完善。可是咱们也看到它在使用上也存在的不足，如HA的架构过于复杂(若是要实现HA，须要部署JournalNode，ZKFC)，并且当集群规模很是大时，须要考虑HDFS的Federation。当经营规模大了以后，DataNode-Decomission的周期也会很是长，主机故障或者磁盘故障须要下线节点的时候，周期长达1~2天，甚至须要专门安排人员去管理DataNode-Decomission，重启一个NameNode可能都要花费半天的时间。
OSS优点是什么？OSS就是阿里云上服务化的对象存储，它的管理和运维成本很是的低，同时有多种不一样类型的数据分层存储形式(如标准型、低频型、归档型)。OSS经过这种方式有效的下降用户使用成本，不须要用户关注NameNode和Federation(由于是服务化的)，而且数据可靠性很是好(提供了11个9的数据可靠性)。因此能看到大量的客户在使用OSS来构建企业数据湖，OSS的典型特色就是开放性好，基本上全部云产品都会支持OSS做为背后的存储。
同时 OSS也存在问题，在最开始对象存储诞生时主要是用于配合业务系统在大数据场景下进行数据存储。由于OSS是为通用场景而设计，因此在面向大数据计算引擎(Spark，Flink)作适配的时候会面临性能问题。当进行rename操做的时，实际上执行的是move操做，并且是真的进行文件拷贝，不像Linux文件系统那样够很快的完成rename操做， list操做时也会请求全部的object，数量过多时速度极慢；一致性(最终一致性的周期)也会相对比较长一些。 当进行读写的时候，有可能会出现数据不一致的问题。
EMR自研的JindoFS立足于开源生态，基本上全部计算引擎均可以使用JindoFS来实现对OSS的读取计算和查询的操做。JindoFS一方面能发挥OSS的优点：海量数据(EB级别)存储，同时又能发挥灵活的特性：当你使用 OSS语义的时候，基本全部的计算引擎(如其余的计算类产品或者 BI报表工具)均可以很快获取数据，是一个通用的接口。
JindoFS在云上也被大规模使用，在处理HDFS 和OSS的数据的时候，可以规避文件去作rename、list等操做时的性能问题。
Jindo FS的架构以下图所示，主服务为Namespace Service，从服务为Storage Service。主服务能够部署在一个或者多个节点上，从服务会在每一个节点上都进行部署，Client服务则会在每台EMR机器上都进行部署。当进行数据读写时，会先经过从服务向主服务发出请求，获取文件的位置，若是本地不存在，则会从OSS上获取，同时会Cache到本地 。JindoFS实现了HA架构，其 HA也是在线的，本地经过RocksDB实现，远端经过OTS实现。因此说Jindo FS既兼顾性能，又实现了高可靠。JindoFS也能够经过Ranger进行权限管理和设计。使用JindoFS SDK能够很方便的把线下HDFS数据迁移到OSS进行归档或者使用。
JindoFS支持Block和Cache模式。Block模式下使用JindoFS，它的源数据会放在本地的RocksDB和远端的OTS上，再也不是使用OSS通用的源数据，当数据量比较大(几百T以上)，Block模式性能表现会更好，但通用性会相对差一些，用户只能经过JindoFS的源数据去获取文件的块的位置和和详细信息。同时JindoFS的Block模式也支持用户去指定哪些是热数据、冷数据、温数据，JindoFS能有效的下降运维复杂度。
Cache模式使用本地存储，语义也使用OSS自己的语义如oss://bucket/path。使用Cache模式的好处是通用性很是好，不光在EMR上能够用，在其余的计算引擎均可以使用 OSS的语义。它的不足之处在于性能，当你的数据量级很是大的时候，性能相对Block模式较差。
以上两种模式都应基于自身业务的判断,来进行需选择性使用。
弹性伸缩
EMR能够根据时间和集群的负载(Yarn的指标收集，用户能够手动指定)作弹性伸缩。同时在作弹性伸缩的时候，能够选择多种识别类型，避免由于有特定识别类型因库存缘由形成做业失败，也可使用抢占式实例来下降成本。
EMR的数据湖方案
以下图所示，这是一个离线计算架构，数据能够经过Kafka,日志服务、数据集成（DataWorks里面数据集成)或者闪电立方（阿里云离线迁移产品）等多种方式同步数据到对象存储中，在EMR直接读取和计算，在工做流调度上可使用DataWorks或者Airflow，最上方数据应用包括像数据报表、数据大屏、API等等。
该离线架构优点在于能支撑一个很大规模(EB级别)的数据存储，OSS可以无缝对接到EMR中的大数据计算引擎，同时保证优秀的性能。
结合 OSS的能力，咱们能够实现高性能读取。在管控层面的权限管理，可经过Ranger对全部开源组件实现统一的权限管理。
下图是使用EMR作Ad hoc的场景，该场景有实时计算的数据流入。实时计算经过JindoFS作加速以后，再经过像Presto，Impala等开源的计算引擎对接像 BI报表，数据大屏这种实时展现。 该场景咱们多见于像实时数仓业务。
EMR新功能和特性
客户案例
从IDC迁移上云的典型案例
客户数据规模为 PB级别。上云后发现真正的热数据大概占总数据的百分之十几，经过对象存储的分层存储，有效下降了成本。当集群规模较大时，Master压力会比较大，该用户的Master数量较多，EMR会根据集群规模和负载的判断，动态扩缩Master，同时也能够自定义Master数量来作计算和集群的部署。另外该客户使用了弹性伸缩的能力，有一个相对独立的Spark集群来服务AI、ETL，该Spark集群是一个弹性伸缩的集群。在大数据开发这一块，客户使用了DataWorks来进行大数据开发。
数据高计算性能，权限管理能力，增长企业效能
多计算的集群，集群数量较多，同时客户把集群权限管理，源数据管理统一抽象作了集中管理，像Hive Meta，JindoFS Meta为多个集群共享的源数据。日间集群数量和集群节点数较少，可是夜间业务高峰须要进行扩容来知足晚上业务高峰时的计算能力，在工做流调度这块使用了Airflow来作工做流调度。
有更多相关想法欢迎加入钉钉群继续讨论。
相关阅读推荐：
JindoFS - 分层存储
关于云原生分布式计算和存储引擎JindoFS，看这一篇就够了
E- MapReduce 入门训练营火热报名中，点击文末阅读原文抢入营名额！
报名连接：
https://developer.aliyun.com/learning/trainingcamp/emr/1
本文分享自微信公众号 - Apache Spark技术交流社区（E-MapReduce_Spark）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。