🥇開源 DataHub：LinkedIn 的搜尋和元資料發現平台

開源 DataHub：LinkedIn 元數據搜索和發現平台

對於任何依賴大量數據來制定數據驅動決策的公司來說，快速找到所需的數據至關重要。這不僅會影響資料使用者（包括分析師、機器學習開發人員、資料科學家和資料工程師）的生產力，還會對依賴高品質機器學習 (ML) 管道的最終產品產生直接影響。此外，實施或建構機器學習平台的趨勢自然提出了一個問題：內部發現特徵、模型、指標、資料集等的方法是什麼。

在本文中，我們將討論如何在開放許可下發布資料來源數據中心在我們的元資料搜尋和發現平台中，從專案的早期開始哪裡如何。 LinkedIn 獨立於開源版本維護自己的 DataHub 版本。我們將首先解釋為什麼我們需要兩個獨立的開發環境，然後討論使用開源WhereHows的早期方法，並將我們的DataHub內部（生產）版本與上的版本進行比較 GitHub上。我們還將分享有關推送和接收開源更新以保持兩個儲存庫同步的新自動化解決方案的詳細資訊。最後，我們將提供有關如何開始使用開源 DataHub 的說明，並簡要討論其架構。

WhereHows 現在是一個資料中心！

LinkedIn 的元資料團隊之前介紹過數據中心（WhereHows 的後繼者），LinkedIn 的搜尋和元資料發現平台，並分享了開放該平台的計劃。在此公告發布後不久，我們發布了 DataHub 的 alpha 版本並與社群分享。從那時起，我們不斷為儲存庫做出貢獻，並與感興趣的用戶合作，添加最需要的功能並解決問題。我們現在很高興地宣布正式發布 GitHub 上的資料中心.

開源方法

WhereHows 是 LinkedIn 最初用於查找資料及其來源的門戶，最初是一個內部專案；元數據團隊打開了它 2016年的原始碼。從那時起，該團隊始終維護兩種不同的程式碼庫——一種用於開源，一種用於LinkedIn 內部使用——因為並非所有為LinkedIn 用例開發的產品功能都普遍適用於更廣泛的受眾。此外，WhereHows 有一些非開源的內部相依性（基礎設施、函式庫等）。在接下來的幾年裡，WhereHows 經歷了多次迭代和開發週期，這使得保持兩個程式碼庫同步成為一個巨大的挑戰。多年來，元資料團隊嘗試了不同的方法，試圖保持內部和開源開發同步。

第一次嘗試：“開源第一”

我們最初遵循「開源優先」的開發模型，其中大多數開發發生在開源儲存庫中，並針對內部部署進行更改。這種方法的問題在於，程式碼總是先推送到 GitHub，然後再進行內部全面審查。在對開源儲存庫進行更改並進行新的內部部署之前，我們不會發現任何生產問題。如果部署不佳，也很難確定罪魁禍首，因為變更是大量進行的。

此外，該模型在開發需要快速迭代的新功能時降低了團隊的生產力，因為它迫使所有變更首先推送到開源儲存庫，然後推送到內部儲存庫。為了減少處理時間，可以先在內部儲存庫中完成所需的修復或更改，但是當將這些更改合併回開源儲存庫時，這會成為一個巨大的問題，因為這兩個儲存庫不同步。

與全功能自訂 Web 應用程式相比，此模型對於共用平台、程式庫或基礎架構專案更容易實現。此外，此模型非常適合從第一天開始開源的項目，但WhereHows 是作為完全內部的 Web 應用程式建構的。要完全抽象化所有內部依賴項確實很困難，因此我們需要保留內部分叉，但保留內部分叉並開發大部分開源程式碼並不太有效。

第二次嘗試：“內在第一”

**作為第二次嘗試，我們轉向「內部優先」開發模式，其中大多數開發都在內部進行，並定期對開源程式碼進行更改。儘管該模型最適合我們的用例，但它存在固有的問題。直接將所有差異推送到開源儲存庫，然後稍後嘗試解決合併衝突是一種選擇，但這很耗時。在大多數情況下，開發人員盡量不要在每次檢查程式碼時都這樣做。因此，批量執行此操作的頻率會大大降低，從而使以後解決合併衝突變得更加困難。

第三次就成功了！

上述兩次失敗的嘗試導致WhereHows GitHub 儲存庫在很長一段時間內仍然過時。團隊不斷改進產品的功能和架構，使得WhereHows for LinkedIn的內部版本變得比開源版本更加先進。它甚至還有一個新名稱——DataHub。基於先前的失敗嘗試，團隊決定開發一個可擴展的長期解決方案。

對於任何新的開源項目，LinkedIn 的開源團隊都會建議並支援開發模式，其中專案的模組完全以開源方式開發。版本化工件部署到公共儲存庫，然後使用下列命令重新簽入內部 LinkedIn 工件外部庫請求 (ELR)。遵循這種開發模型不僅有利於那些使用開源的人，而且還可以產生更模組化、可擴展和可插拔的架構。

然而，成熟的後端應用程式（例如 DataHub）將需要大量時間才能達到此狀態。這也排除了在所有內部依賴關係完全抽象化之前開源完全工作的實現的可能性。這就是為什麼我們開發了一些工具來幫助我們更快、更輕鬆地做出開源貢獻。此解決方案對元資料團隊（DataHub 開發人員）和開源社群都有好處。以下各節將討論這種新方法。

開源出版自動化

Metadata 團隊對開源 DataHub 的最新方法是開發一個自動同步內部程式碼庫和開源儲存庫的工具。該工具包的高級功能包括：

將 LinkedIn 程式碼與開源同步，類似 rsync的.
許可證頭生成，類似於阿帕契鼠.
從內部提交日誌自動產生開源提交日誌。
防止破壞開源建置的內部更改依賴性測試.

以下小節將深入研究上述有趣問題的函數。

原始碼同步

與開源版本的 DataHub 不同，DataHub 是單一 GitHub 儲存庫，LinkedIn 版本的 DataHub 是多個儲存庫的組合（內部稱為多產品）。 DataHub 介面、元資料模型庫、元資料倉儲後端服務和串流作業駐留在 LinkedIn 上的單獨儲存庫。但是，為了讓開源使用者更容易使用，我們為 DataHub 的開源版本提供了一個儲存庫。

圖 1：儲存庫之間的同步 LinkedIn 數據中心 和一個儲存庫 數據中心 開源

為了支援自動建置、推送和拉取工作流程，我們的新工具會自動建立與每個來源檔案相對應的檔案層級對應。但是，該工具包需要初始配置，且使用者必須提供高級模組映射，如下所示。

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

模組級映射是一個簡單的 JSON，其鍵是開源儲存庫中的目標模組，值是 LinkedIn 儲存庫中的來源模組清單。開源儲存庫中的任何目標模組都可以由任意數量的來源模組提供。若要指示來源模組中儲存庫的內部名稱，請使用字串插值以 Bash 風格。使用模組級映射文件，這些工具透過掃描關聯目錄中的所有文件來建立文件級映射檔案。

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

文件級映射由工具自動建立；但是，它也可以由使用者手動更新。這是 LinkedIn 原始檔到開源儲存庫中檔案的 1:1 映射。有幾個與自動建立文件關聯相關的規則：

在開源的目標模組有多個來源模組的情況下，可能會出現衝突，例如相同的模組完全質量控製網絡，存在於多個來源模組中。作為一種衝突解決策略，我們的工具預設為「最後一個獲勝」選項。
「null」表示原始檔案不屬於開源儲存庫。
每次開源提交或提取後，該映射都會自動更新並建立快照。這對於識別自上次操作以來源程式碼中的新增和刪除是必要的。

建立提交日誌

開源提交的提交日誌也是透過合併內部儲存庫的提交日誌自動產生的。下面是一個範例提交日誌，顯示了我們的工具產生的提交日誌的結構。提交清楚地表明該提交中打包了來源儲存庫的哪些版本，並提供提交日誌的摘要。看看這個犯罪使用我們的工具包產生的提交日誌的真實範例。

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

依賴性測試

領英有依賴測試基礎設施，這有助於確保對內部多產品的更改不會破壞相關多產品的組裝。開源DataHub儲存庫不是多產品，它不能是任何多產品的直接依賴項，但是藉助獲取開源DataHub原始碼的多產品包裝器，我們仍然可以使用此依賴項測試因此，對提供開源DataHub 儲存庫的任何多產品的任何變更（稍後可能會公開）都會觸發shell 多產品中的建置事件。因此，任何無法建立包裝產品的更改都會在提交原始產品之前通過測試並被恢復。

這是一種有用的機制，有助於防止任何破壞開源建置的內部提交，並在提交時檢測到它。如果沒有這個，就很難確定哪個內部提交導致開源儲存庫建置失敗，因為我們批量對 DataHub 開源儲存庫進行內部變更。

開源 DataHub 和我們的生產版本之間的差異

到目前為止，我們已經討論了同步兩個版本的 DataHub 儲存庫的解決方案，但我們仍然沒有概述為什麼我們首先需要兩個不同的開發流程的原因。在本節中，我們將列出 DataHub 的公共版本和 LinkedIn 伺服器上的生產版本之間的差異，並解釋這些差異的原因。

差異的一個根源在於我們的生產版本依賴尚未開源的程式碼，例如 LinkedIn 的 Offspring（LinkedIn 的內部依賴注入框架）。 Offspring 廣泛用於內部程式碼庫，因為它是管理動態配置的首選方法。但它不是開源的；因此我們需要找到開源 DataHub 的開源替代品。

還有其他原因。當我們根據 LinkedIn 的需求建立元資料模型的擴充時，這些擴充功能通常非常特定於 LinkedIn，可能無法直接應用於其他環境。例如，我們為參與者 ID 和其他類型的匹配元資料提供非常具體的標籤。因此，我們現在已將這些擴充功能從 DataHub 的開源元資料模型中排除。當我們與社群互動並了解他們的需求時，我們將在需要時開發這些擴充功能的通用開源版本。

易於使用和更容易適應開源社群也激發了兩個版本的 DataHub 之間的一些差異。流處理基礎設施的差異就是一個很好的例子。儘管我們的內部版本使用託管流處理框架，但我們選擇對開源版本使用內建（獨立）流處理，因為它避免創建另一個基礎設施依賴項。

差異的另一個例子是在開源實作中使用單一 GMS（通用元資料儲存）而不是多個 GMS。 GMA（通用元資料架構）是DataHub後端架構的名稱，GMS是GMA上下文中的元資料儲存。 GMA 是一種非常靈活的架構，可讓您將每個資料建構（例如資料集、使用者等）分發到自己的元資料儲存中，或將多個資料建構儲存在單一元資料儲存中，只要註冊表中包含資料結構映射即可GMS 已更新。為了方便使用，我們選擇了一個 GMS 實例，將所有不同的資料結構儲存在開源 DataHub 中。

下表給出了兩種實現之間差異的完整列表。

產品特點
領英資料中心
開源資料中心

支援的資料結構
1) 資料集 2) 使用者 3) 指標 4) ML 功能 5) 圖表 6) 儀表板
1) 資料集 2) 用戶

資料集支援的元資料來源
1) 安布里 2) 沙發底座 3) 達利茲 4) 表示 5) HDFS 6) Hive 7) 卡夫卡 8) MongoDB 9) MySQL 10) Oracle 11) 黑 12) 急速 12) 是 13) Teradata 13) 向量 14) 威尼斯
Hive Kafka RDBMS

發布-訂閱
卡夫卡
匯流卡夫卡

流處理
管理
嵌入式（獨立）

依賴注入和動態配置
領英後代
彈簧

建構工具
Ligradle（LinkedIn 的內部 Gradle 包裝）
格拉德魯

CI / CD
CRT（LinkedIn 的內部 CI/CD）
特拉維斯CI 和 Docker中心

元資料儲存
分佈式多個GMS：1）資料集GMS 2）使用者GMS 3）指標GMS 4）特徵GMS 5）圖表/儀表板GMS
單一 GMS 適用於：1) 資料集 2) 用戶

Docker 容器中的微服務

碼頭工人簡化應用程式部署和分發貨櫃化。 DataHub中服務的每個部分都是開源的，包括Kafka等基礎設施元件， Elasticsearch, 新4j и MySQL的，有自己的Docker映像。為了編排 Docker 容器，我們使用了 Docker撰寫.

圖 2：架構 數據中心 *開源**

您可以在上圖中看到 DataHub 的高階架構。除了基礎設施元件之外，它還有四個不同的 Docker 容器：

datahub-gms：元資料儲存服務

資料中心前端：應用程式播放，服務於 DataHub 介面。

datahub-mce-consumer：應用程式卡夫卡流，它使用元資料更改事件 (MCE) 流並更新元資料儲存。

數據集線器-mae-消費者：應用程式卡夫卡流，它使用元資料審核事件流 (MAE) 並建立搜尋索引和圖形資料庫。

開源儲存庫文件和原始 DataHub 部落格文章包含有關各種服務功能的更詳細資訊。

DataHub 上的 CI/CD 是開源的

開源 DataHub 儲存庫使用特拉維斯CI 用於持續整合和 Docker中心用於持續部署。兩者都具有良好的 GitHub 整合並且易於設定。對於大多數由社區或私人公司開發的開源基礎設施（例如匯合），Docker 映像被建立並部署到 Docker Hub 以便於社群使用。 Docker Hub 中找到的任何 Docker 映像都可以透過簡單的命令輕鬆使用碼頭工人拉.

每次提交到 DataHub 開源儲存庫時，所有 Docker 映像都會自動建置並使用「最新」標籤部署到 Docker Hub。如果 Docker Hub 配置了一些命名正規表示式分支，開源倉庫中的所有標籤也在 Docker Hub 中以對應的標籤名稱發布。

使用資料中心

設定資料中心非常簡單，由三個簡單的步驟組成：

複製開源儲存庫並使用提供的 docker-compose 腳本透過 docker-compose 運行所有 Docker 容器以快速啟動。
使用也提供的命令列工具下載儲存庫中提供的範例資料。
在瀏覽器中瀏覽 DataHub。

主動追蹤吉特聊天也配置了快速提問。用戶還可以直接在 GitHub 儲存庫中建立問題。最重要的是，我們歡迎並感謝所有回饋和建議！

Планынабудущее

目前，開源 DataHub 的每個基礎設施或微服務都是作為 Docker 容器建構的，整個系統是使用泊塢窗，撰寫。鑑於受歡迎程度和廣泛 Kubernetes，我們也希望在不久的將來提供基於 Kubernetes 的解決方案。

我們還計劃提供在公有雲服務上部署 DataHub 的交鑰匙解決方案，例如天藍, AWS 或 Google雲端。鑑於 LinkedIn 最近宣布遷移到 Azure，這將符合元資料團隊的內部優先事項。

最後但並非最不重要的一點是，感謝開源社群中所有 DataHub 的早期採用者，他們對 DataHub 進行了 alpha 評級，並幫助我們發現問題並改進文件。

來源： www.habr.com