Implementar arquitetura medallion do Lakehouse no Microsoft Fabric

Este artigo apresenta a arquitetura medallion do lake e descreve como você pode implementar um lakehouse no Microsoft Fabric. Ele é direcionado a vários públicos-alvo:

• Engenheiros de dados: equipe técnica que projeta, cria e mantém infraestruturas e sistemas que permitem que sua organização colete, armazene, processe e analise grandes volumes de dados.
• Equipe do Centro de Excelência, TI e BI: as equipes responsáveis por supervisionar a análise em toda a organização.
• Administradores do Fabric: os administradores responsáveis por supervisionar o Fabric na organização.

A arquitetura medallion do lakehouse, comumente conhecida como arquitetura medallion, é um padrão de design usado pelas organizações para organizar logicamente dados em um lakehouse. É a abordagem de design recomendada para o Fabric.

A arquitetura medallion é composta por três camadas (ou zonas) distintas. Cada camada indica a qualidade dos dados armazenados no lakehouse, com níveis mais altos representando maior qualidade. Essa abordagem de várias camadas ajuda você a criar uma única fonte de verdade para produtos de dados corporativos.

É importante ressaltar que a arquitetura medallion garante o conjunto de propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) à medida que os dados avançam pelas camadas. Começando com dados brutos, uma série de validações e transformações prepara dados otimizados para análise eficiente. Há três etapas do medallion: bronze (bruto), prata (validado) e ouro (enriquecido).

Para obter mais informações, consulte O que é arquitetura medallion do Lakehouse?.

OneLake e lakehouse no Fabric

A base de um data warehouse moderno é um data lake. Microsoft OneLake, que é um data lake único, unificado e lógico para toda a sua organização. Ele vem provisionado automaticamente com todos os locatários do Fabric e foi projetado para ser o único local para todos os seus dados de análise.

Você pode usar o OneLake para:

• Remover silos e reduzir o esforço de gerenciamento. Todos os dados organizacionais são armazenados, gerenciados e protegidos em um recurso do data lake. Como o OneLake é provisionado com seu locatário do Fabric, não há mais recursos para provisionar ou gerenciar.
• Reduzir a movimentação e a duplicação de dados. O objetivo do OneLake é armazenar apenas uma cópia de dados. Menos cópias de dados resultam em menos processos de movimentação de dados e isso gera ganhos de eficiência e redução na complexidade. Se necessário, você pode criar um atalho para fazer referência aos dados armazenados em outros locais, em vez de copiá-los para o OneLake.
• Usar com vários mecanismos analíticos. Os dados no OneLake são armazenados em um formato aberto. Dessa forma, os dados podem ser consultados por vários mecanismos analíticos, incluindo o Analysis Services (usado pelo Power BI), o T-SQL e o Spark. Outros aplicativos não Fabric também podem usar APIs e SDKs para acessar o OneLake.

Para obter mais informações, consulte OneLake, o OneDrive para dados.

Para armazenar dados no OneLake, crie um lakehouse no Fabric. Um lakehouse é uma plataforma de arquitetura de dados para armazenar, gerenciar e analisar dados estruturados e não estruturados em um único local. Ele pode facilmente escalar para grandes volumes de dados de todos os tipos e tamanhos de arquivos e, como ele é armazenado em um único local, ele é facilmente compartilhado e reutilizado em toda a organização.

Cada lakehouse tem um ponto de extremidade de análise de SQL interno que desbloqueia recursos de data warehouse sem a necessidade de mover dados. Isso significa que você pode consultar seus dados no lakehouse usando consultas SQL e sem nenhuma configuração especial.

Para obter mais informações, confira O que é um lakehouse no Microsoft Fabric?.

Tabelas e arquivos

Quando você cria um lakehouse no Fabric, dois locais de armazenamento físico são provisionados automaticamente para tabelas e arquivos.

• Tabelas é uma área gerenciada para hospedar tabelas de todos os formatos no Spark (CSV, Parquet ou Delta). Todas as tabelas, criadas automaticamente ou explicitamente, são reconhecidas como tabelas no lakehouse. Além disso, todas as tabelas Delta, que são arquivos de dados Parquet com um log de transações baseado em arquivo, também são reconhecidas como tabelas.
• Arquivos é uma área não gerenciada para armazenar dados em qualquer formato de arquivo. Todos os arquivos Delta armazenados nessa área não são reconhecidos automaticamente como tabelas. Se você quiser criar uma tabela em uma pasta Delta Lake na área não gerenciada, precisará criar explicitamente um atalho ou uma tabela externa com um local que aponte para a pasta não gerenciada que contém os arquivos Delta Lake no Spark.

A principal distinção entre a área gerenciada (tabelas) e a área não gerenciada (arquivos) é o processo automático de descoberta e registro de tabela. Esse processo é executado em qualquer pasta criada apenas na área gerenciada, mas não na área não gerenciada.

No Microsoft Fabric, o Lakehouse Explorer fornece uma representação gráfica unificada de todo o Lakehouse para que os usuários naveguem, acessem e atualizem seus dados.

Para obter mais informações sobre a descoberta automática de tabela, consulte Descoberta automática de tabela e registro.

Armazenamento do Delta Lake

O Delta Lake é uma camada de armazenamento otimizada que fornece a base para armazenar dados e tabelas. Ele dá suporte a transações ACID para cargas de trabalho de Big Data e, por esse motivo, é o formato de armazenamento padrão em um lakehouse do Fabric.

É importante ressaltar que o Delta Lake oferece confiabilidade, segurança e desempenho no lakehouse para operações de streaming e em lotes. Internamente, armazena dados no formato de arquivo Parquet, no entanto, também mantém logs de transações e estatísticas que fornecem recursos e melhoria de desempenho em relação ao formato Parquet padrão.

O formato Delta Lake em formatos de arquivo genéricos oferece os principais benefícios a seguir.

• Suporte para propriedades ACID e, especialmente, durabilidade para evitar a corrupção de dados.
• Consultas de leitura mais rápidas.
• Aumento da atualização de dados.
• Suporte para cargas de trabalho em lote e streaming.
• Suporte para reversão de dados usando viagem no tempo do Delta Lake.
• Conformidade e auditoria regulatória aprimoradas usando o histórico de tabelas do Delta Lake.

O Fabric padroniza o formato de arquivo de armazenamento com o Delta Lake e, por padrão, cada mecanismo de carga de trabalho no Fabric cria tabelas Delta quando você grava dados em uma nova tabela. Para obter mais informações, consulte Tabelas do Lakehouse e Delta Lake.

Arquitetura medallion no Fabric

O objetivo da arquitetura medallion é melhorar de forma incremental e progressiva a estrutura e a qualidade dos dados à medida que avança em cada estágio.

A arquitetura medallion é composta por três camadas (ou zonas) distintas.

• Bronze: também conhecida como zona bruta, essa primeira camada armazena dados de origem em seu formato original. Os dados nessa camada normalmente são somente de acréscimo e imutáveis.
• Prata: também conhecida como zona enriquecida, essa camada armazena dados provenientes da camada bronze. Os dados brutos foram limpos e padronizados e agora são estruturados como tabelas (linhas e colunas). Eles também podem ser integrados a outros dados para fornecer uma exibição empresarial de todas as entidades de negócios, como cliente, produto e outros.
• Ouro: também conhecida como zona coletada, essa camada final armazena dados provenientes da camada prata. Os dados são refinados para atender a requisitos específicos de análise e negócios downstream. As tabelas normalmente estão em conformidade com o design de esquema em estrela, que dá suporte ao desenvolvimento de modelos de dados otimizados para desempenho e usabilidade.

Importante

Como um Fabric Lakehouse representa uma única zona, você cria uma lakehouse para cada uma das três zonas.

Em uma implementação típica de arquitetura medallion no Fabric, a zona bronze armazena os dados no mesmo formato que a fonte de dados. Quando a fonte de dados é um banco de dados relacional, as tabelas Delta são uma boa opção. As zonas prata e ouro contêm tabelas Delta.

Dica

Para saber como criar um lakehouse, confira o tutorial Cenário de ponta a ponta do Lakehouse.

Diretrizes do Fabric Lakehouse

Esta seção fornece orientações relacionadas à implementação do Fabric Lakehouse usando a arquitetura medallion.

Modelo de implantação

Para implementar a arquitetura medallion no Fabric, você pode usar lakehouses (um para cada zona), um data warehouse ou uma combinação de ambos. Sua decisão deve ser baseada em sua preferência e na experiência de sua equipe. Tenha em mente que o Fabric oferece flexibilidade: você pode usar diferentes mecanismos analíticos que funcionam em uma cópia de seus dados no OneLake.

Aqui estão dois padrões a serem considerados.

• Padrão 1: criar cada zona como um lakehouse. Nesse caso, os usuários empresariais acessam dados usando o ponto de extremidade de análise do SQL.
• Padrão 2: criar as zonas bronze e prata como lakehouses e a zona de ouro como data warehouse. Nesse caso, os usuários empresariais acessam dados usando o ponto de extremidade do data warehouse.

Embora você possa criar todas as lakehouses em um único workspace do Fabric, recomendamos que você crie cada lakehouse em seu workspace do Fabric separado. Essa abordagem fornece mais controle e melhor governança no nível da zona.

Para a zona bronze, recomendamos que você armazene os dados em seu formato original ou use Parquet ou Delta Lake. Sempre que possível, mantenha os dados em seu formato original. Se os dados de origem forem do OneLake, o Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 ou Google, crie um atalho na zona bronze em vez de copiar os dados.

Para as zonas prata e ouro, recomendamos que você use tabelas Delta devido às funcionalidades extras e aos aprimoramentos de desempenho que elas fornecem. O Fabric padroniza no formato Delta Lake e, por padrão, cada mecanismo no Fabric grava dados nesse formato. Além disso, esses mecanismos usam a otimização de tempo de gravação do V-Order para o formato de arquivo Parquet. Essa otimização permite leituras extremamente rápidas por mecanismos de computação do Fabric, como Power BI, SQL, Spark e outros. Para obter mais informações, consulte Otimização de tabela do Delta Lake e V-Order.

Por fim, hoje muitas organizações enfrentam um enorme crescimento nos volumes de dados, juntamente com uma necessidade crescente de organizar e gerenciar esses dados de forma lógica, facilitando o uso e a governança mais direcionados e eficientes. Isso pode fazer com que você estabeleça e gerencie uma organização de dados descentralizada ou federada com governança.

Para atender a esse objetivo, considere implementar uma arquitetura de malha de dados. A malha de dados é um padrão de arquitetura que se concentra na criação de domínios de dados que oferecem dados como um produto.

Você pode criar uma arquitetura de malha de dados para seu patrimônio de dados no Fabric criando domínios de dados. Você pode criar domínios mapeados para seus domínios de negócios, por exemplo, marketing, vendas, inventário, recursos humanos e outros. Em seguida, você pode implementar a arquitetura medallion configurando zonas de dados em cada um de seus domínios.

Para obter mais informações sobre domínios, consulte Domínios.

Compreender o armazenamento de dados da tabela Delta

Esta seção descreve outros tópicos de orientação relacionados à implementação de uma arquitetura medallion do lakehouse no Fabric.

Tamanho do arquivo

Geralmente, uma plataforma de Big Data tem um desempenho melhor quando tem um pequeno número de arquivos grandes em vez de um grande número de arquivos pequenos. Isso ocorre porque a degradação do desempenho ocorre quando o mecanismo de computação deve gerenciar muitos metadados e operações de arquivo. Para melhorar o desempenho da consulta, recomendamos que você vise arquivos de dados com aproximadamente 1 GB de tamanho.

O Delta Lake tem um recurso chamado otimização preditiva. A otimização preditiva remove a necessidade de gerenciar manualmente as operações de manutenção de Tabelas Delta. Quando esse recurso está habilitado, o Delta Lake identifica automaticamente tabelas que se beneficiariam de operações de manutenção e otimiza o armazenamento. Ele pode unir de forma transparente muitos arquivos menores em arquivos grandes e sem qualquer impacto sobre outros leitores e gravadores dos dados. Embora esse recurso faça parte de sua excelência operacional e do trabalho de preparação de dados, o Fabric também tem a capacidade de otimizar esses arquivos de dados durante a gravação de dados. Para obter mais informações, consulte Otimização preditiva para o Delta Lake.

Retenção histórica

Por padrão, o Delta Lake mantém um histórico de todas as alterações feitas. Isso significa que o tamanho dos metadados históricos cresce ao longo do tempo. Com base em seus requisitos de negócios, você deve procurar manter dados históricos apenas por um determinado período de tempo para reduzir os custos de armazenamento. Considere a retenção de dados históricos apenas para o último mês ou outro período apropriado.

Você pode remover dados históricos mais antigos de uma tabela Delta usando o comando VACUUM. No entanto, lembre-se de que, por padrão, você não pode excluir dados históricos nos últimos sete dias, a fim de manter a consistência nos dados. O número padrão de dias é controlado pela propriedade delta.deletedFileRetentionDuration = "interval <interval>" da tabela. Ela determina o período de tempo em que um arquivo deve ser excluído antes de ser considerado para uma operação de vácuo.

Partições de tabela

Ao armazenar dados em cada zona, recomendamos que você use uma estrutura de pasta particionada sempre que aplicável. Essa técnica ajuda a melhorar a capacidade de gerenciamento de dados e o desempenho da consulta. Em geral, os dados particionados em uma estrutura de pasta resultam em uma busca mais rápida por entradas de dados específicas graças à remoção/eliminação de partição.

Normalmente, você acrescenta dados à tabela de destino à medida que novos dados chegam. No entanto, em alguns casos, você pode mesclar dados porque precisa atualizar os dados existentes ao mesmo tempo. Nesse caso, você pode executar uma operação de upsert usando o comando MERGE. Quando a tabela de destino for particionada, use um filtro de partição para acelerar a operação. Dessa forma, o mecanismo pode eliminar partições que não exigem atualização.

Acesso de dados

Por fim, você deve planejar e controlar quem precisa de acesso a dados específicos no lakehouse. Você também deve entender os vários padrões de transação que eles usarão ao acessar esses dados. Em seguida, você pode definir o esquema de particionamento de tabela correto e a ordenação de dados com índices de ordem Z do Delta Lake.

Conteúdo relacionado

Para obter mais informações sobre como implementar uma lakehouse do Fabric, consulte os recursos a seguir.

• Tutorial: Cenário de ponta a ponta do lakehouse
• Tabelas do Lakehouse e Delta Lake
• Guia de decisão do Microsoft Fabric: escolher um armazenamento de dados
• Otimização de tabela do Delta Lake e V-Order
• A necessidade de otimizar a gravação no Apache Spark
• Alguma dúvida? Tente perguntar à comunidade do Fabric.
• Sugestões? Dê ideias para melhorar o Fabric.