Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Como parte do compromisso do Azure Databricks com a inovação, os recursos de plataforma e runtime podem ser desativados e substituídos por novos recursos. As versões do Databricks Runtime também são desativadas e substituídas regularmente. Esta página lista as fases de desativação e os detalhes sobre o suporte correspondente para recursos de plataforma e versões do Databricks Runtime. Ele também inclui consultas SQL para detectar clusters e trabalhos usando versões herdadas do Databricks Runtime.
Para obter informações sobre versões prévias e tipos de versão, confira versões prévias do Azure Databricks.
Ciclo de vida dos recursos da plataforma
As fases de desativação de recursos da plataforma Azure Databricks são descritas na tabela a seguir:
| Fase | Descrição | Suporte | Notas de migração |
|---|---|---|---|
| Herdada | O recurso ainda está disponível, mas há um recurso ou maneira mais recente e melhor de realizar as tarefas que esse recurso oferece. Este rótulo indica data de desativação futura. | Completo. Suporte e documentação estão disponíveis. | A migração para um novo recurso de substituição ou uma nova maneira de realizar a tarefa é incentivada, mas não é necessária de imediato. |
| Preterido | O recurso não está mais no desenvolvimento ativo. As atualizações não são mais lançadas. O recurso será desativado em breve. Portanto, é necessário desenvolver um plano para parar de usar o recurso e fazer a transição para uma alternativa. | Completo. O recurso não é mais atualizado, mas o suporte e a documentação ainda estão disponíveis. | A migração para um novo recurso de substituição ou uma nova maneira de realizar a tarefa é altamente encorajada, pois atualizações importantes não são mais aplicadas. |
| EOS (fim do suporte) | O recurso não está mais em desenvolvimento ativo e o suporte está oficialmente indisponível. | Nenhum. A documentação ainda pode existir, mas foi arquivada e não é mais mantida. | A migração para um novo recurso de substituição ou uma nova maneira de realizar a tarefa é urgente, pois atualizações importantes não são mais aplicadas e o suporte para solução de problemas futuros não está mais disponível. |
| EOL (fim da vida útil) | O recurso foi completamente removido do produto Databricks. | Nenhum | A migração para um novo recurso de substituição ou uma nova forma de executar a tarefa é necessária, pois o recurso não é mais utilizável. Neste ponto, pode ser muito difícil migrar. |
Ciclos de vida de suporte de runtime do Databricks
As tabelas a seguir descrevem os estágios de suporte e políticas de suporte para versões do Databricks Runtime. O Azure Databricks lança runtimes como versões beta e GA. O Azure Databricks dá suporte às versões GA por seis meses, a menos que a versão de runtime seja uma versão LTS (suporte de longo prazo). Para obter informações sobre versões compatíveis do Databricks Runtime, consulte Versões de notas de versão do Databricks Runtime e compatibilidade.
As cargas de trabalho em versões sem suporte do Databricks Runtime podem continuar sendo executadas, mas o Azure Databricks não fornece suporte nem correções.
Ciclo de vida da versão LTS do Databricks Runtime
| Fase | Descrição |
|---|---|
| Beta | SLAs de suporte não são aplicáveis. Para obter mais informações, confira Versões do Azure Databricks. |
| GA, suporte completo para a versão LTS | As principais correções de estabilidade e segurança têm backport. O Databricks lança versões LTS a cada seis meses e dá suporte a elas por três anos completos. As versões LTS com suporte são publicadas em Versões LTS do Databricks Runtime com suporte. |
| EOS (fim do suporte) | Quando não há suporte para a versão:
A data de fim do suporte é três anos após o lançamento. As versões sem suporte são publicadas em Notas de versão do fim do suporte ao Databricks Runtime. |
| EOL (fim da vida útil) | Depois que uma versão atinge o Fim da Vida Útil, ela é removida do ambiente do Azure Databricks e torna-se inutilizável. Não é possível iniciar novas cargas de trabalho e as cargas de trabalho existentes em execução nessas versões falham. Você deve migrar suas cargas de trabalho para uma versão de runtime com suporte. O Azure Databricks faz o melhor esforço para garantir que a data de fim de vida seja seis meses após a data de fim do suporte. No entanto, o Databricks se reserva o direito de remover completamente uma versão de versão a qualquer momento após o término do suporte, sem aviso prévio. |
Ciclo de vida da versão não LTS do Databricks Runtime
| Fase | Descrição |
|---|---|
| Beta | SLAs de suporte não são aplicáveis. Para obter mais informações, confira Versões do Azure Databricks. |
| GA, suporte total | As principais correções de estabilidade e segurança têm backport. O suporte completo para versões do Databricks Runtime dura por seis meses, com exceção das versões LTS (suporte de longo prazo). As versões com suporte, juntamente com as datas de fim de suporte, são publicadas em Todas as versões do Databricks Runtime com suporte. |
| EOS (fim do suporte) | Quando não há suporte para a versão:
As versões sem suporte são publicadas em Notas de versão do fim do suporte ao Databricks Runtime. |
| EOL (fim da vida útil) | O Databricks reserva o direito de remover por completo uma versão de lançamento a qualquer momento após o término do suporte, sem aviso prévio. |
Detectar quais clusters estão usando versões herdadas do Databricks Runtime
Essa exibição temporária fornece um resumo do uso de cluster do Databricks Runtime para clusters que executam o Databricks Runtime versões 10.4 ou anteriores. Ele agrega o uso nos últimos 90 dias e inclui informações de espaço de trabalho, identificadores de cluster, versões do Databricks Runtime, unidades de uso e uso total em Unidades do Databricks (DBUs).
CREATE OR REPLACE TEMP VIEW legacy_dbrs AS
WITH clusters_dbr_versions AS (
SELECT
account_id,
workspace_id,
cluster_id,
cluster_name,
owned_by,
dbr_version,
TRY_CAST(regexp_extract(dbr_version, '(\\d+)\\.(\\w+)?(?:\\.(\\w+))?', 1) AS INT) AS major_version,
TRY_CAST(regexp_extract(dbr_version, '(\\d+)\\.(\\w+)?(?:\\.(\\w+))?', 2) AS INT) AS minor_version,
ROW_NUMBER() OVER(PARTITION BY account_id, workspace_id, cluster_id ORDER BY change_time DESC) AS rnk
FROM
system.compute.clusters
QUALIFY rnk=1
),
usage AS (
SELECT
account_id,
workspace_id,
usage_metadata.cluster_id AS cluster_id,
usage_unit,
ROUND(SUM(usage_quantity), 2) AS total_usage_dbu,
MAX(usage_date) as last_seen_date
FROM
system.billing.usage
WHERE
usage_metadata.cluster_id IS NOT NULL AND
usage_date > CURRENT_DATE() - INTERVAL 90 DAYS
GROUP BY ALL
),
workspace_info AS (
SELECT
account_id,
workspace_id,
workspace_name,
workspace_url
FROM
system.access.workspaces_latest
)
SELECT
cdv.workspace_id,
wi.workspace_name,
wi.workspace_url,
cdv.cluster_name,
cdv.cluster_id,
cdv.owned_by,
cdv.dbr_version,
total_usage_dbu,
usage_unit,
last_seen_date
FROM
clusters_dbr_versions cdv
INNER JOIN usage u USING (workspace_id, cluster_id)
LEFT JOIN workspace_info wi USING (workspace_id)
WHERE
major_version < 10 OR (major_version = 10 AND minor_version < 4)
GROUP BY ALL
ORDER BY
workspace_id, total_usage_dbu DESC;
Para ver o uso herdado do Databricks Runtime por cluster, consulte a exibição que acabou de ser criada.
SELECT * FROM legacy_dbrs;
Para ver o uso agregado do cluster entre workspaces e versões do Databricks Runtime, use a consulta a seguir. Isso ajuda a identificar quais versões do Databricks Runtime ainda estão em uso, o número de clusters executando cada versão e o uso total em DBUs.
SELECT
dbr_version,
workspace_id,
COUNT(DISTINCT cluster_id) total_clusters,
SUM(total_usage_dbu) AS total_usage_dbu
FROM legacy_dbrs
GROUP BY dbr_version, workspace_id
ORDER BY dbr_version, workspace_id
Detectar quais trabalhos estão usando versões herdadas do Databricks Runtime
Use essa consulta para recuperar todos os trabalhos executados nos últimos 90 dias em que a execução mais recente usou uma versão do Databricks Runtime anterior à 10.4. Isso ajuda a identificar cargas de trabalho que exigem atualização.
%sql
with latest_jobs AS (
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM system.lakeflow.jobs
QUALIFY rn=1
),
latest_clusters AS (
SELECT
*,
ROW_NUMBER() OVER(PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
FROM system.compute.clusters
QUALIFY rn=1
),
job_tasks_exploded AS (
SELECT
workspace_id,
job_id,
EXPLODE(compute_ids) as cluster_id
FROM system.lakeflow.job_task_run_timeline
WHERE period_start_time >= CURRENT_DATE() - INTERVAL 90 DAY AND ARRAY_SIZE(compute_ids) > 0
GROUP BY ALL
),
workspace_info AS (
SELECT
account_id,
workspace_id,
workspace_name,
workspace_url
FROM
system.access.workspaces_latest
),
clusters_with_dbr AS (
SELECT
t1.*,
t2.cluster_name,
t2.owned_by,
t2.dbr_version
FROM job_tasks_exploded t1
INNER JOIN latest_clusters t2 USING (workspace_id, cluster_id)
)
SELECT
wi.account_id,
wi.workspace_id,
wi.workspace_name,
wi.workspace_url,
latest_jobs.name,
cwd.job_id,
cwd.cluster_id,
cwd.cluster_name,
cwd.dbr_version
FROM clusters_with_dbr cwd
JOIN workspace_info wi ON cwd.workspace_id = wi.workspace_id
LEFT JOIN latest_jobs USING (workspace_id, job_id)
WHERE dbr_version RLIKE '^([1-9]\\.|10\\.[0-3]\\.)'