They probably threw a fat CIDR block in their IP blacklist to fight off a spam campaign, and your IP was caught in the dragnet. This is how the big companies do it. They’ll evaluate for risk of false positives and as long as that stays below a threshold, they proceed.
In the lower level arrow/parquet libraries you can control the row groups, and even the data pages (although it’s a lot more work). I have used this heavily with the arrow-rs crate to drastically improve (like 10x) how quickly data could be queried from files. Some row groups will have just a few rows, others will have thousands, but being able to bypass searching in many row groups makes the skew irrelevant.
Just beware that one issue you can have is the limit of row groups per file (2^15).
You may be able to get close with sufficiently small row groups, but you will have to do some tests. You can do this in a few hours of work, by taking some sensor data, sorting it by the identifier and then writing it to parquet with one row group per sensor. You can do this with the ParquetWriter class in PyArrow, or something else that allows you fine grained control of how the file is written. I just checked and saw that you can have around 7 million row groups per file, so you should be fine.
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.
I will write something up when the dust settles, I’m still testing things out. It’s a project where the data is fairly standardized but there is about a petabyte to deal with, so I think it makes sense to make investments in efficiency at the lower level rather than through tons of resources at it. That has meant a custom parser for the input data written in Rust, lots of analysis of the statistics of the data, etc. It has been a different approach to data engineering and one that I hope we see more of.
This is a huge challenge with Iceberg. I have found that there is substantial bang for your buck in tuning how parquet files are written, particularly in terms of row group size and column-level bloom filters. In addition to that, I make heavy use of the encoding options (dictionary/RLE) while denormalizing data into as few files as possible. This has allowed me to rely on DuckDB for querying terabytes of data at low cost and acceptable performance.
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.
Look at the website for that polling company. It is bizarre. None of the people on the people page have the company on their LinkedIn pages. Seems to be astroturf.
Edit: look at the photos of the people… AI generated perhaps?
Sqitch is an incredibly under appreciated tool. It doesn’t have a business pushing it like flyway and liquibase, so it isn’t as widely known, but I vastly prefer it to comparable migration tools.
If you’re going to work with weather data use a columnar database, like BigQuery. If you set things up right your performance will generally be a few seconds for aggregation queries. I setup a data platform like this at my previous company and we were able to vastly outperform our competitors and at a much lower cost.
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.
I read this and think “ah, well there are many more non-rich people so the density requirements make this sort of thing complicated” and then I look out the window over the European city I live in where it has been achieved. Then I think about the town an hour away with a vibrant community and pleasant human-scale environment. What makes it all possible? Good transit. Clean buses. The US simply doesn’t have that, and probably not even the political will to make it happen. What a shame.
The thing that matters is oxygen exposure more than anything. You can’t (trivially) reverse the effects of oxygen. This is why Coravin exists: replace the air (with oxygen) with an inert gas. You can do the same for cheap by putting the wine in a container (preferably gas) that reduces its exposure to oxygen, ideally entirely. There are companies selling other tools that do this, like an inflatable device that goes into a bottle.
Please provide more detail. I find the USPS to be one of the best things about this country. Every morning I get an email with photos of the mail I will receive, and a listing of the packages that are coming my way. I can’t remember the last time they’ve ever lost anything of mine. I’m sure not everyone’s experience is like mine - I’m curious how they can be so bad that they create a sense of loathing.
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.