> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
However, maybe the use case here is for team collaboration where the pipelines are easier conveyed through visualizations.
11–20 of 31 posts
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
However, maybe the use case here is for team collaboration where the pipelines are easier conveyed through visualizations.
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
Yeah me too. I think visualizations are cool and can be useful in terms of monitoring the progress of analysis runs. But I can't see my self using a GUI for setting up pipelines when I can do it more explicitly through scripting or some kind of a command line based pipeline framework. However, maybe the use case here is for team collaboration where the pipelines are easier conveyed through visualizations.
Low code tools _can_ (but not necessarily will) effectively empower data teams.
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
Yeah me too. I think visualizations are cool and can be useful in terms of monitoring the progress of analysis runs. But I can't see my self using a GUI for setting up pipelines when I can do it more explicitly through scripting or some kind of a command line based pipeline framework. However, maybe the use case here is for team collaboration where the pipelines are easier conveyed through visualizations.
You make a great point for the use of monitoring the progress of a run. During pipeline runs the visual pipeline interface (also in view only mode during or after running pipeline runs as part of an experiment) can be helpful as a visual indication of where the pipeline failed, how long pipeline steps took to execute and whether certain pipeline steps are still running.
Lastly, for team collaboration we think the visual interface is indeed helpful to explain (especially to the less technical people) the structure of the code, what exactly the pipeline sets out to solve and how the pipeline solves it. In addition, the possibility to add intermediary pipeline steps that serve as dashboards can be helpful for collaboration.
Congratulations! I remember your earlier project: grid studio. Do you support scheduling periodic tasks? Do you support execution triggered with webhook? or some way to expose notebook as REST API?
Currently, tasks can only be scheduled to run at a set time. Could you elaborate a little on why you would want tasks to run periodically? We have some ideas on why this might be helpful, but would love to hear your take on this. (Periodic task scheduling is absolutely something we can add.)
The front-end of the application actually makes calls to our API for multiple things, among which execution of tasks (our internal endpoints can be found here https://github.com/orchest/orchest/tree/master/orchest/orche...). Exposing a (REST) API to the user to interact with the pipeline and start executions is on our roadmap.
I hope this answers your questions.
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
Think like pricing forecasts, decision modelling, marketing segmentation for product design, ....
I think a common thread to these teams -- at least those that I've seen -- is that they consist of stats->DS backgrounds, and no eng->DS backgrounds.
Many of these teams are orchestrating everything within the notebook. I've seen notebooks that contain complex workflows that extend to 10K LOC. I've lost sleep over such things.
Reminds me a bit of https://plynx.com/ , and it's also open source. Is there a major differentiator I'm missing? Also, what is your idea regarding the use case. Why would I need to run it locally for example? Is it mostly about productionizing ML?
I would find a comparison table vs. existing tools useful, to help me consider Orchest by placing it in my existing workflow.
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
I personally agree that this does not seem too useful for any DS team that needs to deploy a model to production. But there are a whole horde of DS teams whose outputs are basically PPT presentations. Think like pricing forecasts, decision modelling, marketing segmentation for product design, .... I think a common thread to these teams -- at least those that I've seen -- is that they consist of stats->DS backgrounds,…
It’s been enough to make me vow to not let people write notebooks that go into prod under my watch lol.
I’m constantly on the watch for software engineering focused tools that solve the issues, rather than data science/engineering focused tools. So many are inextricably linked into python as well, which doesn’t gel nicely with anywhere that has multiple languages in the codebase.
> We're building a visual pipeline tool for data scientists. As a Sr. DS/ML Engineer, this doesn't speak to me.
I personally agree that this does not seem too useful for any DS team that needs to deploy a model to production. But there are a whole horde of DS teams whose outputs are basically PPT presentations. Think like pricing forecasts, decision modelling, marketing segmentation for product design, .... I think a common thread to these teams -- at least those that I've seen -- is that they consist of stats->DS backgrounds,…
It's those 'messy' projects with 10K LoC notebook that could easily be broken up into multiple steps (perhaps some of them notebooks, some of them Python scripts with library function usage) that we feel are a great match for pipelines in Orchest today.
When a team is still experimenting with what models to go with (i.e. trying neural networks v.s. decision trees) it can be helpful to have a more structured prototyping environment with reproducability and easier scalability. Which is also where Orchest shines.
If you want to test some of these models in production, you could easily push artificats to endpoints for serving, in the final steps of a pipeline.