Fast drilldown dashboards from a single Parquet file

Fast drilldown dashboards from a single Parquet file(hamiltonulmer.com)

173 points by v3gas 41 days ago | 23 comments

simonw 40 days ago |

> The bytes pass through a small Cloudflare Worker on the way, because the free r2.dev URL is rate-limited.

For a 40MB file I suggest hosting it directly on GitHub Pages - that's effectively a free CORS-enabled CDN and supports HTTP range requests, so you should be able to get that demo working without needing to involve Cloudflare Workers at all.

hamilton 40 days ago | |

Agreed, for a public demo like this one, GitHub Pages would work great (or any host that speaks HTTP range requests with CORS). I used R2 partly because I wanted to see how it behaved, and partly because the real use-case doesn't fit Pages. The source data already lives on R2 as Iceberg, the files are per-customer and would probably need auth (signed URLs or a session-checking Worker), and obviously 10k customer cubes on a schedule works better with object PUTs rather than git deploys

owebmaster 38 days ago | | |

> Agreed, for a public demo like this one, GitHub Pages would work great

If you are okay with it being down regularly

Edit: Ironically, that would be the case now: https://www.githubstatus.com/incidents/hcbtzksccj2f

mrbluecoat 40 days ago |

A clever repurposing of technologies but realistically only worthwhile for static datasets with range payloads small enough to fit into a web response.

> your pipeline has to rebuild each customer’s file fast enough to meet the update cadence. ... data that updates on a coarse schedule rather than in realtime

simlevesque 40 days ago | |

It doesn't have to all live in the same Parquet file. you can have a Parquet file for all your historical data, plus one for the current week which is updated often cheaply, and then when the week is over you merge that into your big parquet file.

You're making it seem like there's hard limits to what can be done but while there definitely is, you can do incredible stuff.

nicoritschel 40 days ago | | |

And then you eventually just take the weekly files and combine them and you've reinvented data lakes with worse (no) metadata management

simonw 40 days ago | |

"static datasets with range payloads small enough to fit into a web response" fits a lot of workloads.

I expect that if your overall data is less than a GB this trick will work really well for you.

nicoritschel 40 days ago | | |

Most reporting I've ever worked on is based on live data and users expect updates. Range requests over parquet cubes are a cool party trick, but you outgrow it quickly once you need to start regularly updating the dataset such as to avoid full recompuation.

The next step in this journey is Iceberg (and a proper incremental pipeline), which can also be read directly in the browser via WASM either via DuckDB or without. This is from the same author as the parquet library mentioned in the OP https://github.com/hyparam/icebird

cosmojg 40 days ago |

> A dashboard like this one is designed to answer a bounded set of analytical questions ~ requests per day, requests per day for one agency, all-time totals by borough. Each question can be answered by GROUP BY queries, so we can precompute them all ahead of time and save each result as its own small table, called a grouping set. Stack all of the grouping sets in one Parquet file, one section per set, and you have a data cube. A grouping set is only useful if it either enables a question to be answered, or reduces the latency of pulling the data.

What's the benefit of "data cubes" over caching?

hamilton 40 days ago | |

It's a good question. In a sense, the cube is caching, just materialized ahead of time instead of memoized on demand. A result cache still needs a live database behind it for misses; the cube has no misses, since every question the dashboard is designed to answer has data in the cube already. And for this experiment, the goal was to forgo a database to serve the data in the first place.

I provide caveats for when this would work vs. when it doesn't in the post. For a lot of customer-facing dashboards, I think it's probably pretty good.

deanebarker 40 days ago |

Interesting how noise complaints dwarf any other type of complaint in NYC.

wyck 40 days ago |

On the surface (I haven't tested it) it looks like a great cost and runtime saver, but only for data sets that need a cadence above 5 or so minutes. You wouldn't be able to have a refresh button to get the "latest" data outside this window, depending on size and build time? Wondering if you can apply a hybrid approach, combining the historical parquet file with a live query.

masterj 40 days ago | |

Cloudflare Pipelines has a configurable interval to write to parquet files that's as low as 10s: https://developers.cloudflare.com/pipelines/sinks/available-... so you could have a pretty fast refresh

It will cost (slightly) more to write this frequently to R2 since you are charged per-write, but this is something you can tune.

youngtaff 40 days ago |

I’d loved to have seen more detail on how the Parquet file was actually built — are there any good resources that cover this?

MattBlissett 38 days ago | |

With the GROUPING SETS or CUBE features in DuckDB, I think.

https://duckdb.org/docs/current/sql/query_syntax/grouping_se...

wlessard_ca 40 days ago |

How is this any different from the old OLAP cubes like IRL / Express? The cube is basically an array in memory and super fast, the dashboards based on Group By as well. I was an Express consultant at Oracle, great to see old concepts come back to life if it’s what I think it is.

hamilton 39 days ago | |

Indeed, OLAP cubes keep finding new life. The critical difference here is that there isn't a heavy query engine (just a Parquet reader) and a few http requests to pull from the cube. So it's light on the backend and light on the frontend.

yahiamost 40 days ago |

Great read!