Goods：组织谷歌数据集的系统

论文地址： Goods：组织谷歌数据集的系统 Havely et al. SIGMOD 2016

你可以试着建一座数据大教堂。或者你可以建立一个数据集市。在data cathedral，我指的是一个集中的企业数据管理解决方案，公司中的每个人都会购买并敬仰它，每次他们想发布或检索数据集时，都会向EDM致敬。另一方面，数据集市放弃了有预谋的集中控制：

另一种方法是允许企业内部完全自由地访问和生成数据集，并解决以事后方式查找正确数据的问题……在本文中，我们描述了Google数据集搜索（Goods），我们构建这样一个后自组织系统是为了组织在Google中生成和使用的数据集。

公司内的每个人都在使用他们喜欢的任何方式创建和使用数据集，而Goods则在后台工作，以找出哪些数据集存在，并收集关于它们的元数据。换句话说，（惊讶！）谷歌建立了一个爬行引擎……事实证明，这并不是一个容易的问题（首先，目前的目录索引超过260亿个数据集——而这些数据集的访问权限使所有谷歌工程师都能读取）。作为理解数据存在于何处及其来源的问题的一种方法，我发现，与企业内部为严格的中央控制而不断失败的斗争相比，商品具有极大的吸引力。

让我们首先检查一下构建数据集市的好处，然后深入了解一下如何进行数据集市的一些细节。

为什么要建立一个数据集市？
以下是Goods体系的鸟瞰：

Goods从Google的所有地方抓取数据集，从中提取尽可能多的元数据，将其与从其他来源（如日志、源代码等）推断的元数据结合起来，并将此目录提供给Google的所有工程师。货物很快就变得不可或缺了。作为对我们上周所看材料的一个很好的补充，我们举了一个在NLU工作的团队的例子：

Goods使用这个目录为Google工程师提供数据集管理服务。为了说明由商品驱动的服务类型，设想一个团队负责开发文本语料库（比如，新闻文章）的自然语言理解（NLU）。团队中的工程师可能分布在全球各地，他们维护多个管道，为不同的文本语料库添加注释。每个管道可以有多个阶段，根据各种技术（包括短语组块、词性标记和共同引用解析）添加注释。其他团队可以使用NLU团队生成的数据集，NLU团队的管道可以使用其他团队的数据集。基于其目录中的信息，Goods为NLU团队（在本例中为dataset producers）提供了一个仪表板，该仪表板显示其所有数据集，并允许按方面（例如所有者、数据中心、模式）浏览它们。即使团队的数据集位于不同的存储系统中，工程师也可以统一查看所有数据集以及它们之间的依赖关系。商品可以监视数据集的特性，例如数据集的大小、内容中的值分布或数据集的可用性，然后在特性意外更改时通知所有者。

Goods还跟踪数据集的来源，找出在创建给定数据集时使用了哪些数据集，以及哪些数据集在下游使用它。当弄清楚上游变化可能对问题负责，或者弄清楚正在考虑的变化的潜在后果时，出处可视化非常有用。这让我想起谷歌在其机器学习的自动功能管理系统中为跟踪“输入信号”（流和数据集）而建立的许多基础设施。

商品跟踪的全套元数据如下所示：

对于数据集消费者，商品提供了一种搜索机制，用于查找重要和/或相关的数据集。每个数据集都有自己的配置文件页，帮助用户了解其模式、用户、出处，并查找包含类似内容的其他数据集。商品系统允许用户提供自己的数据注释，这些注释也被索引。这一机制促进了在商品基础上的进一步应用。

数据集的配置文件页将一些元数据与其他更专业的工具交叉链接。例如，profile页面将源位置元数据（例如生成数据集的作业）链接到页面，其中包含以作业为中心的工具中这些作业的详细信息。类似地，我们将模式元数据链接到代码管理工具，这些工具提供此模式的定义。相应地，这些工具会链接回商品，以帮助用户获得有关数据集的更多信息。配置文件页还提供不同语言（例如，C++、java、SQL）的访问代码段，以访问数据集的内容。我们为特定的数据集定制生成的代码片段：例如，代码片段使用数据集的路径和模式（如果已知），用户可以在各自的编程环境中复制粘贴代码片段。
数据集的商品配置文件页已成为书签和共享数据集信息的自然句柄。例如，Google文件系统浏览器为目录中的数据集提供到商品页面的直接链接。

谷歌如何打造商品
在不依赖工程师协作的情况下以事后方式创建中央数据存储库的挑战是，您需要从多个信息源拼凑出整体难题—即使这样，您也可能永远无法确定。在Google scale上，有问题的数据集数量之多（26B+）意味着你需要对数据集的爬行和处理频率有一点了解。“即使我们在每个数据集上花费一秒钟（而且许多数据集太大，无法在每个数据集上一秒钟内处理），使用1000台并行机处理260亿个数据集的catolog仍然需要大约300天…”，数据集一直被创建和删除-目录中约5%（1B）的数据集每天都被删除。使用两种策略来帮助处理数据集的数量：一种双轨爬行和处理方法，以及数据集聚类。

双轨方法将某些数据集指定为“重要的”——那些具有高度出处中心性的数据集，以及那些用户已经努力提供自己的附加元数据注释的数据集。模式分析器的一个实例（管道中最重的工作）每天都在这些重要的数据集上运行，并且可以快速地通过它们。第二个实例处理所有数据集，但在任何给定的一天内可能只处理其中的一小部分。

在实践中，与Web爬行一样，确保重要性分布的“头部”具有良好的覆盖率和新鲜度对于大多数用户场景来说已经足够了。

对数据集进行聚类有助于减轻用户的认知负担，并降低处理成本。考虑每天生成并保存到eg./dataset/2015-10-10/daily_scan的数据集。通过提取日期部分，可以获得“每日扫描”文件的通用表示。这可以在商品中显示为一个顶级实体，还可以节省处理时间，例如假设序列中的所有文件共享同一架构。

通过沿不同维度组合层次结构，我们可以构建粒度半晶格结构，其中每个节点对应于查看数据集的不同粒度…表3（下面）列出了我们当前使用的抽象维度。

商品包含半格中每个最顶端元素的条目。这样可以避免出现太多的集群，并有助于保持集群集随时间的稳定。有些集群可能非常大！

Goods使用各种技术来尝试推断数据集的元数据。

由于Goods以一种事后的、非侵入性的方式显式地标识和分析数据集，因此通常不可能完全确定地确定所有类型的元数据。例如，许多数据集由其模式符合特定协议缓冲区的记录组成……Goods试图通过几个签名来揭示这种隐式关联：例如，我们将数据集内容与Google中所有注册的协议缓冲区类型“匹配”，或者我们查阅可能记录了实际协议缓冲区的使用日志。

出处元数据具有特殊的意义。它有助于理解数据如何在公司内部流动，如何跨越内部团队和组织的边界。出处是从生产日志中挖掘出来的，其中包含作业读写每个数据集的信息。为了便于处理，只对日志进行采样，并在几个跳上计算下游和上游关系，而不是完全传递闭包。
要查找与数据集商品关联的架构，需要查找用于读取和写入其记录的协议缓冲区。由于这些几乎总是检入Google的源代码存储库，Goods也会对代码存储库进行爬网以发现协议缓冲区。然后可以生成一个简短的协议缓冲区列表，该列表可以是匹配的…
我们通过扫描文件中的一些记录来执行此匹配，并检查每个协议消息定义，以确定它是否可能生成了我们在这些记录中看到的字节…匹配过程是推测性的，可以生成多个候选协议缓冲区。所有候选协议缓冲区以及每个候选的启发式分数都成为元数据的一部分。
为了方便搜索数据集，Goods还收集汇总数据集内容的元数据。
我们通过对内容进行采样来记录找到的频繁标记。我们分析一些字段，以确定它们是否包含单独或组合的数据键。为了找到潜在的key，我们使用HyperLogLog算法估计单个字段和字段组合中的值的基数，并将该基数与找到潜在密钥的记录数进行比较。我们还收集对单个字段和内容的位置敏感哈希（LSH）值具有校验和的指纹。我们使用这些指纹来查找内容与给定数据集相似或相同的数据集，或其他数据集中与当前数据集中的列相似或相同的列。我们还使用校验和来标识数据集的记录中填充了哪些字段。

在这篇论文中还有很多其他的实现细节，我想在这篇文章中集中讨论一个大的想法，因为我觉得它非常有说服力。作者认为，目前仍然面临的一个重大挑战是，改进数据集排名和确定重要数据集的标准：“我们从用户的反馈中知道，我们必须显著提高排名……我们需要能够区分生产和测试或开发数据集，在为许多其他数据集提供输入的数据集之间，在用户关心的数据集之间，等等。”

最后，我们希望像Goods这样的系统能够为今天的数据驱动型公司，特别是谷歌灌输“数据文化”提供动力。随着我们开发的系统使企业能够通过仪表盘、监控等将数据集视为核心资产，希望拥有与我们拥有的“代码规程”一样多的“数据规程”将变得自然