Cours Complet Data Engineering

Ingestion des Données

L'ingestion de données est la première étape critique de tout pipeline de données. Elle consiste à collecter, recevoir et stocker des données provenant de diverses sources dans un système centralisé.

## Types de Données

### Données Transactionnelles (OLTP)
Les données transactionnelles sont générées par les systèmes métiers en temps réel. Elles représentent les opérations quotidiennes de l'entreprise.

Caractéristiques principales :
- Volume : Faible à moyen (GB/jour)
- Vélocité : Haute (millisecondes)
- Structure : Hautement structurée avec schéma fixe
- Latence requise : Temps réel ou quasi temps réel
- Qualité : Élevée (validation en temps réel)

Sources typiques :
- Systèmes CRM et ERP
- Applications e-commerce
- Systèmes bancaires
- Applications mobiles
- Capteurs IoT

Outils recommandés :
- CDC (Change Data Capture) : Debezium, AWS DMS, Oracle GoldenGate
- API/Webhooks : REST APIs, GraphQL, WebSockets
- Message Queues : RabbitMQ, AWS SQS, Apache Kafka
- ETL traditionnel : Informatica, Talend, DataStage

### Données Analytiques (OLAP)
Les données analytiques sont agrégées et historiques, optimisées pour l'analyse et le reporting.

Caractéristiques principales :
- Volume : Moyen à très élevé (TB/jour)
- Vélocité : Basse à moyenne (heures/jours)
- Structure : Structurée à semi-structurée
- Latence acceptable : Heures à jours
- Qualité : Variable selon la source

Sources typiques :
- Data warehouses existants
- Systèmes de reporting
- Données historiques
- Agrégations métier
- Données externes (APIs publiques)

Outils recommandés :
- ETL/ELT : Apache Airflow + DBT, Matillion, Talend
- Batch Processing : Apache Spark, Hadoop MapReduce
- Data Warehouses : Snowflake, BigQuery, Redshift
- Data Lakes : S3, Azure Data Lake, GCS

## Modes d'Ingestion

### Batch Processing

Le traitement par lots est la méthode traditionnelle d'ingestion de données. Il consiste à traiter de grands volumes de données à intervalles réguliers.

Avantages :
- Économique : Coût par unité de données très faible
- Simple : Mise en œuvre et maintenance faciles
- Idempotent : Garantit la cohérence des données
- Robuste : Retry et recovery simples
- Prévisible : Charge système planifiée

Inconvénients :
- Latence élevée : Données potentiellement obsolètes
- Pics de charge : Utilisation intensive des ressources
- Complexité temporelle : Gestion des dépendances temporelles
- Rigidité : Difficile d'ajuster la fréquence

Cas d'usage optimal :
- Rapports journaliers/mensuels
- Agrégations historiques
- ML training sur données complètes
- Migrations de données
- Nettoyage et transformation en masse

Technologies :
- Orchestration : Apache Airflow, Dagster, Prefect, Luigi
- Processing : Apache Spark, Hadoop MapReduce, AWS Glue
- Stockage temporaire : HDFS, S3, Azure Data Lake
- Scheduling : Cron, Windows Task Scheduler, Kubernetes CronJobs

Métriques de performance :
- Coût : €€ (2/5) - Économique pour grands volumes
- Complexité : ★★ (2/5) - Simple à mettre en œuvre
- Latence : 1h-24h selon la fréquence
- Throughput : TB/jour selon l'infrastructure
- Scalabilité : Excellente (horizontale facile)

### Streaming/Real-time

Le traitement en streaming traite les données au fil de l'eau, permettant une réactivité immédiate.

Avantages :
- Latence minimale : Données disponibles en millisecondes
- Toujours à jour : Informations en temps réel
- Réactivité : Réaction immédiate aux événements
- Charge distribuée : Traitement continu et équilibré
- Flexibilité : Adaptation dynamique aux changements

Inconvénients :
- Coût élevé : Infrastructure 24/7 nécessaire
- Complexité : Gestion d'état et exactly-once delivery
- Debugging difficile : Problèmes difficiles à reproduire
- Expertise requise : Compétences spécialisées nécessaires
- Gestion d'état : Complexité de la persistance d'état

Cas d'usage optimal :
- Détection de fraude en temps réel
- Recommandations dynamiques
- Monitoring et alerting
- IoT et capteurs
- Trading algorithmique
- Analyse de sentiment

Technologies :
- Message Brokers : Apache Kafka, Apache Pulsar, AWS Kinesis
- Stream Processing : Apache Flink, Spark Streaming, Kafka Streams
- CEP (Complex Event Processing) : Esper, WSO2, Apache Beam
- Real-time Analytics : Apache Druid, ClickHouse, TimescaleDB

Métriques de performance :
- Coût : €€€€€ (5/5) - Infrastructure 24/7
- Complexité : ★★★★★ (5/5) - Très complexe
- Latence : <1s (millisecondes)
- Throughput : Millions d'événements/seconde
- Scalabilité : Complexe mais possible

## Comparaison Batch vs Streaming

| Critère | Batch | Streaming | Hybride (Lambda/Kappa) |
|---------|-------|-----------|------------------------|
| Latence | Heures-Jours | Millisecondes-Secondes | Variable selon layer |
| Coût | €€ (2/5) | €€€€€ (5/5) | €€€€ (4/5) |
| Complexité | Simple | Complexe | Très complexe |
| Scalabilité | Horizontale facile | Horizontale complexe | Selon architecture |
| Cas d'erreur | Rejeu facile | Rejeu complexe | Dépend du layer |
| État | Stateless | Stateful | Mixte |
| Débutant | Recommandé | Éviter | Intermédiaire |
| Expert | Utiliser si approprié | Recommandé | Recommandé |

## Architecture Hybride : Lambda et Kappa

### Architecture Lambda
L'architecture Lambda combine les approches batch et streaming pour offrir le meilleur des deux mondes.

Principe :
- Speed Layer : Traitement en streaming pour la latence
- Batch Layer : Traitement par lots pour la précision
- Serving Layer : Fusion des résultats pour la cohérence

Avantages :
- Latence faible + précision élevée
- Flexibilité dans le choix des technologies
- Robustesse et fiabilité

Inconvénients :
- Complexité de maintenance
- Duplication de logique métier
- Coût d'infrastructure élevé

### Architecture Kappa
L'architecture Kappa traite tout en streaming, simplifiant l'architecture.

Principe :
- Un seul pipeline de streaming
- Reprocessing des données historiques si nécessaire
- Logique métier centralisée

Avantages :
- Simplicité conceptuelle
- Maintenance plus facile
- Cohérence des données

Inconvénients :
- Complexité technique du streaming
- Gestion des états complexes
- Expertise requise

## Choix de l'Architecture

### Critères de décision

1. Latence requise
- < 1 minute → Streaming obligatoire
- 1 minute - 1 heure → Batch ou streaming selon le budget
- > 1 heure → Batch recommandé

2. Volume de données
- < 1 GB/jour → Batch simple
- 1-100 GB/jour → Batch avancé ou streaming simple
- > 100 GB/jour → Streaming ou architecture hybride

3. Budget disponible
- Faible → Batch uniquement
- Moyen → Batch + streaming simple
- Élevé → Architecture hybride complète

4. Expertise de l'équipe
- Débutant → Batch uniquement
- Intermédiaire → Batch + streaming simple
- Expert → Architecture hybride

### Recommandations par secteur

E-commerce :
- Recommandations : Streaming (latence < 100ms)
- Analytics : Batch (rapports journaliers)
- Fraude : Streaming (détection temps réel)

Finance :
- Trading : Streaming (latence < 1ms)
- Reporting : Batch (conformité réglementaire)
- Risk : Streaming + Batch (hybride)

IoT :
- Monitoring : Streaming (alertes temps réel)
- Analytics : Batch (agrégations historiques)
- Maintenance : Streaming (prédictif)

## Outils et Technologies

### Écosystème Open Source

Apache Kafka
- Message broker distribué
- Haute disponibilité et scalabilité
- Idéal pour le streaming
- Écosystème riche (Kafka Streams, KSQL)

Apache Flink
- Moteur de streaming unifié
- Gestion d'état avancée
- Exactly-once semantics
- Performance excellente

Apache Spark
- Traitement batch et streaming
- Écosystème ML intégré
- Facile à utiliser
- Large communauté

### Solutions Cloud

AWS :
- Kinesis (streaming)
- Glue (ETL)
- DMS (migration)
- SQS/SNS (messaging)

Azure :
- Event Hubs (streaming)
- Data Factory (ETL)
- Stream Analytics
- Service Bus

GCP :
- Pub/Sub (messaging)
- Dataflow (streaming)
- Dataproc (Spark)
- BigQuery (warehouse)

## Bonnes Pratiques

### 1. Gestion des Erreurs
- Implémenter des mécanismes de retry
- Utiliser des dead letter queues
- Monitorer les échecs d'ingestion
- Avoir des stratégies de fallback

### 2. Qualité des Données
- Valider les données à la source
- Implémenter des contrôles de qualité
- Gérer les données manquantes
- Documenter les transformations

### 3. Monitoring et Observabilité
- Métriques de throughput et latence
- Logs détaillés des erreurs
- Dashboards de monitoring
- Alertes automatiques

### 4. Sécurité
- Chiffrement en transit et au repos
- Authentification et autorisation
- Audit des accès
- Conformité réglementaire

## Métriques et KPIs

### Métriques Techniques
- Throughput : Données traitées par seconde
- Latence : Délai de traitement
- Disponibilité : Uptime du système
- Erreurs : Taux d'échec des jobs

### Métriques Métier
- Fréquence de mise à jour : Actualité des données
- Complétude : Pourcentage de données reçues
- Précision : Qualité des données ingérées
- Temps de valeur : Délai entre réception et utilisation

## Conclusion

L'ingestion de données est la fondation de tout système de données moderne. Le choix entre batch et streaming dépend de vos besoins en latence, budget et expertise. Une approche hybride offre souvent le meilleur compromis entre performance et coût.

Points clés à retenir :
1. Batch : Simple, économique, approprié pour la plupart des cas
2. Streaming : Complexe, coûteux, nécessaire pour la latence
3. Hybride : Meilleur des deux mondes, mais plus complexe
4. Architecture : Choisir selon les besoins métier, pas la technologie
5. Évolution : Commencer simple, évoluer selon les besoins