Live data from Hacker News

Show HN: Orchest – Data Science Pipelines

news.ycombinator.com

11–20 of 31 posts

Re: Show HN: Orchest – Data Science Pipelines

#11
post #8

> 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.

Re: Show HN: Orchest – Data Science Pipelines

#13
post #11
post #8

> 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.

There's a large tradition of data analysis/BI tools using visual programming/ "no-code" tools, think Talend, etc. They're popular since data analysis typically contains a number of people without coding backgrounds. Even among data science teams, many don't have the engineering background of data engineers (and certainly there's a segment of data scientists who don't care as much about building the data pipelines and the cleaning that's necessary).

Low code tools _can_ (but not necessarily will) effectively empower data teams.

Re: Show HN: Orchest – Data Science Pipelines

#14
post #11
post #8

> 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.

Thanks for your input. We are planning to also support an API and/or CLI (besides the GUI) to set up the pipelines through scripting. Depending on what we hear from the community we will definitely add this sooner rather than later.

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.

Re: Show HN: Orchest – Data Science Pipelines

#16

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?

Grid Studio is indeed the project Rick worked on before starting to work on Orchest. Great to hear that you are familiar with it.

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.

Re: Show HN: Orchest – Data Science Pipelines

#17
post #8

> 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, 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.

Re: Show HN: Orchest – Data Science Pipelines

#18

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?

Similarly, there seems to be partial overlap with MLFlow for tracking iterations.

I would find a comparison table vs. existing tools useful, to help me consider Orchest by placing it in my existing workflow.

Re: Show HN: Orchest – Data Science Pipelines

#19
post #17
post #8

> 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,…

I agree, and so many data science and data engineering tools all seem to revolve around using notebooks, much to my frustration. I’ve worked in places whose data pipelines were built around seemingly infinite notebooks, all containing consistently poor software engineering.

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.

Re: Show HN: Orchest – Data Science Pipelines

#20
post #17
post #8

> 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,…

Currently, we are not focused on helping DS teams putting models into production.

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.

Post reply on HN