Привет, хабр!
После последней публикации «Ваш персональный курс по Big Data» мне пришло несколько сотен писем с вопросами, читая которые, я с удивлением обнаружил, что люди очень сильно погружаются в теорию, уделяя мало времени решению практических задач, в которых навыки необходимы совершенно другие. Cегодня я расскажу, какие сложности появляются на практике и с чем приходится работать при решении реальных задач.
Те, кто уже прошел большое число курсов по машинному обучению и начали решать задачи на Kaggle прекрасно знают, как выглядит типичная постановка задачи: "Дан набор обьектов обучающей выборки, для каждого из которых имеются признаки, а также даны значения целевой переменной. Также дана тестовая выборка, для каждого обьекта которой значение целевой переменной необходимо предсказать". Существуют и более сложные постановки, здесь я лишь привел самую типичную — для задач регрессии и классификации. С этого начинается решение задачи на kaggle.com — Вы благополучно читаете условие задачи, смотрите на метрику качества, скачиваете датасет, запускаете IPython Notebook, подключаете Ваши любимые библиотеки и начинаете долго и упорно работать с данными, подбирать гиперпараметры моделей, делать отбор признаков, обучать множество классификаторов и взвешивать их, находить сложные обьекты и смотреть на них более внимательно и т. д. Тем самым Вы боритесь за то, чтобы оптимизировать метрику качества и получить достойную позицию в Leader Board.
К сожалению, на практике все выглядит совсем по-другому. На самом деле, 90% работы уже сделана до Вас. Навыки построения качественных моделей конечно важны, но не первостепенны. Обратите внимание на выделенные выше в постановке задачи слова — они не случайны, т.к. в реальной жизни вам ничего «не дано», нет «метрики качества», нет «обучающей выборки», не говоря уже о том, что по-сути нет и задачи — есть только смутное описание того, какая цель преследуется при решении той или иной задачи. И тут начинается настоящая работа ученого по данным, в которой большую часть занимает рутина, а думать надо далеко наперед и задолго до того, как есть четкая постановка задачи и построена матрица «обьект-признак».
Если кратко, то самыми распространенными проблемами, с которыми приходится сталкиваться являются следующие:
- Размытая постановка задачи
- Большое количество степеней свободы
- Большое количество разных источников данных
- Качество данных и пропуски в них
- «Сырое» ПО для работы с данными
- Неудобство работы с большими данными
- Наличие обучающей выборки
Итак, разберем по-порядку каждую из проблем:
Размытая постановка задачи
Задача не возникает сама по себе — каждую вещь, которую мы делаем — делается для конкретной цели. А цели у бизнеса зачастую формулируются достаточно неформально: «уменьшить отток клиентов», «увеличить выручку от партнерских программ», «удержать пользователей», «снизить нагрузку на конкретный отдел бизнеса за счет оптимизации бизнес-процессов». Именно в такой формулировке (чаще — чуть точнее) задача попадает к Data Scientist'у. Вот именно поэтому данный человек и должен быть знаком с бизнесом, чтобы понимать то, что же на самом деле нужно. Если, например, решается задача продвижения услуг или разрабатывается таргетированное предложение — необходимо понимать, как в последствии будет устроен процесс взаимодействия с клиентом, как будет проводиться рекламная кампания, как будет определяться критерий ее успеха — и для чего тут в конце концов нужно машинное обучение — все это необходимо знать с точностью до деталей. Но как только Вы начинаете разбираться с деталями — у вас появляется следующая проблема.
Большое количество степеней свободы
Что такое — «клиент ушел в отток» — на языке бизнеса понятно — бизнес начинает терять деньги. Но хранилища, в которых содержится информация о клиенте этого не понимают — в них хранятся десятки статусов, в которых отток может означать блокировку, расторжение договора, неиспользование услуг в течении определенного промежутка времени, несвоевременную оплату счетов — все это можно назвать оттоком клиента в той или иной степени. А как Вы думаете — если формулировка целевого параметра и постановки задачи допускает столько степеней свободы — как легко при этом генерировать признаки для задачи? Верно! — это сделать еще сложнее. Теперь на минуту представьте, что мы определились с самой задачей и с признаками. А как будет производиться контакт с клиентом? — и тут оказывается, что процесс удержания клиента — это сложная процедура, которая занимает определенное время и у которой есть определенные особенности. Если скажем, Вы предсказываете, что клиент склонен уйти в отток с определенной вероятность на какую-либо дату, то есть также вероятность — что Вы просто не успеете с ним провзаимодействовать. И все это необходимо учесть задолго до разработки алгоритма. Именно поэтому необходимо научиться быстро погружаться в определенную предметную область, чтобы знать весь процесс и все детали. Предположим, что и с этим мы справились, определились также с тем, какие признаки нам понадобятся для решения задачи. Но тут возникает новая проблема.
Большое количество разных источников данных
Данные, особенно в большой компании, далеко не всегда хранятся в одном источнике. И далеко не всегда средства для работы с этими данным одинаковые, т.к это могут быть как sequence-файлы, лежащие в HDFS, noSQL базы данных, а также реляционные источники. Но ведь нам зачастую нужна матрица «обьект-признак» — а значит придется делать большое количество всем любимых join'ов — что в случае больших данных заставляет думать о том, как сделать запросы оптимально. Тут потребуются навыки работы с разными инструментами, начиная от SQL, Hive, Pig и заканчивая тем, что зачастую проще написать код на Java/Scala, чем использовать SQL-подобные языки. Однако, если вы и знакомы со всеми этими инструментами и представляете, как правильно писать сложные join'ы, возникают другие проблемы.
Качество данных и пропуски в них
Очень часто (чем больше компания — тем чаще) у Вас будет большое количество пропусков в данных — например, если задача требует для решения каких-то определенных признаков — может оказаться так, что большая часть этих признаков доступна лишь для небольшой группы клиентов. Далее, если даже данные по клиентам имеются в наличии, оказывается, что в части данных есть так называемые выбросы, не говоря уже о том, что т.к. и источники данных разные — то одни и те же данные могут храниться в разных форматах и приходится при том же join'е приводить все к одному виду. Но, предположим, что и с этим Вы справились. Написали хороший скрипт на Hive/Pig или на Spark и запустили. Думаете это все? Не совсем.
«Сырое» ПО для работы с данными
Основной причиной популярности Big Data в свое время являлась дешевизна. В частности — большинство популярных инструментов для работы с большими данными — являются open-source разработкой, будь то Hive, Pig или всеми любимый Apache Spark. Но те, кто хоть раз имел опыт работы с open-source инструментами, прекрасно знают — что на них рассчитывать вовсе не стоит и что с первого раза все запускается далеко не всегда. Например, если Вы написали простой скрипт, который последовательно читает файлы из HDFS и отошли на несколько часов. С приходом Вы можете запросто обнаружить, что скрипт «упал» просто потому, что среди папки с файлами, которую Вы читали случайно оказался какой-нибудь *.tmp файл, который Pig, например, не смог прочитать. Все, кто работал с Apache Spark — могут также рассказать Вам про проблемы чтения мелких файлов, про то, что часто тяжело на нем сохранить построенные модели — приходится писать собственные сериализаторы. Таких примеров можно привести очень много. Но, допустим, вы долго запускали и тестировали код и вот, вроде бы, есть у Вас долгожданная матрица «обьект-признак».
Неудобство работы с большими данными
И вот Вы, представьте, что у Вас есть большой обьем данных. Предположим даже, что у Вас небольшая обучающая выборка, которая помещается в оперативной памяти, и Вы уже построили хорошую модель. Как правило, при этом Вы нагенерили большое количество новых признаков (сделали Feature Engineering, с которым мы с Вами знакомились здесь и здесь). А что делать с той самой огромной выборкой обьектов, для которых нужно вызвать Вашу долгожданную функцию Predict? Ведь для нее тоже нужно сделать все те же преобразования, которые вы делали с обучающей выборкой — добавить новые столбцы, заполнить пропуски, нормировать данные. При построении модели Вы наверняка это делали с помощью замечательных пакетов вроде Pandas, в котором имели дело с DataFrame'ами. Все, теперь их больше нет — все придется делать своими руками. Единственное, чему тут остается порадоваться — в Apache Spark версии 1.3 есть поддержка DataFrame, которая позволит работать с большими данными также быстро, как это делается в R или Python. Наверное.
Наличие обучающей выборки
Это, наверное, не самая неприятная, но в то же время важная проблема, которая возникает на практике — где брать обучающую выборку? Тут уже приходится много думать, т.к. важно соблюсти баланс между размером обучающей выборки и ее качеством. Например, в некоторых задачах часто есть некоторый набор обучающих обьектов и можно путем кластеризации и наложении обучающих обьектов пытаться увеличить размер обучающей выборки. Можно также найти обучающую выборку путем решения множества вспомогательных задач — единых методов тут нет — приходится выкручиваться каждый раз под конкретную задачу.
Итого
Итак, я надеюсь, что после прочтения данного поста у Вам еще хочется активно заниматься анализом данных. Ведь все эти проблемы со временем так или иначе решаются (могу сказать это в моем случае, а также путем опроса своих коллег из других компаний). Так бывает всегда, когда появляются новые инструменты, как это происходит в случае с Apache Spark. Однако, важно про все эти особенности и трудности знать заранее.
Именно для этого (а также потому что, после последней публикации моя почта оказалась завалена письмами и я один не успеваю всем отвечать) был создан ресурс MLCLass.ru, на котором я собираю лучших практиков, которые готовы поделиться знаниями, а также помочь новичкам в решении задач! Присоединяйтесь и не стесняйтесь писать свои вопросы и звать друзей, а также активно писать в support! Я и мои коллеги заинтересованы в развитии Data Science и готовы отвечать на все Ваши вопросы!
Успехов всем и отличных начинаний! Встретимся на MLCLass.ru!
Автор: akrot
