数据湖存储架构选型

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: 阿里巴巴计算平台事业部郑锴为大家带来数据湖存储架构选型的介绍

本文内容来自由阿里云计算平台事业部与阿里云开发者社区联合主办的大数据+AI meetup 2020第二站·上海讲师郑锴的分享《数据湖存储架构选型》


一、数据湖是个潮流

简单来讲,数据湖的理念就是说从一个企业的视角来讲,把整个数据集中的统一的存储在一起,主要通过 BI 和 AI 的手段来计算分析原始的数据。数据的类型不光是结构化、半结构化的,还包括音视频,这样的一些材料。

什么事数据湖.png

我们为什么要基于数据湖来做这样的一个转型呢,数据湖能够给我们带来什么样的好处呢。

第一,打破数据孤岛。就是说原始的数据我们先不考虑怎么去处理它、分析它,甚至是说我们先不考虑它到底会不会解决很大的业务上面的问题,我们先把它放在一起,打破数据孤岛,为后面的业务发展演化和计算,可能就提供了很好的一个机会。

第二,基于统一的、集中的整个数据的收集,可以支持各种各样的计算。

第三,弹性。我们数据湖本身是有弹性的,然后支持的计算也是有弹性的。弹性可能在云上面带来成本的很大的伸缩性的空间,为我们优化存储和计算的成本带来了这样一个可能。

第四,管理。我们把数据放在一起,可以提供统一的、集中的这样一个管理控制。

为啥要数据户.png

熟悉 Hadoop 整个生态的话,过去经常会谈到一个非常大的、非常复杂的生态的大图。那个图里面涉及到非常多的组件,结构关系非常复杂。而基于数据湖的架构,可以得到大大的简化。

如下图所示,最下面是数据湖本身,基于这样的一个数据湖存储,我们可以有一个统一的元数据服务,做数据湖的创建管理,然后围绕数据湖做数据的治理开发,和各种数据源的集成打通。但是这个并不是目的,最主要的作用还是说我们要做计算。数据湖的计算,简单来讲就是说我们有各种各样的开源的 BI 的引擎,或者 AI 的引擎,每个引擎可能有自己的集群,然后基于数据湖来进行相应的计算场景的处理。然后满足我们最上面的基于数据湖的各种应用,比如说数据大屏,数据报表,数据挖掘,机器学习。

数据户架构.png

二、湖存储/加速:挑战很大

数据湖架构里面,对于存储的挑战很大。

第一,最大的一个因素是数据量的问题。按照数据湖的理念,我们要把所有的数据全部都放在一起,那么在数据的规模上来讲是非常大的,数据规模可以膨胀到 PB、EB 级别。

第二,文件的规模。从存储系统的角度来讲,文件的规模可以说也是非常大,要么就是层次非常深,要么就是非常扁平。扁平就是说一个目录下可能会有几百万的文件数,形成这样一个超大的目录。

第三,成本。我要收集那么多的数据,我要把全部原始的数据放在一起,成本上怎么去优化。

海量数据.png

另外一个挑战就是说,按照数据湖的架构,它背后的本质是存储和计算分离。现在是专业化的分工,存储的做存储,计算的做计算,这个带来非常大的研发效率的这样一个提升。但是分离了之后,怎么满足计算的吞吐,怎么满足计算对性能的这样一个需求,这也是带来很大挑战的一个原因。

  存储计算和分离.png

另外,在数据湖的整个的方案下面,要考虑到计算场景是非常丰富的,计算的环境也是错综复杂的。大数据,我们要支持分析、交互式、实时计算。然后 AI 有自己的各种各样的引擎来训练。

然后是计算的场景,包括 EMR 、ECS 自建、云原生、混合云。这样的一些环境可能都会涉及到,我们怎么提供一个统一、集中的存储的解决方案,来满足这样一个丰富的计算场景和环境。

丰富计算厂家.png

假设我们能够克服数据量上面的挑战,满足各种计算的环境,也能够提供缓存加速,也能够满足存储的这样一个性能。现在架构师决定了我们要做数据迁移,实施层面的挑战是什么。我们要做大量数据的迁移,之后要做正确性的比对。另外,比如说, Hive 数仓,Spark 作业,可能上千上万的作业我们决定要迁移,迁移了之后要做结果的比对。迁移上来之后,可能我过去有一套成熟的治理、运维的体系,在新的架构下面,我怎么能够尽量少改,能够继续得到支持。这是实施层面的挑战。

三、完美选项之 checklist

数据湖架构下面,从存储、加速的视角,我们可以看到有这样一些挑战,那么理想的选型是什么样子的,要考虑到哪些因素,这里做了一个总结。

  • 第一, 基于对象存储,大规模存储能力。
  • 第二,大目录元数据操作能力。
  • 第三,策略灵活的缓存加速能力。
  • 第四,和计算打通优化的能力。

check list.png

  • 第五,支持数据湖新型表格存储的能力。
  • 第六,归档/压缩/安全存储的能力。
  • 第七,全面的大数据+ AI 生态支持。
  • 第八,强大迁移能力,甚至是无缝迁移能力。

以上就是作为一个理想的数据湖的存储、加速方案,最好具备的一个 checklist 。考虑升级到数据湖架构的这样一些架构师可以对照一下这个 checklist ,来做方案的选型。

四、阿里云上的 JindoFS

接下来看一下阿里云上面在做的 JindoFS 这样一个方案具体是什么样的情况。简单来讲我们在做三个事情。

第一个事情就是说,我们是基于阿里云 OSS ,就是面向 Hadoop , Spark 和 AI 的生态,做了这样的一个 SDK ,然后是优化版本的。我们知道 Hadoop 是具有 OSS 的支持的,我们为什么要做一个新的。简单来讲,就是说我们要做好优化。首先,我们要做好元数据操作的优化,特别是对于大目录要做好优化。另外一个就是 Rename 优化。 我们知道对象存储一个关键的元数据操作就是目录的 rename 操作,它是一个非常大的挑战,这是对象存储的本质决定的。因为对象存储不是文件系统,它其实没有目录的概念,它的目录完全是模拟出来的。也就是说,你对一个目录进行操作,就必须要对成千上万个对象相应的进行操作来模拟。甚至是说,在一些计算场景里面,是不是能够做到跳过 rename 。另外一个是读写 IO 优化,能不能够充分的利用好对象存储带来的水平扩展的这样一个能力,来做好lO的优化。最后, OSS 的多版本,或者 OSS 的归档,我们是不是能够支持。以上是我们第一个层面的工作。

hadoop 0ss支持和优化.png

第二个事情是为 OSS 存储提供一个缓存加速的分布式系统。首先是数据的一致性,包括元数据的一致性和缓存数据的一致性。然后是磁盘缓存,包括写时缓存,读时缓存,以及磁盘的负载均衡。最后是水位清理,包括缓存块 LRU 淘汰。

oss缓存加速系统.png

第三个事情是说,我们也打造了一个基于 OSS 的存储扩展的系统。首先是管理元数据,包括内存缓存,细粒度锁。其次是文件数据分块存放, OSS 1备份,缓存1备份。然后是性能优化,元数据操作普遍 > HDFS ,缓存读 + OSS 读 > HDFS 。最后是高扩展,基于 OSS 的大规模水平扩展。

基于0ss的存储系统.png

下面对照之前提到的 checklist ,看一下 JindoFS 的支持情况。

  • 第一,基于对象存储,大规模存储能力。支持,基于阿里云对象存储 OSS , OSS 支持 EB 级海量存储。
  • 第二,大目录元数据操作能力。支持,JindoFS 在超大目录数据加载、检索、统计、rename 上具有几倍的性能优势。
  • 第三, 缓存加速的能力。支持,JindoFS 支持在大数据分析场景、交互式查询场、机器学习训练 场景和云原生应用场景提供策略灵活的分布式缓存加速能力; 缓存加速的性能提升大于 50% 的效果优于开源方案。
  • 第四,和计算打通优化的能力。支持,和 JindoFS co-design 的 JindoTable 提供对数仓表的缓存、计算加速、治理优化和归档存储支持。

check表哥.png

  • 第五,支持数据湖新型表格存储的能力。支持,JindoFS 提供 Delta 、Hudi 和 Iceberg 所需要的存储接口和事务支持语义,并支持 Flink 实时入湖。
  • 第六,归档/压缩/安全存储的能力。支持, JindoFS 在目录、表、分区级别支持 OSS 归档;提供透明压缩;支持 AK 免密保护,Ranger 授权和审计扩展功能。
  • 第七,全面的大数据+ AI 生态支持。支持,JindoFS 全面兼容和支持开源生态,提供: Hadoop JindoFS SDK; Jindo Job Committer ; POSIX fuse 支持 JindoFuse ; TensorFlow FileSystem ; Flink connector ; Kite SDK 。
  • 第八,强大迁移能力甚至是无缝迁移的能力。部分支持,提供优化的 JindoDistCp 工具,支持 Hadoop 数据源导入。

checklist contd.png

本次分享详细PPT请扫码下方二维码关注数据湖技术圈微信公众号回复1101数据湖领取!

qrcode_for_gh_f0cd22f9c90e_258.jpg

推荐相关阅读:

数据湖架构,为什么需要“湖加速”?


更多数据湖相关信息交流请加入阿里巴巴数据湖技术钉钉群

数据湖丁群二维码.png

相关实践学习
基于EMR Serverless StarRocks一键玩转世界杯
基于StarRocks构建极速统一OLAP平台
快速掌握阿里云 E-MapReduce
E-MapReduce 是构建于阿里云 ECS 弹性虚拟机之上,利用开源大数据生态系统,包括 Hadoop、Spark、HBase,为用户提供集群、作业、数据等管理的一站式大数据处理分析服务。 本课程主要介绍阿里云 E-MapReduce 的使用方法。
目录
相关文章
|
1月前
|
存储 数据采集 弹性计算
Codota的存储架构通过多种方式保障数据安全
Codota的存储架构通过多种方式保障数据安全
30 4
|
2月前
|
运维 负载均衡 安全
深度解析:Python Web前后端分离架构中WebSocket的选型与实现策略
深度解析:Python Web前后端分离架构中WebSocket的选型与实现策略
124 0
|
4月前
|
存储 缓存 前端开发
Django 后端架构开发:存储层调优策略解析
Django 后端架构开发:存储层调优策略解析
69 2
|
1月前
|
存储 缓存 弹性计算
Codota的服务器存储架构
Codota的服务器存储架构
29 5
|
1月前
|
存储 缓存 弹性计算
Codota的存储架构
Codota的存储架构
34 3
|
1月前
|
存储 Cloud Native NoSQL
云原生时代的数据库选型与架构设计
云原生时代的数据库选型与架构设计
25 0
|
2月前
|
存储 监控 分布式数据库
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
本文介绍了百亿级数据存储架构的设计与实现,重点探讨了ElasticSearch和HBase的结合使用。通过ElasticSearch实现快速检索,HBase实现海量数据存储,解决了大规模数据的高效存储与查询问题。文章详细讲解了数据统一接入、元数据管理、数据一致性及平台监控等关键模块的设计思路和技术细节,帮助读者理解和掌握构建高性能数据存储系统的方法。
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
|
2月前
|
消息中间件 运维 NoSQL
基础架构组件选型及服务化
【10月更文挑战第15天】本文概述了分布式系统中常见的基础架构组件及其选型与服务化的重要性。
|
2月前
|
消息中间件 运维 NoSQL
基础架构组件选型及服务化
【10月更文挑战第2天】本文介绍了常见的分布式基础架构组件,包括分布式服务化框架(如Dubbo、Spring Cloud)、分布式缓存(如Redis、Memcached)、数据库及分布式数据库框架(如MySQL、TiDB)、消息中间件(如Kafka、RabbitMQ)和前端接入层(如LVS、Nginx)。文中探讨了组件选型问题,强调统一标准的重要性,避免重复劳动与维护难题。最后,提出基础架构服务化的必要性,通过标准化和平台化提升运维效率
|
3月前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
187 9