This is so cool. I spent years at Pachyderm (YC...something) banging our head against:

- we're "Bazel for data"

- but...we have no Starlark. We're trying to port Airflow but it's not playing well with the way we cache partial results.

Amazing to me that I'm only now seeing the architecture pattern of "pure coordination language connecting sandboxed imperative components", which is used by Nix and Bazel, applied to distributed workflows. If somebody applied this to batch data processing you might have a Pachyderm that actually works better than ours did.

▲

icyfox 10 hours ago | parent [-]

Cool thought! We have an internal version of map reduce implemented in waymark that worked pretty well (though uses Redis for its intermediate values so it's technically not an end-to-end integrated solution).

In principle I would love to have something like this working for arbitrarily large ETL flows; ie. write the logic you want and it tries to figure out a good distributed algorithm to get the outputs. At the moment flowing data through the cluster is the biggest bottleneck. We generally assume that action inputs & outputs themselves are pretty small at the boundary even if their containerized context is quite large.

Where did you hit the most snags with caching?

	▲	msteffen 7 hours ago \| parent \| next [-]
		Well, it was just that the models didn't really line up. To give a somewhat longer description of what Pachyderm does/did: 1. Connect data-scale version control with pipeline orchestrator. 2. Version control tells orchestrator which shards have changed since the last run and which ones haven't. 3. Orchestrator only processes changed shards from one run to the next, instead of all of them. 4. Profit. That's fine for e.g. one mapreduce, but, 1. If an action's behavior changes, you can't re-use its prior results (usually—sometimes you're just adding print statements to debug a failing shard) 2. If the overall pipeline changes, you can't re-use results from the first change onward 3. Figuring out if the overall pipeline changed is not necessarily easy, and if you're always throwing out everything just in case, your product is not helping people. So, the way Waymark uses a compiler for the orchestration layer would've worked so well with our model. It's also just satisfying—once I learned in detail how Bazel/Nix work, I see a fit for that architecture pattern in anything remotely pipeline-y, and it drove me nuts that Airflow/Beam/Dataflow weren't really using it. So I'm very happy to see this for that reason as well. And, as if that weren't enough, it's so cool that it introduces a pure language at the coordination layer (which this type of architecture basically needs, hence the Nix language/Starlark) without actually requiring a new language, or even a new file. Amazing!
	▲	ajb 2 hours ago \| parent \| prev [-]
		Yeah, that's an interesting use case. The problem for you with a compiler would be how to get it to work with all of the efficient python modules like pandas, script, numpy, pytorch etc that all implement their backend in C with intrinsics/GPU usage.