Fase 5: Projetar a arquitetura de armazenamento

Nesta fase, você projeta a infraestrutura de armazenamento para o espaço de trabalho Databricks e Unity Catalog.

Para processar dados no Databricks, é necessário configurar o armazenamento cloud . Existem dois tipos de armazenamento no Databricks:

• Armazenamento default Databricks : Armazenamento na account cloud pertencente Databricks . Utilizado pelo espaço de trabalho serverless para armazenamento da raiz workspace e, opcionalmente, para catálogos Unity Catalog .
• Armazenamento de gerenciamento de clientes : Armazenamento na account cloud do cliente. Utilizado pelo espaço de trabalho clássico para armazenamento workspace e armazenamento Unity Catalog .

Ambos os tipos de armazenamento utilizam o mesmo serviço cloud subjacente.

Projetar a arquitetura de armazenamento workspace

A accountde armazenamento workspace (/bucket) é uma parte obrigatória de um workspace Databricks e é usada para diversas finalidades:

• Armazenamento para o catálogo default Unity Catalog criado para este workspace.
• Outros dados gerados internamente e utilizados por diferentes serviços na plataforma, como a localização default dos modelos de experimentos e registros MLflow MLflow a localização default do pipeline declarativo do LakeFlow Spark e o Cloud Fetch.

padrões de armazenamento do espaço de trabalho

Utilizar uma rede virtual gerenciada pelo cliente oferece maior controle sobre o bucket do sistema de workspace . Primeiro, você cria o bucket raiz e, em seguida, o atribui a um workspace Databricks , mantendo o controle total sobre a política do bucket e garantindo que o workspace ainda possa acessá-lo.

Melhores práticas para armazenamento workspace

• Use locais externos Unity Catalog para substituir os locais de armazenamento default workspace .
• Desative o upload a partir do aplicativo web, a menos que seja absolutamente necessário (configure na página de administração).
• Não utilize o bucket raiz workspace (DBFS) para dados de produção do cliente.
• Entenda os riscos e as soluções alternativas para o bucket raiz.

Migração DBFS

O DBFS (Databricks File System) não deve ser usado para novos dados de produção. Para implantações existentes:

• Dados estruturados : Migrar tabelas DBFS para tabelas de gerenciamento Unity Catalog .
• Dados não estruturados : Migre arquivos do DBFS para volumes do Unity Catalog para acesso a arquivos no estilo POSIX.
• Arquivos do espaço de trabalho : Continue usando o armazenamento workspace (não DBFS) para logs notebooks, bibliotecas e cluster .

Arquitetura de armazenamento Unity Catalog

Os metastores Unity Catalog suportam três tipos de objetos que determinam como e onde os dados são armazenados: gerenciado, externo e estrangeiro.

Tipos de objetos de armazenamento

objetos

Para objetos de gerenciamento, um local de armazenamento de gerenciamento especifica um local no armazenamento de objetos cloud para armazenar dados para tabelas de gerenciamento e volumes de gerenciamento. Você pode associar um local de armazenamento de gerenciamento a um metastore, catálogo ou esquema. Os locais de armazenamento gerenciados em níveis inferiores na hierarquia substituem os locais de armazenamento definidos em níveis superiores quando tabelas gerenciam ou volumes gerenciam.

importante

Não é recomendável confiar em locais default , pois isso pode levar à localização conjunta não intencional de dados e complicar o controle de acesso e o gerenciamento do ciclo de vida. Defina explicitamente os locais de armazenamento no nível do catálogo ou do esquema.

Objetos externos

Objetos externos armazenam seus dados em locais externos. Locais externos associam as credenciais de armazenamento Unity Catalog a contêineres de armazenamento de objetos cloud (por exemplo, buckets Amazon S3 , contêineres Azure ou buckets Google Cloud Storage ). Locais externos são usados para:

• Defina e gerencie os locais de armazenamento de catálogos e esquemas.
• Defina os locais para tabelas externas e volumes externos.

Objetos estranhos

Um catálogo externo especifica uma conexão com um sistema de dados externo para acessar tabelas e esquemas remotos. Você pode associar um catálogo externo a metadados de fontes externas, como Hive metastore, AWS Glue ou Snowflake Horizon. Os catálogos externos fornecem acesso somente leitura aos objetos do banco de dados do sistema remoto, permitindo que você consulte tabelas e esquemas externos por meio do Unity Catalog sem replicar os dados.

arquitetura de armazenamento em nuvem

Arquitetura de armazenamento do GCP

Para uma conta GCP , um metastore Unity Catalog possui as seguintes características:

• Um ou nenhum bucket GCS para gerenciar tabelas no nível do metastore.
• Zero ou mais buckets no nível de catálogo ou esquema para tabelas de gerenciamento.
• Zero ou mais buckets para tabelas externas.

Assim como o espaço de trabalho, os buckets GCP podem estar em projetos diferentes GCP . A conta de serviço GCP fornece autenticação para o Unity Catalog acessar os buckets de armazenamento.

padrões de isolamento de armazenamento

Armazenamento separado por ambiente

Utilize contêineres de armazenamento diferentes para ambientes de desenvolvimento, teste e produção. Isso proporciona limites claros e impede o acesso acidental a dados de produção a partir de ambientes de nível inferior.

Armazenamento separado por unidade de negócio

Quando as unidades de negócio necessitarem de segregação completa de dados para fins de governança ou faturamento, utilize contêineres de armazenamento separados com credenciais de armazenamento distintas para cada unidade de negócio.

Armazenamento separado por domínio de dados

Em arquiteturas de malha de dados, cada domínio deve ter seus próprios contêineres de armazenamento, gerenciados por credenciais de armazenamento específicas do domínio.

Design de armazenamento multirregional

Se várias regiões utilizarem Databricks, a arquitetura de armazenamento deve account a localidade dos dados e os padrões de acesso entre regiões:

• implementou contêineres de armazenamento na mesma região do metastore para desempenho.
• Utilize o Delta Sharing Databricks-gerenciar (D2D) para compartilhar dados entre regiões.
• Avalie a frequência e o volume de acesso a dados entre regiões para determinar se é necessário um pipeline de replicação de dados.
• Considere os custos de saída ao acessar dados entre regiões.

atenção

Não registre tabelas compartilhadas como tabelas externas em mais de um metastore. O risco é que quaisquer alterações no esquema, nas propriedades das tabelas e nos comentários que ocorram como resultado de gravações no metastore A não serão registradas no metastore B. As tabelas no metastore B teriam que ser recriadas para terem o esquema correto, e as propriedades e os comentários das tabelas ficariam completamente desconectados. Isso também pode causar problemas de consistência com o serviço de commit Delta . Use Delta Sharing D2D para compartilhar dados entre metastores.

Estratégia de design de acesso e autenticação

Databricks recomenda o uso do Unity Catalog para gerenciar o acesso a todos os dados e, em particular, recomenda o uso de tabelas gerenciadas sempre que possível. Unity Catalog totalmente gerenciado, disposição de armazenamento, metadados e governança para gerenciamento de tabelas.

Para gerenciar o acesso ao armazenamento cloud externo que contém tabelas e volumes, Unity Catalog usa locais externos, que definem um caminho para o armazenamento cloud e as credenciais necessárias para acessar esse local. Além do armazenamento cloud , Unity Catalog também gerencia permissões para tabelas, modelos e outros elementos ativos, e pode ser integrado a catálogos externos.

Métodos de autenticação pela cloud

Arquitetura de autenticação do GCP

No GCP, Unity Catalog gera uma conta de serviço para acesso ao armazenamento:

1. Crie uma credencial de armazenamento no Unity Catalog, que gera uma account de serviço GCP no plano de controle.
2. Atribua à account de serviço a função IAM apropriada nos buckets GCS (por exemplo, Visualizador de Objetos de Armazenamento, Criador de Objetos de Armazenamento).
3. Criar locais externos que utilizem as credenciais de armazenamento.

Melhores práticas para autenticação no GCP

• Utilize contas de serviço separadas para diferentes buckets ou domínios de dados GCS .
• Aplicar permissões de privilégio mínimo usando condições do IAM.
• Ative o registro de logs do Google Cloud para auditar o acesso aos buckets GCS .
• Restrinja o acesso account de serviço usando políticas IAM .

Estratégia de criptografia de projeto

O armazenamento de dados do cliente pode ser criptografado usando práticas padrão cloud . Por default, os dados são criptografados em repouso usando a criptografia do provedor cloud e uma key de gerenciamento Databricks .

Opções de criptografia

Databricks-gerenciar chave (default)

Por default, seus dados são criptografados em repouso usando a criptografia do provedor cloud e uma key de gerenciamento Databricks . Isso fornece criptografia básica sem necessidade de configuração adicional.

Chave de gerenciamento de clientes

Para organizações que exigem chaves de identificação do cliente, todas cloud oferecem suporte a elas. As chaves de gerenciamento de clientes são geralmente usadas para dois propósitos:

Objetivo 1: Plano de controle e criptografia de serviço gerenciado

Criptografe os dados do cliente no plano de controle Databricks , no armazenamento default e nos serviços serverless compatíveis que armazenam dados do cliente em repouso (como pesquisa vetorial, resultados de consultas, código e segredos) com uma key sob o controle do cliente. Se o cliente remover a key ou revogar o acesso à key, todos os dados relacionados a esse workspace no plano de controle ficarão inacessíveis.

Objetivo 2: criptografia do plano de computação e de dados

Criptografe dados do cliente nos planos de dados e compute do cliente para serviços específicos. Defina uma key gerenciável pelo cliente para fins de criptografia de armazenamento, para que Databricks a utilize para criptografar o bucket raiz e os volumes de armazenamento conectados aos clusters.

Padrões de criptografia

Ambientes altamente regulamentados

Utilize uma chave gerenciada pelo cliente para criptografia tanto no plano de controle quanto no plano compute/dados, a fim de manter o controle total sobre a chave de criptografia e atender aos requisitos compliance .

Implantações empresariais padrão

Use a chave Databricks-gerenciar para a maioria das cargas de trabalho, reservando a chave customer-gerenciar para o espaço de trabalho de produção com dados confidenciais.

Implantações multi-tenant

Considere usar chaves de gerenciamento de cliente separadas para diferentes unidades de negócios ou ambientes, a fim de fornecer isolamento de criptografia.

Projetar segurança de rede de armazenamento

O acesso à rede para armazenamento cloud pode ser limitado como uma camada adicional de segurança. Caso as credenciais sejam vazadas, os controles de acesso à rede impedem seu uso.

Padrões de segurança de rede

• Utilize VPC Service Controls para criar perímetros de segurança em torno dos recursos de armazenamento.

Melhores práticas para segurança de redes de armazenamento

• Limitar o acesso ao armazenamento a redes virtuais ou sub-redes específicas.

• Utilize o serviço privado Connect para conectividade privada.

• Ative o registro de logs do serviço de armazenamento para auditar as tentativas de acesso.

• Configure as regras de rede antes de conceder amplas permissões de armazenamento.

Design de armazenamento em forma de cubo e raio

O padrão de design de armazenamento em estrela (hub-and-spoke) é uma arquitetura comum para implantações do Unity Catalog em empresas. Esse padrão centraliza os dados compartilhados ativos no armazenamento principal, enquanto permite que os dados específicos do domínio sejam armazenados nos dispositivos periféricos.

Características de armazenamento em formato de cubo e raio

• Armazenamento centralizado : Contém dados compartilhados e ativos de toda a organização (por exemplo, dados cadastrais de clientes, dados de referência, conjunto de dados centralizado).
• Armazenamento de dados específicos do domínio: Contém dados pertencentes e gerenciados por unidades de negócios (por exemplo, análises de vendas, campanhas marketing ).
• Separação de armazenamento : os catálogos de hub e de domínio usam armazenamento dedicado com credenciais de armazenamento separadas.
• Preferência de tabelas : Para dados estruturados no lakehouse, use tabelas.
• Volumes para dados brutos : Utilize volumes para acessar dados de destino, brutos ou não estruturados (que podem estar localizados fora do lakehouse , pois terceiros geralmente exigem acesso direto a esses locais de armazenamento).
• Tabelas externas para compartilhamento : Utilize tabelas externas para compartilhar dados fora do lakehouse (com outros sistemas que não podem usar Delta Sharing ou que precisam de acesso direto ao local de armazenamento).

Melhores práticas para projeto de armazenamento em rede (hub-and-spoke)

• Utilize o armazenamento centralizado para dados compartilhados em toda a organização, consumidos por múltiplos domínios.
• Utilize armazenamento spoke para dados específicos de domínio pertencentes a unidades de negócios.
• Separe as credenciais de armazenamento e os locais externos para o hub e para cada spoke.
• Use o recurso Delta Sharing Databrickspara compartilhar dados do hub para os spokes.
• Documentar a propriedade e a linhagem dos dados para armazenamento em hub e spoke.
• Nota: O armazenamento do metastore agora é opcional e não é recomendado o seu uso.

Recomendações de arquitetura de armazenamento

Recomendado

• Use tabelas Unity Catalog e não forneça acesso em nível de armazenamento aos buckets.
• Defina explicitamente os locais de armazenamento no nível do catálogo ou do esquema, em vez de depender dos valores padrão no nível do metastore.
• Armazenamento separado por ambiente (por exemplo, desenvolvimento, teste, produção) usando contêineres de armazenamento diferentes.
• Utilize volumes para caminhos de arquivo no estilo POSIX (Portable Operating System Interface) protegidos pelo Unity Catalog.
• Evite, sempre que possível, padrões legados de acesso a dados, como a montagem de armazenamento cloud e perfis de instância.
• Avalie se a chave de criptografia gerenciada pelo cliente (tanto para o serviço gerenciado quanto para o armazenamento) é necessária para aumentar o controle sobre os dados em repouso.
• Use o recurso " Delta Sharing Databrickspara compartilhar tabelas entre clouds e regiões.

Evitar

• Não utilize o bucket raiz (DBFS) para armazenamento de dados do cliente.
• Não armazene dados de produção no DBFS (Databricks File System).
• Não registre tabelas externas entre regiões (metastores).
• Não forneça acesso em nível de armazenamento (por exemplo, acesso a buckets S3, acesso a contêineres ADLS) diretamente aos usuários.
• Não confie nos locais de armazenamento default do metastore para dados de produção.

Resultados da Fase 5

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

• Arquitetura de armazenamento projetada para espaço de trabalho (gerenciamento de clientes vs. gerenciamento Databricks ).
• Arquitetura de armazenamento Unity Catalog projetada (objetos de gerenciamento vs externos vs objetos estrangeiros).
• Estratégia de isolamento de armazenamento definida (por ambiente, unidade de negócios ou domínio de dados).
• Estratégia de autenticação definida (por exemplo, função IAM , conectores de acesso ou conta de serviço).
• Estratégia de criptografia selecionada (chave de gerenciamento do Databricksvs. chave de gerenciamento do cliente).
• Padrões de segurança de rede de armazenamento definidos (por exemplo, políticas de bucket, firewalls de armazenamento, endpoint VPC ).
• Considerações sobre armazenamento em múltiplas regiões documentadas (se aplicável).
• Avaliação do design de armazenamento em estrela (hub-and-spoke) (para implantações corporativas).
• Estratégia de migração para DBFS planejada (para implantações existentes com dados DBFS).

Próxima fase : Fase 6: Projeto arquitetônico Delta Lake

Orientações de implementação : Para obter instruções passo a passo sobre como implementar seu projeto de armazenamento, consulte Conectar-se ao armazenamento de objetos cloud usando Unity Catalog.