GribStream Blog
Wetterdaten mit MySQL abfragen: öffentliche GribStream-Beta
Verbinden Sie gängige MySQL-Clients und -Treiber mit GribStream, verwenden Sie Ihren API-Token als Passwort und erhalten Sie Wetterdaten als normale MySQL-Zeilen.
GribStream bietet jetzt eine MySQL-kompatible Verbindung als öffentliche Beta an. Jede Programmiersprache, jedes Notebook, Kommandozeilenwerkzeug oder jede Anwendung, die sich mit MySQL verbinden kann, kann über dieselbe vertraute Schnittstelle GribStream-Wetterdaten abfragen.
Verbinden Sie sich mit mysql.gribstream.com auf Port 3307. Verwenden Sie Ihren GribStream-API-Token als Passwort, wählen Sie ein Dataset wie gfs als Datenbank und erhalten Sie die Ergebnisse als normale MySQL-Zeilen.
Dies ist eine öffentliche Beta. Wir empfehlen diese Verbindung noch nicht für Produktions-Workloads. Das unterstützte SQL kann sich ändern, während wir aus der tatsächlichen Nutzung lernen. Bitte melden Sie Probleme oder senden Sie Feedback, oder besuchen Sie uns auf Discord.
Eine kurze MySQL-Sitzung
Sie müssen weder einen MySQL-Server installieren noch Wetterdaten importieren. Mit dem MySQL-Kommandozeilenclient genügt folgende Verbindung:
mysql --host=mysql.gribstream.com \
--port=3307 \
--user=gribstream \
--password
Der Client fragt nach Ihrem API-Token. Nach der Verbindung erscheinen die Datasets als Datenbanken. Die folgende Ausgabe ist gekürzt:
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| aifsoper |
| era5 |
| gfs |
| hrrr |
| ifsoper |
| ... |
+--------------------+
mysql> USE gfs;
Database changed
Jedes Dataset besitzt eine Tabelle timeseries für die beste verfügbare Vorhersage zu jedem Gültigkeitszeitpunkt und eine Tabelle runs für bestimmte Modellläufe. Die verfügbaren Wetterparameter erscheinen als Spalten. Die übliche Schemaabfrage zeigt Zeit- und Ortsfelder neben den Dataset-spezifischen Werten:
mysql> SHOW COLUMNS FROM gfs.timeseries;
+-----------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+-------------+------+-----+---------+-------+
| forecasted_at | datetime(6) | YES | | NULL | |
| forecasted_time | datetime(6) | YES | | NULL | |
| lat | double | YES | | NULL | |
| lon | double | YES | | NULL | |
| lead_time | double | YES | | NULL | |
| ... | ... | ... | ... | ... | ... |
| tmp_2_m_above_ground | double | YES | | NULL | |
| ... | ... | ... | ... | ... | ... |
+-----------------------+-------------+------+-----+---------+-------+
Die Ausgabe ist gekürzt. tmp_2_m_above_ground bezeichnet die GFS-Temperatur in 2 m Höhe. Sie wird in der nativen Einheit des Modells, Kelvin, ausgegeben. Diese numerische Spalte lässt sich auswählen, umrechnen, filtern und umbenennen.
Die folgende Abfrage erzeugte das Diagramm am Anfang des Beitrags. Sie ruft 36 stündliche Vorhersagen für fünf Städte ab und rechnet die Temperatur in Grad Celsius um:
SELECT forecasted_time, name,
tmp_2_m_above_ground AS temp_k,
ROUND(temp_k - 273.15, 2) AS temp_c
FROM gfs.timeseries
WHERE forecasted_time BETWEEN '2026-08-07 19:00:00'
AND '2026-08-09 06:00:00'
AND forecasted_at <= '2026-08-07 12:00:00'
AND (lat, lon, name) IN (
(47.6062, -122.3321, 'Seattle'),
(39.7392, -104.9903, 'Denver'),
(41.8781, -87.6298, 'Chicago'),
(40.7128, -74.0060, 'New York'),
(25.7617, -80.1918, 'Miami')
)
AND lead_time BETWEEN '0h' AND '48h'
ORDER BY forecasted_time, name;
Die Obergrenze für forecasted_at hält das Ergebnis bei dem Modelllauf vom 7. August um 12 UTC, der für das Diagramm verwendet wurde. Die vollständige Abfrage liefert 180 Zeilen; hier sehen Sie den ersten Gültigkeitszeitpunkt:
+---------------------+----------+------------+--------+
| forecasted_time | name | temp_k | temp_c |
+---------------------+----------+------------+--------+
| 2026-08-07 19:00:00 | Chicago | 303.708350 | 30.56 |
| 2026-08-07 19:00:00 | Denver | 307.208350 | 34.06 |
| 2026-08-07 19:00:00 | Miami | 303.908350 | 30.76 |
| 2026-08-07 19:00:00 | New York | 307.208350 | 34.06 |
| 2026-08-07 19:00:00 | Seattle | 301.708350 | 28.56 |
+---------------------+----------+------------+--------+
Die Verbindung ist nur lesend. Sie ist eine gezielte Schnittstelle für Wetterdatenabfragen und keine allgemeine relationale Datenbank.
Warum MySQL?
Für MySQL gibt es bereits ausgereifte Clients für die meisten Programmiersprachen und Datenumgebungen. GribStream-Nutzer können dadurch Verbindungspools, vorbereitete Abfragen, typisierte Zeilen, schrittweises Lesen der Ergebnisse und das Abbrechen von Abfragen verwenden, ohne eine weitere Clientbibliothek einzuführen.
Die vollständige MySQL-Anleitung enthält sofort ausführbare Beispiele für die Kommandozeile, Python, Java, C#, Go, Node.js, Rust, C und DuckDB sowie die vollständige Referenz des unterstützten SQL.
Die Verbindung eignet sich auch für KI-Werkzeuge, die bereits einen allgemeinen MySQL-Connector besitzen. Die herunterladbare GribStream-Skill-Datei für MySQL zeigt einem Agenten, wie er den Katalog erkundet und klar begrenzte Wetterabfragen erstellt.
Eine gezielte SQL-Schnittstelle
Die Beta umfasst das SQL, mit dem Sie ein Dataset, einen Zeitraum, Orte, Lead Times, Ensemble-Mitglieder und Wetterwerte auswählen können. Sie können abgeleitete Werte berechnen, Zeilen filtern, relative Zeiten und benannte Zeitzonen verwenden sowie begrenzte Ergebnisse für die interaktive Erkundung sortieren.
Die Schnittstelle bildet bewusst nicht das gesamte MySQL ab. Wetterabfragen unterstützen weder Schreibvorgänge, Joins, Unterabfragen, Aggregationen, Gruppierungen noch SELECT *. Nicht unterstützte Syntax liefert eine klare Fehlermeldung. Die SQL-Anleitung dokumentiert die unterstützten Formen mit Beispielen.
Große Abrufe, Streaming und Kontingent
Konfigurieren Sie Ihren Client für große Downloads so, dass er Zeilen bei ihrer Ankunft verarbeitet, statt das gesamte Ergebnis im Speicher zu sammeln. Der MySQL-Kommandozeilenclient verwendet --quick; andere Clients bezeichnen dies meist als ungepuffertes, gestreamtes, iteratives oder blockweises Lesen. Die Anleitung verweist auf die passende Dokumentation der einzelnen Clients.
Lassen Sie bei Backfills und anderen umfangreichen Downloads ORDER BY weg und sortieren Sie die Daten nach dem Empfang. Die serverseitige Sortierung ist vor allem für die interaktive Erkundung und begrenzte Ergebnismengen gedacht.
Der Verbrauch des Kontingents richtet sich nach den Wetterdaten, die zur Beantwortung der Abfrage gelesen werden, nicht nur nach den letztlich ausgegebenen Zeilen. Begrenzen Sie Zeitraum, Koordinaten, Lead Times, Ensemble-Mitglieder und ausgewählte Wetterfelder, bevor Sie sich auf Wertefilter oder LIMIT verlassen.
Öffentliche Beta ausprobieren
- Erstellen Sie kostenlos einen GribStream-API-Token, oder verwenden Sie einen vorhandenen Token.
- Öffnen Sie die MySQL-Verbindungsanleitung und das SQL-Handbuch.
- Verbinden Sie sich mit einem MySQL-Client oder -Treiber mit
mysql.gribstream.com:3307. - Beginnen Sie mit einer kleinen, klar begrenzten Abfrage und erweitern Sie sie nach Bedarf.
Das Ziel ist einfach: Wenn Ihre Umgebung bereits MySQL versteht, soll sie einen direkten Weg zu den Wetterdaten von GribStream haben.