vivek-jain

Sharded in-memory caching turns out to be rather useful at scale :)

Some of the key examples highlighted on our blog are Unity Catalog, which is essentially the metadata layer for Databricks, our Query Orchestration Engine, and our distributed remote cache. See the blog post for more!

Today, we are excited to announce the open sourcing of one of our most critical infrastructure components, Dicer: Databricks’ auto-sharder, a foundational system designed to build low latency, scalable, and highly reliable sharded services. It is behind the scenes of every major Databricks product, enabling us to deliver a consistently fast user experience while improving fleet efficiency and reducing cloud costs. Dicer achieves this by dynamically managing sharding assignments to keep services responsive and resilient even in the face of restarts, failures, and shifting workloads. As detailed in the linked blog post, Dicer is used for a variety of use cases including high-performance serving, work partitioning, batching pipelines, data aggregation, multi-tenancy, soft leader election, efficient GPU utilization for AI workloads, and more.

By making Dicer available to the broader community, we look forward to collaborating with industry and academia to advance the state of the art in building robust, efficient, and high-performance distributed systems. In the rest of this post, we discuss the motivation and design philosophy behind Dicer, share success stories from its use at Databricks, and provide a guide on how to install and experiment with the system yourself.

Ah yes that would be useful. Just added base64 encode/decode along with autodetection for decoding!

Ah it currently only supports epoch time to readable date, not the other way around. Will consider this as a feature request!

I'm not sure if this is what you meant, but the website certainly doesn't call out to LLMs under the hood! Agreed, that would be a terrible idea. LLMs were just used to help write the code for the site, tweaked my post to clarify.

I was looking for a VS Code extension precisely like this, and after plenty of searching I managed to find it. Given how polished it is, definitely deserves to be better known. And of course FOSS to boot!

I'm afraid that's not supported today. But it looks like kprobes do support offsets within a function, so it should be possible to get it to work. That does sound pretty cool, please open an issue for this if you're interested! It might be as simple as (effectively) s/uprobe/kprobe/g, in which case I can try to get that working.

As jpgvm mentioned, yes Rust is a compiled language so it works well with eBPF!

The full picture is always a bit nuanced though so to expand on that: I have tried it cursorily with rust [using wachy to trace wachy :)] and it appears to work. The one issue I would say is that wachy is currently hardcoded to use C++ symbol demangling, so rust function names are not completely accurate (although it's surprisingly decent) - please open an issue if you want that fixed (or if you run into any other issues)! I decided it's better to get it out there and improve things that people actually use rather than fix all my TODOs (excuses for being lazy).

And with rust async, I haven't tried it myself but looked into the details some time back. Wachy works by simply looking at function entry/exit timestamps, but the rust aysnc impl is using futures + poll rather than saving and restoring stacks, so it's not gonna work. You can presumably trace the future's poll function, which may or may not be useful. Although, perhaps with some custom eBPF logic and examining the poll return value it could be made to work...

Thanks! Fair point about the naming - as they say, there are only two hard things in computer science: cache invalidation and naming things (and off-by-one errors). My personal view is that everyone should be free to pronounce things as they like (e.g. gif) but I didn't realize the implications for sharing and adoption.