I recently redesigned my personal website to mimic Earth’s layers and also started blogging. Thanks for putting this together, I love browsing through unique personal websites!
321 karma · joined September 5, 2018
I recently redesigned my personal website to mimic Earth’s layers and also started blogging. Thanks for putting this together, I love browsing through unique personal websites!
I'm trying out Clickhouse for the next post. Definitely excited for sub 24 hour data loading!
I haven't heard of VictoriaMetrics but that's some impressive performance. Will check it out!
The data is freely available from the Climate Change Service [1] which has a nice API but download speeds can be a bit slow. You'll have to sign up for this.
NCAR's Research Data Archive [2] provides some of the data (as pre-generated NetCDF files) but at higher download speeds. No signup necessary.
It's not super well documented but I hosted the Python scripts I used to download the data on the accompanying GitHub repository [3].
[1]: https://cds.climate.copernicus.eu/cdsapp#!/dataset/reanalysi...
[2]: https://rda.ucar.edu/datasets/ds633-0/
[3]: https://github.com/ali-ramadhan/timescaledb-insert-benchmark...
From https://deepmind.google/discover/blog/graphcast-ai-model-for...
> Crucially, GraphCast and traditional approaches go hand-in-hand: we trained GraphCast on four decades of weather reanalysis data, from the ECMWF’s ERA5 dataset.
The data is freely available from the Climate Change Service [1] which has a nice API but download speeds can be a bit slow.
NCAR's Research Data Archive [2] provides some of the data (as pre-generated NetCDF files) but at higher download speeds.
It's not super well documented but I hosted the Python scripts I used to download the data on the accompanying GitHub repository [3].
[1]: https://cds.climate.copernicus.eu/cdsapp#!/dataset/reanalysi...
[2]: https://rda.ucar.edu/datasets/ds633-0/
[3]: https://github.com/ali-ramadhan/timescaledb-insert-benchmark...
The data is freely available from the Climate Change Service [1] which has a nice API but download speeds can be a bit slow.
NCAR's Research Data Archive [2] provides some of the data (as pre-generated NetCDF files) but at higher download speeds.
It's not super well documented but I hosted the Python scripts I used to download the data on the accompanying GitHub repository [3].
[1]: https://cds.climate.copernicus.eu/cdsapp#!/dataset/reanalysi...
[2]: https://rda.ucar.edu/datasets/ds633-0/
[3]: https://github.com/ali-ramadhan/timescaledb-insert-benchmark...
Also glad to hear an expert say that WAL data isn't really necessary for bulk loading, especially with chunks. I should get through the ~20 days it takes to load data without a power outage haha (no UPS yet :() but it sounds like even in the worst case I can just resume.
Totally agree that it would be cool to see when and where the weather observations are that are informing the climate model. A quick search didn't turn up this dataset, but it may be somewhere. I'll see if I can find this data.
I'll have to try the binning and compare it with listing all the values and finding the 99th percentile! But yeah the spatial part of that query might be the tougher part.
And yeah I also considered whether to use ERA5 or ERA5-Land. I don't remember if ERA5-Land was missing a variable or I just wanted to look at some ocean grid cells, but I decided to start with vanilla ERA5.
I agree that storing the data is appropriately chunked Zarr files is almost surely going to be faster, simpler to set up, and take up less space. Could even put up an API in front of it to get "queries".
I also agree that I haven't motivated the RDBMS approach much. This is mainly because I took this approach with Postgres + Timescale since I wanted to learn to work with them, and playing around with ERA5 data seemed like the most fun way. Maybe it's the allure of weather data being big enough to pose a challenge here.
I don't have anything to back this up but I wonder if the RDBMS approach, with properly tuned and indexed TimescaleDB + PostGIS (non-trivial to set up), can speed up complex spatio-temporal queries, e.g. computing the 99th percentile of summer temperatures in Chile from 1940-1980, in case many different Zarr chunks have to be read to find this data. I like the idea of setting up different tables to cache these kinds of statistics, but it's not that hard to do with Zarr either.
I'm benchmarking queries and indexes next so I might know more then!
But as rabernat pointed out in his comment, pulling out a long time series from the cloud replica is also slow. And I know I eventually want to perform complex spatio-temporal queries, e.g. computing the 99% percentile of summer temperatures in Chile from 1940-1980.
I don't doubt that a cloud replica can be faster, but it's at odds with my budget of $0 haha.
Ah I did not know about the `create_default_indexes=>false` and that a time index is created by default for hypertables. I'll add a note to explain this! Also curious to benchmark inserting without the time index then creating it manually.
Even with 32 workers I think the HDD was fine. I did monitor disk usage through btop and the SSD that Postgres lived on seemed to be more of a bottleneck than the HDD. So my conclusion was that a faster SSD for Postgres would be a better investment than moving the data from HDD to SSD.
footnote: https://aliramadhan.me/2024/03/31/trillion-rows.html#fn:copy...
This is not something I'm productionizing (at least not yet?) and I'm giving myself zero budget since it's a side project, but if/when I do I'll definitely look into BigQuery!