DataHub de código aberto: plataforma de pesquisa e descoberta de metadados do LinkedIn
Encontrar rapidamente os dados necessários é essencial para qualquer empresa que depende de grandes quantidades de dados para tomar decisões baseadas em dados. Isso não afeta apenas a produtividade dos usuários de dados (incluindo analistas, desenvolvedores de aprendizado de máquina, cientistas de dados e engenheiros de dados), mas também tem um impacto direto nos produtos finais que dependem de um pipeline de aprendizado de máquina (ML) de qualidade. Além disso, a tendência de implementação ou construção de plataformas de aprendizado de máquina levanta naturalmente a questão: qual é o seu método para descobrir internamente recursos, modelos, métricas, conjuntos de dados, etc.
Neste artigo falaremos sobre como publicamos uma fonte de dados sob uma licença aberta em nossa plataforma de busca e descoberta de metadados, desde os primeiros dias do projeto . O LinkedIn mantém sua própria versão do DataHub separada da versão de código aberto. Começaremos explicando por que precisamos de dois ambientes de desenvolvimento separados, depois discutiremos as abordagens iniciais para usar o WhereHows de código aberto e compararemos nossa versão interna (de produção) do DataHub com a versão em . Também compartilharemos detalhes sobre nossa nova solução automatizada para enviar e receber atualizações de código aberto para manter os dois repositórios sincronizados. Por fim, forneceremos instruções sobre como começar a usar o DataHub de código aberto e discutiremos brevemente sua arquitetura.
WhereHows agora é um DataHub!
A equipe de metadados do LinkedIn apresentou anteriormente (sucessor do WhereHows), plataforma de pesquisa e descoberta de metadados do LinkedIn, e planos compartilhados para abri-la. Pouco depois deste anúncio, lançamos uma versão alfa do DataHub e a compartilhamos com a comunidade. Desde então, contribuímos continuamente com o repositório e trabalhamos com usuários interessados para adicionar os recursos mais solicitados e resolver problemas. Temos agora o prazer de anunciar o lançamento oficial .
Abordagens de código aberto
WhereHows, portal original do LinkedIn para encontrar dados e de onde eles vêm, começou como um projeto interno; a equipe de metadados abriu . Desde então, a equipe sempre manteve duas bases de código diferentes – uma para código aberto e outra para uso interno do LinkedIn – já que nem todos os recursos de produtos desenvolvidos para casos de uso do LinkedIn eram geralmente aplicáveis ao público mais amplo. Além disso, WhereHows possui algumas dependências internas (infraestrutura, bibliotecas, etc.) que não são de código aberto. Nos anos que se seguiram, WhereHows passou por muitas iterações e ciclos de desenvolvimento, tornando um grande desafio manter as duas bases de código sincronizadas. A equipe de metadados tentou diferentes abordagens ao longo dos anos para tentar manter sincronizados o desenvolvimento interno e de código aberto.
Primeira tentativa: "Código aberto primeiro"
Inicialmente seguimos um modelo de desenvolvimento "código aberto primeiro", onde a maior parte do desenvolvimento ocorre em um repositório de código aberto e as alterações são feitas para implantação interna. O problema com essa abordagem é que o código sempre é enviado primeiro ao GitHub, antes de ser totalmente revisado internamente. Até que alterações sejam feitas no repositório de código aberto e uma nova implantação interna seja feita, não encontraremos nenhum problema de produção. No caso de uma implantação inadequada, também era muito difícil determinar o culpado porque as alterações eram feitas em lotes.
Além disso, esse modelo reduziu a produtividade da equipe no desenvolvimento de novos recursos que exigiam iterações rápidas, pois forçava todas as alterações a serem primeiro enviadas para um repositório de código aberto e depois enviadas para um repositório interno. Para reduzir o tempo de processamento, a correção ou alteração necessária poderia ser feita primeiro no repositório interno, mas isso se tornou um grande problema quando se tratava de mesclar essas alterações de volta no repositório de código aberto porque os dois repositórios estavam fora de sincronia.
Este modelo é muito mais fácil de implementar para plataformas compartilhadas, bibliotecas ou projetos de infraestrutura do que para aplicativos web personalizados com todos os recursos. Além disso, este modelo é ideal para projetos que iniciam o código aberto desde o primeiro dia, mas o WhereHows foi construído como um aplicativo web totalmente interno. Foi realmente difícil abstrair completamente todas as dependências internas, então precisávamos manter a bifurcação interna, mas manter a bifurcação interna e desenvolver principalmente código aberto não funcionou muito bem.
Segunda tentativa: “Interior primeiro”
**Como uma segunda tentativa, mudamos para um modelo de desenvolvimento "interno primeiro", onde a maior parte do desenvolvimento ocorre internamente e as alterações são feitas regularmente no código-fonte aberto. Embora este modelo seja mais adequado para nosso caso de uso, ele apresenta problemas inerentes. Enviar diretamente todas as diferenças para o repositório de código aberto e depois tentar resolver os conflitos de mesclagem posteriormente é uma opção, mas consome muito tempo. Na maioria dos casos, os desenvolvedores tentam não fazer isso toda vez que revisam seu código. Como resultado, isso será feito com muito menos frequência, em lotes, e assim dificultará a resolução posterior de conflitos de mesclagem.
Na terceira vez funcionou!
As duas tentativas fracassadas mencionadas acima fizeram com que o repositório WhereHows GitHub permanecesse desatualizado por um longo tempo. A equipe continuou a melhorar os recursos e a arquitetura do produto, de modo que a versão interna do WhereHows para LinkedIn se tornou mais avançada do que a versão de código aberto. Tinha até um novo nome – DataHub. Com base em tentativas anteriores fracassadas, a equipe decidiu desenvolver uma solução escalonável e de longo prazo.
Para qualquer novo projeto de código aberto, a equipe de código aberto do LinkedIn aconselha e apoia um modelo de desenvolvimento no qual os módulos do projeto são desenvolvidos inteiramente em código aberto. Os artefatos versionados são implantados em um repositório público e, em seguida, verificados novamente no artefato interno do LinkedIn usando . Seguir esse modelo de desenvolvimento não é bom apenas para quem usa código aberto, mas também resulta em uma arquitetura mais modular, extensível e conectável.
No entanto, um aplicativo back-end maduro, como o DataHub, exigirá uma quantidade significativa de tempo para atingir esse estado. Isso também exclui a possibilidade de abrir o código-fonte de uma implementação totalmente funcional antes que todas as dependências internas tenham sido totalmente abstraídas. É por isso que desenvolvemos ferramentas que nos ajudam a fazer contribuições de código aberto com mais rapidez e muito menos trabalho. Esta solução beneficia tanto a equipe de metadados (desenvolvedor do DataHub) quanto a comunidade de código aberto. As seções a seguir discutirão essa nova abordagem.
Automação de publicação de código aberto
A abordagem mais recente da equipe de Metadados para o DataHub de código aberto é desenvolver uma ferramenta que sincronize automaticamente a base de código interna e o repositório de código aberto. Os recursos de alto nível deste kit de ferramentas incluem:
- Sincronize o código do LinkedIn de/para código aberto, semelhante .
- Geração de cabeçalho de licença, semelhante a .
- Gere automaticamente logs de commit de código aberto a partir de logs de commit internos.
- Evite alterações internas que interrompam compilações de código aberto, .
As subseções a seguir se aprofundarão nas funções mencionadas acima, que apresentam problemas interessantes.
Sincronização de código-fonte
Ao contrário da versão de código aberto do DataHub, que é um repositório único do GitHub, a versão do DataHub do LinkedIn é uma combinação de vários repositórios (chamados internamente ). A interface do DataHub, a biblioteca de modelos de metadados, o serviço de back-end do armazém de metadados e os trabalhos de streaming residem em repositórios separados no LinkedIn. No entanto, para facilitar aos usuários de código aberto, temos um único repositório para a versão de código aberto do DataHub.
Figura 1: Sincronização entre repositórios LinkedIn Hub de dados e um único repositório Hub de dados Código aberto
Para oferecer suporte a fluxos de trabalho automatizados de build, push e pull, nossa nova ferramenta cria automaticamente um mapeamento em nível de arquivo correspondente a cada arquivo de origem. No entanto, o kit de ferramentas requer configuração inicial e os usuários devem fornecer um mapeamento de módulo de alto nível, conforme mostrado abaixo.
{
"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"
]
}O mapeamento em nível de módulo é um JSON simples cujas chaves são os módulos de destino no repositório de código aberto e os valores são a lista de módulos de origem nos repositórios do LinkedIn. Qualquer módulo de destino em um repositório de código aberto pode ser alimentado por qualquer número de módulos de origem. Para indicar os nomes internos dos repositórios nos módulos de origem, use no estilo Bash. Usando um arquivo de mapeamento em nível de módulo, as ferramentas criam um arquivo de mapeamento em nível de arquivo verificando todos os arquivos nos diretórios associados.
{
"${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,
}O mapeamento em nível de arquivo é criado automaticamente pelas ferramentas; no entanto, também pode ser atualizado manualmente pelo usuário. Este é um mapeamento 1:1 de um arquivo de origem do LinkedIn para um arquivo no repositório de código aberto. Existem diversas regras associadas a esta criação automática de associações de arquivos:
- No caso de vários módulos de origem para um módulo de destino em código aberto, podem surgir conflitos, por exemplo, o mesmo , existindo em mais de um módulo de origem. Como estratégia de resolução de conflitos, nossas ferramentas adotam como padrão a opção “o último vence”.
- "nulo" significa que o arquivo de origem não faz parte do repositório de código aberto.
- Após cada envio ou extração de código aberto, esse mapeamento é atualizado automaticamente e um instantâneo é criado. Isso é necessário para identificar adições e exclusões do código-fonte desde a última ação.
Criando logs de confirmação
Os logs de commit para commits de código aberto também são gerados automaticamente pela mesclagem dos logs de commit dos repositórios internos. Abaixo está um exemplo de log de commit para mostrar a estrutura do log de commit gerado por nossa ferramenta. Um commit indica claramente quais versões dos repositórios de origem estão empacotadas naquele commit e fornece um resumo do log de commit. Confira este usando um exemplo real de log de commit gerado por nosso kit de ferramentas.
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.0Teste de dependência
LinkedIn tem , o que ajuda a garantir que as alterações em um multiproduto interno não interrompam a montagem de multiprodutos dependentes. O repositório DataHub de código aberto não é multiproduto e não pode ser uma dependência direta de qualquer multiproduto, mas com a ajuda de um wrapper multiproduto que busca o código-fonte do DataHub de código aberto, ainda podemos usar esse teste de dependência Assim, qualquer alteração (que pode ser posteriormente exposta) em qualquer um dos multiprodutos que alimentam o repositório DataHub de código aberto aciona um evento de construção no multiproduto shell. Portanto, qualquer alteração que falhe na construção de um produto wrapper falha nos testes antes de confirmar o produto original e é revertida.
Este é um mecanismo útil que ajuda a evitar qualquer commit interno que interrompa a compilação de código aberto e o detecte no momento do commit. Sem isso, seria muito difícil determinar qual commit interno causou a falha na construção do repositório de código aberto, porque agrupamos alterações internas no repositório de código aberto DataHub.
Diferenças entre o DataHub de código aberto e nossa versão de produção
Até este ponto, discutimos nossa solução para sincronizar duas versões de repositórios DataHub, mas ainda não descrevemos os motivos pelos quais precisamos de dois fluxos de desenvolvimento diferentes. Nesta seção, listaremos as diferenças entre a versão pública do DataHub e a versão de produção nos servidores do LinkedIn e explicaremos os motivos dessas diferenças.
Uma fonte de discrepância decorre do fato de que nossa versão de produção tem dependências de código que ainda não é de código aberto, como o Offspring do LinkedIn (estrutura interna de injeção de dependência do LinkedIn). Offspring é amplamente utilizado em bases de código internas porque é o método preferido para gerenciar configuração dinâmica. Mas não é de código aberto; então precisávamos encontrar alternativas de código aberto para o DataHub de código aberto.
Há outros motivos também. À medida que criamos extensões para o modelo de metadados para as necessidades do LinkedIn, essas extensões são normalmente muito específicas do LinkedIn e podem não se aplicar diretamente a outros ambientes. Por exemplo, temos rótulos muito específicos para IDs de participantes e outros tipos de metadados correspondentes. Portanto, excluímos agora essas extensões do modelo de metadados de código aberto do DataHub. À medida que nos envolvemos com a comunidade e compreendemos as suas necessidades, trabalharemos em versões comuns de código aberto destas extensões, sempre que necessário.
A facilidade de uso e a adaptação mais fácil para a comunidade de código aberto também inspiraram algumas das diferenças entre as duas versões do DataHub. As diferenças na infraestrutura de processamento de fluxo são um bom exemplo disso. Embora nossa versão interna use uma estrutura de processamento de fluxo gerenciado, optamos por usar processamento de fluxo integrado (autônomo) para a versão de código aberto porque evita a criação de outra dependência de infraestrutura.
Outro exemplo da diferença é ter um único GMS (Generalized Metadata Store) em uma implementação de código aberto, em vez de vários GMSs. GMA (Arquitetura de Metadados Generalizados) é o nome da arquitetura de back-end do DataHub, e GMS é o armazenamento de metadados no contexto do GMA. GMA é uma arquitetura muito flexível que permite distribuir cada construção de dados (por exemplo, conjuntos de dados, usuários, etc.) em seu próprio armazenamento de metadados ou armazenar várias construções de dados em um único armazenamento de metadados, desde que o registro que contém o mapeamento da estrutura de dados em O GMS está atualizado. Para facilidade de uso, escolhemos uma única instância do GMS que armazena todas as diferentes construções de dados no DataHub de código aberto.
Uma lista completa das diferenças entre as duas implementações é fornecida na tabela abaixo.
características do produto
Hub de dados do LinkedIn
DataHub de código aberto
Construções de dados suportadas
1) Conjuntos de dados 2) Usuários 3) Métricas 4) Recursos de ML 5) Gráficos 6) Painéis
1) Conjuntos de dados 2) Usuários
Fontes de metadados compatíveis para conjuntos de dados
1) 2) Sofá 3) 4) 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) 12) Presto 12) 13) Teradata 13) Vetor 14)
Colmeia Kafka RDBMS
Pub-sub
Kafka Confluente
Processamento de fluxo
Dirigido
Incorporado (autônomo)
Injeção de Dependência e Configuração Dinâmica
Filhos do LinkedIn
Construir ferramentas
Ligradle (wrapper Gradle interno do LinkedIn)
CI / CD
CRT (CI/CD interno do LinkedIn)
e
Armazenamentos de metadados
Vários GMS distribuídos: 1) Conjunto de dados GMS 2) GMS do usuário 3) GMS métrico 4) GMS de recursos 5) GMS de gráfico/painel
GMS único para: 1) Conjuntos de dados 2) Usuários
Microsserviços em contêineres Docker
simplifica a implantação e distribuição de aplicativos com . Cada parte do serviço no DataHub é de código aberto, incluindo componentes de infraestrutura como Kafka, , и , tem sua própria imagem Docker. Para orquestrar contêineres Docker usamos .
Figura 2: Arquitetura Hub de dados *Código aberto**
Você pode ver a arquitetura de alto nível do DataHub na imagem acima. Além dos componentes de infraestrutura, possui quatro contêineres Docker diferentes:
datahub-gms: serviço de armazenamento de metadados
datahub-frontend: aplicativo , servindo a interface DataHub.
datahub-mce-consumidor: aplicativo , que usa o fluxo de evento de alteração de metadados (MCE) e atualiza o armazenamento de metadados.
datahub-mae-consumidor: aplicativo , que usa um fluxo de eventos de auditoria de metadados (MAE) e cria um índice de pesquisa e um banco de dados gráfico.
Documentação de repositório de código aberto e contêm informações mais detalhadas sobre as funções de vários serviços.
CI/CD no DataHub é de código aberto
O repositório DataHub de código aberto usa para integração contínua e para implantação contínua. Ambos têm boa integração com o GitHub e são fáceis de configurar. Para a maioria das infraestruturas de código aberto desenvolvidas pela comunidade ou por empresas privadas (por exemplo, ), as imagens do Docker são criadas e implantadas no Docker Hub para facilitar o uso pela comunidade. Qualquer imagem Docker encontrada no Docker Hub pode ser facilmente usada com um simples comando .
Com cada commit no repositório de código aberto DataHub, todas as imagens do Docker são automaticamente construídas e implantadas no Docker Hub com a tag "latest". Se o Docker Hub estiver configurado com algum , todas as tags no repositório de código aberto também são lançadas com nomes de tags correspondentes no Docker Hub.
Usando DataHub
é muito simples e consiste em três etapas simples:
- Clone o repositório de código aberto e execute todos os contêineres Docker com docker-compose usando o script docker-compose fornecido para um início rápido.
- Faça download dos dados de amostra fornecidos no repositório usando a ferramenta de linha de comando que também é fornecida.
- Navegue pelo DataHub em seu navegador.
Rastreado ativamente também configurado para perguntas rápidas. Os usuários também podem criar problemas diretamente no repositório GitHub. Mais importante ainda, agradecemos e agradecemos todos os comentários e sugestões!
Planos para o futuro
Atualmente, toda infraestrutura ou microsserviço para DataHub de código aberto é construída como um contêiner Docker, e todo o sistema é orquestrado usando . Dada a popularidade e ampla , também gostaríamos de fornecer uma solução baseada em Kubernetes em um futuro próximo.
Também planejamos fornecer uma solução pronta para uso para implantação do DataHub em um serviço de nuvem pública, como , ou . Dado o recente anúncio da migração do LinkedIn para o Azure, isto irá alinhar-se com as prioridades internas da equipa de metadados.
Por último, mas não menos importante, obrigado a todos os primeiros a adotar o DataHub na comunidade de código aberto que avaliaram o DataHub como alfa e nos ajudaram a identificar problemas e melhorar a documentação.
Fonte: habr.com