GOODS论文翻译
管理谷歌的数据湖：对GOODS系统的总览
摘要
对于当今的大多数大型企业而言，数据、代码、基础设施共同构成了他们的核心资产。对于大多数企业，他们近几年公司内部生产的数据量呈现爆炸性增长趋势。与此同时，大多数工程师和数据科学家并未使用中心化的数据管理系统，而是不自觉地构造了一个数据湖——一个未经管理或并未管理良好的数据集的集合体，每次使用都要去里面“打捞”（搜寻）相应的数据。本文中我们描述了我们如何搭建和部署GOODS的经历——GOODS是一个管理Google内部数据湖的系统。GOODS爬取Google的基础设施，并搭建一个囊括所有被发现的数据集的目录，包括结构化文本，数据库，电子表格，甚至是使用数据的服务。GOODS后验地抽取出数据集的元数据——工程师们持续地按照之前的方式生成和组织数据集，而GOODS在不影响这些团队工作的情况下为他们提供价值。我们面临的技术挑战来自于Google数据湖的规模和异构性，以及我们所选择的后验式抽取元数据方式（这是吐槽自己给自己挖了个坑吗哈哈，但我觉得这样不打扰数据工作者的既定工作方式的思路对于数据工作者有很大的便利性）。我们相信我们学到的经验教训对于构建一般化的大规模的企业级数据管理平台是非常有实际意义的。
1 .介绍
当今大多数企业见证了用于持续性的研究和开发的内部生产的数据量的爆炸性增长。背后的原因显而易见：数据工程师和数据科学家不受限制地生产和消费数据，企业推动的快速开发周期，实验，以及推动他们竞争力的创新。因此，内部生成的数据经常成为公司最宝贵的资产，与代码和基础设施具有同等的价值。
数据爆炸的另一面是产生了数据湖[1,2,6]：一个体量持续增长的内部数据集的集合体，几乎没有关于数据集的使用意图、价值、起源的编码化信息。这一信息的缺失是有问题的：数据被绑定在那些知道这个数据的起源的团队上（我的理解，也就是其他团队无法知道这些数据的具体来源，用途，价值等重要信息），这会造成生产力损失、错失良机、重复工作、错误地处理数据等问题。
这篇文章中我们详述了“谷歌数据搜索”（GOODS），一个我们搭建并部署了的系统，用于帮助谷歌工程师组织管理数据湖中的数据集。GOODS以后验方式运行：在数据集（被各种各样的管线）创建、使用、更新后，它收集并聚合数据集的元数据。换句话说，团队和工程师们可以用他们喜欢的工具持续地生成和使用数据集，而GOODS则在后台工作，以一种静默工作的方式收集关于数据集及其使用用途的元数据。接下来，GOODS使用这些元数据，为工程师们提供更符合规范的组织、发现数据集的服务。因此，GOODS与企业数据管理系统（EDM）不同，后者是一个需要数据集拥有者和消费者使用特定工具和API来使用数据的网关。
图1：谷歌数据搜索（GOODS）的总览。GOODS从各个存储系统收集了关于数据集的元数据，它会通过分析额外的信息源例如数据所有者和其项目的日志和信息，分析数据集的内容，收集GOODS用户的输入，来推断元数据、以及数据集与数据集之间的关系。收集到的元数据会助力面向用户的工具，也就是图中虚线框里的工具。
Figure1 展示了我们系统的图解。GOODS持续地爬取不同的数据系统和生产基础设施（比如 运行管线的日志）来发现哪些数据集存在，并收集每一个数据集的元数据（比如所有者，使用时间，内容特征，被哪些生产管线使用）.
GOODS把这些元数据聚合在一个中心目录中并把特定数据集的元数据与其他数据集的信息关联起来。之后GOODS使用这个目录为Google工程师提供数据集管理服务。囊括的服务如下：
•公司所有数据集的搜索引擎，包含缩小搜索结果范围的各个方面（？），以帮助工程师和分析师找到最相关的数据集。
•为每个数据集维护一个概述页面，用于呈现GOODS记录的关于特定数据集的元数据，从而可帮助用户理解数据集及其与公司其他数据集的关系。profile页面还集成了其他工具，这些工具可以进一步处理数据集，从而帮助用户对数据进行操作。
•一种监视服务，允许团队监视其拥有的数据集的特性，如数据集的大小、内容中值的分布或可用性。用户可以配置此监视服务，以便在特性被意外更改时发出警报。
•一种注释服务，允许数据集所有者或受信任的主体(例如，数据图书管理员或数据管理团队)使用特定领域的注释扩展数据集的元数据，这些注释可以出现在配置文件页面中。例如，数据集所有者可以为数据集的内容提供文本描述，或者附加的(可以为其他数据使用者提供信息的)数据可视化结果。
搜索是GOODS中最常用的服务，它展示了对数据湖中数据集的探索结果。然而，我们已经看到了对其余服务的良好采用。我们还惊喜地发现，团队将产品用于我们最初没有预料到的场景:
•模式审查
一个团队使用搜索来识别其他团队拥有的数据集，这些数据集符合这个团队的特定模式。然后，这个团队审计结果数据集，以确保使用模式符合其规范。
•通过来源发现数据
GOODS的中心目录包含来源元数据，其形式为“数据集Y由生产作业X读/写”。 这些信息，特别是来源链的可传递性闭包，对于理解数据集的血缘和它的下游依赖关系是很有用的，因此在每个数据集的配置页面中显得尤为重要。一个团队发现了这些来源链的新用法，并使用它们进行数据集发现。具体地说，机器学习团队希望使用被公开为某些领域规范的数据集，但是他们发现这些数据集对机器学习来说“修饰过度”了。为了克服这个问题，团队依赖于来源链来浏览上游并识别用于派生规范数据集的数据集。这些原始数据集包含较少修饰的数据，更适合于特定的机器学习任务。
•内容可视化
一个技术基础设施团队使用注释服务将可视化结果附加到表示ML管道训练数据的数据集。这种可视化显示了训练样本的特征的统计信息，展示在数据集概要页面上，以帮助用户理解特征的分布和发现可能影响机器学习模型质量的异常情况。
本文的其余部分将描述我们开发GOODS的经验。首先，我们要确定在google构建一个包含200多亿数据集的数据湖管理系统时必须解决的关键挑战。我们在GOODS上遇到的许多挑战都是由谷歌数据湖的规模和特点造成的，但我们相信这些经验和教训将适用于其他企业的类似系统。然后，我们将介绍用于组织数据湖元数据的逻辑结构，我们使用实体(数据集、团队、项目等)之间的关系来组织这些元数据。我们认为，这个组织（或者说上文提到的逻辑结构）受到结构化知识库及其在Web搜索中的应用的启发，可以帮助回答有关数据湖内容的重要问题。然后，我们简要回顾了我们在开发产品时所解决的一些与系统相关的技术问题，最后根据我们在当前系统部署方面的经验，提出了一些未来工作的方向。
2.管理和组织企业数据湖的挑战
在设计和制造GOODS时，我们遇到了很多挑战。在本节中，我们将重点介绍并详细说明一些重要的挑战。更详细的挑战列表可以在我们之前的工作[5]中找到。
2.1组织数据湖
正如我们所讨论的，数据湖管理系统的主要目标是为其中的数据集收集元数据。我们可以以独立的眼光看待每个数据集的元数据。然而，我们发现，考虑如何整合元数据以揭示数据集之间的关系，这一方法更为强大。识别和推断这些关系有助于解决我们刚刚描述的一些可伸缩性/可扩展性（什么是扩展性问题？ 如果你的系统对一个用户来说是快的，但是在用户不断增长的高访问量下就慢了。）挑战。此外，它帮助我们组织数据湖中的数据集，从而为用户提供对数据湖内容的更好理解。
例如，考虑对数据湖的以下查询:“查找项目X某一数据集所衍生出来的所有数据集。”这个查询可以帮助评估X项目的影响，或者确定需要向哪些团队通知：“我们即将清除X拥有的数据集”。回答这个查询需要了解不同团队的组成、数据集的所有权和来源关系。另一个有趣的查询是“查找使用特定版本方法X的代码的生产作业所编写的所有数据集”，这可以帮助识别可能受到错误代码影响的数据集。同样，回答这个查询需要了解几种类型的关系，包括来源、生产作业中的二进制文件的版本以及源代码到二进制文件的链接。
为了支持这种功能，我们首先要确定哪些类型的关系是存在的，其中又有哪些是我们能有效确定的。我们已经确认的所有挑战仍然存在。数据集规模大，意味着我们不能执行穷举搜索来识别这些关系。例如，虽然知道哪些数据集或数据集的某些部分具有相同的内容是很有用的，但是我们不能将每一对数据集相互比较。还有，因为我们以一种事后的方式构建产品，我们需要理解基础设施的哪些信号可以帮助发现这些关系。例如，为了识别数据集之间的来源关系，我们可以将生成数据集的不同作业的日志用于连接不同数据集的目录。然而，由于这些资源来自不同的团队，因此它们通常使用不同的命名模式、不同的粒度级别来定义数据集或包含的内容，等等。
2.2元数据提取工作的可伸缩性/可扩展性