Le principe de base : reproduire la prod en local

La question que je me pose avant d'ajouter un outil : est-ce que ce setup me permettrait de bosser sur un vrai pipeline de prod sans rien réapprendre ?

Ce n'est pas du perfectionnisme. C'est du pragmatisme. Quand tu arrives en stage ou en poste, la douleur vient rarement du code, elle vient de l'environnement. Docker qui se comporte différemment en local, des dépendances qui divergent, un pipeline qui "marche sur ma machine". Autant l'éviter dès le départ.

DuckDB : la base de données qui n'a pas besoin de serveur

Ce que c'est : un moteur OLAP embarqué, qui tourne directement dans le process Python. Pas de daemon, pas de connexion réseau, pas de configuration.

Pourquoi il est là : J'ai découvert DuckDB en cherchant une alternative à Pandas sur des gros volumes. Mais ce qui m'a convaincu de l'intégrer dans mon stack local, c'est la friction quasi-nulle. pip install duckdb, et tu requêtes du Parquet, du CSV, ou de la mémoire en SQL. C'est ça.

import duckdb
conn = duckdb.connect()
result = conn.execute(
        """ SELECT
                pickup_location_id,
                COUNT(*) AS nb_courses,
                AVG(fare_amount) AS tarif_moyen
            FROM 'data/yellow_taxi_2023.parquet'
            GROUP BY 1
            ORDER BY 2 DESC
            LIMIT 10
        """
).df()

Ce qu'il remplace : Pandas pour les explorations sur des fichiers > 1M lignes. SQLite pour les petites bases locales. Un Postgres local pour les développements légers.

Limite honnête : DuckDB n'est pas fait pour de la donnée transactionnelle. Et sur des jointures massives avec spill sur disque, il peut surprendre. Mais pour du local analytique, il fait le job mieux que tout le reste.

dbt-core : la transformation comme du vrai code

Ce que c'est : un framework de transformation SQL, avec gestion de dépendances, tests, documentation et lineage.

Pourquoi il est là : Parce qu'un pipeline de transformation qui vit dans un notebook n'existe pas vraiment. Il ne peut pas être revu, testé, versionné proprement, ou repris par quelqu'un d'autre. dbt force une structure : des modèles SQL, un DAG de dépendances, des tests sur les données.

models/
├── staging/ 
        └── stg_taxi_trips.sql
└── marts/
        └── mart_revenue_by_zone.sql

-- models/marts/mart_revenue_by_zone.sql
SELECT
    pickup_location_id,
    DATE_TRUNC('month', pickup_datetime) AS mois,
    COUNT(*) AS nb_courses,
    SUM(total_amount) AS revenu_total
FROM {{ ref('stg_taxi_trips') }}
GROUP BY 1, 2

Ce qu'il apporte concrètement : La commande dbt test qui plante avant que les données corrompues remontent en prod. Le dbt docs generate qui produit une documentation vivante. Et surtout, la discipline de traiter une transformation SQL comme un artefact de code — pas comme un bout de requête oublié dans un coin.

Avec DuckDB : dbt-core + dbt-duckdb, c'est le combo local parfait. Aucun serveur, tout en fichiers, reproductible en 30 secondes sur une nouvelle machine.

Prefect — l'orchestration sans la douleur d'Airflow

Ce que c'est : un orchestrateur de workflows Python. Tu décores tes fonctions, tu définis un flow, tu l'exécutes localement ou tu le déploies.

Pourquoi il est là : Airflow est puissant. Airflow est aussi un enfer à installer localement. Prefect a fait un choix différent : le code d'abord, l'infrastructure ensuite.

from prefect import flow, task

@task
def extraire_donnees(source: str) -> pd.DataFrame: 
    return pd.read_parquet(source)

@task
def charger_donnees(df: pd.DataFrame, destination: str):
    df.to_parquet(destination)

@flow(name="pipeline-taxi")
def pipeline(source: str, destination: str):
    df = extraire_donnees(source)
    charger_donnees(df, destination)

if name == "main":
    pipeline(source="data/raw/", destination="data/processed/")

Ce qu'il apporte : La visibilité sur les runs, la gestion des retries, les logs structurés — sans avoir à déployer un cluster. En local, prefect server start lance une UI complète en une commande.

Limite honnête : Si ton pipeline tient en un script Python de 50 lignes, Prefect est overkill. Je l'utilise dès que j'ai des dépendances entre tâches, des retries nécessaires, ou que je veux tracer l'exécution.

Docker : la frontière entre "ça marche" et "ça marchera"

Ce que c'est : la containerisation. Tu packages ton environnement, et il tourne pareil partout.

Pourquoi il est là : Je ne l'utilise pas pour chaque script. Je l'utilise pour tout ce qui a vocation à sortir de mon laptop : un pipeline Prefect à déployer, un service qui expose une API, un benchmark reproductible.

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
CMD ["python", "pipeline.py"]

Ce qu'il règle : Le fameux ça marche chez moi. Si ton pipeline tourne dans un container, il tourne en CI, en prod, sur la machine d'un collègue. La reproductibilité n'est plus un espoir, c'est une propriété.

Ce qui n'est pas dans la stack et pourquoi

Jupyter Notebooks : Je les utilise encore pour l'exploration initiale. Mais dès que quelque chose doit être reproductible ou partagé, ça sort du notebook et ça entre dans la stack.

Spark en local : J'y viendrai. Mais Spark local demande des ressources, une config, et a une courbe d'apprentissage. DuckDB couvre 95% de mes besoins analytiques locaux — Spark, c'est pour les volumes où DuckDB atteint ses limites (> 100M lignes avec des transformations complexes).

Airflow : Prefect fait le job en local. Si un projet exige Airflow, j'apprends Airflow sur ce projet.

Le schéma complet

Données brutes (CSV, Parquet, JSON)
                ↓
DuckDB (requêtage, exploration)
                ↓
dbt-core (transformations SQL, tests)
                ↓
Prefect (orchestration, scheduling, retries)
                ↓
Docker (packaging, reproductibilité)
                ↓
CI/CD (GitHub Actions — article à venir)

Ce que cette stack m'a appris

Le bon environnement local n'est pas celui qui a le plus d'outils. C'est celui qui crée le moins de friction entre une idée et un pipeline qui tourne. Chaque outil dans cette stack a une raison d'être précise, et aucun ne se chevauche avec un autre.

La prochaine étape logique : ajouter GitHub Actions pour que chaque push déclenche les tests dbt et valide le pipeline. Ce sera peut-être le prochain article pour la data, sans les hacks.

Pourquoi DuckDB comme backend dbt ?

dbt a besoin d'un moteur SQL pour exécuter les transformations. En général c'est Snowflake, BigQuery, Redshift. Ces outils sont excellents en prod — mais lourds à configurer pour du dev local.

DuckDB, c'est un moteur SQL analytique embarqué. Il tourne dans un fichier .duckdb sur ton laptop. Pas de daemon, pas de port à ouvrir, pas de credentials à gérer.

Ce qu'on gagne concrètement :

• Itération rapide : pas de round-trip réseau, les requêtes répondent en millisecondes

• Environnement reproductible : le fichier .duckdb est portable

• Zéro coût : pas de compute cloud qui tourne pendant que tu développes

• Idéal pour apprendre : tu te concentres sur dbt, pas sur la config infra

Ce qu'on va construire

Un projet dbt complet branché sur DuckDB, avec un vrai dataset e-commerce Olist (~100k lignes) :

seeds (CSV Olist)
    └── models/staging (4 vues — nettoyage, typage)
            └── models/marts (1 table — agrégation métier)

Prérequis

• Python 3.11 ou 3.12 — pas 3.13+, pas 3.14 (voir ci-dessous)

• pip

• Connaissance basique de dbt (ref(), dbt run)

⚠️ Le crash qu'on a eu - Python 3.14

Avant de commencer, un point important.

Si tu as Python 3.14 installé sur ta machine, dbt --version va planter avec cette erreur :

TypeError: Metaclasses with custom tp_new are not supported.

Ce n'est pas un bug dbt — c'est une incompatibilité entre Python 3.14 (encore en beta) et protobuf, une dépendance interne de dbt. Le fix : utiliser Python 3.11.

# Vérifie ta version
python --version

# Si tu as 3.14, télécharge Python 3.11.9 sur python.org
# Puis crée ton venv en ciblant explicitement 3.11
py -3.11 -m venv .venv

On a perdu du temps là-dessus. C'est documenté ici pour que tu n'en perdes pas.

Étape 1 — Setup de l'environnement

mkdir dbt-duckdb-demo && cd dbt-duckdb-demo
py -3.11 -m venv .venv
.venv\Scripts\activate

pip install "dbt-core==1.8.9" "dbt-duckdb==1.8.4"
dbt --version

Output attendu :

Core:
  - installed: 1.8.9
Plugins:
  - duckdb: 1.8.4

Étape 2 — Initialiser le projet

dbt init dbt_duckdb_demo
cd dbt-duckdb-demo

dbt te demande quel adaptateur utiliser — choisis duckdb.

Le profiles.yml est créé automatiquement dans ~/.dbt/. Il ressemble à ça :

dbt_duckdb_demo:
  outputs:
    dev:
      type: duckdb
      path: dev.duckdb
      threads: 1
    prod:
      type: duckdb
      path: prod.duckdb
      threads: 4
  target: dev

Trois lignes qui remplacent un bloc de credentials Snowflake. Vérifie la connexion :

dbt debug

Connection test: OK — on continue.

Étape 3 — Le dataset Olist

On utilise le Brazilian E-Commerce Dataset d'Olist, disponible sur Kaggle. Un vrai dataset de production : commandes, clients, paiements d'un e-commerce brésilien.

🔗 kaggle.com/datasets/olistbr/brazilian-ecommerce

On garde 4 fichiers sur les 9 disponibles :

Copie-les dans seeds/, puis supprime les modèles d'exemple :

Remove-Item -Recurse -Force models\example
mkdir models\staging
mkdir models\marts

Charge les seeds :

dbt seed

1 of 4 OK loaded seed file main.olist_customers_dataset    [INSERT 99441 in 1.07s]
2 of 4 OK loaded seed file main.olist_order_items_dataset  [INSERT 112650 in 3.51s]
3 of 4 OK loaded seed file main.olist_order_payments_dataset [INSERT 103886 in 1.88s]
4 of 4 OK loaded seed file main.olist_orders_dataset       [INSERT 99441 in 6.14s]

Finished running 4 seeds in 12.83s.

415 418 lignes chargées. On a de quoi travailler.

Étape 4 — Les modèles staging

Le staging nettoie et type les données brutes. Une source = un modèle staging.

models/staging/stg_customers.sql

with customers as (
    select * from {{ ref('olist_customers_dataset') }}
)

select
    customer_id,
    customer_unique_id,
    customer_zip_code_prefix    as zip_code,
    customer_city               as city,
    customer_state              as state
from customers
where customer_id is not null

models/staging/stg_orders.sql

with orders as (
    select * from {{ ref('olist_orders_dataset') }}
)

select
    order_id,
    customer_id,
    order_status,
    order_purchase_timestamp::timestamp         as purchase_at,
    order_approved_at::timestamp                as approved_at,
    order_delivered_carrier_date::timestamp     as delivered_carrier_date,
    order_delivered_customer_date::timestamp    as delivered_customer_date,
    order_estimated_delivery_date::timestamp    as estimated_delivery_date
from orders
where order_id is not null

models/staging/stg_order_items.sql

with order_items as (
    select * from {{ ref('olist_order_items_dataset') }}
)

select
    order_id,
    order_item_id,
    product_id,
    seller_id,
    price::decimal(10,2)            as price,
    freight_value::decimal(10,2)    as freight_value
from order_items
where order_id is not null

models/staging/stg_order_payments.sql

with stg_order_payments as (
    select * from {{ ref('olist_order_payments_dataset') }}
)

select
    order_id,
    payment_sequential,
    payment_type,
    payment_installments,
    cast(payment_value as decimal(10,2))    as amount
from stg_order_payments
where order_id is not null

Lance le staging complet :

dbt run --select staging

Finished running 4 view models in 0.60s.
Completed successfully

4 modèles. 0.60 secondes. Zéro cloud.

Étape 5 — Le modèle mart

Le mart agrège les données staging pour répondre à une question métier : quel est le comportement d'achat par client ?

models/marts/mart_orders_summary.sql

with stg_customers as (
    select * from {{ ref('stg_customers') }}
),

stg_orders as (
    select * from {{ ref('stg_orders') }}
),

stg_order_payments as (
    select * from {{ ref('stg_order_payments') }}
)

select
    c.customer_id,
    c.customer_unique_id,
    c.zip_code,
    c.city,
    c.state,
    count(distinct o.order_id)                                          as total_orders,
    sum(p.amount)                                                       as total_amount,
    sum(
        case when o.order_status = 'delivered'
        then p.amount else 0 end
    )                                                                   as delivered_amount,
    round(
        count(distinct case when o.order_status = 'delivered'
              then o.order_id end) * 100.0
        / nullif(count(distinct o.order_id), 0)
    )                                                                   as delivery_rate_pct
from stg_customers c
left join stg_orders o on c.customer_id = o.customer_id
left join stg_order_payments p on o.order_id = p.order_id
group by c.customer_id, c.customer_unique_id, c.zip_code, c.city, c.state

dbt run --select mart_orders_summary

Finished running 1 table model in 7.18s.
Completed successfully

7 secondes pour joindre et agréger 3 tables sur ~100k lignes chacune. Sur un laptop, sans cloud.

Étape 6 — Les tests

Crée models/staging/schema.yml :

version: 2

models:
  - name: stg_customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: order_status
        tests:
          - accepted_values:
              values: ['delivered', 'shipped', 'canceled', 'unavailable',
                       'invoiced', 'processing', 'created', 'approved']

  - name: stg_order_items
    columns:
      - name: order_id
        tests:
          - not_null

  - name: stg_order_payments
    columns:
      - name: order_id
        tests:
          - not_null
      - name: amount
        tests:
          - not_null

dbt test

Finished running 7 tests in 1.23s.
Completed successfully — PASS=7 WARN=0 ERROR=0

Étape 7 — Le lineage

dbt docs generate
dbt docs serve

dbt ouvre un navigateur avec le DAG complet du projet :

Le lineage te montre visuellement que chaque modèle ne dépend que de ce qu'il doit dépendre. C'est la traçabilité de ta transformation, documentée automatiquement.

Ce qu'on a construit

Note : l'architecture complète Medallion inclut une couche intermediate entre staging et marts. On l'a volontairement omise ici pour garder le projet lisible. Elle fera l'objet d'un article dédié.

Ce que DuckDB ne remplace pas

DuckDB est excellent pour le dev local et les volumes jusqu'à quelques dizaines de millions de lignes. Ce n'est pas un entrepôt cloud donc pas de multi-utilisateurs, pas de contrôle d'accès granulaire, pas de haute disponibilité.

Pour de la prod partagée, tu brancheras dbt sur Snowflake ou BigQuery. Les modèles qu'on vient d'écrire fonctionneront sans modification — c'est exactement l'intérêt de cette stack.

Prochaine étape

Tu as une stack dbt + DuckDB qui tourne en local avec de vraies données. L'étape suivante : automatiser tout ça avec GitHub Actions pour que chaque modification de modèle soit validée et testée automatiquement avant de merger.

C'est l'article #004.

Solide comme un Loko.

Le contexte

Pandas est l'outil par défaut de tout Data Engineer Python. Fiable, connu, documenté. Mais il a une limite fondamentale : il charge tout le dataset en RAM. Chaque opération commence par matérialiser l'intégralité des données en mémoire.

DuckDB prend le contre-pied total. Il scanne les fichiers Parquet directement sur disque, colonne par colonne, sans jamais tout charger. C'est ce qu'on appelle un moteur de requêtes en place.

J'ai voulu mesurer la différence de façon rigoureuse, pas juste lire la doc. Voici les résultats bruts.

Le setup

Dataset : NYC Yellow Taxi Trip Data (Kaggle)

2 tailles testées :

• Small : 10,9M lignes - 229 MB Parquet

• Medium : 54M lignes - 1138 MB Parquet

7 opérations testées : Nous avons testés 7 opérations, lesquelles sont les suivantes :

• Chargement

• COUNT(*)

• GROUP BY simple & GROUP BY multi

• Filtre + agrégation

• Window function

• JOIN

Métriques capturées : Notre analyse s'est basé sur 3 indicateurs clés à savoir :

• le Temps d'exécution

• la RAM consommée

• et la consommation en terme de CPU

Environnement : Python 3.11 · DuckDB 1.x · Pandas 2.x · 15 Go RAM

Les Résultats

1. Sur le dataset Small de 10,9M de lignes

1. Sur le dataset Medium de 54 M de lignes

Les crashs : des observations légitimes

Deux opérations ont crashé des deux côtés. Ce n'est pas un échec de test. C'est le résultat le plus instructif.

Le bon pattern : DuckDB + Pandas ensemble

DuckDB ne remplace pas Pandas, il le complète. Le bon workflow serait :

1. DuckDB pour l'agrégation lourde : lecture Parquet, filtres, GROUP BY, agrégations

2. Pandas pour la manipulation fine : transformations Python custom, ML, visualisation

3. DuckDB retourne directement un DataFrame Pandas via .df()

# Le pattern recommande
# DuckDB fait le travail lourd, Pandas reçoit un DataFrame propre

import duckdb

result = duckdb.sql("""
    SELECT passenger_count,
           AVG(fare_amount)  AS avg_fare,
           COUNT(*)          AS nb_trips
    FROM read_parquet('data/*.parquet')
    WHERE trip_distance > 5
    GROUP BY passenger_count
    ORDER BY nb_trips DESC
""").df()  # <- retourne un DataFrame Pandas

# Ensuite tu travailles normalement avec Pandas
print(result.head())

Le verdict

Il y a un anti-pattern que je vois partout dans le monde de la data : utiliser Apache Spark pour traiter 10 000 lignes de CSV. Le framework impressionne sur le papier, il est dans le CV, alors on l'utilise — même quand un simple script pandas ferait le travail en 2 secondes avec zéro infrastructure.

J'ai failli faire la même erreur en construisant ce blog. Réflexe de dev : npx create-next-app@latest loko-labs.

Un framework React, un pipeline de build, des dépendances à maintenir. Tout ça pour... afficher du texte et appeler une API.

J'ai pris du recul. Et j'ai appliqué à mon propre projet le même principe que je défends pour les pipelines de données : la bonne complexité pour le bon problème.

Ce que la landing page devait faire

Avant de choisir un outil, un ingénieur pose la question du besoin réel. Voici la spec complète :

• Présenter Loko Labs et son positionnement

• Afficher les derniers articles publiés sur Hashnode

• Être hébergée gratuitement

• Se mettre à jour automatiquement à chaque publication

• Zéro maintenance dans le temps

L'arbitrage : Next.js vs HTML statique

Voici les trade-offs concrets que j'ai évalués :

Next.js aurait été le bon choix avec un routing complexe ou du rendu serveur. Mais pour une landing page qui appelle une API ? C'est ce qu'on appelle du over-engineering.

La stack retenue : simple, solide, portable

Voici exactement ce que j'ai utilisé - et c'est très exactement uniquement ça :

loko-labs/
    index.html    <- tout le code (HTML, CSS, JS en un seul fichier)

# Hébergement : GitHub Pages (gratuit, illimité pour les repos publics)
# Données : API GraphQL Hashnode (appelée côté client au chargement de la page)
# Domaine :  à venir, mais un fichier CNAME dans le repo suffit à le gérer

L'intégration Hashnode en 15 lignes

L'API GraphQL de Hashnode est publique. On a pas besoin de clé API pour lire les articles :

const query = `
    query {
        publication(host: "votreusername.hashnode.dev") {
            posts(first: 6) {
                edges {
                  node { title brief slug url publishedAt tags { name } }
                }
            }
        }
    }
`;

const res = await fetch('https://gql.hashnode.com/', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query })
});

const { data } = await res.json();
// -> articles frais a chaque visite, sans redéploiement

Résultat : à chaque visite, les articles sont toujours à jour sans aucun redéploiement. Pas de webhook, pas de GitHub Action, juste un fetch.

Le vrai sujet : l'ingénierie, c'est choisir

Dans le monde de la data, on souffre d'un biais systématique vers la complexité. On déploie Kubernetes parce que Netflix le fait. On adopte des frameworks parce qu'ils sont populaires, pas parce qu'ils résolvent notre problème.

Un bon ingénieur data ne se demande pas "quel outil impressionnant puis-je utiliser ?" Il se demande "quel est le minimum viable pour que ça tienne en production ?"

Ce principe s'applique exactement à un pipeline de données :

• Airflow pour un job cron quotidien ? → Un simple script Python suffit.

• Kafka pour 100 événements/jour ? → Une table PostgreSQL avec polling suffit.

• dbt pour 3 transformations simples ? → Des vues SQL directement dans la base suffisent.

• Next.js pour une landing page statique ? → Un fichier HTML suffit.

La bonne stack n'est pas celle qui impressionne — c'est celle qui résiste dans le temps avec le moins d'efforts de maintenance possible.

Et la suite ?

Cette landing page va évoluer avec Loko Labs :

• Domaine custom lokolabs.dev → un fichier CNAME dans le repo

• Compteur d'articles dynamique dans le hero

• Score Lighthouse target : 100/100

En résumé

La complexité est une dette.

Chaque framework, chaque service que tu ajoutes est une obligation de maintenance future. La vraie expertise d'un ingénieur, ce n'est pas de savoir utiliser les outils complexes — c'est de savoir quand ne pas les utiliser.

La landing page de Loko Labs a été construit avec un fichier HTML, l'API Hashnode, et GitHub Pages. Ça tourne, c'est gratuit, ça ne tombera pas en panne à 2h du matin. Solide comme un Loko.

Tags : #DataOps #Architecture #WebDev #Hashnode #GitHubPages #BonnesPratiques