Fase 2: Estratégia para design do ambiente de trabalho

Nesta fase, você projeta sua arquitetura de workspace para se alinhar à estrutura, aos requisitos de segurança e às necessidades operacionais da sua organização.

Entender áreas de trabalho

O workspace do Azure Databricks é o limite operacional em uma região de nuvem em que as equipes desenvolvem e executam cargas de trabalho. Ele contém artefatos de colaboração (por exemplo, notebooks, trabalhos, dashboards e repositórios) e configurações no escopo do workspace, como permissões de workspace, políticas de cluster, segredos e configurações de SQL. O workspace é um ambiente de execução e colaboração. Os dados persistentes normalmente são armazenados em serviços de nuvem, como o armazenamento de objetos.

Os administradores criam e configuram workspaces com base nos objetivos de sua organização. Alguns usam um único workspace, enquanto outros se separam por domínio, ambiente (desenvolvimento/teste/prod), linha de negócios, geografia ou limites regulatórios. Essas opções determinam o raio administrativo, a separação de tarefas, a atribuição de custo e a frequência da replicação. Começar pequeno com o Azure Databricks requer uma configuração mínima, mas implantações maiores devem considerar os requisitos futuros e como eles afetam sua capacidade de proteger dados enquanto habilita as equipes.

Escolher o modelo de implantação do workspace

Há dois tipos de workspaces do Azure Databricks disponíveis:

Workspaces sem servidor

Uma implantação de workspace em sua conta do Azure Databricks que vem pré-configurada com computação sem servidor e armazenamento padrão para fornecer uma experiência completamente sem servidor.

Características do workspace sem servidor

• Armazenamento padrão: armazenamento em nuvem na conta de nuvem do Azure Databricks, na mesma região que o workspace.
  • Você ainda pode se conectar ao armazenamento em nuvem a partir de espaços de trabalho sem servidor.
• Computação sem servidor: pré-configurada e imediatamente disponível.
• Inicialização rápida: não é necessário provisionamento de infraestrutura.
• Dimensionamento automático: dimensiona com a demanda de carga de trabalho.

Espaços de trabalho clássicos

Uma implantação de workspace na sua conta do Azure Databricks que provisiona recursos de armazenamento e computação na sua conta de nuvem existente. A computação e os serviços sem servidor ainda estão disponíveis em workspaces clássicos.

Características clássicas do workspace

• Armazenamento gerenciado pelo cliente: armazenamento em sua conta de nuvem.
• Computação gerenciada pelo cliente: infraestrutura de computação em sua conta de nuvem.
• Controle de rede: controle total sobre a configuração de VPC/VNet.
• Flexibilidade: a computação sem servidor ainda pode ser usada junto com a computação clássica.

Recomendações do modelo de implantação do workspace

Use estas recomendações para decidir se deseja implantar um workspace clássico ou sem servidor para seu cenário:

• Confirme se a região que você planeja usar dá suporte a workspaces sem servidor e computação sem servidor se você pretende usar sem servidor.
• Examine as limitações do workspace sem servidor para verificar se elas atendem aos seus requisitos.
• Avalie seus principais casos de uso (por exemplo, dimensionamento automático versus controle de cluster refinado) e escolha workspaces clássicos ou sem servidor adequadamente.
• Recomendação: comece com workspaces sem servidor para eficiência operacional.
• Use workspaces clássicos quando: você precisa de configurações de rede personalizadas, conectividade local (on-premises) ou requisitos de conformidade específicos.

Estratégia de divisão do ambiente de trabalho de design

Há várias razões para dividir uma configuração de lakehouse em diferentes espaços de trabalho. Considere esses padrões ao projetar sua arquitetura de workspace.

Motivos para dividir espaços de trabalho

Isolar workspaces de acordo com os requisitos de proteção de dados

Para indústrias fortemente regulamentadas, com uma rigorosa imposição de separação de dados, isole os espaços de trabalho para simplificar a implementação de controles para dados confidenciais, sem interferir nos fluxos de trabalho de menor risco.

Isolar unidades de negócios diferentes

Verifique se nenhum ativo de workspace no Azure Databricks é compartilhado entre unidades de negócios quando os limites organizacionais exigem isolamento completo.

Isolar equipes com diferentes necessidades de plataforma

Se equipes diferentes exigirem acesso a diferentes conjuntos de recursos de plataforma (por exemplo, acesso total a todos os recursos de uma equipe de administração central, mas não para outras equipes ou testes de plataforma), essas equipes deverão ser separadas por workspaces.

Isolar ambientes do ciclo de vida de desenvolvimento de software (SDLC)

Separe os ambientes Dev, Staging e Prod se você tiver requisitos de isolamento estritos. Por exemplo:

• Algumas organizações implantam ambientes de Desenvolvimento/Preparo/Prod em diferentes redes virtuais, de modo que workspaces separados são necessários para cada ambiente.
• Para testar novas configurações de workspace antes de aplicá-las ao Prod (como habilitar ou restringir recursos), o Prod deve ser um workspace diferente de Desenvolvimento ou Preparo.
• Muitas empresas também isolam esses ambientes de uma perspectiva de armazenamento e computação usando diferentes contêineres de armazenamento, redes virtuais e workspaces do Azure Databricks.

Operar em várias regiões de nuvem

Quando uma organização atende usuários ou coleta dados em vários países ou geografias, regulamentos ou políticas internas podem exigir que dados específicos permaneçam na região, o que impulsiona a necessidade de workspaces separados implantados em cada região de nuvem que processam ou armazenam esses dados. Dividir workspaces por região permite que as equipes alinhem as implantações do Azure Databricks com contas de armazenamento locais e redes virtuais, seguindo os padrões comuns da empresa para governança e segurança.

Os workspaces regionais também ajudam a reduzir a latência para aplicativos de dados e análise interativa, colocando a computação mais próxima de usuários locais e fontes de dados, o que melhora a experiência do usuário e o desempenho da consulta.

Dividir para superar os limites de recursos

Contas de nuvem (ou assinaturas) têm limites de recursos. Implantar os workspaces em contas diferentes é uma forma de garantir que haja recursos suficientes disponíveis para cada um. Há também limites em cada workspace do Azure Databricks, como o número de tarefas que podem ser executadas simultaneamente ou o número máximo de Aplicativos do Azure Databricks. Dividir os espaços de trabalho garante que as cargas de trabalho em cada espaço tenham acesso a mais recursos.

Limites de recursos do provedor de nuvem

Limites do workspace do Azure

Para superar os limites de nível de assinatura (por exemplo, contas de armazenamento máximas ou taxas máximas de solicitação por segundo), os workspaces com altas demandas de recursos devem ser implantados em assinaturas separadas do Azure.

Limites importantes

• Assinaturas do Azure e limites de serviço.
• Limites do workspace do Azure Azure Databricks.

Considerações sobre espaços de trabalho divididos

Limitações de colaboração

Não há nenhum compartilhamento de notebook (colaboração) entre workspaces. Use o Catálogo do Unity em workspaces para promover o compartilhamento de dados sempre que possível. O código pode ser compartilhado usando o GitHub entre workspaces.

Sobrecarga administrativa

A sobrecarga administrativa para um grande número de espaços de trabalho pode se tornar substancial. Muitas vezes, ter mais de 100 espaços de trabalho pode, inadvertidamente, levar a espaços de trabalho órfãos ou não gerenciados, o que pode acarretar risco de custo e/ou exfiltração.

Requisito de automação

Para vários workspaces, a instalação e a manutenção devem ser totalmente automatizadas (usando ferramentas como o Terraform, ferramentas específicas de nuvem ou a API REST). Isso é especialmente importante para fins de mobilidade e cenários de recuperação de desastre (DR), em que o provisionamento rápido do workspace, o failover e a replicação de configuração entre regiões ou nuvens são requisitos operacionais críticos.

Custos de infraestrutura de rede

Se cada workspace precisar ser protegido na camada de rede (como para a proteção contra exfiltração de dados), a infraestrutura de rede necessária poderá ficar muito cara se você tiver centenas de workspaces.

Limitações de recursos

Alguns recursos têm suporte limitado entre workspaces, como computação sem servidor com controles de saída sem servidor, que acessam os serviços gerenciados do Catálogo do Unity. Determinados recursos, como recursos de IA, Link Privado do Azure e chaves de criptografia, são definidos em um nível de workspace. Se a empresa exigir configurações de segurança diferentes para outras equipes, a aprovação desses recursos definirá a divisão do workspace.

SDLC e matriz de unidade de negócios

Se você quiser separar workspaces para Desenvolvimento/Homologação/Produção e também quiser separar unidades de negócios por workspaces, considere os limites dos workspaces dos diferentes provedores de nuvem. A matriz pode levar rapidamente a um grande número de espaços de trabalho.

Entender os modos de segurança do workspace

Os workspaces atribuídos ao Catálogo do Unity dão suporte aos seguintes modos de acesso para clusters:

Exemplos de implantações de espaço de trabalho

Ao começar a usar o Azure Databricks, a maioria das organizações implanta um lakehouse de locatário único em uma única região de nuvem. No entanto, à medida que sua organização cresce, os administradores podem adaptar suas implantações para atender aos casos de uso complexos.

Implantação de locatário único e região única

• Um workspace de produção.
• Um workspace de desenvolvimento.
• Todos os recursos em uma única região de nuvem.

implantação com várias regiões

• Espaço de trabalho de produção na região dos EUA.
• Workspace de produção na região da UE (para conformidade com o RGPD).
• Ambiente de desenvolvimento compartilhado.
• Metastore do Unity Catalog por região com Compartilhamento Delta D2D para acesso a dados entre regiões.

Implantação de unidade de vários negócios

• Um workspace por unidade de negócios (por exemplo, Vendas, Marketing, Engenharia).
• Ambiente de trabalho de desenvolvimento compartilhado para todas as equipes.
• Metastore central do Unity Catalog com segregação no nível do catálogo.

Implantação baseada em ambiente

• Workspace de produção (todas as unidades de negócios).
• Espaço de trabalho de homologação (teste de pré-produção).
• Ambiente de desenvolvimento (desenvolvimento compartilhado).
• Redes e armazenamento separados para cada ambiente.

Definir convenções de nomenclatura do workspace

Estabeleça uma convenção de nomenclatura consistente para workspaces para melhorar a capacidade de descoberta e o gerenciamento.

Padrão de nomenclatura recomendado

{organization}-{environment}-{region}-{purpose}

Exemplos

• acme-prod-us-west-analytics
• acme-dev-shared
• acme-prod-eu-west-gdpr
• acme-staging-us-east-dataeng

Práticas recomendadas para nomeação de espaço de trabalho

• Use letras minúsculas e hifens.
• Incluir designação de ambiente (por exemplo, prod, preparo, desenvolvimento).
• Incluir região para implantações de várias regiões.
• Inclua a unidade de negócios ou a finalidade quando aplicável.
• Mantenha os nomes abaixo de 50 caracteres.
• Convenções de nomenclatura de documentos em seu runbook.

Recomendações de estratégia para workspace

Recomendado

• Divida ambientes SDLC em workspaces separados (pelo menos Dev e Prod, mas possivelmente mais dependendo dos requisitos).
• Use ferramentas de automação como o Terraform sempre que possível para minimizar o erro humano e estabelecer padrões de implantação repetíveis.
• Comece com workspaces sem servidor e alterne para workspaces clássicos somente quando você tiver requisitos de conformidade ou de rede específicos.
• Estratégia de divisão de espaço de trabalho do documento e convenções de nomenclatura.
• Crie um workspace administrativo por região para gerenciar recursos do Unity Catalog.

Evitar esses padrões

• Não crie workspaces separados para equipes individuais ou projetos pequenos (use catálogos e esquemas do Catálogo Unity para isolamento).
• Não implante mais de 50 a 100 workspaces sem justificativa forte e automação robusta.
• Não divida workspaces desnecessariamente (balancee as necessidades de isolamento com a complexidade operacional).
• Evite a criação de workspace ad hoc sem seguir convenções de nomenclatura.

Resultados da fase 2

Depois de concluir a Fase 2, você deverá ter:

• Modelo de implantação de workspace selecionado (sem servidor versus workspaces clássicos).
• Estratégia de divisão de workspace projetada com base em necessidades organizacionais (por exemplo, ambiente, unidade de negócios, região, conformidade).
• Noções básicas sobre limites de recursos e estratégias de mitigação.
• Convenção de nomenclatura do espaço de trabalho definida.
• Modos de segurança compreendidos (padrão versus dedicado).
• Arquitetura de implantação de exemplo documentada.
• Estratégia planejada de automação para provisionamento de espaço de trabalho.

Próxima fase: Fase 3: Arquitetura do Catálogo do Design Unity