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）：

搜索響應時間

讓搜索服務以秒為單位響應搜索查詢很重要。

支持大型索引的擴展性

隨著企業的發展，搜索服務需要擴展到支持數千個數據集和工件。

易于使用新的數據源

應簡化數據源所有者將其數據源添加到搜索服務的過程。

自動監控和告警

服務的運行狀況應該易于監控。生產過程中的任何問題都應該自動生成告警。