So basically a Nyquist rate type of concept.
97 karma · joined May 15, 2018
sudo shutdown +15 (or other amount of minutes)
when I need a compute instance and don’t want to forget to turn it off. It’s a simple trick that will save you in some cases.
Just beware that one issue you can have is the limit of row groups per file (2^15).
Then spin up duckdb and do some performance tests. I’m not sure this will work, there is some overheard with reading parquet, which is why it is discouraged to have small files and row groups.
Regarding reading materials, I found this DuckDB post to be especially helpful in realizing how parquet could be better leveraged for efficiency: https://duckdb.org/2024/03/26/42-parquet-a-zip-bomb-for-the-...
What we are lacking now is tooling that gives you insight into how you should configure Iceberg. Does something like this exist? I have been looking for something that would show me the query plan that is developed from Iceberg metadata, but didn’t find anything. It would go a long way to showing where the bottleneck is for queries.
Edit: look at the photos of the people… AI generated perhaps?
The great thing about this data is it is generally append only, unless errors are found in earlier data sets. But it’s something that usually only happens once a year if at all.
A honyaki chef’s knife and a vinyl cutting board to go with it.
We work to transfer the risk of the inevitable – natural disasters – everywhere on earth. We work with climate model datasets and are building a system to structure and operate contracts to transfer the risks of natural disasters, primarily in non-developed countries. We're backed by the British and German governments and we have a fantastic team of PhDs, engineers, scientists and just generally nice people.
Email us a resume and a little bit about you at careers@globalparametrics.com
Jobs here: http://www.globalparametrics.com/jobs/
We are developing risk transfer products, particularly for low and middle income countries, based on parametric models. Our work deals with running parametric models, loading them into our data system via DAGs, developing micro services to calculate hazard and index values, visualize risk and much, much more. We’re looking for people familiar with GCMs, insurance/risk, developing micro services, creating infrastructure to handle large amounts of data, and an interest in climate change and resiliency efforts. If this interests you, email me at globalparametrics.com via tjohnson
Here is the job post:
We are seeking a database architect for maintaining a large and growing repository of geophysical scientific data (50TB). The bulk of the data consists of
* Global Climate Data * Numerical weather forecasting models (GCMs) * Seismic and Earthquake events * Hurricane storm tracks
This data must be updated daily and organized for consumption by scientists through consistent data access layers and APIs. Experience with large scientific datasets is preferred, and suggest that you highlight this experience compared to large transactional databases.
Specific Responsibilities:
* Responsibility for creating an optimized database architecture for efficient delivery * Maintaining and updating the database with new data sets * Refine and automate regular data harvesting processes * Refine DB queries and indexes to speed performance * Expertise in SQL and NoSQL environments
Environment:
The candidate will work largely independently, but also collaboratively with other code developers in an agile development framework. Results are prioritized over process. This senior position will report directly the to the chief technical officer.
Global Parametrics (GP) offers innovative resilience solutions in emerging economies impacted by natural disasters. GP is a for-profit social venture, with government backing from the UK and Germany.
Email careers@globalparametrics.com with your CV, a brief explanation of who you are, and a summary of your relevant technical experience to apply.
I work for this company and we need someone who is motivated by working on difficult scientific and computing infrastructure problems. To work for Global Parametrics is a chance to work on helping low and middle income countries become more resilient to natural disasters. Many companies talk about how they are improving people's lives – here's a chance to actually do it.
Here is the job post:
We are seeking a database architect for maintaining a large and growing repository of geophysical scientific data (50TB). The bulk of the data consists of
* Global Climate Data
* Numerical weather forecasting models (GCMs)
* Seismic and Earthquake events
* Hurricane storm tracks
This data must be updated daily and organized for consumption by scientists through consistent data access layers and APIs. Experience with large scientific datasets is preferred, and suggest that you highlight this experience compared to large transactional databases.
Specific Responsibilities:
* Responsibility for creating an optimized database architecture for efficient delivery
* Maintaining and updating the database with new data sets
* Refine and automate regular data harvesting processes
* Refine DB queries and indexes to speed performance
* Expertise in SQL and NoSQL environments
Environment:
The candidate will work largely independently, but also collaboratively with other code developers in an agile development framework. Results are prioritized over process. This senior position will report directly the to the chief technical officer.
Global Parametrics (GP) offers innovative resilience solutions in emerging economies impacted by natural disasters. GP is a for-profit social venture, with government backing from the UK and Germany.
Email careers@globalparametrics.com with your CV, a brief explanation of who you are, and a summary of your relevant technical experience to apply.
This is a very bad example of what factors are for in R, because it makes it seem like factors are for defining variables or keys in key value pairs. You can use them for that, but it isn't the intended use. A better example would be:
suppose you were comparing the amount of sugar in fruits based on several growing locations, and you had three columns:
| Fruit | Location | Density (g/L) |
Fruit would be a factor variable (let's say it takes the possibilities of apple, banana, orange), and location could be too, if it were a discrete set of possibilities (as opposed to lat/lon coords)
This author seems to forget that R was built for working with data in an analytical setting, unlike all of the languages he's comparing it to. It has creeped into other areas, but that seems to be because in the hands of a skilled user it is far easier to implement a data analysis solution. I'm sure someone will come in and say how much better pandas is, but on the small datasets, I'll stick with R, especially with how brittle and buggy matplotlib is.