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

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

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

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

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

В транзакционных базах данных (то есть тех, которые поддерживают работающие приложения и используются, например, для обработки заказов, а не для составления отчетов) довольно часто встречаются два поля: 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

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