Goods: Organizing Google's Datasets[4]

[egolearner]

论文

google在16 SIGMOD的论文。
https://dl.acm.org/doi/10.1145/2882903.2903730

1 引言

通过允许工程师和数据科学家不受限制的消费和产生数据集，企业鼓励快速开发、实验最终籍由创新赢得先机。

两种形式：

• 企业数据管理(EDM) 数据集的owner需要主动做集成，通过EDM系统做发布、检索和集成。
• owner完全自由的访问和产生数据集，事后解决找到正确数据的问题。

GOODS采用的是后者，在后台以非侵入的方式收集数据集的元数据和使用信息，使得工程师可以方便的组织和查找数据集。
Goods不断地爬取不同的存储系统和生产系统日志，以发现存在的数据集和收集元数据信息（如owner、访问时间、内容特征、访问的流水线）。即使团队的数据集在不同的存储系统中，工程师也能够得到统一的视图和依赖关系。Goods能够监控数据集，并发出报警。 Goods提供的另一重要信息是数据集的血缘。Goods给数据集的消费者提供了搜索引擎，可以搜索整个公司的数据集，提供了面信息(facet)帮助减少搜索结果和找到最新和最重要的数据集。Goods为数据集提供了profile页面，展示schema和自动生成查询的代码，还包括了和当前数据集相似的数据集。 Goolds允许用户以众包的形式补充元数据信息：owner可以进行标注；数据集审计师可以可以打标敏感信息以提醒owner或者要求做安全审查。

2 挑战

2.1 数据集的个数和规模

Google工程师全部可读的就有260亿个数据集，全部数据集估计会翻倍。数据集的规模带来n^2问题，比如计算相似度的时候。

2.2 多样性

许多种存储格式和存储系统。

2.3 翻腾的新数据

数据集不断地被产生和删除。临时数据集对数据集的血缘提供了关键信息。

2.4 元数据发现的不确定性

因为以事后的方式处理数据集，带来不确定性，比如数据可能是不同的pb类型，以近似的方式来推断字段是否是主键。

2.5 计算数据集的重要性

数据集的重要性难以判定。唯一的明显连接是血缘信息，但并不代表重要性。

2.6 恢复数据集的语义

从原始数据中确定语义对于小规模的数据集是复杂问题，对于大数据集难上加难。

3 Goods catalog

Goods catalog对每个数据集包含一条数据，并将相关的数据集分组为cluster，可以用于优化元数据的计算，基于cluster下的数据集有相似的属性的假设。

3.1 元数据

Goods从存储系统中获取基本的元数据，如大小、owner、读者、访问权限等。此外，从日志中做了元数据推断。

• 基础元数据。时间戳、文件格式、owner、访问权限。
• 血缘。 数据集如何被产生，如何被消费，依赖和被依赖的数据集。基于此产生连接图，牺牲完整性获取效率，只会包含日志中数据访问事件的部分样本，只固化几跳的上下游关系。
• Schema。从代码库中拿到pb列表，选一些记录来依次匹配，会匹配到多个pb，所有的候选pb和其heuristics score都作为元数据的一部分。
• 内容摘要。采样内容记录频繁的token。通过分析其中的字段确定是否包含独立或合并主键。收集包含单个字段校验和locality-sensitive hash的指纹信息，找到相同或类似的数据集或数据集的列。
• 用户提供的注解。
• 语义。对于pb定义的数据集，抽取注释。将数据集的内容和Google的Knowledge Graph做匹配，以确定字段中的实体。

  3.2 组织数据集为聚类

  聚类是为了降低计算成本，聚类本身需要廉价，不能通过访问内容确定。通过数据集的路径来确定聚类，如把日期或月份做抽象。 通过沿不同的维度构成层次，构成了granularity semi-lattice的结构，每个节点对应了查看数据集的不同粒度。 图 table-3

如果聚类中的几个成员schema相同，我们将schema传播到整个聚类，goods采用的是按需计算的方式以区分传播得到的元数据和真实分析得到的元数据。

4 后端实现

4.1 catalog存储

使用bigtable存储，每行代表一个数据集或数据集聚类，其路径作为key。其中使用了bigtable的按行事务一致性。Goods将只有batch jobs使用的数据放到专门为batch调优（高度压缩、不驻内存）的列族中。 存储两类元数据：

• 数据集的元数据
• 处理数据集的modules的状态元数据，如时间戳、成功状态、错误信息。使用状态元数据来同步modules的运行和做系统的探查。

  4.2 batch job的性能和调度

  将Job调度到地理上靠近数据集的机器上。 使用状态元数据做同步，比如A必须在B之前跑，B会检查A是否访问过，如果没有的话B会跳过，下次运行时再重试。如果A重新处理了一行，B下次运行时也会重新处理。modules还会使用自己的状态元数据来避免在可配置的新鲜度时间窗内重复处理行。 大多数job每天运行，在24小时内处理完成，超出后进行优化或增加并行。在引入新数据集时，最重的schema分析器需要几天甚至几星期才能赶上，goods启发式地将将带用户标注或血缘高向心性的数据集标记为“重要”，同时启动两个job：一个job只处理重要数据集可以很快处理完，另一个job处理所有数据集在一天结束时只能处理一小部分。对大多数使用场景，保证头部重要数据集的覆盖和新鲜度就足够了。

  4.3 容错

  状态元数据中记录module的错误信息，会触发有限的重试。血缘连接module仅当连接的时间戳比上次成功运行更新时才会合入连接图中。 处理的库有可能崩溃或者死循环，将这些潜在的危险任务在单独的沙箱进程中运行，使用watchdog将长时间的停顿转为崩溃让流水线得以继续。

  4.4 元数据GC

  1. 移除行的条件使用声明式的断言，其中既使用元数据又使用其他访问或更新的modules的状态。
  2. 从catalog中删除项时避免产生“悬空行”。
  3. 其他module需要能和GC独立和同时运行。

最终设计允许除GC外的所有modules操作非事务更新，采用两阶段的方式：阶段1，使用声明式的断言标记要删除的行；阶段2，24小时后如果行依然满足删除条件则删除，否则去除标记。 所有其他modules满足下列限制：

• 能够做非事务更新
• 忽略GC标记的行
• module单次迭代不超过24小时

5 前端：catalog服务

5.1 数据集profile页

数据集或聚类的路径作为输入，从catalog中存储的元数据产生HTML页面。为了防止展示的信息过多，对血缘信息做了压缩，如果压缩后仍然更多的话，则只展示最新的项。 数据集的profile页与更专门化的工具互相连接，如血缘元数据指向产生数据集的job的详情页，schmea元数据指向代码管理工具。反过来这些工具也会指向goods。 profile页还包含了不同语言的访问代码片段。 profile页的目的是提供一站式的商店，让用户可以探查数据集的信息，理解数据集使用的上下文信息。

5.2 数据集搜索

用户可以用简单的关键字查询数据集，关键字可以只命中索引的一部分，如查询path:x。用户可以指定部分路径。搜索之后采用启发式的方式对数据集排序。

• 数据集的重要性取决于其类型，如Dremel表被认为很重要。
• 关键词的重要性取决于其命中的索引部分，如命中路径比命中读写数据集的job重要。
• 血缘扇出是数据集重要性的优良指示器。但是类似web爬虫类的任务天然有很多的消费者，但不代表重要，需要微调和控制这一条的权重。
• 包含owner标注的描述的数据集可能是重要的。

除了关键词搜索，goods提供了元数据切面，如owner或者文件格式。

5.3 团队dashboard

dashboard一站式的展示团队产生的所有数据集的有趣元数据，如各种健康指标、其他dashboard、数据集所在的存储系统是否在线。dashboard提供了监控和报警机制。

6 经验教训

• 且行且进化。数据集的catalog超出了原计划的使用用例，如下列趋势：审计PB、重新找到实验性的数据集、理解遗留代码、书签、标注数据集。
• 使用域相关信号做排序。几个例子是血缘、从其他团队数据集去范化(denormalized)的数据集、跨团队边界的使用。
• 预期和处理异常数据集。如异常日期、其他库的死循环。
• 按需导出数据。存储catalog的kv存储和搜索服务用的倒排索引都不适合做可视化或者做复杂的血缘路径查询。解决方式为导入图系统中。
• 保证可恢复性。除了使用bigtable保存几天的滚动窗口，还有定制化的恢复机制（对高价值的数据集做快照，复制catalog的子集，使用goods的数据集监控服务监控自身）。

8 结论和展望

• 如何对数据集做排序？如何确定重要的数据集？
• 不同团队提供不同的元数据，需要用其他的弱信号来补全数据集。
• 理解数据集中数据的语义对搜索服务至关重要。
• 将自动爬取数据集和主动注册数据集结合起来。
• 希望goods帮助刺激渗透数据文化

comment

• goods索引了google所有的数据，肇始时其他团队都来主动接入可行性不大，因此采用了自动爬取的方式。在google内部有足够影响力之后，新业务就愿意主动接入了，因此最后提到了自动爬取和主动注册相结合。仅为猜测。
• 统一代码库对schema的自动分析至关重要。
• 对于如何从内容中抽取元数据感觉语焉不详。