Текст книги "Аналитическая культура. От сбора данных до бизнес-результатов"

ДУБЛИРОВАНИЕ ДАННЫХ

Еще одна распространенная проблема – дублирование данных. Это означает, что одна и та же запись появляется несколько раз. Причины могут быть разными: например, предположим, у вас десять файлов, которые нужно внести в базу данных, и вы случайно загрузили файл номер шесть дважды, или при загрузке файла возникала ошибка, вы остановили процесс, устранили ошибку и повторили загрузку, но при этом первая половина данных загрузилась в вашу базу дважды. Дублирование данных может возникнуть при повторной регистрации. Например, пользователь прошел регистрацию несколько раз, указал тот же самый или другой адрес электронной почты, в результате чего у него появилась другая учетная запись с той же самой персональной информацией. (Звучит просто, но подобная неопределенность может оказаться весьма коварной.) Дублирование информации также может возникнуть в результате того, что несколько приборов фиксируют ее по одному событию. В исследовании медицинских ошибок, о котором шла речь ранее, в 35 % случаев причиной ошибки был неправильный перенос данных из одной системы в другую: иногда данные терялись, иногда дублировались. По данным госпиталя Джонса Хопкинса, в 92 % случаев дублирование информации в их базе данных происходило в момент регистрации стационарных больных.

Когда речь идет о базах данных, есть несколько способов предотвратить дублирование. Наиболее эффективный – добавление ограничений в таблицу с базой данных. Вы можете создать составной ключ, который определяет одно или несколько полей и делает запись уникальной. После добавления этого ограничения у вас будет появляться оповещение, если вводимая комбинация данных совпадет с уже существующей в таблице. Второй способ – выбор варианта загрузки данных по принципу «все или ничего». Если в момент загрузки данных обнаруживается проблема, происходит откат на изначальные позиции, а новая информация в базе данных не сохраняется. Это дает шанс разобраться с причиной проблемы и повторить процесс загрузки данных без дублирования информации. Наконец, третий (менее эффективный) подход – выполнять две операции при загрузке: первая операция – SELECT, чтобы выяснить, не присутствует ли уже такая запись, вторая операция – INSERT, добавление новой записи.

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

УСЕЧЕННЫЕ ДАННЫЕ

При загрузке информации в базу данных часть ее может потеряться (Anderson → anders или 5456757865 → 54567578). В лучшем случае можно лишиться пары символов в форме обратной связи. В худшем может произойти усечение и объединение идентификационных данных двух разных клиентов и вы непреднамеренно объедините данные двух разных клиентов или заказов в один.

Как такое может произойти? В обычных реляционных базах данных при создании таблицы задаются название и тип каждого поля: например, должен быть столбец под названием «Фамилия» с ячейками, содержащими до 32 символов, или столбец «ID клиента» с целым числом в диапазоне от 0 до 65535. Проблема в том, что не всегда заранее известно максимальное количество символов или максимальное значение идентификатора, с которыми вам придется столкнуться. Возможно, вы получите образец данных, рассчитаете длину ячейки и для подстраховки увеличите это значение в два раза. Но вы никогда не узнаете наверняка, достаточно ли этого, пока не начнете работать с реальными данными. Более того, в базах ошибки с усечением данных, как правило, относятся к категории предупреждений: появляется оповещение, но процесс загрузки данных не прекращается. В результате такие проблемы легко не заметить. Один из способов предотвратить это – изменить настройки в базе данных, чтобы предупреждения отображались как полноценные ошибки и заметить их было легче.

ЕДИНИЦЫ ИЗМЕРЕНИЯ

Еще один источник проблем с качеством данных – несовпадение единиц измерения, особенно когда речь идет о международных командах и наборах данных. CNN сообщает[35]35
  URL: http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/


[Закрыть]:

Агентство NASA потеряло орбитальный аппарат по исследованию Марса стоимостью 125 млн долл. из-за того, что команда технических специалистов корпорации Lockheed Martin использовала при расчетах английские единицы измерения [фунт-секунда], в то время как специалисты самого агентства пользовались более привычной метрической системой [ньютон-секунда] для управления аппаратом.

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

Другая область, где единицы измерения имеют критическое значение, – денежные валюты. Представим сайт для электронной коммерции, на котором размещен заказ стоимостью 23,12. В США по умолчанию будет считаться, что это 23,12 долл., в то время как во Франции это будет 23,12 евро. Если заказы из разных стран окажутся объединены в одну базу данных учета информации по валютам, то итоговый анализ будет иметь отклонения в сторону более слабой валюты (поскольку в числовом выражении цена за тот же предмет будет выше) и фактически окажется бесполезен.

Базы данных должны обеспечивать столько метаданных и контекста, сколько необходимо, чтобы избежать подобного недопонимания.

Кроме того, можно просто принять метрическую систему и придерживаться ее (проснись, Америка!).

ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ

Следующая проблема с данными, которую в некоторых случаях бывает сложно отследить, это значения по умолчанию (рис. 2.3A и D). Пропущенные данные могут отражаться в базе данных как NULL, но также может использоваться определенное значение, которое можно задать. Например, 1 января 1900 года – стандартная дата по умолчанию. С ней могут быть разные проблемы. Во-первых, если вы забудете о том, что эта дата появляется по умолчанию, результаты анализа могут вас весьма озадачить. Предположим, вы оставили это значение по умолчанию в ячейке с датой рождения. Аналитиков может смутить тот факт, что столько людей в вашей базе данных старше 100 лет. Во-вторых, при неудачном значении по умолчанию есть риск перестать различать пропущенные и актуальные данные. Например, если вы устанавливаете «0» как значение по умолчанию для пропущенных данных, а значение актуальных данных тоже может быть равным 0, впоследствии вы не сможете определить, в какой ячейке отражены результаты измерения, а в какой просто пропущены данные. Отнеситесь к выбору значений по умолчанию внимательно.

Происхождение данных

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

Эти метаданные делятся на два типа: история источников (отслеживает, откуда появились данные) и история преобразований (отслеживает, какие изменения претерпевали данные).

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

В транзакционных базах данных (то есть тех, которые поддерживают работающие приложения и используются, например, для обработки заказов, а не для составления отчетов) довольно часто встречаются два поля: created_at (время создания) и last_modified (последнее изменение). Как следует из названия полей, они содержат уточняющую информацию о времени создания записи (эта метаинформация заносится один раз и больше не меняется) и о времени, когда было сделано самое недавнее изменение (эта метаинформация обновляется в режиме реального времени каждый раз, когда в запись вносятся любые изменения). Иногда в таблице может быть дополнительное поле modified_by, в котором фиксируется имя пользователя, внесшего последнее изменение. Это помогает определить, например, было ли изменение в заказе или адресе электронной почты сделано самими пользователями или представителем, действующим от имени клиента. В данном случае элемент created_at – история источников, в то время как элементы last_modified и modified_by отражают историю преобразований. Наиболее детальный инструмент отслеживания происхождения – таблицы с журналом событий, где четко протоколируется, какие именно изменения, кем и когда были внесены.

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

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

Качество данных как совместная ответственность

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

Таблица 2.1. Краткий обзор некоторых типов проблем с качеством данных и потенциальные варианты их решения. Более подробный список можно найти у Singh and Singh. A descriptive classification of causes of data quality problems in data warehousing, IJCSI Intl. J. Comp. Sci 7, no. 3 (2010): 41–50

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

Далее руководители направлений и эксперты в предметных областях должны проверить качество данных. Аналитики должны провести разведочный анализ или воспользоваться собственными методами определения, находятся ли значения в допустимых границах, соблюдаются ли ожидаемые закономерности (например, соотношение систолического и диастолического давления), оценить объем пропущенных данных и так далее. На фермерском рынке шеф-повар ресторана сам выбирает продукты, пробует авокадо, нюхает базилик. Образно говоря, это его сырые ингредиенты. У аналитиков должно быть такое же отношение к данным. Это их сырые ингредиенты, которые они должны тщательно отобрать.

Руководители направлений, как правило, принимают решения о покупке баз данных у третьих сторон, о разработке инструментов по сегментированию аудитории в ходе опроса клиентов или о проведении A/B-тестирования онлайн. Они тоже должны задумываться об объективности данных, на которые опираются. Они должны проводить сами или делегировать проведение разведочного анализа данных, составлять диаграммы распределения и обнаруживать «пятидюймовых» людей.