Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

Когда стоит связываться с коммерческим ПО? Ответ: когда на это есть деньги. Практически у любого коммерческого ПО есть open-source-аналог. Да, как правило, они хуже, особенно в каких-то деталях. Например, я так и не нашел достойный open-source-аналог для OLAP-кубов. Отчетные системы тоже выглядят недоделанными. Но что касается инженерных технологий, таких как Hadoop, Spark, Kafka, – то это очень надежные и мощные инструменты разработчиков. Они очень хорошо зарекомендовали себя в коммерческом применении.

Обсудим языки программирования, которые будут использоваться при разработке системы. Мой принцип – чем их меньше, тем лучше. До Retail Rocket мне удавалось обходиться одним SQL. Правда, для перекачивания данных (ETL) из источника в хранилище приходилось использовать специальные коммерческие инструменты от Microsoft. В Retail Rocket в свое время использовалось аж четыре языка программирования для создания рекомендаций: Pig, Hive, Java, Python. Потом мы заменили их все на Scala, так как он относится к семейству JVM, на котором написана Hadoop. Поэтому на нем очень легко программировать на платформе Hadoop/Spark, для последней он еще является родным. Но пару лет назад мы стали использовать Python и SQL. Здесь пришлось отойти от Scala – некоторые вещи на нем делать было неудобно.

Scala – прекрасный и изящный язык программирования, но мы уперлись в две проблемы. Во-первых, пользователям очень сложно было бы работать с ним в качестве интерфейса к данным, для этого намного лучше подходит SQL. Во-вторых, все современные библиотеки машинного обучения сейчас пишутся на Python. Сейчас Scala используется для разработки центрального ядра системы, агрегации и доставки данных, SQL для отчетов, Python для разработки моделей машинного обучения и несложных прототипов. Обычно выбор языка программирования зависит от нескольких вещей:

• для какой системы он будет использоваться (например, SQL идеально подходит для баз данных);

• есть ли специалисты по этому языку в вашей компании и на рынке.

Например, заставлять пользователей вашей системы учить сложные в освоении языки программирования для доступа к данным – плохая идея. Для пользователей это вспомогательный инструмент, и много времени на его изучение они тратить не захотят.

Специалисты на рынке – моя головная боль. Scala – очень редкий язык, довольно непростой в изучении. Специалистов на рынке очень мало, а имеющиеся стоят дорого. Вот на Python работают очень многие. Хотя за одного Scala-разработчика я бы дал трех на Python. Здесь мы приняли сознательное решение: качество нашей работы для нас важнее, поэтому выбрали Scala. Нанимать готовых Scala-людей почти не получалось, поэтому мы сделали свой курс молодого бойца [19], когда новичок в течение полугода обучается программировать на нем.

Обсудим возможность привлечения внешнего подрядчика для создания аналитической системы. Ему на откуп можно отдать разные аспекты:

• создание и поддержка технической части системы;

• аналитическая часть;

• выделенные задачи.

Когда требуется сократить время развертывания технической части проекта и получить качественный результат – нужен хороший подрядчик. Но попробуй его еще найди! Мало того что редкий подрядчик достаточно глубоко знает предмет – ситуация часто усугубляется тем, что заказчик не знает, чего хочет.

В одной из компаний, где я работал, была собрана команда для реализации проекта. Проект не аналитический, в теории он выглядел замечательно. К тому же командой руководил человек, который преподавал проектирование таких систем чуть ли не в топовом университете. Для технической реализации были выбраны самые «современные» технологии. В итоге три или четыре разработчика писали эту систему целый год. В попытке запустить ее потратили целые сутки… Не завелось, и всю систему выбросили на свалку. То же самое может случиться и с аналитикой. Теория очень сильно отличается от практики, тем более в нашем быстро меняющемся мире.

Риск уменьшится, если привлечь очень опытного аналитика, который не раз лично реализовывал подобные проекты. На вашем проекте он будет выступать в качестве независимого советника или даже арбитра. Это нужно, чтобы, с одной стороны, «приземлить» заказчика, с другой – ограничить подрядчика. Я считаю, что проект на старте лучше сильно урезать по «хотелкам», чтобы получить на выходе работающую версию как можно быстрее. На то есть несколько причин. Во-первых, после того как вы, заказчик, вживую поработаете с ней, вам гораздо легче будет сформулировать, что вы действительно хотите. Это тяжело делать абстрактно на бумаге, конструируя сферического коня в вакууме. Вторая причина – драйв, лично для меня это очень важно. Когда время течет медленно, у команды, да и у заказчиков, постепенно угасает интерес. И на выходе мы уже получаем вымученный проект, которым уже не так сильно хочется заниматься.

Если нет возможности найти советника – попытайтесь хоть немного разобраться в вопросе самостоятельно, почитайте книгу, посмотрите видеозаписи конференций. Иначе велика вероятность, что проект просто не взлетит. А если и взлетит, то будет потрачено много времени и денег.

Хорошо, если можно отдать на аутсорс технологическую часть, но можно ли это сделать с аналитикой? Общий ответ – нет. Сторонние аналитики никогда не будут обладать всей полнотой бизнес-контекста. С другой стороны, аутсорс аналитики какого-то направления вполне возможен. Например, рекламного.

Еще один вариант аутсорса – отдать какую-то часть проекта целиком: вы отдаете данные, а на выходе получаете готовый продукт. Пример такого сотрудничества – компания Retail Rocket. Начали мы бизнес с товарных рекомендаций. Интернет-магазины отдавали нам данные и товарную базу, на выходе они получали готовые рекомендации. Лично у меня идея такого бизнеса зародилась во время работы в компании Wikimart.ru. Я сделал рекомендации для сайта компании и подумал: почему бы не запустить тиражируемое решение. Это бы сняло необходимость интернет-магазину нанимать инженеров машинного обучения и изобретать велосипед. Результат получался гораздо быстрее, буквально за неделю. Среднее качество рекомендаций нашего сервиса гораздо лучше внутренней разработки. Если бы меня наняли сейчас в интернет-магазин, то, скорее всего, я бы привлек внешний сервис рекомендаций вместо того, чтобы делать собственную разработку.

Немного расскажу о своем личном опыте работы на аутсорсе. В 2009 году я ушел из Ozon.ru. В то время у меня был достаточно популярный блог по аналитике KPIs.ru, созданный за пару лет до этого. И оттуда ко мне стали приходить запросы на консалтинг по аналитике из самых разных сфер: разработчики игр, e-commerce, венчурный фонд и т. д. Потихоньку я стал наращивать темп консультаций, одновременно работая на три компании. Первой я помог выбрать нужную технологию и нанять людей в команду, проводил собеседования. Второй – помогал растить стартапы. В третьей компании я поработал руками, подняв аналитическую систему. Мне этот опыт много дал – прежде всего я помогал компаниям, не отвлекаясь на корпоративные детали и бюрократию, как было бы, работай я в штате. Ну а компаниям моя работа позволила осуществлять быстрый старт проектов. Кстати, в третьей компании я в результате остался работать (это был Wikimart.ru): ее основатель предложил мне возглавить отдел аналитики – и я согласился, потому что в тот момент хотел быть ближе к данным и работать руками. На этом тогда закончился мой аутсорс.