Thanks all for your advice. As I understand in layman's term if I had two applications running successfully where app 2 was dependent on app 1 I would finish app 1, store the results in HDFS and the app 2 starts reading the results from HDFS and work on it.
Using Alluxio or others replaces HDFS with in-memory storage where app 2 can pick up app1 results from memory or even SSD and do the work. Actually I am surprised why Spark has not incorporated this type of memory as temporary storage. Dr Mich Talebzadeh LinkedIn * https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* http://talebzadehmich.wordpress.com *Disclaimer:* Use it at your own risk. Any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on this email's technical content is explicitly disclaimed. The author will in no case be liable for any monetary damages arising from such loss, damage or destruction. On 27 October 2016 at 11:28, Mich Talebzadeh <mich.talebza...@gmail.com> wrote: > > There was a mention of using Zeppelin to share RDDs with many users. From > the notes on Zeppelin it appears that this is sharing UI and I am not sure > how easy it is going to be changing the result set with different users > modifying say sql queries. > > There is also the idea of caching RDDs with something like Apache Ignite. > Has anyone really tried this. Will that work with multiple applications? > > It looks feasible as RDDs are immutable and so are registered tempTables > etc. > > Thanks > > > Dr Mich Talebzadeh > > > > LinkedIn * > https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw > <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* > > > > http://talebzadehmich.wordpress.com > > > *Disclaimer:* Use it at your own risk. Any and all responsibility for any > loss, damage or destruction of data or any other property which may arise > from relying on this email's technical content is explicitly disclaimed. > The author will in no case be liable for any monetary damages arising from > such loss, damage or destruction. > > >
