数禾云上数据湖最佳实践

目录

1. 数禾科技
2. 云上自建CDH
3. 云上混合架构
4. 阿里云第一代数据湖
4.1. 什么是数据湖
4.2. 阿里云数据湖设计
4.2.1. 阿里云数据湖整体架构
4.2.2. 统一存储和元数据管理
4.2.3. 多EMR多OSS桶设计
4.2.4. 分布式调度系统设计
4.2.5. 用户权限系统设计
4.2.6. EMR弹性伸缩设计
4.2.7. 负载均衡管理
4.2.8. OSS桶生命周期管理
4.2.9. 日志管理
4.2.10. 终端权限管理
4.2.11. 组件UI管理
4.2.12. 监控告警管理
4.2.13. 即席查询设计
4.2.14. 集群安全组设计
4.2.15. 数据脱敏设计
4.2.16. YARN队列设计
4.3. 数据湖EMR治理
4.3.1. 调整EMR预伸缩时间
4.3.2. 更改EMR弹性伸缩策略
4.3.3. 优化EMR云盘空间
4.3.4. EMR机器组的选择
4.3.5. EMR成本控制
4.3.6. 购买RI预留抵扣券
4.3.7. 弹性保障
4.4. 数据湖OSS治理
4.4.1. 数仓ODS多版本桶治理
4.4.2. 数仓日志桶治理
4.4.3. 数仓桶和集市桶治理
4.4.4. 监控桶内对象
5. 阿里云第二代数据湖
5.1. 阿里云数据湖构建
5.2. 阿里云数据湖解决方案

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 什么是数据湖

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。你可以按原样存储数据，而无需先对数据进行结构化处理，然后运用不同类型的引擎进行分析，包括大数据处理、可视化、实时分析、机器学习等，以指导做出更好的决策。

数据湖与数据仓库相比

数据湖解决方案的基本要素

• 数据移动

数据湖允许您导入任何数量的实时获得的数据。您可以从多个来源收集数据，并以其原始形式将其移入到数据湖中。此过程允许您扩展到任何规模的数据，同时节省定义数据结构、Schema 和转换的时间。

• 安全地存储和编目数据

数据湖允许您存储关系数据和非关系数据。它们还使您能够通过对数据进行爬网、编目和建立索引来了解湖中的数据。最后，必须保护数据以确保您的数据资产受到保护。

• 分析

数据湖允许组织中的各种角色（如数据科学家、数据开发人员和业务分析师）通过各自选择的分析工具和框架来访问数据。这包括 Apache Hadoop、Presto 和 Apache Spark 等开源框架，以及数据仓库和商业智能供应商提供的商业产品。数据湖允许您运行分析，而无需将数据移至单独的分析系统。

• 机器学习

数据湖将允许组织生成不同类型的见解，包括报告历史数据以及进行机器学习（构建模型以预测可能的结果），并建议一系列