Get best of the week

Migrando de um Data Lake contínuo para um Data Mesh distribuído

Olá Habr! Apresento a você a tradução do artigo “Como ir além de um lago de dados monolítico para uma malha de dados distribuídos” por Zhamak Dehghani (Zhamak Degani) (todas as imagens são tiradas do mesmo artigo).

Todas as grandes empresas agora estão tentando construir enormes data warehouses centralizados. Ou um cluster ainda maior de Data Lakes (como regra, em um hdup). Mas não conheço um único exemplo da construção bem-sucedida de tal plataforma de dados. Em todos os lugares há sofrimento e sofrimento para quem está construindo uma plataforma de dados e para os usuários. No artigo abaixo, o autor (Zhamak Degani) oferece uma abordagem completamente nova para a construção de uma plataforma de dados. Essa é a arquitetura da plataforma de dados de quarta geração chamada Data Mesh. O artigo original em inglês é muito volumoso e francamente difícil de ler. A tradução também se mostrou bastante grande e o texto não é muito simples: frases longas, vocabulário bastante seco. Não reformulei os pensamentos do autor para manter a precisão da redação.Mas eu recomendo que você continue lendo este texto difícil e leia o artigo. Para quem lida com dados, será muito útil e muito interessante.

Evgeny Cherny

Muitas empresas estão investindo na próxima geração do Data Lake com a esperança de simplificar o acesso a dados em toda a empresa e fornecer informações comerciais e a capacidade de tomar decisões de alta qualidade automaticamente. Mas as abordagens atuais para a construção de plataformas de dados têm problemas semelhantes que não nos permitem alcançar nossos objetivos. Para resolver esses problemas, precisamos abandonar o paradigma de um Data Lake centralizado (ou seu antecessor, o data warehouse). E passe para um paradigma baseado em uma arquitetura distribuída moderna: considere os domínios de negócios como uma prioridade de primeiro nível, aplique o pensamento da plataforma para criar uma infraestrutura com capacidade de autoatendimento e percepção de dados como um produto.

imagem

Conteúdo

  • A arquitetura atual da plataforma de dados em uma grande empresa
    • Abordagens arquitetônicas problemáticas
    • domain driven
      • -
      • (data pipelines),
        • (discoverable)
        • (addressable)
        • ,
    • data- -
    • Infraestrutura de dados centralizada como plataforma
  • Mudança de paradigma para o Data Mesh

Construir uma organização orientada a dados continua sendo um dos principais objetivos estratégicos de muitas das empresas com as quais trabalho. Meus clientes estão bem cientes das vantagens de tomar decisões com base em dados de alta qualidade: garantir a mais alta qualidade de serviço ao cliente, hiper personalização, reduzindo custos operacionais e tempo devido à otimização, fornecendo aos funcionários ferramentas de análise e análise de negócios. Eles investem pesadamente na construção de plataformas de dados modernas. Mas, apesar dos crescentes esforços e investimentos na construção de tais plataformas, muitas organizações vêem os resultados como medíocres.

As organizações enfrentam muitas dificuldades no processo de transformação em empresas orientadas a dados: migração de sistemas legados e décadas de sistemas de desenvolvimento, resistência da cultura existente e alta competição entre diferentes prioridades de negócios. Seja como for, quero compartilhar com você uma abordagem arquitetural que leve em consideração os motivos da falha de muitas iniciativas no campo da construção de plataformas de dados. Demonstrarei como podemos adaptar e aplicar as lições da década passada na construção de arquiteturas distribuídas no campo de dados. Eu chamei essa nova abordagem arquitetônica de Data Mesh .

Antes de continuar lendo, peço que tente abandonar os preconceitos estabelecidos pelo paradigma atual da arquitetura tradicional da plataforma de dados enquanto lê este artigo. Esteja aberto à possibilidade de passar do Data Lakes centralizado para uma arquitetura Data Mesh distribuída deliberadamente. Aceite que os dados sejam inerentemente distribuídos e onipresentes.

A arquitetura atual da plataforma de dados em uma grande empresa


Vamos falar sobre o significado centralizado, monolítico e independente de negócios dos dados do Data Lake.

Quase todo cliente com quem trabalho está planejando ou já está construindo sua plataforma de dados de terceira geração. Reconhecendo os erros das gerações anteriores.

  • Primeira geração: data warehouses corporativos proprietários e plataformas de business intelligence. Essas são decisões para grandes somas de dinheiro que deixaram as empresas com quantidades igualmente grandes de dívida técnica. A dívida técnica está em milhares de trabalhos, tabelas e relatórios de ETL não suportados que apenas um pequeno grupo de especialistas entende, o que leva a uma subestimação do impacto positivo dessa funcionalidade nos negócios.
  • Segunda geração: ecossistemas de Big Data com o Data Lake como uma bala de prata. Um ecossistema complexo de big data e trabalhos em lotes de longa duração, suportados por uma equipe central de engenheiros de dados altamente especializados. Na melhor das hipóteses, usado para análises de P&D.

As plataformas de dados de terceira geração são mais ou menos semelhantes às gerações anteriores, mas com uma tendência para

  1. streaming para fornecer disponibilidade de dados em tempo real com uma arquitetura como Kappa ,
  2. combinando processamento em lote e streaming para transformar dados usando estruturas como Apache Beam ,
  3. uso de serviços em nuvem para armazenamento e processamento de dados e plataformas de aprendizado de máquina em nuvem.

A plataforma de dados de terceira geração elimina alguns dos problemas das gerações anteriores, como análise de dados em tempo real, e também reduz o custo de gerenciamento de uma infraestrutura de big data. No entanto, muitos recursos subjacentes que levaram às falhas das gerações anteriores ainda são preservados.

imagem
Figura 1: Três gerações de plataformas de dados

Abordagens arquitetônicas problemáticas


Para descobrir as limitações básicas que todas as gerações de plataformas de dados têm em si mesmas, vejamos sua arquitetura e recursos. Neste artigo, usarei o negócio de streaming de mídia da Internet (como Spotify, SoundCloud, Apple iTunes) como um exemplo para explicar alguns conceitos.

Centralizado e monolítico


De uma altura de 10.000 metros, a arquitetura da plataforma de dados se parece com a Figura 2 abaixo.
imagem
Figura 2: Vista de uma altura de 10.000 metros em uma plataforma de dados monolítica A

parte central da arquitetura é responsável por:

  • (to ingest) , , . , , : ; ; ; , ; ( ..).
  • , , , . , , — .
  • (to serve) . machine learning BI . , . , Kafka.

Por padrão, o contrato geralmente aceito é o fato de o Data Platform monolítico armazenar e possuir dados que pertencem a diferentes domínios de negócios. Por exemplo, 'eventos de reprodução', 'KPIs de vendas', 'artistas', 'álbuns', 'gravadoras', 'áudio', 'podcasts', 'eventos de música' etc. - dados de um grande número de domínios díspares.

Apesar do fato de que, na última década, aplicamos com sucesso o conceito de Design Orientado a Domínio (e seu principal padrão de Contexto Limitado ) ao design de nossos sistemas de informação, ignoramos amplamente esses conceitos no design de plataformas de dados. Passamos da propriedade dos dados no nível do domínio comercial para a propriedade dos dados, independentemente dos domínios comerciais. Estamos orgulhososque criou o maior monólito - Big Data Platform.

imagem
Figura 3: Uma plataforma de dados centralizada sem limites claros entre dados de diferentes domínios de negócios. E sem a propriedade dos dados relevantes pelo domínio comercial,

esse modelo centralizado pode funcionar para pequenas organizações que possuem domínios comerciais simples e opções limitadas de consumo de dados. Mas não é adequado para grandes empresas com domínios de negócios grandes e complexos, um grande número de fontes de dados e diversas necessidades para trabalhar com dados de consumidores.

Existem dois elos fracos na arquitetura e estrutura de uma plataforma de dados centralizada, que geralmente levam a falhas no processo de construção:

  • Um grande número de fontes e grandes quantidades de dados. , , . , . . , , , . , data scientists . , ( ) , . , – - .
  • . . , . .

Aqui, preciso esclarecer que não estou falando a favor do uso de dados fragmentados e díspares, ocultos nas profundezas dos sistemas legados. Dados que são difíceis de detectar, entender e usar. Também não apoio os inúmeros data warehouses distintos da mesma organização, que são o resultado de muitos anos de dívida técnica acumulada. Mas argumento que a resposta para esses dados fragmentados inacessíveis não é criar uma plataforma de dados centralizada com uma equipe centralizada que armazena e possui dados de todos os domínios de negócios.

Essa abordagem não é dimensionada em grandes organizações, como mostrado acima.

Decomposição do transportador altamente conectado


imagem
Figura 4: Decomposição arquitetônica da plataforma de dados

O segundo problema com a arquitetura tradicional da plataforma de dados é como decompomos a arquitetura. Se cair a 3.000 metros acima da arquitetura da plataforma de dados, encontraremos uma decomposição arquitetônica em torno das funções de carregamento, limpeza, agregação, entrega de dados etc. Conforme descrito na seção anterior, a necessidade de conectar novas fontes e novos consumidores requer um crescimento da plataforma. Os arquitetos devem encontrar uma maneira de dimensionar o sistema, dividindo-o em quanta arquitetônicos. Quantum arquitetônico, conforme descrito no livro “ Construindo arquiteturas evolucionárias”, É um componente implementável independentemente com alta conectividade funcional, que inclui todos os elementos estruturais necessários para a operação correta do sistema. A motivação para dividir o sistema em quanta arquitetônicos consiste principalmente na criação de equipes independentes, cada uma das quais cria e mantém seu próprio quantum arquitetônico (subsistema funcional). Isso permite que você paralelize o trabalho e aumente a velocidade e a escalabilidade operacional.

Influenciados pelas gerações anteriores de plataformas de dados, os arquitetos dividem a plataforma em uma série de etapas de processamento de dados. Este é um pipeline que implementa o processamento de dados: carregamento, preparação, agregação, fornecimento de acesso / descarregamento, etc.

Embora esse particionamento forneça um certo nível de dimensionamento, também possui uma limitação interna que atrasa o desenvolvimento de novas funcionalidades na plataforma: existe uma alta conectividade entre as etapas do pipeline, o que não permite a independência necessária de equipes individuais.

Vamos voltar ao nosso exemplo de mídia de streaming. As plataformas de mídia de streaming na Internet têm um forte design de domínio em relação ao tipo de mídia que oferecem. Eles geralmente iniciam seus serviços com "músicas" e "álbuns" e depois se aplicam a "eventos musicais", "podcasts", "programas de rádio", "filmes" etc. Ativando um novo recurso, por exemplo, visibilidade para "podcasts" play rate ”, exige uma alteração em todos os componentes do pipeline. As equipes precisam desenvolver novos serviços para carregar, limpar e preparar dados (incluindo agregação), a fim de adicionar a visibilidade da "taxa de reprodução de podcasts". Isso requer sincronização entre liberações de várias equipes funcionais. Muitas plataformas de dados usam ferramentas de download baseadas em configuração que podem lidar facilmente com essas tarefas.como simplesmente adicionar novas fontes ou expandir as existentes. Mas isso não elimina a necessidade de gerenciamento completo de versões em todos os estágios do pipeline de processamento de dados. Para fornecer aos usuários acesso a novos dados, a unidade arquitetônica mínima que precisa ser alterada é o pipeline inteiro. E isso limita significativamente nossa capacidade de aumentar a velocidade e a escala do desenvolvimento da plataforma de dados em resposta ao surgimento de novas fontes e usuários de dados.E isso limita significativamente nossa capacidade de aumentar a velocidade e a escala do desenvolvimento da plataforma de dados em resposta ao surgimento de novas fontes e usuários de dados.E isso limita significativamente nossa capacidade de aumentar a velocidade e a escala do desenvolvimento da plataforma de dados em resposta ao surgimento de novas fontes e usuários de dados.

Equipes separadas e altamente especializadas


O terceiro problema das plataformas de dados modernas é como estruturamos as equipes que criam e mantêm a plataforma. Quando ficarmos suficientemente baixos na arquitetura de uma plataforma de dados tradicional, veremos um grupo de engenheiros de dados estritamente especializados separados das unidades organizacionais nas quais os dados são criados ou usados ​​para a tomada de decisões. Os engenheiros de plataforma de dados são destacados em equipes separadas apenas com base em suas competências técnicas e experiência com tecnologias de big data. O conhecimento comercial das áreas de assunto correspondentes (domínios de negócios) está ausente nessas equipes.

imagem
Figura 5: Equipes de plataforma de dados especializadas e dispersas

Pessoalmente, não invejo a vida dos engenheiros de plataformas de dados. Eles devem receber dados de equipes que não têm incentivo para fornecer dados de qualidade e corretos. Eles não entendem o significado comercial dos dados que você precisa baixar. Eles devem preparar dados para atender às necessidades analíticas e operacionais, sem uma compreensão clara do uso final desses dados e sem acesso a especialistas no campo de consumo desses dados.

Note-se que já encontramos anteriormente um problema semelhante de separação de equipes. E eles foram capazes de encontrar uma solução bem-sucedida para esse problema.

imagem

Em nosso exemplo com streaming multimídia, temos o comando “media player”, que possui dados sobre como os usuários interagem com o player: músicas que os usuários ouvem, compras feitas, qualidade de áudio das músicas que ouvem etc. Por outro lado, existem equipes de consumidores de dados relevantes: uma equipe de recomendações de músicas; equipe de monitoramento de vendas; equipe de pagamento do artista etc. E entre eles, uma triste equipe de desenvolvedores de uma plataforma de dados, que, ao custo de um grande esforço, recebe dados de uma equipe e fornece acesso a eles (após processamento preliminar) para todos os consumidores.

Na realidade, temos equipes de fontes de dados não envolvidas e equipes frustradas de consumidores de dados que precisam lutar por um lugar no topo da lista de pendências da equipe de desenvolvimento da plataforma de dados.

Criamos uma arquitetura e estrutura organizacional que não fornece a escalabilidade necessária e não é capaz de atingir os objetivos de construir uma organização orientada a dados.

Arquitetura da plataforma de dados de próxima geração


E qual é a solução para os problemas que discutimos acima? Na minha opinião, é necessária uma mudança de paradigma. Uma mudança de paradigma na interseção de métodos que desempenharam um papel importante na construção de uma arquitetura distribuída escalável moderna e que a indústria de tecnologia como um todo implementou em um ritmo acelerado. Métodos que produziram resultados bem-sucedidos.

Acredito que a próxima arquitetura de plataforma de dados corporativos seja integrar a Arquitetura Orientada a Domínios Distribuídos, projetar plataformas de autoatendimento e pensar em produtos para dados.

imagem
Figura 6: Mudando a mudança de paradigma da plataforma de dados da próxima geração.

Entendo que isso possa parecer um monte de chavões em uma frase, mas cada um desses componentes teve um impacto incrivelmente positivo na alteração dos fundamentos técnicos de nossos sistemas de informação. Vamos ver como podemos aplicar cada uma dessas disciplinas ao mundo dos dados para nos afastarmos do paradigma atual que foi transferido de muitos anos de construção de data warehouses das gerações anteriores.

Arquitetura orientada a dados e domínio distribuído


Decomposição e propriedade de dados com base na orientação do domínio comercial


O livro de Eric Evans, Domain-Driven Design , teve um profundo impacto no pensamento arquitetônico contemporâneo e, portanto, na modelagem organizacional. A nova arquitetura de microsserviço decompôs os sistemas de informações em serviços distribuídos, construídos dentro dos limites de domínios de negócios específicos. Isso mudou fundamentalmente a forma como as equipes são formadas: a partir de agora, uma equipe pode ser proprietária de forma independente e autônoma de seus microsserviços.

Curiosamente, ignoramos o conceito de domínios de negócios no campo de dados. Aplicação futura do design orientado a domínio na arquitetura da plataforma de dados: este é o surgimento de eventos de domínio comercialem sistemas de informação e carregá-los em plataformas de dados monolíticas. No entanto, depois que os dados são carregados no armazenamento centralizado, o conceito de propriedade de dados de diferentes domínios de negócios por diferentes equipes é perdido.

Para descentralizar uma plataforma de dados monolítica, você precisa alterar a maneira como pensa sobre os dados, sua localização e propriedade. Em vez de transferir dados para um Data Lake ou plataforma, os domínios devem armazenar e manter seus conjuntos de dados de maneira amigável.

Em nosso exemplo, em vez de carregar dados do media player em um repositório centralizado para processamento adicional pela equipe de suporte do repositório, por que não armazenar e processar esses conjuntos de dados no domínio e não dar acesso a nenhuma outra equipe? O próprio local em que esses conjuntos de dados serão fisicamente armazenados pode ser tecnicamente implementado no domínio, conforme desejado. Obviamente, você pode usar uma arquitetura centralizada, mas os dados dos próprios players de mídia permanecerão sob a propriedade e o suporte da equipe do domínio correspondente no qual esses dados são gerados. Da mesma forma, em nosso exemplo, o domínio de desenvolvimento de recomendações de músicas pode criar conjuntos de dados no formato mais adequado para uso (por exemplo, na forma de estruturas de gráficos) com base nos dados do media player. Se houver outras equipes,quem considera esse formato conveniente e útil, também pode acessá-lo.

Obviamente, isso implica que podemos duplicar dados em diferentes domínios quando alteramos seu formato para um que se adapte a um consumidor específico.

Tudo isso requer uma mudança em nosso pensamento, de baixar dados (via ETL ou streaming) para escalar esse processo para todos os domínios. O quantum arquitetônico em uma plataforma de dados orientada a domínio é um domínio comercial, não o estágio de carregamento e transformação de dados.

imagem
Figura 7: Decomposição de uma arquitetura baseada em domínios de negócios e equipes de propriedade de dados.

Conjuntos de dados do domínio de origem


Alguns domínios de negócios estão bem alinhados com as fontes de dados (sistemas de informação). No caso ideal, o sistema de informações e a equipe que o acompanha não são apenas responsáveis ​​por adicionar e dar suporte à funcionalidade comercial, mas também fornecem conjuntos de dados descrevendo os fatos e a realidade do domínio comercial correspondente. No entanto, na escala de uma grande organização, como regra, não há correspondência inequívoca entre o domínio comercial e o sistema de informação. Como regra, para cada domínio, existem vários sistemas de informação que automatizam diferentes processos de negócios de um determinado domínio e, consequentemente, armazenam dados relacionados a ele. Para esses domínios, é necessário integrar e agregar dados diferentes para obter conjuntos de dados consistentes e alinhados em todo o domínio comercial.

O melhor formato para armazenar fatos que descrevem um domínio comercial é Eventos de Domínio . Eles podem ser armazenados como um log de eventos distribuído com registros de data e hora. Esse log pode ter acesso concedido a consumidores autorizados.

Além desses logs, as fontes de dados também devem fornecer acesso a instantâneos periódicos dos principais conjuntos de dados em seu domínio. A agregação dessas imagens é para o intervalo de tempo que reflete melhor o intervalo de alterações do seu domínio (geralmente um dia / semana / mês / trimestre, etc.).

Observe que os conjuntos de dados do domínio comercial preparados para os consumidores devem ser separados dos conjuntos de dados internos de fontes (que os sistemas de informação usam para seu trabalho). Eles devem ser armazenados em um local fisicamente diferente, adequado para trabalhar com big data. A seguir, será descrito como criar um armazém de dados e uma infraestrutura de serviço para ele.

Conjuntos de dados específicos de domínio preparados para os consumidores são os elementos mais básicos de toda a arquitetura. Eles não se transformam e não são personalizados para um consumidor específico, mas são dados brutos e não processados.

Conjuntos de dados do domínio do consumidor


Outros domínios estão intimamente relacionados aos consumidores de dados. Os conjuntos de dados desse domínio são criados de tal maneira que, quando usados, se ajustam ao conjunto associado de cenários do usuário. Esses conjuntos de dados são diferentes dos conjuntos de dados do domínio de origem. Não são dados brutos, mas os dados passaram por vários estágios de transformação. A estrutura desses conjuntos de dados e sua apresentação são adaptados aos casos específicos de seu uso. Essa. Este é um análogo de data marts especializados em um repositório centralizado. Para esses conjuntos de dados do domínio do consumidor (conjuntos de dados do domínio do consumidor) deve ser fornecida a possibilidade de recuperação rápida dos dados brutos.

Pipelines de dados distribuídos implementados em seus domínios


A propriedade dos dados em nossa nova arquitetura é delegada da plataforma central para as equipes nos domínios de negócios, mas a necessidade de limpeza, preparação e agregação de dados (usando o pipeline de dados) não desaparece. Portanto, a implementação de seu próprio pipeline de dados se torna uma tarefa interna da equipe do domínio de negócios. Como resultado, obtemos nossos próprios pipelines de dados de domínio distribuídos por todos os domínios.

Por exemplo, os domínios de origem devem incluir limpeza de dados, remoção duplicada, enriquecimento de dados, etc., para que outros domínios possam usar esses dados sem processamento preliminar. Cada conjunto de dados deve estar em conformidade com seu objetivo de nível de serviço em termos de qualidade dos dados.

Da mesma forma, os estágios de criação de mostruários especializados de um pipeline centralizado para processamento de dados entram nos próprios pipelines de dados de domínios de consumidores que constroem conjuntos de dados de domínio de consumidor.

imagem
Figura 8: Pipelines de processamento de dados distribuídos implementados em seus domínios

Pode parecer que esse modelo levará a uma grande duplicação de esforços em cada domínio para criar sua própria implementação de um pipeline de processamento de dados. Falaremos sobre esse problema na seção "infraestrutura de dados centralizada como plataforma".

Dados e Pensamento do Produto


A transferência da propriedade dos dados e a responsabilidade pelo desenvolvimento e manutenção de pipelines de processamento de dados para os lados dos domínios de negócios podem causar sérias preocupações com a disponibilidade contínua e a facilidade de uso desses conjuntos de dados distribuídos. Portanto, aqui chegamos ao pensamento prático do produto em relação aos dados.

Dados de domínio como um produto


Nos últimos dez anos, o pensamento do produto penetrou profundamente no desenvolvimento de sistemas de informação das organizações e transformou seriamente a abordagem desse desenvolvimento. As equipes de domínio para o desenvolvimento de sistemas de informação fornecem novos recursos na forma de APIs que os desenvolvedores usam nas organizações como blocos de construção para criar funcionalidades de ordem superior e maior valor. As equipes se esforçam para criar a melhor experiência para os usuários de suas APIs por meio de documentação clara e detalhada que é fácil de acessar; ambientes de teste indicadores de qualidade cuidadosamente rastreados.

Para que uma plataforma de dados distribuídos seja bem-sucedida, as equipes de dados dos domínios de negócios devem aplicar o pensamento do produto em relação ao fornecimento de conjuntos de dados: perceber os dados que eles preparam como produto e os consumidores (analistas, cientistas de dados, engenheiros de dados, especialistas em ML etc.) como seus clientes.

imagem
Figura 9: Características dos conjuntos de dados do domínio como produtos

Considere o nosso exemplo - streaming de conteúdo de mídia pela Internet. O domínio comercial mais importante é a história da reprodução: por quem, onde, quando e quais músicas foram ouvidas. Este domínio possui vários consumidores de dados importantes dentro da organização. Um requer dados em modo quase em tempo real para estudar a experiência do usuário e a detecção oportuna de quaisquer problemas e erros de reprodução. Outros estão interessados ​​em instantâneos históricos agregados por dia ou mês. Portanto, nosso domínio fornece dados em dois formatos: eventos de reprodução em forma de streaming (streaming, tópico em kafka ou algo parecido) e eventos de reprodução agregados em formato de lote (arquivo, tabela na seção, etc.).

Para fornecer a melhor experiência do usuário para os consumidores, os produtos de dados do domínio comercial devem ter os seguintes recursos principais.

Conveniência e facilidade de detecção (detectável)


É necessário garantir as condições sob as quais qualquer produto de dados pode ser facilmente encontrado. A implementação mais comum desse requisito é a presença de um registro - um catálogo de todos os produtos de dados disponíveis com as metainformações necessárias (como proprietários, fontes de origem, amostras de conjuntos de dados, frequência de atualização, estrutura de conjuntos de dados etc.). Esse serviço centralizado permite que os consumidores de dados encontrem facilmente o conjunto de dados em que estão interessados. Cada produto de dados de qualquer domínio comercial deve ser registrado em um diretório de dados centralizado.

Observe que há uma mudança de uma única plataforma centralizada que possui todos os dados para produtos de dados distribuídos de diferentes domínios de negócios registrados em um único diretório de dados.

Endereço exclusivo (endereçável)


Cada produto de dados deve ter um endereço exclusivo (de acordo com o contrato global), que permitirá que seus consumidores tenham acesso programático a ele. As organizações podem adotar vários acordos sobre o nome dos produtos de dados e sua localização, dependendo dos métodos disponíveis de armazenamento físico de dados e dos formatos dos próprios dados. Para arquitetura descentralizada distribuída, essas convenções gerais são necessárias. Os padrões de endereço do conjunto de dados eliminam o atrito ao pesquisar e acessar produtos de dados.

Qualidade dos dados


Ninguém usará um produto que não é credível. Nas plataformas de dados da geração atual, o download e a publicação de dados contendo erros e que não refletem toda a verdade do negócio são generalizados, ou seja, dados que não podem ser confiáveis. É nesta parte que um número significativo de trabalhos ETL é concentrado, o que limpa os dados após o carregamento.

A nova arquitetura exige que os proprietários dos produtos de dados adotem o SLO (Service Level Objective) em termos de precisão, confiabilidade e relevância dos dados. Para garantir uma qualidade aceitável, é necessário usar métodos como limpeza de dados e teste automático de integridade de dados no estágio de criação de um produto de dados. As informações sobre a linhagem de dados nos metadados de cada produto de dados oferecem aos consumidores confiança adicional no próprio produto e em sua adequação a necessidades específicas.

O valor alvo do indicador de qualidade dos dados (ou o intervalo aceitável) varia dependendo do produto de dados de um domínio comercial específico. Por exemplo, um domínio de "evento de repetição" pode fornecer dois produtos diferentes: um no modo quase em tempo real com um nível mais baixo de precisão (incluindo eventos perdidos ou repetidos); e o segundo com um atraso maior e um nível mais alto de qualidade dos dados. Cada produto de dados define e mantém um nível-alvo de integridade e confiabilidade de seus dados na forma de um conjunto de SLO (Objetivo de Nível de Serviço).

Descrição clara da semântica e sintaxe de dados


Produtos de qualidade devem ser fáceis de usar. Criar produtos de dados o mais simples possível de usar por analistas, engenheiros e cientistas de dados requer a presença de semântica e sintaxe de dados bem descritas. Idealmente, conjuntos de dados de amostra são fornecidos como exemplos.

Integrabilidade de dados e padrões para toda a organização


Um dos principais problemas em uma arquitetura de dados controlada por domínio distribuído é a necessidade de integrar dados de diferentes domínios. A chave para a integração fácil e eficiente de dados entre domínios é definir e seguir regras e padrões. Tais padrões devem ser definidos no nível da organização. A padronização é necessária no campo de determinação de tipos e regras de dados aceitáveis ​​para sua aplicação, convenções sobre nomes e endereços de produtos de dados, formatos de metadados, etc.

Para as entidades que podem ser armazenadas de uma forma diferente e com um conjunto diferente de atributos em domínios diferentes, é necessário implementar a prática do Gerenciamento de Dados Mestre. Atribua a eles identificadores globais e alinhe o conjunto e, o mais importante, atribua valores entre todos os domínios.

Garantir a interoperabilidade dos dados para sua integração efetiva, bem como definir padrões para armazenar e apresentar produtos de dados no nível da organização, são um dos princípios fundamentais para a construção desses sistemas distribuídos.

Segurança de dados e controle de acesso


É essencial garantir o acesso seguro aos dados, independentemente de a arquitetura ser centralizada ou não. No mundo dos produtos de dados orientados ao domínio de negócios descentralizados, o controle de acesso é possível (e deve ser aplicado) com um maior grau de granularidade para cada conjunto de dados. As políticas de controle de acesso a dados podem ser definidas centralmente, mas implementadas separadamente para cada produto de dados. Como uma maneira conveniente de implementar o controle de acesso aos conjuntos de dados, você pode usar o sistema Enterprise Identity Management e o controle de acesso baseado em funções .

A seguir, uma única infraestrutura será descrita, o que permite implementar fácil e automaticamente os recursos acima para cada produto de dados.

Comando multifuncional de dados do domínio de negócios


As seguintes funções devem ser representadas nas equipes que fornecem dados na forma de produtos de dados: proprietário do produto e engenheiro de dados.

O proprietário do produto de dados é responsável pelo conceito e roteiro, o ciclo de vida de seus produtos. Mede a satisfação de seus clientes e mede e melhora constantemente a qualidade dos dados de seu domínio de negócios. Ele preenche e equilibra a lista de pendências de seus produtos de dados com os requisitos dos consumidores de dados.

Além disso, os proprietários do produto de dados devem definir as principais métricas e indicadores de desempenho (KPIs) para seus produtos. Por exemplo, o tempo necessário para se familiarizar e começar a usar o produto de dados pelo usuário pode ser uma dessas métricas.

Para criar e manter seus próprios pipelines de dados dentro de um domínio comercial, a equipe deve incluir engenheiros de dados. Um bom efeito colateral disso será a disseminação de habilidades relevantes no domínio comercial. De acordo com minhas observações, atualmente alguns engenheiros de dados, embora sejam competentes no uso de suas ferramentas e tecnologias, não têm conhecimento das práticas padrão de desenvolvimento de software quando se trata de criar produtos de dados. Primeiro de tudo, práticas de DevOps como entrega contínua e teste automático. Por outro lado, os desenvolvedores de software que desenvolvem sistemas de informação geralmente não têm experiência e conhecimento suficientes no campo de tecnologias e ferramentas para trabalhar com dados como um produto.Combiná-los em equipes multifuncionais dentro do domínio comercial levará ao surgimento de especialistas com um perfil mais amplo. Observamos algo semelhante durante o desenvolvimento do DevOps quando novos tipos de engenheiros apareceram, comoSRE .

imagem
Figura 10: Comando cruzado de dados do domínio funcional

Infraestrutura de dados centralizada como plataforma


Um dos aspectos sensíveis da arquitetura orientada a domínio distribuído da plataforma de dados é a necessidade de duplicação em cada domínio dos esforços e habilidades necessários para operar a pilha de infraestrutura e tecnologia usada nos pipelines de dados. Felizmente, a criação de uma infraestrutura comum como plataforma é uma tarefa que é bem aprendida a ser resolvida em TI (mas não no campo de trabalho com dados).

A equipe de infraestrutura de dados deve possuir e fornecer como serviço as ferramentas necessárias para os domínios de negócios coletarem, processarem e armazenarem seus produtos de dados.

imagem
Figura 11: Infraestrutura de dados como plataforma

A infraestrutura de dados como plataforma deve estar livre de quaisquer conceitos específicos do domínio ou lógica de negócios. Além disso, a plataforma deve ocultar aos usuários a complexidade de sua implementação e fornecer a quantidade máxima de sua funcionalidade para uso no modo de autoatendimento. Aqui está uma lista de alguns dos recursos que uma infraestrutura de dados centralizada, como uma plataforma, deve fornecer:

  • Armazenamento de dados escalável em vários formatos
  • Criptografia de dados (aqui hash, despersonalização etc.)
  • Versão de produtos de dados
  • Armazenando Esquema de Dados do Produto de Dados
  • Controle de acesso a dados
  • Exploração madeireira
  • Orquestração de processos de processamento de dados / threads
  • Armazenamento em cache na memória
  • Armazenando Metadados e Linhagem de Dados
  • Monitoramento, alertas, registro
  • Cálculo de métricas de qualidade para produtos de dados
  • Manutenção do catálogo de dados
  • Padronização e políticas, a capacidade de controlar a conformidade
  • Endereçando produtos de dados
  • Pipelines de CI / CD para produtos de dados

Ao criar uma infraestrutura de dados centralizada, é necessário garantir que a criação de um produto de dados em tal infraestrutura leve o mínimo de tempo possível. Portanto, a automação máxima da funcionalidade principal é muito importante, como: a capacidade de baixar dados usando configurações simples, registro automático de um produto de dados no diretório de dados, etc. O uso da infraestrutura em nuvem pode reduzir os custos operacionais e aumentar a velocidade de fornecer acesso à infraestrutura de dados sob demanda.

Mudança de paradigma para o Data Mesh


Foi uma longa leitura! Vamos resumir brevemente tudo o que está escrito acima. Examinamos algumas das principais características das plataformas de dados modernas: pipelines de dados complexos e centralizados, monolíticos (com centenas e milhares de tarefas intimamente ligados), equipes díspares altamente especializadas. Depois de falarmos sobre uma nova abordagem de malha de dados, que inclui produtos de dados distribuídos focados em domínios de negócios gerenciados por equipes multifuncionais (com proprietários de produtos e engenheiros de dados), usando uma infraestrutura de dados comum como plataforma de hospedagem.

O Data Mesh é uma arquitetura distribuída, com gerenciamento centralizado e padrões desenvolvidos que garantem a integrabilidade dos dados, e com uma infraestrutura centralizada que permite o uso do autoatendimento. Espero que o leitor seja bastante óbvio que essa arquitetura está muito longe de um conjunto de armazenamento pouco acoplado de dados inacessíveis, desenvolvido independentemente em diferentes departamentos.

imagem
Figura 12: Arquitetura de malha de dados de 10.000 metros

Você pode perguntar: como o Data Lake ou o Data Warehouse se encaixam nessa arquitetura? Eles são simplesmente nós separados (domínios) nessa arquitetura distribuída. Há uma alta probabilidade de que, em uma arquitetura como essa, não precisaremos mais do Data Lake. Afinal, teremos acesso à pesquisa dos dados originais de diferentes domínios de negócios, projetados na forma de produtos de dados.

Consequentemente, o Data Lake não é mais o elemento central de toda a arquitetura. Mas continuaremos a usar as tecnologias e ferramentas usadas para construir o Data Lake, seja para criar uma infraestrutura de dados comum ou para a implementação interna de nossos produtos de dados.

Isso realmente nos leva de volta para onde tudo começou. James dicksonem 2010, ele pretendia usar o Data Lake para um domínio comercial, e vários domínios de dados formariam o Water Garden.

A principal mudança de paradigma é considerar o produto de dados do domínio de negócios como uma tarefa de primeira prioridade e as ferramentas e tecnologias como uma segunda tarefa de prioridade (como um detalhe de implementação). Isso é para desviar o modelo mental de um Data Lake centralizado para um ecossistema de produtos de dados que se integram de maneira transparente e eficiente entre si.

Algumas palavras sobre relatórios e visualização (usando ferramentas de BI, etc.). O mesmo princípio se aplica a eles: nessa arquitetura, são nós separados. Essa. eles são produtos de dados independentes em um domínio comercial, focados principalmente no consumidor e não na fonte de dados.

Admito que, embora eu veja a aplicação bem-sucedida dos princípios do Data Mesh por meus clientes, escalá-los em grandes organizações ainda tem um longo caminho a percorrer. Mas a tecnologia obviamente não é uma limitação aqui. Todas as ferramentas que usamos hoje podem igualmente ser usadas para a distribuição e propriedade de produtos de dados por diferentes equipes. Em particular, a transição para a padronização de tarefas de processamento de dados por pacote e fluxo, bem como o uso de ferramentas como Apache Beam ou Google Cloud DataFlow , facilita o processamento de uma variedade de conjuntos de dados com endereços exclusivos.

Plataformas de catálogo de dados, como o Google Cloud Data Catalog, oferecem facilidade de descoberta, controle de acesso e gerenciamento centralizado de conjuntos de dados de domínios de negócios distribuídos. Um grande número de plataformas na nuvem permite que os domínios de negócios escolham adequados para o armazenamento direcionado de seus produtos de dados.

A necessidade de uma mudança de paradigma é óbvia. Existem todas as tecnologias e ferramentas necessárias para isso. Executivos de negócios e profissionais de processamento de dados devem reconhecer que o atual paradigma e abordagem de Big Data com uma grande plataforma de Data Lake só repetirá as falhas do passado, usando novas tecnologias e ferramentas em nuvem.

Vamos passar de uma plataforma de dados monolítica centralizada para um ecossistema de produtos de dados.

imagem

Links para fontes primárias e materiais adicionais sobre o tópico


More articles:


All Articles