Fase 2: Estratégia de design workspace

Nesta fase, você projeta a arquitetura do seu workspace para que esteja alinhada com a estrutura da sua organização, os requisitos de segurança e as necessidades operacionais.

Compreenda o espaço de trabalho

Um workspace Databricks é o limite operacional em uma região cloud onde as equipes desenvolvem e executam cargas de trabalho. Ele contém artefatos de colaboração (por exemplo, Notebook, Job, dashboards e repositórios) e configurações com escopo workspace , como permissões workspace , política de cluster, segredos e configurações SQL . O workspace é um ambiente de execução e colaboração. Os dados persistentes são normalmente armazenados em serviços cloud , como armazenamento de objetos.

Os administradores criam e configuram o espaço de trabalho com base nos objetivos da sua organização. Algumas equipes utilizam um único workspace enquanto outras se separam por domínio, ambiente (desenvolvimento/teste/produção), linha de negócios, geografia ou limites regulatórios. Essas escolhas determinam o raio administrativo, a segregação de funções, a atribuição de custos e a frequência de replicação. Começar com uma solução pequena como o Databricks requer configuração mínima, mas implantações maiores devem considerar requisitos futuros e como eles afetam sua capacidade de proteger dados e, ao mesmo tempo, capacitar as equipes.

Escolha o modelo de implantação workspace

Existem dois tipos de espaço de trabalho Databricks disponíveis:

espaço de trabalho sem servidor

Uma implantação workspace em sua account Databricks que vem pré-configurada com compute serverless e armazenamento default para fornecer uma experiência totalmente serverless .

características workspace sem servidor

• Armazenamento padrão : armazenamento em nuvem na account cloud da Databricks, na mesma região do workspace.

  • Você ainda pode se conectar ao seu armazenamento cloud a partir do espaço de trabalho serverless .

• computesem servidor : pré-configurada e disponível imediatamente.

• startuprápida : Não é necessário provisionar infraestrutura.

• Dimensionamento automático : adapta-se à demanda de carga de trabalho.

Espaço de trabalho clássico

Uma implantação workspace em sua account Databricks que provisiona recursos de armazenamento e compute em sua account cloud existente. compute sem servidor e serviços ainda estão disponíveis no espaço de trabalho clássico.

Características clássicas workspace

• Armazenamento de gerenciamento de clientes : Armazenamento em sua account cloud .
• Customer-gerenciar compute : infraestrutura de computação em sua account cloud .
• Controle de rede : Controle total sobre a configuração de VPC/VNet.
• Flexibilidade : compute sem servidor ainda pode ser usada juntamente com compute clássica.

Recomendações do modelo de implantação do espaço de trabalho

Use essas recomendações para decidir se deve implantar um workspace serverless ou um espaço de trabalho clássico para o seu cenário:

• Confirme se a região que você planeja usar oferece suporte a espaços de trabalho serverless e compute serverless , caso pretenda usar serverless.
• Analise as limitações workspace serverless para verificar se elas atendem aos seus requisitos.
• Avalie seus principais casos de uso (por exemplo, dimensionamento automático versus controle granular cluster ) e escolha o espaço de trabalho clássico ou serverless de acordo com a sua necessidade.
• Recomendação : comece com um espaço de trabalho serverless para obter eficiência operacional.
• Use o espaço de trabalho clássico quando : você precisar de configurações de rede personalizadas, conectividade on-premises ou requisitos compliance específicos.

Projetar uma estratégia de divisão workspace

Existem vários motivos para dividir uma casa à beira lakehouse em diferentes espaços de trabalho. Considere esses padrões ao projetar a arquitetura do seu workspace .

Motivos para dividir o espaço de trabalho

Isolar o espaço de trabalho com base nos requisitos de proteção de dados

Para setores altamente regulamentados com rigorosas exigências de separação de dados, o isolamento do espaço de trabalho simplifica a implementação de controles para dados sensíveis sem interferir em fluxos de trabalho de menor risco.

Isolar diferentes unidades de negócio

Garanta que nenhum workspace ativo no Databricks seja compartilhado entre unidades de negócios quando os limites organizacionais exigirem isolamento completo.

Isolar equipes com diferentes necessidades de plataforma

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

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

Separe os ambientes de desenvolvimento, teste e produção se você tiver requisitos de isolamento rigorosos. Por exemplo:

• Algumas organizações implantaram ambientes de desenvolvimento/teste/produção em redes virtuais diferentes, sendo necessário um espaço de trabalho separado para cada ambiente.
• Para testar novas configurações workspace antes de aplicá-las ao ambiente de Produção (como habilitar ou restringir recursos), o ambiente de Produção deve ser diferente dos workspace de Desenvolvimento e de Teste.
• Muitas empresas também isolam esses ambientes do ponto de vista de armazenamento e compute , utilizando diferentes contêineres de armazenamento, redes virtuais e o espaço de trabalho Databricks .

Operar em diversas regiões cloud

Quando uma organização atende usuários ou coleta dados em vários países ou regiões geográficas, regulamentações ou políticas internas podem exigir que dados específicos permaneçam na região, o que gera a necessidade de um espaço de trabalho separado implantado em cada região cloud para processar ou armazenar esses dados. Dividir o espaço de trabalho por região permite que as equipes alinhem as implementações Databricks com contas de armazenamento local e redes virtuais, mantendo-se em conformidade com os padrões corporativos comuns de governança e segurança.

O espaço de trabalho regional também ajuda a reduzir a latência para aplicativos interativos de análise e dados, colocando o compute mais perto dos usuários locais e da fonte de dados, o que melhora a experiência do usuário e o desempenho das consultas.

Dividir para superar as limitações de recursos

conta na nuvem (ou inscrição) possui limites de recursos. Implantar um espaço de trabalho em uma conta diferente é uma forma de garantir que haja recursos suficientes disponíveis para cada workspace. Cada workspace Databricks também possui limites, como o número de tarefas que podem ser executadas simultaneamente ou o número máximo de Databricks Apps. Dividir o espaço de trabalho garante que as cargas de trabalho em cada workspace tenham acesso a mais recursos.

limites de recursos do provedor de nuvem

Limites workspace GCP

No GCP, o número máximo de espaços de trabalho permitidos por default é 20.

Limites importantes

• Limites de projeto e serviço do GCP.
• Limites workspace GCP Databricks .

Considerações sobre espaço de trabalho dividido

Limitações de colaboração

Não existe compartilhamento (colaboração) de Notebooks entre espaços de trabalho. Use Unity Catalog em todo o espaço de trabalho para promover o compartilhamento de dados sempre que possível. O código pode ser compartilhado entre espaços de trabalho usando GitHub .

Despesas administrativas

Os custos administrativos para um grande número de espaços de trabalho podem se tornar substanciais. Frequentemente, ter mais de 100 espaços de trabalho pode levar inadvertidamente a espaços de trabalho órfãos ou não gerenciados, o que pode representar um risco de custo e/ou exfiltração de dados.

Requisito de automação

Para múltiplos espaços de trabalho, tanto a configuração quanto a manutenção devem ser totalmente automatizadas (usando ferramentas como Terraform, ferramentas específicas cloudou a API REST ). Isso é especialmente importante para fins de mobilidade e cenários de recuperação de desastres (DR), onde o provisionamento rápido workspace , o failover e a replicação de configuração entre regiões ou clouds são requisitos operacionais críticos.

Custos de infraestrutura de rede

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

limitações de recurso

Alguns recursos têm suporte limitado entreworkspace , como compute serverless com controles de saída serverless , que acessam o gerenciamento de serviços Unity Catalog . Determinados recursos, como recursos AI , Google Private Service Connect e chaves de criptografia, são definidos no nível workspace . Caso a empresa exija configurações de segurança diferentes para outras equipes, a aprovação desses recursos define a divisão workspace .

Matriz SDLC e de unidades de negócios

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

Compreenda os modos de segurança workspace

Os espaços de trabalho atribuídos ao Unity Catalog suportam os seguintes modos de acesso para clusters:

Modo de segurança	Características
Standard	Vários usuários podem trabalhar no mesmo cluster. Adequado para cargas de trabalho gerais (por exemplo, ETL, exploração de dados). Suporta apenas SQL, Python e Scala. Suporta controle de acesso granular (FGAC), incluindo permissões baseadas em viewe controle de acesso baseado em atributos/tabelas (ABAC). Não há suporte para o DBR de Machine Learning ML ) (mas muitas bibliotecas ML podem ser instaladas no DBR padrão).
Dedicado	Compatível com ML DBR e todos os idiomas. Dedicado a um único usuário: o cluster é acessível apenas por um usuário (atribuído durante a criação cluster ). Dedicado a um único grupo: Vários usuários do mesmo grupo podem trabalhar no mesmo cluster (o grupo é atribuído durante a criação do cluster).

Exemplos de implantações workspace

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

Implantação detenant único e região única

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

Implantação multirregional

• workspace de produção na região dos EUA.
• workspace de produção na região da UE (para compliance GDPR ).
• workspace de desenvolvimento compartilhado.
• Metastore Unity Catalog por região com Delta Sharing D2D para acesso a dados entre regiões.

Implantação em várias unidades de negócio

• Um workspace por unidade de negócio (por exemplo, vendas, marketing, engenharia).
• workspace de desenvolvimento compartilhado para todas as equipes.
• Metastore Unity Catalog com segregação em nível de catálogo.

Implantação baseada no ambiente

• workspace de produção (todas as unidades de negócio).
• workspace de teste (pré-produção).
• workspace de desenvolvimento (desenvolvimento compartilhado).
• Redes e armazenamento separados para cada ambiente.

Defina as convenções de nomenclatura workspace .

Estabeleça uma convenção de nomenclatura consistente para os espaços de trabalho a fim de melhorar a 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

Melhores práticas para nomear workspace

• Use letras minúsculas e hífenes.
• Inclua a designação do ambiente (por exemplo, produção, teste, desenvolvimento).
• Inclua a região para implantações em várias regiões.
• Inclua a unidade de negócios ou a finalidade, quando aplicável.
• Os nomes devem ter menos de 50 caracteres.
• Documente as convenções de nomenclatura no seu manual de procedimentos.

recomendações de estratégia de espaço de trabalho

Recomendado

• Divida os ambientes do SDLC em espaços de trabalho separados (no mínimo Desenvolvimento e Produção, mas possivelmente mais, dependendo dos requisitos).
• Utilize ferramentas de automação como o Terraform sempre que possível para minimizar erros humanos e estabelecer padrões de implantação repetíveis.
• Comece com o espaço de trabalho serverless e mude para o espaço de trabalho clássico somente quando tiver requisitos específicos de rede ou compliance .
• Estratégia de divisão workspace do documento e convenções de nomenclatura.
• Crie um workspace administrativo por região para gerenciar os recursos Unity Catalog .

Evite esses padrões

• Não crie espaços de trabalho separados para equipes individuais ou projetos pequenos (use catálogos e esquemas Unity Catalog para isolamento).
• Não implante mais de 50 a 100 espaços de trabalho sem uma justificativa sólida e automação robusta.
• Não divida o espaço de trabalho desnecessariamente (equilibre as necessidades de isolamento com a complexidade operacional).
• Evite a criação de workspace ad hoc sem seguir as convenções de nomenclatura.

Resultados da Fase 2

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

• Modelo de implantação do espaço de trabalho selecionado (espaço de trabalho serverless vs. espaço de trabalho clássico).
• Estratégia de divisão do espaço de trabalho projetada com base nas necessidades organizacionais (por exemplo, ambiente, unidade de negócios, região, compliance).
• Compreensão dos limites dos recursos e das estratégias de mitigação.
• Convenção de nomenclatura de espaços de trabalho definida.
• Modos de segurança compreendidos (padrão vs. dedicado).
• Exemplo de arquitetura de implantação documentada.
• Estratégia de automação planejada para o provisionamento workspace .

Próxima fase : Fase 3: Projetar a arquitetura Unity Catalog