fast model evaluation about mist

[spushkarev]

Thanks @geoHeil
We were looking at mleap but we do not feel comfortable to invent yet another model serialization format and re-writing mllib local.
There is a parallel activity in Spark community for separating and re-writing mllib local https://issues.apache.org/jira/browse/SPARK-13944 . So, our current solution should be aligned with these changes.

[geoHeil]

@spushkarev v0.8 seems to support Fast local ML serving (experimental) but it is unclear to me how to configure that.

[spushkarev]

Hi @geoHeil . Yes, we have "silently" released experimental code for 2 ml models. We are working on remaining ml models and documentation. It will be officially released within 2-3 weeks.

[geoHeil]

https://github.com/Hydrospheredata/mist/blob/master/docs/use-cases/ml-realtime.md you mention

We are going to add this abstract entry point in future releases.
could you clarify what you mean with abstract entry point / when this is supposed to happen. Thanks.

Additionally, could you explain what LocalDataColumn is, especially the difference to a normal spark data frame (when considering a local spark context)

Do I understand correctly that MIST will still use a local spark context for its fast model evaluation?

What if a popular algorithm like https://github.com/dmlc/xgboost/tree/master/jvm-packages is used to build the model (relies on JNI and C dependencies) MIST will not "work around it" as PMML would do to increase the speed of scoring.

[spushkarev]

@geoHeil

1. By "Abstract entry point" I mean that it is easy to write the base Mist job which accepts "model name" or "model UUID" in parameters and serves that model. It might be used for internal/debug use. It's not a priority for the moment for us, but you could try to add it yourself.

2. LocalDataColumn is just a local in memory data structure, arrays (in opposite to distributed DataFrame). It operates with local transformations while having the same interface as DataFrame.

3. Local serving do not use SparkContext at all.

4. I'm not sure I follow your question. If xgboost is trained in Spark and saved into parquet we'll be able to serve it the same as we do it with MLLib using xgboost core. This solution is better in terms of usability (everything in one context, no export/import), predictability (the same code base is used for training and serving) and performance.

[geoHeil]

Regarding 4 Xgboost is using its native c dependencies to score the model. It would be great if there was a way similar to pmml to score without these dependencies to serve more predictiond spushkarev <[email protected]> schrieb am So. 8. Jan. 2017 um 10:58:

…

@geoHeil <https://github.com/geoHeil> 1. By "Abstract entry point" I mean that it is easy to write the base Mist job which accepts "model name" or "model UUID" in parameters and serves that model. It might be used for internal/debug use. It's not a priority for the moment for us, but you could try to add it yourself. 2. LocalDataColumn is just a local in memory data structure, arrays (in opposite to distributed DataFrame). It operates with local transformations while having the same interface as DataFrame. 3. Local serving do not use SparkContext at all. 4. I'm not sure I follow your question. If xgboost is trained in Spark and saved into parquet we'll be able to serve it the same as we do it with MLLib using xgboost core. This solution is better in terms of usability (everything in one context, no export/import), predictability (the same code base is used for training and serving) and performance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnc9AAvCJZmEc0_k7pARfj2HtFb4mulks5rQLNEgaJpZM4LJuKz> .

[geoHeil]

Will only data frame operations work? Or will RDD be supported as well? Georg Heiler <[email protected]> schrieb am So. 8. Jan. 2017 um 12:18:

…

Regarding 4 Xgboost is using its native c dependencies to score the model. It would be great if there was a way similar to pmml to score without these dependencies to serve more predictiond spushkarev ***@***.***> schrieb am So. 8. Jan. 2017 um 10:58: @geoHeil <https://github.com/geoHeil> 1. By "Abstract entry point" I mean that it is easy to write the base Mist job which accepts "model name" or "model UUID" in parameters and serves that model. It might be used for internal/debug use. It's not a priority for the moment for us, but you could try to add it yourself. 2. LocalDataColumn is just a local in memory data structure, arrays (in opposite to distributed DataFrame). It operates with local transformations while having the same interface as DataFrame. 3. Local serving do not use SparkContext at all. 4. I'm not sure I follow your question. If xgboost is trained in Spark and saved into parquet we'll be able to serve it the same as we do it with MLLib using xgboost core. This solution is better in terms of usability (everything in one context, no export/import), predictability (the same code base is used for training and serving) and performance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnc9AAvCJZmEc0_k7pARfj2HtFb4mulks5rQLNEgaJpZM4LJuKz> .

[spushkarev]

1. Need to take a look deeper into xgboost. In general I think that re-using dependencies is better than re-implementing it and then maintaining compatibility.
2. LocalData structure supports only minimal set of methods required for Pipeline.transform

[dos65]

We started hydro-serving project to solve ml serving problem