Support mixed model for RandomForestClassificationModel

[wbo4958]

This PR implemented cpu() to convert Cuml RandomForestClassificationModel to Spark RandomForestClassificationModel, and a simple test to predict a single instance can pass. Still, this PR needs to be refactored.

For simplicity, This PR just returned the model JSON string (for CPU inference) alongside the model bytes (for GPU inference), but it increases the bandwidth when collecting from executor to driver which may cause perf issue. We need to find a way to combine them.

There's some difference between Cuml RandomForestClassificationModel and Spark RandomForestClassificationModel.

1. Cuml RandomForestClassificationModel doesn't include GiniStat in the InternalNode
2. Cuml RandomForestClassificationModel uses probability as the leaf value, while Spark RandomForestClassificationModel uses stats (how many instances each label contains), but we can convert the probs to the stats.
3. Cuml RandomForestClassificationModel doesn't have impurity information, but we can calculate it according to the leaf value.

Right now, this PR only supports Gini impurity, I will file a followup to support entropy and variance.

[leewyang]

For simplicity, This PR just returned the model JSON string (for CPU inference) alongside the model bytes (for GPU inference), but it increases the bandwidth when collecting from executor to driver which may cause perf issue. We need to find a way to combine them.

Wonder if you can avoid serializing the model JSON string by just using treelite.dump_as_json() on the driver side, after collecting the trees from the executors. Not sure if that JSON format is compatible/sufficient, but it would avoid serializing the model essentially twice (in treelite and JSON formats).

[lijinf2]

Need assert statements to ensure the predicted results are the same as pyspark predictions.

[wbo4958]

Hmm. The predictions between cuML and pyspark may be different. It's hard to compare the prediction results.

[wbo4958]

build

[wbo4958]

For simplicity, This PR just returned the model JSON string (for CPU inference) alongside the model bytes (for GPU inference), but it increases the bandwidth when collecting from executor to driver which may cause perf issue. We need to find a way to combine them.

Wonder if you can avoid serializing the model JSON string by just using treelite.dump_as_json() on the driver side, after collecting the trees from the executors. Not sure if that JSON format is compatible/sufficient, but it would avoid serializing the model essentially twice (in treelite and JSON formats).

Thx @leewyang, it seems that cuML model is not compatible with treelite model.

treelite_json = cu_rf.convert_to_treelite_model().dump_as_json()
AttributeError: 'cuml.fil.fil.TreeliteModel' object has no attribute 'dump_as_json'

[leewyang]

Wonder if this might be useful: rapidsai/cuml#3853
Sounds like it'd require an extra serialize/deserialize to disk to get it to the actual treelite model class, but presumably this would only need to be done on the driver.

Otherwise, LGTM. (Also, pls remove "[DRAFT]" if ready for review).

[eordentlich]

We should consider a gpu version of this where we have all the supporting metrics needed to construct the summary also implemented on gpu.

[eordentlich]

In future work.

[wbo4958]

Good suggestion, Let me file a task for it.

[wbo4958]

Wonder if this might be useful: rapidsai/cuml#3853 Sounds like it'd require an extra serialize/deserialize to disk to get it to the actual treelite model class, but presumably this would only need to be done on the driver.

Otherwise, LGTM. (Also, pls remove "[DRAFT]" if ready for review).

Really good, Seems we can just return the json strings of treelite in the executor side according to the example of that PR. Great. Thx, I will file a follow up for it.

[wbo4958]

build

[wbo4958]

build