1.1. 重点是在开发洞察的迭代过程中找到相关的数据集（表、视图、模式、文件、流和事件）和工件（指标、仪表盘、模型、ETL和即席查询）

1.2. 搜索服务简化了数据集和工件的发现过程

1.2.1. 通过搜索服务，数据用户可以使用关键字、搜索通配符、业务术语等表达他们要查找的内容

1.2.2. 在底层，该服务完成了发现数据源、索引数据集和工件、对结果进行排序、确保访问治理和管理持续变更等烦琐工作

1.2.3. 数据用户可以获取一个与输入搜索查询最相关的数据集和工件的列表

1.2.4. 此类服务的成功标准是降低搜索耗时

1.2.4.1. 降低搜索耗时可以显著地减少洞察耗时，因为数据用户能够快速搜索，并迭代不同的数据集和工件

1.2.5. 减缓搜索过程会对洞察的总体时间产生负面倍增效应

1.3. 搜索服务可以自动完成将相关数据集和工件列入清单的过程，极大地简化了发现阶段的工作

2.1. 查找数据集和工件的需求是数据科学家路线图的起点

2.2. 确定业务问题的可行性

2.2.1. 给定一个业务问题，发现阶段的第一步是确定有关数据集可用性的可行性

2.2.2. 可用性状态

2.2.2.1. 数据不存在，需要对应用程序进行检查

2.2.2.2. 源系统中有可用的数据，但没有聚合到数据湖中

2.2.2.3. 数据是可用的，并且已经被其他工件使用

2.2.3. 可行性分析能在项目初期评估所需的洞察耗时，对做好项目规划至关重要

2.2.4. 在数据可用性方面发现的差距会被纳入数据收集阶段的需求

2.3. 为数据准备选择相关数据集

2.3.1. 目标是筛选出一个或多个用于整个路线图下一阶段的数据集

2.3.2. 为数据准备选择相关数据集是一个迭代的过程，包括使用关键词搜索数据集、对搜索结果进行抽样，以及选择对数据属性的含义和沿袭进行更深层次的分析

2.3.3. 一个常见的场景是存在多个事实来源，一个给定的数据集可能存在于一个或多个具有不同意义的数据孤岛中

2.3.4. 如果现有的工件已经在使用该数据集，则这就是数据集质量较高的一个体现

2.4. 重用现有的工件进行原型开发

2.4.1. 目标不是从头开始，而是找到任何可以重用的构建模块

2.4.2. 一个单一地理位置的仪表盘已经存在，可以通过参数化地理位置和其他输入来重用

2.4.3. 可以利用已固化的数据管道生成的标准化业务指标

2.4.4. 可以重用在notebook中共享的探索性查询

3.1. 搜索耗时是反复筛选相关数据集和工件所需的总时间

3.2. 考虑到查找过程的复杂性，团队经常会重新发明轮子，导致组织内存在大量数据管道、仪表盘和模型的副本

3.3. 既浪费精力，又导致更长的洞察耗时

3.4. 搜索服务的目标是最大限度地减少在每个活动中花费的时间

3.5. 为数据集和工件建立索引

3.5.1. 任务

3.5.1.1. 定位数据集和工件的来源

3.5.1.2. 探索这些数据源，以聚合模式和元数据属性等细节

3.5.2. 团队知识是有针对性的，并不总是正确的或更新

3.5.3. 探索其他元数据的来源（比如模式、沿袭和执行统计等）需要特定于源技术的API或命令行接口

3.5.4. 数据用户需要与数据源所有者和团队知识合作，以聚合列名、数据类型和其他细节的含义

3.5.5. 理解数据管道代码等工件需要分析查询逻辑以及如何重用它

3.5.6. 随着新的应用程序和工件的不断开发，建立索引是一个持续的过程

3.5.7. 加之现有的数据集和工件也在不断发展，及时跟上变化并更新结果会耗费较多时间

3.6. 对结果排序

3.6.1. 一个典型的搜索排序过程是从手动搜索数据存储、目录、Git仓库、仪表盘等开始的

3.6.2. 排序会耗费很长时间的原因

3.6.2.1. 表没有明确的名称或定义良好的模式

3.6.2.2. 表中的字段名称不恰当

3.6.2.3. 存在未被广泛使用或管理的低质量数据集和工件

3.6.2.4. 模式没有与业务的发展同步演进

3.6.3. 一种常见的启发式方法就是只查看那些在各个用例中使用的、访问请求量大的流行数据资产

3.7. 访问控制

3.7.1. 安全地连接到数据集和工件源

3.7.2. 限制对搜索结果的访问

3.7.3. 将访问搜索结果的权限限制在可控范围内

3.7.3.1. 限制搜索结果是在能够发现数据集或工件的存在与获得对安全属性的访问之间的平衡

4.1. 搜索服务应该能够解答一些数据用户的问题

4.2. 关键模块

4.2.1. 索引模块

4.2.1.1. 发现可用的数据集和工件，提取模式和元数据属性并将其添加到目录中

4.2.1.2. 该模块需要跟踪更改并不断更新细节信息

4.2.1.3. 根据搜索服务索引的数据集和工件的类型，索引模块需求因部署要求而异

4.2.1.4. 数据集涵盖结构化数据、半结构化数据和非结构化数据

4.2.1.4.1. 半结构化NoSQL数据集可以是键-值存储、文档存储、图形数据库、时间序列存储等

4.2.1.5. 随着数据集和工件的不断发展而更新索引

4.2.1.6. 确定索引需要以多快的速度更新用以反映变化，即确定可接受的刷新延迟

4.2.1.7. 跨版本和历史分区定义索引，即定义搜索范围是否仅限于当前分区

4.2.2. 排序模块

4.2.2.1. 负责根据相关性和流行程度对搜索结果进行排序

4.2.2.2. 排序是相关性和流行度的权衡结果

4.2.2.3. 相关性基于名称、描述和元数据属性的匹配

4.2.3. 访问控制模块

4.2.3.1. 确保向数据用户显示的搜索结果符合访问控制策略

4.2.3.2. 搜索结果的访问控制策略可以根据用户的具体信息、数据属性的具体信息或两者来定义

4.2.3.3. 特定于用户的策略称为基于角色的访问控制（RBAC）

4.2.3.4. 特定于属性的策略称为基于属性的访问控制（ABAC）

4.2.3.5. 特殊处理需求

4.2.3.5.1. 屏蔽行或列的值

4.2.3.5.2. 时间变化策略，即数据集和工件在特定的时间戳之前是不可见的

4.3. 非功能性需求

4.3.1. 搜索响应时间

4.3.1.1. 让搜索服务以秒为单位响应搜索查询很重要

4.3.2. 支持大型索引的扩展性

4.3.2.1. 随着企业的发展，搜索服务需要扩展到支持数千个数据集和工件

4.3.3. 易于使用新的数据源

4.3.3.1. 应简化数据源所有者将其数据源添加到搜索服务的过程

4.3.4. 自动监控和告警

4.3.4.1. 服务的运行状况应该易于监控

4.3.4.2. 生产过程中的任何问题都应该自动生成告警

5.1. 推拉式索引器模式

5.1.1. 发现并不断更新可用的数据集和工件

5.1.2. 推拉式索引器模式用于在企业的各个孤岛中发现并更新可用的数据集和工件

5.1.3. 索引器的拉取功能会发现源，提取数据集和工件，并将它们添加到目录中

5.1.4. 推送功能与跟踪数据集和工件中的更改有关

5.1.5. 连接阶段

5.1.5.1. 索引器连接到可用的数据源

5.1.6. 提取阶段

5.1.6.1. 下一个阶段是提取细节信息

5.1.7. 更新阶段

5.1.7.1. 数据源将更新发布到事件总线上的数据集和工件

5.1.7.2. 为了防止混入低质量的数据，可以引进同行评审检查（类似于代码评审），这样可以改进方法、借鉴其他的工作并保证数据的精确性

5.1.8. Metacat使用一个拉取模型来提取数据集的细节信息，使用一个推送通知模型以便数据源将它们的更新发布到Kafka等事件总线上

5.1.9. 优点

5.1.9.1. 索引更新及时

5.1.9.2. 定期爬取新的数据源，并将更改事件推送到事件总线上进行处理

5.1.9.3. 是一种可扩展的模式，用于提取和更新不同类别的元数据属性

5.1.9.4. 虑到推拉方法的组合，它具备支持大量数据源的可扩展性

5.1.10. 缺点

5.1.10.1. 针对不同类型数据源的配置和部署可能会有挑战

5.1.10.2. 要通过拉取方式访问详细信息需要源代码权限，这可能会受到源代码的权限限制

5.1.11. 推拉式索引器模式是实现索引的高级方法（与推模式相比）

5.1.11.1. 为了确保找到数据源，加载过程应该包括将数据源添加到拉取目标的列表，以及创建一组公共访问凭证

5.2. 混合搜索排序模式

5.2.1. 对结果进行排序，以帮助数据用户找到最相关的数据集和工件，从而满足数据项目的需求

5.2.2. 该模式的成功标准是最相关的结果排在前5名

5.2.3. 解析阶段

5.2.3.1. 搜索从一个输入字符串开始，通常使用简单的短语

5.2.3.2. 该服务由用于文档检索的传统倒排索引提供支持，其中每个数据集和工件都被构建成一个文档，其中包含基于元数据派生的索引令牌

5.2.3.3. 解析过程的另一个起点是浏览流行的表和工件列表，并找到与业务问题最相关的表和工件

5.2.4. 排序阶段

5.2.4.1. 结果排序是相关性和流行度的结合

5.2.4.2. 相关性是基于输入文本与表名、列名、表描述、元数据属性等的模糊匹配

5.2.4.3. 基于流行度的匹配是基于活跃度—即查询次数较多的数据集和工件在列表中靠前的位置显示，而查询次数较少的数据集和工件在搜索结果中靠后的位置显示

5.2.4.4. 理想的结果是既流行又相关的结果

5.2.4.5. 另一种启发式方法是基于质量指标进行排序，例如报告的问题数量，以及数据集是否作为强化数据管道的一部分而不是临时流程生成

5.2.5. 反馈阶段

5.2.5.1. 需要根据反馈调整相关性和流行度之间的权重

5.2.5.2. 搜索排序的有效性可以通过显性或隐性的方式来度量：显性的方式是对展示的结果进行“大拇指向上/向下”的评分，隐性的方式是前5个结果的点击率（CTR）

5.2.6. 评分通常会很困难，需要根据用户的体验调整评分函数

5.2.6.1. 在其他条件相同的情况下，评分函数更倾向于结构化表而不是文件数据集

5.2.7. 沿袭扇出是数据集重要性的一个很好的指标，表明了流行度

5.2.8. 启发式方法倾向于具有许多读取作业和下游数据集的数据集

5.2.9. 用户界面使数据集所有者能够为他们希望其他团队使用的数据集提供描述

5.2.10. 优点

5.2.10.1. 它平衡了相关性和流行度，让数据用户可以快速筛选出最相关的数据

5.2.10.2. 尽管在第一天就需要为相关性匹配添加大量元数据，但这不会成为瓶颈。当该模式更多地使用基于流行度来排序时，可以增量地对元数据进行索引

5.2.11. 缺点

5.2.11.1. 它并不能取代对整理数据集的需求

5.2.11.1.1. 该模式依赖于与业务细节同步的元数据细节的准确性

5.2.11.2. 很难在流行度和相关性之间取得适当的平衡

5.2.12. 对于有大量元数据的数据集和工件，它利用相关性进行匹配

5.2.12.1. 对于没有得到很好整理的数据资产，它利用流行度进行匹配

5.3. 目录访问控制模式

5.3.1. 根据数据用户的角色和其他属性，限制对搜索服务中可见的数据集和工件的访问

5.3.2. 搜索服务的目标是让数据用户轻松发现数据集和工件

5.3.2.1. 要确保不违反访问控制策略

5.3.3. 显示给不同用户的搜索结果可以排除选定的数据集，或者在元数据细节的级别上有所不同

5.3.4. 阶段

5.3.4.1. 分类

5.3.4.1.1. 在该阶段对用户、数据集和工件进行分类

5.3.4.1.2. 根据用户的角色将用户分成不同的组：数据管理员、财务用户、数据质量管理员、数据科学家、数据工程师、管理员等

5.3.4.1.3. 角色定义了在搜索过程中可见的数据集和工件

5.3.4.2. 定义

5.3.4.2.1. 策略定义了针对特定数据集或工件向特定用户显示的搜索细节的级别

5.3.4.2.2. 数据质量用户可以查看高级元数据并更改日志历史记录

5.3.4.2.3. 策略定义分为RBAC和ABAC

5.3.4.2.3.1. RBAC是基于用户定义策略

5.3.4.2.3.2. ABAC是根据用户定义的标签、基于IP地址的地理标签、基于时间的标签等属性定义策略

5.3.4.3. 执行

5.3.4.3.1. 每个人的基本元数据：针对搜索查询，结果向每个人显示基本元数据（如名称、描述、所有者、更新日期、用户自定义标签等），无论他们是否有访问权限

5.3.4.3.2. 选择性的高级元数据：特定的用户可以根据访问控制策略来获得高级元数据

5.3.4.3.3. 屏蔽列和行：基于访问控制，同一个数据集在数据预览中将展示不同的列数和行数

5.3.4.3.4. 对目录的更新将自动传播到访问控制

5.3.5. 优点

5.3.5.1. 如果目录级别上有集中的访问控制策略，则很容易进行管理

5.3.5.2. 它提供基于不同用户和用例的可配置访问控制

5.3.6. 缺点

5.3.6.1. 目录访问控制策略可能与数据源策略不同步

5.3.6.2. 目录访问模式是平衡可发现性和访问控制的必备工具，它具有很强的灵活性，既可以采用简单的启发式方法，也支持复杂的细粒度授权以及屏蔽