Global Earthquake Monitor

J'ai d'abord créé un lakehouse nommé earthquakes_lakehouse pour stocker les données sismiques brutes de l'API USGS. C'est la base qui permet de structurer les données selon l'architecture Medallion. L'ingestion se fait depuis un notebook du lakehouse, en Python, via l'appel :

GET https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&starttime=2014-01-01&endtime=2014-01-02

Les données sont ensuite stockées en tables Delta Lake, qui apportent transactions ACID, contrôle du schéma et time travel — un format fiable et scalable pour la suite.

Un script Python récupère les séismes depuis l'API et les stocke dans la couche Bronze, sur une fenêtre glissante de 7 jours pour garder un jeu de données à jour.

1. 01Dates dynamiques — start_date correspond à il y a sept jours et end_date à hier ; les deux sont ensuite paramétrées depuis Data Factory.
2. 02Requête API — le script construit l'URL avec ces dates, demande du GeoJSON et ne conserve que le champ features, qui contient les événements.
3. 03Stockage dans le lakehouse — en cas de succès, les événements sont enregistrés en JSON dans /lakehouse/default/Files/ avec un nom daté (YYYY-MM-DD_earthquake_data.json).

1.1.png

Le fichier JSON est ensuite chargé dans un DataFrame Spark pour affiner progressivement les données à travers les couches Medallion.

1.2-1.png

Dans la couche Silver, les événements bruts sont nettoyés et structurés : les attributs pertinents sont extraits et des transformations utiles sont appliquées.

1. 01Extraction des champs — le JSON imbriqué est aplati et renommé, en se concentrant sur la localisation (latitude, longitude, altitude), la magnitude, la significativité, les horodatages et les descriptions.
2. 02Restructuration — geometry.coordinates est éclaté en longitude, latitude et altitude ; properties fournit le titre, le lieu, la significativité (sig), la magnitude (mag), le type de magnitude (magType) et les horodatages.

2.1-1.png

1. 01Horodatages lisibles — time et updated sont stockés en millisecondes epoch Unix et convertis en timestamps standards.
2. 02Table Silver — les données nettoyées sont persistées dans earthquake_events_silver en mode append, pour ajouter les nouveaux événements sans écraser l'historique.
3. 03Interrogation — la table Silver peut être explorée en SQL directement dans le lakehouse.

3.1-2.png3.2.png

• →Seuls les événements récents (postérieurs à start_date) sont lus depuis Silver.
• →Le code pays est déduit de la latitude et de la longitude avec la bibliothèque reverse_geocoder.
• →Comme Spark travaille sur des données distribuées, get_country_code est enregistrée comme UDF pour être utilisée dans les transformations.

4.png

1. 01Code pays — get_country_code_udf ajoute une colonne country_code pour l'analyse géographique.
2. 02Classes de significativité — les événements sont classés Low (sig < 100), Moderate (100 ≤ sig < 500) ou High (sig ≥ 500).
3. 03Table Gold — le DataFrame affiné est ajouté à earthquake_events_gold.

4.2-1.png4.3.png

Un pipeline Data Factory exécute chaque jour les trois notebooks, dans l'ordre :

1. 01Bronze Notebook — lance l'ingestion brute avec des paramètres dynamiques : start_date → hier, end_date → aujourd'hui.
2. 02Silver Notebook — enchaîné en cas de succès, reçoit start_date.
3. 03Gold Notebook — enchaîné en cas de succès, reçoit start_date.

5.png

Tout le workflow est désormais automatisé : Bronze, Silver et Gold s'exécutent séquentiellement selon une planification, et des données fraîches sont disponibles chaque jour sans intervention manuelle.

Au-dessus de la couche Gold, un modèle sémantique définit les relations et les mesures calculées pour rendre l'analyse et la visualisation dans Power BI efficaces.

6.1.png6.2-2.png

Le rapport final visualise l'activité sismique mondiale. On filtre par période et par niveau de significativité (High, Moderate, Low) ; la carte dimensionne chaque bulle selon la significativité, et des KPI affichent le nombre total de séismes et la significativité maximale.

dh3.png