Zonas e contentores Data Lake
É importante planejar sua estrutura de dados antes de colocá-la em um data lake. Quando você tem um plano, você pode usar a segurança, particionamento e processamento de forma eficaz.
Para obter uma visão geral dos data lakes, consulte Visão geral do Armazenamento do Azure Data Lake para análises em escala de nuvem.
Descrição geral
Suas três contas de data lake devem estar alinhadas às camadas típicas do data lake.
| Número do lago | Camadas | Número do contentor | Nome do contentor |
|---|---|---|---|
| 1 | Raw | 1 | Desembarque |
| 1 | Raw | 2 | Conformidade |
| 2 | Enriquecido | 1 | Padronizado |
| 2 | Com curadoria | 2 | Produtos de dados |
| 3 | Desenvolvimento | 1 | Área restrita do Google Analytics |
| 3 | Desenvolvimento | # | Número de armazenamento primário da sinapse |
A tabela anterior mostra o número padrão de contêineres que recomendamos por zona de aterrissagem de dados. A exceção a essa recomendação é se diferentes políticas de exclusão automática forem necessárias para os dados em um contêiner. Esses requisitos determinam sua necessidade de mais contêineres.
Nota
Três lagos de dados são ilustrados em cada zona de pouso 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 aterrissagem de dados.
Dependendo de suas necessidades, convém 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 espaço de nome hierárquico, que permite gerenciar arquivos com eficiência. O recurso de espaço de nome hierárquico organiza 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 no seu computador.
Quando seu mecanismo de ingestão agnóstica de dados ou aplicativo de integração registra um novo sistema de registro, ele cria pastas necessárias em contêineres nas camadas de dados brutas, enriquecidas e padronizadas. Se um aplicativo de dados alinhado à origem ingere os dados, sua equipe de aplicativo de dados precisará de sua equipe de zona de aterrissagem de dados para criar as pastas e os grupos de segurança. Coloque um nome de princípio de serviço ou identidade gerenciada no grupo correto e atribua um nível de permissão. Documente esse processo para sua zona de aterrissagem de dados e equipes de aplicativos de dados.
Para obter mais informações sobre equipes, consulte Compreender 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 que têm diferentes classificações de segurança e dados e atribuir-lhes diferentes acessos de segurança.
Seu contêiner padronizado precisa de uma pasta geral para dados confidenciais ou abaixo e uma pasta confidencial para dados pessoais. Controle o acesso a essas pastas usando listas de controle de acesso (ACLs). Você pode criar um conjunto de dados com todos os dados pessoais removidos e armazená-lo em sua pasta geral. Pode ter outro conjunto de dados que inclua todos os dados pessoais na sua pasta de dados pessoais sensíveis .
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 seus ativos de dados.
Para obter mais informações, consulte Gerenciamento de acesso a dados e Dados restritos.
Aviso
Alguns produtos de software não suportam a montagem da raiz de um contêiner de data lake. Devido a essa limitação, cada contêiner de data lake em camadas brutas, selecionadas, enriquecidas e de desenvolvimento deve conter uma única pasta que se ramifica para várias pastas. Configure cuidadosamente as permissões da sua pasta. Quando você cria uma nova pasta a partir da raiz, a ACL padrão no diretório pai determina a ACL padrão de um diretório filho e a ACL de acesso. A ACL de um arquivo filho não tem uma ACL padrão.
Para obter mais informações, consulte Listas de controle de acesso (ACLs) no Azure Data Lake Storage Gen2.
Camada bruta ou data lake um
Pense na camada bruta como um reservatório que armazena dados em seu estado natural e original. Não é filtrado nem purificado. Você pode armazenar os dados em seu 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 apenas à sua pasta associada.
Ao carregar dados de sistemas de origem na zona bruta, você pode optar por fazer:
- Cargas completas para extrair um conjunto de dados completo.
- O delta carrega para carregar apenas dados alterados .
Indique o padrão de carregamento escolhido na estrutura de pastas para simplificar o uso para os consumidores de dados.
Os dados brutos dos sistemas de origem para cada aplicativo de dados alinhado à fonte ou fonte do mecanismo de ingestão automatizada aterrissam na pasta completa ou na pasta delta. Cada processo de ingestão deve ter acesso de gravação apenas à sua pasta associada.
As diferenças entre cargas completas e cargas delta são:
Carga completa - Os dados completos da fonte podem ser integrados se:
- O volume de dados na origem é pequeno.
- O sistema de origem não mantém um campo de carimbo de data/hora que identifique se os dados foram adicionados, atualizados ou excluídos.
- O sistema de origem substitui os dados completos de cada vez.
Carga delta - Os dados incrementais da origem podem ser integrados se:
- O volume de dados na origem é grande.
- O sistema de origem mantém 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 sobre alterações de dados.
Seu data lake bruto é composto por seus contêineres de desembarque e conformidade. Cada contentor utiliza uma estrutura de pastas 100% obrigatória e específica para a sua finalidade.
Layout do contêiner de desembarque
Seu contêiner de desembarque é reservado para dados brutos provenientes de um sistema de origem reconhecido. Seu mecanismo de ingestão agnóstica de dados ou um aplicativo de dados alinhado à fonte carrega os dados, que são inalterados e em seu formato original suportado.
.
|-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
Recipiente de conformidade da camada bruta
Sua camada bruta contém dados conformes com a qualidade dos dados. À medida que os dados são copiados para um contêiner de desembarque, o processamento e a computação de dados são acionados para copiar os dados do contêiner de desembarque para o contêiner de conformidade. Nesta primeira etapa, os dados são convertidos no formato delta lake e pousam em uma pasta de entrada. Quando a qualidade dos dados é executada, os registros que passam são copiados para a pasta de saída. Os registros que falham são parar em uma pasta de erro.
.
|-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)}
Gorjeta
Pense em cenários em que você pode precisar reconstruir uma plataforma de análise do zero. Considere os dados mais granulares necessários para reconstruir armazenamentos de dados de leitura downstream. Certifique-se de ter um plano de continuidade de negócios e recuperação de desastres para seus principais componentes.
Camada enriquecida ou data lake dois
Pense na camada enriquecida como uma camada de filtração. Remove impurezas e também pode envolver enriquecimento.
Seu contêiner de padronização contém sistemas de registro e mestres. As pastas são segmentadas primeiro por área temática e, em seguida, por entidade. Os dados estão disponíveis em tabelas particionadas mescladas que são otimizadas para consumo de análise.
Recipiente 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)}
Nota
Esta camada de dados é considerada a camada de prata ou fonte de dados de leitura. Os dados dentro dessa camada não tiveram transformações aplicadas além da qualidade dos dados, conversão do lago delta 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 curada ou data lake dois
A sua camada selecionada é a sua camada de consumo. É otimizado para análise em vez de ingestão ou processamento de dados. A camada selecionada pode armazenar dados em data marts desnormalizados ou esquemas em estrela.
Os dados de seu contêiner padronizado são transformados em produtos de dados de alto valor que são servidos aos seus consumidores de dados. Estes dados têm estrutura. Ele pode ser servido aos consumidores no estado em que se encontram, como blocos de anotações de ciência de dados, ou por meio de outro armazenamento de dados de leitura, como o Banco de Dados SQL do Azure.
Use ferramentas, como o Spark ou o Data Factory, para fazer modelagem dimensional em vez de fazê-lo dentro do mecanismo de banco de dados. Este uso de ferramentas torna-se um ponto-chave se você quiser fazer do seu lago a única fonte de verdade.
Se você fizer modelagem dimensional fora do lago, talvez queira publicar modelos de volta ao lago para obter consistência. Esta camada não substitui um armazém de dados. Seu desempenho normalmente não é adequado para painéis responsivos ou análises interativas de usuário final e consumidor. Essa camada é mais adequada para analistas internos e cientistas de dados que executam consultas ou análises improvisadas em grande escala, ou para analistas avançados que não têm necessidades de relatórios sensíveis ao tempo. Como os custos de armazenamento são menores em seu data lake do que em seu data warehouse, pode ser econômico manter dados granulares e de baixo nível em seu lago. Armazene dados agregados no seu armazém. Gere essas agregações usando o Spark ou o Azure Data Factory. Persista-os no seu data lake antes de carregá-los no seu armazém de dados.
Os ativos de dados nessa zona geralmente são altamente controlados e bem documentados. Atribua permissões por departamento ou função e organize permissões por grupo de consumidores ou data mart.
Recipiente de produtos de dados
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Gorjeta
Quando você pousar dados em outro armazenamento 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 produto de dados são guiados para seu armazenamento de dados de leitura principal ou instância do Banco de Dados SQL do Azure, mas 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
Seus consumidores de dados podem trazer outros produtos de dados úteis junto com os dados ingeridos em seu contêiner padronizado.
Nesse cenário, sua plataforma de dados pode alocar uma área de sandbox de análise para esses consumidores. Na área restrita, eles podem gerar informações valiosas usando os dados e produtos de dados selecionados que eles trazem. Por exemplo, se uma equipe de ciência de dados quiser determinar a melhor estratégia de colocação de produtos para uma nova região, ela poderá trazer outros produtos de dados, como dados demográficos de clientes e de uso, de produtos semelhantes nessa região. A equipe pode usar os insights de vendas de alto valor desses dados para analisar o ajuste do mercado do produto e a estratégia de oferta.
Nota
A área de sandbox de análise é uma área de trabalho para um indivíduo ou um pequeno grupo de colaboradores. As pastas da área restrita têm um conjunto especial de políticas que impedem tentativas de usar essa área 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.
Estes produtos de dados são geralmente de qualidade e precisão desconhecidas. Eles ainda são categorizados como produtos de dados, mas são temporários e relevantes apenas para o grupo de usuários que está usando os dados.
Quando esses produtos de dados amadurecerem, sua empresa poderá promovê-los para sua camada de dados selecionada. Para manter suas equipes de produtos de dados responsáveis por novos produtos de dados, forneça às equipes uma pasta dedicada em sua zona de dados selecionada. Eles podem armazenar novos resultados na pasta e compartilhá-los com outras equipes em toda a organização.
Nota
Para cada espaço de trabalho do Azure Synapse que você criar, use o data lake três para criar um contêiner para usar como armazenamento principal. Esse contêiner impede que os espaços de trabalho do Azure Synapse interfiram com os limites de taxa de transferência de suas zonas selecionadas e enriquecidas.
Exemplo de fluxo de dados para produtos e sandbox de análise
O diagrama a seguir compila as informações neste artigo e mostra como os dados fluem para uma área restrita de produtos de dados e análise.
