Conceba uma plataforma de dados self-service para uma malha de dados

Last reviewed 2024-09-03 UTC

Numa malha de dados, uma plataforma de dados de autosserviço permite aos utilizadores gerar valor a partir dos dados, permitindo-lhes criar, partilhar e usar produtos de dados de forma autónoma. Para tirar o máximo partido destas vantagens, recomendamos que a sua plataforma de dados de ajuda autónoma ofereça as capacidades descritas neste documento.

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 em Crie uma malha de dados moderna e distribuída com Google Cloud e Arquitetura e funções numa malha de dados.

A série tem as seguintes partes:

Normalmente, as equipas de plataformas de dados criam plataformas de dados de autosserviço centrais, conforme descrito neste documento. Esta equipa cria as soluções e os componentes que as equipas de domínio (produtores e consumidores de dados) podem usar para criar e consumir produtos de dados. As equipas de domínio representam partes funcionais de uma malha de dados. Ao criar estes componentes, a equipa da plataforma de dados permite uma experiência de desenvolvimento simples e reduz a complexidade da criação, implementação e manutenção de produtos de dados seguros e interoperáveis.

Em última análise, a equipa da plataforma de dados deve permitir que as equipas de domínio avancem mais rapidamente. Ajudam a aumentar a eficiência das equipas de domínio, fornecendo-lhes um conjunto limitado de ferramentas que satisfazem as suas necessidades. Ao fornecer estas ferramentas, a equipa da plataforma de dados elimina o encargo de a equipa do domínio criar e obter estas ferramentas por si própria. As escolhas de ferramentas devem ser personalizáveis para diferentes necessidades e não forçar uma forma inflexível de trabalhar nas equipas do domínio de dados.

A equipa da plataforma de dados não deve focar-se na criação de soluções personalizadas para orquestradores de pipelines de dados nem para sistemas de integração contínua e implementação contínua (CI/CD). As soluções, como os sistemas de CI/CD, estão prontamente disponíveis como serviços na nuvem geridos, por exemplo, o Cloud Build. A utilização de serviços de nuvem geridos pode reduzir os custos gerais operacionais para a equipa da plataforma de dados e permitir-lhe focar-se nas necessidades específicas das equipas do domínio de dados como utilizadores da plataforma. Com a redução dos encargos operacionais, a equipa da plataforma de dados pode dedicar mais tempo a responder às necessidades específicas das equipas do domínio de dados.

Arquitetura

O diagrama seguinte ilustra os componentes de arquitetura de uma plataforma de dados de autosserviço. O diagrama também mostra como estes componentes podem ajudar as equipas à medida que desenvolvem e consomem produtos de dados na malha de dados.

Componentes da plataforma de dados self-service, conforme descrito no texto seguinte.

Conforme mostrado no diagrama anterior, a plataforma de dados self-service oferece o seguinte:

  • Soluções de plataforma: estas soluções consistem em componentes componíveis para o aprovisionamento de projetos Google Cloud e recursos, que os utilizadores selecionam e montam em diferentes combinações para satisfazer os respetivos requisitos específicos. Em vez de interagirem diretamente com os componentes, os utilizadores da plataforma podem interagir com soluções da plataforma para os ajudar a alcançar um objetivo específico. As equipas do domínio de dados devem conceber soluções de plataforma para resolver problemas comuns e áreas de atrito que causam atrasos no desenvolvimento e no consumo de produtos de dados. Por exemplo, as equipas de domínio de dados que integram a malha de dados podem usar um modelo de infraestrutura como código (IaC). A utilização de modelos de IaC permite-lhes criar rapidamente um conjunto de Google Cloud projetos com autorizações padrão da gestão de identidade e de acesso (IAM) , rede, políticas de segurança e APIs Google Cloud relevantes ativadas para o desenvolvimento de produtos de dados. Recomendamos que cada solução seja acompanhada de documentação, como orientações de "como começar" e exemplos de código. As soluções de plataforma de dados e os respetivos componentes têm de ser seguros e estar em conformidade por predefinição.

  • Serviços comuns: estes serviços oferecem capacidade de deteção, gestão, partilha e observação de produtos de dados. Estes serviços facilitam a confiança dos consumidores de dados nos produtos de dados e são uma forma eficaz para os produtores de dados alertarem os consumidores de dados para problemas com os respetivos produtos de dados.

As soluções de plataformas de dados e os serviços comuns podem incluir o seguinte:

  • Modelos de IaC para configurar ambientes de espaço de trabalho de desenvolvimento de produtos de dados fundamentais, que incluem o seguinte:
    • IAM
    • Registo e monitorização
    • Trabalhar em rede
    • Proteções de segurança e conformidade
    • Etiquetagem de recursos para atribuição de faturação
    • Armazenamento, transformação e publicação de produtos de dados
    • Registo, catalogação e etiquetagem de metadados de produtos de dados
  • Modelos de IaC que seguem as diretrizes de segurança organizacionais e as práticas recomendadas que podem ser usados para implementar recursos em espaços de trabalho de desenvolvimento de produtos de dados existentes. Google Cloud
  • Modelos de aplicações e pipelines de dados que podem ser usados para iniciar novos projetos ou usados como referência para projetos existentes. Seguem-se alguns exemplos de modelos:
    • Utilização de bibliotecas e frameworks comuns
    • Integração com ferramentas de registo, monitorização e observabilidade da plataforma
    • Ferramentas de criação e teste
    • Gestão da configuração
    • Pipelines de CI/CD e embalagem para implementação
    • Autenticação, implementação e gestão de credenciais
  • Serviços comuns para fornecer observabilidade e administração de produtos de dados que podem incluir o seguinte:
    • Verificações de tempo de atividade para mostrar o estado geral dos produtos de dados.
    • Métricas personalizadas para fornecer indicadores úteis sobre produtos de dados.
    • Apoio técnico operacional por parte da equipa central, de modo que as equipas consumidoras de dados sejam alertadas para alterações nos produtos de dados que usam.
    • Tabelas de dados de produtos para mostrar o desempenho dos produtos de dados.
    • Um catálogo de metadados para descobrir produtos de dados.
    • Um conjunto de políticas computacionais definidas centralmente que podem ser aplicadas globalmente na malha de dados.
    • Um mercado de dados para facilitar a partilha de dados entre equipas de domínio.

O artigo Crie componentes e soluções de plataformas com modelos de IaC aborda as vantagens dos modelos de IaC para expor e implementar produtos de dados. Forneça serviços comuns aborda o motivo pelo qual é útil fornecer às equipas de domínio componentes de infraestrutura comuns que foram criados e são geridos pela equipa da plataforma de dados.

Crie componentes e soluções de plataformas com modelos de IaC

O objetivo das equipas de plataformas de dados é configurar plataformas de dados de autosserviço para obter mais valor dos dados. Para criar estas plataformas, criam e fornecem às equipas de domínio modelos de infraestrutura validados, seguros e de autosserviço. As equipas de domínio usam estes modelos para implementar os respetivos ambientes de desenvolvimento e consumo de dados. Os modelos de IaC ajudam as equipas da plataforma de dados a atingir esse objetivo e a permitir a escalabilidade. A utilização de modelos de IaC validados e fidedignos simplifica o processo de implementação de recursos para as equipas de domínio, permitindo que essas equipas reutilizem pipelines de CI/CD existentes. Esta abordagem permite que as equipas de domínio comecem rapidamente e se tornem produtivas na malha de dados.

Os modelos de IaC podem ser criados através de uma ferramenta de IaC. Embora existam várias ferramentas de IaC, incluindo o Cloud Config Connector, o Pulumi, o Chef e o Ansible, este documento fornece exemplos de ferramentas de IaC baseadas no Terraform. O Terraform é uma ferramenta de IaC de código aberto que permite à equipa da plataforma de dados criar de forma eficiente componentes e soluções de plataforma compostos paraGoogle Cloud recursos. Com o Terraform, a equipa da plataforma de dados escreve código que especifica o estado final escolhido e permite que a ferramenta descubra como alcançar esse estado. Esta abordagem declarativa permite que a equipa da plataforma de dados trate os recursos de infraestrutura como artefactos imutáveis para implementação em vários ambientes. Também ajuda a reduzir o risco de inconsistências entre os recursos implementados e o código declarado no controlo de origem (denominado desvio de configuração). A deriva da configuração causada por alterações ad hoc e manuais à infraestrutura dificulta a implementação segura e repetível de componentes de IaC em ambientes de produção.

Os modelos de IaC comuns para componentes de plataforma compostos incluem a utilização de módulos do Terraform para implementar recursos, como um conjunto de dados do BigQuery, um contentor do Cloud Storage ou uma base de dados do Cloud SQL. Os módulos do Terraform podem ser combinados em soluções completas para implementar Google Cloud projetos, incluindo recursos relevantes implementados através dos módulos compostos. Pode encontrar exemplos de módulos do Terraform nos projetos do Terraform para Google Cloud.

Por predefinição, cada módulo do Terraform deve cumprir as diretrizes de segurança e as políticas de conformidade que a sua organização usa. Estas salvaguardas e políticas também podem ser expressas como código e automatizadas através de ferramentas de validação de conformidade automatizadas, como a Google Cloud ferramenta de validação de políticas.

A sua organização deve testar continuamente os módulos do Terraform fornecidos pela plataforma, usando as mesmas restrições de conformidade automatizadas que usa para promover alterações na produção.

Para tornar os componentes e as soluções de IaC detetáveis e consumíveis para equipas de domínio com experiência mínima no Terraform, recomendamos que use serviços como o Service Catalog. Os utilizadores com requisitos de personalização significativos devem poder criar as suas próprias soluções de implementação a partir dos mesmos modelos do Terraform compostos usados pelas soluções existentes.

Quando usar o Terraform, recomendamos que siga as Google Cloud práticas recomendadas descritas em Práticas recomendadas para usar o Terraform.

Para ilustrar como o Terraform pode ser usado para criar componentes da plataforma, as secções seguintes abordam exemplos de como o Terraform pode ser usado para expor interfaces de consumo e consumir um produto de dados.

Exponha uma interface de consumo

Uma interface de consumo para um produto de dados é um conjunto de garantias sobre a qualidade dos dados e os parâmetros operacionais fornecidos pela equipa do domínio de dados para permitir que outras equipas descubram e usem os respetivos produtos de dados. Cada interface de consumo também inclui um modelo de apoio técnico do produto e documentação do produto. Um produto de dados pode ter diferentes tipos de interfaces de consumo, como APIs ou streams, conforme descrito no artigo Crie produtos de dados numa malha de dados. A interface de consumo mais comum pode ser um conjunto de dados autorizado, uma vista autorizada ou uma função autorizada do BigQuery. Esta interface expõe uma tabela virtual só de leitura, que é expressa como uma consulta na rede de dados. A interface não concede autorizações de leitor para aceder diretamente aos dados subjacentes.

A Google fornece um exemplo de módulo do Terraform para criar vistas autorizadas sem conceder autorizações às equipas para os conjuntos de dados autorizados subjacentes. O código seguinte deste módulo do Terraform concede estas autorizações da IAM na vista autorizada dataset_id:

module "add_authorization" {
  source = "terraform-google-modules/bigquery/google//modules/authorization"
  version = "~> 4.1"

  dataset_id = module.dataset.bigquery_dataset.dataset_id
  project_id = module.dataset.bigquery_dataset.project

  roles = [
    {
      role           = "roles/bigquery.dataEditor"
      group_by_email = "ops@mycompany.com"
    }
  ]

  authorized_views = [
    {
      project_id = "view_project"
      dataset_id = "view_dataset"
      table_id   = "view_id"
    }
  ]
  authorized_datasets = [
    {
      project_id = "auth_dataset_project"
      dataset_id = "auth_dataset"
    }
  ]
}

Se precisar de conceder aos utilizadores acesso a várias visualizações de propriedade, conceder acesso a cada visualização de propriedade autorizada pode ser demorado e mais difícil de manter. Em vez de criar várias visualizações autorizadas, pode usar um conjunto de dados autorizado para autorizar automaticamente todas as visualizações criadas no conjunto de dados autorizado.

Consuma um produto de dados

Para a maioria dos exemplos de utilização de estatísticas, os padrões de consumo são determinados pela aplicação em que os dados estão a ser usados. A principal utilização de um ambiente de consumo fornecido centralmente destina-se à exploração de dados antes de os dados serem utilizados na aplicação de consumo. Conforme abordado no artigo Descubra e consuma produtos numa malha de dados, o SQL é o método mais usado para consultar produtos de dados. Por este motivo, a plataforma de dados deve fornecer aos consumidores de dados uma aplicação SQL para a exploração dos dados.

Consoante o exemplo de utilização da análise, pode usar o Terraform para implementar o ambiente de consumo para os consumidores de dados. Por exemplo, a ciência dos dados é um exemplo de utilização comum para os consumidores de dados. Pode usar o Terraform para implementar blocos de notas geridos pelo utilizador do Vertex AI para serem usados como um ambiente de desenvolvimento de ciência de dados. A partir dos blocos de notas de ciência de dados, os consumidores de dados podem usar as respetivas credenciais para iniciar sessão na malha de dados e explorar os dados aos quais têm acesso e desenvolver modelos de ML com base nestes dados.

Para saber como usar o Terraform para implementar e ajudar a proteger um ambiente de bloco de notas no Google Cloud, consulte o artigo Crie e implemente modelos de IA generativa e aprendizagem automática numa empresa.

Oferecer serviços comuns

Além dos componentes e das soluções de IaC self-service, a equipa da plataforma de dados também pode assumir a responsabilidade pela criação e operação de serviços de plataforma partilhados comuns usados por várias equipas de domínio de dados. Alguns exemplos comuns de serviços de plataforma partilhados incluem software de terceiros alojado por si, como ferramentas de visualização de Business Intelligence ou um cluster Kafka. No Google Cloud, a equipa da plataforma de dados pode optar por gerir recursos como o catálogo universal do Dataplex e os destinos do Cloud Logging em nome das equipas do domínio de dados. A gestão de recursos para as equipas do domínio de dados permite que a equipa da plataforma de dados facilite a gestão e a auditoria de políticas centralizadas em toda a organização.

As secções seguintes mostram como usar o catálogo universal do Dataplex para a gestão e a administração centralizadas numa malha de dados no Google Cloud, e a implementação de funcionalidades de observabilidade de dados numa malha de dados.

Dataplex Universal Catalog para gestão de dados

O catálogo universal do Dataplex oferece uma plataforma de gestão de dados que ajuda a criar domínios de dados independentes numa malha de dados que abrange a organização. O catálogo universal do Dataplex permite-lhe manter controlos centrais para governar e monitorizar os dados em todos os domínios.

Com o catálogo universal do Dataplex, uma organização pode organizar logicamente os respetivos dados (origens de dados suportadas) e artefactos relacionados, como código, blocos de notas e registos, num lake do catálogo universal do Dataplex que representa um domínio de dados. No diagrama seguinte, um domínio de vendas usa o catálogo universal do Dataplex para organizar os respetivos recursos, incluindo métricas e registos de qualidade de dados, em zonas do catálogo universal do Dataplex.

Recursos organizados pelo catálogo universal do Dataplex.

Conforme mostrado no diagrama anterior, o catálogo universal do Dataplex pode ser usado para gerir dados de domínio nos seguintes recursos:

  • O catálogo universal do Dataplex permite que as equipas de domínio de dados geram de forma consistente os respetivos recursos de dados num grupo lógico denominado lago do catálogo universal do Dataplex. A equipa do domínio de dados pode organizar os respetivos recursos do catálogo universal do Dataplex no mesmo lake do catálogo universal do Dataplex sem mover fisicamente os dados nem armazená-los num único sistema de armazenamento. Os recursos do catálogo universal do Dataplex podem referir-se a contentores do Cloud Storage e a conjuntos de dados do BigQuery armazenados em vários Google Cloud projetos que não oGoogle Cloud projeto que contém o lake do catálogo universal do Dataplex. Os recursos do catálogo universal do Dataplex podem ser estruturados ou não estruturados, ou podem ser armazenados num lago de dados analíticos ou num armazém de dados. No diagrama, existem data lakes para o domínio de vendas, o domínio da cadeia de abastecimento e o domínio do produto.
  • As zonas do catálogo universal do Dataplex permitem que a equipa do domínio de dados organize ainda mais os recursos de dados em subgrupos mais pequenos no mesmo lake do catálogo universal do Dataplex e adicione estruturas que capturem aspetos importantes do subgrupo. Por exemplo, as zonas do catálogo universal do Dataplex podem ser usadas para agrupar recursos de dados associados num produto de dados. Agrupar recursos de dados numa única zona do catálogo universal do Dataplex permite que as equipas do domínio de dados geram políticas de acesso e políticas de governação de dados de forma consistente na zona como um único produto de dados. No diagrama, existem zonas de dados para vendas offline, vendas online, armazéns da cadeia de fornecimento e produtos.

Os lagos e as zonas do catálogo universal do Dataplex permitem que uma organização unifique os dados distribuídos e os organize com base no contexto empresarial. Esta disposição constitui a base para atividades como a gestão de metadados, a configuração de políticas de governação e a monitorização da qualidade dos dados. Essas atividades permitem que a organização faça a gestão dos respetivos dados distribuídos em grande escala, como numa malha de dados.

Observabilidade de dados

Cada domínio de dados deve implementar os seus próprios mecanismos de monitorização e alerta, idealmente através de uma abordagem padronizada. Cada domínio pode aplicar as práticas de monitorização descritas em Conceitos na monitorização de serviços, fazendo os ajustes necessários aos domínios de dados. A observabilidade é um tópico vasto e está fora do âmbito deste documento. Esta secção aborda apenas padrões úteis em implementações de malhas de dados.

Para produtos com vários consumidores de dados, o fornecimento de informações oportunas a cada consumidor sobre o estado do produto pode tornar-se um encargo operacional. As soluções básicas, como as distribuições de email geridas manualmente, são normalmente propensas a erros. Podem ser úteis para notificar os consumidores sobre interrupções planeadas, lançamentos de produtos futuros e descontinuações, mas não fornecem informações operacionais em tempo real.

Os serviços centrais podem desempenhar um papel importante na monitorização da saúde e da qualidade dos produtos na malha de dados. Embora não seja um pré-requisito para uma implementação bem-sucedida da malha de dados, a implementação de funcionalidades de observabilidade pode melhorar a satisfação dos produtores e consumidores de dados, e reduzir os custos operacionais e de apoio técnico gerais. O diagrama seguinte mostra uma arquitetura de observabilidade de malha de dados baseada no Cloud Monitoring.

Observabilidade da malha de dados.

As secções seguintes descrevem os componentes apresentados no diagrama, que são os seguintes:

Verificações de tempo de atividade

Os produtos de dados podem criar aplicações personalizadas simples que implementam verificações de tempo de atividade. Estas verificações podem servir como indicadores de alto nível do estado geral do produto. Por exemplo, se a equipa de produtos de dados descobrir uma diminuição súbita na qualidade dos dados do respetivo produto, pode marcar esse produto como não saudável. As verificações de tempo de atividade quase em tempo real são especialmente importantes para os consumidores de dados que derivaram produtos que dependem da disponibilidade constante dos dados no produto de dados a montante. Os produtores de dados devem criar as respetivas verificações de tempo de atividade para incluir a verificação das dependências a montante, fornecendo assim uma imagem precisa do estado do respetivo produto aos consumidores de dados.

Os consumidores de dados podem incluir verificações de tempo de atividade do produto no respetivo processamento. Por exemplo, uma tarefa de composição que gera um relatório com base nos dados fornecidos por um produto de dados pode, como primeiro passo, validar se o produto está no estado "em execução". Recomendamos que a sua aplicação de verificação do tempo de atividade devolva uma carga útil estruturada no corpo da mensagem da respetiva resposta HTTP. Esta carga útil estruturada deve indicar se existe um problema, a causa principal do problema num formato legível por humanos e, se possível, o tempo estimado para restaurar o serviço. Esta carga útil estruturada também pode fornecer informações mais detalhadas sobre o estado do produto. Por exemplo, pode conter as informações de saúde de cada uma das visualizações no conjunto de dados autorizado exposto como um produto.

Métricas personalizadas

Os produtos de dados podem ter várias métricas personalizadas para medir a respetiva utilidade. As equipas de produção de dados podem publicar estas métricas personalizadas nos respetivos projetos Google Cloud específicos do domínio designados. Para criar uma experiência de monitorização unificada em todos os produtos de dados, pode conceder-se acesso a um projeto de monitorização de malha de dados central a esses projetos específicos do domínio.

Cada tipo de interface de consumo de produtos de dados tem métricas diferentes para medir a respetiva utilidade. As métricas também podem ser específicas do domínio empresarial. Por exemplo, as métricas das tabelas do BigQuery expostas através de vistas ou através da API Storage Read podem ser as seguintes:

  • O número de linhas.
  • Atualidade dos dados (expressa como o número de segundos antes da hora de medição).
  • O índice de qualidade de dados.
  • Os dados disponíveis. Esta métrica pode indicar que os dados estão disponíveis para consulta. Em alternativa, pode usar as verificações de tempo de atividade mencionadas anteriormente neste documento.

Estas métricas podem ser vistas como indicadores do nível de serviço (INS) para um produto específico.

Para streams de dados (implementadas como tópicos do Pub/Sub), esta lista pode ser as métricas padrão do Pub/Sub, que estão disponíveis através de tópicos.

Apoio técnico operacional da equipa da plataforma de dados central

A equipa da plataforma de dados central pode expor painéis de controlo personalizados para apresentar diferentes níveis de detalhes aos consumidores de dados. Um painel de controlo de estado simples que liste os produtos na malha de dados e o estado de tempo de atividade desses produtos pode ajudar a responder a vários pedidos de utilizadores finais.

A equipa central também pode funcionar como um hub de distribuição de notificações para notificar os consumidores de dados acerca de vários eventos nos produtos de dados que usam. Normalmente, este hub é criado através da criação de políticas de alerta. A centralização desta função pode reduzir o trabalho que tem de ser feito por cada equipa produtora de dados. A criação destas políticas não requer conhecimentos dos domínios de dados e deve ajudar a evitar gargalos no consumo de dados.

Um estado final ideal para a monitorização da malha de dados é que o modelo de etiqueta do produto de dados exponha os ISNs e os objetivos ao nível do serviço (ONS) que o produto suporta quando fica disponível. A equipa central pode, em seguida, implementar automaticamente os alertas correspondentes através da monitorização de serviços com a API Monitoring.

Tabelas de dados de produtos

Como parte do contrato de governação central, as quatro funções numa malha de dados podem definir os critérios para criar tabelas de indicadores para produtos de dados. Estas tabelas de dados podem tornar-se uma medição objetiva do desempenho dos produtos de dados.

Muitas das variáveis usadas para calcular as tabelas de dados são a percentagem de tempo em que os produtos de dados estão a cumprir o respetivo SLO. Os critérios úteis podem ser a percentagem de tempo de atividade, as classificações médias de qualidade de dados e a percentagem de produtos com atualidade dos dados que não fica abaixo de um limite. Para calcular estas métricas automaticamente através da linguagem de consulta Prometheus (PromQL), as métricas personalizadas e os resultados das verificações de tempo de atividade do projeto de monitorização central devem ser suficientes.

O que se segue?