3.3　定义需求

搜索服务应该能够解答一些数据用户的问题。比如，是否有与主题X相关的数据集或工件？与X的匹配可以与名称、描述、元数据、标签、类别等相关。与主题X相关的数据集和工件以及相关的数据用户团队有哪些？与选中的数据集相关联的元数据（如沿袭、统计、创建日期等）的细节是什么？

建立搜索服务需要三个关键模块：

索引模块

发现可用的数据集和工件，提取模式和元数据属性并将其添加到目录中。该模块需要跟踪更改并不断更新细节信息。

排序模块

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

访问控制模块

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

3.3.1　索引模块需求

根据搜索服务索引的数据集和工件的类型，索引模块需求因部署要求而异。图3-1说明了数据集和工件的不同类别。需求收集包括收集这些类别的清单和已部署技术的列表。例如，以表和模式的形式存储的结构化数据可以采用多种技术（如Oracle、SQL Server、MySQL等）进行索引。

图3-1显示了搜索服务覆盖的实体，包括数据和工件。数据集涵盖结构化数据、半结构化数据和非结构化数据。半结构化NoSQL数据集可以是键-值存储、文档存储、图形数据库、时间序列存储等。工件包括生成的洞察和方法，如ETL、notebook、即席查询、数据管道和GitHub仓库，它们都可能被重用。

另一部分需求是随着数据集和工件的不断发展而更新索引。根据更新在搜索服务中的反映方式来定义需求很重要：

• 确定索引需要以多快的速度更新用以反映变化，即确定可接受的刷新延迟。
• 跨版本和历史分区定义索引，即定义搜索范围是否仅限于当前分区。

3.3.2　排序需求

排序是相关性和流行度的权衡结果。相关性基于名称、描述和元数据属性的匹配。作为需求的一部分，我们可以定义与部署最相关的元数据属性列表。表3-1表示元数据属性的规范化模型。可以根据数据用户的需求定制元数据模型。

除了规范化元数据属性外，我们还可以捕获特定技术的元数据。例如，对于Apache HBase, hbase_namespace和hbase_column_families是特定技术的元数据的例子。这些属性可用于进一步搜索和筛选结果。

3.3.3　访问控制需求

搜索结果的访问控制策略可以根据用户的具体信息、数据属性的具体信息或两者来定义。特定于用户的策略称为基于角色的访问控制（RBAC），而特定于属性的策略称为基于属性的访问控制（ABAC）。例如，限制特定用户组的可见性是RBAC策略，为数据标记或PII定义的策略是ABAC策略。

除了访问策略外，可能还需要其他特殊处理需求：

• 屏蔽行或列的值。
• 时间变化策略，即数据集和工件在特定的时间戳之前是不可见的（例如，季度结果的表格在正式宣布结果的日期之前是不可见的）。

3.3.4　非功能性需求

以下是在设计搜索服务时应该考虑的一些关键非功能性需求（NFR）：

搜索响应时间

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

支持大型索引的扩展性

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

易于使用新的数据源

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

自动监控和告警

服务的运行状况应该易于监控。生产过程中的任何问题都应该自动生成告警。