Exportations multiples et décharges importantes

1) Quand vous avez besoin de « grandes » exportations et ce qui est important

• Cohérence des données (snapshot/point dans le temps).
• Passage en volume (écriture/lecture parallèle, sérialisation en continu).
• Renouvelable (resumable) et livraison partielle.
• Intégrité (checksum) et vérifiabilité (manifeste).
• Sécurité/PII (masquage, cryptage, contrôle d'accès).
• Gestion des coûts (compression, temporisation, CDN, TTL).

2) Formats de données : avantages/inconvénients

CSV - compact, rapide à écrire/lire ; inconvénients : blindage, types perdus. Bon pour les rapports tabulaires.
JSON Lines (JSONL) - par ligne par objet, pratique pour le streaming et l'échantillonnage partiel ; inconvénients : volume.
Parquet/Avro - formats de colonne/circuit, compression et prédicate pushdown ; idéal pour l'analyse et le big data.
Mixed : JSONL pour le téléchargement API → la conversion hors ligne vers Parquet.

Compression : 'gzip '/' zstd' (mieux). Pour de très grands volumes - archives split (128-512 Mo par pièce ~).

3) Cohérence : comment obtenir un « instantané »

OBD : Isolation transactionnelle REPETABLE READ/SNAPSHOT ; pour les threads, les slots logiques de réplication ou la marque « watermark » (max. 'updated _ at'/version).
Event sourcing : export par le journal offset.
Tranches : exportation « complète » + « delta » (déchargement ultérieur des modifications depuis 'watermark').

4) Partitionnement en morceaux (multipart/chunking)

4. 1 espèces « multipart »

Upload (à nous) : multipart/form-data (petits fichiers), S3 Multipart Upload (MPU )/GCS Resumable (grands).
Download (de nous) : HTTP Range ('bytes = start-end'), 'multipart/byteranges' (plusieurs gammes dans la même réponse), 'zip of parts', répertoires dans l'objet store.

4. 2 Stratégies de partitionnement

Taille (par exemple 256 Mo par pièce).
Par clé/date (chardante par 'tenant _ id', 'YYYY/MM/DD').
Par table/entité (fichiers individuels par type).

Équilibre : Les parties 64-512 Mo sont bien téléchargées en parallèle et ne surchauffent pas la mémoire.

5) Architecture d'exportation API (modèle asynchrone)

1. 'POST/exports' → une tâche dans la file d'attente (métadonnées : format, filtres, chiffrement, durée de vie).

2. Les workers construisent snapshot, effacent les données et écrivent les parties dans le stockage des objets.

3. Génère un manifeste (JSON) avec une liste de pièces, des tailles, checksum, une version de schéma.

4. 'GET/exports/{ id}' retourne l'état et le ou les liens sur les parties/pré-signées de l'URL.

5. `GET /exports/{id}/manifest. json 'est une machine de vérité pour la vérification/distribution.

json
{
"export_id": "exp_2025_10_31_001",
"created_at": "2025-10-31T14:23:00Z",
"schema": "orders_v3",
"format": "parquet+zstd",
"parts": [
{"name":"part-00000. parquet. zst","size":268435456,"sha256":"...","url":"...","range":"bytes=0-268435455"},
{"name":"part-00001. parquet. zst","size":241172480,"sha256":"...","url":"..."}
],
"total_bytes": 509607936,
"encryption": {"type":"AES-256-GCM","key_id":"kms/keys/exp"},
"watermark": {"type":"updated_at","value":"2025-10-31T00:00:00Z"}
}

6) Décharges renouvelables (resumable)

HTTP Range : le client rattrape la « queue » du fichier : 'Range : bytes = 241172480-'.
Plusieurs gammes : 'Range : bytes = 0-9992000-2999' → la réponse 'Content-Type : multipart/byteranges'.
Stratégie client : « workers » parallèles par pièce, vérification 'sha256' de chacun, retraits avec backoff exponentiel.
CDN : prise en charge de Range, mise en tampon désactivée des grandes réponses.

7) Grands téléchargements à nous (resumable upload)

S3 Multipart Upload : les clients chargent des pièces (5-5000), le serveur recueille 'CompleteMultipartUpload'.
GCS Resumable : une session, décalage - le client peut continuer avec 'Content-Range'.
TUS (protocole) est un apload indépendant renouvelable sur HTTP.

Modèle B2B : nous donnons l'URL pré-signée pour l'apload de pièces directement à la store et les métadonnées à notre API.

8) Compression, cryptage, intégrité

Compression : 'zstd'est préférable (meilleur ratio/vitesse). Compressez chaque pièce séparément (il est plus pratique de reprendre/mettre en cache).

• Sur le fil : TLS 1. 2+.
• Au repos : serveur-side KMS (SSE-KMS) ou client-side (AES-256-GCM) avec emballage de clé (key wrapping).
• Ne mettez jamais la clé « crue » dans le manifeste.
• Checksum : Minimum de SHA-256 par partie + commun pour l'ensemble. Vérifiez sur le client avant ack.

9) Intégration avec le périmètre : NGINX/CDN

nginx server {
listen 443 ssl http2;
server_name downloads. example. com;

location /exports/ {
proxy_buffering off;
proxy_request_buffering off;
proxy_read_timeout 3600s;
add_header Accept-Ranges bytes;
proxy_pass http://export-backend;
}
}

• `Content-Disposition: attachment; filename="export_2025-10-31_part-00000. parquet. zst"`
• « ETag »/« If-Range » pour un rattrapage correct.
• 'Cache-Control '(par exemple' private, max-age = 3600 ') pour les décharges personnelles.

10) Sécurité et conformité

Authentification/autorisation : délivrance d'exportations uniquement au propriétaire/aux rôles ; références temporelles (pré-signées) avec une TTL courte.
PII : masquage/pseudonymisation ; le manifeste ne contient que des champs techniques.
RGPD/régulateurs locaux : suppression des exportations par TTL, audit des téléchargements, interdiction de la délivrance croisée régionale sans motif.
Rate limiting & quotas : limiter le nombre d'exportations simultanées et le volume total par jour/mois (per-tenant).
Anti-scraping : SAR/filtres de bot pour la délivrance de références, limitation des plages (maxi parties parallèles).

11) Observabilité et exploitation

• `export_jobs_total{status}` (queued/running/succeeded/failed/expired)
• `export_bytes_total`, `export_part_duration_ms{p50,p95,p99}`
• `download_range_requests_total`, `resumes_total`, `checksum_fail_total`
• `storage_cost_estimate` и `egress_bytes_cdn`

• Qui a créé export, filtres, watermark, liste de téléchargement (IP/UA/time).
• Hachage des pièces et rapprochement côté client (confirmation).

• Dormez sur les étapes : snapshot → serialize → upload part → finalize.

12) Productivité et coût

Parallèle : générer plusieurs parties simultanément (N workers), mais limiter I/O.
Mémoire : sérialisation en continu (itérateurs, curseurs OBD, cuves de 4 à 16 Mo).
Dedup : pour les exportations souvent répétées, un cache-pièce intelligent par filtre/hachage.
CDN : bénéfique pour les ensembles publics « généraux » ; pour les personnels - attention (sécurité/PII).

13) Exemples d'interfaces

13. 1 Création d'exportation (REST)

http
POST /exports
Content-Type: application/json
Authorization: Bearer <token>

{
"format": "parquet+zstd",
"filters": {"date_from":"2025-10-01","date_to":"2025-10-31","tenant":"acme"},
"split_size_mb": 256,
"encryption": {"mode":"server-side-kms","key_id":"kms/keys/exp"}
}

json
{
"id":"exp_2025_10_31_001",
"status":"queued",
"estimated_parts": 12,
"manifest_url": "/exports/exp_2025_10_31_001/manifest. json"
}

13. 2 Délivrance d'une partie avec Range

http
GET /exports/exp_.../part-00003. parquet. zst
Range: bytes=1048576-

13. 3 Pseudo-code de worker

pseudo snapshot = db. begin_snapshot()
for shard in plan_shards(snapshot):
part_stream = encode_stream(shard. rows, format="parquet", compress="zstd")
url = object_store. upload_stream(part_stream, part_name, encryption=KMS)
manifest. add(part_name, size, sha256, url)
write_manifest(manifest)

14) Modèles d'exportation delta

Exportation complète une fois dans N (jour/semaine) + delta toutes les heures par 'updated _ at> watermark'.
Côté consommateur : appliquer les deltas dans l'ordre en vérifiant 'version '/' seq'.
Gardez le dernier watermark dans le consommateur et dans le manifeste.

15) Anti-modèles

Génération d'exportation dans la requête (synchrone) - temporisation et OOM.
Un fichier géant sans partitionnement est l'impossibilité de reprendre/injecter en parallèle.
L'absence de checksum et de manifeste ne peut pas être prouvée d'intégrité.
Émission de références publiques permanentes aux données personnelles.
Tampon SSE/CDN ou Range désactivé - brise le « chargement ».
Exporte des données « sales » (pas de snapshot/isolation).

16) Chèque de mise en œuvre

• Format et compression : CSV/JSONL/Parquet + 'zstd/gzip'.
• Cohérence : snapshot transactionnel ou watermark/offset.
• Partition : parties 64-512 Mo, génération et téléchargement parallèles.
• Manifeste : liste des parties, tailles, SHA-256, version du schéma, watermark.
• Reprise : HTTP Range, support « multipart/byteranges », retraits client.
• Sécurité : URL pré-signées, TTL, cryptage (KMS/AEAD), masquage PII.
• Limites/quotas : per-tenant, volumes journaliers, nombre de job actifs.
• Observabilité : métriques de job/parties, audit des téléchargements, alertes sur checksum-fail.
• Coût : CDN pour les ensembles publics, TTL et auto-cleanup en store.
• Runbooks/Game Days : falaises du réseau, indisponibilité du store, surchauffe OBD, panne KMS.

17) Game Days (playbooks)

Rupture du réseau lors du téléchargement : le client doit continuer avec 'Range'.
Échec du chargement d'une seule pièce : rétraction de la pièce sans recentrer toutes les exportations.
Chute de l'ouvrier : le joba reprend avec le dernier chank non confirmé.
Pas de KMS : dégradation sûre (pause de génération, pas de sortie non cryptée).
La croissance des données × 2 : vérifier le temps de génération, redistribuer le parallélisme, ne pas tuer la base de données.

18) Résultats

Les grands décharges robustes sont une architecture asynchrone + partitionnement + reprise + intégrité vérifiable. Faites un snapshot, écrivez des morceaux en parallèle, publiez un manifeste avec checksum, maintenez HTTP Range et des liens à courte durée de vie. Pensez à la sécurité, aux limites et à l'observabilité - et les exportations de gigaoctets ne seront plus un cauchemar nocturne pour les équipes et les utilisateurs.