使用 E-MapReduce 构建云上数据湖

Posted 2021-04-19 Apache Spark技术交流社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了使用 E-MapReduce 构建云上数据湖相关的知识，希望对你有一定的参考价值。

原视频链接：https://www.slidestalk.com/AliSpark/EMapReduce191196?video

编辑：杨仲鲍，北京海致星图科技有限公司服务端开发工程师，大数据爱好者，Spark 中文社区志愿者

首先介绍一下阿里云飞天大数据平台(简称飞天平台)，飞天平台由AI-PAI（机器学习和深度学习的平台）和大数据平台组成。除 EMR 之外，还有像 MaxCompute，DataHub，实时计算，图计算等不同的计算引擎

如上图所示，橙色部分为阿里云自研的计算引擎/平台，灰色部分为对接开源生态的一个计算引擎/平台。EMR为飞天平台内开源的重要组成部分。

今天主做三个部分的介绍
1.数据湖介绍

2.EMR数据湖方案

3.客户实践案例

数据湖

数据湖在15年被提出，最近两三年变的异常火爆，在Gartner的魔力象限中数据湖属于非常有投资和探索价值的技术。

那数据湖是什么呢？之前我们使用数据仓库来管理结构化数据，在Hadoop兴起后，大量的非结构化、结构化数据被统一存储到HDFS上，但随着数据的积累可能会出现部分数据在采集时并没有合适的应用场景，所以我们可能会对其先进行存储，等到业务有需要了，我们再去进一步的进行开发和挖掘。

在数据量不断增长的情况下，我们可以用像OSS ，HDFS等对象存储来做统一式的存储。同时我们可能会面不同计算场景的选择，比如说Ad hoc查询，离线计算，实时计算，以及机器学习，深度学习的场景。在不同的计算场景下，还需要面临不同引擎的选择，在不同的场景下要统一监控、授权、审计、账号体系一系列的工作。

使用 E-MapReduce 构建云上数据湖

第一部分是数据获取(图中最左边的框框)，主要用于采集关系型数据库。日志用户点击流到统一的存储里去，使用不同的计算服务对数据进行加工和计算，同时把计算结果应用于AI分析平台进行机器学习或深度学习，最终将结果用于业务，使用搜索、源数据管理等能力使数据达到增值的效果。数据除计算和存储外，还需要一系列的管控和审计的手段。

使用 E-MapReduce 构建云上数据湖

大数据技术诞生已有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作为统一的权限管理平台。

使用 E-MapReduce 构建云上数据湖

下图展示了EMR 的整个开源大数据的生态，其中包含了一些软件以及硬件。
使用 E-MapReduce 构建云上数据湖

这里分了几个层面。

如JindoFS是在存储层(OSS)之上。是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或者客户端的配置，实现完全的隔离，同时避免用户频繁去登到集群上进行操作。
使用 E-MapReduce 构建云上数据湖

JindoFS

使用 E-MapReduce 构建云上数据湖

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，数量过多时速度极慢；一致性(最终一致性的周期)也会相对比较长一些。当进行读写的时候，有可能会出现数据不一致的问题。
使用 E-MapReduce 构建云上数据湖

EMR自研的JindoFS立足于开源生态，基本上所有计算引擎都可以使用JindoFS来实现对OSS的读取计算和查询的操作。JindoFS一方面能发挥OSS的优势：海量数据(EB级别)存储，同时又能发挥灵活的特性：当你使用 OSS语义的时候，基本所有的计算引擎(如其他的计算类产品或者 BI报表工具)都可以很快获取数据，是一个通用的接口。

JindoFS在云上也被大规模使用，在处理HDFS 和OSS的数据的时候，能够规避文件去做rename、list等操作时的性能问题。

使用 E-MapReduce 构建云上数据湖

Jindo FS的架构如下图所示，主服务为Namespace Service，从服务为Storage Service。主服务可以部署在一个或者多个节点上，从服务会在每个节点上都进行部署，Client服务则会在每台EMR机器上都进行部署。当进行数据读写时，会先通过从服务向主服务发出请求，获取文件的位置，如果本地不存在，则会从OSS上获取，同时会Cache到本地。JindoFS实现了HA架构，其 HA也是在线的，本地通过RocksDB实现，远端通过OTS实现。所以说Jindo FS既兼顾性能，又实现了高可靠。JindoFS也可以通过Ranger进行权限管理和设计。使用JindoFS SDK可以很方便的把线下HDFS数据迁移到OSS进行归档或者使用。

使用 E-MapReduce 构建云上数据湖

JindoFS支持Block和Cache模式。Block模式下使用JindoFS，它的源数据会放在本地的RocksDB和远端的OTS上，不再是使用OSS通用的源数据，当数据量比较大(几百T以上)，Block模式性能表现会更好，但通用性会相对差一些，用户只能通过JindoFS的源数据去获取文件的块的位置和和详细信息。同时JindoFS的Block模式也支持用户去指定哪些是热数据、冷数据、温数据，JindoFS能有效的降低运维复杂度。

使用 E-MapReduce 构建云上数据湖

Cache模式使用本地存储，语义也使用OSS本身的语义如oss://bucket/path。使用Cache模式的好处是通用性非常好，不光在EMR上可以用，在其他的计算引擎都可以使用 OSS的语义。它的不足之处在于性能，当你的数据量级非常大的时候，性能相对Block模式较差。

以上两种模式都应基于自身业务的判断,来进行需选择性使用。
使用 E-MapReduce 构建云上数据湖

弹性伸缩

EMR可以根据时间和集群的负载(Yarn的指标收集，用户可以手动指定)做弹性伸缩。同时在做弹性伸缩的时候，可以选择多种识别类型，避免因为有特定识别类型因库存原因造成作业失败，也可以使用抢占式实例来降低成本。

使用 E-MapReduce 构建云上数据湖

EMR的数据湖方案

如下图所示，这是一个离线计算架构，数据可以通过Kafka,日志服务、数据集成（DataWorks里面数据集成)或者闪电立方（阿里云离线迁移产品）等多种方式同步数据到对象存储中，在EMR直接读取和计算，在工作流调度上可以使用DataWorks或者Airflow，最上方数据应用包括像数据报表、数据大屏、API等等。

该离线架构优势在于能支撑一个很大规模(EB级别)的数据存储，OSS能够无缝对接到EMR中的大数据计算引擎，同时保证优秀的性能。

结合 OSS的能力，我们可以实现高性能读取。在管控层面的权限管理，可通过Ranger对所有开源组件实现统一的权限管理。
使用 E-MapReduce 构建云上数据湖

下图是使用EMR做Ad hoc的场景，该场景有实时计算的数据流入。实时计算通过JindoFS做加速之后，再通过像Presto，Impala等开源的计算引擎对接像 BI报表，数据大屏这种实时展示。该场景我们多见于像实时数仓业务。
使用 E-MapReduce 构建云上数据湖

EMR新功能和特性

使用 E-MapReduce 构建云上数据湖

客户案例

从IDC迁移上云的典型案例

客户数据规模为 PB级别。上云后发现真正的热数据大概占总数据的百分之十几，通过对象存储的分层存储，有效降低了成本。当集群规模较大时，Master压力会比较大，该用户的Master数量较多，EMR会根据集群规模和负载的判断，动态扩缩Master，同时也可以自定义Master数量来做计算和集群的部署。另外该客户使用了弹性伸缩的能力，有一个相对独立的Spark集群来服务AI、ETL，该Spark集群是一个弹性伸缩的集群。在大数据开发这一块，客户使用了DataWorks来进行大数据开发。使用 E-MapReduce 构建云上数据湖

数据高计算性能，权限管理能力，增加企业效能

多计算的集群，集群数量较多，同时客户把集群权限管理，源数据管理统一抽象做了集中管理，像Hive Meta，JindoFS Meta为多个集群共享的源数据。日间集群数量和集群节点数较少，但是夜间业务高峰需要进行扩容来满足晚上业务高峰时的计算能力，在工作流调度这块使用了Airflow来做工作流调度。

有更多相关想法欢迎加入钉钉群继续讨论。