Комплексный анализ данных и машинное обучение: 8 причин для миграции с Wolfram Mathematica на Python/R
В качестве Пролога. В январе 2016 года мы объявили об очередном изменении технической политики в области Математического моделирования, Комплексного анализа данных и Высокопроизводительных вычислений. Основная суть изменений: область применения Wolfram Mathematica существенно сузилась, ограничившись собственно математическими задачами: аналитическими (символьными) вычислениями и численными расчётами. При этом задачи комплексного анализа данных и статистической обработки были переведены на языки программирования Python и R. Причём процесс перехода на новую технологическую платформу начался существенно ранее – весной 2015 года. Теперь, по прошествии года с лишним, и по результатам успешного выполнения нескольких проектов, можно с уверенностью констатировать, что данное решение было не только верным, но и весьма своевременным.
Перед изложением основных причин, побудивших нас на переход, а также плюсов и минусов предложенного решения, отметим, что в основе всего изложенного ниже лежит квинтэссенция нашего опыта и задач, поэтому суждения вполне могут быть субъективными. Кроме того, многие приведённые критические замечания применимы не только к Wolfram Mathematica, но и к MathWorks MatLAB, и к другим подобным системам.
Итак, в июле 2013 года мы ввели Wolfram Mathematica в статус главной платформы для построения математических моделей и проведения численных расчётов. История и мотивы данного решения достаточно подробно изложены в нашем посте. Задачи комплексного анализа данных и статистической обработки также в основном решались в этом же инструменте. Можно сказать, что это было золотое время 9-й версии программы: необходимости в других платных решениях, таких как MatLAB, Statistica, SAS и т.п. – не возникало абсолютно, так как широкий набор функций Mathematica покрывал 80% аналитических задач, а для оставшихся 20% разрабатывались самописные пакеты расширения для неё же (при этом за счёт наличия высокоуровневых функций, затраты на разработку и отладку кода были весьма малыми). Для существенно специфических задач статистики использовался R, через вызов его функций из среды Mathematica посредством её стандартного пакета расширения RLink. Подобный баланс между нашими потребностями и путями их удовлетворения существовал достаточно продолжительное время: мы мониторили другие инструменты (как платные, так и бесплатные, в основном последние), тестировали их, фиксировали изменения, но ничего не меняли: Mathematica оставалась главной «рабочей лошадкой». Но все периоды стабильности, как известно, рано или поздно, заканчиваются.
Весной 2015 года, ситуация изменилась скачкообразно и фактическая монополия Wolfram Mathematica внутри нашей группы была нарушена. Этому способствовала конвергенция нескольких независимых событий. В числе основных:
Во-первых, вышла новая версия R v3.2.0. В ней упор был сделан на оптимизацию быстродействия и работу с данными большого объёма (например, операции cbind/rbind над матрицами, содержащими более 2-х млрд. элементов выполнялись без каких-либо ограничений). Стабильность функционирования ядра R при высоких нагрузках также стала весьма высокой. Таким образом, систему R стало возможно применять для анализа данных большого объёма. В свою очередь, это выявило ряд существенных недостатков подхода на основе вызова функций R из среды Mathematica:
Интерфейс RLink содержал протечку по памяти, что приводило к аварийным ситуациям, при многократном вызове функций R.
Из-за применения Java Runtime Environment, интерфейс RLink существенно ограничивал возможности по перекачке больших объёмов данных между R и Mathematica, приводил к оверхеду по памяти.
Реализация более менее сложных и/или эффективных методик анализа данных большого объёма в R всё равно требовала хорошего владения этим языком программирования, например в части избавления от циклов, путём их замены на вызов функций семейства ?apply. Таким образом, проще было разработать полноценное приложение для системы R, чем городить мосты между Mathematica и R.
Во-вторых, вышла новая версия Сaffe – отличного фреймворка для работы c глубокими свёрточными нейронными сетями. В ней была улучшена поддержка библиотеки NVIDIA cuDNN v2 предназначенной для ускорения вычислений на GPU, введены новые слои и расширен интерфейс с Python. Анализ ситуации позволил сделать два основных вывода:
Разработка и поддержка собственных «велосипедов» для решения типовых задач Deep Learning потеряло всякий смысл, кроме учебно-методического.
Существовавшая определённая монополия и мода на применение MatLAB в решении научно-исследовательских задач в области глубокого обучения – закончилась. На арену вышел и стремительно захватил лидерство Python.
В-третьих, вышла 0.7-я версия библиотеки Theano – отличного инструмента для разработки и исследования нетривиальных алгоритмов Deep Learning. Это ещё более упрочило позиции языка Python на арене решений для глубокого обучения.
В-четвёртых, вышла новая версия Wolfram Mathematica, это был минорный релиз 10.1. С его выходом стало окончательно ясно, что анонсировавшиеся перед выходом «десятки» тектонические сдвиги в области Machine Learning фактически оказались не более чем «детской игрушкой». В числе сильнейших ограничений:
Слабый набор реализованных алгоритмов для обучения с учителем, см. например функцию Classify. Плохой контроль над параметрами обучаемых моделей и процессом обучения.
Низкая производительность алгоритмов, как в режиме обучения, так и при «прямом проходе». Одноядерная реализация и отсутствие возможности распараллеливания в режиме обучения.
Закрытость предобученных моделей. Невозможность штатными средствами извлечь их параметры. Отсутствие средств экспорта предобученных моделей.
Комплексный анализ сложившейся ситуации показал, что существует в общем-то восемь основных причин делающих Wolfram Mathematica весьма неэффективным инструментом решения задач Machine Learning и анализа данных большого объёма (не путать с Big Data). Причём эти причины справедливы и для версии 11.0.0, вышедшей в августе 2016 года (последний релиз на момент написания данной статьи). Далее, мы эти причины приводим в порядке критичности для наших проектов:
Первое. Неэффективное управление памятью. Все массивы либо int 64, либо double. Функция ByteArray не спасает ситуацию по двум причинам. Во-первых, она поддерживает только unsigned int 8. Во-вторых, создание массива и доступ к данным идёт всё равно через его распаковку в int 64.
В свою очередь Python, при использовании массивов numpy или структур pandas, позволяет весьма гибко подстраиваться под пользовательские типы данных и тем самым эффективно управлять памятью, банально её экономить.
Второе. Проблемы с экспортом/импортом данных. Так многочисленные баги при работе с форматом hdf5 сводят на нет использование Mathematica для подготовки обучающих/тестовых наборов данных для Сaffe. Неэффективная реализация операции чтение/запись для csv файлов больших размеров делает невозможной работу с ними.
Оба языка, и Python и R, от данного недостатка свободны.
Третье. Неэффективная организация Shared Array при параллельных вычислениях на компьютерах с многоядерными процессами. Высокие временные накладные расходы на синхронизацию и значительный оверхед по памяти, зачастую сводят на нет положительный эффект от распараллеливания.
В свою очередь, например, в R под Linux, при использовании пакета doMC получается конструировать весьма эффективные приложения для мультиядерных параллельных вычислений, без оверхеда по памяти и с низкими временными накладными расходами на синхронизацию.
Четвёртое. Слабость функционала. Идёт экстенсивное расширение функционала вширь (увеличение количества покрываемых предметных областей), но не вглубь (детальная проработка направлений). Это приводит к невозможности решения специфических задач стандартными средствами системы.
В свою очередь набор возможностей Python по машинному обучению и Deep Learning – просто «зашкаливает». Широкий набор специализированных пакетов для R, позволяет решать весьма специфические вопросы на достаточно глубоком уровне.
Пятое. Излишняя интеграция с серверным функционалом. Ряд функций, которые активно применяются в анализе данных, работают исключительно при наличии подключения к серверам Wolfram. Яркий пример – это семейство функций Geographic Data. Таким образом становится невозможен анализ приватных данных без их раскрытия третьей стороне.
Функционал обоих языков, и Python и R, от данного недостатка свободен. Всю обработку возможно вести на машинах (кластерах) изолированных от сети Интернет.
Шестое. Неэффективные GUI приложения. Сколь-нибудь сложные приложения на основе Dynamic Interactivity Language сопровождаются, как правило, двумя основными недостатками: слабая отзывчивость интерфейса и повышенная нагрузка на центральный процессор.
Здесь имеет смысл упомянуть про библиотеку pyQT для Python. Она позволяет достаточно оперативно конструировать приложения (есть визуальный редактор) со сложным и при этом отзывчивым интерфейсом пользователя. Нагрузка на центральный процессор при соизмеримой сложности приложений существенно ниже, нежели у Mathematica.
Седьмое. Общесистемные проблемы. Похоже, что погоня за двумя «идеями фикс»: язык общего пользования и облачные технологии (специализированные платформы), нарушили баланс «технического долга» и новые фичи в Mathematica вводятся за счёт отказа от исправления большого количества старых багов, путём переноса их в новые релизы. При этом отсутствует публичный баг-трекер и план исправления ошибок. Сюда же можно отнести проблематику устаревших сред разработки, не отвечающих современным требованиям на IDE, поддерживающих REPL режим разработки программного обеспечения.
Вопрос конечно весьма сложный и объёмный для того, чтобы написать по нему короткий комментарий, но в любом случае открытость языков Python и R существенно снижает остроту обозначенной проблемы. Что касается IDE, то ситуация здесь также весьма благоприятная. С другой стороны, понятно, что мы сравниваем платные и бесплатные решения, но обычно если платишь, то предполагаешь, что твои проблемы будут решаться на должном уровне.
Восьмое. Высокая стоимость и закрытость решений. Построение системы для параллельной обработки данных, способной задействовать свыше 8-ми ядер и/или несколько хостов, резко (кратно) увеличивает стоимость лицензий на Mathematica. Отчуждаемые standalone-приложения, на основе технологии Wolfram CDF Player Pro, излишне тяжелы (отсутствует возможность выбора необходимого функционала) и требуют платной лицензии. При этом явно читается курс на построение компанией SaaS песочницы: Mathematica Online, Wolfram Cloud, и т.п.
Вопрос этот также весьма сложный и объёмный для короткого комментария, но тем не менее: системы анализа данных на основе Python и R – бесплатны; standalone-приложения, вместе со средой исполнения, существенно более компактны, нежели Wolfram CDF Player Pro; экосистема этих языков также существенно более открыта и динамична. В качестве примера рекомендуем ознакомиться с технологией Jupyter Notebook. Что же касается закрытия экосистемы со стороны компании Wolfram, то понятно, что SaaS слишком соблазнителен для его закрытия со стороны вендора. Уникальная фича – и клиенты от тебя уже никуда не уйдут, потому что у тебя не только необходимые алгоритмы, но и данные (секреты) клиентов. А любой сценарий обработки данных, выходящий за типичные заложенные возможности – дополнительный источник дохода для компании и дополнительные расходы, наряду с «головной болью», для клиентов.
А какие же основные минусы данного решения (в контексте перевода задач анализа данных на языки Python и R)? На самом деле для нас их два. Во-первых, банально нужно учить дополнительные языки и отслеживать ситуацию с новыми фичами и багами. Во-вторых, наблюдается некоторое усложнение процессов конфигурирования программной среды. Но плюсы настолько сильны, что минусы нивелируются (по крайней мере на момент написания данного поста).
В качестве Заключения. Как было уже отмечено в начале данной заметки, всё вышесказанное относится именно к вопросам так или иначе увязанным на комплексный анализ данных и машинное обучение. Что касается решения собственно математических задач: аналитических (символьных) вычислений и численных расчётов, то здесь Wolfram Mathematica – прекрасный инструмент (по крайней мере на настоящее время), конечно со своими огрехами, но куда уж без них.
23 августа 2016 года.
Андрей Макаренко,
группа «Конструктивная Кибернетика».
Обсуждение: contact@rdcn.ru
Ключевые слова: Комплексный анализ данных, машинное обучение, Deep Learning, Wolfram Mathematica, Python, R.
