数禾云上数据湖最佳实践
简介： 数禾科技从成立伊始就组建了大数据团队并搭建了大数据平台。并在ECS上搭建了自己的Cloudera Hadoop集群。但随着公司互联网金融业务的快速扩张发展，大数据团队承担的责任也越来越重，实时数仓需求，日志分析需求，即席查询需求，数据分析需求等，每个业务提出的需求都极大的考验这个Cloudera Hadoop集群的能力。为了减轻Cloudera集群的压力，我们结合自身业务情况，在阿里云上落地一个适合数禾当前现实状况的数据湖。
1.数禾科技
数禾科技成立于2015年8月，是分众传媒、红杉资本、新浪等联合投资的C轮金融科技公司。公司的愿景是做陪伴用户一生的智能金融家，秉承开放，挑战，专业，创新的价值观，让人人享有金融服务最优解。 公司的主要产品是还呗和拿铁智投，主要提供信贷，理财，电商等服务，已经拥有8000万注册用户。作为国内金融科技代表性企业，数禾科技率先将大数据和AI技术引入智能获客、智能风控、智能运营、智能客服等多个方面。截至目前，数禾科技已与包括银行、信贷、持牌消金、基金和保险等在内的100余家金融机构展开合作。
2.云上自建CDH
数禾科技从成立伊始就组建了大数据团队并在某云厂商上搭建了大数据平台。我们在某云厂商上购买了EC2实例，并在EC2实例上搭建了自己的Cloudera Hadoop集群。
早期，这个Cloudera Hadoop集群只是来做T+1离线数仓，半夜等到业务日切结束后，我们用Sqoop组件抽取业务数据库的全量或增量数据到Hadoop集群，用离线数仓Hive做一系列ETL清洗后，把结果数据生成邮件发送给领导做下一步决策，或推送到数据库供Tableau报表展示，或插入到业务数据库让业务系统来调用。
但是随着公司互联网金融业务的快速扩张发展，大数据团队承担的责任也越来越重，实时数仓需求，日志分析需求，即席查询需求，数据分析需求等，每个业务提出的需求都极大的考验这个Cloudera Hadoop集群的能力。为了满足实时数仓需求，我们在Cloudera集群上安装了Hbase组件；为了满足日志分析的需求，我们在Cloudera集群上安装了Flume、Kafka组件；为了满足即席查询的需求，我们在Cloudera集群上安装了Presto组件；为了满足数据分析的需求，我们在Cloudera集群上安装了Jupyter组件，每添加一个业务需求就是对原有系统稳定性的巨大挑战。
Cloudera集群
除了业务需求的不断增多，公司的组织架构越来越复杂，人员越来越多，各类数据总量的指数级上升，Cloudera集群的各种弊端已经显现，且逐渐不能承受这些挑战。
- 扩展性差
集群规模扩容需要在Cloudera Manager上操作，需要运维人员掌握一定的技能，且存在一定操作风险。另外，如果有突发情况或临时需求需要大规模扩容时，需要先购买大量的EC2机器然后经过一系列复杂操作加入集群，事后又需要一系列复杂操作释放这些机器，且这些线上操作对集群的在线业务稳定造成很大困扰。
- 费用很高
存储费用方面，刚开始我们没有预料到日后数据量的飞速发展，我们在Cloudera集群的HDFS存储使用了三个副本，且EC2机器配置了SSD磁盘，再加上每周的数据备份也占用了大量磁盘资源，磁盘费用一直居高不下；计算费用方面，晚上任务多计算资源不够，白天任务少计算资源多余，这种资源需求差带来费用的浪费。
- 集群更新困难
我们使用的是Cloudera5.5.1的版本，几年下来为了集群的稳定运行一直不敢更新，而搭建新版本Cloudera集群做集群迁移又涉及到大量的人力物力，所以这个老版本一直在服役。因为集群兼容阻碍了我们使用新的开源组件，或者需要花很大的精力去做开源组件的重构，阻碍了新技术的引进。
- 维护门槛高
搭建一套Cloudera集群并进行后续维护对运维人员的技术要求较高，而解决实际问题需要更高的技术要求。另外Cloudera Manager不开源和Cloudera社区不够活跃也对集群运维造成一定的困扰。
- 集群容灾差
数据容灾，HDFS存储三副本无法跨可用区。服务容灾，服务节点无法跨可用区部署。可用区故障会影响整个集群的稳定。
3.云上混合架构
为了减轻Cloudera集群的压力，我们想到把一部分业务迁移到云厂商上产品，逐渐形成了云上混合架构。
- 根据业务和功能不同，搭建了若干云上EMR集群
这些云上EMR集群共享存储和元数据。但是由于EMR Hive版本和Cloudera Hive版本不兼容，导致元数据无法统一，最终形成了Cloudera Hive和EMR Hive两套元数据。这些EMR集群减轻了Cloudera集群的压力
- 为了减轻Cloudera的压力我们设计EMR Hive混合架构Chive
Chive架构就是把EMR Hive的元数据接入Cloudera Hive，相当于使用Cloudera HDFS的存储，但是用了EMR的计算资源。Hive混合架构也大大减轻了Cloudera集群的压力
- 冷热数据分离
Cloudera集群上的热数据保存在HDFS上，而冷数据通过Cloudera Hive建外表的方式放到S3桶上，在S3上设置生命周期定期把数据放入冷存储。
云上混合架构
有了云上混合架构实践，实际已经有一个大数据数据湖的雏形，我们想趁着某云厂商迁移到阿里云之际，在阿里云上落地一个适合数禾当前现实状况的数据湖。
4. 阿里云第一代数据湖
4.1 什么是数据湖
数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。你可以按原样存储数据，而无需先对数据进行结构化处理，然后运用不同类型的引擎进行分析，包括大数据处理、可视化、实时分析、机器学习等，以指导做出更好的决策。
数据湖与数据仓库相比
| 特性 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据 | 来自事务系统、运营数据库和业务线应用程序的关系数据 | 来自 IoT 设备、网站、移动应用程序、社交媒体和 企业应用程序的非关系和关系数据 |
| Schema | 设计在数据仓库实施之前（写入型 Schema） | 写入在分析时（读取型 Schema） |
| 性价比 | 更快查询结果会带来较高存储成本 | 更快查询结果只需较低存储成本 |
| 数据质量 | 可作为重要事实依据的高度监管数据 | 任何可以或无法进行监管的数据（例如原始数据） |
| 用户 | 业务分析师 | 数据科学家、数据开发人员和业务分析师（使用监 管数据） |
| 分析 | 批处理报告、BI 和可视化 | 机器学习、预测分析、数据发现和分析 |
数据湖解决方案的基本要素
- 数据移动
数据湖允许您导入任何数量的实时获得的数据。您可以从多个来源收集数据，并以其原始形式将其移入到数据湖中。此过程允许您扩展到任何规模的数据，同时节省定义数据结构、Schema 和转换的时间。
- 安全地存储和编目数据
数据湖允许您存储关系数据和非关系数据。它们还使您能够通过对数据进行爬网、编目和建立索引来了解湖中的数据。最后，必须保护数据以确保您的数据资产受到保护。
- 分析
数据湖允许组织中的各种角色（如数据科学家、数据开发人员和业务分析师）通过各自选择的分析工具和框架来访问数据。这包括 Apache Hadoop、Presto 和 Apache Spark 等开源框架，以及数据仓库和商业智能供应商提供的商业产品。数据湖允许您运行分析，而无需将数据移至单独的分析系统。
- 机器学习
数据湖将允许组织生成不同类型的见解，包括报告历史数据以及进行机器学习（构建模型以预测可能的结果），并建议一系列规定的行动以实现最佳结果。
我们根据数据湖的定义和基本要素，在阿里云上落地适合数禾当前现实状况的第一代数据湖方案。
4.2 阿里云数据湖设计
4.2.1 阿里云数据湖整体架构
阿里云数据湖整体架构
专有网络VPC（Virtual Private Cloud）是用户基于阿里云创建的自定义私有网络, 不同的专有网络之间二层逻辑隔离，用户可以在自己创建的专有网络内创建和管理云产品实例，比如ECS、负载均衡、RDS等。
我们把公司的业务放到两个VPC下，业务VPC和大数据VPC。抽数EMR从业务VPC的RDS、OSS、KAFKA中抽取数据落到数据湖OSS中形成ODS层的数据，核心数仓EMR T+1对ODS层数据做ETL生成CDM数仓层和ADS集市层的数据供其他大数据EMR和业务EMR使用。
下面分章节介绍我们在阿里云数据湖落地中的解决方案和实践。
4.2.2 统一存储和元数据管理
统一存储是指把存储设置在OSS对象存储上作为数据湖，若干EMR集群统一使用这个数据湖。阿里云对象存储OSS（Object Storage Service）是阿里云提供的海量、安全、低成本、高持久的云存储服务。其数据设计持久性不低于12个9。OSS具有与平台无关的RESTful API接口，可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。也可以使用阿里云提供API、SDK接口或者OSS迁移工具轻松地将海量数据移入或移出阿里云OSS。数据存储到阿里云OSS以后，可以选择标准存储（Standard）作为主要存储方式，也可以选择成本更低、存储期限更长的低频访问存储（Infrequent Access）、归档存储（Archive）、冷归档存储（Cold Archive）作为不经常访问数据的存储方式。基于OSS的这些特性很适合做数据湖的存储。
统一元数据是指，使用数据湖的若干EMR中的组件统一使用一套元数据，比如Hive，Ranger，Hue等。我们把这些EMR元数据统一放在外置的RDS实例上，阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储，我们可以快速搭建稳定可靠的数据库服务，相比自建数据库有便宜易用，具有灵活计费、按需变配、即开即用、高性能、高可用架构、多种容灾方案、高安全性等特点。也很适合做统一元数据存储。
4.2.3 多EMR多OSS桶设计
利用统一OSS存储和统一元数据的架构，我们设计了多EMR多OSS桶的框架
数据湖上多EMR多OSS桶设计
抽数EMR T+1抽取业务RDS到数据湖，核心数仓EMR在分层数仓中进行一系列ETL操作生成CDM公共维度层数据，业务EMR基于CDM公共维度层数据进行ETL操作生成ADS集市层数据，EMR presto对CDM和ADS的数据进行即席查询。
一个业务EMR主要提供即席查询服务和DAG调度任务服务，用户只能把自己的即席查询和调度任务提交到他所在部门的EMR，且我们可以设置YARN队列资源把两种任务所占资源进行隔离。
业务EMR提供服务
4.2.4 分布式调度系统设计
Airflow是一个可编程，调度和监控的工作流平台，基于有向无环图DAG Airflow可以定义一组有依赖的任务，并按照依赖依次执行。Airflow提供了丰富的命令行工具用于系统管控，而其Web管理界面同样也可以方便的管控调度任务，并且对任务运行状态进行实时监控，方便了系统的运维和管理。
Airflow 系统在运行时有许多守护进程，它们提供了 Airflow 的全部功能。守护进程包括 Web服务器-WebServer、调度程序-Scheduler、执行单元-Worker、消息队列监控工具-Flower等。这些守护进程彼此之间是独立的，他们并不相互依赖，也不相互感知，每个守护进程在运行时只处理分配到自己身上的任务。基于Airflow的这种特性我们搭建了基于数据湖的Airflow集群高可用的分布式调度体系。
数据湖上Airflow分布式调度体系
为了在EMR上便捷执行任务，我们把Airflow Worker部署在EMR的Gateway上，因为Gateway上有所有EMR当前部署组件的客户端命令和配置。
我们也可以通过增加单个Worker节点的守护进程数来垂直扩展Worker能力提高集群任务并发度，也可以添加更多 Gateway（一个Gateway部署一个Worker）来水平扩展Worker能力提高集群任务并发度。现实中我们为了提高任务并发度且减低单个Gateway的压力，为高并发提交作业的核心数仓集群和抽数集群配置了两个Gateway和Airflow Worker。
后续我们还准备为Airflow Master部署两个节点，解决Master节点单点故障的问题。
4.2.5 用户权限系统设计
用户权限系统一直是架构设计的核心。我们设计了基于数据湖上三层用户权限体系，第一层RAM访问控制，第二层EMR执行引擎访问权限，第三层大数据交互式分析访问权限。
数据湖上三层用户权限体系
第一层访问控制（RAM）是阿里云提供的管理用户身份与资源访问权限的服务。RAM允许在一个阿里云账号下创建并管理多个身份，并允许给单个身份或一组身份分配不同的权限，从而实现不同用户拥有不同资源访问权限的目的。我们给每个EMR绑定了一个ECS应用角色，而每个ECS应用角色只能访问数据湖里相应的OSS桶。
第二层EMR执行引擎访问权限，包括HiveServer2，Presto，Spark等执行引擎。
首先我们需要了解，认证(Authentication)是指验证用户所用的身份是否是对的，授权(Authorization)是指验证用户所用身份操作是否有权限。
HiveServer2支持多种用户认证方式：NONE、NOSASL、KERBEROS、LDAP、PAM、CUSTOM等。而权限认证可以使用HIVE自带的权限体系、RANGER、SENTRY等开源组件。
使用Presto的Hive Connector，Presto和Hive可以共用同套用户权限体系。而经过阿里云EMR大数据团队的支持，Spark客户端也可以支持这套用户权限体系。
最终我们使用EMR Openldap保存用户和用户组信息，EMR Ranger提供集中式的权限管理框架。而EMR Openldap的用户和组信息会和公司的AD进行同步，AD中新进员工或者离职员工信息都会T+1方式同步到EMR Openldap。
OpenLdap和Ranger用户权限管理体系
第三层大数据交互式分析访问权限。我们自建了一套类HUE的统一用数大数据交互式分析查询系统，通过限制交互式分析查询系统的EMR访问入口，用户只能访问本部门的EMR。
通过这三层用户权限系统，可基本覆盖全场景用户取数需求。
4.2.6 EMR弹性伸缩设计
EMR的弹性伸缩功能可以根据业务需求和策略设置伸缩策略。弹性伸缩开启并配置完成后，当业务需求增长时EMR会自动为您增加Task节点以保证计算能力，当业务需求下降时EMR会自动减少Task节点以节约成本。
在我们的数据湖上跑了大量的EMR集群，正是由于EMR弹性伸缩的特性，我们能在满足业务需求情况下节省成本和提高执行效率，这也是大数据上云相比传统IDC自建大数据集群最重要的优势之一。
我们设置了若干弹性伸缩规则如下，主要遵循弹性扩容要比弹性缩容的阈值门槛低的原则。
4.2.7 负载均衡管理
EMR集群是无状态，可随时新建和销毁。但是不能因为EMR集群的新建和销毁影响对外提供的服务接口稳定，于是我们设计了数据湖上EMR集群的统一服务接口层。
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。我们采用HAProxy的四层网络层负载均衡，也就是TCP和UDP的负载均衡来提供统一服务。
在实现上，我们主要用HAProxy代理各个EMR的HiveServer2接口，ResouceManger接口，HiveMetaStore接口，Presto Http接口等，且让HAProxy支持 Include 加载多个模块配置文件的方式便于维护和重启。
4.2.8 OSS桶生命周期管理
数仓ODS层的数据和其他数仓层的数据相比具有不可再生的特性（业务RDS库的数据会定期做删除，数仓承担了数据备份的功能），我们把ODS层的数据放在多版本桶上，能够同样实现Cloudera Hadoop定期打Snapshot快照做定期数据备份，所以我们需要设置ODS桶数据的生命周期一来保障ODS层数据的安全，二来保持数据量的稳定增长。
ODS多版本桶的生命周期设置
Hadoop HDFS文件系统会有一个垃圾箱回收机制，便于将删除的数据回收到垃圾桶里面去，避免某些误操作删除一些重要文件。回收到垃圾桶里里面的资料数据，都可以进行恢复。HDFS为每一个用户创建一个回收站，目录为/user/用户名/.Trash/被用户删除的文件或目录，在系统回收站中都有一个周期(fs.trash.interval)，周期过后HDFS会自动将这些数据彻底删除。而如果是数据湖架构，回收站目录将被设置在OSS桶上，HDFS不会对这些垃圾文件定期删除，于是我们需要设置OSS文件生命周期（删除3天前的数据）来定期删除这些垃圾文件。
垃圾箱的生命周期设置
4.2.9 日志管理
日志服务（Log Service，简称 SLS）是针对日志类数据一站式服务，用户无需开发就能快捷完成数据采集、消费、投递以及查询分析等功能，帮助提升运维、运营效率，建立 DT 时代海量日志处理能力。
鉴于EMR组件日志的周期性删除，我们必须把EMR上组件的历史日志统一收集在一个地方以便于后续的排查问题，SLS正适合数据湖上多EMR日志收集这一场景。我们根据EMR组件常用日志收集了
4.2.10 终端权限管理
开发人员需要有特定EMR实例的登录权限，以便于开发操作。
终端权限管理
终端登录方式如上，通过公司堡垒机，登录大数据VPC下一台特定linux跳板机，从而去登录EMR的实例，不同角色的操作人员有特定的登录权限。其中大数据运维可以用统一密钥对以root账号登录EMR HADOOP集群任意一个实例，然后切换到hadoop账号后，登录EMR集群中任意一个实例。
4.2.11 组件UI管理
如上所示knox的地址不太容易记忆，我们采用了云解析DNS的产品。
云解析DNS（Alibaba Cloud DNS）是一种安全、快速、稳定、可扩展的权威DNS服务，云解析DNS为企业和开发者将易于管理识别的域名转换为计算机用于互连通信的数字IP地址，从而将用户的访问路由到相应的网站或应用服务器。
我们使用别名记录，将容易记忆的域名指向knox域名很好的解决了这个问题。
4.2.12 监控告警管理
EMR-APM大盘提供EMR集群用户，特别是集群运维人员使用的包含监控集群、监控服务、监控作业整体运行状况、排查和解决集群作业问题的一套完整工具的产品。
常用有YARN-HOME图表，可以看到历史弹性伸缩实例的情况
EMR APM大盘中YARN-HOME图表
YARN-QUEUE图表，可以看到历史每个队列的资源使用情况和任务执行情况
EMR APM大盘中YARN-QUEUE图表
EMR APM大盘中YARN-QUEUE图表
云监控（CloudMonitor）是一项针对阿里云资源和互联网应用进行监控的服务。云监控服务可用于收集阿里云资源或用户自定义的监控指标，探测服务可用性，以及针对指标设置警报。使您全面了解阿里云上的资源使用情况、业务的运行状况和健康度，并及时收到异常报警做出响应，保证应用程序顺畅运行。
我们采用让数据湖上的多个EMR核心组件告警信息接入云监控，让云监控统一电话，钉钉，邮件告警给相关责任人。
4.2.13 即席查询设计
即席查询能力是数据湖对外输出能力的考验。我们自研了统一用数大数据交互式查询系统，支持HiveServer2和Presto两种执行引擎。通过限制统一用数的查询入口，用户只能提交即席查询作业在自己部门所在的EMR上。 而Presto所占用的计算资源会和Hadoop所占用的YARN计算资源相互影响，我们独立搭建了一套EMR Presto集群，单独为统一用数提供Presto即席查询服务。
数据湖上即席查询设计
统一用数在满足用户即席查询基本需求的基础上，我们还做了很多个性化的需求。
- 公司工单审批系统接入
- 组件服务状态监测提醒
- HiveSQL语法和PrestoSQL语法互转
- 元数据展示，包括样本数据展示，血缘关系展示，调度信息展示，统计信息等
4.2.14 集群安全组设计
ECS实例的安全组是一种虚拟防火墙，具备状态检测和数据包过滤能力，用于在云端划分安全域。安全组是一个逻辑上的分组，由同一地域内具有相同安全保护需求并相互信任的实例组成。
在数据湖上的所有EMR必须绑定特定的安全组来为外界提供服务。我们为大数据集群不同实例组分配了不同的安全组。
4.2.15 数据脱敏设计
敏感数据主要包括客户资料、技术资料、个人信息等高价值数据，这些数据以不同形式存在于大数据数仓中，敏感数据的泄露会给企业带来严重的经济和品牌损失。
EMR Ranger支持对Hive数据的脱敏处理（Data Masking），对Select的返回结果进行脱敏处理，对用户屏蔽敏感信息。但是EMR Ranger该功能只针对HiveServer2的场景，不适用于Presto的场景。
数据湖的敏感字段扫描按照预设的敏感字段规则进行扫描，分小时级别的增量扫描和天级别的全量扫描。扫描结果通过Ranger Mask Restful API写入Ranger的元数据库，当用户的即席查询通过HiveServer2并命中敏感字段时，该敏感字段只有预设的前面几个字符是正常显示，后面字符全部用x来脱敏处理。
ranger脱敏效果
4.2.16 YARN队列设计
一个业务EMR主要提供即席查询服务和DAG调度任务服务，用户只能把自己的即席查询和调度任务提交到他所在部门的EMR，且我们可以设置YARN队列资源把两种任务所占资源进行隔离。
4.3 数据湖EMR治理
EMR治理在数据湖治理中具有举足轻重的作用，EMR治理包括稳定性治理，安全性治理，执行效率治理和成本治理等。
4.3.1 调整EMR预伸缩时间
数仓半夜的T+1任务有时效性要求，我们需要在0点数仓作业开始执行时提前准备好充足的计算资源。由于EMR当前弹性伸缩架构限制，优雅下线会导致缩容和扩容不能并行。
- 在不影响0点数仓作业的情况下，尽可能推迟预扩容时间
定时调度执行EMR OpenAPI，临时缩短优雅下线参数可以时预扩容时间从22：00延迟到23：30。 - 查看任务运行监控，尽可能提前恢复弹性伸缩时间
查看EMR APM大盘监控，观察任务执行时间，提前调整弹性伸缩下限恢复弹性伸缩从10：00提前到6：00。
优化前后，22：00-10：00平均在线节点从52台缩减到44台。
4.3.2 更改EMR弹性伸缩策略
弹性伸缩功能可以根据业务需求和策略设置伸缩策略。弹性伸缩开启并配置完成后，当业务需求增长时EMR会自动增加Task节点以保证计算能力，当业务需求下降时EMR会自动减少Task节点以节约成本。Task节点的付费方式有包年包月，按量实例和竞价实例。在全弹性伸缩情况下我们应该尽可能使用竞价实例，可以参考阿里云《EMR弹性低成本离线大数据分析最佳实践》
- 竞价实例优先，按量实例兜底
此方案兼顾了集群计算能力，成本和弹性伸缩的稳定性，尽可能多用竞价实例，只有在可用区ECS库存匮乏的情况下才使用按量实例。
弹性伸缩配置
- 可用区迁移
不同的可用区库存不一样，我们应该尽可能把EMR集群部署或迁移到库存充裕的可用区，这样才能尽可能使用竞价实例降低成本 - 弹性策略调整
夜间和白天的任务性质不一样，比如夜间以调度任务为主，使用的是dw队列，而白天以即席查询为主，使用的是default队列。我们可以用调度定时刷新队列资源，有效的利用队列资源从而避免队列资源浪费。
经过上述一系列优化后，EMR集群费用减少1/5
4.3.3 优化EMR云盘空间
EMR的弹性实例可以使用云盘，云盘包括高效云盘，SSD和ESSD
- ESSD云盘：基于新一代分布式块存储架构的超高性能云盘产品，结合25GE网络和RDMA技术，单盘可提供高达100万的随机读写能力和更低的单路时延能力。建议在大型OLTP数据库、NoSQL数据库和ELK分布式日志等场景中使用。
- SSD云盘：具备稳定的高随机读写性能、高可靠性的高性能云盘产品。建议在I/O密集型应用、中小型关系数据库和NoSQL数据库等场景中使用。
- 高效云盘：具备高性价比、中等随机读写性能、高可靠性的云盘产品。建议在开发与测试业务和系统盘等场景中使用。
当前处于性价比考虑我们选择了ESSD云盘。并根据查看弹性节点每日云盘监控，合理确定弹性伸缩实例数据盘数量和容量。
4.3.4 EMR机器组的选择
在一个业务EMR上，主要提供即席查询服务和DAG调度任务服务。弹性伸缩比较适合DAG调度任务的场景，而不适合即席查询的场景，因为即席查询具有查询时间短频次高的特点。基于以上因素考虑，我们往往会预留固定数量的TASK实例，而这些实例使用先付费比较合适。
于是我们设置了两个TASK机器组，先付费TASK机器组和后付费TASK机器组，先付费TASK机器组主要满足即席查询的需求，而后付费弹性TASK机器组满足DAG调度任务的需求
4.3.5 EMR成本控制
在我们公司的产品消费分布中，ECS云服务器占总费用的很大比例，而EMR弹性实例又占ECS云服务器中大多数，所以我们需要关注EMR的费用账单来有效的控制成本。
我们可以使用详单订阅服务，调用SubscribeBillToOSS导出阿里云OSS订阅账单详单数据到大数据Hive表，经过一系列ETL计算出每日每个EMR的费用报表。EMR的费用主要包括包年包月实例费用，按量实例费用，竞价实例费用，云盘费用和预留券抵扣费用。阿里云提供了给资源打TAG的方式实现分账，具体实现上，我们通过给EMR集群打TAG的方式实现多业务集群之间的分账管理。可以参考[《单账户下企业分账最佳实践》]（https://bp.aliyun.com/detail/168)。
通过报表我们发现EMR-A 30台机器费用和EMR-B 50台机器的费用不成比例，通过分析费用组成我们发现EMR-A处于资源匮乏可用区，用了大量的按量实例和预留实例券，而EMR-B处于资源富余可用区，用了大量的竞价实例，按量实例+预留券费用是远高于竞价实例的。
另外我们还计算了EMR中每个SQL的费用来督促业务优化大SQL和下线无用SQL。我们拉取ResourceManger里的MemorySeconds指标，计算公式为SQL费用=MemorySeconds Of SQL/Total MemorySeconds Of EMR*EMR总费用。
4.3.6 购买RI预留抵扣券
预留实例券是一种抵扣券，可以抵扣按量付费实例（不含抢占式实例）的账单，也能够预留实例资源。相比包年包月实例，预留实例券与按量付费实例这种组合模式可以兼顾灵活性和成本。
预留实例券支持地域和可用区。地域级预留实例券支持在指定地域中可以跨可用区匹配按量付费实例。可用区级预留实例券只可匹配同一可用区中的按量付费实例。
预留实例券支持三种付款类型：全预付、部分预付和0预付。不同付款类型对应不同计费标准。
由于我们使用了竞价实例优先，按量实例兜底的弹性策略，我们购买了一部分跨可用区0预付的预留实例券用来抵扣弹性伸缩的按量实例。下图是预留实例券每个账期的使用情况。
可以看到，有两款ECS规格的预留实例券的使用率分别是0和百分之六十二点五，没有达到预期的百分之百。其原因是后期资源从按量切换到抢占式实例，而预留实例券是不支持抢占式实例的。整体上使用预留实例券之后，相比较按量付费成本节省了百分之四十左右。更多详情可以参考《RI和SCU全链路使用实践》。
弹性保障
弹性保障为灵活付费的日常弹性资源需求提供百分百的资源确定性保障。通过弹性保障，只需要支付一笔较低的保障费用，即可换取固定周期（支持1个月~5年）的资源确定性保障。购买弹性保障时设置可用区、实例规格等属性，系统会以私有池的方式预留属性相匹配的资源。在创建按量付费实例时选择使用私有池的容量，即可保证百分百创建成功。
我们知道双十一前后一段时间阿里云会出现资源紧张的情况，而公司的一些T+1任务属于极度重要任务，为了低成本保障双十一期间EMR弹性资源，我们为数据湖上一些重要的EMR绑定了弹性保障私有池来保障这些重要EMR上的弹性资源在此期间一定能够得到。
4.4 数据湖OSS治理
上面介绍了数据湖上执行引擎EMR的治理，下面我们介绍数据湖的存储介质OSS的治理。
4.4.1 数仓ODS多版本桶治理
版本控制是针对OSS存储空间（Bucket）级别的数据保护功能。开启版本控制后，针对数据的覆盖和删除操作将会以历史版本的形式保存下来。您在错误覆盖或者删除对象（Object）后，能够将Bucket中存储的Object恢复至任意时刻的历史版本。
我们在自建Cloudera Hadoop中为了保障数据的安全使用了HDFS Snapshot的功能。在数据湖架构中，我们使用OSS自带的版本控制功能来保障数据湖上数据的安全。
OSS支持设置生命周期（Lifecycle）规则，自动删除过期的文件和碎片，或将到期的文件转储为低频或归档存储类型，从而节省存储费用。我们也需要设置多版本桶的生命周期来节约成本，保留当前版本且自动删除3天后的历史版本。
4.4.2 数仓日志桶治理
从下图中可以看到9月28日之前标准存储线性增长，9月28日设置了冷存储生命周期，冷存储线性增长，标准存储基本不变，而标准型单价0.12元/GB/月，归档型单价0.033元/GB/月，330T数据转成冷存储节约百分之七十二点五费用。
4.4.3数仓桶和集市桶治理
数据湖架构下EMR的HDFS回收站目录被设置在OSS桶上，HDFS不会对这些垃圾文件定期删除，于是我们需要设置HDFS垃圾箱的生命周期来定期删除垃圾箱内的这些垃圾文件。
4.4.4 监控桶内对象
对象存储OSS支持存储空间清单功能，可定期将Bucket内文件（Object）的信息导出到指定Bucket，帮助了解Object的状态，简化并加速工作流和大数据作业任务等。Bucket清单功能以周为单位将Bucket内的Object进行扫描，扫描完成后会生成CSV格式的清单报告，并存储到指定的Bucket内。在清单报告中可以有选择地导出指定对象的元数据信息，如文件大小、加密状态等。
我们通过设置存储空间清单导出CSV格式的文件放入Hive表中，定期出报表来监控桶内对象的变化情况，找出异常增长情况并加以治理。
5. 阿里云第二代数据湖
第一代数据湖的执行引擎是EMR存储介质是OSS，当我们公司引入Dataphin数据中台时，他的执行引擎和存储是Maxcompute，和我们当前的数仓执行引擎EMR是两套异构的执行引擎，带来的问题如下
-
存储冗余
EMR的存储资源放在OSS对象存储上，MaxCompute的存储资源放在盘古上，造成存储资源的冗余。 -
元数据不统一
EMR的元数据统一放在外置的RDS数据库上，MaxCompute的元数据放在MC元数据库里，两者元数据不统一造成无法共享。 -
用户权限不统一
EMR的用户权限体系是用openldap和ranger构建，而MaxCompute的用户权限体系是用MaxCompute自带的用户权限体系。 -
湖仓计算不能自由流动
根据任务的性质和任务计费规则，高吞吐高复杂度低并发的任务适合在EMR中跑，而低吞吐低复杂度高并发的任务适合在MaxCompute中跑；另外我们可以把双十一的计算资源放在MaxCompute上，解决EMR资源不足的问题。而当前情况不能自由选择执行引擎
阿里云提供了两套湖仓一体方案，其中基于HDFS存储的方案，通过创建外部项目将Hive元数据映射到MaxCompute（相关最佳实践可以参考 https://bp.aliyun.com/detail/169 ）。我们采用另外一种基于数据湖构建DLF（DataLake Formation）实现湖仓一体的数据湖方案。将我们EMR的元数据和MaxCompute元数据迁移到DLF，底层使用OSS作统一存储，打通EMR构建的数据湖和MaxCompute构建的数据仓库两套体系，让数据和计算在湖和仓之间自由流动，真正实现湖仓一体。即湖仓一体的数据湖本质：统一的存储，统一的元数据和自由接入执行引擎。5.1 阿里云数据湖构建
阿里云数据湖构建（Data Lake Formation，DLF）是一款全托管的快速帮助用户构建云上数据湖的服务，产品提供了云上数据湖统一的权限管理、数据湖元数据管理和元数据自动抽取能力。
-
统一数据湖存储
阿里云数据湖构建使用阿里云对象存储（Object Storage Service，OSS）作为云上数据湖的统一存储，在云上可以使用多种计算引擎面向不同的大数据计算场景，开源大数据E-MapReduce，实时计算，MaxCompute交互式分析（Hologres），机器学习PAI等，但您可以使用统一的数据湖存储方案避免数据同步产生的复杂度和运维成本。 -
多样化入湖模板
阿里云数据湖构建可以将多种数据源数据抽取到数据湖中，目前支持的包括关系型数据库(MySQL)、阿里云日志服务（SLS）、阿里云表格存储（OTS）、阿里云对象服务（OSS）和Kafka等，用户可以指定存储格式，提高计算和存储效率。 -
数据湖元数据管理
用户可以定义数据湖元数据的格式，进行集中和统一管理，保证数据质量。
5.2 阿里云数据湖解决方案
我们主要使用阿里云数据湖构建产品的统一元数据管理功能和统一用户权限管理功能。如图架构EMR和MaxCompute共享数据湖DLF的元数据，用户权限和权限管理功能。
基于DLF的数据湖系统架构
数据湖的数据流图如下
数据流图
-
EMR ETLX把业务RDS和业务OSS的数据抽取到数据湖中，即ODS层数据落数据湖。
-
Dataphin数据中台对数据湖的数据进行维度建模（建模中间表包括事实逻辑表和维度逻辑表用MaxCompute内表，不落入数据湖），最后维度建模结果产生在CDM层或者ADS层数据湖上。
-
EMR或其他执行引擎对数据湖上的ADS层数据进行即席查询分析或者调度使用。
作者：程俊杰
原文链接
本文为阿里云原创内容，未经允许不得转载