Databricks : CI/CD avec Azure DevOps et 3 méthodes de déploiement de notebooks en masse, la 3eme va vous étonner !

Avant de parler de méthode de déploiement, on va parler un peu de Databricks et de CI/CD.

Il n’y a pas toujours besoin de mettre en place du CI/CD, surtout lorsqu’on a des usages “self-service” et que l’on travaille directement production. Mais par exemple lorsqu’on a besoin d’automatiser des traitements (ça doit tourner tous les jours en automatique ou en continu via du streaming) et que l’on veut pas tout casser en production en cas d’erreur suite à une modification de code. Dans ces cas là, il vaut mieux travailler sur différents environnements identiques et indépendants. Et notamment au moins avec un environnement de dev pour pouvoir coder et tester son code tranquillement avant de modifier la prod. Beaucoup de personnes écrivent des livres entiers sur le sujet, mais nous on va simplifier et résumer le CI/CD à 2 choses :

  1. bien gérer la vie de son code grâce à un contrôleur de sources (un repo) => je ne perds plus de code, je trace les modifications, je travaille à plusieurs…
  2. déployer facilement et de façon automatisée le code dans les différents environnements => j’appuie sur un bouton et ça part en prod !

Databricks est compatible avec ces usages de développement et de déploiement en continue pour tous vos projets de data science et de data engineer.

Tout d’abord, il est possible de se connecter nativement à Github, Bitbucket Cloud ou dans Azure DevOps et de synchroniser ses notebooks automatiquement dans un repository GIT. Personnellement, j’utilise surtout Azure DevOps qui est simple à utiliser et sécurisé donc adapté à un usage en entreprise. Pour savoir comment mettre ca en place, la documentation Databricks est plutôt complète: https://docs.azuredatabricks.net/user-guide/notebooks/azure-devops-services-version-control.html#notebook-integration

Attention, il va  falloir mettre en place la synchro pour chaque notebook et après modification du notebook dans Databricks, surtout ne pas oublier de cliquer sur “Save now”  et mettre un commentaire (un vrai commentaire avec la description de vos modifications, pas de “zezg” ou “ghherhe” !) pour lancer un commit et synchroniser avec le script du repo, sinon bah ça fait rien Smile !

chrome_TdhduWhbxW

Une fois synchronisés, les notebooks se retrouvent alors dans le repo sous forme de fichiers textes Python, Scala, R ou SQL en fonction du type de notebook (même si ce notebook contient des blocks d’un autre langage).

rdjj1g4dYe

Tout ces principes de synchro seront à mettre en place dans le workspace Databricks de développement seulement, pas besoin pour les autres environnements.

Maintenant lorsque vos développements sont terminés, vous allez vouloir déployer vos notebooks sur d’autre workspaces Databricks pour l’UAT, la Préprod, la Prod … il est possible d’utiliser aussi Azure DevOps et ses pipelines de Build et de Release :

  • La partie Build va aller chercher les scripts dans le repo et générer un objet qu’on appelle un Artifact (l’équivalent d’un package de déploiement)
  • La partie Release elle va récupérer l’Artifact et le déployer dans le workspace Databricks de l’environnement souhaité.

POWERPNT_HuxGoRoZ8D

Sans rentrer trop dans les détails, le Build est simple, il suffit d’aller chercher les scripts dans le repo, la Release est un peu plus compliquée car il faut une méthode pour déployer les composants (code, notebooks…) et avec Azure DevOps il existe déjà des composants proposés par la communauté dans le marketplace :

Moi je vous propose une troisième solution de déploiement en masse de notebooks un peu plus “roots” via un script PowerShell :

Param(
    [string]$apiKey,
    [string]$rootDirectory,
    [string]$uriroot
)

Set-Location -Path $rootDirectory

# Create directory
foreach($directory in Get-ChildItem ".\" -Recurse -Directory)
{
    write-host $directory.FullName.Replace($rootDirectory,"")
    $body = @{
        path = $directory.FullName.Replace($rootDirectory,"").replace("\","/")
    }
    $bodyjson = (ConvertTo-Json $body)
    $headers = @{
        'Authorization' = "Bearer $apiKey"
    }
    $uri = "$uriroot/2.0/workspace/mkdirs"
    Invoke-RestMethod -Method 'Post' -Uri $uri -Headers $headers -Body $bodyjson
}

# Deploy Notebooks
foreach($file in Get-ChildItem ".\" -Recurse -File -Filter "*.*")
{
     
    write-host $file.FullName.Replace($rootDirectory,"")
    
    $EncodedText = [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes($file.FullName))
    
    $lng = ""
    if($file.Extension -eq ".py")
    {
        $lng = "PYTHON"
    }
    elseif($file.Extension -eq ".scala")
    {
        $lng = "SCALA"
    }
    elseif($file.Extension -eq ".sql")
    {
        $lng = "SQL"
    }
    elseif($file.Extension -eq ".r")
    {
        $lng = "R"
    }
    else {
        continue
    }
    $body = @{
        content = $EncodedText
        path = $file.FullName.Replace($rootDirectory,"").replace("\","/").replace($file.Extension,"")
        language = $lng
        overwrite = $TRUE
        format = "SOURCE"
    }
    $bodyjson = (ConvertTo-Json $body)
    $headers = @{
        'Authorization' = "Bearer $apiKey"
    }
    $uri = "$uriroot/2.0/workspace/import"
    Invoke-RestMethod -Method 'Post' -Uri $uri -Headers $headers -Body $bodyjson

}

L’intérêt de ce script PowerShell par rapport aux autres solutions est surtout qu’il fonctionnera aussi en dehors de Azure DevOps Smile

Les paramètres en entré sont :

En local il s’appelle de cette façon : .\deploynotebooks.ps1 -apiKey « <accesKey> » -rootDirectory « C:\pathTo\notebooks » -uriroot https://westeurope.azuredatabricks.net/api

Et dans Azure DevOps, mettez le script quelque part dans votre repo et vous pourrez passer par une tache d’exécution de script PowerShell de votre pipeline de release :

9IcLrYTvC6

FADATA

Fabien Adato est Consultant Data et BI chez AZEO. Après avoir intégré la société CGI Business Consulting où il rejoint une équipe dédiée à la Business Intelligence, il fait ses premières armes sur la solution Microsoft SQL Server. Pendant plus de 4 ans, il acquiert des compétences techniques et fonctionnelles sur toute la chaîne de valeur de la BI (ETL, Base de Données, Cube Olap et Rapport). Il a pu se spécialiser également sur de nouvelles technologies de la Data et notamment Hadoop, Pig et Hive, ainsi que des technologies self-service BI, le No-SQL comme la base de données MongoDB et le moteur d’indexation ElasticSearch. Il entre chez AZEO en 2014 pour y assurer le poste de Consultant DATA / BI, autour des technologies Microsoft SQL Server, Power BI et Azure Cortana Intelligence.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *