Live data from Hacker News

Bauplan – Git-for-data pipelines on object storage

docs.bauplanlabs.com

31–40 of 46 posts

Re: Bauplan – Git-for-data pipelines on object storage

#31

The Git-like approach to data versioning seems really promising to me, but I'm wondering what those merge operations are expected to look like in practice. In a coding environment, I'd review the PR basically line-by-line to check for code quality, engineering soundness, etc. But in the data case it's not clear to me that a line-by-line review would be possible, or even useful; and I'm also curious about what (if any…

That’s a great question. Diffing is one area we’ve thought a bit about but still need to dedicate more cycles to. One thing I would be curious about is, what are you doing in these notebooks to check? For what it’s worth, could possibly have an intermediate Python model that does some calculation to look at differences and materializes the results to a table, which you could then query directly for further insight. O…

> For what it’s worth, could possibly have an intermediate Python model that...materializes the results to a table

I think this is kind of the answer I was looking for, and in other systems I've actually manually implemented things like this with a "temp materialize" operator that's enabled by a "debug_run=True" flag. With the NB thing basically I'm trying to "step inside" the data pipeline, like how an IDE debugger might run a script line by line until an error hits and then drops you into a REPL located 'within' the code state. In the notebook I'll typically try to replicate (as close as possible) the state of the data inside some intermediate step, and will then manually mutate the pipeline between the original and branch versions to determine how the pipeline changes relate to the data changes. I think the dream for me would be to having something that can say "the delta on line N is responsible for X% of the variance in the output", although I recognize that's probably not a well defined calculation in many cases. But either way at a high level my goal is to understand why my data changes, so I can be confident that those changes are legit and not an artifact of some error in the pipeline.

Asserting that a set of expectations is met at multiple pipeline stages also gets pretty close, although I do think it's not entirely the same. Seems loosely analogous to the difference between unit and integration/E2E tests. Obviously I'm not going to land something with failing unit tests, but even if tests are passing the delta may include more subtle (logical) changes which violate the assumptions of my users or integrated systems (ex. that their understanding the business logic is aligned with what was implemented in the pipeline).

Re: Bauplan – Git-for-data pipelines on object storage

#32

Earlier quoted context omitted.

To me they seem like the pythonic version of dbt! Instead of yaml, you write Python code. That, and a lot of on-the-fly computations to generate an optimized workflow plan.

Plenty of stuff in common with dbt's philosophy. One big thing though, dbt does not run your compute or manage your lake. It orchestrate your code and pushes it down to a runtime (e.g. 90% of the time Snowflake). This IS a runtime. You import bauplan, write your functions and run them in straight into the cloud - you don't need anything more. When you want to make a pipeline you chain the functions together, and the…

I see, this is a great answer. So you don't need any platform or spark or anything. Just storage and compute?

Re: Bauplan – Git-for-data pipelines on object storage

#33
post #32

Earlier quoted context omitted.

Plenty of stuff in common with dbt's philosophy. One big thing though, dbt does not run your compute or manage your lake. It orchestrate your code and pushes it down to a runtime (e.g. 90% of the time Snowflake). This IS a runtime. You import bauplan, write your functions and run them in straight into the cloud - you don't need anything more. When you want to make a pipeline you chain the functions together, and the…

I see, this is a great answer. So you don't need any platform or spark or anything. Just storage and compute?

You technically just need storage (files in a bucket you own and control forever).

We bring you the compute as ephemeral functions, vertically integrated with your S3: table management, containerization, read / write optimizations, permissions etc. is all done by the platform, plus obvious (at least to us ;-)) stuff like preventing you to run a DAG that is syntactically incorrect etc.

Since we manage your code (compute) and data (lake state through git for data), we can also provide full auditing with one liners: e.g. "which specific run change this specific table on this data branch? -> bauplan commit ..."

Re: Bauplan – Git-for-data pipelines on object storage

#34
post #18

Looks interesting! Bauplan seems like a mix of an orchestration engine and a data warehouse. It's similar to Motherduck as it runs DuckDB on managed EC2, with more data engineer-focused branching and Python support similar to SQLMesh. It's interesting that most vendors compute in their own managed account instead of BYOC though. I understand it's hard to manage compute on the customer cloud for vendors, but I was und…

Correct.

Unlike warehouses or SQL lakehouses, we also any Python code, including from your private AWS repositories for example, through a simple decorator, while giving you transactional pipelines, fully versioned and revertible, like it's a database on your S3.

Wrt deployment, I think things are a bit more nuanced: we are soc2 compliant and provide a enterprise ready control vs data plane separation - data are only processed in single tenant VPC, which is private linked to your account, effectively making the same account networking wise. If you insist on having the data plane in your own account, the architecture supports that as our only data plane dependency is VMs (we install our own custom runtime there!).

To give you a sense, one of our large customers is a 4BN / year large broadcaster with tens of milions of users, and they run with the above AWS security posture.

Happy to answer more offline if you're curious (jacopo.tagliabue@bauplanlabs.com)

Re: Bauplan – Git-for-data pipelines on object storage

#35
post #27

How do you compare with DVC and LakeFS?

Thanks for the question!

On the data side of things, DVC is more about versioning static datasets / local files, while Bauplan manages your entire lakehouse, potentially hundreds of tables with point in time versioning (time travel) and branching (at any given time, different version of the same table) -> https://docs.bauplanlabs.com/en/latest/tutorial/02_catalog.h....

On the compute side of things, Bauplan runs the functions for you, unlike catalogs which only see a partial truth and provide only a piece of the puzzle: Bauplan knows both your code (because it runs your pipeline) and your data (because it handles all the commits on the lakehouse), which allows a one-liner reply to question such as:

"who change, when, with which code, this table on this branch?"

It also allows a lot of optimizations in multi-player mode, such as efficient caching of data (https://arxiv.org/abs/2411.08203) and packages (https://arxiv.org/pdf/2410.17465).

Re: Bauplan – Git-for-data pipelines on object storage

#36

I’m intrigued but what’s the pricing going to be? What am I paying for? Something to make faas easier? What’s the magic behind the scenes?

The pricing is a bit bespoke at the moment as we work closely with our customers - you can reach out at anytime to any of us for a chat (jacopo.tagliabue@bauplanlabs.com). The general driver is just compute capacity: how much resources you want to have available at any point in time?

My usual suggestion is to get a feeling for the APIs and capabilities on the public sandbox on our home page, which is free and with a lot of examples and datasets to start from!

As for the magic, the reasons behind building a FaaS runtime and the main optimizations have been shared in a few recent papers with the community - e.g. https://arxiv.org/pdf/2410.17465 and https://arxiv.org/abs/2411.08203 - and deep dive on podcasts (e.g. https://www.youtube.com/watch?v=gPJvgkHIEBY).

If you want to geek out more, just reach out!

Re: Bauplan – Git-for-data pipelines on object storage

#37
post #19

For someone like me (who is not an ML expert, but can write Python fluently) Bauplan looks like an ideal fit. Looking forward to taking a deeper look and building something in production.

Glad to see it resonates! Happy to help if needed!

Re: Bauplan – Git-for-data pipelines on object storage

#38

Congrats on the more official launch! Super promising, first product that shares dbt-type data organization/orchestration capabilities with a compute layer worthy of replacing existing data warehouses/python environments.

Glad to see it resonates, especially the Python part <3

Re: Bauplan – Git-for-data pipelines on object storage

#39

Earlier quoted context omitted.

That’s a great question. Diffing is one area we’ve thought a bit about but still need to dedicate more cycles to. One thing I would be curious about is, what are you doing in these notebooks to check? For what it’s worth, could possibly have an intermediate Python model that does some calculation to look at differences and materializes the results to a table, which you could then query directly for further insight. O…

> For what it’s worth, could possibly have an intermediate Python model that...materializes the results to a table I think this is kind of the answer I was looking for, and in other systems I've actually manually implemented things like this with a "temp materialize" operator that's enabled by a "debug_run=True" flag. With the NB thing basically I'm trying to "step inside" the data pipeline, like how an IDE debugger…

"In the notebook I'll typically try to replicate (as close as possible) the state of the data inside some intermediate step, and will then manually mutate the pipeline between the original and branch versions to determine how the pipeline changes relate to the data changes."

You can automate many changes / tests by materializing the parent(s) of the target table, and use the SDK to produce variations of a pipeline programmatically. If your pipeline has a free parameter (say top-k=5 for some algos), you could just write a Python for loop, and do something like:

client.create_branch() client.run()

for each variation, materializing k versions at the end that you can inspect (client.query("SELECT MAX ...")

The broader concept is that every operation in the lake is immutably stored with an ID, so every run can be replicated with the exact same data sources and the exact same code (even if not committed to GHub), which also means you can run the same code varying the data source, or run a different code on the same data: all zero-copy, all in production.

As for the semantics of merge and other conflicts, we will be publishing by end of summer some new research: look out for a new blog post and paper if you like this space!

Post reply on HN