数据湖存储架构选型-技术圈

作者简介

郑锴，花名铁杰，阿里巴巴高级技术专家，Apache Hadoop PMC。深耕分布式系统开发和开源大数据多年，目前专注于在阿里云上研发业界领先的 Hadoop/Spark 大数据平台和数据湖解决方案产品。

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

一、数据湖是个潮流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、完美选项之 checklist

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

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

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

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

四、阿里云上的 JindoFS

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

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

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

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

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

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

第五，支持数据湖新型表格存储的能力。支持，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 数据源导入。