What is our primary use case?
My main use case for
Dagster Labs is to write pipelines to orchestrate things. My main pipeline that I have built and most used is a data extraction pipeline that extracts data from different data sources and converts them into a final delta table. I have developed all of this using
Dagster Labs, and it involves using Python, Spark, and other tools.
A unique workflow I have developed is that I have completely automated all the pipelines by using sensors that Dagster Labs provides by default. This is my main use case and a unique flow that I have developed. Since automating with Dagster Labs, I save around 90% of manual effort. I monitor Dagster Labs jobs once a week to check whether everything is working fine, but other than that, I never open Dagster Labs to see how jobs are processing.
What is most valuable?
One of the best features Dagster Labs offers is its Python-based orchestrator, which is very useful. It also supports various things, including hosting Dagster Labs in
Snowflake and also on a VM level. Furthermore, it supports various sources such as Spark and other different sources, and it has a wide range of sources that I can connect using Dagster Labs.
What makes the Python-based orchestrator in Dagster Labs stand out for me compared to others is hosting Dagster Labs on Snowflake, which is a very useful feature because due to the heavy pipelines that I run, Snowflake eases my tasks by scaling up and down. Connecting to different sources, I mostly use Spark jobs for submitting Spark jobs directly from Dagster Labs.
Dagster Labs has positively impacted my organization by increasing efficiency because I automated all my pipelines using sensors in Dagster Labs, which reduced a lot of manual effort and less manual intervention. Unless there is a major issue with data or something else, there is no need for manual intervention, and everything goes smoothly.
What needs improvement?
One major issue I see with Dagster Labs is with retrying the pipeline. Of course, there is a retry of the pipeline available in case it fails, but it starts from the beginning at the first step. Many other orchestrators I previously used, such as
Azure Data Factory, allow retry from the step of failure. However, in Dagster Labs, it is not possible because it runs on Dagster ephemeral containers and must start a container again, so that feature is something I miss.
Smaller pain points include that after I switched from native Dagster Labs to Snowflake, some of the GraphQL APIs started failing; they load only when I load on the browser for the first time or when I have to clear the cache. Sometimes the GraphQL APIs silently fail, which shows the health of the pipelines that have been run in the last 24 hours; I haven't debugged much into it because it's not impacting much, but it could provide some useful metrics.
Dagster Labs handles scheduling and monitoring of pipelines fairly well; however, one issue while scheduling jobs is that I can't trigger another job from another job. If job A succeeds, I can't directly trigger job B from job A. The only possibility I see is using schedule sensor-based jobs, where I poll the current job, and once that current job succeeds, I trigger another job. It's an alternate way, but it would be useful if there was the functionality of triggering job B from job A.
For how long have I used the solution?
I have been using Dagster Labs for the past three years.
What do I think about the stability of the solution?
Dagster Labs is stable in my experience; initially, the UI was tricky, but now the UI looks good and it is more stable.
What do I think about the scalability of the solution?
Dagster Labs's scalability is very good; it supports deployment on
Kubernetes and scales up well when there is a need and scales down when there is no need.
How are customer service and support?
I haven't needed to reach out for help regarding Dagster Labs customer support until now.
How was the initial setup?
Onboarding and training my team to use Dagster Labs presented some challenges; the documentation of Dagster Labs is really tricky and difficult for anyone learning any orchestrator tool for the first time. However, since I have prior experience, it was kind of easy compared to others when I started learning it. Better documentation would have facilitated better onboarding of new members.
What was our ROI?
The time saved is evident in the reduction of manual intervention to monitor pipelines; previously, I manually triggered jobs for different data extractions, but since everything is automated now, manual intervention has reduced by about 90%. Unless there is development of a new pipeline on Dagster Labs, I generally don't actively monitor the ongoing jobs.
Which other solutions did I evaluate?
I evaluated
Airflow as an option before choosing Dagster Labs.
What other advice do I have?
When selecting Dagster Labs, one of the key criteria was that I initially thought of
Airflow as an alternate, but I chose Dagster Labs because it is new and also open source. Documentation could have been better.
My advice for others looking into using Dagster Labs is to first understand all the functionalities that Dagster Labs offers; take a little bit of time to try and explore all the features, and then it's better to go into implementation. That way, you can design your pipelines better.
I chose eight out of 10 because of the retry issue I mentioned earlier; I would have rated it 10 out of 10 if there was an option to retry the pipeline from the point of failure. It would be great if the feedback items could be released in upcoming versions.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other