Кластеризация гистограммы с помощью (Py)Spark для сокращения данных

Я хочу сгруппировать различные распределения вероятностей в виде гистограмм. У меня есть набор данных с> 10 млн наблюдений. Одно наблюдение имеет 5 различных гистограмм (> 100 признаков). Целью кластеризации является сокращение данных путем создания кодовой книги/прототипов, с помощью которых я могу представлять распределения исходного набора данных.

Теперь я не уверен, что это лучший способ сделать это. Идеи:

  • Использование нормального алгоритма k-средних искрового мл с евклидовыми расстояниями.
  • Попробуйте реализовать другую меру расстояния для k-средних на искре (например, Кульбак Лейблер, Дженнсен Шеннон) (https://github.com/derrickburns/generalized-kmeans-clustering или http://www.scalaformachinelearning.com/2015/12/kullback-leibler-divergence-on-apache.html)
  • Внедрите SOM в Spark для кластеризации распределений с использованием пользовательских функций расстояния (не уверен, что это возможно для такого большого набора данных. Можно ли создать собственный алгоритм в Spark, который будет работать поэтапно, но требует объединения результатов в каждый шаг?)

Как бы вы оценили идеи? Осуществимы ли они? Я упускаю из виду явно более эффективное/простое решение? Любые подсказки будут очень признательны!


person MosbyT    schedule 10.02.2019    source источник
comment
Являются ли гистограммы нормализованными (сумма 1) и однородными (одинаковая группировка для каждой строки)? Имеет ли смысл обрабатывать 5 разных гистограмм отдельно?   -  person Has QUIT--Anony-Mousse    schedule 11.02.2019
comment
Пока ваши данные помещаются в ОЗУ, я бы изучил альтернативы Spark, которые имеют лучшие и более быстрые алгоритмы. Для изучения кодовой книги выборка строк должна быть такой же хорошей, например, только 1 миллион строк.   -  person Has QUIT--Anony-Mousse    schedule 11.02.2019
comment
Спасибо за комментарии! Гистограммы нормализованы, но имеют два разных биннинга (2 одинаковых - 3 одинаковых). Я не уверен, есть ли смысл рассматривать их отдельно. Все они представляют разные части, например. Ускорение, Скорость.   -  person MosbyT    schedule 11.02.2019
comment
Итак, вы предлагаете что-то вроде: выборка строк, а затем использование Tensorflow на машине с большим количеством оперативной памяти для обучения? Это не был бы метод выборки, который отбирает данные на основе меры подобия, такой как расхождение Дженсена-Шеннона, наиболее полезной для моей цели (сокращения данных).   -  person MosbyT    schedule 11.02.2019
comment
Нет необходимости использовать Tensorflow. С другой стороны. Забудьте об этих инструментах для работы с большими данными. У них есть только медленный алгоритм Ллойда. Но лучшие алгоритмы (которые не являются наивными параллельными и, следовательно, их нелегко портировать на Spark, а не на Tensorflow) в 100 раз быстрее.   -  person Has QUIT--Anony-Mousse    schedule 12.02.2019
comment
У меня сложилось впечатление, что алгоритм искры k-средних (параллельный k-средних с k-средних|| инициализацией) вполне эффективен? Или, по крайней мере, достаточно производительный для моего набора данных. Я борюсь с реализацией производительной версии SOM на Spark, хотя. Вопрос заключается в том, не имеет ли SOM смысла для большого набора данных с >100 функциями, потому что алгоритмические требования (количество требуемых итераций и т. д.) слишком высоки, или SOM не имеет смысла в Spark, или SOM не имеет смысла без выборки? Спасибо!   -  person MosbyT    schedule 12.02.2019
comment
Я никогда не был убежден в SOM вообще. Предполагается, что у вас уже есть хорошее сходство во входном домене. По моему опыту, Spark kmeans работает довольно медленно. Но kmeans быстрый (в частности, если вы устанавливаете слабые пределы допуска), вы можете просто не знать, насколько быстрым он может быть... И есть есть различия в качестве результата: здесь Spark выдает гораздо большие ошибки, чем sklearn stackoverflow.com/questions/50406096/   -  person Has QUIT--Anony-Mousse    schedule 13.02.2019