Начал выкладывать слайды своего курса ПЗАД. В его рамках я рассказываю также и про связку Matlab, R, Python (последнее время без R — в зависимости от настроения). Так получилось, что работать в Матлабе мне всегда нравилось: в своё время быстро перешёл на него с С, великолепная графика и помощь. Из минусов только отсутствие хороших библиотек для машинного обучения и платность.
Слайды: Matrix Laboratory (эффективное программирование) (pdf) сделаны по моей старой книжке (см. последнюю главу). В книжке ещё есть хорошая подборка задач — можно проверить свои знания.
Анализ малых данных 
Спасибо большое, что делитесь такой полезной информацией!
Читая Ваш блог, меня все больше мучает вопрос: что не так с R? Вот в опросе, который Вы устраивали относительно недавно, тоже почти никто его не упоминал. Это так традиционно сложилось или у него есть какие-то серьёзные недостатки?
R — хороший язык, созданный специально для статистического анализа данных. Лет 5 назад только в нём можно было найти волшебные библиотеки randomForest, gbm и т.п. Большинство современных алгоритмов (xgboost, глубокие НС и т.д.) тут же портируются на R (ну или имеют подходящие обёртки). Сейчас его полностью адаптируют для работы с Big Data. Скоринговые системы многих российских банков написаны на R.
В чём подвох…
1) Синтаксис R раздражает профессиональных программистов.
2) На нём сложно вести профессиональную разработку (всё, что написано на R остаётся кодом на R).
3) Python традиционно используют для многих задач: парсинг логов, web-разработка и т.п. Если возникла потребность в машинном обучении, то ни у кого не вызовет вопросов, если опять будут использовать Python. А вот если речь зайдёт об R… позвольте, а зачем использовать какой-т там R?!
Спасибо за ответ.
Особенно понравился первый пункт:) Синтаксис у R действительно очень «своеобразный».
Кстати, на эту же тему: http://www.kdnuggets.com/2015/05/r-vs-python-data-science.html
Александр, пара небольших замечаний по R в скоринге.
Большая часть крупных российских банков использует для скоринга (в проме) BRMS- платформу SM европейской компании Experian (которая стоит как чугунный мост) или (намного реже) решение американской компании FICO (которая еще дороже). Плюс некоторое количество внедрений еще одного европейского решения.
Крупнейший банки пользуют американский софт SAS RTDM (та же BRMS, только способная считать еще больше и быстрее, и еще более сложные вещи) и есть, если не ошибаюсь, единичные внедрения продукта аналогичного класса от Oracle (тоже США), хотя я лично знаю только о внедрения последнего у коллекторов и о пилоте в одном банке (но я этой темой с Oracle плотно не интересовался). Банки, у которых нет денег на вышеперечисленное, и которым не надо скорить десятки или сотни тысяч заявок в день по десяткам или сотням моделей и сотням или тысячам маршрутов со скоростью порядка секунд, пользуют чаще всего решения типа Deductor российской компании BaseGroup.
Вместе с BRMS-машинами Deductor, FICO и SAS RTDM почти всегда используют «родные» решения для разработки моделей и аналитики соответствующего производителя, что позволяет бесшовно внедрять модели в пром (у SAS так вообще целая линейка аналитических продуктов — от статпакета до датамайнингового решения с рядом отраслевых расширений, которые отдельно лицензируются). У Experian такого решения нет, так что SM пользуют обычно либо вместе с аналитическими продуктами SAS (в России самый частый вариант), либо вместе с SPSS (один случай в России мне известен), либо с Matlab (на Западе вроде бы такое бывает, про РФ не слышал), либо плагин ScorTo для Excel. Ну или вообще «голый» Excel — и так бывает, особенно в ближнем Зарубежье, пока банк что-то не купит (строго говоря, не совсем Excel — на VBA пишут скрипты, точнее пользуют готовые из популярной западной книги, где показано, как в Excel скормодели делать). В Лондоне в банках для аналитики Matlab вроде как активно пользуют, но я никогда не интересовался, куда эти модели потом внедряют. Подозреваю, что собеседник не вполне понял мой вопрос (или я его ответ) и он говорил об инвестиционных банках, а не о кредитном скоринге. Впрочем, там пользуют скорее всего решения Experian в проме, так что один фиг ручками надо вносить модели, какой бы ты статпакет или матпакет не пользовал. А в рыночных рисках Matlab реально рулит, так что вполне допускаю, что там Matlab пользуют активно в рыночных рисках для аналитики, и, чтобы зоопарк не плодить, и для задач кредитного скоринга.
В Штатах, где конкуренция дикая, для аналитики вообще что только не используют от узкоспециализированных решений типа Arrow Modeler (для скоринга) до S+ (проприетарный отец R) или KNIME, но в банках там везде FICO окопался, причем его из банков, как SAS из медицины, фармы, атомной энергетики и транспортных компаний фиг сковырнешь
Я это к чему — R ни российский Deductor, ни европейские решения типа SM, ни американский SAS RTDM не поддерживают.
Примеры использования R в России есть, но я знаю только о четырех — в одном госбанке для валидации моделей Базель 2, в другом — для разработки некоторых моделей корпоративного кредитования, да и то там R запускают на АНАЛИТИЧЕСКОМ сервере SAS c помощью SAS IML (модуль SAS для матричных вычислений, аналог Matlab в некотором смысле) буквально ради пары алгоритмов, которые на SAS толком не реализованы, еще в одном небольшом банке (который то в конце 2, то ли в начале 3 сотни по активам) для разработки моделей (там 2 или 3 модели в год делают и их вполне все устраивает), и в одной финансовой компании, которая пользует ETL-машину от Oracle, модели на R запускают в проме для обсчета (в пакетном режиме), но соответствующее решение, позволяющее гонять модели на R в проме (в режиме пакетного обсчета) стоит как чугунный мост.
Решение, позволяющее применять модели R в проме в потоковом режиме в решении класса BRMS, по-моему, было только у компании RA,(и то я не уверен на 100%), которую Microsoft купил. Oracle, возможно, уже «вкрутил» такую возможность в свое BRMS решение RTD класса (в ETL-машине уже точно поддерживается), и SAS вроде как грозится это тоже сделать. Последние собираются еще и поддержку Python в свои продукты добавить — строго говоря, основные деньги мегавендоры зарабатывают на платформых для прома (для очень продвинутых клиентов) и на отраслевых solution (для всех остальных), а не на датамайнинговых инструментах и статпакетах, даже в серверном исполнении. Так что SAS, который всегда считался одним из самых дорогих статпакетов, сейчас базовую версию своего статпакета (без графической оболочки) вообще бесплатно дает. Если тенденция сохранится, лет через 5-7 они ИМХО и продукты типа Guide и Miner будут бесплатно давать, а бабки будут брать за допноды для разработки специализированных актуарных и скоринговых моделей, за серверные версии с поддержкой репозитария моделей, да за коробки для прома, где все эти модели должны жить и приносить деньги.
От себя я замечу, что это не есть что-то совсем новое для мегавендоров, например, когда они на заре становления с самописок перетаскивали клиентов, были добавлены поддержка С, Fortran и Cobol
Более того, американская корпорация может дать грант университету, те сваяют какой-то супералгоритм на C или Fortran, и это можно спокойно пользовать в среде, например, SAS (или любого другого крупного вендора научного, инженерного или аналитического ПО) для каких-то изощренных вещей. Так что для SAS и Oracle такие финты привычны.
Цель расширения поддержки R и Python, насколько я понял, в том, чтобы сбить цену на аналитиков в Штатах (в университетах в США много спецов, умеющих работать с R и Python), и сделать внедрение продвинутой аналитики в пром более доступным для среднего и малого бизнеса. А крупному бизнесу дать возможность использовать наиболее передовые алгоритмы, которые мегавендор еще сам не успел реализовать на своей платформе (и вообще сэкономить на таких вещах)
P.S. Спасибо огромное за материалы.
Спасибо за развёрнутый комментарий. Очень полезный!
Поясню, почему я написал «Скоринговые системы многих российских банков написаны на R».
2-3 года назад я общался с выпускницей нашей кафедры, которая успела поработать во многих банках. Она как раз писала скоринговые системы и сказала, что в «богатых банках» используют SAS, а в «бедных» — R.
Позже её высказывание часто подтверждалось. Например, в прошлом году я собеседовал парня из Хоум Кредит, он сказал, что пишет на R (что меня, впрочем, очень удивило).
На самом деле, Вы меня даже ещё больше удивили. Я впервые слышу про использование Deductor для этих целей. Ясно, что у BaseGroup есть куча банков в клиентах, но я не думал, что они достаточно крупный игрок на этом рынке.
1. R часто используют как вспомогательный инструмент для каких-то отдельных задач. В этом смысле мы тоже его используем, т.к. там есть пара статистик, которые не реализованы в SAS, плюс библиотеки для работы с временными рядами богаче, чем в SAS ETS, а покупать SAS Forecasting Studio для решения задач, которые раз-два в год возникают — глупость полнейшая
2. Сейчас в Россию достаточно агрессивно Microsoft решил зайти. Причем, насколько я вижу, они продвигают не только облачный Azure (который скорее малым компаниям будет интересен и тем, кто не готов серьезно вкладываться в экспертизу и инфраструктуру), но и свой продукт Microsoft R Server (на базе решения компании Revolution Analytics, которую MS приобрел годом ранее).
Учитывая, что средний бизнес в России на MS SQL Server весьма плотно сидит (на Oracle крупняк преимущественно), что оный R Server плотно интегрировали в SQL Server 2016, и есть опенсорсная реализация, шансы у MS неплохие. Тем более, что сообщество R в России сейчас уже довольно многочисленное. Задумка, насколько понимаю, та же — снизить порог вхождения для бизнеса (среднего, который сейчас в это мало вовлечен), в т.ч. за счет использования недорогих аналитиков и лицензий. Так что в ближайшие года 3 рынок труда для людей со знанием R может сильно увеличиться.
[…] Другие заметки в блоге из этой же серии:Питон (Python), Python: категориальные признаки, Знакомство с Pandas, Знакомство с scikit-learn (слайды), Считаем категории, NumPy — делаем быстрее, Matlab. […]