Fase 8: Projetar a configuração compute
Nesta fase, você projeta os recursos compute e as configurações workspace para otimizar o desempenho, o custo e a segurança.
Databricks recomenda o uso compute serverless como opção principal. A arquitetura sem servidor não requer configuração, está sempre disponível e escala automaticamente conforme a carga de trabalho aumenta em segundos. Configure o compute clássica manualmente apenas se serverless não for compatível com o seu caso de uso.
Estratégia de dimensionamento cluster de design
Para cargas de trabalho compute clássicas, siga as práticas recomendadas de dimensionamento cluster para encontrar um ponto de partida razoável para suas cargas de trabalho.
Considerações sobre o dimensionamento do cluster
- Tipo de carga de trabalho : o processamento em lote requer clusters maiores. Cargas de trabalho interativas se beneficiam do dimensionamento automático.
- Volume de dados : dimensione os clusters com base no volume de dados esperado e nos requisitos de paralelismo.
- Requisitos de desempenho : Equilíbrio entre custo e latência de consulta.
- Dimensionamento automático : Ative o dimensionamento automático para cargas de trabalho com demanda variável.
- Tipos de instância : Escolha os tipos de instância com base nos requisitos de CPU, memória e E/S.
padrões de dimensionamento de clusters
- Pequenos clusters (2 a 8 nós): Desenvolvimento, teste e conjunto de dados pequeno.
- clustersde tamanho médio (8 a 32 nós): Cargas de trabalho ETL e análise de produção.
- clustersgrandes (32+ nós): Processamento de lotes em grande escala e treinamento machine learning .
Melhores práticas para dimensionamento cluster
- comece com uma configuração de linha de base e itere com base nas métricas de desempenho.
- Utilize o dimensionamento automático para lidar com cargas de trabalho variáveis de forma eficiente.
- Monitore as métricas de utilização do cluster (por exemplo, CPU, memória, E/S) para dimensionar os clusters corretamente.
- Utilize instâncias spot/preemptíveis para cargas de trabalho tolerantes a falhas a fim de reduzir custos.
- Documentar as decisões de dimensionamento cluster e as linhas de base de desempenho.
Para obter orientações detalhadas sobre o dimensionamento cluster , consulte as recomendações de configuração de computação.
Estratégia de dimensionamento SQL warehouse
Embora as equipes de ciência de dados sejam geralmente pequenas, os casos de uso de Business Intelligence (BI) frequentemente envolvem milhares de analistas. Para suportar tantos usuários, o Databricks SQL utiliza um mecanismo de escalonamento automático que adiciona ou remove clusters com base em três fatores principais:
- Taxa de transferência de consultas : Quantas consultas estão em execução no momento?
- Tamanho da fila : Quantas consultas estão aguardando uma vaga?
- Demanda prevista : a carga de trabalho estimada para os próximos dois minutos.
Essencialmente, o Databricks adiciona clusters quando calcula que o hardware atual não consegue processar as consultas existentes e futuras com rapidez suficiente.
Escolha a configuração correta SQL warehouse
Selecionar a configuração correta envolve equilibrar o tamanho do poder compute (potência) e a quantidade compute (concorrência).
Selecionando o tamanho (XS a XL)
O "tamanho da camiseta" do seu cluster determina quanta capacidade compute está disponível por consulta.
- Camadas pequenas (XS, S) : Ideais para consultas simples e rápidas. A opção mais econômica para painéis de controle básicos.
- Camadas grandes (L, XL) : Necessárias para consultas complexas e pesadas que processam conjuntos de dados massivos, a fim de evitar gargalos de desempenho.
Selecionando a contagem (concorrência)
O número de recursos compute determina quantos usuários simultâneos você pode suportar.
- Regra geral : Planeje aproximadamente 10 consultas simultâneas por cluster.
- Alta simultaneidade : Se você tiver muitos usuários executando consultas pequenas, use muitos clusters pequenos.
- Baixa concorrência : Se você tiver poucos usuários executando consultas massivas, use alguns clusters grandes.
Resumo : Aumente o tamanho para tornar as consultas individuais mais rápidas. Aumente a quantidade de usuários para suportar mais pessoas simultaneamente.
Melhores práticas para dimensionamento SQL warehouse
- Comece com um data warehouse SQL serverless (sem necessidade de dimensionamento).
- Para um data warehouse SQL clássico, comece com um tamanho médio e ajuste com base nos padrões de consulta.
- Monitore o desempenho das consultas e as métricas de enfileiramento.
- Utilize vários data warehouses para diferentes casos de uso (consultas pontuais versus relatórios).
- Documente os SLAs de desempenho para diferentes grupos de usuários.
Estratégia de política de cluster de design
Com a política de cluster, os administradores Databricks podem controlar diversos aspectos dos clusters que são criados. Políticas de cluster são recomendadas para todas as organizações. Os padrões comuns incluem:
casos de uso de política de cluster
- Limitar os usuários a configurações predefinidas : incluindo tipos de instância disponíveis, versões do Databricks e tamanhos de instância.
- Simplificar a interface do usuário : fixando e ocultando alguns valores.
- Controle de custos : Limitando o custo máximo por cluster.
- Garantir compliance : Exigindo que os metastores externos ou as tags de cluster específicas estejam em conformidade com as políticas corporativas.
padrões de política de cluster
- Política de desenvolvimento : Pequenos clusters com boa relação custo-benefício para desenvolvimento e testes.
- Política de produção : clusters maiores e mais poderosos com tipos de instância e tags específicos.
- PolíticaML : clusters com GPUs habilitadas e ambientes de execução de aprendizado ML .
- Política spot/preemptível : Use instâncias spot para cargas de trabalho tolerantes a falhas.
Melhores práticas para política de cluster
- Crie políticas separadas para diferentes equipes ou casos de uso.
- Use a política de cluster para impor controles de custos e limites de recursos.
- Exigir tags em todos os clusters para atribuição de custos.
- Simplifique a interface do usuário ocultando opções de configuração desnecessárias.
- Documento político de cluster : objetivos e restrições.
Para obter informações detalhadas sobre a configuração de políticas de cluster , consulte Criar e gerenciar políticas compute.
Estratégia de política orçamentária de design
As políticas de orçamento consistem em tags que são aplicadas a qualquer atividade compute serverless realizada por um usuário atribuído à política. As tags são registradas em seus registros de faturamento, permitindo que você atribua determinados usos de recursos serverless a orçamentos específicos.
casos de uso da política orçamentária
- Atribua os custos compute serverless a departamentos ou projetos específicos.
- Acompanhe os custos para diferentes ambientes (por exemplo, desenvolvimento, teste e produção).
- Monitorar os gastos em relação aos limites orçamentários.
- Gere relatórios de custos por unidade de negócios ou centro de custos.
Melhores práticas para políticas orçamentárias
- Criar políticas orçamentárias para cada departamento ou projeto.
- Utilize esquemas de tags consistentes em todos os recursos compute .
- Monitore a utilização do orçamento por meio de tabelas e painéis do sistema.
- Configure um alerta para o limite de orçamento.
- Revisar e ajustar as alocações orçamentárias trimestralmente.
Assim que uma política é aplicada a um Notebook, Job ou pipeline LakeFlow Spark Declarative, quaisquer tags contidas na política são propagadas para sua tabela de sistema system.billing.usage na coluna custom_tags .
Monitorar uso e custos
Importe painéis de controle de uso pré-configurados para seu espaço de trabalho para monitorar o uso em nível de conta e workspace .
Melhores práticas de monitoramento de uso
- Importe e personalize painéis de controle de uso pré-configurados.
- Monitore as tendências de uso por workspace, usuário e tipo compute .
- Configure um alerta para padrões de gastos incomuns.
- Analisar mensalmente os relatórios de utilização com as equipes de finanças.
- Utilize tabelas do sistema para análise de uso personalizada.
Para obter informações sobre o uso do painel padrão, consulte Monitorar a atividade account com tabelas do sistema.
Estratégia de controle de acesso de projeto
Em uma instalação default Databricks , todos os usuários podem criar e modificar objetos workspace , a menos que um administrador habilite o controle de acesso workspace . Organizações que desejam implementar a segregação de controle de acesso dentro de um workspace podem habilitar o controle de acesso workspace .
Padrões de controle de acesso
- Permissivo (default) : Todos os usuários podem criar clusters, trabalhos e notebooks.
- Restrito : Os usuários precisam de permissões explícitas para criar objetos workspace .
- Segregado : Equipes diferentes têm acesso a recursos workspace diferentes.
Melhores práticas para controle de acesso workspace
- Ativar o controle de acesso workspace para ambientes de produção.
- Utilize grupos para gerenciar permissões em vez de usuários individuais.
- Implemente o princípio do menor privilégio (conceda apenas as permissões necessárias).
- Revise e audite as permissões workspace regularmente.
- Documente as políticas de controle de acesso em seu manual de procedimentos.
Para obter informações detalhadas sobre a configuração do controle de acesso, consulte Listas de controle de acesso.
Revisar configurações workspace
A página Configurações do espaço de trabalho no Console de Administração contém um grande número de configurações importantes, muitas das quais não são cobertas por APIs (e, portanto, não podem ser automatizadas). Revise todas essas configurações antes de preparar um workspace para produção.
Baixe o guia de Melhores Práticas de Segurança em https://www.databricks.com/trust/security-features/best-practices e implementar as sugestões de acordo.
Configurações críticas workspace a serem revisadas
-
Controle de acesso/visibilidade : Ativado por default. Controla a visibilidade workspace, cluster, pool e Job.
-
Controle de acesso da tabela : Desativado por default. Considere deixar esta opção desativada e usar o Unity Catalog quando forem necessárias ACLs de tabela mais detalhadas.
-
Impor isolamento de usuário : Desativado por default. Habilite para evitar o uso de clusters "Sem isolamento".
-
Serviço de contêiner : Desativado por default. Habilite para permitir contêineres Docker personalizados.
-
Listas de permissões Git Repos : Desativadas por default. Considere habilitar a opção para limitar os repositórios aos quais os usuários podem acessar.
-
Proteções contra exfiltração : Considere desabilitar o recurso para evitar a exfiltração de dados:
- Botão de download para resultados Notebook
- upload uso de dados UI
- Exportação Notebook
- Notebook Mesa Prancheta recurso
- Download do artefato de execução MLflow
-
Armazenamento de resultados Notebook interativo : Habilite para armazenar os resultados na account do cliente.
Melhores práticas para configurações workspace
- Revise todas as configurações workspace antes da implantação em produção.
- Habilitar recurso com base em requisitos de segurança e compliance .
- Desative o recurso que possa permitir a exfiltração de dados para áreas de trabalho sensíveis.
- Documente as configurações e a justificativa workspace em seu manual de procedimentos.
- Utilize IaC (Terraform) para gerenciar as configurações workspace sempre que possível.
recomendações compute do espaço de trabalho
Recomendado
- Use compute serverless como opção principal para SQL, Notebook, Job e pipeline declarativo Spark LakeFlow .
- Crie a configuração inicial para clusters e SQL Warehouse e, em seguida, refine-a com base em cargas realistas.
- Ao projetar para capacidade, leve em consideração a relação custo/desempenho.
- Use a política de cluster para restringir permissões e impor tamanhos cluster razoáveis.
- Utilize políticas orçamentárias para atribuir custos de computação serverless a departamentos ou projetos.
- Monitore o uso por meio de tabelas do sistema e painéis pré-configurados.
- Ativar o controle de acesso workspace para ambientes de produção.
- Analise cuidadosamente as configurações workspace antes da implementação em produção.
Evite esses padrões
- Não crie clusters manualmente sem política de cluster em produção.
- Não permita tamanhos de cluster ilimitados ou tipos de instância sem controles.
- Não deixe de realizar testes com cargas de trabalho realistas antes de definir os tamanhos finais do cluster.
- Evite habilitar recursos que possam permitir a exfiltração de dados sem revisão de segurança.
- Não implante em produção sem antes revisar todas as configurações workspace .
Resultados da Fase 8
Após concluir a Fase 8, você deverá ter:
- Estratégia de computação definida (serverless versus compute clássica para diferentes cargas de trabalho).
- Estratégia de dimensionamento de cluster projetada para cargas de trabalho compute clássicas.
- Estratégia de dimensionamento SQL warehouse projetada para cargas de trabalho BI e análise.
- Estratégia de política de cluster projetada com políticas para diferentes equipes ou casos de uso.
- Estratégia de política orçamentária concebida para a atribuição de custos em serverless .
- Abordagem de monitoramento de utilização definida com dashboards e alertas.
- Estratégia de controle de acesso projetada para objetos workspace .
- Configurações do espaço de trabalho revisadas e documentadas para implantação em produção.
- Estratégia de otimização de custos definida (por exemplo, instâncias spot, escalonamento automático, dimensionamento adequado).
Próxima fase : Fase 9: Estratégia de observabilidade do projeto
Orientações de implementação : Para obter instruções passo a passo sobre como implementar sua configuração compute , consulte compute.