Open Source DataHub : la plateforme de recherche et de découverte de métadonnées de LinkedIn
Trouver rapidement les données dont vous avez besoin est essentiel pour toute entreprise qui s'appuie sur de grandes quantités de données pour prendre des décisions fondées sur les données. Non seulement cela a un impact sur la productivité des utilisateurs de données (y compris les analystes, les développeurs de machine learning, les data scientists et les ingénieurs de données), mais cela a également un impact direct sur les produits finaux qui dépendent d'un pipeline de machine learning (ML) de qualité. De plus, la tendance à mettre en œuvre ou à créer des plateformes d’apprentissage automatique soulève naturellement la question : quelle est votre méthode pour découvrir en interne des fonctionnalités, des modèles, des métriques, des ensembles de données, etc.
Dans cet article, nous parlerons de la façon dont nous avons publié une source de données sous licence ouverte. dans notre plateforme de recherche et de découverte de métadonnées, dès les premiers jours du projet . LinkedIn gère sa propre version de DataHub séparément de la version open source. Nous commencerons par expliquer pourquoi nous avons besoin de deux environnements de développement distincts, puis discuterons des premières approches d'utilisation de l'open source WhereHows et comparerons notre version interne (de production) de DataHub avec la version sur . Nous partagerons également des détails sur notre nouvelle solution automatisée pour envoyer et recevoir des mises à jour open source afin de synchroniser les deux référentiels. Enfin, nous fournirons des instructions sur la façon de démarrer avec le DataHub open source et discuterons brièvement de son architecture.
WhereHows est désormais un DataHub !
L'équipe métadonnées de LinkedIn précédemment présentée (successeur de WhereHows), la plateforme de recherche et de découverte de métadonnées de LinkedIn, et plans partagés pour l'ouvrir. Peu de temps après cette annonce, nous avons publié une version alpha de DataHub et l'avons partagée avec la communauté. Depuis lors, nous avons continuellement contribué au référentiel et travaillé avec les utilisateurs intéressés pour ajouter les fonctionnalités les plus demandées et résoudre les problèmes. Nous sommes maintenant heureux d'annoncer la sortie officielle .
Approches open source
WhereHows, le portail original de LinkedIn permettant de rechercher des données et d'en déterminer la provenance, a démarré comme un projet interne ; l'équipe des métadonnées l'a ouvert . Depuis lors, l'équipe a toujours maintenu deux bases de code différentes : une pour l'open source et une pour l'usage interne de LinkedIn, car toutes les fonctionnalités du produit développées pour les cas d'utilisation de LinkedIn n'étaient généralement pas applicables à un public plus large. De plus, WhereHows possède certaines dépendances internes (infrastructure, bibliothèques, etc.) qui ne sont pas open source. Dans les années qui ont suivi, WhereHows a connu de nombreuses itérations et cycles de développement, ce qui rendait la synchronisation des deux bases de code un grand défi. L’équipe des métadonnées a essayé différentes approches au fil des ans pour tenter de synchroniser le développement interne et open source.
Premier essai : "L'Open source d'abord"
Nous avons initialement suivi un modèle de développement « open source d'abord », dans lequel la plupart des développements ont lieu dans un référentiel open source et les modifications sont apportées pour le déploiement interne. Le problème avec cette approche est que le code est toujours envoyé vers GitHub avant d’être entièrement revu en interne. Jusqu'à ce que des modifications soient apportées à partir du référentiel open source et qu'un nouveau déploiement interne soit effectué, nous ne trouverons aucun problème de production. En cas de mauvais déploiement, il était également très difficile de déterminer le coupable car les modifications étaient apportées par lots.
De plus, ce modèle réduisait la productivité de l'équipe lors du développement de nouvelles fonctionnalités nécessitant des itérations rapides, car il obligeait toutes les modifications à être d'abord transférées dans un référentiel open source, puis transférées vers un référentiel interne. Pour réduire le temps de traitement, le correctif ou la modification requis pouvait d'abord être effectué dans le référentiel interne, mais cela devenait un énorme problème lorsqu'il s'agissait de fusionner ces modifications dans le référentiel open source car les deux référentiels n'étaient pas synchronisés.
Ce modèle est beaucoup plus facile à mettre en œuvre pour les plateformes partagées, les bibliothèques ou les projets d'infrastructure que pour les applications Web personnalisées complètes. De plus, ce modèle est idéal pour les projets qui démarrent l'open source dès le premier jour, mais WhereHows a été conçu comme une application Web entièrement interne. Il était vraiment difficile d'abstraire complètement toutes les dépendances internes, nous devions donc conserver le fork interne, mais conserver le fork interne et développer principalement de l'open source n'a pas vraiment fonctionné.
Deuxième tentative : « L’intérieur d’abord »
**Dans une deuxième tentative, nous sommes passés à un modèle de développement « interne d'abord », dans lequel la plupart des développements ont lieu en interne et des modifications sont apportées régulièrement au code open source. Bien que ce modèle soit le mieux adapté à notre cas d’utilisation, il présente des problèmes inhérents. Transférer directement toutes les différences vers le référentiel open source, puis essayer de résoudre les conflits de fusion ultérieurement est une option, mais cela prend du temps. Dans la plupart des cas, les développeurs essaient de ne pas faire cela à chaque fois qu'ils révisent leur code. En conséquence, cela sera effectué beaucoup moins fréquemment, par lots, ce qui rendra plus difficile la résolution ultérieure des conflits de fusion.
La troisième fois, ça a marché !
Les deux tentatives infructueuses mentionnées ci-dessus ont rendu le référentiel WhereHows GitHub obsolète pendant une longue période. L'équipe a continué à améliorer les fonctionnalités et l'architecture du produit, de sorte que la version interne de WhereHows pour LinkedIn soit devenue plus avancée que la version open source. Il avait même un nouveau nom : DataHub. Sur la base de tentatives infructueuses précédentes, l’équipe a décidé de développer une solution évolutive et à long terme.
Pour tout nouveau projet open source, l'équipe open source de LinkedIn conseille et soutient un modèle de développement dans lequel les modules du projet sont entièrement développés en open source. Les artefacts versionnés sont déployés dans un référentiel public, puis réarchivés dans l'artefact LinkedIn interne à l'aide de . Suivre ce modèle de développement est non seulement bénéfique pour ceux qui utilisent l'open source, mais aboutit également à une architecture plus modulaire, extensible et enfichable.
Cependant, une application back-end mature telle que DataHub aura besoin de beaucoup de temps pour atteindre cet état. Cela exclut également la possibilité d'ouvrir une implémentation entièrement fonctionnelle avant que toutes les dépendances internes n'aient été entièrement abstraites. C'est pourquoi nous avons développé des outils qui nous aident à apporter des contributions open source plus rapidement et avec beaucoup moins de douleur. Cette solution profite à la fois à l’équipe métadonnées (développeur DataHub) et à la communauté open source. Les sections suivantes discuteront de cette nouvelle approche.
Automatisation de la publication Open Source
La dernière approche de l'équipe Metadata concernant le DataHub open source consiste à développer un outil qui synchronise automatiquement la base de code interne et le référentiel open source. Les fonctionnalités de haut niveau de cette boîte à outils incluent :
- Synchronisez le code LinkedIn vers/depuis l'open source, similaire .
- Génération d'en-tête de licence, similaire à .
- Générez automatiquement des journaux de validation open source à partir des journaux de validation internes.
- Empêchez les changements internes qui interrompent les builds open source en .
Les sous-sections suivantes approfondiront les fonctions mentionnées ci-dessus qui présentent des problèmes intéressants.
Synchronisation du code source
Contrairement à la version open source de DataHub, qui est un référentiel GitHub unique, la version LinkedIn de DataHub est une combinaison de plusieurs référentiels (appelés en interne ). L'interface DataHub, la bibliothèque de modèles de métadonnées, le service backend de l'entrepôt de métadonnées et les tâches de streaming résident dans des référentiels distincts sur LinkedIn. Cependant, pour faciliter la tâche des utilisateurs open source, nous disposons d'un référentiel unique pour la version open source de DataHub.
Figure 1 : Synchronisation entre les référentiels LinkedIn Centre de données et un référentiel unique Centre de données Open source
Pour prendre en charge les flux de travail automatisés de création, de poussée et d'extraction, notre nouvel outil crée automatiquement un mappage au niveau du fichier correspondant à chaque fichier source. Cependant, la boîte à outils nécessite une configuration initiale et les utilisateurs doivent fournir un mappage de module de haut niveau, comme indiqué ci-dessous.
{
"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"
]
}Le mappage au niveau du module est un simple JSON dont les clés sont les modules cibles dans le référentiel open source et les valeurs sont la liste des modules sources dans les référentiels LinkedIn. Tout module cible dans un référentiel open source peut être alimenté par n'importe quel nombre de modules sources. Pour indiquer les noms internes des référentiels dans les modules sources, utilisez dans le style Bash. À l'aide d'un fichier de mappage au niveau du module, les outils créent un fichier de mappage au niveau du fichier en analysant tous les fichiers dans les répertoires associés.
{
"${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,
}Le mappage au niveau du fichier est automatiquement créé par les outils ; cependant, il peut également être mis à jour manuellement par l'utilisateur. Il s'agit d'un mappage 1:1 d'un fichier source LinkedIn vers un fichier du référentiel open source. Il existe plusieurs règles associées à cette création automatique d'associations de fichiers :
- Dans le cas de plusieurs modules sources pour un module cible en open source, des conflits peuvent survenir, par exemple le même , existant dans plusieurs modules sources. En tant que stratégie de résolution de conflits, nos outils utilisent par défaut l'option « le dernier gagne ».
- "null" signifie que le fichier source ne fait pas partie du référentiel open source.
- Après chaque soumission ou extraction open source, ce mappage est automatiquement mis à jour et un instantané est créé. Ceci est nécessaire pour identifier les ajouts et suppressions du code source depuis la dernière action.
Création de journaux de validation
Les journaux de validation pour les validations open source sont également générés automatiquement en fusionnant les journaux de validation des référentiels internes. Vous trouverez ci-dessous un exemple de journal de validation pour montrer la structure du journal de validation généré par notre outil. Une validation indique clairement quelles versions des référentiels sources sont regroupées dans cette validation et fournit un résumé du journal de validation. Vérifiez celui-ci en utilisant un exemple réel de journal de validation généré par notre boîte à outils.
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.0Tests de dépendance
LinkedIn a , ce qui permet de garantir que les modifications apportées à un multiproduit interne n'interrompent pas l'assemblage des multiproduits dépendants. Le référentiel open source DataHub n'est pas multi-produits et ne peut pas être une dépendance directe d'un multi-produit, mais avec l'aide d'un wrapper multi-produits qui récupère le code source open source DataHub, nous pouvons toujours utiliser ce test de dépendance. Ainsi, toute modification (qui peut être exposée ultérieurement) apportée à l'un des multiproduits qui alimentent le référentiel open source DataHub déclenche un événement de build dans le multiproduit shell. Par conséquent, toute modification qui ne parvient pas à créer un produit wrapper échoue aux tests avant de valider le produit d’origine et est annulée.
Il s'agit d'un mécanisme utile qui permet d'empêcher toute validation interne qui interrompt la version open source et la détecte au moment de la validation. Sans cela, il serait assez difficile de déterminer quelle validation interne a provoqué l'échec de la construction du référentiel open source, car nous regroupons les modifications internes dans le référentiel open source DataHub.
Différences entre DataHub open source et notre version de production
Jusqu'à présent, nous avons discuté de notre solution pour synchroniser deux versions des référentiels DataHub, mais nous n'avons toujours pas expliqué les raisons pour lesquelles nous avons besoin de deux flux de développement différents en premier lieu. Dans cette section, nous listerons les différences entre la version publique de DataHub et la version de production sur les serveurs LinkedIn, et expliquerons les raisons de ces différences.
Une source de divergence vient du fait que notre version de production possède des dépendances sur du code qui n'est pas encore open source, comme Offspring de LinkedIn (le framework d'injection de dépendances interne de LinkedIn). Offspring est largement utilisé dans les bases de code internes car il s'agit de la méthode privilégiée pour gérer la configuration dynamique. Mais ce n'est pas open source ; nous devions donc trouver des alternatives open source au DataHub open source.
Il y a aussi d'autres raisons. Lorsque nous créons des extensions du modèle de métadonnées pour les besoins de LinkedIn, ces extensions sont généralement très spécifiques à LinkedIn et peuvent ne pas s'appliquer directement à d'autres environnements. Par exemple, nous avons des étiquettes très spécifiques pour les identifiants des participants et d'autres types de métadonnées correspondantes. Nous avons donc désormais exclu ces extensions du modèle de métadonnées open source de DataHub. Au fur et à mesure que nous nous engageons auprès de la communauté et comprenons ses besoins, nous travaillerons sur des versions open source communes de ces extensions si nécessaire.
La facilité d'utilisation et l'adaptation plus facile pour la communauté open source ont également inspiré certaines des différences entre les deux versions de DataHub. Les différences dans l’infrastructure de traitement des flux en sont un bon exemple. Bien que notre version interne utilise un framework de traitement de flux géré, nous avons choisi d'utiliser le traitement de flux intégré (autonome) pour la version open source car cela évite de créer une autre dépendance d'infrastructure.
Un autre exemple de différence est le fait d'avoir un seul GMS (Generalized Metadata Store) dans une implémentation open source plutôt que plusieurs GMS. GMA (Generalized Metadata Architecture) est le nom de l'architecture back-end de DataHub, et GMS est le magasin de métadonnées dans le contexte de GMA. GMA est une architecture très flexible qui vous permet de distribuer chaque construction de données (par exemple, ensembles de données, utilisateurs, etc.) dans son propre magasin de métadonnées, ou de stocker plusieurs constructions de données dans un seul magasin de métadonnées, à condition que le registre contenant le mappage de la structure des données soit présent. GMS est mis à jour. Pour faciliter l'utilisation, nous avons choisi une seule instance GMS qui stocke toutes les différentes constructions de données dans le DataHub open source.
Une liste complète des différences entre les deux implémentations est donnée dans le tableau ci-dessous.
Caractéristiques du produit
Hub de données LinkedIn
Hub de données open source
Constructions de données prises en charge
1) Ensembles de données 2) Utilisateurs 3) Métriques 4) Fonctionnalités ML 5) Graphiques 6) Tableaux de bord
1) Ensembles de données 2) Utilisateurs
Sources de métadonnées prises en charge pour les ensembles de données
1) 2) Base de canapé 3) 4) 5) HDFS 6) Ruche 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Rapidement 12) 13) Teradata 13) Vecteur 14)
SGBDR Hive Kafka
Pub-sous
Kafka confluent
Traitement de flux
Géré
Intégré (autonome)
Injection de dépendances et configuration dynamique
Progéniture LinkedIn
Construire des outils
Ligradle (le wrapper Gradle interne de LinkedIn)
CI / CD
CRT (CI/CD interne de LinkedIn)
ainsi que
Magasins de métadonnées
Plusieurs GMS distribués : 1) GMS de jeu de données 2) GMS utilisateur 3) GMS métrique 4) GMS de fonctionnalités 5) GMS graphique/tableau de bord
GMS unique pour : 1) Ensembles de données 2) Utilisateurs
Microservices dans les conteneurs Docker
simplifie le déploiement et la distribution des applications avec . Chaque partie du service de DataHub est open source, y compris les composants d'infrastructure tels que Kafka, , и , possède sa propre image Docker. Pour orchestrer les conteneurs Docker que nous avons utilisés .
Figure 2 : Architecture Centre de données *Open source**
Vous pouvez voir l'architecture de haut niveau de DataHub dans l'image ci-dessus. Outre les composants d'infrastructure, il dispose de quatre conteneurs Docker différents :
datahub-gms : service de stockage de métadonnées
frontend datahub : application , au service de l'interface DataHub.
datahub-mce-consumer : application , qui utilise le flux d'événements de modification de métadonnées (MCE) et met à jour le magasin de métadonnées.
datahub-mae-consumer : application , qui utilise un flux d'événements d'audit de métadonnées (MAE) et crée un index de recherche et une base de données graphique.
Documentation du référentiel open source et contiennent des informations plus détaillées sur les fonctions de divers services.
CI/CD sur DataHub est open source
Le référentiel open source DataHub utilise pour une intégration continue et pour un déploiement continu. Les deux ont une bonne intégration GitHub et sont faciles à configurer. Pour la plupart des infrastructures open source développées par la communauté ou des entreprises privées (par ex. ), les images Docker sont créées et déployées sur Docker Hub pour faciliter leur utilisation par la communauté. Toute image Docker trouvée dans Docker Hub peut être facilement utilisée avec une simple commande .
À chaque validation dans le référentiel open source DataHub, toutes les images Docker sont automatiquement créées et déployées sur Docker Hub avec la balise « latest ». Si Docker Hub est configuré avec certains , toutes les balises du référentiel open source sont également publiées avec les noms de balises correspondants dans Docker Hub.
Utiliser DataHub
est très simple et se compose de trois étapes simples :
- Clonez le référentiel open source et exécutez tous les conteneurs Docker avec docker-compose à l'aide du script docker-compose fourni pour un démarrage rapide.
- Téléchargez les exemples de données fournis dans le référentiel à l'aide de l'outil de ligne de commande également fourni.
- Parcourez DataHub dans votre navigateur.
Suivi actif également configuré pour des questions rapides. Les utilisateurs peuvent également créer des problèmes directement dans le référentiel GitHub. Plus important encore, nous apprécions et apprécions tous les commentaires et suggestions !
Plans pour l'avenir
Actuellement, chaque infrastructure ou microservice pour DataHub open source est construit comme un conteneur Docker, et l'ensemble du système est orchestré à l'aide de . Compte tenu de la popularité et de l'étendue , nous aimerions également proposer une solution basée sur Kubernetes dans un avenir proche.
Nous prévoyons également de fournir une solution clé en main pour déployer DataHub sur un service cloud public tel que , ou . Compte tenu de l'annonce récente de la migration de LinkedIn vers Azure, cela correspondra aux priorités internes de l'équipe métadonnées.
Enfin et surtout, merci à tous les premiers utilisateurs de DataHub dans la communauté open source qui ont évalué les alphas de DataHub et nous ont aidés à identifier les problèmes et à améliorer la documentation.
Source: habr.com