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的策略有效期可以將策略配置為在指定的時間范圍內有效，例如，在收益發布日前限制對敏感財務信息的訪問。

目錄訪問控制模式的優點：

• 如果目錄級別上有集中的訪問控制策略，則很容易進行管理。
• 它提供基于不同用戶和用例的可配置訪問控制。

目錄訪問控制模式的缺點：

• 目錄訪問控制策略可能與數據源策略不同步。例如，數據用戶可以根據目錄策略訪問元數據，但不能根據后端源策略訪問實際數據集。

目錄訪問模式是平衡可發現性和訪問控制的必備工具，它具有很強的靈活性，既可以采用簡單的啟發式方法，也支持復雜的細粒度授權以及屏蔽。