简介：数禾科技从成立伊始就组建了大数据团队并搭建了大数据平台。并在 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 上设置生命周期定期把数据放入冷存储。

云上混合架构

有了云上混合架构实际，理论曾经有一个大数据数据湖的雏形，咱们想趁着某云厂商迁徙到阿里云之际，在阿里云上落地一个适宜数禾以后现实状况的数据湖。

1. 阿里云第一代数据湖

=============

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/…。
通过报表咱们发现 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 表中，定期出报表来监控桶内对象的变动状况，找出异样增长状况并加以治理。

1. 阿里云第二代数据湖

=============

第一代数据湖的执行引擎是 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 层数据进行即席查问剖析或者调度应用。

作者：程豪杰
原文链接
本文为阿里云原创内容，未经容许不得转载