3.2　最小化搜索耗时

搜索耗时是反复筛选相关数据集和工件所需的总时间。考虑到查找过程的复杂性，团队经常会重新发明轮子，导致组织内存在大量数据管道、仪表盘和模型的副本。这既浪费精力，又导致更长的洞察耗时。今天，搜索耗时分别花在本节讨论的三个活动上。搜索服务的目标是最大限度地减少在每个活动中花费的时间。

3.2.1　为数据集和工件建立索引

建立索引涉及两个任务：

• 定位数据集和工件的来源。
• 探索这些数据源，以聚合模式和元数据属性等细节。

这两个任务都很耗时。目前，跨孤岛定位数据集和工件需要通过即席查询来尝试。在获取有关数据集和工件的信息时，我们会用到备忘单、wiki、口传经验等，这些都是团队知识的表现形式。但是，团队知识是有针对性的，并不总是正确的或更新的。

探索其他元数据的来源（比如模式、沿袭和执行统计等）需要特定于源技术的API或命令行接口。无论底层技术如何，都无法标准化地提取这些信息。数据用户需要与数据源所有者和团队知识合作，以聚合列名、数据类型和其他细节的含义。类似地，理解数据管道代码等工件需要分析查询逻辑以及如何重用它。考虑到技术的多样性，很难在一个通用的、可搜索的模型中表示细节。

随着新的应用程序和工件的不断开发，建立索引是一个持续的过程。加之现有的数据集和工件也在不断发展，及时跟上变化并更新结果会耗费较多时间。

3.2.2　对结果排序

现在，一个典型的搜索排序过程是从手动搜索数据存储、目录、Git仓库、仪表盘等开始的。搜索涉及在Slack群组中联系、通过wiki查找，或参加午餐研讨会以收集团队知识。由于以下现实情况，对下一阶段的分析结果进行排序会耗费很长时间：

• 表没有明确的名称或定义良好的模式。
• 表中的字段名称不恰当。
• 存在未被广泛使用或管理的低质量数据集和工件。
• 模式没有与业务的发展同步演进。
• 没有遵循模式设计的管理和最佳实践。一种常见的启发式方法（或者说捷径）就是只查看那些在各个用例中使用的、访问请求量大的流行数据资产。另外，新数据用户最好关注团队中已知数据专家的活动。

3.2.3　访问控制

访问控制需要考虑两个方面：

• 安全地连接到数据集和工件源。
• 限制对搜索结果的访问。

连接到数据源是非常耗时的，需要安全和风控团队对访问进行验证和授权。加密的源字段还需要对应的解密密钥。读请求权限可以限制允许访问的数据对象，比如选择表、视图和模式。

另一方面是将访问搜索结果的权限限制在可控范围内。限制搜索结果是在能够发现数据集或工件的存在与获得对安全属性的访问之间的平衡。