Пирамида потребностей в работе с данными

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

Нам попался интересный материал, опубликованный в KDnuggets, по теме иерархии потребностей в Big Data, написанный техническим директором Data Culpa, Inc, Митчем Хейлом. В рамках нашей серии переводных текстов, мы решили сделать адаптацию этой публикации, чтобы рассказать вам чуть больше о больших данных и, может быть, дать пищу для размышлений специалистам из этой области.

Согласно пирамиде Маслоу, сначала человек стремится удовлетворить самые базовые потребности – такие, как пища и наличие крова. Затем следуют социальные потребности, а высшая ступень – потребность в творчестве и самореализации.

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

В идеале у команды должны быть инструменты для измерения качества данных на каждом из уровней пирамиды.

Содержание:

Чтобы получить качественные данные, сначала необходимо убедиться, что данные актуальны, и ими в принципе можно пользоваться.

Работал ли ваш пайплайн? Если да, то когда? Он производил новые данные или перерабатывал старые? Чтобы обнаружить «несвежие» данные, необходимо тщательно проверить систему на «застрявшие» каналы данных. Когда вообще ничего не обновлялось, это довольно легко увидеть. Но если переместился порядковый номер и временная метка, это ещё не значит, что всё нормально: остальные данные могут не «переехать».

После того как свежесть данных установлена, переходим на следующий уровень – их объем. В первую очередь, следует ответить себе на два вопроса:

1. Соответствуют ли объемы данных тому, что мы ожидали?

2. Если объемы данных меняются, соответствуют ли они тенденциям, которые мы уже наблюдали? Например, слабой активности в выходные дни или посреди ночи.

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

Следующая ступень в пирамиде потребностей – структура (формат) данных: имена и типы полей. Я встречал разные подходы к каталогизации. Кто-то использует данные формата JSON, хранящиеся в строковых (текстовых) полях, кто-то – системы, которые могут поддерживать подзаписи. К примеру, сервис для анализа больших объёмов данных BigQuery.

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

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

Наконец, мы рассматриваем содержание значений данных. Для оценки их качества нужно обозначить отдельные категории. Это делается в тех случаях, когда уникальность значений низка по сравнению с размером популяции. Чтобы проанализировать строки, вычислите ряд моделей для определения и захвата новых типов строк. Это позволит не терять время на такие простые вопросы, как «Является ли значение строки нулевым?» или «Какова её длина?».

Отладка потоков данных приводит к таким вопросам, как "Почему это поле имеет такое значение?".

Когда я занимался построением конвейеров данных, я сталкивался с этим снова и снова. Моим решением было дополнить данные полями, в которые я мог вставлять метаданные. Например, текстовое объяснение, имя файла скрипта и номер строки, другие переменные – всё, что мне понадобится для последующей отладки возможной проблемы. Записи вроде: "Я пометил этот товар как отсутствующий на складе, потому что два источника данных сказали, что его нет в наличии, хотя третий источник данных говорит, что у нас есть 1000 штук" – полезная вещь при дальнейшей работе с данными.

Не каждый имеет возможности и ресурсы, чтобы добавить более-менее серьёзный объём метаданных. Многое зависит от объёмов данных и их стандартизированности. Но если вы можете сделать это – сделайте. Инструменты, которые автоматически выявляют проблемы с полями данных, могут также анализировать и ваши новые поля метаданных. Это приведет к появлению оповещений о метаданных, которые смогут предупредить вас об изменениях на периферии.

Следует помнить, что пирамида потребностей действительно является пирамидой. Она строится «снизу вверх», и если на нижних уровнях есть недоработка – то всё рушится. Все начинается с актуальности данных. Если данные, которые вы анализируете на верхних уровнях иерархии, устарели, у вас будет ложное чувство уверенности в их качестве. Вы будете думать, что сегодняшние данные великолепны, хотя у вас перед глазами данные, полученные в прошлую среду.

Когда вы убедились, что данные свежие, можно переходить к более высоким ступеням пирамиды. Убедитесь, что у вас есть все нужные данные. Проверьте, понимаете ли вы их структуру . И так далее – ступень за ступенью.

Я рекомендую командам по работе с Big Data убедиться, что у них есть инструменты для любого из этих уровней, и что они могут отдельно отслеживать каждый уровень. Когда все уровни будут показывать хорошие результаты, вы будете знать, что удовлетворили все потребности вашей пирамиды. Это позволит вашей data-команде работать с максимальной эффективностью. Даже Маслоу был бы доволен.

Митч Хейл – технический директор Data Culpa, Inc. У него более пятнадцати лет опыта в сфере обработки данных для розничной торговли, машинно-генерируемых данных, компьютерного зрения и приложений для аналитики. Он также имеет опыт создания решений для центров обработки данных. Митч помогал разрабатывать продукты для таких компаний, как Data Domain (продана EMC), Pancetera (продана Quantum) и Conjur (продана CyberArk). Он является соавтором более 25 выданных патентов на изобретения в области сжатия данных, оптимизации данных и защиты данных.