Live data from Hacker News

Airflow's Problem

stkbailey.substack.com

11–20 of 126 posts

Re: Airflow's Problem

#11
post #5

This is why I though the shift from "orchestrate jobs" to "keep track of state of assets" that Dagster is trying to do is pretty important. But it sems it might not be enough - it still keeps clunky (pythonic) interface and I don't know how well it does multi-tenancy.

Could you clarify what "keep track of state of assets" means?

Re: Airflow's Problem

#12
The post feels like a bait-and-switch in the sense that it presents itself as about Airflow's shortcomings but focuses mostly on problems that Airflow doesn't attempt to solve.

Airflow can certainly be frustrating and it doesn't solve _all_ workflow orchestration problems. Surely the same thing can be said of many tools? This seems mostly like a mismatch of expectations.

Re: Airflow's Problem

#13
post #5

This is why I though the shift from "orchestrate jobs" to "keep track of state of assets" that Dagster is trying to do is pretty important. But it sems it might not be enough - it still keeps clunky (pythonic) interface and I don't know how well it does multi-tenancy.

Could you clarify what "keep track of state of assets" means?

https://www.dagster.io/blog/software-defined-assets

Of course, nothing stops Airflow or other tools fron thinking this way as well.

Re: Airflow's Problem

#14
post #12

The post feels like a bait-and-switch in the sense that it presents itself as about Airflow's shortcomings but focuses mostly on problems that Airflow doesn't attempt to solve. Airflow can certainly be frustrating and it doesn't solve _all_ workflow orchestration problems. Surely the same thing can be said of many tools? This seems mostly like a mismatch of expectations.

100% agreed. By analogy, an article titled “pthreads’ problem” should be about shortcomings in the POSIX multithreading model, not an article saying that the implementation of machine-level parallelism is irrelevant because Kubernetes exists.

Re: Airflow's Problem

#15
I've been using airflow for about 2 years now in production. It's been mostly good - the few times things go wrong, it's a huge pain in the ass to figure out why... but it's significantly better than just straight cron on Linux. Airflow 2 has improved a lot of speed and catching up issues from airflow 1.x

I don't have time to investigate other solutions like dagster and prefect and migrate jobs to it for testing.

Re: Airflow's Problem

#16
post #15

I've been using airflow for about 2 years now in production. It's been mostly good - the few times things go wrong, it's a huge pain in the ass to figure out why... but it's significantly better than just straight cron on Linux. Airflow 2 has improved a lot of speed and catching up issues from airflow 1.x I don't have time to investigate other solutions like dagster and prefect and migrate jobs to it for testing.

If it is just you, you are fine, and I'm not sure other tools would have that much benefit.

Trouble with Airflow starts when multiple teams and user types start to share it.

Re: Airflow's Problem

#18
> Shift 1: “We know the lineage” to “We know what in god’s name is happening”

Bro I can't even get my company to the _first_ part, and we're collectively already having issues with the second? What is everyone else's read on this situation in general? Do you all have row and table level lineages for your data? For pipelines that people are actively using? Every company I've ever been in can hardly figure out where finance gets last years "magical excel sheet", let alone be close to a spot where they're actively using data lineage tools.

I also don't like Airflow, but for somewhat different reasons.

I think it couples orchestration and transformation too tightly, I don't understand the desire to integrate everything with your actual runtime Python code - I think it's markedly the wrong level of abstraction/integration and limits your engineering capacity. There's undoubtedly some good engineering, it's come a long way, and it's mighty popular, but every time I look at a repo that uses it, the only read I get is "cross-cutting-chaos".

Re: Airflow's Problem

#19
I've recently had the sales team from Magniv.io pestering me to try it as an alternative to Airflow with a "shift left" perspective for automating jobs. I wasn't convinced enougy by the value prop to dive deeper. I think it was a language problem - I was just having trouble understanding and relating to the problems they solve and then figuring out whether or not I have those problems too.

I'm running into the same issue with this guy's post, although a little less so. The question he seems to ask is "With a complex pattern of data flows, if something breaks, how do you recover?" His argument is that Airflow does not offer enough visibility into the full data trace nor enough tools to apply recovery rules for repairing broken bits.

I think I agree, but prometheus doesn't really solve that. Nor necessarily does better management of automated job queue backlog management and job retries.

He also complains about some syntax and design choices that predate MyPy and Pydantic and modern Async Python coding. Those seem fairly easy things to drag Airflow forward with in future releases.

Re: Airflow's Problem

#20
post #12

The post feels like a bait-and-switch in the sense that it presents itself as about Airflow's shortcomings but focuses mostly on problems that Airflow doesn't attempt to solve. Airflow can certainly be frustrating and it doesn't solve _all_ workflow orchestration problems. Surely the same thing can be said of many tools? This seems mostly like a mismatch of expectations.

FWIW the author is pretty direct about this. After the cute beginning, he basically says that his problem is with Airflow's scope, not it's execution.
Post reply on HN