Fondamentaux des Données : Types, Formats et Sérialisation

En DevOps, tu passes ton temps à déplacer de la donnée. Logs, configs, métriques, backups — tout ça transite entre services, entre environnements, entre outils. Et si tu choisis le mauvais format ou que tu ignores comment fonctionne la sérialisation, tu te retrouves avec des pipelines fragiles et des bugs silencieux qui pourrissent ta prod un mardi à 3h du mat’.

🔥 Cas réel : Une boîte e-commerce perdait 15% de ses commandes dans un pipeline ETL parce que le CSV d’import encodait les prix avec des virgules décimales (format français). Le parser interprétait 12,50 comme deux colonnes. Zéro erreur levée — juste des données corrompues en silence pendant deux semaines.

Le choix du format de données n’est pas un détail technique. C’est une décision d’architecture qui impacte la fiabilité, la performance et la maintenabilité de tout ton système. Ce cours pose les fondations.

Comprendre les types et formats de données

Les données se rangent en trois familles. Les structurées suivent un schéma rigide — ta base PostgreSQL avec ses tables bien typées. Les semi-structurées sont flexibles — JSON, YAML, où chaque document peut avoir des champs différents. Les non structurées n’ont aucun schéma — images, vidéos, logs bruts.

En tant que DevOps, tu jongleras surtout entre quatre formats d’échange. Chacun a son territoire, et le problème survient quand tu utilises l’un à la place de l’autre :

• CSV : tabulaire, lisible, simple. Idéal pour les exports ponctuels et l’échange avec des non-techniques. Mais pas de typage, encodage fragile, et les virgules dans les valeurs cassent tout.
• JSON / JSONL : le couteau suisse. Lisible, flexible, universel pour les API et les configs. JSONL (un objet par ligne) est le standard pour les logs structurés — streamable, append-friendly, compatible avec les pipelines Unix.
• Parquet : stockage colonnaire compressé. Quand tu fais un SELECT AVG(cpu) sur 10 millions de lignes, Parquet ne lit que la colonne cpu. Ratio de compression typique : 10:1 par rapport au CSV. Le roi du data lake.
• Avro : format binaire avec évolution de schéma native. Le compagnon de Kafka — tu peux ajouter un champ sans casser les consumers existants.

💡 Tip DevOps : En règle générale — JSON pour les API, Parquet pour le stockage analytique, Avro pour le streaming Kafka, CSV uniquement pour l’échange ponctuel avec des humains.

Commandes essentielles

jq est ton meilleur ami pour manipuler du JSON en ligne de commande. Combiné avec les outils Unix classiques, tu peux explorer et transformer des données sans écrire une seule ligne de Python :

# Filtrer les erreurs dans des logs JSONL et afficher timestamp + message
cat app.jsonl | jq -r 'select(.level == "ERROR") | "\(.timestamp) \(.msg)"'

# Compter les occurrences par niveau de log
cat app.jsonl | jq -r '.level' | sort | uniq -c | sort -rn

# Convertir du CSV en JSON (nécessite csvkit)
csvjson servers.csv > servers.json

# Vérifier l'encodage d'un CSV avant de le parser
file -i data.csv

⚠️ Attention : jq charge chaque ligne en mémoire. Sur des fichiers de plusieurs Go, passe à duckdb qui mange du Parquet et du JSONL au petit-déjeuner.

Pour comparer les formats de sérialisation, voici un exemple concret. Les mêmes données encodées en JSON vs MessagePack (binaire) — sur un message la différence est anecdotique, mais sur des millions de messages Kafka par jour, ça change tout :

import json, msgpack

data = {"service": "api-gateway", "latency_ms": 42, "healthy": True, "replicas": 3}

json_bytes = json.dumps(data).encode()       # ~70 octets
msgpack_bytes = msgpack.packb(data)           # ~40 octets — 40% plus compact

🧠 À retenir : JSON est lisible mais verbeux. Les formats binaires (Protobuf, MessagePack, Avro) sont compacts et rapides. Lisibilité pour le debug, binaire pour la performance en prod.

Cas concret : pipeline de métriques serveur

Ton infra génère des métriques toutes les 30 secondes. Tu dois les collecter, nettoyer et stocker pour alimenter dashboards et alertes. Le flux classique :

Collecte (JSONL)  →  Transformation (Python)  →  Stockage (Parquet)
  streamable           nettoyage + typage          compressé Zstd, partitionné

Voici le cœur du pipeline. On lit du JSONL brut (facile à streamer et debugger), on nettoie, et on écrit en Parquet (compact et rapide à requêter) :

import pandas as pd
import json

# Lire les métriques JSONL brutes
metrics = []
with open("metrics-2026-03-21.jsonl") as f:
    for line in f:
        metrics.append(json.loads(line))

df = pd.DataFrame(metrics)
df['timestamp'] = pd.to_datetime(df['timestamp'])
df['cpu_percent'] = df['cpu_percent'].astype(float)
df = df.drop_duplicates(subset=['hostname', 'timestamp'])

# Écriture Parquet partitionné — stockage divisé par 10
df.to_parquet("metrics/", partition_cols=['hostname'], compression='zstd', index=False)

🔥 Cas réel : Ce pattern est standard chez les boîtes qui gèrent des centaines de serveurs. Le passage de CSV à Parquet réduit le stockage de 90% et les requêtes analytiques passent de 45 secondes à 2 secondes.

Pièges fréquents

Le CSV qui ment. Un CSV n’a pas de typage. "42" — string ou int ? "12,50" — décimale française ou deux colonnes ? Sans spécification explicite, tu joues à la roulette russe. Et l’encodage ? Un fichier Latin-1 ouvert en UTF-8 transforme tous tes accents en hiéroglyphes.

Le JSON sans validation. Tu reçois du JSON d’une API externe et tu le stockes direct. Un jour, le champ version passe de string à integer — pipeline explosé. Toujours valider les données entrantes :

from jsonschema import validate, ValidationError

schema = {
    "type": "object",
    "required": ["service", "version"],
    "properties": {
        "service": {"type": "string", "minLength": 1},
        "version": {"type": "string", "pattern": r"^\d+\.\d+\.\d+$"}
    }
}

try:
    validate({"service": "api", "version": "1.2.3"}, schema=schema)
except ValidationError as e:
    print(f"Donnée invalide : {e.message}")

Le Parquet non partitionné. Un fichier Parquet de 50 Go monolithique, c’est aussi lent qu’un CSV. Partitionne par date, par région, par ce que tu filtres le plus souvent.

Kafka sans Schema Registry. Envoyer du JSON brut dans Kafka est tentant mais dangereux. Sans registre de schémas, un champ renommé côté producer casse tous les consumers en silence.

💡 Tip DevOps : Mets en place un Schema Registry dès le premier message Kafka, pas après le premier incident. C’est comme les tests — plus tu attends, plus ça coûte cher.

Exercice pratique

Crée un mini-pipeline de conversion sur ta machine :

1. Génère un fichier servers.jsonl avec 10 serveurs (hostname, ip, cpu_percent, memory_percent, timestamp)
2. Écris un script Python qui lit ce JSONL, filtre les serveurs avec un CPU > 80%, et écrit le résultat en Parquet avec compression Zstd
3. Relis le Parquet avec pandas et affiche les stats : moyenne CPU, serveur le plus chargé
4. Compare la taille du fichier JSONL vs Parquet

Voici le squelette pour démarrer :

# Génère le JSONL de test
python3 -c "
import json, random
from datetime import datetime
for i in range(10):
    print(json.dumps({
        'hostname': f'srv-{i:02d}',
        'ip': f'10.0.1.{i+1}',
        'cpu_percent': round(random.uniform(10, 95), 1),
        'memory_percent': round(random.uniform(20, 90), 1),
        'timestamp': datetime.now().isoformat()
    }))
" > servers.jsonl

Bonus : ajoute une validation JSON Schema avant l’écriture Parquet. Tout serveur avec un champ manquant ou un type incorrect doit être loggué et écarté du résultat final.

À retenir

🧠 Les fondamentaux à graver :

• CSV → simple mais fragile. Échanges ponctuels uniquement, jamais en pipeline critique
• JSON/JSONL → universel et lisible. JSONL pour les logs et le streaming léger
• Parquet → roi du stockage analytique. Compression 10:1, lecture sélective par colonne. Ton format par défaut dès que ça dépasse quelques Mo
• Avro → compagnon de Kafka. Évolution de schéma native, indispensable en streaming
• Valide toujours les données entrantes — un pipeline sans validation est une bombe à retardement
• Le format dépend du contexte : lisibilité pour le debug, binaire pour la prod, colonnaire pour l’analytique

Dans le prochain cours, on passe aux pipelines ETL — comment orchestrer le mouvement de toutes ces données de manière fiable et automatisée.