Uso de atributos usando tags
Este artigo explica como usar tags personalizadas e default para atribuir cargas de trabalho a espaços de trabalho, equipes, projetos e usuários específicos.
Para monitorar o custo e atribuir com precisão o uso do Databricks, o senhor pode adicionar tags personalizadas às cargas de trabalho e ao recurso compute. Databricks recomenda o uso de tabelas do sistema para view dados de uso. Consulte a referência da tabela do sistema de uso faturável.
Essas tags se propagam tanto para o uso logs quanto para AWS EC2 e AWS instâncias do EBS para análise de custos. Observação : os dados das tags podem ser replicados globalmente. Não use nomes ou valores de tags que possam comprometer a segurança de seu recurso. Por exemplo, não use nomes de tags que contenham informações pessoais ou confidenciais.
Tags objetos e recurso
O senhor pode adicionar tags personalizadas para os seguintes objetos gerenciar por Databricks:
Objeto | Interface de marcação (UI) | Interface de marcação (API) |
|---|---|---|
Workspace | N/A | |
Pool | UI do pool no site Databricks workspace | |
Para todos os fins e para o trabalho compute | computar a UI no site Databricks workspace | |
Armazém SQL | SQL warehouse UI no site Databricks workspace |
Não atribua uma tag personalizada com o endereço key Name a um clustering. Cada clustering tem uma tag Name cujo valor é definido por Databricks. Se o senhor alterar o valor associado a key Name, o clustering não poderá mais ser rastreado por Databricks. Como consequência, o clustering pode não ser encerrado depois de se tornar parado e continuará a incorrer em custos de uso.
tags padrão
Databricks adiciona as seguintes tags default a compute para todos os fins:
Etiqueta key | Valor |
|---|---|
| Valor constante: |
| Databricks ID interna do clustering |
| Nome do clustering |
| Nome de usuário (endereçoemail ) do usuário que criou o clustering |
No Job clustering, o site Databricks também aplica as seguintes tags default:
Etiqueta key | Valor |
|---|---|
| Nome do Job |
| ID do Job |
Databricks adiciona as seguintes tags default a todo o pool:
Etiqueta key | Valor |
|---|---|
| Valor constante: |
| ID interno do Databricks do usuário que criou o pool |
| ID interna do pool do Databricks |
Em compute usado por lakehouse monitoramento, Databricks também aplica as seguintes tags:
Etiqueta key | Valor |
|---|---|
| verdade |
| ID da tabela monitorada |
| ID do site workspace onde o monitor foi criado |
| ID do metastore em que a tabela monitorada existe |
Tag serverless compute cargas de trabalho
Visualização
Esse recurso está em Public Preview.
Para atribuir o uso do serverless compute a usuários, grupos ou projetos, o senhor pode usar as políticas de orçamento do serverless. Quando um usuário recebe uma política de orçamento do serverless, seu uso do serverless é automaticamente marcado com as tags da política. Consulte Uso de atributos com as políticas de orçamento do serverless.
Propagação de tags
As tags são propagadas para as instâncias do AWS EC2 de forma diferente, dependendo se o clustering foi criado ou não a partir de um pool.
Se um clustering for criado a partir de um pool, suas instâncias EC2 herdarão apenas as tags personalizadas e default workspace e pool, e não a tag do cluster. Portanto, se o senhor quiser criar um cluster a partir de um pool, certifique-se de atribuir todas as tags de cluster personalizadas de que precisa ao workspace ou pool.
Se um clustering não for criado a partir de um pool, suas tags se propagarão como esperado para as instâncias do EC2.
As tags clustering e pool se propagam para os relatórios de uso doDBU, independentemente de o clustering ter sido criado ou não a partir de um pool.
Se houver um conflito de nome de tag, as tags Databricks default têm precedência sobre as tags personalizadas e as tags pool têm precedência sobre a Cluster Tag.
Limitações
- A chave e os valores da tag só podem conter letras, espaços, números ou os caracteres
+,-,=,.,_,:,/,@. As tags que contêm outros caracteres são inválidas. - Se o senhor alterar os nomes ou valores das chaves de tag, essas alterações serão aplicadas somente após a reinicialização do clustering ou a expansão do site pool.
- Se as tags personalizadas do clustering entrarem em conflito com as tags personalizadas do site pool, o clustering não poderá ser criado.
- Pode levar até uma hora para que as tags workspace personalizadas sejam propagadas após qualquer alteração.
- Não é possível atribuir mais de 20 tags a um recurso workspace.
Práticas recomendadas de marcação
- Como as tags podem ser inseridas manualmente, sua organização deve padronizar seu par key-value. Databricks recomenda o desenvolvimento de uma política comercial para key e a nomeação de valores que o senhor possa compartilhar com todos os usuários.
- Todos os recursos devem ser marcados com uma chave geral que atribua o uso a uma unidade de negócios ou projeto. Por exemplo, um recurso do Job compute criado pela equipe financeira para seu orçamento anual pode incluir as tags
business-unit:financeeproject:annual-budget. - Para percepções mais granulares, atribua tags usando uma chave de alta especificidade. Por exemplo, o senhor pode criar chaves com base em funções, produto, serviço ou clientes.
- Quando aplicável, os administradores do workspace devem aplicar as tags usando as políticas do compute e as políticas de orçamento do serverless. Consulte Aplicação de tags personalizadas.
Aplicação de etiquetas com IAM role
Para garantir que determinadas tags sejam sempre preenchidas quando o recurso compute for criado, é possível aplicar uma IAM política específica ao accountprincipal IAM role do seu(aquele criado durante a account configuração do; entre em contato com o AWS administrador do se precisar de acesso). A IAM política deve incluir declarações explícitas de negação para a chave de tag obrigatória e valores opcionais. A criação do clustering falhará se as tags necessárias com um dos valores permitidos não forem fornecidas.
Por exemplo, se o senhor quiser impor as tags Department e Project, com apenas valores especificados permitidos para a primeira e um valor de forma livre e não vazio para a segunda, poderá aplicar uma política de IAM como esta:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MandateLaunchWithTag1",
"Effect": "Deny",
"Action": ["ec2:RunInstances", "ec2:CreateTags"],
"Resource": "arn:aws:ec2:region:accountId:instance/*",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:RequestTag/Department": ["Deptt1", "Deptt2", "Deptt3"]
}
}
},
{
"Sid": "MandateLaunchWithTag2",
"Effect": "Deny",
"Action": ["ec2:RunInstances", "ec2:CreateTags"],
"Resource": "arn:aws:ec2:region:accountId:instance/*",
"Condition": {
"StringNotLike": {
"aws:RequestTag/Project": "?*"
}
}
}
]
}
Ambas as ações ec2:RunInstances e ec2:CreateTags são necessárias para cada tag para uma cobertura eficaz dos cenários em que há agrupamentos que têm apenas instâncias sob demanda, apenas instâncias pontuais ou ambas.
A Databricks recomenda que o senhor adicione uma declaração de política separada para cada tag. A política geral pode se tornar longa, mas é mais fácil de depurar. Consulte a Referência de operadores de condição de política de IAM para obter uma lista de operadores que podem ser usados em uma política.
Os erros de criação de clustering devido a uma política IAM mostram um encoded error message, começando com:
Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster.
A mensagem é codificada porque os detalhes do status da autorização podem constituir informações privilegiadas que o usuário que solicitou a ação não deve ver. Consulte DecodeAuthorizationMessage API (ou CLI) para obter informações sobre como decodificar essas mensagens.