オープンソース DataHub: LinkedIn のメタデータ検索および検出プラットフォーム

オープンソース DataHub: LinkedIn のメタデータ検索および検出プラットフォーム

大量のデータを利用してデータに基づく意思決定を行う企業にとって、必要なデータを迅速に見つけることは不可欠です。これは、データ ユーザー (アナリスト、機械学習開発者、データ サイエンティスト、データ エンジニアを含む) の生産性に影響を与えるだけでなく、高品質の機械学習 (ML) パイプラインに依存する最終製品にも直接影響を与えます。さらに、機械学習プラットフォームの実装または構築の傾向により、当然、「機能、モデル、メトリック、データセットなどを内部で発見する方法は何ですか」という疑問が生じます。

この記事では、オープン ライセンスの下でデータ ソースを公開する方法について説明します。 データハブ プロジェクトの最初の日から、メタデータ検索および発見プラットフォームで どこでどうやって。 LinkedIn は、オープンソース バージョンとは別に、独自のバージョンの DataHub を維持しています。まず、なぜ2つの別々の開発環境が必要なのかを説明し、次にオープンソースのWhereHowsを使用する初期のアプローチについて説明し、DataHubの内部（本番）バージョンと GitHub。また、オープンソースのアップデートをプッシュおよびプルして両方のリポジトリの同期を保つための新しい自動化ソリューションの詳細も共有します。最後に、オープンソースの DataHub の使用を開始する方法について説明し、そのアーキテクチャについて簡単に説明します。

WhereHows は DataHub になりました!

LinkedInのメタデータチームは以前、 データハブ LinkedIn のメタデータ検索および発見プラットフォームである WhereHows の後継について説明し、それを公開する計画を共有しました。この発表の直後に、DataHub のアルファ版をリリースし、コミュニティと共有しました。それ以来、私たちはリポジトリに継続的に貢献し、関心のあるユーザーと協力して、最もリクエストの多い機能を追加し、問題を解決してきました。正式リリースを発表できることを嬉しく思います GitHub 上の DataHub.

オープンソースのアプローチ

LinkedIn のデータとその出所を検索するためのオリジナルのポータルである WhereHows は、社内プロジェクトとして始まりました。メタデータチームがそれを公開しました 2016年のソースコード。それ以来、チームは常に 2 つの異なるコードベースを維持してきました。1 つはオープンソース用、もう 1 つは LinkedIn の社内使用用です。これは、LinkedIn のユースケース向けに開発されたすべての製品機能が、より広いユーザー層に一般的に適用できるわけではないためです。さらに、WhereHows にはオープンソースではない内部依存関係 (フレームワーク、ライブラリなど) がいくつかあります。その後数年間、WhereHows は多くの反復と開発サイクルを経て、2 つのコードベースの同期を維持することが大きな課題となりました。メタデータ チームは、社内開発とオープン ソース開発を同期させるために、長年にわたってさまざまなアプローチを試みてきました。

最初の試み：「オープンソースを第一に」

当初、私たちは「オープンソースファースト」の開発モデルを採用していました。このモデルでは、主な開発はオープンソースリポジトリで行われ、変更は内部展開用に行われます。このアプローチの問題点は、コードが内部で完全にレビューされる前に、必ず最初に GitHub にプッシュされることです。オープンソース リポジトリから変更が取得され、新しい内部展開が完了するまで、実稼働上の問題は発生しません。不適切なデプロイメントの場合、変更が一括して導入されたため、原因を特定することも非常に困難でした。

さらに、このモデルでは、すべての変更を最初にオープンソース リポジトリにプッシュしてから、内部リポジトリにプッシュする必要があったため、迅速な反復を必要とする新機能の開発時にチームの生産性が低下しました。処理時間を短縮するために、まず内部リポジトリで必要な修正や変更を行うこともできますが、2 つのリポジトリが同期されていないため、それらの変更をオープン ソース リポジトリにマージする際に大きな問題が生じます。

このモデルは、フル機能のカスタム Web アプリケーションよりも、一般的なプラットフォーム、ライブラリ、またはインフラストラクチャ プロジェクトに実装する方がはるかに簡単です。さらに、このモデルは初日からオープンソースで始めるプロジェクトには理想的ですが、Wh​​ereHows は完全に社内向けの Web アプリケーションとして構築されました。すべての内部依存関係を完全に抽象化するのは非常に困難だったため、内部フォークを維持する必要がありましたが、内部フォークを維持し、大部分をオープンソースで開発することはうまくいきませんでした。

2回目の試み：「まずは内部から」

** 2 度目の試みとして、私たちは「社内優先」開発モデルに移行しました。このモデルでは、主な開発は社内で行われ、オープンソース コードに定期的に変更が加えられます。このモデルは私たちのユースケースに最適ですが、独自の問題もあります。すべての相違点をオープンソース リポジトリに直接プッシュし、後でマージの競合を解決しようとすることも選択肢の 1 つですが、時間がかかります。ほとんどの場合、開発者はコードをチェックするたびにこれを行わないようにします。その結果、これはバッチで実行される頻度が大幅に減り、その後のマージ競合の解決がより困難になります。

3回目ですべてうまくいきました！

上記の 2 回の失敗した試みの結果、WhereHows GitHub リポジトリは長い間古いままになってしまいました。チームは製品の機能とアーキテクチャの改良を続け、WhereHows for LinkedIn の社内バージョンはオープンソース バージョンよりも進化しました。新しい名前も DataHub になりました。チームは、これまでの失敗した試みに基づいて、スケーラブルで長期的なソリューションを開発することを決定しました。

LinkedIn のオープンソース チームは、新しいオープンソース プロジェクトに対して、プロジェクトのモジュールが完全にオープンソースで開発される開発モデルについてアドバイスとサポートを提供します。バージョン管理された成果物はパブリックリポジトリにデプロイされ、その後LinkedInの内部成果物にプッシュバックされます。 外部ライブラリリクエスト（ELR）。この開発モデルに従うことは、オープンソースを使用する人にとって有益であるだけでなく、よりモジュール化され、拡張可能で、プラグ可能なアーキテクチャをもたらします。

ただし、DataHub のような成熟した内部アプリケーションがこの状態に到達するには、かなりの時間がかかります。これにより、すべての内部依存関係が完全に抽象化される前に、完全に機能する実装をオープンソース化する可能性も排除されます。そこで私たちは、オープンソースへの貢献をより迅速かつ容易に行えるツールを開発しました。このソリューションは、メタデータ チーム (DataHub の開発者) とオープン ソース コミュニティの両方にメリットをもたらします。次のセクションでは、この新しいアプローチについて説明します。

オープンソース公開の自動化

メタデータ グループのオープン ソース DataHub に対する最新のアプローチは、内部コードベースとオープン ソース リポジトリを自動的に同期するツールを開発することです。このツールキットの主な機能は次のとおりです。

1. LinkedInのコードをオープンソースと同期する、類似の rsync.
2. 次のようなライセンスヘッダーを生成します アパッチラット.
3. 内部コミット ログからオープン ソース コミット ログを自動的に生成します。
4. 内部の変更がオープンソースビルドを壊すのを防ぐには 依存性テスト.

以下のサブセクションでは、興味深い問題を抱える上記の関数について詳しく説明します。

ソースコード同期

単一のGitHubリポジトリであるDataHubのオープンソース版とは異なり、DataHubのLinkedIn版は複数のリポジトリ（内部的には 複数の製品）。 DataHub インターフェース、メタデータ モデル ライブラリ、メタデータ ストア バックエンド サービス、ストリーミング ジョブは、LinkedIn 上の異なるリポジトリにあります。ただし、オープンソース ユーザーの利便性を考えて、DataHub のオープンソース バージョン用のリポジトリを 1 つ用意しています。

図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"
  ]
}

モジュール レベルのマッピングは、キーがオープン ソース リポジトリ内のターゲット モジュールであり、値が LinkedIn のリポジトリ内のソース モジュールのリストである単純な JSON です。オープンソース リポジトリ内の任意のターゲット モジュールは、任意の数のソース モジュールにフィードできます。ソースモジュール内の内部リポジトリ名を示すには、 文字列補間 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 マッピングです。この自動ファイル マッピング作成には、いくつかのルールが関連しています。

• オープンソースのターゲットモジュールに複数のソースモジュールがある場合、例えば同じ FQCN複数のソース モジュールに存在します。私たちのツールは、競合解決戦略として、デフォルトで「最後の 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

依存性テスト

LinkedInは 依存性テストインフラストラクチャこれにより、内部のマルチプロダクトへの変更によって、依存するマルチプロダクトのビルドが壊れることがなくなります。オープンソースの DataHub リポジトリはマルチプロダクトではないため、どのマルチプロダクトにも直接依存することはできませんが、オープンソースの DataHub ソースコードを取得するマルチプロダクト ラッパーを使用することで、この依存関係テスト システムを引き続き使用できます。したがって、オープンソースの DataHub リポジトリにフィードするマルチプロダクトのいずれかの変更 (後でオープンソース化される可能性があります) は、ラッパー マルチプロダクトでビルド イベントをトリガーします。したがって、シェルのマルチプロダクトの構築を許可しない変更は、元のマルチプロダクトがコミットされて元に戻される前にテストに失敗します。

これは、オープンソース ビルドを壊す内部コミットを防ぎ、コミット時にそれを検出するのに役立つ便利なメカニズムです。これがないと、内部変更のバッチをオープンソースの DataHub リポジトリにプッシュするため、どの内部コミットがオープンソース リポジトリのビルドの失敗の原因となったかを特定するのが非常に難しくなります。

オープンソースのDataHubと製品版の違い

ここまで、2 つのバージョンの DataHub リポジトリを同期させるためのソリューションについて説明してきましたが、そもそも 2 つの異なる開発ストリームが必要な理由についてはまだ説明していません。このセクションでは、DataHub のパブリック バージョンと LinkedIn のサーバー上の製品バージョンの違いをリストし、それらの違いの理由について説明します。

矛盾の原因の 1 つは、製品版が LinkedIn の Offspring (LinkedIn の内部依存性注入フレームワーク) など、まだオープン ソースではないコードに依存しているという事実です。 Offspring は動的構成を管理するための推奨方法であるため、内部コードベースで広く使用されています。しかし、これはオープンソースではありません。そのため、オープンソースの DataHub に代わるオープンソースの代替品を見つける必要がありました。

他にも理由はあります。 LinkedIn のニーズに合わせてメタデータ モデルの拡張機能を作成すると、これらの拡張機能は通常 LinkedIn に特有のものとなり、他の環境に直接適用されない可能性があります。たとえば、参加者 ID やその他の種類のコンプライアンス メタデータには非常に具体的なラベルがあります。そのため、これらの拡張機能はオープンソースの DataHub メタデータ モデルから除外されました。私たちはコミュニティと関わり、そのニーズを理解しながら、必要に応じてこれらの拡張機能の一般的なオープンソース バージョンに取り組んでいきます。

使いやすさとオープンソース コミュニティによる採用のしやすさも、DataHub の 2 つのバージョン間の違いの一部につながっています。ストリーム処理インフラストラクチャの違いが良い例です。社内バージョンではマネージド ストリーム処理フレームワークを使用していますが、別のインフラストラクチャ依存関係の作成を回避するため、オープン ソース バージョンでは組み込み (スタンドアロン) ストリーム処理を使用することにしました。

違いのもう 1 つの例として、オープン ソース実装には複数の GMS (一般化メタデータ ストア) ではなく 1 つの GMS が存在することが挙げられます。 GMA (Generalized Metadata Architecture) は DataHub の内部アーキテクチャの名前であり、GMS は GMA のコンテキスト内のメタデータ ストアです。 GMA は非常に柔軟なアーキテクチャであり、データ構造と GMS のマッピングを含むレジストリが更新されている限り、各データ構造 (データセット、ユーザーなど) を独自のメタデータ ストアに分散したり、複数のデータ構造を単一のメタデータ ストアに保存したりすることができます。使いやすさを考慮して、オープンソースの DataHub 内のさまざまなデータ構造をすべて保存する単一の GMS インスタンスを選択しました。

2 つの実装間の違いの完全なリストを以下の表に示します。

製品の特徴
LinkedIn データハブ
オープンソースデータハブ

サポートされているデータ構造
1) データセット 2) ユーザー 3) 指標 4) ML 機能 5) チャート 6) ダッシュボード
1) データセット 2) ユーザー

データセットでサポートされているメタデータソース
1) アンブリー 2) カウチベース 3) ダリッド 4) エスプレッソ 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) ピノ 12) プレスト 12) 海 13) テラデータ 13) ベクター 14) ヴェネツィア
Hive Kafka RDBMS

パブリッシュ/サブスク
LinkedIn カフカ
合流型カフカ

ストリーム処理
管理
組み込み（スタンドアロン）

依存性注入と動的構成
LinkedInの子孫
春

ビルドツール
Ligradle (LinkedIn の内部 Gradle ラッパー)
グラドルフ

CI / CD
CRT（LinkedIn の社内 CI/CD）
トラビスCI の三脚と Dockerハブ

メタデータストア
分散型複数の GMS: 1) データセット GMS 2) ユーザー GMS 3) メトリック GMS 4) 機能 GMS 5) チャート/ダッシュボード GMS
1) データセット 2) ユーザー用の単一 GMS

Dockerコンテナ内のマイクロサービス

デッカー アプリケーションの導入と配布を簡素化します コンテナ化。 DataHubのサービスのすべての部分はオープンソースであり、Kafkaなどのインフラストラクチャコンポーネントも含まれています。 Elasticsearch, Neo4j и MySQLには独自の Docker イメージがあります。 Dockerコンテナをオーケストレーションするために、 ドッカーの作成.

図2: アーキテクチャ データハブ *オープンソース**

上の図で、DataHub の高レベルアーキテクチャを確認できます。インフラストラクチャ コンポーネントに加えて、次の 4 つの異なる Docker コンテナがあります。

datahub-gms: メタデータストレージサービス

データハブフロントエンド: アプリケーション プレイDataHub インターフェースを提供します。

datahub-mce-consumer: アプリケーション カフカストリームメタデータ変更イベント (MCE) ストリームを消費し、メタデータ ストアを更新します。

datahub-mae-consumer: アプリケーション カフカストリームは、メタデータ監査イベント (MAE) ストリームを使用して、検索インデックスとグラフ データベースを作成します。

オープンソースリポジトリのドキュメントと DataHubブログのオリジナル投稿 さまざまなサービスの機能に関するより詳細な情報が含まれています。

オープンソース DataHub の CI/CD

オープンソースのDataHubリポジトリは トラビスCI 継続的インテグレーションと Dockerハブ 継続的なデプロイメント用。どちらも GitHub と適切に統合されており、セットアップも簡単です。コミュニティや民間企業によって開発されるほとんどのオープンソース インフラストラクチャ (例: ジャンクショ​​ン)、Docker イメージが作成され、コミュニティが簡単に使用できるように Docker Hub にデプロイされます。 Docker HubにあるDockerイメージは簡単なコマンドで簡単に使用できます。 ドッカープル.

DataHub オープンソース リポジトリにコミットするたびに、すべての Docker イメージが自動的にビルドされ、「最新」タグが付けられて Docker Hub にデプロイされます。 Docker Hubにいくつかの設定がされている場合 正規表現ブランチの命名オープンソース リポジトリ内のすべてのタグは、対応するタグ名とともに Docker Hub でもリリースされます。

DataHubの使用

DataHubの設定 非常にシンプルで、次の 3 つの簡単なステップで構成されています。

1. オープンソース リポジトリのクローンを作成し、提供されている docker-compose クイックスタート スクリプトを使用して、すべての Docker コンテナーを docker-compose で実行します。
2. 提供されているコマンドライン ツールを使用して、リポジトリで提供されているサンプル データをダウンロードします。
3. ブラウザで DataHub を表示します。

積極的に監視 Gitterチャット 簡単な質問にも対応します。ユーザーは GitHub リポジトリ内で直接問題を作成することもできます。最も重要なことは、すべてのフィードバックと提案を歓迎し、感謝することです。

将来の計画

現在、オープンソースのDataHubの各インフラストラクチャまたはマイクロサービスはDockerコンテナとして構築されており、システム全体は ドッカーの作成。人気と幅広い使用を考えると Kubernetes近い将来には Kubernetes ベースのソリューションも提供したいと考えています。

また、DataHubをパブリッククラウドサービスに導入するためのターンキーソリューションも提供する予定です。 Azure, AWS または Googleクラウド。 LinkedIn が最近 Azure への移行を発表したことを考えると、これはメタデータ チームの内部優先事項と一致することになります。

最後になりましたが、DataHub のアルファ バージョンをレビューし、問題の特定とドキュメントの改善にご協力いただいたオープン ソース コミュニティの DataHub 早期導入者の皆さんに感謝申し上げます。

出所： habr.com