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

• Когда нужно передать знания одного проекта от одного сотрудника другому, например, был нанят новичок. «Головой» будет сотрудник, который передает знания, «руками» за клавиатурой – кому передают.

• Когда проблема сложная и непонятная. Тогда два опытных сотрудника в паре решат ее намного эффективней одного. Будет сложнее сделать задачу анализа однобоко.

Обычно на планировании мы переносим задачу в категорию парных, если понятно, что она подходит под критерии таковой.

Плюсы парного подхода – время используется намного эффективней, оба человека очень сфокусированы, они друг друга дисциплинируют. Сложные задачи решаются более творчески и на порядок быстрей. Минус – в таком режиме невозможно работать больше нескольких часов, очень сильно устаешь.

Еще одна важная вещь, которой я научился у инженеров Retail Rocket [31], – работа с техническим долгом (technical debt). Технический долг – это работа со старыми проектами, оптимизация скорости работы, переход на новые версии библиотек, удаление старого программного кода от тестирования гипотез, инженерное упрощение проектов. Все эти задачи занимают добрую треть времени разработки аналитики. Приведу цитату технического директора Retail Rocket Андрея Чижа [31]:

«Я еще не встречал компаний за свою практику (а это более 10 компаний, в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют».

Я тоже не встречал. Видел «болота» программных проектов, где старье мешает создавать новое. Суть технического долга – все, что вы сделали ранее, нужно обслуживать. Это как с ТО автомобиля – его нужно делать регулярно, иначе машина сломается в самый неожиданный момент. Программный код, в который давно не вносились изменения или обновления, – плохой код. Обычно он уже работает по принципу «работает – не трогай». Четыре года назад я общался с разработчиком Bing. Он рассказал, что в архитектуре этого поискового движка есть скомпилированная библиотека, код которой потерян. И никто не знает, как это восстановить. Чем дольше это тянется, тем хуже будут последствия.

Как аналитики Retail Rocket обслуживают технический долг:

• После каждого проекта тестирования гипотез мы удаляем программный код этой гипотезы везде, где только можно. Это избавляет нас от ненужного и неработающего хлама.

• Если происходит обновление каких-либо версий библиотек – мы делаем это с некоторым запозданием, но делаем регулярно. Например, платформу Spark мы апгрейдим регулярно, начиная с версии 1.0.0.

• Если какие-либо компоненты обработки данных работают медленно – ставим задачу и занимаемся ею.

• Если есть какие-то потенциально опасные риски – например, переполнение дисков кластера, тоже ставится соответствующая задача.

Работа с техническим долгом – это путь к качеству. Меня убедила в этом работа в проекте Retail Rocket. С инженерной точки зрения проект сделан как в «лучших домах Калифорнии».

Прежде чем мы перейдем к собственно анализу данных, считаю необходимым рассмотреть предмет изучения. Цитата выше – это определение данных, которое дает Википедия. Оно очень сухое, но емкое. В моей книге я намеренно сузил это определение: под данными будут пониматься цифровые данные, которые могут быть прочитаны и обработаны ПО.

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

• Медицинские анализы – помощь в постановке диагноза, принятие решений о выводе лекарства на рынок.

• Фотографии – поиск предметов, распознавание лиц.

• Товары – закупки нужных товаров на склад.

• История посещений сайта – рекомендательная система интересных страниц.

• Список клиентов – разбить их на группы, чтобы предложить разные скидки.

• Географические карты – навигация с учетом автомобильных пробок.

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

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

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

Очень хайповый термин, который сейчас звучит из каждого утюга. Мне посчастливилось поработать в этой теме последние 8 лет и накопить достаточно большую экспертизу. Попробую дать собственное определение: большие данные (Big Data) – это такой объем данных, который невозможно обработать в требуемое время на одной машине (сервере).

Обычно когда говорят про большие данные, имеют в виду только их объем. Но на самом деле в коммерческом или научном применении очень важно время. Исследователь не может бесконечно ждать. Чем быстрее можно получить результат, тем лучше. Особенно когда мы работаем в условиях неопределенности результата и запрос к данным нужно итеративно уточнять, как правило, начиная с самых простых шагов. Современная техника, особенно скорость реакции приложений мобильного телефона, приучила нас к очень быстрой реакции на наши действия, и подсознательно мы этого ожидаем и от систем обработки данных.