阿里云云原生数据湖体系全解读——数据湖构建Data Lake Formation_阿里云 数据湖 图表

大数据引擎现状

在大数据计算和存储领域， 因不同业务场景、 不同数据规模， 诞生了很多适合处理不同需求的各类大数据引擎， 比如计算引擎类有数据分析引擎 Hive、 交互式分析引擎 Presto、迭代计算引擎 spark 以及流处理引擎 Flink 等， 存储类有日志存储系统的 SLS、 分布式文件系统 HDFS 等， 这些引擎和系统很好的满足了某一领域的业务需求， 但也存在非常严重的数据孤岛问题： 在同一份数据上综合使用这些系统， 必然面临着大量的 ETL 工作， 而且更关键的是在目前各种公司业务链路上这种使用方式非常常见， 同时因数据加工、 转储产生的成本以及整体延时大大增加， 业务决策时间也相应变长， 解决这一问题的关键在于引擎元数据需要互通， 只有构建满足各种引擎需求的数据湖统一元数据服务视图， 才能实现数据共享， 避免其中额外的 ETL 成本以及降低链路的延时。

数据湖元数据服务的设计

数据湖元数据服务的设计目标是能够在大数据引擎、 存储多样性的环境下， 构建不同存储系统、 格式和不同计算引擎统一元数据视图， 并具备统一的权限、 元数据， 且需要兼容和扩展开源大数据生态元数据服务， 支持自动获取元数据， 并达到一次管理多次使用的目的，这样既能够兼容开源生态， 也具备极大的易用性。 另外元数据应该支持追溯、 审计， 这就要求数据湖统一元数据服务具备以下能力和价值：

• 提供统一权限、 元数据管理模块： 统一的权限/元数据管理模块是各类引擎和存储互通的基础， 不仅权限/元数据模型需要满足业务对于权限隔离的需要， 也需要能够合理支持目前引擎的各种权限模型。
• 提供大规模元数据的存储和服务能力， 提升元数据服务能力极限， 满足超大数据规模和场景。
• 提供存储统一的元数据管理视图： 将各类存储系统（ 对象、 文件、 日志等系统） 上数据进行结构化既能够方便数据的管理， 也因为有了统一元数据， 才能进行下一步的分析和处理。
• 支撑丰富的计算引擎： 各类引擎， 通过统一元数据服务视图访问和计算其中的数据， 满足不同的场景需求。 比如 PAI/MaxCompute/Hive 等可以在同一份 OSS 数据上进行计算和分析。 通过引擎支撑的多样化， 业务场景将越来容易进行场景转换和使用。
• 元数据操作的追溯/审计。
• 元数据自动发现和收集能力： 通过对文件存储的目录/文件/文件格式的自动感知， 自动创建和维护元数据的一致性， 方便存储数据的自动化维护和管理。

数据湖元数据服务的架构

元数据服务上层是引擎接入层：通过提供各种协议的 SDK 和插件， 能够灵活支撑各种引擎的对接， 满足引擎对于元数据服务的访问需要。 并且通过元数据服务提供的视图， 对底层文件系统进行分析和处理。通过插件体系无缝兼容 EMR 引擎， 能够使 EMR 全家桶开箱即用， 用户全程无感知， 即可体验统一元数据服务， 避免原 Mysql 等存储的可扩展性差的问题。

元数据服务提供存储视图：通过对不同存储格式/存储目录文件的抽象， 为引擎提供统一元数据服务， 同时能够避免多引擎独立使用元数据服务之间的不一致性。

元数据的管理和自动发现：元数据通过各种方式能够灵活的、 跨引擎管理元数据， 既能使用户方便的集成元数据服
务、 扩展元数据服务能力， 也能够降低管理成本。

• Web Console、 Sdk、 各类引擎客户端和接口：兼容开源生态引擎的各类数据库/表/分区上的 DDL 操作。提供多版本元数据管理/追溯的能力。通过元数据能力的开放， 在 ETL 部分/开源工具部分将来也能通过各式插件进行对接， 进一步完善整体生态。
• 元数据自动发现：元数据自动发现能力是元数据管理能力的另一核心部分， 能够自动收集各处文件系统散落的数据， 极大了拓宽了统一元数据服务的场景， 节省了管理的代价和复杂性。 这其中的能力包括：自动分析目录层次， 动态增量创建database/table/partition 等元数据。自动分析文件格式， 对于各类格式比如常规文本格式及开源大数据格式parquet、 orc 等都进行了支持。