Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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