Дело продвигается довольно успешно, с учетом того, что Kotlin - экосистема не является тут первопроходцем. Догоняющее развитие требует меньше ресурсов и позволяет срезать углы, чем мы успешно занимаемся.
Я тоже have a dream, что через несколько лет, многие важные и простые вещи связанные с анализом данных/ML можно будет делать спокойно на своем языке программирования, таком как Kotlin/C#/Go и т.д., этот процесс идет с разной скоростью во всех таких экосистемах.
Вы написали
Однако, официальная библиотека от JetBrains дала бы большой толчок в этом направлении.
KotlinDL - это официальная библиотека от JetBrains, на которой можно эффективно решать задачи классификации/регрессии из классического ML, вот примеры.
Если говорить о других алгоритмах и конструкциях, а-ля деревья, случайный лес, knn, различный числовой препроцессинг - то они в планах на первую половину 2022 и их выход сейчас сильно зависит от темпов развития другой библиотеки, multik - либы для эффективных вычислений над векторами и матрицами (сейчас KotlinDL использует вычислительное ядро TensorFlow, но оно не дает все, что нам нужно)
Добрый день, @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, и вы написав эту статью уже стали частью проекта и сообщества, спасибо вам за это.
В плане Kafka можно попробовать сделать основной упор на визуализацию топологии, которая может менять в real-time и постепенно распространить на остальные Apache-фреймворки.
Было бы довольно перспективно добавить несложную систему мониторинга для Ignite-кластера, с визуализацией топологии, простыми метриками живучести и просмотром содержимого в таблицах или кэшах.
На самом деле, есть еще Datalore от JetBrains (похоже на Colab, тоже с квотами бесплатных вычислений), там работает тот же kernel для Kotlin, только вчера там писал
Мне казалось, что Lena Hall больше практик, чем теоретик (я подписан на нее в твиттере), ближе к DevOps, будет интересно потом глянуть на ее теоретическую сторону.
Добрый день, все матричные и векторные операции происходят на движке TensorFlow в нативной памяти. Реализации на JVM у KotlinDL нет (по крайней мере пока).
А если все-таки мы бы хотели оставить подсчет глобальны метрик на стороне Ignite-кластера, может стоило бы для этого поднимать каку-то MetricsNode, в которую бы все стекалось. Или мини-Ignite кластер или какой-ниудь сторонний, но embedded сервис?
Если вам хочется запилить кусок ML на Java поверх Ignite, то у нас (коммьюнити пилящих) есть много разных полезных задач, пишите мне в личку тут или в соц.сетках, указанных выше.
Спасибо, в ворохе шума, как-то пропустил этот тип архитектуры. Статья обзорная, но поможет тем, кто занимается машинным обучением в проде, применяя разные подходы, а не является диванным архитектором нейросеток, читающим все новинки.
С точки зрения сохранности драгоценных петабайт — да, с точки зрения того, что и чтение может быть неэффективным и сканить все и быть CPU Burst на нашем едином кластере — пусть учатся на локальны машинка вместо 2 Гб занимать 1 Гб, как вы считаете?
Спасибо, буду пробовать, понравится — буду рекомендовать. Но в целом, уверенному в себе Java-разрабу, собрать скелет проекта с Sbt и найти верные зависимости в maven central будет более чем полезно, как вы считаете?
Чтобы прочувствовать, да, так и есть, можно даже петабайты взять, хотя вы самостоятельно можете себе урезать выч.ресурсы и все будет почти тоже самое (например взять кластер из 8 ядерных машинок по 16GB). Особо большого выигрыша от уборки хипа в десятки GB тут и нет.
А чтобы освоить Spark API на базовом уровне, до того как тебя подпустят к терабайтам и петабайтам — вполне хватит самостоятельной работы с опорой на источнике.
Согласитесь, подпускать к драгоценным терабайтам бойца, который не знает что такое Parquet и пытается сам оптимизировать руками набор операций над DataFrame-ом — не стоит, пусть подучит матчасть.
Про Python — не знал про ограничения API, впрочем обычная ситуация, когда Scala API уехало вперед.
С учетом очень слабеньких ручейков других JVM — языков с показом их связки с Java именно в России, их надо поддерживать. На самостоятельные конференции рассчитывать сложно, верю в трек JVM languages в будущем:)
Дело продвигается довольно успешно, с учетом того, что Kotlin - экосистема не является тут первопроходцем. Догоняющее развитие требует меньше ресурсов и позволяет срезать углы, чем мы успешно занимаемся.
Я тоже have a dream, что через несколько лет, многие важные и простые вещи связанные с анализом данных/ML можно будет делать спокойно на своем языке программирования, таком как Kotlin/C#/Go и т.д., этот процесс идет с разной скоростью во всех таких экосистемах.
Вы написали
KotlinDL - это официальная библиотека от JetBrains, на которой можно эффективно решать задачи классификации/регрессии из классического ML, вот примеры.
Если говорить о других алгоритмах и конструкциях, а-ля деревья, случайный лес, knn, различный числовой препроцессинг - то они в планах на первую половину 2022 и их выход сейчас сильно зависит от темпов развития другой библиотеки, multik - либы для эффективных вычислений над векторами и матрицами (сейчас KotlinDL использует вычислительное ядро TensorFlow, но оно не дает все, что нам нужно)
Добрый день, @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, и вы написав эту статью уже стали частью проекта и сообщества, спасибо вам за это.
В плане Kafka можно попробовать сделать основной упор на визуализацию топологии, которая может менять в real-time и постепенно распространить на остальные Apache-фреймворки.
Было бы довольно перспективно добавить несложную систему мониторинга для Ignite-кластера, с визуализацией топологии, простыми метриками живучести и просмотром содержимого в таблицах или кэшах.
А вот список библиотек доступных с полоборота в ноутбуке
Кстати, буквально на этой неделе вышел второй релиз, там много чего интересного https://blog.jetbrains.com/kotlin/2021/05/kotlin-dl-0-2/
Между тем, у нас есть numpy обёрнутый на Kotlin
Кроме того, у нас в отделе разрабатывается библиотека эффективных матричных операций на чистом Kotlin (+ дополнительный wrapper для OpenBlas).
Если вам хочется запилить кусок ML на Java поверх Ignite, то у нас (коммьюнити пилящих) есть много разных полезных задач, пишите мне в личку тут или в соц.сетках, указанных выше.
А чтобы освоить Spark API на базовом уровне, до того как тебя подпустят к терабайтам и петабайтам — вполне хватит самостоятельной работы с опорой на источнике.
Согласитесь, подпускать к драгоценным терабайтам бойца, который не знает что такое Parquet и пытается сам оптимизировать руками набор операций над DataFrame-ом — не стоит, пусть подучит матчасть.
Про Python — не знал про ограничения API, впрочем обычная ситуация, когда Scala API уехало вперед.