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

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

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

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

WhereHows は DataHub になりました。

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

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

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

まずは試してみましょう: 「まずはオープンソース」

私たちは当初、「オープンソースファースト」の開発モデルに従いました。このモデルでは、ほとんどの開発はオープンソースリポジトリで行われ、変更は内部デプロイメントのために行われます。 このアプローチの問題は、コードが内部で完全にレビューされる前に常に最初に GitHub にプッシュされることです。 オープンソース リポジトリから変更が加えられ、新しい内部デプロイメントが行われるまで、運用上の問題は見つかりません。 導入が不十分な場合、変更はバッチで行われるため、原因を特定することも非常に困難でした。

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

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

XNUMX回目の試み：「内側ファースト」

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

XNUMX回目でうまくいきました！

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

新しいオープンソース プロジェクトについては、LinkedIn のオープンソース チームが、プロジェクトのモジュールを完全にオープンソースで開発する開発モデルをアドバイスおよびサポートします。 バージョン管理されたアーティファクトはパブリック リポジトリにデプロイされ、次を使用して内部 LinkedIn アーティファクトにチェックインされます。 外部ライブラリリクエスト (ELR)。 この開発モデルに従うことは、オープンソースを使用するユーザーにとって良いだけでなく、よりモジュール化され、拡張可能でプラグイン可能なアーキテクチャにもなります。

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

オープンソースのパブリッシングオートメーション

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

1. LinkedIn コードをオープン ソースとの間で同期する (同様の) rsync.
2. ライセンスヘッダーの生成、同様 アパッチラット.
3. 内部コミット ログからオープンソース コミット ログを自動的に生成します。
4. オープンソース ビルドを破壊する内部変更を防ぐには、次の方法があります。 依存関係のテスト.

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

ソースコードの同期

単一の GitHub リポジトリであるオープン ソース バージョンの DataHub とは異なり、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"
  ]
}

モジュール レベルのマッピングは、キーがオープン ソース リポジトリ内のターゲット モジュール、値が LinkedIn リポジトリ内のソース モジュールのリストである単純な JSON です。 オープンソース リポジトリ内のターゲット モジュールには、任意の数のソース モジュールを供給できます。 ソースモジュール内のリポジトリの内部名を示すには、次を使用します。 文字列補間 バッシュスタイルで。 このツールは、モジュール レベルのマッピング ファイルを使用して、関連するディレクトリ内のすべてのファイルをスキャンして、ファイル レベルのマッピング ファイルを作成します。

{
  "${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、複数のソース モジュールに存在します。 競合解決戦略として、当社のツールはデフォルトで「最後に勝つ」オプションを設定しています。
• 「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 と製品バージョンの違い

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

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

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

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

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

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

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

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

データセットでサポートされているメタデータ ソース
1) アンブリー 2) カウチベース 3) ダリド 4) エスプレッソ 5) HDFS 6) ハイブ 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
単一 GMS 用: 1) データセット 2) ユーザー

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

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

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

上の画像で、DataHub の高レベルのアーキテクチャを確認できます。 インフラストラクチャ コンポーネントに加えて、次の XNUMX つの異なる 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 内の対応するタグ名とともにリリースされます。

データハブの使用

データハブのセットアップ は非常にシンプルで、次の XNUMX つの簡単な手順で構成されます。

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

アクティブに追跡されています ギッターチャット 簡単な質問用にも構成されています。 ユーザーは、GitHub リポジトリで直接問題を作成することもできます。 最も重要なことは、すべてのフィードバックや提案を歓迎し、感謝することです。

将来の計画

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

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

最後になりましたが、DataHub アルファを評価し、問題の特定とドキュメントの改善に協力してくれたオープン ソース コミュニティの DataHub の初期導入者全員に感謝します。

出所： habr.com