简介: 上海数禾信息科技大数据平台负责人 程俊杰:MaxCompute+DLF+EMR的湖仓一体架构实现了统一元数据管理 ,统一存储管理,统一权限管理 ,真正实现湖仓计算的自由流动,为企业业务高速发展助力。
程俊杰 上海数禾信息科技大数据平台负责人
通过本次分享,与大家介绍湖仓一体在上海数禾信息科技有限公司演进的四个阶段,包括每个阶段大数据平台的架构以及演进的原因。并着重介绍基于MaxCompute+Data Lake Formation+E-MapReduce的湖仓一体架构,其中包括基于湖仓一体的大数据平台架构,实现此架构面临的挑战以及落地后带来的收益。最后介绍湖仓一体的未来规划。希望可以借此分享帮助其他企业的大数据平台快速成长,同时为企业的高速发展助力。
一、公司业务
上海数禾信息科技有限公司,简称数禾科技,成立于2015年,目前C轮融资,主要产品有“还呗”和“拿铁智投”。
目前注册用户1亿多,业务涵盖信贷,理财和电商。产品包括智能营销,智能风控,智能运营,智能客服。和100多家金融机构进行合作,包括银行、消金、信托、基金、保险。
数禾科技的使命是让人人享有金融服务最优解,公司的愿景是做陪伴用户一生的智能金融家。
二、湖仓一体架构的演进
· 湖仓一体架构演进的时间轴
数禾科技大数据平台的湖仓一体架构演进分为下面四个阶段:
2015-2018.11,云上自建CDH集群。
在公司成立之初,数禾在云上购买了云服务器,并在上面搭建了CDH集群,数仓主要使用Hive,一开始数据量不大,选择了本地SSD磁盘,HDFS存储选择了三副本存储。
2018.12-2020.8,CDH+EMR混合云架构。
由于数禾业务的飞速发展,在计算上,为了扩展CDH集群的计算能力,修改了EMR Hive的源代码,使不同版本的EMR Hive和CDH Hive共享CDH Hive元数据,实现了EMR和CDH的计算流动,缓解了CDH的计算资源压力。在存储上,把部分HDFS上的冷数据,比如日志,备份数据等保存在对象存储上,使CDH和EMR通过外表共享这些数据,大大减轻了CDH存储的成本压力。
2020.9-2021.8,OSS+EMR生态的云原生数据湖。
在这种架构下为每个部门搭建了属于他们自己的EMR集群。在计算上,多个EMR共享一套Hive元数据,且各个EMR各司其职完成自己的任务,完全做到不同角色EMR之间的计算流动。在存储上,多个EMR共享OSS对象存储,且每个EMR绑定自己的RAM角色做到EMR访问OSS对象存储的权限控制。
2021.8-至今,基于MC+DLF+EMR的湖仓一体架构。
自从数禾购买了阿里云数据中台产品之后,该产品使用MaxCompute作为计算引擎,对上个阶段的云原生数据湖架构兼容性带来一些挑战。在和阿里云专家团队进行了几轮充分讨论后,落地了基于MaxCompute+DLF+EMR的湖仓一体架构。 MaxCompute 多项目与多EMR集群共享DLF元数据和数据湖存储OSS,真正做到EMR和MaxCompute之间计算流动。
· 湖仓一体演进中大数据架构以及演进原因
(1) 云上自建CDH集群
在六年前,与大多数公司创立之初一样,数禾选择了在云上购买服务器并自建CDH集群的大数据解决方案。
数据源分为离线数据源,存储在RDS和对象存储上,实时数据源为埋点日志Kafka数据。 离线数据使用Sqoop组件抽取,实时数据使用Flume组件抽取 ,抽取后的实时和离线数据统一保存在CDH的HDFS存储上。
计算层一开始使用Hive,后面使用了执行更加高效的计算引擎Spark和TEZ。
应用层为报表系统,统一用数交互式查询,Jupyter机器学习和RDS业务库。统一用数交互式查询是数禾自研的一套即席查询交互式查询系统,集成了工单审批,权限控制,数据样本和血缘展示等功能。RDS业务库是为了凌晨让数仓加工产生的应用层数据写入,白天让业务系统进行调用。
(2) 第二阶段:CDH+EMR混合云
随着公司业务的飞速发展,业务所用计算资源消耗越来越大,云上自建CDH集群也出现了一系列瓶颈:
自建CDH集群扩展性差。操作难度高且有一定操作风险。且操作周期长,从一开始购买机器,添加节点到集群,分配角色,分发配置,可能还需要择机重启依赖组件或集群,整个过程少则半天,多则一天。
昼夜资源使用不均,导致资源无法合理使用。从半夜的业务系统的日切结束,数仓开始抽取并加工数据,使用大量的计算资源,且早上某些核心数据产出有时效性要求。如果半夜发生事故导致任务延迟,还需要加速跑保证早上数据按时产出,这样需要额外更多的资源储备。而白天集群大部分时间只是供业务人员即席查询,分析,建模使用,需要的计算资源较少。由于没有集群弹性扩缩容,需要全天使集群资源保持一个较高的水位,造成资源的浪费。
CDH集群使用本地SSD磁盘,存储费用高。一开始数据量较少,为了提高CDH磁盘IO性能选择了SSD磁盘,且选择了HDFS三副本保存,后面随着数据量的逐渐增多,SSD磁盘消耗的成本越来越高。且计算和存储不分离,计算资源的增多也造成存储资源的相应增加。
CDH组件的压力日益变大。随着集群任务的逐渐增多,CDH的ResourceManager和HiveServer2组件压力逐渐增加,只能采用Master节点升配,JVM配置调整,重启组件,加强组件监控告警的方式解决。但还是存在很大的事故风险。
为了扩展CDH集群的计算能力,提出了CDH+EMR混合云的大数据架构。
在计算上,一方面根据各个业务场景搭建了多套独立的EMR集群;另一方面,为扩展CDH集群的计算能力,修改了EMR 较高Hive版本的Hive Metastore源代码,使之可以兼容CDH 较低版本Hive的元数据,这样CDH和EMR Hive统一使用一套CDH Hive元数据,用EMR的弹性伸缩能力扩展了CDH计算资源,大大缓解了CDH的计算资源压力,且弹性伸缩能力保证了计算资源的有效利用。
在存储上,把部分CDH磁盘上的冷数据,比如日志,备份数据以Hive 外表的方式保存在对象存储上,使CDH和EMR可以共享这些数据,由于对象存储的费用成本大大低于SSD磁盘存储,因此大大减轻了CDH磁盘成本压力。
(3) 第三阶段:OSS+EMR生态的云原生数据湖
随着员工日益增多,组织架构日趋复杂,CDH+EMR的混合云架构不能满足需求:
元数据管理不完全统一,存在CDH和EMR多套元数据。
用户管理和权限管理不统一,使用Hive自带的用户权限管理系统,CDH和EMR多套元数据也带来了多套用户权限管理体系。
HDFS和对象存储上的数据有冗余。
部门计算资源不能有效隔离。虽然Yarn队列能隔离内存资源,但不能彻底隔离所有资源,比如CPU资源,IO资源和Network资源。
为了解决上面问题,我们提出OSS+EMR生态的云原生数据湖架构。
为了方便管理VPC资源,数禾根据业务单元划分了多个VPC,其中包括业务VPC和大数据VPC。
业务数据保存在业务VPC下,包括资信数据放在业务VPC的OSS对象存储上,埋点日志数据放在业务VPC的云Kafka上,业务数据放在业务VPC的RDS数据库上,还有一些第三方存储包括Mongo,Oracle数据也放在业务VPC下。
大数据VPC上的EMR集群,根据EMR的职能分为数据同步集群,核心数仓集群,标签集群和给每个部门使用的业务集群。数据同步集群利用Sqoop组件把业务VPC下的RDS业务数据和OSS业务数据抽取到数据湖存储OSS中;核心数仓集群对ODS层数据进行数据加工,放到数仓层中;标签集群对数仓层数据进行加工,产出离线标签;而各个部门的业务集群对数仓层数据加工,产生各自的集市数据。每个EMR集群各司其职,完成整个分层数仓的功能。
另外,在EMR访问权限上,每个EMR根据职能绑定各自的RAM角色,访问各自的OSS桶数据;在用户管理上,单独搭建了一个EMR LDAP集群,统一保存所有EMR Hive用户账号,且此LDAP集群T+1和公司的Active Directory同步,加入新员工账号并删除离职员工账号;在权限管理上,使用统一的Ranger权限管理系统,把所有EMR Ranger元数据保存在一个元数据库里管理;所有的EMR Hive元数据也保存在统一的元数据库里;调度系统使用Airflow,搭建了高可用的Airflow Master架构,并把Airflow Worker部署在每个EMR集群的Gateway节点上方便调度任务直接提交到EMR集群;使用了JindoFS组件对数据湖的存储和计算进行加速,这里使用了JindoFS的Cache模式。
三、 基于 MaxCompute+Data Lake Formation+E-MapReduce的湖仓一体架构
· OSS+EMR生态的云原生数据湖架构的瓶颈
数禾引入MaxCompute作为计算引擎的数据中台产品,给原来的OSS+EMR生态的云原生数据湖架构带来很大的挑战:
异构计算引擎元数据管理不统一,MaxCompute的元数据保存在MaxCompute元仓项目上,而EMR的元数据保存在外置RDS数据库上。
异构计算引擎存储管理不统一,MaxCompute表数据存储在MaxCompute内部存储上,而EMR的表数据存储在OSS对象存储上。
异构计算引擎权限管理不统一,MaxCompute表的访问权限由MaxCompute内部权限管理系统控制,而EMR的Hive表的访问权限由Ranger控制。
湖仓计算不能自由流动,由于以上三点原因,EMR创建的表不能马上被MaxCompute访问,而MaxCompute中创建的表也不能马上被EMR访问,当前必须通过创建MaxCompute和EMR的OSS外表才能做到两边引擎的数据互访。
· 基于MaxCompute+DLF+EMR的湖仓一体架构
在和阿里云专家团队进行了好几轮充分讨论后,提出基于MaxCompute+DLF+EMR的湖仓一体架构。
数据湖构建DLF(Data Lake Formation)是一款全托管构建云上数据湖服务的产品,产品提供了云上数据湖统一的权限管理、数据湖元数据管理和元数据自动抽取能力。
从架构上看,底层还是采用数据湖存储OSS,中间是元数据管理+湖加速 ,元数据管理使用DLF数据湖构建,包括元数据管理,数据血缘管理和数据权限管理。湖加速由JindoFS+MaxCompute数据湖加速实现,包括智能Cache,冷热分层,本地缓存加速来实现计算和存储的加速。 计算引擎层,数据湖中的多EMR集群和数据仓库中的多MaxCompute项目,借助统一的元数据管理+湖加速的能力,两者实现元数据的统一和计算的自由流动。
从数据流上看,首先数据同步EMR抽取业务RDS和业务OSS数据到数据湖,阿里云数据中台产品绑定的MaxCompute的ODS贴源层项目,对数据湖中的ODS数据进行数据清洗,脱敏,统一命名,精度清洗等操作。CDM数仓层项目主要提供OneData规范建模的功能。这里需要强调一下,由于阿里云数据中台产品的设计,这层的数据主要以内表的方式落在MaxCompute内部,不落在数据湖上,这里用灰色表示。ADS应用层项目主要用于各个业务方基于CDM层数据建立各自的数据集市,可以直接对数据湖进行读取和写入。VDM沙箱层项目直接向终端用户提供ADS层和CDM层数据的查询,分析功能。
这样,数据湖上的统一用数交互式查询可以通过即席查询EMR对数据湖的数据进行查询和分析,Jupyter也可以通过机器学习EMR对数据湖中的数据进行模型训练和推理。
· 实现MaxCompute+DLF+EMR架构面临的挑战
当前数禾线上25个EMR处于生产环境,任何事故将导致EMR产出延迟造成公司的资损。阿里云DLF团队为数禾设计了一整套完整的Hive Metastore切换到DLF的解决方案,共分为五个阶段,四个切换过程:
METASTORE_ONLY,DLF切换前,读写Hive Metastore。
METASTORE_DLF_FAILURE,这个阶段首先读写Hive Metastore, 然后写入DLF允许失败。
METASTORE_DLF_SUCCESS,这个阶段首先读写Hive Metastore,然后写入DLF不允许失败。
DLF_METASTORE_SUCCESS,这个阶段首先读写DLF,然后写入Hive Metastore不允许失败。
DLF_ONLY,最终切换完成后只读写DLF,完全抛弃Hive Metastore;
每个切换阶段,25个EMR集群分为不重要集群,非重要业务集群,重要业务集群和核心集群,按顺序进行灰度切换。且每个EMR切换后都用自动化Hive全场景单元测试脚本进行验证,保证切换结果正确。
· 基于MaxCompute+DLF+EMR湖仓一体架构的收益
统一元数据管理,统一把EMR元数据和MaxCompute元数据保存在DLF中。
统一存储管理,统一把EMR的数据和MaxCompute外表数据保存在数据湖OSS中。
统一权限管理,统一把EMR权限和MaxCompute外表访问权限收敛在DLF中。
湖仓计算自由流动,基于以上特点,EMR中创建的表,MaxCompute能马上访问;反之亦然,真正做到湖仓计算自动流动。
四、湖仓一体的未来规划
未来湖仓一体会把DLF元数据管理功能升级为统一的元数据管理平台,包括统一的元数据仓库和统一的元数据服务。
可以注册数据湖EMR的元数据到元数据管理平台,数据湖以E-MapReduce作为执行引擎,且用JindoFS作为计算和存储的加速模块,以OSS对象存储保存;可以注册数据仓库MaxCompute的元数据到元数据管理平台,同时支持MaxCompute的内表和外表。数据仓库以MaxCompute为计算引擎,以智能cache作为计算和存储的加速,数据既可以落在OSS存储也可以落在MaxCompute内部;也可以同步其他的联邦数据源到元数据管理平台,包括Hologres交互式分析,RDS数据库,ElasticSearch搜索和分析引擎,和云Hbase等数据源。这样可以实现多种数据源元数据的统一,计算和数据的自由流动。
在应用层上使用湖仓统一开发管理平台对所有接入统一元数据管理平台的云产品进行开发和管理,功能包括湖仓数据集成和开发模块,既可以集成多数据源,也可以做免数据传输的多数据源联邦查询;湖仓血缘关系模块,管理所有数据源的大血缘关系;湖仓权限管理模块,管理所有数据源的用户访问权限;湖仓数据管理和治理模块,包括多数据源表字段的命名规范,数据有效性验证等功能。
更多关于大数据计算、云数据仓库技术交流,欢迎扫码查看咨询。
