[ 
https://issues.apache.org/jira/browse/SPARK-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151486#comment-14151486
 ] 

Mridul Muralidharan commented on SPARK-3714:
--------------------------------------------


Most of the drawbacks mentioned are not severe imo - at best, they are 
unfamiliarity with oozie platform (points 2, 3, 4, 5).
Point 1 is interesting (sharing spark context) - though from a fault tolerance 
point of view, it makes supporting it challenging; ofcourse oozie was not, 
probably, designed with something like spark in mind - so there might be 
changes to oozie which might benefit spark; we could engage with oozie dev for 
that.

But discarding it to reinvent something when oozie already does everything 
mentioned in requirements section seems counterintutive.


I have seen multiple attempts to 'simplify' workflow management, and at 
production scale almost everything ends up being similar ...
Note that most production jobs have to depend on a variety of jobs - not just 
spark or MR - so you will end up converigng on a variant of oozie anyway :-)

Having said that, if you want to take a crack at solving this with spark 
specific idioms in mind, it would be interesting to see the result - I dont 
want to dissuade from doing so !
We might end up with something quite interesting.

> Spark workflow scheduler
> ------------------------
>
>                 Key: SPARK-3714
>                 URL: https://issues.apache.org/jira/browse/SPARK-3714
>             Project: Spark
>          Issue Type: New Feature
>          Components: Project Infra
>            Reporter: Egor Pakhomov
>            Priority: Minor
>
> [Design doc | 
> https://docs.google.com/document/d/1q2Q8Ux-6uAkH7wtLJpc3jz-GfrDEjlbWlXtf20hvguk/edit?usp=sharing]
> Spark stack currently hard to use in the production processes due to the lack 
> of next features:
> * Scheduling spark jobs
> * Retrying failed spark job in big pipeline
> * Share context among jobs in pipeline
> * Queue jobs
> Typical usecase for such platform would be - wait for new data, process new 
> data, learn ML models on new data, compare model with previous one, in case 
> of success - rewrite model in HDFS directory for current production model 
> with new one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to