Привет!
В последнее время все чаще слышу от своих коллег, которые работают в подразделениях Big Data в разных компаниях утверждения о том, что процесс разработки построен не очень эффективно, что зачастую делается большое количество лишних итераций, а также что есть некоторое непонимание со стороны руководителей всех тонкостей получаемых на выходе продуктов. Поэтому в этой и следующей статьях я постараюсь рассказать о своем опыте построения команды, в которой мы работали достаточно эффективно. Сразу отмечу, что это лишь наш опыт, который не претендует на правильность и полноту. Статья направлена в первую очередь на руководителей разработки и представителей бизнеса.
Итак, в этой статье начнем в первую очередь с ролей в команде, а также затронем сам процесс разработки. В любом деле, особенно в творческом, главную роль играют люди. Стоит отметить, что в Big Data это особенно важно – команда зачастую маленькая, но очень сильная и слаженная. Трудностью является еще и то, что не так много мест пока в России, где можно получить соответствующее образование, да и образование не успевает за потребностями бизнеса — очень часто, как бы об этом не спорили, требуется понимание предметной области. И, наконец, еще большую сложность представляет сам портрет людей, которые способны создавать по-настоящему качественные Big Data продукты – они должны сочетать в себе ряд очень редких качеств.
Сразу отметим, что мы акцентируем внимание именно на разработке продуктов. Тем не менее, очень важно строить правильную архитектуру кластера, подключать источники данных, администрировать и настраивать хранилище данных. Это достаточно сложный и непростой процесс, в особенности связанный с тем, что технологии хранения и обработки данных в настоящее время являются достаточно сырыми и только появляются поставщики, которые гарантируют поддержку, зачастую недостаточную. Об этом в последствии будет отдельный пост, здесь же сосредоточимся именно на команде разработки.
Lead Data Scientist
Понятно, что ни одна команда не может без лидера. Это должен быть в первую очередь человек, который одновременно разбирается в технологиях для обработки и храния данных, а также их анализа. Это человек, который имеет достаточный опыт разработки продуктов с нуля. Чаще, это выходцы из академический среды. И одновременно, этот же человек должен хорошо понимать бизнес, чтобы иметь возможность разговаривать с заказчивами на одном языке. По моему опыту, в России последнее является одним из самых сложных – мало сделать хороший продукт – о нем нем надо рассказать так, чтобы все поняли, в особенности люди, которые не знакомы со всеми тонкостями Predictive Analytics. Все знают историю про магазин Target в 2012 году, но мало кто из руководителей знает, какие алгоритмы используются для построения рекомендательных систем, какие оценки качества применяются в таких задачах. Руководитель такой команды в западных странах называется обычно Lead Data Scientist (намеренно не будем переводить все названия на русский, чтобы не искажать смысла).
Small-Data Scientist
Далее, конечно же аналитики, которые работают в плотной связке с руководителем. Это люди, которых называют Data Scientists. В нашей команде существовало также неформальное разделение на Small-Data Scientist и Big-Data Scientist. Первые работают чаще с небольшими данными, которые помещаются в оперативной памяти на одной машине. Отсюда и название – Small-Data. Именно они занимаются всей творческой работой в проекте. Это люди, хорошо разбирающиеся в математике, но использующие при этом довольно простые инструменты для реализации своих идей – Python, R или подобные скриптовые языки с большим количеством библиотек, а также различные средства визуализации данных. Иногда даже применяются инструменты, вроде Weka, RapidMiner, SPSS Modeler (данные инструменты рекомендуется использовать для тестирования простых алгоритмов) которые практически избавляют от программирования. На момент написания статьи, таких людей проще готовить, нежели искать на рынке. Обычно, в команде может быть от 3 до 20 таких специалистов.
В данном же месте отметим, что под «Большими Данными» будем понимать те, которые не умещаются на одной машине и поэтому хранятся, как правило, распределенно.
ETL-Specialist
Далее, не менее важную роль играют люди, умеющие работать с источниками данных. Они работают с огромными массивами информации, однако занимаются больше вопросами выгрузки/загрузки данных, нежели разработкой алгоритмов. Именуют обычно этих специалистов ETL Specialist (Extract, Transform и Load). Их работа подразумевает собой работу с выгрузками данных, несложными манипуляциями с ними и загрузкой данных обратно в хранилище. Стоит отметить, что лучше всего на эту роль в больших компаниях подходят сотрудники, которые работали с данными и знают их внутреннее устройство. Это своего рода библиотекари, которые знают, “где на какой полке что лежит”. В этом плане нам повезло — мы работали с открытыми данными, для которых есть хорошее API. По опыту можно сказать, что в больших компаниях, данные специалисты используют как правило другие инструменты для работы с данными, нежели те, что необходимы для работы с Big Data. Обычно это аналитики, которые используют SQL-похожие инструменты, в то время как для работы с большими данными надо понимать парадигму Map-Reduce, несмотря на то, что инструменты вроде Hive или Pig имеют SQL-похожий синтаксис.
Big-Data Scientist
И наконец, когда дело доходит до действительно больших данных, когда необходимо “обучать” алгоритмы на огромных выборках, когда играет вопрос производительности алгоритмов машинного обучения и правильной их реализации в парадигме Map-Reduce за дело берется Big-Data Scientist (опять же, в нашей терминологии). По сравнению с Small-Data Scientists, это люди, которые чуть менее разбираются в математике и алгоритмах машинного обучения, но имеют значительный опыт в программировании. Сложно ответить на вопрос, кому проще стать таким человеком – тому, кто уже является Small-Data Scientist или человеку, имеющему большой опыт программирования. Таких людей в команде у нас было немного.
Итак, мы рассмотрели пример небольшой команды Big Data. Хотелось бы услышать мнения руководителей разработки, читающих хабр, об их опыте. Надеюсь также, что людям, заинтересованным в работе в Big Data подразделении примерно стало понятно, чем им придется заниматься и какие задачи стоят перед разработчиками!
Автор: akrot
