Zonas e contêineres do data lake
É importante planejar sua estrutura de dados antes de colocá-la em um data lake. Quando você tem um plano, pode usar a segurança, o particionamento e o processamento de forma eficaz.
Para obter uma visão geral dos data lakes, consulte Visão geral do Azure Data Lake Storage para análise em escala de nuvem.
Visão geral
Suas três contas de data lake devem se alinhar às camadas típicas de data lake.
| Número do lago | Camadas | Número do contêiner | Nome do contêiner |
|---|---|---|---|
| 1 | Raw | 1 | Destino |
| 1 | Raw | 2 | Compatibilidade |
| 2 | Enriquecido | 1 | Padronizado |
| 2 | Selecionado | 2 | Produtos de dados |
| 3 | Desenvolvimento | 1 | Área restrita de análise |
| 3 | Desenvolvimento | # | Número de armazenamento principal do Synapse |
A tabela anterior mostra o número padrão de contêineres que recomendamos por zona de destino de dados. A exceção a essa recomendação é quando diferentes políticas de exclusão temporária são necessárias para os dados em um contêiner. Esses requisitos determinam a necessidade de mais contêineres.
Observação
Três data lakes são ilustrados em cada zona de destino de dados. O data lake fica em três contas de data lake, vários contêineres e pastas, mas representa um data lake lógico para sua zona de destino de dados.
Dependendo de seus requisitos, você pode consolidar camadas brutas, enriquecidas e selecionadas em uma conta de armazenamento. Mantenha outra conta de armazenamento chamada "desenvolvimento" para que os consumidores de dados tragam outros produtos de dados úteis.
Para obter mais informações sobre como separar contas de data lake, consulte Contas de armazenamento em um data lake lógico.
Habilite o Armazenamento do Azure com o recurso de namespace hierárquico, que permite gerenciar arquivos com eficiência. O recurso de namespace hierárquico organiza os objetos e arquivos dentro de uma conta em uma hierarquia de diretórios e subdiretórios aninhados. Essa hierarquia é organizada da mesma forma que o sistema de arquivos em seu computador.
Quando seu mecanismo independente de ingestão de dados ou aplicativo de integração registra um novo sistema de registro, ele cria pastas obrigatórias em contêineres nas camadas de dados brutos, enriquecidos e padronizados. Se um aplicativo de dados alinhado à origem ingerir os dados, sua equipe de aplicativo de dados precisará que sua equipe de zona de destino de dados crie as pastas e os grupos de segurança. Coloque um nome de entidade de serviço ou identidade gerenciada no grupo correto e atribua um nível de permissão. Documente esse processo para as equipes de aplicativos de dados e zona de destino de dados.
Para saber mais sobre equipes, confira Noções básicas sobre funções e equipes para análises em escala de nuvem no Azure.
Cada produto de dados deve ter duas pastas no contêiner de produtos de dados que sua equipe de produtos de dados possui.
Na camada enriquecida de um contêiner padronizado, há duas pastas por sistema de origem, divididas por classificação. Com essa estrutura, sua equipe pode armazenar separadamente dados com diferentes classificações de segurança e dados e atribuir a eles diferentes acessos de segurança.
O contêiner padronizado precisa de uma pasta geral para confidencial ou menos e uma pasta confidencial para dados pessoais. Controle o acesso a essas pastas usando listas de controle de acesso (ACLs). É possível criar um conjunto de dados com todos os dados pessoais removidos e armazená-lo em sua pasta geral. Você pode, então, ter outro conjunto de dados que inclui todos os dados pessoais em sua pasta de dados pessoais confidenciais.
Uma combinação de ACLs e grupos do Microsoft Entra restringe o acesso aos dados. Essas listas e grupos controlam o que outros grupos podem ou não acessar. Os proprietários de dados e as equipes de aplicativos de dados podem aprovar ou rejeitar o acesso aos ativos de dados.
Para obter mais informações, consulte Privacidade dos dados.
Aviso
Alguns produtos de software não dão suporte à montagem da raiz de um contêiner do data lake. Devido a essa limitação, cada contêiner de data lake nas camadas de dados brutos, coletados, enriquecidos e de desenvolvimento deve conter uma única pasta que se ramifica para várias pastas. Configure suas permissões de pasta com atenção. Quando você cria uma nova pasta a partir da raiz, a ACL padrão no diretório pai determina a ACL padrão e a ACL de acesso de um diretório filho. A ACL de um arquivo filho não tem uma ACL padrão.
Para saber mais, confira ACLs (listas de controle de acesso) no Azure Data Lake Storage Gen2.
Camada de dados brutos (bronze) ou data lake um
Observação
A arquitetura de medalhão é um padrão de design de dados que descreve uma série de camadas de dados refinadas de forma incremental que fornecem uma estrutura básica no lakehouse. As camadas bronze, prata e ouro significam o aumento da qualidade dos dados em cada nível, sendo que a camada ouro representa a mais alta qualidade.
Pense na camada bruta como um reservatório que armazena dados no estado natural e original. Eles não são filtrados nem purificados. Você pode armazenar os dados no formato original, como JSON ou CSV. Ou pode ser econômico armazenar o conteúdo do arquivo como uma coluna em um formato de arquivo compactado, como Avro, Parquet ou Databricks Delta Lake.
Esses dados brutos são imutáveis. Mantenha seus dados brutos bloqueados e, se você conceder permissões a qualquer consumidor, automatizado ou humano, certifique-se de que eles sejam somente leitura. Você pode organizar essa camada usando uma pasta por sistema de origem. Dê a cada processo de ingestão acesso de gravação somente à pasta associada.
Ao carregar dados de sistemas de origem na zona de dados brutos, você pode optar por fazer:
- Cargas completas para extrair um conjunto de dados completo.
- Cargas delta para carregar apenas os dados alterados.
Indique o padrão de carregamento escolhido na estrutura de pastas para simplificar o uso para seus consumidores de dados.
Os dados brutos dos sistemas de origem para cada aplicativo de dados alinhado à origem ou origem do mecanismo de ingestão automatizado chegam à pasta completa ou à pasta delta. Cada processo de ingestão deve ter acesso de gravação somente à pasta associada.
As diferenças entre cargas completas e cargas delta são:
Carga completa – os dados completos da origem podem ser integrados se:
- O volume de dados na origem for baixo.
- O sistema de origem não mantiver um campo de carimbo de data/hora que identifica se os dados foram adicionados, atualizados ou excluídos.
- O sistema de origem substitui os dados completos todas as vezes.
Carga delta – os dados incrementais da origem podem ser integrados se:
- O volume de dados na origem for grande.
- O sistema de origem mantiver um campo de carimbo de data/hora que identifica se os dados foram adicionados, atualizados ou excluídos.
- O sistema de origem cria e atualiza arquivos quando ocorrem alterações de dados.
Seu data lake bruto for composto por seus contêineres de destino e conformidade. Cada contêiner usa uma estrutura de pastas 100% obrigatória específica para sua finalidade.
Layout do contêiner de destino
Seu contêiner de aterrissagem é reservado para dados brutos de um sistema de origem reconhecido. Seu mecanismo de ingestão independente de dados ou um aplicativo de dados alinhado à origem carrega os dados, que permanecem inalterados e em seu formato original com suporte.
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
Contêiner de conformidade de camada bruta
Sua camada bruta contém dados em conformidade com a qualidade de dados. À medida que os dados são copiados para um contêiner de destino, o processamento e a computação de dados são acionados para copiar os dados do contêiner de destino para o contêiner de conformidade. Nesta primeira fase, os dados são convertidos no formato de delta lake e colocados em uma pasta de entrada. Quando a qualidade dos dados é realizada, os registros aprovados são copiados para a pasta de saída. Os registros reprovados chegam a uma pasta de erros.
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
Dica
Pense em cenários em que talvez seja necessário recompilar uma plataforma de análise do zero. Considere os dados mais granulares necessários para recompilar repositórios de dados de leitura downstream. Tenha um plano de continuidade dos negócios e recuperação de desastres implementado para seus principais componentes.
Camada de dados enriquecidos (prata) ou data lake dois
Pense na camada enriquecida como uma camada de filtragem. Ela remove impurezas e também pode envolver enriquecimento.
Seu contêiner de padronização contém sistemas de registros e mestres. As pastas são segmentadas primeiro por área de assunto e, em seguida, por entidade. Os dados ficam disponíveis em tabelas mescladas e particionadas que são otimizadas para consumo de análise.
Contêiner padronizado
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
Observação
Essa camada de dados é considerada a camada prata ou a fonte de dados de leitura. Os dados nessa camada não tiveram transformações aplicadas além da qualidade dos dados, conversão do delta lake e alinhamento do tipo de dados.
O diagrama a seguir mostra o fluxo de data lakes e contêineres dos dados de origem para um contêiner padronizado.
Camada de dados coletados (ouro) ou data lake dois
Sua camada coletada é sua camada de consumo. Ela é otimizada para análises, em vez de para ingestão ou processamento de dados. A camada de dados coletados pode armazenar dados em data marts desnormalizados ou esquemas em estrela.
Os dados do contêiner padronizado são transformados em produtos de dados de alto valor que são fornecidos aos consumidores de dados. Esses dados têm estrutura. Eles podem ser fornecidos aos consumidores no estado em que se encontram, como notebooks de ciência de dados, ou por meio de outro repositório de dados de leitura, como o Banco de Dados SQL do Azure.
Use ferramentas, como o Spark ou o Data Factory, para a modelagem dimensional em vez de usar o mecanismo de banco de dados. Isso é importante para fazer do data lake a única fonte da verdade.
Quando a modelagem dimensional é feita fora do data lake, recomenda-se publicar os modelos novamente nele para fins de consistência. Essa camada não é uma substituta para um data warehouse. Normalmente, o desempenho dela não é adequado para painéis responsivos ou análises interativas de usuários finais e consumidores. Essa camada é mais adequada para analistas internos e cientistas de dados que executam consultas ad hoc de grande escala, consultas ou análises improvisadas ou para analistas avançados que não têm necessidades rígidas de relatórios sensíveis ao tempo. Como os custos de armazenamento são mais baixos em seu data lake do que em seu data warehouse, pode ser econômico manter dados granulares e de baixo nível em seu lake. Armazene dados agregados em seu warehouse. Gere essas agregações usando o Spark ou o Azure Data Factory. Persista-os em seu data lake antes de carregá-los em seu data warehouse.
Ativos de dados nessa zona são altamente governados e bem documentados. Atribua permissões por departamento ou função e organize as permissões por grupo de consumidores ou data mart.
Contêiner de produtos de dados
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Dica
Ao armazenar dados em outro repositório de dados de leitura, como o Banco de Dados SQL do Azure, certifique-se de ter uma cópia desses dados localizada em seus dados selecionados. Os usuários do seu produto de dados são guiados para seu principal armazenamento de dados de leitura ou instância do Banco de Dados SQL do Azure, mas eles também podem explorar dados com ferramentas extras se você disponibilizar os dados em seu data lake.
Camada de desenvolvimento ou data lake três
Os consumidores podem trazer outros produtos de dados úteis com os dados ingeridos no contêiner padronizado.
Nesse cenário, sua plataforma de dados pode alocar uma área restrita de análise para esses consumidores. Na área restrita, eles podem gerar insights valiosos usando os dados selecionados e os produtos de dados que eles trazem. Por exemplo, se uma equipe de ciência de dados quiser determinar a melhor estratégia de posicionamento de produtos para uma nova região, ela poderá trazer outros produtos de dados, como dados demográficos dos clientes e dados de uso de produtos semelhantes dessa região. A equipe pode usar os insights de vendas altamente valiosos desses dados para analisar a adequação do produto ao mercado e a estratégia de oferta.
Observação
A área restrita de análise é uma área de trabalho para um indivíduo ou um pequeno grupo de colaboradores. As pastas dessa área têm um conjunto especial de políticas que impedem tentativas de usá-la como parte de uma solução de produção. Essas políticas limitam o armazenamento total disponível e por quanto tempo os dados podem ser armazenados.
Geralmente, esses produtos de dados são de qualidade e precisão desconhecidas. Eles ainda são categorizados como produtos de dados, mas são temporários e são relevantes apenas para o grupo de usuários que os usam.
Quando esses produtos de dados evoluem, sua empresa pode promovê-los para sua camada de dados coletados. Para manter suas equipes de produtos de dados responsáveis por novos produtos, forneça a elas uma pasta dedicada na zona de dados coletada. Elas podem armazenar os novos resultados na pasta e compartilhá-los com outras equipes na sua organização.
Observação
Para cada Azure Synapse workspace que você criar, use o data lake três para criar um contêiner a ser usado como armazenamento primário. Esse contêiner impede que os espaços de trabalho do Azure Synapse interfiram nos limites de taxa de transferência das zonas coletadas e enriquecidas.