Pyspark Почему GroupBy (и GroupBy с count ()) по результатам GBMClassifier дает противоречивый результат - PullRequest
Новая
       80

Pyspark Почему GroupBy (и GroupBy с count ()) по результатам GBMClassifier дает противоречивый результат

0 голосов
/ 03 мая 2019

В Pyspark у меня загружен большой набор данных, который я запускаю через свой GBMClassifier.Перед обучением / примеркой выполнение группового задания на входных данных дает ожидаемые результаты (значения суммируются с ожидаемым количеством и т. Д.).Однако после подгонки тестовых данных использование GroupBy в прогнозах не дает воспроизводимых результатов.Я пытаюсь создать базовую Точность / Вспомнить, поэтому я пытаюсь разделить на группы по меткам и прогнозам.Результаты, которые выводятся, не меняются в огромных количествах, но перемещаются и не являются надежными.Я не использовал MultiClassMetrics, потому что я хочу исследовать различные пороговые значения вероятности классификации, однако на данный момент он будет открыт для него.Я не смог получить свой выходной DataFrame в формате, который поддерживает MultiClassMetrics.

Я пробовал GroupBy с Count (), а также фильтрацию по конкретным наборам данных, чтобы увидеть, если использовать два разныхподходы могут привести к различным результатам (т. е. если данные в столбце не были сопоставлены фильтром)

Стоит отметить, что я работаю над AWS в ноутбуках EMR, в кластере из 4 узлов. 

train_df=splits[0]
test_df=splits[1]

gbm = GBTClassifier(stepSize=0.1, seed=2018)

model_gbm = gbm.fit(train_df)
prediction_gbm = model_gbm.transform(test_df)

#Split the probability column into two values to allow assessment of different classification thresholds
prediction_gbm = (prediction_gbm.withColumn("probability_split",to_array(col("probability")))        .withColumn('prob_norm',col("probability_split")0]).withColumn('prob_fraud',col("probability_split")[1]))

#Test a new threshold

newPrediction = when(col('prob_fraud')>0.5,1).otherwise(0)
prediction_gbm = prediction_gbm.withColumn('newPrediction',newPrediction)

#This section simply prints the results of my grouping. This is what is producing inconsistent results
gbm_FN=prediction_gbm.filter((F.col('label')==1) & (F.col('newPrediction')==0)).count()
gbm_FP=prediction_gbm.filter((F.col('label')==0) & (F.col('newPrediction')==1)).count()
gbm_TP=prediction_gbm.filter((F.col('label')==1) & (F.col('newPrediction')==1)).count()
gbm_TN=prediction_gbm.filter((F.col('label')==0) & (F.col('newPrediction')==0)).count()

#Here is the groupBy code as well for clarification
prediction_gbm.groupBy(['label','prediction']).count().show()

Я ожидаю, что выходные значения для 4 групп меток и прогнозов будут последовательно складываться.Кроме того, я ожидал бы, что результаты группировки будут такими же, как и у 4-х произведенных значений, и сложатся в одно и то же значение.

РЕДАКТИРОВАТЬ: при обучении моей модели я получаю эту ошибку напервый проход, но после этого, когда я запускаю его, я не вижу этой проблемы: 

Traceback (most recent call last):
  File "/opt/conda/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/opt/conda/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/conda/lib/python3.6/site-packages/awseditorssparkmonitoringwidget-1.0-py3.6.egg/awseditorssparkmonitoringwidget/cellmonitor.py", line 178, in cell_monitor
    job_binned_stages[job_id][stage_id] = all_stages[stage_id]
KeyError: 905

1 Ответ

0 голосов
/ 15 мая 2019

Я потратил некоторое время, играя с этим, и кажется, что проблема с непоследовательными результатами была вызвана функцией randomSplit (), которую я не включил в свой первоначальный ответ.Решение состояло в том, чтобы кэшировать кадр данных перед разделением.Больше информации здесь: Как Spark отслеживает расщепления в randomSplit?

Что касается ошибки, то это, по-видимому, тайм-аут из PySpark.Немного возни с предположением, что это может быть ошибка нехватки памяти, но ее трудно отладить в ноутбуке EMR.Этого не происходит при непосредственном использовании spark-submit для главного узла, что говорит о том, что он, возможно, основан на памяти, поскольку вы можете увеличить объем памяти в режиме spark-submit, пока это не так просто в ноутбуке.

...