数据湖技术解析.pdf

封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）目录 数据湖架构及概念简介.4 数据湖统一元数据与权限.10 数据湖管理及优化.22 基于 EMR 的新一代数据湖存储加速技术详解.30 基于 Delta Lake 构建数据湖仓体系.44 Spark on k8s 在阿里云 EMR 的优化实践.64 实时数据湖 Flink Hudi 实践探索.77 数据湖架构及概念简介 4 数据湖架构及概念简介 作者：陈鑫伟 一、数据湖演进历程 1.什么是数据湖？数据湖概念于 2010 年提出，其目的是解决传统数据仓库和数据集市所面临的两个问题：其一，希望通过统一的元数据存储解决数据集市之间的数据孤岛问题；其二，希望存储原始数据，而非存储数据集市建设过程中经过裁剪后的数据，以避免数据原始信息的丢失。当时，开源的 Hadoop 是数据湖的主要代表。随着云计算的发展，2015 年，各个云厂商开始围绕云上的对象存储重新解读和推广数据湖。云上对象存储具有大规模、高可用和低成本的优势，逐步替代了 HDFS 成为云上统一存储的主流选择。云上的对象存储支持结构化、半结构化和非结构化的数据类型，同时以存算分离的架构和更开放的数据访问方式支持多种计算引擎的分析，主要代表有 AWS S3 和阿里云的 OSS。2019 年，随着 Databricks 公司和 Uber 公司陆续推出 Delta Lake、Hudi 和 Iceberg数据湖格式，通过在数据湖的原始数据之上再构建一层元数据层、索引层的方式，解决数据湖上数据的可靠性、一致性和性能等问题。同时，流式计算技术如 Flink、AI 技术等也开始在数据湖上有了更广泛的应用。数据湖架构及概念简介 5 同年，AWS 和阿里云也相继推出了 Data Lake Formation 等数据湖构建和管理的产品，能够帮助用户更快速地构建和管理云上数据湖。数据湖架构的不断演进和成熟也得到了更多客户的关注和选择。2.数据湖架构演进 早期，用户基本在 IDC 机房里基于服务器或虚拟机建设 Hadoop 集群，主要的存储为 HDFS，主流的计算引擎为 Hive 和 Spark 等。随着云计算的发展，很多用户为了解决 IDC 机房在资源扩缩容和运维方面的困难，开始选择在云上构建自己的数据湖平台。可以选择云上提供的大数据构建平台，比如 EMR，来帮助快速建设和部署多个集群。但大部分早期用户选择直接将云下的架构搬到云上，依然以 HDFS 为主要的存储，因此 HDFS 的问题依然存在，比如 NameNode 的扩展性问题、稳定性问题；比如计算资源和存储资源的耦合问题等；数据也存储于集群内部，跨集群、跨引擎的数据访问也会存在问题。而现在更主流的选择是数据湖架构，基于云上对象存储如 OSS 做统一存储。在存储之上，有一套管控平台进行统一的元数据管理、权限管理、数据的治理。再上层会对接更丰富的计算引擎或计算产品，除了 Hadoop、Hive、Spark 等离线分析引擎，也可以对接流式的引擎比如 Flink，Olap 引擎如 ClickHouse、Doris、StarRocks 等。数据湖架构及概念简介 6 二、云原生数据湖架构 1.阿里云数据湖发展历程 阿里云在数据湖方向已经经过了很多年的发展。最早期的 OSS 发布于 2011 年，彼时数据湖的应用场景还很少。直到 2015 年，阿里云发布了云上 EMR 产品，开始将Hive 和 Spark 放至 EMR 集群，再将数据放至 OSS，存算分离的架构开始流行。2018 年和 2019 年，阿里云相继推出了数据湖分析 DLA 和数据湖构建 DLF 两款专门面向数据湖的产品。2022 年推出的数据湖存储（OSS-HDFS）以及 EMR Data Lake集群，数据湖解决方案的产品矩阵逐步形成。整个历程中，有三个标志性事件：2019 年，阿里云发布了阿里云云原生数据湖白皮书，很多业内伙伴都基于这份白皮书开始研究学习和建设自己的数据湖；同年阿里云也打通数据湖和自研的 MaxCompute 云原生数仓，推出了湖仓一体架构；2022 年，阿里云成为首批通过通信院的云原生数据湖测评认证的企业。数据湖架构及概念简介 7 2.数据湖建设思路及挑战 经过多年沉淀，阿里云在数据湖的建设上也积累了一定的经验和思路。我们认为数据湖的建设主要包括四个阶段。第一阶段：数据入湖。通过各种各样的入湖方式将数据导入数据湖。入湖方式可以根据自己的业务需求和场景进行选择，比如全量入湖、CDC 更新入湖、实时追加写入以及整个 Hadoop 集群搬迁上云等。第二阶段：数据湖存储与管理。帮助用户更好地管理发现和高效使用数据湖里的数据。此阶段主要包括以下几个方面：数据目录与检索：一方面能够提供元数据的服务，另一方面能够提供数据的快速检索能力。权限控制与审计：因为数据湖本身是相对开放和松散的体系，需要有比较强的权限管控的能力来保证企业数据的安全性。数据质量控制：避免数据湖发展成数据沼泽的关键手段。湖表管理与优化：管理优化数据湖格式。数据湖架构及概念简介 8 存储管理与优化：对象存储提供了数据冷热分层的特性，但这些特性落地时还需要辅以自动化的手段以进行存储管理优化。第三阶段：数据处理与分析。可以根据实际场景选择多种数据处理和分析方式，比如做离线分析、实时计算、交互式分析、AI 训练等。第四阶段：数据服务与应用。数据湖较为开放，因此可以直接用 BI 系统、可视化系统连接数据湖上的引擎，进行实时分析或可视化的数据展示等。另一方面，数据湖里的数据也可以再进一步同步或 Sink 到更专业的数据系统中，比如到 ES 里进行进一步数据检索，比如到ClickHouse/Doris/StarRocks 等做更丰富的多元分析。3.阿里云云原生数据湖解决方案 经历了多年的摸索后，阿里云推出了一个较为完整的云原生数据湖解决方案，整体架构如上图所示：底层是存储层：统一存储各类数据，并对外提供文件访问的接口和协议。数据湖架构及概念简介 9 第二层是管控层：可以理解为服务化的管控与优化，一方面提供统一的元数据、统一权限管控，另一方面提供智能化数据湖管理、快速数据检索等能力。第三层是多元的计算与分析层：可以通过很多开源或阿里云自研的分析引擎对湖内数据进行加工和处理。最上层是数据开发治理层：提供了面向湖和仓完善的数据开发体系以及数据治理平台。由此可见，数据湖的建设不仅仅是大数据相关技术的集成和应用，同时也是一个复杂的系统工程，需要有成熟的方法论以及平台型的基础设施做支撑，才能建设出安全可靠、功能完善、成本可控的企业级数据湖。数据湖统一元数据与权限 10 数据湖统一元数据与权限 作者：熊佳树，阿里云数据湖构建与分析研发 一、元数据与权限背景介绍 1.开源元数据体系由来、演进及问题 开源大数据体系是指以 Hadoop 为中心的生态系统，而目前 Hive 是开源数仓的事实标准。关于大数据的由来和发展，要追溯到谷歌在 2003 年发表的论文，论文中提出了HDFS 和 MapReduce 两个组件。HDFS 组件最早用于解决网页存储问题，它可以部署在大量廉价的机器上，提供极佳的硬件容错能力以及存储的扩展性。MapReduce的初衷是解决搜索引擎中大规模网页数据的并行化处理问题。同时它也是比较通用的并行处理框架，可用于处理很多大数据场景。虽然HDFS和MapReduce很好地解决了大数据存储和大规模数据并行处理的问题，但依然存在几个缺点：第一，编程门槛较高。传统的数仓工程师接触的编程接口一般是 SQL，但MapReduce 框架有一定的编程能力要求。数据湖统一元数据与权限 11 第二，HDFS 上存储的是文件和目录，并没有存储元数据，也无法进行查询。因此即使知道文件的结构，也无法对文件的内容方式变化进行管理，导致程序本身可能丧失稳定性。基于以上痛点，以雅虎为代表的公司提出了 Apache Pig，提供 SQL-like 语言，该语言的编译器会把类 SQL 的数据分析请求转换为一系列经过优化处理的 MapReduce运算，屏蔽了 MapReduce 细节，可以很轻松高效地处理数据；而以 Facebook 为代表的公司提出 Hive 的解决方案，在 HDFS 上提供了一层数据抽象，屏蔽了文件系统及编程模型的细节，极大降低了数仓开发人员的门槛。通过对数据及文件系统到元数据的抽象，能够非常方便地进行数据共享、检索以及查看数据变更历史。这一层的元数据抽象即如今大家所熟知的 Database、Table、Partition 和 Function，同时在元数据上又衍生出了非常接近 SQL 语言的 HiveQL。同时后续的 Hive3.0 版本新增了 catalog 的功能，Hive4.0 版本新增了 Connectors功能。依托于元数据，计算引擎可以很好地进行历史的追溯。除了追溯历史 schema变更外，元数据还有一个重要功能是保护数据（不做不兼容的变更）。Hive3.0 实现的 catalog 功能，主要基于以下两个场景：多个系统之间可能需要 MetaStore 元数据的 Namespace，期望能够达到一定的隔离。比如Spark有自己的catalog，Hive也有自己的catalog，不同的catalog上可以有不同的鉴权、运营策略。可以对接外部系统的 catalog。Hive4.0 的 Connectors 主要是定义数据DataSource，其他引擎对接 Hive 元数据后，即可通过该接口识别 DataSource的信息，方便其他引擎做查询。数据湖统一元数据与权限 12 目前 Hive 上几乎已经支持了 Hadoop 生态的所有计算引擎，因此它也已经成为开源数仓的事实标准。但它依然存在一些问题，比如虽然支持了 schema 的衍变，但是并不能通过 Time-Travel 的方式查询数据变化的历史快照，虽然有 ACID 新特性，但与 Hive 引擎的深度绑定导致无法很好地移植到其他引擎上。另外，ACID 特性主要使用 rename 的方式做 isolation 隔离，在做文件 Compaction及在存储分离等场景容易出现问题，比如 rename 过程在云存储上的性能问题。开源社区针对这些点衍化出了一些数据湖的格式，在不同程度上解决了ACID的问题。数据湖格式拥有自己的元数据，同时会将自身的元数据注册到 Hive Metastore 中。数据湖格式的元数据与Hive元数据形成补充，并没有脱离整体Hive元数据的视图，其他引擎依然可以通过Hive Metastore这一套元数据管理体系访问数据湖格式上的数据。但 Hive Metastore 上并没有多租户的能力，同时受限于单个元数据库的能力瓶颈，有些公司会部署多套 Metastore，这很容易形成数据孤岛，所以也有一些公司提出了解决方案，比如 Waggle-Dance 及 Multiple Hive Metastore 方案等。另外因为HiveMetaStore 使用 Thrift 协议的接口，所以内部引擎和自研引擎对接 Hive Metastore 时，必须对接 Metastore 的协议以及依赖相应的客户端，这种依赖还是比较重的。另外，Metastore 在设计元数据存储时高度去冗余，因此会带来一些 Metadata Fetch的性能问题。开源的 Waggle-Dance 方案后端有多个 Metastore，每个 Metastore 有自己的Database 存储。Waggle-Dance 模块实现了 Hive Metastore 后端完整的 Thrift 协 数据湖统一元数据与权限 13 议，能够无缝对接到其它引擎，解决现有的 Metastore 瓶颈问题，比如单个 DB 存储量、单个 Metastore 性能问题等。但是 Waggle-Dance 解决多租户的方案存在命名冲突问题，需要提前做 Database和 Metastore 的命名规划。因为 Waggle-Dance 路由的模块有一个 Database 到后端 Metastore 路由表。如果是 Hive3.0，可以通过 catalog 这一层路由的映射设计来解决。另外，Waggle-Dance 可能会带来 Thrift 接口协议的冲突，比如后端可能存在多个Hive Metastore 的版本或有多个不同 client 的版本。因此中间层的路由组件可能需要兼容不同的版本，就可能会出现协议的兼容性问题。2.权限控制体系介绍 除了元数据外，元数据和数据访问的安全性也非常重要。企业的数据安全性必须依赖于完善的权限体系。权限的基本三要素包括主体、客体和操作。ACL 建立在基础三要素之上，对应到元数据上为：某个人对某个表有什么样的操作权限。ACL 存在一定的缺陷，比如后续如果权限比较多会难以管理，因此又发展出 RBAC 和 PBAC 权限。以入住酒店为例解释 ACL、RBAC 和 PBAC 三者的区别：比如住客入住酒店后会得到一把房门钥匙，得到进入某个房间的权限，即相当于 ACL；而针对某一楼层有一个楼层管理员，可以管理所有房间，即相当于 RBAC，在 ACL 上面增加了一层用户的角色到权限的映射，有了角色之后很显然降低了权限管理成本；但是如果有比较特殊的需求，比如需要限制某一层的管理员只能在上午 7 点后才有权限进入房间，即需要 PBAC，它是基于策略的模型，在普通权限模型的基础之上支持了权限条件。数据湖统一元数据与权限 14 Hive0.13 提出了 Hive Storage-Based Authorization，它是基于底层存储的鉴权。该权限策略的优点在于无论是 meta 操作还是底层文件存储操作，都可以获得统一的权限视图。但它是基于目录和底层文件的权限体系，因此无法很好地映射到 SQL 层面权限操作。同时，因为底层的权限是文件，所以无法在数据层面或字段级别做更细粒度的鉴权，因此它并不支持 Fine-grain control。基于以上问题，社区提出了 Hive SQL-Standard Based Authorization，即基于 SQL的标准化鉴权模型，能够在 SQL 层面支持 Grant 和 Revoke 控制指令。同时可以做相对细粒度的权限控制，比如可以将搜索上的很多操作映射到权限模型上。该模型实现了列级的访问控制，但没有实现行级的权限。另外，Hive SQL-Standard Based Authorization 虽然具有 SQL 层面的权限，但并不包含存储系统的权限。因此做存储系统的访问或实操层面访问时，无法获得统一的权限视图。且该模式不支持数据湖格式。后来，某商业公司推出了 Apache Ranger（Sentry），面向所有大数据开源生态组件，对底层的文件系统 YARN、Hive、Spark、Kafka 提供了中心化的权限控制方案。同时支持在 SQL 层面进行 Grant、Revoke，比此前的模型增加了更细粒度的权限，比如行级过滤、列级权限控制，同时在权限上还具备 exception policy 及其他能力。但 Apache Ranger 也存在一些问题。因为 PBAC 模型的权限是事先定好的，不依赖对象的存在与否。比如用户对某表有 select 权限，表被删除后又被重新建出，而该用户仍然拥有权限，这并不合理。另外，虽然 ranger 可以使用在很多大数据组件之上，但仅限于 Hive 的 HiveServer，而 Hive Metastore 上并没有权限控制，所以它 数据湖统一元数据与权限 15 面临的问题在于Hive Metastore提供的元数据访问接口和在之上提供的权限接口存在分离。因此，总结来看，数据湖管理面临的挑战包含以下几个方面：在元数据服务层面，开源版本没有多租户的能力，扩展性、稳定性以及性能方面都存在问题，对接多个计算引擎难度大。数据安全层面，权限控制方案复杂，成熟度低，无法覆盖所有计算引擎，且为开放存储，权限难以控制。数据治理层面，开源社区目前没有非常好的数据管理工具。无法很好地根据元数据分析现有的存储成本，也无法做很好的生命周期管理。虽然 Hive4.0 已经增加了一些特性，比如可以做 partition 的自动发现以及对 partition 做一定的生命周期管理，但整体上依然没有很好的治理手段。查询性能层面，存储计算分离架构的读写性能受带宽控制，原始数据未经过优化因而查询性能低，且缺少索引、统计等加速手段。阿里云针对上述问题和挑战，实现了一套面向数据湖领域的元数据、安全、治理、加速的解决方案：数据湖统一元数据与权限 16 全托管免运维的统一元数据中心 统一元数据中心脱胎于阿里云内部久经考验的元数据底座，无缝对接多种开源计算引擎和自研的内部引擎，同时依托于阿里云的数据湖构建与管理 DLF 产品提供了元数据的发现、迁移、备份的能力。企业级权限控制 数据安全方面，支持阿里云账号系统，也可以兼容开源的 LDAP 账号体系；提供字段级别的读写权限控制和 Location 权限托管。引擎和应用甚至可以对接元数据 API和权限 API，实现自己的权限集成或元数据集成，从而使所有引擎及应用都可以实现对权限的统一控制。智能数据管理与优化?精细化存储统计与分析?自动化数据冷热判断与分层 多重数据湖加速?JindoFS 提供数据缓存加速?自动小文件合并、数据清理?自动 Stats 计算、查询优化?湖格式元数据服务化 二、阿里云数据湖统一元数据服务 1.阿里云上数据湖统一元数据服务架构 阿里云上数据湖统一元数据服务（DLF）提供了多租户、统一数据目录，支持多引擎的扩展与切换。兼容了 Hive2.X 与 Hive3.X 协议，能够实现无缝对接开源与自研的所有计算引擎。同时，所有 API、SDK 和对接开源引擎的客户端已经在阿里云上开源，支持客户自研引擎、应用或系统集成。数据湖统一元数据与权限 17 另外，依托于底层存储的表格存储，面向海量结构化提供的 service 服务有着非常优秀的弹性伸缩能力，无需担心扩展问题。同时提供了高可用、免运维的能力。此外，提供统一的权限控制，用户只需依靠权限的配置，无论在 EMR 引擎上、阿里云的自研引擎上，还是在 DataWorks 等数据开发平台上，都可以实现多引擎、多管理平台或多应用的统一权限管控。能够支持阿里云 RAM 以及开源 LDAP 账号体系。统一元数据服务的最下层是数据湖存储，目前支持对象存储和文件存储。数据服务层提供了两个基础服务：第一层是 catalog，负责管理元数据，包括 Catalog、Database、Function 和 Table；第二层是权限服务，包括 ACL 体系、RBAC 和 PBAC，TBAC 正在计划中（主要针对资源包）。再上层对接阿里云网关认证体系，支持 RAM 的子账号鉴权以及权限策略，可以实现底层元数据 API 和权限 API，之上提供了 SDK 插件体系。有的云厂商保留了所有组件，在 Hive Metastore 内部进行封装来实现开源的无缝对接。其优点在于只需改动Hive Metastore，其他的引擎都能自动对接到 Hive Metastore 上。而阿里云没有选择 Hive Metastore 方案，主要出于以下几个考量：首先，保留 Hive Metastore 会带来一定的成本，所有请求都需要进行转发，会导致性能损耗。同时，Hive Metastore 本身的稳定性会影响整体元数据服务的稳定性，而且随着用户集群流量的增大，Metastore 也需要扩容。因此阿里云选择了在轻量级 SDK 上实现 client 接口并直接嵌入到引擎中，实现开源引擎到 DLF 服务的对接。阿里云自研的引擎 MaxCompute、Hologres 以及全托管的 OLAP 引擎也已经完全对接 DLF。另外，用户的元数据管理应用或开发平台也可以对接 API。数据湖统一元数据与权限 18 很多用户内部的元数据管理应用通过 JDBC 的方式连接底层的 MySQL，而这也可能存在问题。比如底层元数据结构的升级会导致应用也需要改动。另一方面，直接对接 JDBC 接口查询底层数据，完全没有权限控制。但是如果对接 DLF API，无论是 API访问还是 EMR 访问，都会经过一层权限的控制体系，不会泄露权限。2.阿里云上数据湖统一元数据基本功能及优化 阿里云提供了多租户和统一的数据目录，是以阿里云账号进行租户之间隔离的一种机制。阿里云账号下可以创建多个 catalog，提供了 table 级别的 schema 多版本，可以根据版本数据查询 table schema 的演变过程。同时阿里云内部各引擎通过支持 DLF，也同时实现了 Iceberg、Hudi、Delta 数据湖格式打通。此外，在 catalog 上会按租户的元数据做分区，用户的存储不会打在同一个后端存储的热点分区上。同时，我们实现了 ID 化，方便后续进行软删除、异步删除等优化。同时，在很多请求上实现了异步化。IO 方面也进行了部分优化。比如做 List partition 时，返回的是同一个表 partition的所有元数据，而在大多数场景上 partition 元数据的 SD 都相同，因此完全可以基于相同的 SD 做共享，进行 partition SD 压缩，减少网络层的 IO。数据湖统一元数据与权限 19 3.阿里云上数据湖统一元数据之稳定性机制 稳定性是另一个比较关键的问题。在云上需要对接所有租户，因此元数据服务的升级、灰度、自动恢复能力非常重要。自动恢复能力和弹性伸缩是云上的标配，都是基于资源调度系统实现。稳定性机制的底层是阿里云 Table Store，上层是元数据服务。元数据服务有两个常驻集群 A 和 B，互为主备关系。在做升级时，将备服务配置为灰度状态，前端网关根据服务的配置策略以及租户分桶策略采集流量，然后发到灰度服务上，观察灰度流量是否正常，如果正常则升级到主服务；如果出现问题，则根据配置回滚即可。升级对用户侧、引擎侧完全无感知。即使是服务下线，也会等到主服务的流量归零才下线，这一层依赖于元数据自己的网关，因此可以实现得更为轻量，比如可以通过切断心跳的方式实现下线。三、阿里云数据湖统一权限服务 实现数据湖统一权限服务，首先要解决两个问题：身份的问题、API 和引擎的访问权限一致性问题。下图为数据湖统一权限架构图。底层为湖上数据及元数据，上层为数据湖统一鉴权服务，包括网关、用户模型转换、引擎的鉴权插件体系和 DLF 数据访问服务端鉴权。最上层是已经实现以及进行中的数据湖格式、开源引擎、数仓、数据湖构建平台以及应用。数据湖统一元数据与权限 20 目前，我们提供了 ACL 和 RBAC 和 PBAC 三种权限控制相结合的方式，ACL 和 Policy互相补充。其中 ACL 模式依赖于授权的主体和客体，因此主客体必须存在，支持白名单授权。Policy 同时支持白名单和黑名单。数据湖统一元数据与权限 21 引擎侧与 API 侧如何实现统一的鉴权？如果是用户持有 AK 或在外部操作上使用管理平台，则该层级全部通过 DLF SDK/API，在服务端元数据访问时会调用底下的鉴权引擎。如果是 EMR 开源集群，用户通过 beeline 接口方式、通过 LDAP 认证，再通过 Spark ThriftServer 获取元数据。引擎会持有可信的身份，经过可信身份校验后引擎可以获取所有元数据，再由引擎负责用户模型的转换，获取用户的操作与身份，代理用户鉴权，将相应的鉴权请求发到服务端，调用同样的服务端鉴权逻辑，最终实现引擎侧和 API 层的统一鉴权。四、数据湖元数据与权限展望 未来，数据湖元数据与权限将在统一、一致性和性能三个方面持续演进。统一元数据、权限、生态：云上的元数据目录及集中式权限管理将会成为标配，引擎、格式和各生态组件、开发平台对于元数据、权限的支持具备一致性。此外，支持非结构化、机器学习场景元数据模型自定义，这样其他类型的元数据也可通过自定义的方式接入到统一的元数据体系中。元数据加速：比如针对数据湖格式推出定制元数据 API，为计算层提供给更多面向性能优化的方案。更灵活的权限控制及更安全的数据访问：用户可以自定义角色权限、操作权限。另外数据存储也可以实现加密，当然这一切都会管理在统一元数据服务侧。数据湖管理及优化 22 数据湖管理及优化 作者：杨庆苇，阿里云开源大数据高级开发工程师 一、数据湖元数据仓库介绍 数据湖的实践过程中，我们面临了诸多挑战：第一，数据难以识别和查找。数据湖内存在大量未被有效识别的数据，可能是历史遗留或未被管理的数据，比如通过文件拷贝上传或其他工具引擎写入湖内的数据。其次，传统元数据服务里缺乏有效的检索服务，数据增长到一定规模时，很难从大量元数据中搜索和定位到特定场景下的数据。第二，数据资产管理能力弱，湖上缺乏有效的数据资产分析和优化工具，难以精细化掌握库、表分区级别的数据明细。对schema维度存储分层方案落地困难，数据冷热难以辨别，无法在库、表分区维度实现分层。第三，湖格式优化缺乏系统的解决方案。比如小文件合并操作需要用户对湖格式有一定的了解，能主动发现部分 schema 存在不合理的小文件，且利用计算引擎运行小文件合并任务，存在一定的使用门槛。此外，需要用户能够识别无效的历史数据以对其进行清理。为了解决数据湖实践过程中遇到的挑战，综合湖上数据特点以及计算引擎特点，阿里云提出了基于元仓数据底座，以云原生资源池的海量计算能力为基础，结合管控的在线服务能力，为用户提供全托管的湖管理和优化的解决方案。1.数据湖元数据仓库架构 元仓组成湖上元数据以及分析和计算数据，为湖管理和优化提供了参考指标。经过数据采集、ETL、数据分析、计算等过程，将湖上分布在各处的数据进行整合，提取出有意义的指标，构建出分析库、指标库和索引库，为上层应用提供数据支撑。数据湖管理及优化 23 上图右侧是云原生计算池，通过 Spark 引擎利用云上的可伸缩资源运行 Analyze、Indexing、Compaction、Tiering 等分析和优化任务，并实时将计算结果写回元仓，参与指标库与索引库的建设，丰富和扩展元仓的指标资产，如在计算池内运行 stats任务、获取表行数大小等指标，并回写到元仓指标库，用户可在第一时间查看表的基础信息，并以此为参考做数据质量分析等操作。管控层提供用了在线服务能力，如在线目录、检索服务、指标服务等，优化引擎负责分析元仓上的指标，并依据规则生成优化任务提交给云原生计算池进行计算。在此之上延伸出了很多湖管理优化的能力：数据湖管理及优化 24 元数据能力：解决了数据难以识别和操作的问题。比如针对元数据检索，通过建立检索库，快速搜索元数据以及相关的 schema 明细。元数据发现通过云原生池计算运行任务提取元数据信息，有效识别湖内未知数据。存储优化能力：解决了数据资产管理能力弱的痛点。比如存储统计分析，通过元仓的指标库分析库、表分区级别的数据明细、冷热分层，通过指标库提供的表分区，最近访问时间、访问频率、冷热指标对表分区自动分层。查询优化能力：如小文件合并，通过指标库提取出小文件表和分区信息，根据规则在云原生资源池上运行小文件合并任务。此为全托管过程，用户侧无感知。湖格式管理优化：实现了元数据加速和自动优化。以上方案解决了数据湖管理与优化的部分问题，帮助用户更好地使用和管理数据湖。2.数据湖元数据仓库建设 湖上元仓的原始数据由三类数据构成：存储数据：文件级别的 OSS 存储数据信息，包括大小、存储路径、存储类型、最近更新时间等，均来自存储访问日志和明细清单，这些基础数据构成存储属性的元数据，是分析和管理对象存储的基础。元数据：描述目录、库、表、分区、函数等的数据，包括索引、属性、存储以及 stats 的统计数据。主要来自于引擎元数据服务存储以及 stats 的计算扩充，是大表治理、小文件合并等优化操作的基础数据。引擎行为数据：包括血缘数据、引擎任务执行数据，比如文件大小、文件数、任务上下游依赖信息数据。这些数据在引擎计算时产生，是建设数据地图、生命周期管理的基础数据。数据湖管理及优化 25 以上数据经过日志服务消费、Spark批任务、离线同步、Spark Structured Streaming、流任务实时消费等方式集成到元仓，作为元仓的原始数据。元仓选择 Hologres 作为存储库，因为 Hologres 对于海量数据的实时写入、实时更新、实时分析能提供较好的支持。对于实时性要求不高，但有较大数据量分析的场景，比如库表存储分析，可以通过MaxCompute 离线数据加工的方式，将原始数据转换成明细数据，并提供离线指标给管控层；对于有较高实时性要求的场景，比如获取表分区行数、执行更新时间等，通过 Hologres 实时分析能力，实时计算出分析指标，并提供给 DLF 管控。元仓包含了实时和离线场景，为数据湖管理和优化提供了稳定、高质量的数据基础。二、阿里云 DLF 数据湖管理与优化 1.元数据检索 元数据检索解决了数据湖上数据难以查找的痛点。主要提供了两种搜索方式，一是全文检索，通过对元数据所有列属性建立索引，满足对任意单词的搜索都能在毫秒级别内做出响应；二是提供了多列精确查询，满足在特定条件场景下的搜索，比如按库名、表名、列名、Location 地址、创建时间、最后修改时间等特殊属性精确匹配搜索。索引库选择了阿里云 Elasticsearch 方案。ES 是实时分布式的搜索与分析引擎，可以近乎准实时地存储、查询和分析超大数据集，非常适合元数据的实时搜索场景。为了达到搜索结果秒级延迟的效果，我们选用 Spark Streaming 流技术，实时同步和解析引擎生产的 DML 日志写入 ES 库。数据湖管理及优化 26 但消费日志存在着两个天然的问题：一是消息的顺序性，无法保证顺序产生的 DML事件能被顺序地消费并写入 ES 库；二是消息的可靠性，日志服务无法保证集群日志能够百分百被捕捉并写入到 hub。为了解决上述痛点，一方面会通过消息内的最近更新时间做判断，逻辑上保证了消息的顺序性；另一方面，通过每日的离线任务同步元数据库做索引补偿，保证了每日元数据信息的可靠性。通过流技术、离线补偿技术、ES 检索能力，实现了湖内从大量元数据中快速搜索和定位的能力。2.数据资产分析 1)分析维度 湖上资产分析能力能够更高效、简洁地帮助用户分析和管理湖上资产，包含了资源统计、趋势变化、存储排名、存储分层。数据湖管理及优化 27 资源统计提供了总存储量、总库表数量、API 访问信息总量，为用户提供了直观的数据感受，对湖上资产进行全局把握。趋势变化反映了上述统计指标近 7 天、30 天和 1 年的增减变化。通过数据波动能够发现业务的发展状态，比如判断某业务近期的发展态势，并根据态势调整资源投入。存储排名反映了库表在一定范围内的排序情况，用户可以根据这一排名发现表的数据成本问题，比如 80%的存储集中在 20%表里。存储分层描述了对象存储上存储类型的分布情况、存储格式分布情况以及大小文件分布情况。通过分布情况判断当前数据分层是否合理。以上分析数据一方面能够帮助用户更好地理解和掌握湖上资产，另一方面为用户管理和优化湖数据提供了事实依据。2)数据模型 资产分析的模型建立遵循数仓的分层范式，从下至上分别为源数据层、数据公共层、数据应用层。OSS 存储的日志、明细数据、元数据和审计数据通过离线任务同步至元仓 ODS 层，然后通过离线加工计算出公共层数据，包括元数据、维表、文件存储、明细表、库表汇总等，然后根据业务需求将公共数据加入到应用数据并输出给管控，最后进行报表展示。数据湖管理及优化 28 3.库表维度精细化分析-DataProfile DataProfile 模块在库表元素之上，增加扩展了 stats 指标。stats 是引擎对于表的统计信息，包括表的记录数、表大小、文件数量等基础数据。在此基础上做了 stats 扩展，包括小文件数据、小文件占比、冷热度、分层信息指标等。由于数据湖对接多种引擎，Spark、Hive 等。每种引擎 stats 计算结果都无法保证全面准确，且触发条件不一致，指标的覆盖度较低。默认情况下，如果分区表的记录数、大小文件指标覆盖度不足 20%，则无法直接使用元数据 stats 指标。因此，我们通过主动提交 stats分析任务，帮助用户计算表的 stats 数据。首先，引擎做 DML 任务后会产生一个事件，元仓记录这一事件，stats 集群实时消费 DML 事件，并拉起对应的 stats 分析任务，同时扩展了 analyze 命令，支持小文件数量、数据分层占比等分析指标。整个 stats 集群运行在云原生资源池内，为避免元数据服务与业务库的冲突，任务运行完成后会实时写入指标库。上述方案补充了云原生计算引擎 stats 数据覆盖准确度不高的问题，为表分析和优化提供了基础数据。Stats 能为管控页面提供库、表分区级别的明细数据，也能为其他优化引擎提供数据支持，比如分析表的小文件数量指标进行小文件合并，同时也能服务多种引擎做 CBO 优化。数据湖管理及优化 29 4.生命周期管理 生命周期管理模块能够对 schema 维度存储分层，有效地帮助用户降低存储成本。OSS 对象存储提供了文件级别的分层能力，OSS 不同存储类型价格不同，由热到冷分别为标准、低频、归档、冷归档，成本依次递减。基于此能力，可以将不常使用的数据冷冻，待使用时再解冻，以此降低存储成本。基于 OSS 的分层能力，结合引擎元数据，提供库表分区粒度的生命周期管理能力，根据规则对表和分区进行冷冻或解冻，以此降低用户对数据湖内冷热分层的使用门槛。规则中心通过元仓提供的指标制定，包括最近修改时间、创建时间、分区值、访问频率等指标，其中访问频率由分析引擎任务明细产生，通过 hook 的方式采集 Spark或 Hive 执行任务时的任务明细，经过计算加工提取访问频率和最近访问的时间冷热信息。最近修改时间、创建时间分区值等基础指标由元仓计算而来。决策中心定期触发规则判断，在满足规则的情况下会产生归档任务，由任务中心实行。整个任务中心通过分布式调度，定时或手动执行解冻或归档任务，利用 JindoSDK的高并发、高稳定特性，执行目录级别的文件归档操作。生命周期管理过程对于用户而言十分便捷，用户无需操作 OSS 文件，极大提高了用户对湖上数据的分层管理能力。以上为阿里云数据湖团队在数据湖管理优化过程中的实践，在实际应用过程中，帮助客户优化存储成本的同时，提高了数据的使用效率。基于 EMR 的新一代数据湖存储加速技术详解 30 基于 EMR 的新一代数据湖存储加速技术详解 作者：孙大鹏，阿里云开源大数据平台数据湖存储团队 一、背景介绍 大数据行业蓬勃发展，主要源自于通讯技术的发展，全球数据规模，预计 2025 年将增长到 163ZB，相当于全球 60 亿人，平均每人 27TB 数据。数据量爆发式增长，使得企业拥有了更多数据资源。更多数据意味着需要更大的存储。此外，数据本身极具价值，因此要挖掘数据价值并进行充分利用，以此反向推动业务的发展和改造。基于 EMR 的新一代数据湖存储加速技术详解 31 大数据技术的发展趋势是云化、轻量化、服务化。数据湖、与云融合、实时计算已经成为大数据领域的关键词。存算分离概念在云计算早期已被提出。存储与计算耦合的自建平台会造成额外成本，且受限于本地网络带宽。有了云计算以后，网络带宽得到了很大缓解。可以按量收费，提供服务化、容器化的能力，更好地做运维开发。1.业界存储架构演进 早期的大数据基于 HDFS 构建数仓。HDFS 是非常好的分布式存储选型，单集群可稳定支撑到 4-6 亿文件规模，数据量可达 100 PB。但是 HDFS 运维成本比较高，存储作为基础组件，一旦存储出现问题，则意味着整个业务被中断。此外，达到 4-6亿文件规模，100PB 数据量后，再进行扩展则会出现问题。因此，社区提出了 HDFS Federation 方案。将 HDFS 集群进行扩展，并将业务进行拆分，大业务可以独立使用一组 NameNode，可突破单组