Выбираем технологии
Это будет моим вторым шагом. Правильный технологический стек избавит вас от головной боли на несколько лет вперед. Детально технологии я буду обсуждать в следующих главах. Сейчас обрисую общую картину. Примерный список вопросов к технологиям звучит так:
• Собственное хранилище или облачное?
• Использовать ли open-source-технологии?
• Какой язык программирования использовать для артефактов инженерии?
• Можем ли отдать разработку аналитики стороннему подрядчику?
• Какую отчетную систему выбрать?
• Требуется ли где-нибудь скорость анализа, близкая к real-time?
Это самые базовые вопросы, но от них зависит многое. В том числе каких сотрудников нанимать, сколько придется инвестировать, как быстро запустится проект.
Насчет хранилища данных у меня обычно следующее правило: если компания собирается зарабатывать на данных существенную часть своей выручки, то лучше собственное хранилище. Если для компании аналитика – вспомогательный проект, то лучше использовать облачное хранилище.
Цель работы коммерческой компании – прибыль. Прибыль является разностью выручки и затрат, куда входит и себестоимость хранилища. И может быть довольно большой, если данные хранятся в облаке. Ее можно оптимизировать, создав собственное хранилище. Да, тут будут затраты на администрирование. Внимания такая система будет требовать больше. Но и способов снизить затраты у вас будет явно больше, система будет намного гибче. Если же аналитическая система не имеет такого прямого влияния на P&L (прибыли и убытки), то гораздо проще будет работать с облачным хранилищем. Тогда вам не придется думать об отказавших серверах – «облака» сделают за вас свою работу сами.
Технологии open-source (свободно распространяемое ПО с открытым исходным кодом) имеют очень большой вес в аналитике. Впервые я столкнулся с ними, когда учился на Физтехе. На втором курсе у меня появился компьютер, он имел очень слабую производительность даже по тем временам, поэтому я установил туда Linux. Часами компилировал ядро под свои нужды, учился работать в консоли. И это пригодилось мне ровно через десять лет. Именно тогда я посетил офис компании Netflix в Лос-Гатосе (Калифорния) и познакомился с директором по аналитике Эриком Колсоном. Он рассказал тогда об инструментах, которые используют его сотрудники в работе, и даже нарисовал маркерами на доске их названия. И как раз он много говорил об открытом ПО для анализа данных, таком как Python, Hadoop и R. До этого я пользовался только коммерческим софтом, но несколько месяцев спустя по следам этой встречи, летом, в пустом офисе, когда все сотрудники офиса Wikimart.ru отправились на корпоратив, я написал первые 9 строчек кода на языке Pig для платформы Hadoop (тут мне пригодилось знание Linux). На это ушло 4 часа. Тогда я еще не знал, что через несколько лет именно на этом языке и на этой платформе будет написан «мозг» рекомендательной системы Retail Rocket. К слову сказать, вся аналитическая система RR, как внутренняя для принятия решений, так и вычислительная для расчета рекомендаций, написана с использованием только open-source-технологий.
Сейчас, оборачиваясь в прошлое, я могу сказать, что Retail Rocket – это самое крутое, что я сделал в своей карьере: компания быстро вышла в прибыльность, успешно конкурирует с западными аналогами, и сейчас там работает больше сотни сотрудников по всему миру с основными офисами в Москве, Тольятти, Гааге, Сантьяго, Мадриде и Барселоне. Российская компания развивается и создает рабочие места за рубежом! Сейчас вектор развития изменился: RR продает не только рекомендательную систему, но и много сопутствующих услуг для интернет-магазинов. Технологии анализа больших данных и машинного обучения, которые мы создали в далеком 2013 году, актуальны до сих пор, и я очень горд, что мы были на голову выше наших конкурентов в технологическом плане.
Когда стоит связываться с коммерческим ПО? Ответ: когда на это есть деньги. Практически у любого коммерческого ПО есть 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], когда новичок в течение полугода обучается программировать на нем.
Поговорим об аутсорсе
Обсудим возможность привлечения внешнего подрядчика для создания аналитической системы. Ему на откуп можно отдать разные аспекты:
• создание и поддержка технической части системы;
• аналитическая часть;
• выделенные задачи.
