Uma malha de dados é um framework arquitetônico e organizacional que trata os dados como um produto (referido neste documento como produtos de dados). Nesse framework, os produtos de dados são desenvolvidos pelas equipes que entendem melhor esses dados e que seguem um conjunto de padrões de governança de dados em toda a organização. Depois que os produtos de dados são implantados na malha de dados, as equipes distribuídas em uma organização podem descobrir e acessar dados relevantes de acordo com as necessidades deles de maneira mais rápida e eficiente. Para alcançar essa malha de dados com bom funcionamento, primeiro você precisa estabelecer os componentes arquitetônicos de alto nível e os papéis organizacionais descritos neste documento.
Este documento faz parte de uma série que descreve como implementar uma malha de dados no Google Cloud. Ele pressupõe que você leu e conhece os conceitos descritos em Criar uma malha de dados moderna e distribuída com o Google Cloud.
A série tem as seguintes partes:
- Arquitetura e funções em uma malha de dados (este documento)
- Projetar uma plataforma de dados de autoatendimento para uma malha de dados
- Criar produtos de dados em uma malha de dados
- Descobrir e consumir produtos de dados em uma malha de dados
Nesta série, a malha de dados descrita é interna a uma organização. Embora seja possível estender uma arquitetura de malha de dados para fornecer produtos de dados a terceiros, essa abordagem estendida está fora do escopo deste documento. A extensão da malha de dados envolve outras considerações além do uso dentro de uma organização.
Arquitetura
Os termos-chave a seguir são usados para definir os componentes de arquitetura que são descritos nesta série:
- Produto de dados: é um contêiner lógico ou agrupamento de um ou mais recursos de dados relacionados.
- Recurso de dados: é um recurso físico em um sistema de armazenamento que armazena dados estruturados ou armazena uma consulta que gera dados estruturados.
- Atributo de dados: é um campo ou elemento de um recurso de dados.
O diagrama a seguir fornece uma visão geral dos principais componentes de arquitetura em uma malha de dados implementada no Google Cloud.
O diagrama anterior mostra o seguinte:
- Os serviços centrais permitem a criação e o gerenciamento de produtos de dados, incluindo políticas organizacionais que afetam os participantes da malha de dados, os controles de acesso (por meio de grupos do Identity and Access Management) e os artefatos específicos da infraestrutura. Exemplos de compromissos e reservas e infraestrutura que facilita o funcionamento da malha de dados são descritos em Criar soluções e componentes de plataforma.
- Os serviços centrais fornecem principalmente o Data Catalog a todos os produtos de dados na malha de dados e o mecanismo de descoberta para clientes em potencial desses produtos.
- Os domínios de dados expõem subconjuntos de dados como produtos de dados por meio de interfaces de consumo de dados bem definidas. Esses produtos de dados, podem ser uma tabela, visualização, arquivo estruturado, tópico ou stream. No BigQuery, seria um conjunto de dados e, no Cloud Storage, uma pasta ou um bucket. Pode haver diferentes tipos de interface que podem ser expostas como um produto de dados. Um exemplo de interface é uma visualização do BigQuery em uma tabela do BigQuery. Os tipos de interfaces mais usados para fins analíticos são discutidos em Criar produtos de dados em uma malha de dados.
Implementação de referência de malha de dados
Veja uma implementação de referência dessa arquitetura no
repositório data-mesh-demo.
Os scripts do Terraform usados na implementação de referência demonstram
conceitos de malha de dados e não se destinam ao uso em produção. Ao executar esses scripts,
você aprenderá a fazer o seguinte:
- Separar as definições de produtos dos dados subjacentes.
- Criar modelos do Data Catalog para descrever interfaces de produtos.
- Criar tags para as interfaces de produtos com esses modelos.
- Conceder permissões aos consumidores do produto.
Para as interfaces de produto, a implementação de referência cria e usa os seguintes tipos de interface:
- Visualizações autorizadas nas tabelas do BigQuery.
- Fluxos de dados baseados em tópicos do Pub/Sub.
Para mais detalhes, consulte o arquivo README no repositório.
Funções em uma malha de dados
Para que uma malha de dados funcione bem, você precisa definir papéis claros para as pessoas que realizam tarefas na malha de dados. A propriedade é atribuída aos arquétipos ou funções da equipe. Essas funções contêm as principais jornadas do usuário para as pessoas que trabalham na malha de dados. Para descrever claramente as jornadas do usuário, elas foram atribuídas aos papéis do usuário. Esses papéis de usuário podem ser divididos e combinados com base nas circunstâncias de cada empresa. Você não precisa mapear os papéis diretamente com os funcionários ou as equipes da sua organização.
Um domínio de dados é alinhado com uma unidade de negócios (BU, na sigla em inglês) ou uma função em uma empresa. Exemplos comuns de domínios de negócios podem ser o departamento de hipoteca em um banco ou os departamentos de cliente, distribuição, finanças ou de RH de uma empresa. Conceitualmente, existem duas funções relacionadas ao domínio em uma malha de dados: as equipes de produtor de dados e as equipes de consumidor de dados. É importante entender que um único domínio de dados provavelmente atenderá às duas funções de uma só vez. Uma equipe de domínio de dados produz produtos de dados próprios. A equipe também consome produtos de dados para gerar insights de negócios e produzir produtos de dados derivados para o uso de outros domínios.
Além das funções baseadas em domínio, uma malha de dados também tem um conjunto de funções realizadas por equipes centralizadas na organização. Essas equipes centrais permitem o funcionamento da malha de dados oferecendo supervisão, serviços e governança entre domínios. Elas reduzem a carga operacional para domínios de dados na produção e consumo de produtos de dados e facilitam as relações de vários domínios necessárias para que a malha de dados opere.
Neste documento, descrevemos apenas funções que têm um papel específico da malha de dados. Há vários outros papéis necessários em qualquer empresa, independentemente da arquitetura usada na plataforma. No entanto, esses outros papéis estão fora do escopo deste documento.
As quatro funções principais de uma malha de dados são as seguintes.
- Equipes do produtor baseadas em domínio de dados: crie e mantenha produtos de dados durante todo o ciclo de vida. Essas equipes costumam ser chamadas de produtores de dados.
- Equipes do consumidor baseadas em domínios de dados: descubra produtos de dados e os use em vários aplicativos de análise. Essas equipes podem consumir produtos de dados para criar novos produtos de dados. Essas equipes são geralmente chamadas de consumidores de dados.
- Equipe central de governança de dados: define e aplica políticas de governança de dados entre os produtores de dados, garantindo alta qualidade de dados e confiabilidade dos dados. Essa equipe costuma ser chamada de equipe de governança de dados.
- Equipe central de plataforma de infraestrutura de dados de autoatendimento:oferece uma plataforma de dados de autoatendimento para produtores de dados. Essa equipe também fornece as ferramentas para descoberta de dados centrais e observabilidade do produto de dados que consumidores e produtores de dados usam. Essa equipe é frequentemente chamada de equipe da plataforma de dados.
Uma função extra opcional a ser considerada é a de um Centro de Excelência (COE, na sigla em inglês) para a malha de dados. O objetivo do COE é fornecer o gerenciamento da malha de dados. A COE também é a equipe de arbitragem designada que resolve todos os conflitos criados por qualquer uma das outras funções. Essa função é útil para ajudar a conectar as outras quatro funções.
Equipe de produtor baseada em domínio de dados
Normalmente, os produtos de dados são criados com base em um repositório físico de dados (um ou vários data warehouses, lakes ou streams). Uma organização precisa de papéis tradicionais da plataforma de dados para criar e manter esses repositórios físicos. No entanto, esses papéis tradicionais não são as pessoas que criam o produto de dados.
Para criar produtos de dados usando esses repositórios físicos, uma organização precisa ter uma combinação de profissionais de dados, como engenheiros e arquitetos de dados. A tabela a seguir lista todos os papéis de usuário específicos do domínio necessários em equipes de produtores de dados.
Papel |
Responsabilidades |
Habilidades necessárias |
Ação desejada |
|---|---|---|---|
Proprietário de produto de dados |
|
Análise de dados Arquitetura de dados Gerenciamento de produtos |
|
Líder técnico do produto de dados |
|
Engenharia de dados Arquitetura de dados Engenharia de software |
|
Suporte a produtos de dados |
|
Engenharia de software Engenharia de confiabilidade do site (SRE) |
|
Especialista em assuntos (SME) para domínios de dados |
|
Análise de dados Arquitetura de dados |
|
Proprietário dos dados |
|
|
|
Equipes de consumidores baseadas em domínios de dados
Em uma malha de dados, as pessoas que consomem um produto de dados costumam ser usuários de dados que estão fora do domínio do produto. Esses consumidores usam um catálogo de dados central para encontrar produtos de dados relevantes para as necessidades deles. Como é possível que mais de um produto de dados atenda às necessidades deles, os consumidores de dados podem acabar se inscrevendo em vários produtos de dados.
Se os consumidores de dados não conseguirem encontrar o produto de dados necessário para o caso de uso, é sua responsabilidade consultar diretamente com o COE da malha de dados. Durante essa consulta, os consumidores de dados podem aumentar as necessidades de dados e buscar orientações sobre como atender a essas necessidades por um ou mais domínios.
Ao procurar um produto de dados, os consumidores de dados estão procurando dados que os ajudem a alcançar vários casos de uso, como painéis e relatórios de análise persistentes, relatórios de desempenho individuais e outras métricas de desempenho comercial. Como alternativa, os consumidores de dados podem estar procurando produtos de dados que possam ser usados em casos de uso de inteligência artificial (IA) e machine learning (ML). Para alcançar esses vários casos de uso, os consumidores de dados exigem uma combinação de perfis de profissionais de dados, que são os seguintes:
Papel |
Responsabilidades |
Habilidades necessárias |
Ação desejada |
|---|---|---|---|
Analista de dados |
Pesquisa, identifica, avalia e assina produtos de domínio de domínio único ou de vários domínios para criar uma base para que os frameworks de Business Intelligence funcionem. |
Engenharia do Analytics Análise de negócios |
|
Desenvolvedor de aplicativos |
Desenvolve um framework de aplicativos para consumo de dados em um ou mais produtos de dados, dentro ou fora do domínio. |
Desenvolvimento de aplicativos Engenharia de dados |
|
Especialista em visualização de dados |
|
Análise de requisitos Visualização de dados |
|
Cientista de dados |
|
Engenharia de ML Engenharia do Google Analytics |
|
Equipe central de governança de dados
A equipe de governança de dados permite que os produtores e consumidores de dados compartilhem, agreguem e calculem dados com segurança, de maneira autônoma, sem introduzir riscos de conformidade à organização.
Para atender aos requisitos de conformidade da organização, a equipe de governança de dados é uma combinação de perfis de profissionais de dados, que são:
Papel |
Responsabilidades |
Habilidades necessárias |
Ação desejada |
|---|---|---|---|
Especialista em governança de dados |
|
PME legal PME de segurança PME de privacidade de dados |
|
Gerente de dados (local em cada domínio) |
|
Arquitetura de dados Gestão de dados |
|
Engenheiro de governança de dados |
|
Engenharia de software |
|
Equipe central de plataforma de infraestrutura de dados de autoatendimento
A equipe da plataforma de infraestrutura de dados de autoatendimento ou apenas a equipe da plataforma de dados é responsável por criar um conjunto de componentes da infraestrutura de dados. As equipes de domínio de dados distribuídos usam esses componentes para criar e implantar os produtos de dados. A equipe da plataforma de dados também promove práticas recomendadas e apresenta ferramentas e metodologias que ajudam a reduzir a carga cognitiva para equipes distribuídas ao adotar novas tecnologias.
A infraestrutura da plataforma deve fornecer integração fácil com ferramentas de operação para observabilidade global, instrumentação e automação de conformidade. Por outro lado, a infraestrutura deve facilitar essa integração para preparar as equipes distribuídas para o sucesso.
A equipe da plataforma de dados tem um modelo de responsabilidade compartilhada que ela usa com as equipes de domínio distribuídas e a equipe de infraestrutura subjacente. O modelo mostra quais responsabilidades são esperadas dos consumidores da plataforma e a quais componentes da plataforma a equipe de dados oferece suporte.
Como a plataforma de dados é um produto interno, a plataforma não oferece suporte a todos os casos de uso. Em vez disso, a equipe da plataforma de dados lança continuamente novos serviços e recursos de acordo com um roteiro priorizado.
A equipe da plataforma de dados pode ter um conjunto padrão de componentes em desenvolvimento e em desenvolvimento. No entanto, as equipes de domínio de dados podem optar por usar um conjunto diferente e exclusivo de componentes se as necessidades de uma equipe não se alinharem às fornecidas pela plataforma de dados. Se as equipes de domínio de dados escolherem uma abordagem diferente, elas precisarão garantir que toda a infraestrutura de plataforma que criarem e mantiverem esteja em conformidade com as políticas e os protetores de toda a organização para a segurança e a governança de dados. Para infraestruturas de plataforma de dados desenvolvidas fora da equipe central da plataforma de dados, a equipe da plataforma de dados pode optar por investir em conjunto ou incorporar os próprios engenheiros nas equipes do domínio. A escolha de coinvestir ou incorporar engenheiros pela equipe da plataforma de dados pode depender da importância estratégica da infraestrutura da plataforma do domínio de dados para a organização. Ao se envolverem no desenvolvimento de infraestrutura por equipes de domínio de dados, as organizações podem fornecer o alinhamento e a experiência técnica necessária para reempacotar novos componentes de infraestrutura de plataforma que estejam em desenvolvimento para reutilização futura.
Talvez seja necessário limitar a autonomia nos estágios iniciais de criação de uma malha de dados se o objetivo inicial for receber a aprovação das partes interessadas para escalonar verticalmente a malha de dados. No entanto, limitar a autonomia corre o risco de criar um gargalo na equipe da plataforma de dados central. Esse gargalo pode impedir o escalonamento da malha de dados. Portanto, todas as decisões de centralização precisam ser tomadas com cuidado. Para os produtores de dados, fazer as escolhas técnicas deles em um conjunto limitado de opções disponíveis pode ser preferível para avaliar e escolher entre uma lista ilimitada de opções por conta própria. Promover a autonomia dos produtores de dados não equivale a criar um cenário tecnológico. Em vez disso, o objetivo é impulsionar a conformidade e a adoção da plataforma, equilibrando a liberdade de escolha e padrão.
Uma boa equipe de plataforma de dados é uma fonte central de educação e práticas recomendadas para o restante da empresa. Veja a seguir algumas das atividades mais impactantes que recomendamos para as equipes da plataforma de dados central:
- Incentivo a análises regulares de design arquitetônico para novos projetos funcionais e proposta de maneiras comuns de desenvolvimento entre equipes de desenvolvimento.
- Compartilhar conhecimento e experiências e definir coletivamente as práticas recomendadas e as diretrizes de arquitetura.
- Garantir que os engenheiros tenham as ferramentas certas para validar e verificar dificuldades comuns, como problemas com código, bugs e degradações de desempenho.
- Organização de hackathons internos para que as equipes de desenvolvimento possam destacar os requisitos para as ferramentas internas.
Alguns exemplos de papéis e responsabilidades da equipe da plataforma de dados central:
| Papel | Responsabilidades | Habilidades necessárias |
Ação desejada |
|---|---|---|---|
Proprietário de produtos da plataforma de dados |
|
Operações e estratégia de dados Gerenciamento de produtos Gerenciamento de partes interessadas |
|
Engenheiro de plataforma de dados |
|
Engenharia de dados Engenharia de software |
|
Engenheiro de segurança e plataforma, representante das equipes centrais de TI, como rede e segurança, que está incorporado à equipe da plataforma de dados |
|
Engenharia de infraestrutura Engenharia de software |
|
Arquiteto corporativo |
|
Arquitetura de dados Repetição da solução e solução de problemas Consenso de criação |
|
Outras considerações sobre a malha de dados
Há várias opções de arquitetura para uma plataforma de dados de análise, cada uma com pré-requisitos diferentes. Para ativar cada arquitetura de malha de dados, recomendamos que sua organização siga as práticas recomendadas descritas nesta seção.
Conseguir financiamento da plataforma
Como explicado na postagem do blog "Se você quer transformar o início com finanças", a plataforma nunca está concluída: está sempre funcionando com base em um roteiro priorizado. Portanto, a plataforma precisa ser financiada como um produto, não como um projeto com um endpoint fixo.
O primeiro usuário da malha de dados carrega o custo. Geralmente, o custo é compartilhado entre a empresa que forma o primeiro domínio de dados para iniciar a malha de dados e a equipe de tecnologia central, que geralmente abriga a equipe da plataforma de dados central.
Para convencer as equipes financeiras a aprovar o financiamento da plataforma central, recomendamos que você estabeleça um caso de negócios para o valor da plataforma centralizada que está sendo realizada ao longo do tempo. Esse valor vem da reimplementação dos mesmos componentes em equipes de entrega individuais.
Definir a plataforma mínima viável para a malha de dados
Para definir a plataforma mínima viável da malha de dados, recomendamos testar e iterar com um ou mais casos de negócios. Para o piloto, encontre casos de uso necessários e onde há um consumidor pronto para adotar o produto de dados resultante. Os casos de uso já teriam financiamento para desenvolver os produtos de dados, mas seria necessário ter a entrada de equipes técnicas.
Verifique se a equipe que está implementando o piloto entende o modelo operacional da malha de dados da seguinte maneira:
- A empresa (ou seja, a equipe de produtores de dados) é proprietária do backlog, do suporte e da manutenção.
- A equipe central define os padrões de autoatendimento e ajuda a empresa a criar o produto de dados, mas transmite o produto de dados à empresa para execução e propriedade quando está concluído.
- O objetivo principal é comprovar o modelo operacional de negócios (domínios produzidos, domínios consumidos). O objetivo secundário é provar o modelo operacional técnico (padrões de autoatendimento desenvolvidos pela equipe central).
- Como os recursos da equipe de plataforma são limitados, use o modelo de equipes de tronco e ramificação para agrupar conhecimento, mas ainda permitir o desenvolvimento de produtos e serviços de plataforma especializados.
Também recomendamos que você faça o seguinte:
- Planeje roteiros em vez de permitir que serviços e recursos evoluam de forma orgânica.
- Definir os recursos mínimos viáveis da plataforma, incluindo ingestão, armazenamento, processamento, análise e ML.
- Incorpore a governança de dados em cada etapa, não como um fluxo de trabalho separado.
- Implementar os recursos mínimos de governança, plataforma, fluxo de valor e gestão da mudança. Os recursos mínimos são aqueles que atendem a 80% dos casos de negócios.
Planejar a coexistência da malha de dados com uma plataforma de dados existente
Muitas organizações que querem implementar uma malha de dados provavelmente já têm uma plataforma de dados, como um data lake, um data warehouse ou uma combinação de ambos. Antes de implementar uma malha de dados, essas organizações precisam planejar como a plataforma de dados atual pode evoluir à medida que a malha de dados cresce.
Essas organizações devem considerar fatores como os seguintes:
- Os recursos de dados que são mais eficazes na malha de dados.
- Os recursos que precisam permanecer na plataforma de dados atual.
- Se os recursos precisam ser movidos ou se podem ser mantidos na plataforma existente e ainda participar da malha de dados.
A seguir
- Para saber mais sobre como projetar e operar uma topologia de nuvem, consulte o Framework da arquitetura do Google Cloud.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.