• 摘要
○ 介绍GooDs
§ 重新考虑如何组织大规模的组织结构化数据集
§ 提取元数据的范围：从每个数据集中的显著信息到数据集之间的关系（个体信息到个体之间的关系）
§ 运用元数据提供数据集访问和操作的服务
○ 讨论需要克服的技术挑战
§ 爬取和推断数十亿的数据集的元数据
§ 维护元数据目录的一致性
§ 运用元数据为用户提供服务
○ 目标：对构建大规模企业级数据管理系统具有借鉴意义
1. 介绍
○ 大公司内部数据集暴涨
§ 原因：为了竞争优势，对数据集的滥用
§ 对于公司而言，数据集与源码、基础设施同样重要
§ 没有一个标准的数据集管理方法
§ 需要开发标准灵活的数据集管理方法
○ 企业数据管理方法
§ Enterprise Data Management (EDM)
□ 企业中组织数据集的常用方法
□ 生成数据集和管理数据集都在一套系统内
§ 事后（post-hoc）方法
□ 类似数据湖（data lade）的概念
® 数据累计成“湖”
® 访问数据就是从湖中钓鱼（“fish”the right datasets）
□ 采取事后的模式
® 不介入数据的生产和使用
® 为已经生成的数据提供管理工具
○ Google Dataset Search（GooDs）
§ 采用事后（post-hoc）方法
§ 维护一个数据集目录
□ 通过爬取数据集的信息来发现数据集并收集其元数据
® 元数据包括所有者、访问时间、内容特征、生产管道的访问记录等
® 借助额外的来源来推断元数据
§ 将有关的数据集和其元数据在目录中进行关联操作（不改变数据集本身）
§ 提供数据集的依赖关系（上游和下游数据集）
§ 允许用户通过众包的方式扩展目录
§ 用于搜索、监视、可视化数据流等
○ GooDs架构（图1）
§ 底层：持续的在不同存储系统中爬取数据集和数据集相关的元数据信息，此外还通过其他的来源来推断元数据
§ 中层：生成数据集的中央目录，将有关的数据集以及其元数据在目录中进行关联
§ 上层：提供搜索，监视，可视化数据流的服务
□ 显示数据集的上游数据集和下游数据集，当发现数据集存在问题时可以通过检查起源来确定是否是由于上游数据集的变化导致。同样的，团队想要对管道作出重大更改或者在已有数据集中发现bug时可以迅速通知下游
□ 提供仪表盘，用户可以获得数据集的统一视图和数据集的依赖关系，检测数据集的特性，当特性发生异常通知所有者
□ 搜索引擎：搜索所有数据集，缩小搜索结果和找到最新或潜在的重要数据集。为每个数据集提供概要页面。页面中提供与当前数据集相似的数据集信息，有助于发现互补数据集。
□ 提供众包扩展元数据目录，数据集所有者可以对数据集进行注释，帮助用户确定适合的数据集。数据集审计员可以标记包含敏感信息的数据集，并提醒数据集所有者或提示审查
2. 挑战
○ 数据集规模
§ 仅仅对所有工程师可读的数据集索引，数据集数量就超过260亿
§ 如果增加被限制的数据集并支持更多存储系统，数据集数量将增加一倍以上
§ 即使在每个数据集花费一秒的时间并使用1000太机器并行处理260亿数据集，也要花费约300天的时间
§ 元数据推理的计算量呈指数增长的问题加剧了规模问题
○ 多样性
§ 数据集有不同的格式和存储系统，很难定义出一个涵盖所有数据集类型的单一数据集概念
□ 隐藏由于数据集多样性和复杂性所造成的访问查询的差异
§ 元数据提取成本的差异
□ 与数据集的大小和元数据的类型有关
□ 需要确定哪些数据集是重要的，根据拥有特定类型的元数据的成本和收益执行元数据推断
§ 多样性也体现在数据集的相互关系中，而数据集的相互关系也反过来影响我们在目录中建模和存储元数据的方式。
○ 目录条目的流动率
§ 目录中每天都有大量（约十亿）旧的数据集被删除，同时也会有几乎同等数量的新条目添加
§ 在这种程度的流失率下，需要考虑哪种数据集需要优先计算，哪种数据集需要优先加入目录中
□ 对临时数据集数据集重要性的判断
○ 元数据的不确定性
§ 由于GooDs采用事后非侵入方式识别和分析数据集，无法完全确定所有类型的元数据
§ 由于问题的规模，GooDs对数据集的分析只能是一个近似的过程，不够精准
○ 计算数据集的重要性
§ 推断目录中的数据集的相对重要性是一个挑战
□ 什么使数据集变得重要”这个基本问题很难回答
□ 为了了解其重要性，通常需要在更全局的上下文中检查数据集
§ 数据集对用户的重要性
□ 企业环境下，结构化数据集的重要性与web搜索环境中的重要性有很大的不同
® 来源链接是二者唯一明确的联系，但这并不代表重要性就一致
® 可以用于Web搜索的许多信息，数据集并不具备
® 数据集可以提供Web页面没有的结构化上下文
§ 当我们在推导出元数据时为数据集设定的优先级（多样性那一小节中）可以作为重要性的另一个参考
○ 恢复数据集语义
§ 理解数据集内容的语义对于搜索、排序和描述数据集非常有用
□ 可以通过内容的语义改进搜索
§ 将原始字节提升到概念的抽象级别，有助于元数据的推导
§ 从原始数据中识别语义是一个困难的问题，即使对于小数据集也是如此
□ 因为数据中没有足够的信息来进行这种推理
□ 对大规模的数据集进行语义推理更加的困难
3. GooDs目录
• 虽然每个独立的存储系统都维护一个目录，但每个目录都有不同类型的元数据
• 数据通常不受约束的跨系统流动
• GooDs目录提供了整个公司可用数据集的统一的全局视图
• GooDs目录将相关的数据集组织到一个集群中，使其成为目录中的一个单独的条目
• GooDs假设集群中所有数据集具有相似的属性，以此来优化元数据计算
3.1 元数据
○ 表2显示元数据列表
○ 大多数存储系统并不记录除基本元数据（数据集大小、所有者等）外的其他重要元数据（生成数据集的作业、访问数据集的团队和用户、数据集的模式等），因此要进行元数据推理
○ 基本元数据（Basic metadata）
§ 通过爬取存储系统来获取，过程中不需要推理
§ GooDs的其他模块会通过基础元数据来决定他们的行为
○ 来源（Provenance）
§ GooDs维护一个目录数据集产生、消费，以及上下游数据集依赖关系的元数据
□ 通过对生产日志的分析来识别和填充
□ 为数据集的读写任务提供信息
§ 连接数据集和任务形成一个传递闭包
□ 确定数据集是如何相互连接的
□ 考虑了时间信息，确定这些依赖存在最早和最新的时间点
□ 由于数据访问事件非常多，所以传递闭包可能非常大，因此为了提高效率，只处理日志中访问进行采样处理，并且只在几个层级内具化上下游关系
○ 结构信息（Schema）
§ 理解数据集的另一种核心元数据类型
§ 由于谷歌中最常用的格式不是自描述的，因此需要推断其Schema
§ 谷歌几乎搜有的结构化数据及都是基于序列化的protocol buffer编码的
§ 通过中央代码库对数据集进行匹配确定给定数据集是由哪个protocol buffer编码，可能匹配出多个候选protocol buffer
§ 将候选protocol buffer和每个候选的启发式分数都加入元数据
○ 内容摘要（Content summary）
§ 对内容进行采样，统计使用频繁的字符
§ 分析字段（fields）得出数据键（HyperLogLog算法）
§ 收集具有各个字段的校验和（checksums）和内容的位置敏感哈希(locality-sensitive hash，LSH)值的指纹（fingerprints）识别相同或相似的数据集
○ 用户提供的注释（User-provided annotations）
§ 允许数据集的所有者提供描述文本
§ 注释有助于过滤掉实验性的或不应该显示给用户的数据集
○ 语义（Semantics）
§ GooDs结合了几个噪声信号（noisy signals），以获得关于数据集语义的元数据
§ 对于schema符合protocol buffer的数据集，GooDs可以检查定义protocol buffer的源代码，并提取附加注释
□ 注释通常有很高的质量，进行词法分析可以获得schema语义的短
§ 通过知识图谱识别不同领域的实体
○ 其他
§ 除此自外，还收集数据集所属团队的标识符、数据集所属项目的描述，以及数据集的元数据更改的历史
§ 允许团队添加自己的源数据类型
3.2 将数据集组织成集群（clusters）
○ GooDs目录中每个数据集不是完全独立、
§ 定期生成不同版本
§ 阔不同数据中心复制
§ 被分片成更小的数据集
§ …
○ 集群的优点
§ 可以将不同版本的数据集组合在一起，为用户提供一个有用的逻辑抽象
§ 只需要为集群中的几个数据集收集元数据，节省数据提取成本
○ 聚类本身应该是低开销的
○ 根据数据集的路径（path）进行聚类
§ 数据集路径通常可以通过嵌入的时间戳、版本等标识辅助聚类
§ 假设莫数据集路径为：/dataset/2015-10-10/daily_scan
□ 我们可以抽象出日期的“天”（/dataset /2015-10-/daily_scan）获得一个月内产生的数据集
□ 抽象出日期中的“月”（/dataset/2015--/daily_scan）获得一年内产生的数据集
○ 按照不同的维度构成层次结构，我们可以构造多粒度半网格结构（granularity semi-lattice structure）
§ （个人理解）半网格就是将路径的某维度的信息抽象比如上面列出的/dataset /2015-10-/daily_scan，就是将路径中的“天”这个维度抽象
§ 图2展示了一个由两个维度抽象构成的层次结构（日期，版本号）的半网格示例
§ 表3列出了GooDs当前用于为每个数据集构建多粒度半网格（granularity semi-lattice）的抽象维度
§ 通过从数据集路径中提取不同维度，最终得到一组半网格，其中的非叶节点就是数据集集群分组选择的不同方式
§ 可以在目录的当前状态下使用合适的目标函数来优化集群的选择
○ 由于每天目录的流失率（churn）会导致频繁的集群重计算
§ 可能会造成用户每天看到不同的集群（表示逻辑数据集）
§ 解决方案：只为每个半格的最顶部元素创建一个条目
□ 如图2，目录将之生成一个条目/dataset//来表示底层的三个数据集
□ 优点：
® 方法简单
® 将集群条目的数量保持在一个较低的水平
® 证每个数据集恰好映射到一个集群
® 在一段时间内维护一个稳定的集群
○ 集群元数据的计算
§ 如果我们知道集群中几个数据集的元数据，并且他们元数据中的某个信息都相同，那么我们可以将该信息作为整个集群元数据中对应的信息
§ 是使用传递的信息来得到集群的元数据还是按需计算，需要看具体的应用设计需求而定
○ 图3显示目录中每个集群的数据集数量分布，说明了集群化的显著优点
§ 显著地将“物理”数据集压缩为更小的“逻辑”数据集（目录中的一个条目可以包含多个数据集）
§ 用户更容易地查看目录
§ 节省元数据计算成本
4. 后端实现
4.1 目录存储（Catalog storage）
○ 使用Bigtable来存储GooDs目录
§ 可扩展的时序键值对存储（a scalable, temporal key–value store）
§ 行表示数据集或数据集群，数据集或集群的路径为键。
§ 提供行级事务一致性，适合GooDs系统大部分都是基于数据集处理的情况
○ 系统中有些应用场景不是单数据集处理方式
§ 将多行信息聚合成一行逻辑数据集
§ 同集群中的跨数据及传播元数据（但元数据传播是最好的方法，不需要强一致性）
○ BIgtable包含几个独立的列族
§ 仅由批处理访问的数据（不是提供给前端工具的数据）保存在单独的列族
§ 专为批处理操作而做出的调整（高度压缩，非内存驻留）
§ 由于只为数据集集群提供信息，所以可以高度压缩
○ 以BIgtable方式存储目录，并为每一行存储两种元数据
§ 数据集元数据
§ 状态元数据
□ 与各模块处理数据集结果相关的元数据
□ 列出了处理该条目的每个模块以及模块的时间戳、成功状态和错误消息(如果有的话)
□ 状态元数据用于协调模块的执行
□ 还可以用于系统检查（某个模块成功处理数据集的哪个部分？最常见的错误代码是什么？）
□ 结合Bigtable 的时序数据模型，状态元数据还可以用于调试
□ 通过配置Bigtable几代状态元数据，我们可以看到我们的模块在一段时间内做过什么
4.2 批处理的性能和调度
○ 系统由两类任务组成
§ 大量多样的批处理任务
§ 少量为前端和API提供服务的任务
○ GooDs系统被设计为可扩展的，以兼容新的爬虫，分析模块
○ 一些批处理任务执行很快，一般几个小时之内可以完成；其他的例如分析数据集内容的程序，需要花费很多天才能分析完一个爬虫程序爬取的结果
○ 数据集分布在世界各地，GooDs安排在地理上接近的分析程序去分析这些数据集
○ 所有任务彼此独立的运行
§ 不限制任务执行顺序
§ 不管是否同时运行
§ 如果某个任务失败，则让他们暂时离线
§ 每个任务包括一个或多个模块
○ 模块通常会依赖于其他模块
§ 这些模块需要其他模块先对给定数据集做出处理
§ 模块通过状态元数据相互协作执行，粒度精确到行
□ 如果模块A一定在B之前，那么B在访问行时先检查该行状态元数据中A访问的标记，如果没有，则绕过该行，下次运行时再次尝试
□ 如果A重新处理了该行，在下次执行时B也会重新处理它
§ 模块还可以使用自己的状态元数据避免在一段时间内重复处理已经处理过的行
§ 大多数任务是按天执行，并在24小时内完成
□ 当任务超时没有完成，系统会对任务进行优化，和/或增加其并行性
□ 以24小时为周期处理新的目录行和/或刷新一段时间之外的已经处理过的目录行
○ 重要数据集
§ 大量新数据集加入之后，Schema Analyzer（我们的最重量级的任务）需要几天甚至几周才能分析完成
§ 需要优先级机制来是模块优先处理更重要的数据集
□ 指定用户提供注释或者血缘集成度搞得数据集为“重要”
□ 每个人物分为两个实例
® 一个只处理重要的数据集
® 一个处理所有数据集（一天可能只处理很小一部分）
□ 实践证明，确保重要数据集分布的“头部”具有良好的覆盖率和刷新率（freshness）就足够了
○ 大型爬虫任务对目录执行盲写
§ 程序从数据源读取数据之后，将所有数据直接写入Bigtable
§ 不区分插入和更新
§ 比通过读取目录来反链接（anti-join）新的数据更有效率
§ 某些情况，不能采用盲写，可能导致依赖模块不必要的重新运行或阻塞垃圾回收
4.3 容错机制
○ 由于分析的数据集数量大种类多，会遇到各种各样的问题
○ 状态元数据会记录每个数据集发生的错误
§ 显示某个模块的错误中止的状态元数据会触发重试（有限次的）
§ 需要依赖其他模块对数据集处理的模块需要其作业范围内数据集的状态元数据（状态元数据记录了任务的开始时间以及是否成功）
§ 这种方法是保守的
□ 如果之前模块部分执行失败，系统可能需要重新进行Bigtable写操作
§ 这种方法保证了起源图的正确性
§ 系统能够将记录的任务血源信息标记为“已使用”，这个特性对于垃圾收集非常重要
○ 使用沙盒将存在崩溃或进入或挂起的风险的任务封装到单独的进程
§ 系统中有一些模块（检查数据集内容的模块）使用了第三方库
□ 这些库有时会崩溃或进入死循环（这种情况不可避免）
§ 由于不能让长时间运行的分析任务崩溃或挂起，所以使用沙盒将这些任务封装到单独的进程，使用看门狗线程进行监控
§ 将长时间的停顿的进程转换为崩溃状态，保证管道的其余部分可以继续运行
○ 在多个地理位置复制目录
§ 写入到主服务器（ master）时，在后台的其他地方进行异步复制
4.4 元数据的垃圾回收
○ 系统每天吸收并创造大量数据，其中相当一部分是临时文件
○ 只要模块相关的元数据被使用来更新目录之后，这些被删除的数据集的目录中对应的条目就会被删除
○ 起初采用的简单保守的垃圾回收方法
§ 如果一个条目一周没有更新，就会被删除
§ 这会导致目录变得臃肿
§ 需要采用更有效地垃圾回收方法
○ 垃圾回收机制三个限制
§ 删除行的条件最好表示为陈述性断言（declarative predicates），该断言使用访问或更新行的模块的元数据和状态信息
□ 如删除目录中的数据集的条件：
® 数据集已从存储系统中删除
® 与其来源链接的模块已经对其最近更新的来源信息（成功地）进行了处理
§ 当从目录中删除条目时，必须保证不会创建所谓的“悬挂行（dangling rows）”
□ 由于Bigtable不区分插入和更新，因此在删除一行是必须确保没有并发执行的模块将该行的信息添加到该行
□ 加入垃圾回收模块和某一模块同时对某一行进行操作，垃圾回收模块删除将该行删除后，另一个模块却将它计算出的信息写入该行。此时这一行数据只包含模块写入的信息，即“悬挂行（dangling rows）”
□ 导致行营数据集所在位置信息丢失，可能影响其他模块的完整性
§ 所有其他模块都必须独立于垃圾回收模块，并和垃圾回收同时运行
○ Bigtable支持条件突变（conditional mutations），即遵循事务原则
§ 如果给定断言为true，则以事务性方式是更新或删除行
§ 让所有对Bigtable操作的模块都要判断该行是否被删除，代价太大
□ 因此conditional mutations会导致大量的日志结构读开销
○ 目前的垃圾回收策略：允许除垃圾回收器外的所有模块执行非事务性更新
§ 垃圾回收的两个阶段
□ 使用陈述性断言的方式删除目录行（三个约束的第一个）
® 在第一阶段，我们的垃圾回收并不真正的删除Bigtable条目
® 而是在其上方只一个特殊的tombstone标记
□ 24小时后(见下面关于这个阈值的更多信息)，如果行仍然满足删除条件，我们删除它；否则，我们就会移除tombstone标记
§ 其他模块需要遵循以下约束：
□ 可以执行非事务式更新操作
□ 它们会忽略带有tombstone标记的行，以避免更新将要被删除的行
□ 一个模块的单次迭代不能存活超过24小时(我们的模块调度机制实现了这一点)
§ 这个垃圾回收设计满足上面的三个约束条件，保证了整个系统的效率
5. 前端：服务目录
• 本章节讲述的是通过GooDs中收集的元数据所启用的主要服务(参见图1的顶部)
5.1 数据集概要页面
○ 在易于查看的页面中展示元数据
§ 配置文件页面服务以数据集或数据集群的路径作为输入
§ 从目录中导出元数据生成页面
○ 提供编辑元数据特定部分的方法，允许用户增加或纠正存储在目录中的信息
○ 系统必须在详尽展现元数据信息和页面上的信息数量可控之间做权衡
§ 信息量的控制非常重要，既不会让被过多的信息淹没，又可以避免传输大量的信息
§ 比如血缘信息，为了比卖你向用户传递和呈现庞大的信息，每当来源元数据变得太大时，就是用3.2节介绍的抽象机制对来源元数据进行压缩，如果压缩后还是太大，就只保留最近的条目
○ 页面将一些元数据与其他更专业的工具交叉链接
§ 例如，配置页面将来源元数据与 job-centric tools的任务详情页相关联；我们将架构（Schema）元数据与代码管理工具相关联，代码管理工具提供了这个架构的定义
§ 相应地，这些工具也可以链接到GooDs，帮助用户获得更多关于数据集的信息
○ 配置文件页面提供了不同语言(例如，c++， Java, SQL)的访问代码段（access snippets）来访问数据集的内容
§ 为特定数据集定制生成代码段
□ 功能
® 代码段可以使用数据集的路径和架构
® 用户可以在各自的编程环境中复制-粘贴代码段
□ 代码段目标是补充配置文件页面中的元数据内容
® 后者提供关于数据集内容的模式架构级信息（schema-level）
® 而代码段提供了快速检查实际内容或通过代码分析内容的简便方法
○ 概要界面总述
§ 概要页面目的
□ 提供一站式服务
□ 用户可以在其中查看有关数据集的信息
□ 并理解数据集在生产中使用的上下文
§ 以上特性使概要页面成为用户之间共享数据集或从其他工具链接到数据集信息的工具
§ 当用户检查目录的内容时，谷歌的文件系统浏览器提供到GooDs数据概要页面的直接链接
5.2 数据集搜索
○ 这个服务任务是如何为用户推荐感兴趣的数据集
○ 搜索关键字与数据集匹配
§ 数据集搜索允许谷歌人员使用简单的关键字搜索来查找数据集
□ 该服务由用于文档检索的传统倒排索引支持
® 其中将每个数据集看成一个“文档”
® 我们从数据集元数据的子集派生出每个文档的索引令牌，每个令牌都可以与索引的特定部分相关联
◊ 例如搜索atom“path:x”将只匹配数据集路径上的关键字“x”，而不限定的atom“x”将匹配数据集元数据的任何部分中的关键字
◊ 表4总结了数据集搜索索引中的主要部分及意义
□ 索引令牌的提取遵循索引覆盖的查询类型
® 以路径为例，按照公共分隔符分割数据集的路径，查询令牌与索引中的连续令牌进行匹配
® 当索引协议缓冲区（protocol buffers）的名称时，我们遵循了类似的方案，可以用命名空间限定(例如，“foo.bar.X”)
○ 派生一个评分函数来对匹配的数据集进行排序
§ 目标：使第一个结果与用户的搜索相关
§ 评分通常是一个困难的问题，需要持续地进行调整
§ 评分函数设计的一些方法
□ 数据集的重要性取决于它的类型
® 其他条件都相同的情况下，我们的评分函数更偏向于Dremel表[19]，而不是文件数据集
◊ 为了使数据集对更多用户可见，数据集所有者需要将数据集注册为Dremel表
® 将此作为评价数据集的重要指标，反映在最终评分中
□ 关键字匹配的重要性取决于索引部分
® 例如，在所有其他条件相同的情况下，关键字在数据集路径上的匹配比在读取或写入数据集的任务上的匹配更重要
□ 血缘关系是数据集重要性的良好指标
® 这个方法更倾向于具有许多读取任务的数据集和有很多下游的数据集
◊ 如果有很多生产管道访问，说明该数据集很有可能是重要的
® 可以将这种方法看作是图中PageRank的近似
◊ 数据集和生产任务是顶点
◊ 任务对数据集的访问用边表示
® 该方法可能会给出错误的评分
◊ 某些数据集仅仅被许多内部管道间接访问，会导致这些数据集被分配很高的分数，即使他们对大多数用户是无用的
◊ 例如Web爬虫
□ 带有所有者描述的数据集可能是重要的
◊ 数据集所有者为他们的数据集添加描述以促进更多用户使用
◊ 如果关键字匹配出现在一个数据集的描述，那么这个数据集的权重也应该更高
§ 除上述信号之外，评分函数还整合了其他一些信号
○ GooDs还提供了目录中的一些分类的元数据的类别划分（facets）
§ 划分类别：数据集所有者、数据集文件格式…
§ 为用户提供了匹配数据集的概述，有助于用户更容易地制定后续的深入查询
5.3 团队仪表板（Team dashboards）
○ 仪表盘使一个显示团队生成的所有数据集以及数据集元数据的一站式服务窗口
§ 仪表盘的内容会随着数据集的改变而更新
§ 用户可以将仪表盘页面嵌入到其他文档中，并与他人共享
○ 仪表盘还提供见是数据集的方法，并进行监测
§ 设置简便（用户只需要点几下鼠标就可以设置监控）
§ GooDs检查相应数据集中被监控的属性，并将警报传递到内部监控UI
§ GooDs还通过分析一些常见属性的发展趋势，自动生成监控
6. 教训总结
• 不断发展（Evolve as you go）
○ GooDs系统的使用趋势
§ 审核协议缓冲区（Audit protocol buffers）
□ 某些协议缓冲区包含个人身份信息，因此使用这些缓冲区的数据集需要遵守访问策略
□ 对违反策略的数据集提出警告
§ 重新查找数据集（Re-find datasets）
□ 数据集处理过程中会生成实验需要的数据集备份
□ 但是在分析过程中，工程师经常会忘记他们的路径
□ GooDs可以根据关键字搜索很容易的找到
§ 理解遗留代码（Understand legacy code）
□ 遗留代码因为很难找到最新文档造成很难读懂
□ GooDs通过来源图可以找到代码的输入输出数据集
□ 这有助于理解代码的底层逻辑
§ 标记数据集（Bookmarks datasets）
□ 数据集概要界面提供数据集信息一站式展示
□ 用户可以对感兴趣的页面进行标记以便之后再次访问
□ 也可以分享给其它用户
§ 注释数据集（Annotate datasets ）
□ GooDs目录可以作为数据集注释的枢纽，可以支持在团队之间共享
• 使用特定领域的信号进行排名（Use domain-specific signals for ranking）
○ 如第2节所述，与其他领域(如Web排名)的排名问题相比，数据集排名问题具有独特的特征
○ 数据集之间的来源关系提供了一个重要的领域特定的排名信号
• 预期并处理非常规数据集（Expect and handle unusual datasets）
○ 由于数据集数量巨大，会出现很多情况
○ 有些代码可以一次性解决，有些则需要系统级的重新设计
○ 采用的策略：先使用最简单的解决方案(尽管是临时解决方案)，然后在需要时对其进行通用化
• 按需导出数据（Export data as required）
○ 问题
§ GooDs目录的存储介质是键值存储，搜索服务由传统的倒排索引支持
§ 两种结构都不适合在起源图上可视化或执行复杂的路径查询
○ 解决方案
§ 将目录数据每天按主谓宾三元组（ subject–predicate–object triples）的形式导出
§ 将这些三元组导入到基于图形的系统中以支持路径查询的，并公开更易于可视化的API
○ 对于由存储介质原因不能支持的强大查询处理能力的用例，最简单的策略是将目录数据导出到一个适当的专门引擎
• 确保可恢复性（Ensure recoverability）
○ 提取数十亿数据集的元数据是成本非常高的
○ 在稳定状态下，我们在每天只处理当天的新数据集
○ 丢失或损坏大量目录可能需要数周的时间才能恢复，或者将大量额外的计算资源用于恢复
○ 重大数据丢可能导致一些元数据无法重新计算
○ 解决策略
§ 对Bigtable进行了配置，使其在几天内保留快照的滚动窗口
§ 专门为GooDs构建了定制的恢复性方案
□ 一个专门的进程，将高价值的数据集(用户通过注释明确表示感兴趣的数据集)快照到一个单独的目录中，以防止数据丢失
□ 另一个进程复制支持概要页面的目录子集，这样即使主目录离线，服务也仍然可用
□ 使用GooDs数据集监控服务监控目录(这是另一个结构化数据集！)，以确保尽早发现数据损坏和删除
