Pular para o conteúdo principal
Última atualização em

Fase 6: Projeto arquitetônico Delta Lake

Nesta fase, você projeta a arquitetura de armazenamento Delta Lake e os padrões de organização de dados para sua lakehouse.

Design de arquitetura de medalhão​

A arquitetura Medallion organiza os dados em camadas para melhorar a qualidade dos dados à medida que avançam pelo pipeline. Esse padrão é fundamental para construir uma lakehouse bem estruturada.

Em sua forma mais simples, a arquitetura do medalhão consiste em três camadas: camada de bronze (dados brutos), camada de prata (dados refinados) e camada de ouro (dados prontos para uso comercial).

Camada de bronze (dados brutos)​

Ingerir os dados de origem na primeira camada do lakehouse e persistir os dados lá. Quando todos os dados subsequentes forem criados a partir da camada de bronze, você poderá reconstruir as camadas seguintes a partir desta camada, se necessário.

Características da camada de bronze

  • Fonte da verdade : dados brutos exatamente como chegam dos sistemas de origem.
  • Transformações mínimas : Dados armazenados em seu formato original (ou convertidos para Delta para fins de auditoria).
  • Imutável : os dados são apenas para adição, nunca atualizados ou excluídos.
  • Schema-on-read : Manipulação flexível de esquemas para diversos sistemas de origem.
  • Rastreamento de auditoria : Para algumas aplicações (como GDPR ou dados regulamentados), pode ser apropriado converter esta camada para o formato Delta.

Melhores práticas para camada de bronze

  • Preserve todos os campos de dados de origem para garantir total auditabilidade.
  • Use os volumes Unity Catalog para armazenar arquivos brutos.
  • Implemente a ingestão incremental para evitar o reprocessamento completo.
  • Partição por data de ingestão para gestão eficiente de dados.
  • Documento fonte de dados e programação de ingestão.

Camada de prata (dados refinados)​

A finalidade da segunda camada é armazenar dados limpos, refinados, filtrados e agregados.

Características da camada de prata

  • Qualidade dos dados : Remove duplicados, lida com valores ausentes, impõe o esquema.
  • Enriquecimento : combinar dados de múltiplas fontes para criar um conjunto de dados integrado.
  • Padronização : Aplica tipos de dados, formatos e convenções de nomenclatura consistentes.
  • Regras de negócio : Implementa regras de validação e lógica de negócio.
  • Serve para análises : Base para relatórios, painéis de controle e machine learning.

Melhores práticas para camada de prata

  • Implementar verificações e monitoramento da qualidade dos dados.
  • Use Unity Catalog para gerenciar os dados da camada prateada.
  • Particione por dimensões de negócio (por exemplo, data, região, produto).
  • Lógica de transformação de documentos e regras de negócio.
  • Estabeleça SLAs para garantir a atualização dos dados.

Camada de ouro (dados prontos para uso comercial)​

A terceira camada é criada em torno das necessidades do negócio ou do projeto. Isso proporciona uma view diferente do produto de dados para outras unidades de negócios ou projetos, preparando os dados de acordo com as necessidades de segurança (por exemplo, dados anonimizados) ou otimizando o desempenho (por exemplo, visão pré-agregada).

Características da camada de ouro

  • Específico para cada negócio : Adaptado a casos de uso e consumidores específicos.
  • Otimizado para desempenho : Pré-agregado e desnormalizado para consultas rápidas.
  • Controle de acesso : Implementa segurança em nível de linha e mascaramento de coluna.
  • Pronto para o consumidor : Estruturado para ferramentas BI , aplicativos e modelos de machine learning.
  • Produto de dados : Publicado como conjunto de dados reutilizável em toda a organização.

Melhores práticas para camada de ouro

  • Crie tabelas de ouro separadas para diferentes unidades de negócio ou casos de uso.
  • Utilize a visualização dinâmica para segurança em nível de linha e em nível de coluna.
  • Implemente a otimização preditiva para tabelas consultadas com frequência.
  • Documente linhagem de dados do bronze ao ouro.
  • Publique os dados do produto através Unity Catalog com propriedade claramente definida.

Considerações sobre a zona de aterragem​

Em organizações maiores, os pipelines geralmente possuem uma área de destino adicional na cloud. A área de aterrissagem recebe arquivos brutos de sistemas externos antes de serem incorporados à camada de bronze.

padrões de zona de pouso

  • Armazenamento de objetos na nuvem : buckets S3, ADLS Gen2 ou GCS para o envio de arquivos.
  • Volumes do Unity Catalog : Acesso seguro a arquivos no estilo POSIX com governança do Unity Catalog.
  • Acesso de terceiros : Sistemas externos podem escrever diretamente nas zonas de aterrissagem.
  • Gatilhos de notificação : Use notificações de eventos para acionar o pipeline de ingestão.

Para obter orientações completas sobre a arquitetura do medalhão, consulte O que é a arquitetura do medalhão lakehouse ?.

Estratégia de ingestão de dados de projeto​

A ingestão de dados na camada de bronze é o primeiro passo na arquitetura do medalhão. Elabore sua estratégia de ingestão com base na fonte de dados, nos volumes e nos requisitos de latência.

Métodos de ingestão​

LakeFlow Connect

LakeFlow Connect é um serviço de gerenciamento de ingestão de dados fornecido pela Databricks que permite sincronizar regularmente dados de fontes externas com Databricks sem a necessidade de escrever uma única linha de código.

Ferramentas de ingestão de parceiros

Ferramentas como Fivetran também podem importar dados de fontes não suportadas pelo LakeFlow Connect. Quaisquer dados brutos e não estruturados desse tipo devem ser armazenados em volumes Unity Catalog (em vez de locais externos).

Pipeline de ingestão personalizado

Para requisitos de transformações complexas ou fontes não suportadas, crie um pipeline de ingestão personalizado usando o pipeline declarativo LakeFlow Spark ou um Notebook.

Padrões de ingestão​

ingestão de lotes

  • carregamentos de dados regulares programáveis (por exemplo, por hora, diariamente, semanalmente).
  • Melhor para grandes volumes de dados históricos.
  • Menor custo comparado à transmissão.
  • Latência aceitável para cargas de trabalho analíticas.

ingestão de licença

  • Ingestão contínua de dados com baixa latência.
  • Utilize o pipeline declarativo LakeFlow Spark com Auto Loader para ingestão de arquivos de transmissão.
  • Melhor para casos de uso analítico e operacional de tempo real.
  • Custos compute mais elevados, mas dados atualizados.

Alterar captura de dados (CDC)

  • Capturar e aplicar alterações incrementais dos sistemas de origem.
  • Eficiente para tabelas grandes com atualizações frequentes.
  • Preserva a linhagem de dados e o histórico de auditoria.
  • Compatível com o pipeline declarativo LakeFlow Connect e LakeFlow Spark .

Práticas recomendadas para ingestão de dados

  • Utilize os volumes do Unity Catalog para armazenar os dados brutos antes da ingestão em formato bronze.
  • Implemente a ingestão idempotente para lidar com novas tentativas de forma segura.
  • Utilize Auto Loader para ingestão eficiente de arquivos do armazenamento cloud .
  • Configure as políticas de retenção para os dados da zona de aterrissagem.
  • Monitore o pipeline de ingestão em busca de falhas e problemas de qualidade de dados.

Estratégia de gerenciamento de mesa de design​

Tabelas e volumes podem ser criados como gerenciados ou externos. Compreender as vantagens e desvantagens ajuda você a elaborar a estratégia de tabela correta.

vs tabelas externas​

tabelas e volumes

Unity Catalog gerencia o acesso a tabelas e volumes externos do Databricks, mas não controla os arquivos subjacentes nem gerencia totalmente o local de armazenamento desses arquivos. As tabelas e volumes, por outro lado, são totalmente gerenciados pelo Unity Catalog e armazenados em um local de armazenamento associado ao esquema que os contém.

Databricks recomenda o gerenciamento de volumes e tabelas para a maioria das cargas de trabalho, pois simplificam a configuração, a otimização e a governança. Novos recursos, como otimização preditiva e gerenciamento de DR, estão disponíveis apenas para tabelas de gerenciamento.

Tabelas e volumes externos

A maior diferença com as tabelas externas é que estas não oferecem a estrutura de pastas simples de schema_name/table_name, usando em vez disso pastas internas no estilo GUID. Essas pastas só devem ser acessadas através do Unity Catalog.

Quando usar tabelas externas

  • Os dados devem permanecer em locais específicos de armazenamento cloud por motivos regulatórios ou compliance .
  • Sistemas externos exigem acesso direto aos arquivos de dados.
  • Compartilhar dados com sistemas que não podem usar Delta Sharing.
  • Dados existentes que não podem ser migrados para o armazenamento gerenciado.

Melhores práticas para gestão de mesas

  • Use tabelas de gerenciamento para todos os novos dados lakehouse (bronze, prata, ouro).
  • Utilize volumes gerenciais para zona de aterrissagem e dados brutos não estruturados.
  • Reserve tabelas externas apenas para dados que precisam permanecer em caminhos específicos.
  • Políticas de propriedade e ciclo de vida de documentos para todas as tabelas.
  • Ative a otimização preditiva para tabelas consultadas com frequência.

Design de medalhão em forma de cubo e raios​

O padrão de design hub-and-spoke pode ser combinado com a arquitetura medallion para implantações corporativas. Esse padrão centraliza os dados compartilhados de forma ativa, ao mesmo tempo que permite o processamento de dados específicos de cada domínio.

Características do medalhão do tipo cubo e raios

  • Hub de dados : ingere, organiza e gerencia dados ativos de toda a organização (por exemplo, dados SAP ou dados ativos gerais, como clima ou finanças). Esses podem ser considerados produtos de dados vinculados à fonte.
  • Domínios de dados : Cada domínio lê alguns dos dados selecionados pelo hub e também ingere e seleciona seus próprios dados brutos específicos do domínio. Os domínios geram, então, dados específicos do domínio.
  • Modelos de publicação
    • Publicação centralizada : os domínios publicam os dados do produto de volta ao hub para consumo em toda a organização.
    • Publicação distribuída : Os domínios publicam produtos de dados em seus próprios catálogos para uso específico do domínio.

Exemplo de medalhão com design de cubo e raios

Data Hub (Central)
├── Bronze: Organization-wide raw data (SAP, financials, weather)
├── Silver: Curated shared datasets
└── Gold: Enterprise-wide data products

Sales Domain
├── Bronze: Sales-specific raw data + shared hub data
├── Silver: Sales analytics datasets
└── Gold: Sales data products (published to hub or domain)

Engineering Domain
├── Bronze: Engineering telemetry + shared hub data
├── Silver: Engineering metrics
└── Gold: Engineering dashboards (published within domain)

Melhores práticas para medalhões em modelo hub-and-spoke

  • Utilize o hub para dados compartilhados em toda a organização, que são consumidos por vários domínios.
  • Permitir que os domínios ingiram e organizem seus próprios dados específicos do domínio.
  • Estabelecer políticas claras de publicação de produtos de dados (centralizadas versus distribuídas).
  • Utilize catálogos Unity Catalog para separar dados de hubs e domínios.
  • Utilize o recurso Delta Sharing Databrickspara compartilhar produtos de dados entre o hub e os domínios.

Desenvolver uma estratégia de governança de dados​

A governança de dados garante a qualidade, a descoberta e compliance dos dados em todo o lakehouse. Elabore estratégias de governança adequadas à maturidade e às necessidades da sua organização.

Estratégia de qualidade de dados​

Independentemente da variante da arquitetura medallion, a qualidade dos dados deve melhorar à medida que os dados progridem pelas camadas. Consequentemente, a confiança nos dados aumentará posteriormente do ponto de vista empresarial.

Ferramentas de qualidade de dados

  • Restrições : Garantir que a qualidade e a integridade dos dados adicionados a uma tabela sejam verificadas automaticamente.
  • Chave primária e chave estrangeira : codificam as relações entre os campos nas tabelas (informativas, não obrigatórias).
  • Expectativas : Impedir que problemas de qualidade de dados se propaguem para os fluxos subsequentes (atualmente com o pipeline declarativo LakeFlow Spark , em breve com todas as tabelas Unity Catalog ).
  • monitoramento lakehouse : Monitore as propriedades estatísticas e a qualidade dos dados em todas as tabelas da sua account.

Melhores práticas de qualidade de dados

  • Implementar verificações de qualidade de dados na ingestão do pacote Bronze (por exemplo, validação de esquema, verificação de valores nulos).
  • Impor regras de qualidade mais rigorosas à medida que os dados migram para os formatos prata e ouro.
  • Monitore as métricas e tendências de qualidade dos dados ao longo do tempo.
  • Defina SLAs de qualidade de dados para conjuntos de dados críticos.
  • Automatize alertas para violações da qualidade dos dados.

Evite silos de dados​

A movimentação, cópia e duplicação de dados consomem tempo e podem diminuir a qualidade dos dados no lakehouse, especialmente quando levam à formação de silos de dados. Para deixar clara a distinção entre cópia de dados e silo de dados, uma cópia descartável ou independente dos dados não é prejudicial por si só. Por vezes, é necessário impulsionar a agilidade, a experimentação e a inovação. Quando essas cópias entram em operação com produtos de dados comerciais subsequentes que dependem delas, elas se transformam em silos de dados. Esses silos logo ficam dessincronizados, o que acaba levando a um data lake menos confiável.

Melhores práticas para evitar silos de dados

  • Use a visualização Unity Catalog e Delta Sharing em vez de copiar os dados.
  • Estabeleça uma única fonte de verdade para cada dataset.
  • Desencoraje cópias e duplicatas de dados em nível departamental.
  • Use a linhagem Unity Catalog para rastrear dependências de dados.
  • Elimine regularmente os conjuntos de dados redundantes.

catálogo de dados e descoberta​

Unity Catalog fornece descoberta de dados e linhagem para usabilidade e governança de dados.

Descobrimento de dados

Usuários de todas as áreas de negócios, especialmente em um modelo de autoatendimento, precisam ser capazes de descobrir dados relevantes. Portanto, uma lakehouse precisa de um catálogo de dados que abranja todos os dados relevantes para o negócio. Os principais objetivos de um catálogo de dados são:

  • Permitir que os usuários pesquisem e descubram conjuntos de dados.
  • Forneça metadados, descrições e documentação para o conjunto de dados.
  • Mostrar linhagem de dados da origem ao consumo.
  • Exibir métricas de qualidade de dados e informações de atualização.

Linhagem de dados

Acompanhe a linhagem de dados com precisão para que os usuários possam explicar como os dados chegaram à sua forma atual. O Unity Catalog captura automaticamente a linhagem para:

  • Dependências entre tabelas.
  • Execuções Notebook e jobs que leem ou gravam dados.
  • Sistemas de origem a montante.
  • Consumidores a jusante e produto de dados.

Melhores práticas para catálogo de dados

  • Adicione descrições e tags a todos os catálogos, esquemas e tabelas.
  • Proprietários de dados de documentos e especialistas no assunto.
  • Use a pesquisa Unity Catalog para ativar a descoberta de dados.
  • Revise e atualize os metadados regularmente.
  • Use a análise de linhagem para entender as dependências de dados antes de fazer alterações.

Recomendações de arquitetura paraDelta Lake​

Recomendado

  • Utilize a arquitetura medalhão para estruturar o data lake (bronze, prata, ouro).
  • Use as tabelas Unity Catalog para gerenciar todos os dados lakehouse (do bronze ao ouro).
  • Utilize volumes do Unity Catalog para zonas de aterrissagem e dados brutos não estruturados.
  • Implemente verificações de qualidade de dados em cada camada (bronze, prata, ouro).
  • Use Unity Catalog para permitir descoberta de dados e acompanhamento de linhagem.
  • Ative a otimização preditiva para tabelas consultadas com frequência.
  • Estabeleça políticas claras de publicação de produtos de dados para arquiteturas em estrela (hub-and-spoke).

Evitar

  • Não crie silos de dados duplicando dados operacionais em diferentes domínios.
  • Não utilize tabelas externas a menos que os dados precisem permanecer em locais de armazenamento específicos.
  • Não ignore a camada de bronze (sempre preserve os dados brutos como fonte da verdade).
  • Não ignore as verificações de qualidade de dados para cumprir os prazos de entrega.
  • Não permita a proliferação descontrolada de dados sem a governança Unity Catalog .

Resultados da Fase 6​

Após concluir a Fase 6, você deverá ter:

  • Arquitetura de medalhão projetada (camadas de bronze, prata e ouro com propósitos claros).
  • estratégia de absorção de dados definida (lotes, transmissão ou CDC com base em requisitos).
  • Estratégia de gerenciamento de tabelas projetada (gerenciar vs tabelas externas).
  • Arquitetura em formato de medalhão (hub-and-spoke) avaliada (para organizações com múltiplos domínios).
  • Estratégia de qualidade de dados definida com verificações apropriadas em cada camada.
  • Políticas de governança de dados estabelecidas (por exemplo, catálogo, linhagem, descoberta).
  • Arquitetura da zona de aterragem projetada (se necessário para sistemas externos).
  • Modelo de publicação de produtos de dados definido (centralizado, distribuído ou híbrido).

Próxima fase : Fase 7: Planejar a abordagem de Infraestrutura como Código

Orientações de implementação : Para obter instruções passo a passo sobre como implementar seu projeto Delta Lake, consulte O que é Delta Lake no Databricks?.