Текст книги "Роман с Data Science. Как монетизировать большие данные"

Парный анализ данных

О парном программировании я узнал от разработчиков [30] Retail Rocket. Это техника программирования, при которой исходный код создается парами людей, программирующих одну задачу и сидящих за одним рабочим местом. Один программист сидит за клавиатурой, другой – работает головой, сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они могут меняться местами.

И нам удалось ее адаптировать для нужд аналитики! Аналитика, как и программирование, – творческий процесс. Представьте, что вам нужно построить стену. У вас есть один рабочий. Если вы добавите еще одного – скорость вырастет примерно в два раза. В творческом процессе так не получится. Скорость создания проекта не вырастет в два раза. Да, можно проект декомпозировать, но я сейчас обсуждаю задачу, которая не декомпозируется, и ее должен делать один человек. Парный же подход позволяет многократно ускорить этот процесс. Один человек за клавиатурой, второй сидит рядом. Две головы работают над одной проблемой. Когда я решаю сложные проблемы, я разговариваю сам с собой. Когда разговаривают две головы друг с другом – они ищут причину лучше. Мы используем схему парной работы для следующих задач.

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

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

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

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

Технический долг

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

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

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

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

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

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

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

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

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

Глава 5
Данные

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

Википедия

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

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

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

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

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

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

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

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

Как собираются данные

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

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

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

Big Data

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

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

Большой объем данных на самом деле получить очень несложно. Дам простой пример. Если каждую миллисекунду сохранять вашу геопозицию, например GPS координаты, то за сутки мы получим: 1000 миллисекунд в секунде × 60 секунд × 60 минут × 24 часа = 86 400 000 событий. Цифра очень впечатляет, особенно если масштабировать ее на всех людей на Земле. Более подробно о больших данных я расскажу в главе про хранилища данных.

Связность данных

Одна из важнейших характеристик данных – возможность связать разные источники данных. Например, если удается связать затраты на интернет-рекламу и продажи через нее, то вы получаете инструмент эффективности. Далее добавляем данные по реально доставленным заказам, так как в некоторых e-commerce-бизнесах процент отказов очень высок. И на выходе мы получаем эффективность с поправкой на отказы. Фантазируем дальше, добавляем к данным категории товаров – получаем возможность видеть эффективность рекламы в разрезе категорий товаров. Продолжать можно до бесконечности. Кстати, именно этот пример иллюстрирует то, что называется «сквозной аналитикой».

Вышеприведенный пример показывает, что, добавляя новый источник данных, мы можем улучшить точность и увеличить число «степеней свободы», что можно делать с самими данными. Лично для меня это увеличивает ценность данных на порядок. Вот только есть одна заминка с тем, как эти данные связать. Для этого нужен «ключ», который должен быть в обоих источниках, и этот ключ не всегда бывает настолько точным, насколько требуется нам. Поясню на примере. Чтобы идеально связать затраты на интернет-рекламу и покупки, нужен ключ – id пользователя. Но проблема в том, что, скорее всего, от рекламных систем вы не получите информации о том, сколько вы потратили денег на конкретного пользователя. Из-за этого приходится использовать набор ключей из ссылок, которые однозначно характеризуют рекламное объявление. Точность из-за этого страдает, но это реальная жизнь данных – лучше получить что-то, чем ничего.

Много данных не бывает

Эту фразу я повторял, когда работал в Ostrovok.ru. Я точно не помню, с чем она была связана, возможно, требовалось расширить парк серверов. Считаю, что в эпоху облачных вычислений, дешевого хранения данных и хороших алгоритмов их сжатия нужно сохранять максимально много и подробно. Поверьте, когда понадобится найти ответ на какой-то вопрос и вы будете понимать, что данных нет, а могли бы быть, будет очень обидно. Рано или поздно собирать их все равно придется, почему бы не начать прямо сейчас?

ВАЖНО! Здесь хочу поднять одну проблему: в какой бы компании я ни работал – везде разработчики игнорируют аналитиков. При разработке какого-либо функционала или продукта анализ его функциональности через данные ставится на последнее место. В лучшем случае будет сделан сбор простейших метрик по усмотрению разработчика. Дальнейший сценарий такой – менеджеры проекта или продукта, владельцы бизнеса начинают активно интересоваться его судьбой. Что там с цифрами? Бегут к аналитикам, просят нарыть хоть что-нибудь. А что может сделать аналитик, если данных для статистических тестов не хватает и точность страдает? Только высосать информацию из пальца. С таким положением вещей я лично сталкивался десятки раз, а случаи, когда все было сделано как надо, могу по пальцам пересчитать.

Я предлагаю активно бороться с этим. Разработку можно понять – им нужно как можно быстрее выкатить новую «фичу» с очень хорошим качеством. Анализ метрик их не волнует, это лишние строчки кода, это работа аналитиков. Что делать? Это сфера ответственности менеджера проекта/продукта, лица, от имени которого ставится задача разработке. Необходимо в процессе постановки подобных задач предусмотреть «визу» от аналитиков. Что в нее входит:

1. Отправка технического задания и примерного списка вопросов к эффективности новой разработки аналитикам.

2. Аналитики со своей стороны отдают вам список метрик, а также встречное техническое задание для логирования (сбора метрик) данных проекта: что собирать и в каком формате.

Этот процесс не так прост, как кажется. Часто приходится в итеративном формате договариваться обо всех нюансах и ограничениях, в том числе с разработчиками. Происходит своеобразный торг, но он стоит того. Заранее хорошо продуманный результат не будет идеальным на 100 %, но если менеджмент получит ответы на 80 % своих вопросов в течение нескольких дней с момента запуска «фичи» – это успех. Ничто не играет против нас так, как время! И лучше его потратить до запуска, а не после, теряя деньги на неэффективном продукте.

Доступ к данным

Теперь коснемся доступа к данным внутри компании. Кто может получить его?

Отвлечемся на компанию Netflix, один из крупнейших поставщиков сериалов (мой любимый – «Карточный домик»). У компании очень интересная корпоративная культура [32]. Один из ее принципов звучит так: «Share information openly, broadly, and deliberately» (обмениваемся информацией открыто, широко и сознательно).

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

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

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

Качество данных

Данные бывают грязными, очень грязными. Если вам встретятся «чистые» данные, то это, скорее всего, неправда. Но бывает, что в жизни сказочно везет. Аналитики данных тратят львиную долю своего времени на очистку данных от выбросов и прочих артефактов, которые могут помешать получить правильное решение. Мы все работаем в условиях неопределенности, и увеличивать ошибку из-за грязи в данных совсем не хочется.

Для меня качественные данные – это данные, которые могут быть использованы для решения конкретной задачи без каких-либо предварительных очисток. Я намеренно написал «конкретной задачи», потому что считаю: разные задачи требуют разной степени точности, так как последствия и уровень риска для компании разные. И мы движемся по лезвию бритвы, стараясь решить задачу как можно быстрее наименьшими усилиями, балансируем между трудоемкостью и ценой ошибки. Если это бухгалтерская задача, то она требует очень высокой степени точности, так как санкции налоговой службы могут быть весьма болезненными. Если управленческая и последствия не столь значимы, то некоторой степенью точности можно пренебречь. Решение здесь за руководителем аналитики.

Основные причины плохого качества данных:

• человеческий фактор;

• техническая потеря данных;

• ошибка интеграции и выгрузки данных в хранилище;

• отставание в обновлении данных в хранилище.

Рассмотрим более подробно.

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

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

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

Ошибки интеграции данных очень неприятны, они появляются в самый неожиданный момент, когда их не ждешь, их сложно диагностировать. Под ошибкой интеграции я понимаю потерю данных из-за неправильной работы процесса сбора данных. Она может быть обратимой и необратимой. Обратимая касается в основном ситуаций, когда мы забираем данные из какого-то источника, и чтобы исправить ошибку, достаточно данные перечитать из него. Необратимая ошибка связана с тем, что по факту данные «исчезают» после отправки к нам, то есть они идут потоком и нигде больше не сохраняются. Я уже писал, как обнаружил, когда одна из самых продвинутых систем в мире не передавала данные по браузеру Opera. После исправления данные стали передаваться, но старые данные уже не восстановить. Бывает, что разработчики сложного решения не предусмотрели, забыли или допустили ошибку в реализации сбора статистической информации об использовании продукта. В таком случае вы получите статистику только после исправления, а со старыми данными можно попрощаться навсегда.

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

Как проверяется и контролируется качество данных

Для меня это сродни искусству, но существует несколько полезных практик, из тех, которые по принципу Парето дают 80 % результата при затраченных 20 % усилий:

• мониторинг выгрузки данных в хранилище;

• здоровый скептицизм к полученным результатам анализа;

• статистический анализ выбросов;

• особое внимание к недублированным источникам данным.

Первый шаг для любой аналитической системы – ее мониторинг, а именно мониторинг обновления данных в хранилище. Это несложно, зато очень эффективно с точки зрения максимально быстрого поиска проблем. Такой мониторинг можно разделить на две части: одна отслеживает, что данные поступают в систему вовремя, вторая убеждается, что они корректны. Первая часть очень проста, как правило она реализована на специально программе или системе-планировщике (scheduler). Главное – правильно подписаться на уведомления об ошибках и вовремя на них реагировать. Лучше это делать, как в армии: лампочка загорелась – бежим исправлять; стоит составить инструкции для персонала, как действовать в случае аварии.

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

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

Выбросы – это данные, которые не укладываются в нашу картину мира, а точнее в распределение, которое мы обычно наблюдаем: кто-то совершил очень крупную покупку в магазине, поступили странные данные от одного из избирательных участков, зачислена аномально большая сумма на счет. Все это выбросы, но удалять их из анализа просто так нельзя. Часто удаление выброса может привести к изменению выводов и решений на полностью противоположные. Считаю, что работа с выбросами данных является искусством. Более подробно это рассмотрим в главе 10.

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