Chapitre 2 : MLOps vs DevOps vs DataOps

Comprendre le paysage des Ops

Le paysage moderne des données et des logiciels implique plusieurs disciplines "Ops". Comprendre comment elles se rapportent et diffèrent est crucial pour construire des équipes et des systèmes efficaces.

Aperçu de la comparaison

Tableau de comparaison détaillé

Aspect	DevOps	DataOps	MLOps
Focus principal	Livraison de logiciels	Livraison de pipeline de données	Livraison de modèles ML
Principal artefact	Code d'application	Produits de données	Modèles ML
Tests	Unitaire, intégration, E2E	Qualité des données, schéma	Validation de modèle, A/B
Versionnage	Code uniquement	Traçabilité des données	Code + Données + Modèles
Surveillance	Métriques d'application, journaux	Métriques de qualité des données	Performance du modèle, dérive
Cible CI/CD	Déployer des applications	Déployer des pipelines de données	Déployer des modèles
Boucle de rétroaction	Rapports de bogues	Problèmes de données	Dégradation du modèle

DevOps : La fondation

DevOps se concentre sur le raccourcissement du cycle de développement tout en livrant fréquemment des fonctionnalités, des correctifs et des mises à jour.

Pratiques fondamentales de DevOps

# Exemple : Pipeline CI/CD standard DevOps
name: Application CI/CD
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build
        run: npm run build
      
      - name: Unit Tests
        run: npm test
      
      - name: Integration Tests
        run: npm run test:integration
      
      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .

  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy to Production
        run: kubectl apply -f k8s/

Outils DevOps

Catégorie	Outils
Contrôle de version	Git, GitHub, GitLab
CI/CD	Jenkins, GitHub Actions, GitLab CI
Conteneurs	Docker, Podman
Orchestration	Kubernetes, Docker Swarm
Surveillance	Prometheus, Grafana, Datadog
IaC	Terraform, Ansible, Pulumi

DataOps : Gestion des pipelines de données

DataOps applique les principes DevOps aux flux de travail d'analyse de données et d'ingénierie des données.

Pratiques fondamentales de DataOps

# Exemple : Pipeline DataOps avec Great Expectations
import great_expectations as gx
from great_expectations.core.batch import BatchRequest

# Créer un contexte de données
context = gx.get_context()

# Définir les attentes pour la qualité des données
validator = context.get_validator(
    batch_request=BatchRequest(
        datasource_name="my_datasource",
        data_connector_name="default_inferred_data_connector",
        data_asset_name="sales_data",
    ),
    expectation_suite_name="sales_data_expectations"
)

# Vérifications de la qualité des données
validator.expect_column_values_to_not_be_null("customer_id")
validator.expect_column_values_to_be_between("quantity", min_value=1, max_value=1000)
validator.expect_column_values_to_be_unique("order_id")
validator.expect_column_values_to_match_regex("email", r"^[\w\.-]+@[\w\.-]+\.\w+$")

# Enregistrer les attentes
validator.save_expectation_suite(discard_failed_expectations=False)

Outils DataOps

Catégorie	Outils
Orchestration	Apache Airflow, Dagster, Prefect
Qualité des données	Great Expectations, dbt tests, Soda
Catalogue de données	DataHub, Amundsen, Apache Atlas
ETL/ELT	dbt, Spark, Fivetran
Traçabilité des données	OpenLineage, Marquez

MLOps : L'intersection

MLOps se situe à l'intersection de DevOps et DataOps, héritant des pratiques des deux tout en ajoutant des capacités spécifiques au ML.

Ce que MLOps ajoute

Défis spécifiques à MLOps

Défi	Description	Solution
Reproductibilité du modèle	Même code, résultats différents	Fixation des graines, verrouillage de l'environnement
Dérive des données	Les données d'entrée changent au fil du temps	Détection de dérive, surveillance
Décadence du modèle	La performance du modèle se dégrade	Entraînement continu, alertes
Gestion des expériences	Suivi de nombreuses expériences	MLflow, W&B, Neptune
Cohérence des caractéristiques	Mismatch train/serve des caractéristiques	Feature stores

Structures d'équipe

Option 1 : Équipe MLOps centralisée

┌─────────────────────────────────────────────────────────┐
│                    Équipe de plateforme MLOps            │
├─────────────────────────────────────────────────────────┤
│  • Possède l'infrastructure ML                           │
│  • Fournit des outils en libre-service                   │
│  • Définit les normes et les meilleures pratiques        │
│  • Soutient plusieurs équipes ML                         │
└─────────────────────────────────────────────────────────┘
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
     ┌─────────┐    ┌─────────┐    ┌─────────┐
     │ Équipe  │    │ Équipe  │    │ Équipe  │
     │   ML    │    │   ML    │    │   ML    │
     │    A    │    │    B    │    │    C    │
     └─────────┘    └─────────┘    └─────────┘

Avantages :

Normes cohérentes
Utilisation efficace des ressources
Expertise spécialisée

Inconvénients :

Potentiel goulot d'étranglement
Peut ne pas comprendre les besoins spécifiques de l'équipe

Option 2 : Ingénieurs MLOps intégrés

┌─────────────────────────────────────────────────────────┐
│                   Équipe Produit A                       │
├─────────────────────────────────────────────────────────┤
│  Scientifiques des données (3) + Ingénieur ML (1) + MLOps (1) │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                   Équipe Produit B                       │
├─────────────────────────────────────────────────────────┤
│  Scientifiques des données (2) + Ingénieur ML (2) + MLOps (1) │
└─────────────────────────────────────────────────────────┘

Avantages :

Connaissance approfondie du domaine
Itération rapide
Communication directe

Inconvénients :

Efforts dupliqués
Pratiques incohérentes
Consommation intensive de ressources

Option 3 : Modèle hybride (recommandé)

┌─────────────────────────────────────────────────────────┐
│              Équipe centrale de plateforme MLOps         │
│  (Infrastructure, Outils, Normes, Support)              │
└─────────────────────────────────────────────────────────┘
                          │
    ┌─────────────────────┼─────────────────────┐
    ▼                     ▼                     ▼
┌───────────┐       ┌───────────┐       ┌───────────┐
│ Produit   │       │ Produit   │       │ Produit   │
│ Équipe A  │       │ Équipe B  │       │ Équipe C  │
│           │       │           │       │           │
│ Ing. ML ◄──┼───────┼──► Outils │◄──────┼─► Ing. ML │
│           │       │   partagés │       │           │
└───────────┘       └───────────┘       └───────────┘

Matrice des responsabilités

Matrice RACI pour projet ML

Activité	Scientifique des données	Ingénieur ML	Ingénieur MLOps	Ingénieur des données
Collecte de données	C	I	I	R/A
Ingénierie des caractéristiques	R/A	C	I	C
Développement de modèle	R/A	C	I	I
Pipeline de formation	C	R/A	C	I
Déploiement de modèle	I	C	R/A	I
Surveillance	I	C	R/A	C
Infrastructure	I	I	R/A	I

Légende : R = Responsable, A = Responsable final, C = Consulté, I = Informé

Points de collaboration

Transfert de données (DataOps → MLOps)

# Exemple : Contrat de données entre DataOps et MLOps
data_contract:
  name: customer_features
  version: 1.2.0
  owner: data-engineering@company.com
  
  schema:
    customer_id:
      type: string
      nullable: false
      pattern: "^CUS-[0-9]{8}$"
    
    age:
      type: integer
      nullable: false
      min: 18
      max: 120
    
    total_purchases:
      type: float
      nullable: false
      min: 0.0
  
  sla:
    freshness: 1 hour
    availability: 99.9%
    
  delivery:
    format: parquet
    location: s3://data-lake/features/customer/
    update_frequency: hourly

Transfert de déploiement (MLOps → DevOps)

# Exemple : Spécification de déploiement de modèle
model_deployment:
  name: customer-churn-model
  version: 2.1.0
  
  container:
    image: mlplatform/models:customer-churn-v2.1.0
    resources:
      cpu: "2"
      memory: "4Gi"
      gpu: "0"
    
  scaling:
    min_replicas: 2
    max_replicas: 10
    target_cpu_utilization: 70%
    
  endpoints:
    health: /health
    predict: /predict
    metrics: /metrics
    
  monitoring:
    latency_p99_threshold_ms: 100
    error_rate_threshold: 0.01

Points clés à retenir

Résumé

DevOps se concentre sur la livraison d'applications - MLOps étend cela aux modèles
DataOps se concentre sur la qualité des données - MLOps dépend de données propres et versionnées
MLOps combine les deux et ajoute des pratiques spécifiques au ML (suivi des expériences, versionnage des modèles)
La structure de l'équipe doit correspondre à la maturité et à la taille de l'organisation
Des interfaces claires entre les équipes préviennent les goulots d'étranglement et la confusion

Exercice pratique

Créez un document de comparaison simple pour votre organisation :

Listez les pratiques DevOps actuelles
Listez les pratiques DataOps actuelles (le cas échéant)
Identifiez les lacunes pour la mise en œuvre de MLOps
Proposez des changements de structure d'équipe

Suivant : Chapitre 3 : Le cycle de vie du ML

Comprendre le paysage des Ops​

Aperçu de la comparaison​

Tableau de comparaison détaillé​

DevOps : La fondation​

Pratiques fondamentales de DevOps​

Outils DevOps​

DataOps : Gestion des pipelines de données​

Pratiques fondamentales de DataOps​

Outils DataOps​

MLOps : L'intersection​

Ce que MLOps ajoute​

Défis spécifiques à MLOps​

Structures d'équipe​

Option 1 : Équipe MLOps centralisée​

Option 2 : Ingénieurs MLOps intégrés​

Option 3 : Modèle hybride (recommandé)​

Matrice des responsabilités​

Matrice RACI pour projet ML​

Points de collaboration​

Transfert de données (DataOps → MLOps)​

Transfert de déploiement (MLOps → DevOps)​

Points clés à retenir​

Exercice pratique​