Uma malha de dados é uma framework arquitetónica e organizacional que trata os dados como um produto (referidos neste documento como produtos de dados). Nesta estrutura, os produtos de dados são desenvolvidos pelas equipas que melhor compreendem esses dados e que seguem um conjunto de normas de gestão de dados ao nível da organização. Depois de implementados na malha de dados, os produtos de dados permitem que as equipas distribuídas numa organização descubram e acedam aos dados relevantes para as suas necessidades de forma mais rápida e eficiente. Para alcançar uma malha de dados com um bom funcionamento, tem de estabelecer primeiro os componentes arquitetónicos de alto nível e as funções organizacionais que este documento descreve.
Este documento faz parte de uma série que descreve como implementar uma malha de dados no Google Cloud. Parte do princípio de que leu e está familiarizado com os conceitos descritos no artigo Crie uma malha de dados moderna e distribuída com Google Cloud.
A série tem as seguintes partes:
- Arquitetura e funções numa malha de dados (este documento)
- Conceba uma plataforma de dados self-service para uma malha de dados
- Crie produtos de dados numa malha de dados
- Descubra e consuma produtos de dados numa malha de dados
Nesta série, a malha de dados descrita é interna a uma organização. Embora seja possível expandir uma arquitetura de malha de dados para fornecer produtos de dados a terceiros, esta abordagem expandida está fora do âmbito deste documento. A expansão de uma malha de dados envolve considerações adicionais além da utilização numa organização.
Arquitetura
Os seguintes termos-chave são usados para definir os componentes de arquitetura descritos nesta série:
- Produto de dados: um produto de dados é um contentor lógico ou um agrupamento de um ou mais recursos de dados relacionados.
- Recurso de dados: um recurso de dados é um recurso físico num sistema de armazenamento que contém dados estruturados ou armazena uma consulta que gera dados estruturados.
- Atributo de dados: um atributo de dados é um campo ou um elemento de um recurso de dados.
O diagrama seguinte oferece uma vista geral dos principais componentes de arquitetura numa malha de dados implementada no Google Cloud.
O diagrama anterior mostra o seguinte:
- Os serviços centrais permitem a criação e a gestão de produtos de dados, incluindo políticas organizacionais que afetam os participantes da malha de dados, controlos de acesso (através de grupos de gestão de identidade e de acesso) e os artefactos específicos da infraestrutura. Alguns exemplos destes compromissos e reservas, e da infraestrutura que facilita o funcionamento da malha de dados, são descritos no artigo Crie componentes e soluções de plataforma.
- Os serviços centrais fornecem principalmente o catálogo de dados para todos os produtos de dados na malha de dados e o mecanismo de descoberta para potenciais clientes destes produtos.
- Os domínios de dados expõem subconjuntos dos respetivos dados como produtos de dados através de interfaces de consumo de dados bem definidas. Estes produtos de dados podem ser uma tabela, uma vista, um ficheiro estruturado, um tópico ou uma stream. No BigQuery, seria um conjunto de dados e, no Cloud Storage, seria uma pasta ou um contentor. Podem existir diferentes tipos de interfaces que podem ser expostas como um produto de dados. Um exemplo de uma interface é uma vista do BigQuery sobre uma tabela do BigQuery. Os tipos de interfaces mais usados para fins de análise são abordados no artigo Crie produtos de dados numa malha de dados.
Implementação de referência da malha de dados
Pode encontrar uma implementação de referência desta arquitetura no
repositório data-mesh-demo.
Os scripts do Terraform usados na implementação de referência demonstram os conceitos de malha de dados e não se destinam a utilização em produção. Ao executar estes scripts, vai aprender a fazer o seguinte:
- Separe as definições dos produtos dos dados subjacentes.
- Crie modelos do catálogo de dados para descrever interfaces de produtos.
- Etiquete interfaces de produtos com estes modelos.
- Conceda autorizações aos consumidores do produto.
Para as interfaces de produtos, a implementação de referência cria e usa os seguintes tipos de interfaces:
- Vistas autorizadas sobre tabelas do BigQuery.
- Streams de dados baseadas em tópicos do Pub/Sub.
Para mais detalhes, consulte o ficheiro README no repositório.
Funções numa malha de dados
Para que uma malha de dados funcione bem, tem de definir funções claras para as pessoas que realizam tarefas na malha de dados. A propriedade é atribuída a arquétipos de equipas ou funções. Estas funções contêm os percursos do utilizador principais para as pessoas que trabalham na malha de dados. Para descrever claramente os percursos dos utilizadores, estes foram atribuídos a funções de utilizador. Estas funções de utilizador podem ser divididas e combinadas com base nas circunstâncias de cada empresa. Não precisa de mapear as funções diretamente com os funcionários ou as equipas na sua organização.
Um domínio de dados está alinhado com uma unidade de negócio (BU) ou uma função numa empresa. Alguns exemplos comuns de domínios empresariais podem ser o departamento de hipotecas de um banco ou os departamentos de clientes, distribuição, finanças ou recursos humanos de uma empresa. Em termos conceptuais, existem duas funções relacionadas com o domínio numa malha de dados: as equipas de produtores de dados e as equipas de consumidores de dados. É importante compreender que é provável que um único domínio de dados sirva ambas as funções em simultâneo. Uma equipa de domínio de dados produz produtos de dados a partir de dados que lhe pertencem. A equipa também consome produtos de dados para obter estatísticas empresariais e produzir produtos de dados derivados para utilização por outros domínios.
Além das funções baseadas no domínio, uma malha de dados também tem um conjunto de funções que são realizadas por equipas centralizadas na organização. Estas equipas centrais permitem o funcionamento da malha de dados, fornecendo supervisão, serviços e governação entre domínios. Reduzem o encargo operacional para os domínios de dados na produção e no consumo de produtos de dados, e facilitam as relações entre domínios necessárias para o funcionamento da malha de dados.
Este documento descreve apenas funções que têm um papel específico da malha de dados. Existem várias outras funções necessárias em qualquer empresa, independentemente da arquitetura usada para a plataforma. No entanto, estas outras funções estão fora do âmbito deste documento.
As quatro principais funções numa malha de dados são as seguintes:
- Equipas de produtores baseadas no domínio de dados: criam e mantêm produtos de dados ao longo do respetivo ciclo de vida. Estas equipas são frequentemente denominadas produtores de dados.
- Equipas de consumidores baseadas no domínio de dados: descubra produtos de dados e use-os em várias aplicações de análise. Estas equipas podem consumir produtos de dados para criar novos produtos de dados. Estas equipas são frequentemente referidas como os consumidores de dados.
- Equipa central de administração de dados: define e aplica políticas de administração de dados entre os produtores de dados, garantindo uma elevada qualidade e fiabilidade dos dados para os consumidores. Esta equipa é frequentemente designada por equipa de administração de dados.
- Equipa central da plataforma de infraestrutura de dados de self-service: oferece uma plataforma de dados de self-service para produtores de dados. Esta equipa também fornece as ferramentas para a deteção central de dados e a observabilidade dos produtos de dados que os consumidores e os produtores de dados usam. Esta equipa é frequentemente referida como a equipa da plataforma de dados.
Uma função adicional opcional a considerar é a de um centro de excelência (COE) para a malha de dados. O objetivo do COE é fornecer gestão da malha de dados. O COE é também a equipa de arbitragem designada que resolve quaisquer conflitos apresentados por qualquer uma das outras funções. Esta função é útil para ajudar a associar as outras quatro funções.
Equipa de produtores baseada no domínio de dados
Normalmente, os produtos de dados são criados com base num repositório físico de dados (seja um ou vários data warehouses, lagos ou streams). Uma organização precisa de funções tradicionais de plataforma de dados para criar e manter estes repositórios físicos. No entanto, estes papéis tradicionais da plataforma de dados não são normalmente as pessoas que criam o produto de dados.
Para criar produtos de dados a partir destes repositórios físicos, uma organização precisa de uma combinação de profissionais de dados, como engenheiros de dados e arquitetos de dados. A tabela seguinte apresenta todas as funções de utilizador específicas do domínio necessárias nas equipas de produtores de dados.
Função |
Responsabilidades |
Competências necessárias |
Resultados desejados |
|---|---|---|---|
Proprietário do produto de dados |
|
Análise de dados Arquitetura de dados Gestão de produtos |
|
Responsável técnico do produto de dados |
|
Engenharia de dados Arquitetura de dados Engenharia de software |
|
Apoio técnico para produtos de dados |
|
Engenharia de software Engenharia de fiabilidade de sites (EFS) |
|
Especialista no assunto (SME) para o domínio de dados |
|
Análise de dados Arquitetura de dados |
|
Proprietário dos dados |
|
|
|
Equipas de consumidores baseadas no domínio de dados
Numa malha de dados, as pessoas que consomem um produto de dados são normalmente utilizadores de dados que estão fora do domínio do produto de dados. Estes consumidores de dados usam um catálogo de dados central para encontrar produtos de dados relevantes para as suas necessidades. Uma vez que é possível que mais do que um produto de dados possa satisfazer as suas necessidades, os consumidores de dados podem acabar por subscrever vários produtos de dados.
Se os consumidores de dados não conseguirem encontrar o produto de dados necessário para o respetivo exemplo de utilização, é da sua responsabilidade consultar diretamente o COE da malha de dados. Durante essa consulta, os consumidores de dados podem apresentar as suas necessidades de dados e procurar aconselhamento sobre como satisfazer essas necessidades através de um ou mais domínios.
Quando procuram um produto de dados, os consumidores de dados procuram dados que os ajudem a alcançar vários exemplos de utilização, como painéis de controlo e relatórios de estatísticas persistentes, relatórios de desempenho individuais e outras métricas de desempenho da empresa. Em alternativa, os consumidores de dados podem estar à procura de produtos de dados que possam ser usados em exemplos de utilização de inteligência artificial (IA) e aprendizagem automática (AA). Para alcançar estes vários exemplos de utilização, os consumidores de dados precisam de uma combinação de perfis de profissionais de dados, que são os seguintes:
Função |
Responsabilidades |
Competências necessárias |
Resultados desejados |
|---|---|---|---|
Analista de dados |
Pesquisa, identifica, avalia e subscreve produtos de dados de domínio único ou de vários domínios para criar uma base para o funcionamento das estruturas de inteligência empresarial. |
Engenharia de análise Análise empresarial |
|
Programador de aplicações |
Desenvolve uma estrutura de aplicação para o consumo de dados em um ou mais produtos de dados, dentro ou fora do domínio. |
Desenvolvimento de aplicações Engenharia de dados |
|
Especialista em visualização de dados |
|
Análise de requisitos Visualização de dados |
|
Cientista de dados |
|
Engenharia de ML Engenharia de análise |
|
Equipa de gestão de dados central
A equipa de administração de dados permite que os produtores e os consumidores de dados partilhem, agreguem e calculem dados em regime de self-service, sem introduzir riscos de conformidade na organização.
Para cumprir os requisitos de conformidade da organização, a equipa de administração de dados é uma combinação de perfis de profissionais de dados, que são os seguintes:
Função |
Responsabilidades |
Competências necessárias |
Resultados desejados |
|---|---|---|---|
Especialista de gestão de dados |
|
Especialista jurídico Especialista em segurança Especialista em privacidade de dados |
|
Responsável pelos dados (integrado em cada domínio) |
|
Arquitetura de dados Gestão de dados |
|
Engenheiro de gestão de dados |
|
Engenharia de software |
|
Equipa central da plataforma de infraestrutura de dados self-service
A equipa da plataforma de infraestrutura de dados self-service, ou apenas a equipa da plataforma de dados, é responsável pela criação de um conjunto de componentes de infraestrutura de dados. As equipas de domínio de dados distribuídos usam estes componentes para criar e implementar os respetivos produtos de dados. A equipa da plataforma de dados também promove práticas recomendadas e introduz ferramentas e metodologias que ajudam a reduzir a carga cognitiva das equipas distribuídas quando adotam novas tecnologias.
A infraestrutura da plataforma deve oferecer uma integração fácil com as ferramentas de operações para observabilidade global, instrumentação e automatização da conformidade. Em alternativa, a infraestrutura deve facilitar essa integração para configurar equipas distribuídas para o sucesso.
A equipa da plataforma de dados tem um modelo de responsabilidade partilhada que usa com as equipas de domínio distribuídas e a equipa de infraestrutura subjacente. O modelo mostra as responsabilidades esperadas dos consumidores da plataforma e os componentes da plataforma que a equipa da plataforma de dados suporta.
Uma vez que a plataforma de dados é, em si mesma, um produto interno, não suporta todos os exemplos de utilização. Em alternativa, a equipa da plataforma de dados lança continuamente novos serviços e funcionalidades de acordo com um plano prioritário.
A equipa da plataforma de dados pode ter um conjunto padrão de componentes implementados e em desenvolvimento. No entanto, as equipas de domínio de dados podem optar por usar um conjunto de componentes diferente e único se as necessidades de uma equipa não se alinharem com as fornecidas pela plataforma de dados. Se as equipas do domínio de dados escolherem uma abordagem diferente, têm de garantir que qualquer infraestrutura de plataforma que criem e mantenham está em conformidade com as políticas e as salvaguardas ao nível da organização para segurança e gestão de dados. Para a infraestrutura da plataforma de dados desenvolvida fora da equipa central da plataforma de dados, a equipa da plataforma de dados pode optar por co-investir ou incorporar os seus próprios engenheiros nas equipas de domínio. A decisão da equipa da plataforma de dados de investir em conjunto ou incorporar engenheiros pode depender da importância estratégica da infraestrutura da plataforma do domínio de dados para a organização. Ao manterem-se envolvidas no desenvolvimento da infraestrutura por equipas de domínio de dados, as organizações podem fornecer o alinhamento e a especialização técnica necessários para reembalar quaisquer novos componentes de infraestrutura da plataforma que estejam em desenvolvimento para reutilização futura.
Pode ter de limitar a autonomia nas fases iniciais da criação de uma malha de dados se o seu objetivo inicial for obter a aprovação das partes interessadas para expandir a malha de dados. No entanto, limitar a autonomia acarreta o risco de criar um gargalo na equipa da plataforma de dados central. Este gargalo pode impedir a expansão da malha de dados. Por isso, quaisquer decisões de centralização devem ser tomadas cuidadosamente. Para os produtores de dados, fazer as suas escolhas técnicas a partir de um conjunto limitado de opções disponíveis pode ser preferível a avaliar e escolher a partir de uma lista ilimitada de opções. A promoção da autonomia dos produtores de dados não equivale à criação de um panorama tecnológico não regulamentado. Em alternativa, o objetivo é promover a conformidade e a adoção da plataforma, encontrando o equilíbrio certo entre a liberdade de escolha e a padronização.
Por último, uma boa equipa de plataforma de dados é uma fonte central de formação e práticas recomendadas para o resto da empresa. Seguem-se algumas das atividades mais impactantes que recomendamos que as equipas da plataforma de dados centralizada realizem:
- Promover revisões regulares do design arquitetónico para novos projetos funcionais e propor formas comuns de desenvolvimento entre as equipas de desenvolvimento.
- Partilhar conhecimentos e experiências, e definir coletivamente práticas recomendadas e diretrizes arquitetónicas.
- Garantir que os engenheiros têm as ferramentas certas para validar e verificar erros comuns, como problemas com o código, erros e degradações de desempenho.
- Organizar hackatons internos para que as equipas de desenvolvimento possam apresentar os seus requisitos para necessidades de ferramentas internas.
Seguem-se exemplos de funções e responsabilidades da equipa da plataforma de dados central:
| Role | Responsabilidades | Competências necessárias |
Resultados desejados |
|---|---|---|---|
Proprietário do produto da plataforma de dados |
|
Estratégia e operações de dados Gestão de produtos Gestão de partes interessadas |
|
Engenheiro de plataforma de dados |
|
Engenharia de dados Engenharia de software |
|
Engenheiro de plataforma e segurança (um representante das equipas de TI centrais, como redes e segurança, que está integrado na equipa da plataforma de dados) |
|
Engenharia de infraestruturas Engenharia de software |
|
Arquiteto empresarial |
|
Arquitetura de dados Iteração de soluções e resolução de problemas Criação de consenso |
|
Considerações adicionais para uma malha de dados
Existem várias opções de arquitetura para uma plataforma de dados de estatísticas, cada uma com pré-requisitos diferentes. Para ativar cada arquitetura de malha de dados, recomendamos que a sua organização siga as práticas recomendadas descritas nesta secção.
Adquira financiamento da plataforma
Conforme explicado na publicação do blogue "Se quiser transformar, comece pelas finanças", a plataforma nunca está concluída: está sempre a funcionar com base num plano prioritário. Por conseguinte, a plataforma tem de ser financiada como um produto e não como um projeto com um ponto final fixo.
O primeiro adotante da malha de dados suporta o custo. Normalmente, o custo é partilhado entre a empresa que forma o primeiro domínio de dados para iniciar a malha de dados e a equipa de tecnologia central, que geralmente alberga a equipa central da plataforma de dados.
Para convencer as equipas financeiras a aprovarem o financiamento da plataforma central, recomendamos que apresente um argumento comercial sobre o valor da plataforma centralizada que se vai concretizar ao longo do tempo. Esse valor resulta da reimplementação dos mesmos componentes em equipas de fornecimento individuais.
Defina a plataforma viável mínima para a malha de dados
Para ajudar a definir a plataforma mínima viável para a malha de dados, recomendamos que teste e itere com um ou mais exemplos práticos. Para o seu teste-piloto, encontre exemplos de utilização necessários e onde exista um consumidor pronto para adotar o produto de dados resultante. Os exemplos de utilização já devem ter financiamento para desenvolver os produtos de dados, mas deve existir uma necessidade de contributo das equipas técnicas.
Certifique-se de que a equipa que está a implementar o teste-piloto compreende o modelo de funcionamento da malha de dados da seguinte forma:
- A empresa (ou seja, a equipa de produção de dados) é proprietária da lista de pendências, do apoio técnico e da manutenção.
- A equipa central define os padrões de autosserviço e ajuda a empresa a criar o produto de dados, mas transfere o produto de dados para a empresa para execução e propriedade quando estiver concluído.
- O objetivo principal é comprovar o modelo de funcionamento da empresa (domínios que produzem, domínios que consomem). O objetivo secundário é validar o modelo de funcionamento técnico (padrões de self-service desenvolvidos pela equipa central).
- Como os recursos da equipa da plataforma são limitados, use o modelo de equipas principais e secundárias para reunir conhecimentos, mas ainda permitir o desenvolvimento de serviços e produtos de plataforma especializados.
Também recomendamos que faça o seguinte:
- Planeie roteiros em vez de deixar que os serviços e as funcionalidades evoluam organicamente.
- Definir capacidades mínimas viáveis da plataforma que abrangem o carregamento, o armazenamento, o processamento, a análise e a aprendizagem automática.
- Incorporar a governação de dados em cada passo, e não como um fluxo de trabalho separado.
- Implementar as capacidades mínimas na governação, na plataforma, na cadeia de valor e na gestão de alterações. As capacidades mínimas são as que satisfazem 80% dos exemplos de utilização.
Planeie a coexistência da malha de dados com uma plataforma de dados existente
Muitas organizações que querem implementar uma malha de dados já têm uma plataforma de dados existente, como um lago de dados, um armazém de dados ou uma combinação de ambos. Antes de implementar uma malha de dados, estas organizações têm de criar um plano para a forma como a respetiva plataforma de dados existente pode evoluir à medida que a malha de dados cresce.
Estas organizações devem considerar fatores como os seguintes:
- Os recursos de dados mais eficazes na malha de dados.
- Os recursos que têm de permanecer na plataforma de dados existente.
- Se os recursos têm de ser movidos ou se podem ser mantidos na plataforma existente e continuar a participar na malha de dados.
O que se segue?
- Para saber mais sobre a conceção e o funcionamento de uma topologia de nuvem, consulte o Google Cloud Framework de arquitetura bem estruturada.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.