3.4　实现模式

与现有的任务图相对应，搜索服务的自动化有三个级别（如图3-2所示）。每个级别都对应于将目前手工或效率低下的任务组合自动化。

推拉式索引器模式

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

混合搜索排序模式

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

目录访问控制模式

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

3.4.1　推拉式索引器模式

推拉式索引器模式用于在企业的各个孤岛中发现并更新可用的数据集和工件。索引器的拉取功能会发现源，提取数据集和工件，并将它们添加到目录中。这类似于搜索引擎在互联网上抓取网站，并抽取出相关的网页。推送功能与跟踪数据集和工件中的更改有关。在这种模式中，数据源生成更新事件，这些事件被推送到目录中以更新现有的详细信息。

推拉式索引器模式包含以下几个阶段（如图3-3所示）。

1. 连接阶段

索引器连接到可用的数据源，例如数据库、目录、模型和仪表盘仓库等。这些数据源信息可以手动添加，也可以自动发现。自动发现数据源有几种方法：扫描网络（类似于漏洞分析中使用的方法）、使用云账户API发现账户内部署的服务等。

2. 提取阶段

下一个阶段是提取细节信息，比如所发现数据集和工件的名称、描述，以及其他元数据。对于数据集，索引器向目录提供源凭证来提取细节信息（如第2章所述）。目前没有直接的方法来提取所有工件的细节信息。对于notebook、数据管道代码和其他持久化在Git仓库中的文件，索引器会查找元数据头，比如文件开头的少量结构化元数据（包括作者、标签和简短描述）。这对于notebook工件特别有用，因为从查询到转换、可视化和记录，整个内容都包含在一个文件中。

3. 更新阶段

数据源将更新发布到事件总线上的数据集和工件。这些事件用于对目录进行更新。例如，当一个表被删除时，目录订阅这个推送通知并删除记录。

现在我们看一个工件仓库示例：Airbnb的开源项目Knowledge Repo（https://oreil.ly/hKl8e）。该项目的核心部分有一个GitHub仓库，notebook、查询文件和脚本都被提交到这个仓库中。每个文件开始时都有少量结构化元数据，包括作者、标记和内容的简短总结。一个Python脚本会用来验证内容，并使用Markdown语法将post请求转换为纯文本。GitHub的拉取请求用于查看标题内容，并根据时间、主题或内容对标题进行组织。为了防止混入低质量的数据，可以引进同行评审检查（类似于代码评审），这样可以改进方法、借鉴其他的工作并保证数据的精确性。此外，每个post都有一组元数据标签，提供多对一的主题继承（超出了文件的文件夹位置）。用户可以订阅主题并得到更新通知。

推拉式索引器模式一个示例是Netflix的开源项目Metacat catalog（https://oreil.ly/js2JN），它能够索引数据集。Metacat使用一个拉取模型来提取数据集的细节信息，使用一个推送通知模型以便数据源将它们的更新发布到Kafka等事件总线上。源数据还可以调用显式的REST API来发布更改事件。在Metacat中，更改也被发布到Amazon SNS中。向SNS发布事件可以让数据平台中的其他系统对这些元数据或数据更改做出相应的“反应”。例如，当删除表时，垃圾收集服务可以订阅事件并适当地清理数据。

推拉式索引器模式的优点：

• 索引更新及时。定期爬取新的数据源，并将更改事件推送到事件总线上进行处理。
• 它是一种可扩展的模式，用于提取和更新不同类别的元数据属性。
• 考虑到推拉方法的组合，它具备支持大量数据源的可扩展性。

推拉式索引器模式的缺点：

• 针对不同类型数据源的配置和部署可能会有挑战。
• 要通过拉取方式访问详细信息需要源代码权限，这可能会受到源代码的权限限制。

推拉式索引器模式是实现索引的高级方法（与推模式相比）。为了确保找到数据源，加载过程应该包括将数据源添加到拉取目标的列表，以及创建一组公共访问凭证。

3.4.2　混合搜索排序模式

给定一个字符串输入，排序模式会生成一个数据集和工件的列表。字符串可以是表名、业务术语表概念、分类标签等。这类似于搜索引擎用于生成相关结果的页面排名。该模式的成功标准是最相关的结果排在前5名。搜索排序的有效性对于减少洞察耗时至关重要。例如，如果相关结果在首页的前三名，而不是在后面几页，用户就不会浪费时间去检查和分析不相关的结果。混合搜索排序模式实现了相关性和流行度的结合，以找到最相关的数据集和工件。

该模式有三个阶段（如图3-4所示）：

1. 解析阶段

搜索从一个输入字符串开始，通常使用简单的短语。除了搜索之外，还可以通过多个条件来过滤结果。该服务由用于文档检索的传统倒排索引提供支持，其中每个数据集和工件都被构建成一个文档，其中包含基于元数据派生的索引令牌。每一类元数据都可以与索引的特定部分相关联。例如，从数据集的创建者派生的元数据与索引的“创建者”部分相关联。因此，搜索creator:x将只匹配数据集creator上的关键字x，而非限定的atom x将匹配数据集元数据中任何部分的关键字。解析过程的另一个起点是浏览流行的表和工件列表，并找到与业务问题最相关的表和工件。

2. 排序阶段

结果排序是相关性和流行度的结合。相关性是基于输入文本与表名、列名、表描述、元数据属性等的模糊匹配。基于流行度的匹配是基于活跃度——即查询次数较多的数据集和工件在列表中靠前的位置显示，而查询次数较少的数据集和工件在搜索结果中靠后的位置显示。一个理想的结果是既流行又相关的结果。还有其他几个启发式方法需要考虑，例如，新创建的数据集在相关性上有更高的权重（因为它们还不流行）。另一种启发式方法是基于质量指标进行排序，例如报告的问题数量，以及数据集是否作为强化数据管道的一部分而不是临时流程生成。

3. 反馈阶段

需要根据反馈调整相关性和流行度之间的权重。搜索排序的有效性可以通过显性或隐性的方式来度量：显性的方式是对展示的结果进行“大拇指向上/向下”的评分，隐性的方式是前5个结果的点击率（CTR）。这将微调权重和相关匹配的模糊匹配逻辑。

混合搜索排序模式的一个示例是开源项目Amundsen（https://oreil.ly/BzyoZ）。Amundsen对数据集和工件建立索引。输入解析实现了类型前置能力，以提高匹配的精确度。输入字符串支持通配符以及关键字、类别、业务术语表等。可以使用不同类型的过滤器进一步缩小输入范围，例如：

• 按类别搜索，如数据集、数据表、数据流、标签等。
• 根据keyword: value进行过滤，例如column: users或column_description: channels。

Amundsen通过实现一个薄的Elasticsearch代理层来与目录交互，从而实现模糊搜索。元数据被持久化在Neo4j中，它使用数据接入库来构建索引。搜索结果显示的是内联元数据的一个子集——表的描述，以及表最后更新的日期。

评分通常会很困难，需要根据用户的体验调整评分函数。以下是Google的数据集搜索服务（https://oreil.ly/V2BEZ）在评分函数中使用的一些启发式方法：

数据集的重要性取决于它的类型

在其他条件相同的情况下，评分函数更倾向于结构化表而不是文件数据集。假设数据集所有者必须显式地将数据集注册为表，从而使数据集对更多用户可见，这个动作可以体现数据集的重要程度。

关键字匹配的重要性取决于索引部分

例如，在其他条件相同的情况下，数据集路径上的关键字匹配，要比读写数据集的作业上的匹配更重要。

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

具体来说，这个启发式方法倾向于具有许多读取作业和下游数据集的数据集。如果许多生产管道访问某数据集，那么该数据集很可能是重要的。我们可以将这种启发式方法看作图中的PageRank近似实现，其中数据集和生产作业是顶点，边表示作业对数据集的访问。

带有所有者来源描述的数据集很可能是重要的

我们的用户界面使数据集所有者能够为他们希望其他团队使用的数据集提供描述。这种描述能够体现数据集的重要性。如果一个数据集的描述中出现关键字匹配，那么这个数据集的权重也会提高。

混合搜索排序模式的优点：

• 它平衡了相关性和流行度，让数据用户可以快速筛选出最相关的数据。
• 尽管在第一天就需要为相关性匹配添加大量元数据，但这不会成为瓶颈。当该模式更多地使用基于流行度来排序时，可以增量地对元数据进行索引。

混合搜索排序模式的缺点：

• 它并不能取代对整理数据集的需求。该模式依赖于与业务细节同步的元数据细节的准确性。
• 很难在流行度和相关性之间取得适当的平衡。

混合搜索排序模式提供了两全其美的方法。对于有大量元数据的数据集和工件，它利用相关性进行匹配。对于没有得到很好整理的数据资产，它利用流行度进行匹配。

3.4.3　目录访问控制模式

搜索服务的目标是让数据用户轻松发现数据集和工件。但同样重要的是要确保不违反访问控制策略。显示给不同用户的搜索结果可以排除选定的数据集，或者在元数据细节的级别上有所不同。这种模式在元数据目录处实施访问控制，并为细粒度授权和访问控制提供了一种集中的方法。

目录访问控制模式有三个阶段：

分类

在该阶段对用户、数据集和工件进行分类。根据用户的角色将用户分成不同的组：数据管理员、财务用户、数据质量管理员、数据科学家、数据工程师、管理员等。角色定义了在搜索过程中可见的数据集和工件。类似地，数据集和工件使用用户定义的标签进行注释，例如财务、PII等。

定义

策略定义了针对特定数据集或工件向特定用户显示的搜索细节的级别。例如，与财务结果相关的表可以限制为财务用户。类似地，数据质量用户可以查看高级元数据并更改日志历史记录。策略定义分为RBAC和ABAC。RBAC是基于用户定义策略，ABAC是根据用户定义的标签、基于IP地址的地理标签、基于时间的标签等属性定义策略。

执行

通常，有三种方法可以在搜索结果中执行访问控制策略。

• 每个人的基本元数据：针对搜索查询，结果向每个人显示基本元数据（如名称、描述、所有者、更新日期、用户自定义标签等），无论他们是否有访问权限。这样做的原因是通过显示存在的数据集和工件来确保用户的工作效率。如果数据集符合要求，用户就可以请求访问。
• 选择性的高级元数据：特定的用户可以根据访问控制策略来获得高级元数据，如列统计信息和数据预览。
• 屏蔽列和行：基于访问控制，同一个数据集在数据预览中将展示不同的列数和行数。对目录的更新将自动传播到访问控制，例如，如果一列被标记为敏感信息，搜索结果将自动开始反映在数据预览中。

用于细粒度授权和访问控制的流行开源解决方案的一个示例是开源项目Apache Ranger（https://oreil.ly/R2Op6），它提供了一个集中的框架，为Atlas目录和所有Hadoop生态系统实现安全策略。它支持基于单个用户、组、访问类型、用户定义的标签、IP地址等动态标签的RBAC和ABAC策略（如图3-5所示）。Apache Ranger的策略模型得到了增强，支持行过滤和数据屏蔽特性，这样用户就只能访问表中的行子集，或者访问经过敏感数据屏蔽/修订的值。Ranger的策略有效期可以将策略配置为在指定的时间范围内有效，例如，在收益发布日前限制对敏感财务信息的访问。

目录访问控制模式的优点：

• 如果目录级别上有集中的访问控制策略，则很容易进行管理。
• 它提供基于不同用户和用例的可配置访问控制。

目录访问控制模式的缺点：

• 目录访问控制策略可能与数据源策略不同步。例如，数据用户可以根据目录策略访问元数据，但不能根据后端源策略访问实际数据集。

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