数据湖元数据服务的实现和挑战

大数据引擎的现状

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

数据湖元数据服务的设计

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

提供统一权限、元数据管理模块：统一的权限/元数据管理模块是各类引擎和存储互通的基础，不仅权限/元数据模型需要满足业务对于权限隔离的需要，也需要能够合理支持目前引擎的各种权限模型。

提供大规模元数据的存储和服务能力，提升元数据服务能力极限，满足超大数据规模和场景

提供存储统一的元数据管理视图：将各类存储系统（对象、文件、日志等系统）上数据进行结构化既能够方便数据的管理，也因为有了统一元数据，才能进行下一步的分析和处理。

支撑丰富的计算引擎：各类引擎，通过统一元数据服务视图访问和计算其中的数据，满足不同的场景需求。比如PAI/MaxCompute/Hive等可以在同一份OSS数据上进行计算和分析。通过引擎支撑的多样化，业务场景将越来容易进行场景转换和使用。

元数据操作的追溯/审计

元数据自动发现和收集能力：通过对文件存储的目录/文件/文件格式的自动感知，自动创建和维护元数据的一致性，方便存储数据的自动化维护和管理。

数据湖元数据服务的架构

元数据服务上层是引擎接入层

通过提供各种协议的SDK和插件，能够灵活支撑各种引擎的对接，满足引擎对于元数据服务的访问需要。并且通过元数据服务提供的视图，对底层文件系统进行分析和处理。

通过插件体系无缝兼容EMR引擎，能够使EMR全家桶开箱即用，用户全程无感知，即可体验统一元数据服务，避免原Mysql等存储的可扩展性差的问题

元数据服务提供存储视图

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

元数据的管理和自动发现

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

Web Console、Sdk、各类引擎客户端和接口

1.兼容开源生态引擎的各类数据库/表/分区上的DDL操作。

2.提供多版本元数据管理/追溯的能力

3.通过元数据能力的开放，在ETL部分/开源工具部分将来也能通过各式插件进行对接，进一步完善整体生态

元数据自动发现

元数据自动发现能力是元数据管理能力的另一核心部分，能够自动收集各处文件系统散落的数据，极大了拓宽了统一元数据服务的场景，节省了管理的代价和复杂性。这其中的能力包括

1.自动分析目录层次，动态增量创建database/table/partition等元数据

2.自动分析文件格式，对于各类格式比如常规文本格式及开源大数据格式parquet、orc等都进行了支持

元数据服务的未来

数据湖元数据服务为大数据而生，为互通生态而生，期望后续继续完善其服务能力和支撑更多的大数据引擎，通过开放的服务能力、存储能力、统一的权限及元数据管理能力，为客户节省管理/人力/存储等各项成本，实现客户自己的业务价值。

• « 上一篇：Webpack基本使用
• » 下一篇：线性表顺序表示和实现（C语言)