Live data from Hacker News

Dabbling with Dagster vs. Airflow

davidsj.substack.com

41–50 of 56 posts

Re: Dabbling with Dagster vs. Airflow

#41
post #34

Earlier quoted context omitted.

Spark, after all _is_ a large Apache project?

It is a bit more nuanced. On one hand, it is immensely successful Apache project. On the other hand, it is a failure of open source - Databricks Spark is full of proprietary extensions that are not in Apache Spark. AWS Spark (in EMR and Glue) is full of proprietary extensions that are not in Apache Spark. Same with Cloudera, IBM and other players. There's also the story how Databricks people blocked IBM patch to Apac…

>On the other hand, it is a failure of open source - Databricks Spark is full of proprietary extensions that are not in Apache Spark. AWS Spark (in EMR and Glue) is full of proprietary extensions that are not in Apache Spark. Same with Cloudera, IBM and other players.

Well, can't disagree with that.

>There's also the story how Databricks people blocked IBM patch to Apache Spark that was supposed to make it faster on IBM POWER platform - they didn't want to help competition.

Any link to that? I can't find the story.

Re: Dabbling with Dagster vs. Airflow

#42

I tried (and tried, and tried, and tried) once to set up a local "test" instance of Airflow just to try out a few different things and understand better how the whole thing worked. I finally gave up after a week - I've never come across any software that I couldn't install, but Airflow just ended up being too much.

Astronomer has CLI that makes this week a 5 minutes task.

https://github.com/astronomer/astro-cli

Re: Dabbling with Dagster vs. Airflow

#43

I tried (and tried, and tried, and tried) once to set up a local "test" instance of Airflow just to try out a few different things and understand better how the whole thing worked. I finally gave up after a week - I've never come across any software that I couldn't install, but Airflow just ended up being too much.

Have you got experience with Docker? Becuase containerized airflow seemed fairly simple for me.

Re: Dabbling with Dagster vs. Airflow

#44

The author seems to think that Dagster or Prefect will take over Airflow, I don't think this is true. All of them being open source means that if one has a good idea or better way of doing something the other can quickly implement the feature and even use the some of same code. We saw it with Airflow implementing the TaskFlow API as a response to Dagster, and in a few weeks Airflow 2.4 is going to have dataset schedu…

I don't really think that either will overtake Airflow in terms of sheer number or users or orgs it is deployed at. 1. Dagster and Prefect won't ever have a hosted version on AWS/GCP (teams can spin these up from their consoles without even considering a vendor conversation or leaving their infra). 2. There are very large Airflow projects out there with huge DE teams running them, that just can't really move to Dagst…

Dagster already offers Dagster Cloud which came out a month or so ago[1]. It's a fully hosted solution for teams that don't want to run their own.

[1] https://dagster.io/cloud

Re: Dabbling with Dagster vs. Airflow

#45

I recently had the experience of setting up some Prefect pipelines, which I can compare to this article. Note that while I'm not new to data engineering, I'm new to open source frameworks, and have some insight into Airflow (studied architecture in depth, written a lot of code in it). Prefect is generally very easy to use. Essentially, you: (a) write a Python-based flow, which defines some job to run (with subtasks),…

Disclaimer: I work for Prefect.

It looks like we added cron and other schedule types to the deployment CLI just under a month ago[1].

Over the last couple of releases, we've also made it easier to pull deployments from GitHub or bake your flow code into Docker images instead of needing S3-like storage.

As with any product, there's always more to do, so I appreciate you sharing your thoughts. More than anywhere else I've worked, community feedback is a huge driver of product enhancements and feature development. Feel free to join our Slack community[2] if you'd like to share more feedback or ask questions.

[1] https://github.com/PrefectHQ/prefect/blob/main/RELEASE-NOTES...

[2] https://www.prefect.io/slack/

Re: Dabbling with Dagster vs. Airflow

#46
post #34

Earlier quoted context omitted.

It is a bit more nuanced. On one hand, it is immensely successful Apache project. On the other hand, it is a failure of open source - Databricks Spark is full of proprietary extensions that are not in Apache Spark. AWS Spark (in EMR and Glue) is full of proprietary extensions that are not in Apache Spark. Same with Cloudera, IBM and other players. There's also the story how Databricks people blocked IBM patch to Apac…

>On the other hand, it is a failure of open source - Databricks Spark is full of proprietary extensions that are not in Apache Spark. AWS Spark (in EMR and Glue) is full of proprietary extensions that are not in Apache Spark. Same with Cloudera, IBM and other players. Well, can't disagree with that. >There's also the story how Databricks people blocked IBM patch to Apache Spark that was supposed to make it faster on…

> Any link to that? I can't find the story.

I can't find it either, I'm pretty sure I heard it on some conference, so consider it made up. It was years ago anyway.

Re: Dabbling with Dagster vs. Airflow

#47

I tried (and tried, and tried, and tried) once to set up a local "test" instance of Airflow just to try out a few different things and understand better how the whole thing worked. I finally gave up after a week - I've never come across any software that I couldn't install, but Airflow just ended up being too much.

Like others are saying, containerized Airflow is trivial.

Astronomer is extra trivial, but it's not FOSS.

Re: Dabbling with Dagster vs. Airflow

#48
Disclaimer: I am building a no-code, SQL-focused data pipeline platform to improve the experience around data pipelines, see my profile for more. The idea is to replace all of Fivetran, DBT, Airflow and more with a single platform that can handle all with no code.

I like the fact that the articles the author has are walking the reader through their own journey, along with the learnings and opinions after the trial periods. I am curious to hear how Dagster will evolve for their usage.

One of the things that has been a big discussion point among data folks that I have been talking to is that people that haven't done ops before underestimate the amount of operations that go into managing an Airflow instance, there are still quite a lot of stuff to be figured out: - how do I get my pipeline code there? - where do I execute them? - how do I setup my development environment? - how do I make sure the platform is up and running? - how do I know if a task fails? - where do I store my logs? - how do I scale my setup?

If you are using a managed solution like MWAA or Cloud Composer, some of these questions might go away, but some aren't. As it stands today, Airflow is a powerful but hard-to-use technology; in my opinion, it is less of a tool that is supposed to be used directly by data engineers / analysts, and more of a platform that should enable easier-to-use platforms for its internal users.

In that sense, I believe Dagster is hitting the right chord: they focus on the pain points in DX for Airflow and similar solutions, they have figured out how to do development branches, they are focusing on assets rather than tasks, and they are constantly improving their product as far as I can tell from the outside. However, it is still a platform that you have to have engineers writing code for it: asking a data analyst to write python code to schedule a few SQL queries still adds a huge barrier to entry.

I am excited to see all the innovation that is happening in this space. I find the point about people getting used to the baggage around Airflow to be a quite real problem, and I am very happy to see solutions like Dagster are gaining speed. All in all, it is a very large space and there are many different problems that need to be solved to add the data abilities larger organizations have to smaller companies with limited budgets.

Re: Dabbling with Dagster vs. Airflow

#49

I tried (and tried, and tried, and tried) once to set up a local "test" instance of Airflow just to try out a few different things and understand better how the whole thing worked. I finally gave up after a week - I've never come across any software that I couldn't install, but Airflow just ended up being too much.

Astronomer has CLI that makes this week a 5 minutes task. https://github.com/astronomer/astro-cli

And it’s free

Re: Dabbling with Dagster vs. Airflow

#50

I recently had the experience of setting up some Prefect pipelines, which I can compare to this article. Note that while I'm not new to data engineering, I'm new to open source frameworks, and have some insight into Airflow (studied architecture in depth, written a lot of code in it). Prefect is generally very easy to use. Essentially, you: (a) write a Python-based flow, which defines some job to run (with subtasks),…

The single best reason to use Prefect is in it's integration with Dask/Ray.

This makes scaling Prefect so much simpler than Airflow.

Post reply on HN