Затем я иду к разработчикам и начинаю узнавать, а что же, собственно, у них есть какие данные они собирают и где эти данные находятся. Во-первых, меня интересуют данные, которые помогут решать задачи клиента (мне важно увидеть не только схемы, но и живые примеры таких данных строки таблиц и файлов). Во-вторых, для меня важны те данные, которые есть, а применения им пока нет какие задачи они могли бы решить? К финалу этого этапа у меня уже есть:
Список вопросов, которые покрываются текущими данными.
Список вопросов без данных и понимание того, сколько усилий потребуется, чтобы их получить.
Данные, которые пока не решают никаких актуальных задач.
Источники данных и их примерные объемы.
И это только первая итерация. С этим списком я иду к заказчикам, общаюсь с теми же людьми, объясняю им, можно ли ответить на их вопросы, нужны ли дополнительные данные а потом снова иду к разработчикам. Выглядит как челночная дипломатия, но именно так я и строю план проекта.
В итоге у меня есть: список требований к системе, список имеющихся данных и задач, которые нужно выполнить, чтобы получить недостающие цифры. Выглядит просто, но бывает, что на эти шаги уходят недели. Я не выгружаю бездумно все данные из хранилища, чтобы потом начать с ходу пытаться делать метрики и дашборды. Но пытаюсь решить эту задачу в уме. Это мне сэкономит силы, а заказчикам сбережет нервы. Они заранее будут знать, что получится сразу, а что нет.
Выбираем технологии
Это будет моим вторым шагом. Правильный технологический стек избавит вас от головной боли на несколько лет вперед. Детально технологии я буду обсуждать в следующих главах. Сейчас обрисую общую картину. Примерный список вопросов к технологиям звучит так:
Собственное хранилище или облачное?
Использовать ли 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], когда новичок в течение полугода обучается программировать на нем.
Поговорим об аутсорсе
Обсудим возможность привлечения внешнего подрядчика для создания аналитической системы. Ему на откуп можно отдать разные аспекты:
создание и поддержка технической части системы;
аналитическая часть;
выделенные задачи.
Когда требуется сократить время развертывания технической части проекта и получить качественный результат нужен хороший подрядчик. Но попробуй его еще найди! Мало того что редкий подрядчик достаточно глубоко знает предмет ситуация часто усугубляется тем, что заказчик не знает, чего хочет.
В одной из компаний, где я работал, была собрана команда для реализации проекта. Проект не аналитический, в теории он выглядел замечательно. К тому же командой руководил человек, который преподавал проектирование таких систем чуть ли не в топовом университете. Для технической реализации были выбраны самые «современные» технологии. В итоге три или четыре разработчика писали эту систему целый год. В попытке запустить ее потратили целые сутки Не завелось, и всю систему выбросили на свалку. То же самое может случиться и с аналитикой. Теория очень сильно отличается от практики, тем более в нашем быстро меняющемся мире.