Как я запускал классификацию изображений на домашнем кластере Apache Ignite ML

Добрый день, @Demschwarz я один из авторов Ignite ML, хотел бы прокомментировать вашу статью.

Во-первых, вам огромное спасибо за то, что подробно зафиксировали свой опыт как пользователя от начала до конца - это очень ценно для разработчиков OSS проектов, чей глаз давно замылен, все настройки пророщены, тестовые кластера гоняются по много раз, а некоторые вещи кажутся очевидными и существуют только в голове.

Во - вторых, я хотел бы поделиться своей статьей непосредственно относящейся к исследованиям производительности отдельных алгоритмов ML на кластере из 1,2 или 4 машин в Amazon. Среди них есть и SVM, но там решается задача бинарной классификации.

Вот ссылка.

Сразу оговорюсь, это не какой-то официальный бенчмарк, а мое личное исследование.

В - третьих, вы безусловно правы, стартовое руководство, обещающее легкую прогулку, неполно и подходит, как мне кажется уже опытным пользователям Ignite, а не тем, кто например, только хочет попробовать машинное обучение.

В - четвертых, исходя из моего опыта, все это хорошо и стабильно работает, в том числе на довольно больших кэшах, когда у вас кластер с нодами, каждая из которых имеет много оперативки (кратно больше 8Gb, например 40Gb или 80Gb), и достаточный размер DataRegionConfiguration.maxSize - например 10Gb.

В - пятых, есть большая проблема с тем, как корректно делать бенчмарки для ML тренировки, это время сильно зависит от следующих вещей: значений гиперпараметров алгоритма, критерия остановки, количества партиций (в случае Ignite), настроек JVM и GC, количества машин (ведь мы хотим еще увидеть эффект масштабирования) и выделенной там RAM и CPU - ресурсов.

В - шестых, вы используете довольно нетривиальный способ загрузки данных, кладете данные в ресурсы и полагаетесь на механизм загрузки для мелких датасетов из примеров. Он там прост и не оптимален, конечно. На самом деле, есть продвинутые техники вливания данных в кэши и таблицы и они за рамками моих статей и в целом Apache Ignite ML исходит из того, что данные уже кто-то куда-то поместил и разместил и нам остается их только отпроцессить и построить модель на них.

В - седьмых, в моей статье, указанной выше я делюсь своими гипотезами о некоторых зависимостях между алгоритмом ML, количеством машин и временем тренировки в зависимости от количества доступной памяти и числа партиций (многомерный кубик такой получается). Все таки большинство алгоритмов демонстрируют ускорение вычислений в зависимости от числа машин, но есть и парочка алгоритмов, которые в силу своей природы и закона Амдала плохо распределяются и имеют ограниченный эффект по ускорению (благо, хоть не замедляются в десятки раз) при увеличении количества нод в кластере. Что характерно, кстати и для Apache Spark ML, и для H2O. Просто некоторые (но не SVM, конечно) алгоритмы весьма плохи для распределения.

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

Прочтя это, вы скажете, стоп, почему я не мог это прочесть в офф.доке и столько мучился? Я вас понимаю, сочувствую, но могу пока сказать, что это оборотная сторона OSS, и вы написав эту статью уже стали частью проекта и сообщества, спасибо вам за это.