Partager via


Databricks prend en charge les cycles de vie

Dans le cadre de l’engagement d’Azure Databricks en matière d’innovation, les fonctionnalités de plateforme et d’exécution peuvent être supprimées et remplacées par de nouvelles fonctionnalités. Les versions de Databricks Runtime sont également supprimées et remplacées selon une planification régulière. Cette page répertorie les phases de mise hors service et les détails relatifs à la prise en charge correspondante des fonctionnalités de plateforme et des versions de Databricks Runtime. Il inclut également des requêtes SQL pour détecter des clusters et des travaux à l’aide des versions héritées de Databricks Runtime.

Pour plus d’informations sur les préversions et les types de versions, consultez les préversions d’Azure Databricks.

Cycle de vie des fonctionnalités de la plateforme

Les phases de mise hors service des fonctionnalités de la plateforme Azure Databricks sont décrites dans le tableau suivant :

Étape Descriptif Soutien Notes de migration
Ancien La fonctionnalité est toujours disponible, mais il existe une fonctionnalité plus récente, une meilleure fonctionnalité ou un moyen d’accomplir les tâches que cette fonctionnalité fournit. Cette étiquette indique une date de déclassement future. Complet. La prise en charge et la documentation sont disponibles. La migration vers une nouvelle fonctionnalité de remplacement ou une nouvelle façon d’accomplir la tâche est encouragée, mais pas immédiatement nécessaire.
Déprécié La fonctionnalité ne fait plus partie du développement de fonctionnalités actif. Les mises à jour ne sont plus publiées. La fonctionnalité sera bientôt retirée. Vous devez donc développer un plan pour cesser d’utiliser la fonctionnalité et passer à une alternative. Complet. La fonctionnalité n’est plus mise à jour, mais la prise en charge et la documentation sont toujours disponibles. La migration vers une nouvelle fonctionnalité de remplacement ou une nouvelle façon d’accomplir la tâche est fortement encouragée, car les mises à jour importantes ne sont plus appliquées.
Fin du support (EoS) La fonctionnalité n’est plus en développement actif et le support est officiellement indisponible. Aucune. La documentation peut toujours exister, mais elle a été archivée et n’est plus conservée. La migration vers une nouvelle fonctionnalité de remplacement ou une nouvelle façon d’accomplir la tâche est urgente, car les mises à jour importantes ne sont plus appliquées et la prise en charge des problèmes qui peuvent survenir n’est plus disponible.
Fin de vie (EoL) La fonctionnalité a été complètement supprimée du produit Databricks. Aucun(e) La migration vers une nouvelle fonctionnalité de remplacement ou une nouvelle façon d’accomplir la tâche est requise, car la fonctionnalité n’est plus utilisable. À ce stade, il peut être très difficile de migrer.

Cycles de vie de la prise en charge de Databricks Runtime

Les tableaux suivants décrivent les étapes de prise en charge et de stratégies de prise en charge pour les versions de Databricks Runtime. Azure Databricks publie les runtimes en versions bêta et GA. Azure Databricks prend en charge les versions GA pendant six mois, sauf si la version d'exécution est une version de support à long terme (LTS). Pour plus d’informations sur les versions prises en charge de Databricks Runtime, consultez Notes de publication sur les versions et la compatibilité de Databricks Runtime.

Les charges de travail sur les versions Databricks Runtime non prises en charge peuvent continuer à s’exécuter, mais Azure Databricks ne fournit ni prise en charge ni correctifs.

Cycle de vie de la version Databricks Runtime LTS

Étape Descriptif
Bêta Les contrats SLA de prise en charge ne sont pas applicables. Pour plus d’informations, consultez Versions de Databricks Runtime.
Disponibilité générale, prise en charge complète pour la version LTS Les principaux correctifs de sécurité et de stabilité sont rétro-portés.
Databricks publie des versions LTS tous les six mois et les prend en charge pendant trois années complètes.
Les versions LTS prises en charge sont publiées dans les versions LTS du Runtime Databricks prises en charge.
Fin du support (EoS) Si une version n’est pas prise en charge :
  • Les charges de travail exécutées sur ces versions ne bénéficient d'aucun support de la part de Databricks.
  • Les correctifs ne sont pas rétroportés.
  • Il n’est plus sélectionnable à l’aide de l’interface utilisateur lorsque vous créez ou mettez à jour une ressource de calcul.

La date de fin du support est trois ans après la publication.
Les versions non prises en charge sont publiées dans les notes de publication de fin de support de Databricks Runtime.
Fin de vie (EoL) Une fois qu’une version atteint la fin de vie, elle est supprimée de l’environnement Azure Databricks et devient inutilisable. Vous ne pouvez pas lancer de nouvelles charges de travail et les charges de travail existantes s’exécutant sur ces versions échouent. Vous devez migrer vos charges de travail vers une version d’exécution prise en charge.
Azure Databricks fait un meilleur effort pour garantir que la date de fin de vie est de six mois après la date de fin de support. Toutefois, Databricks se réserve le droit de supprimer complètement une version de mise en production à tout moment après la fin du support, sans préavis préalable.

Cycle de vie de la version de Databricks Runtime Non-LTS

Étape Descriptif
Bêta Les contrats SLA de prise en charge ne sont pas applicables. Pour plus d’informations, consultez Versions de Databricks Runtime.
Disponibilité générale - Prise en charge complète Les principaux correctifs de sécurité et de stabilité sont rétro-portés.
La prise en charge complète des versions de Databricks Runtime dure six mois, à l’exception des versions du support à long terme (LTS).
Les versions prises en charge ainsi que leurs dates de fin de support sont publiées dans Toutes les versions prise en charge de Databricks Runtime.
Fin du support (EoS) Si une version n’est pas prise en charge :
  • Les charges de travail exécutées sur ces versions ne bénéficient d'aucun support de la part de Databricks.
  • Les correctifs ne sont pas rétroportés.
  • Il n’est plus sélectionnable à l’aide de l’interface utilisateur lorsque vous créez ou mettez à jour une ressource de calcul.

Les versions non prises en charge sont publiées dans les notes de publication de fin de support de Databricks Runtime.
Fin de vie (EoL) Databricks se réserve le droit de supprimer complètement une version à tout moment après la fin du support, sans préavis.

Détecter les clusters qui utilisent les versions héritées de Databricks Runtime

Cette vue temporaire fournit un résumé de l’utilisation du cluster Databricks Runtime pour les clusters exécutant Databricks Runtime versions 10.4 ou antérieures. Il agrège l’utilisation au cours des 90 derniers jours et inclut les informations de l’espace de travail, les identificateurs de cluster, les versions de Databricks Runtime, les unités d’utilisation, et l’utilisation totale en unités 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;

Pour voir l’utilisation héritée de Databricks Runtime par cluster, interrogez la vue qui vient d’être créée.

SELECT * FROM legacy_dbrs;

Pour afficher l’utilisation agrégée du cluster entre les espaces de travail et les versions databricks Runtime, utilisez la requête suivante. Cela permet d’identifier les versions de Databricks Runtime qui sont toujours en cours d’utilisation, le nombre de clusters exécutant chaque version et l’utilisation totale dans les unités de base de données.

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

Détecter les travaux qui utilisent les versions héritées de Databricks Runtime

Utilisez cette requête pour récupérer tous les travaux qui ont été exécutés au cours des 90 derniers jours où l’exécution la plus récente a utilisé une version databricks Runtime antérieure à 10.4. Cela permet d’identifier les charges de travail qui nécessitent une mise à niveau.

%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]\\.)'