Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Что такое качество данных? Это что-то абсолютное или относительное для каждой задачи? В чём измерять качество данных?</p>

2 <p>Качество имеет несколько определений: - обладание определённым свойством (схоже с "характеристикой"); - стандарт чего-то, сравнимый с другими объектами того же типа, степень отличия.</p>

3 <p>Для разных ролей, вовлечённых в процесс разработки и использования аналитических платформ, важны<strong>разные определения качества</strong>: 1. Для data scientists важно, чтобы данные обладали свойством описать исследуемый феномен для разработки предсказывающей или классифицирующей модели; в такой постановке задач важны атрибуты с высокой информационной ценностью, и, например, абсолютная полнота данных уже не так важна. 2. Для software/data engineers важно второе определение, оно обеспечивает знание о том что данные "не стали хуже" во время загрузки и обработки в платформе; также для инженеров важна гранулярная измеримость качества, возможность рассуждать о качестве отдельной записи, партиции, датасета, чтобы информировать о плохом качестве как можно раньше.</p>

4 <p>Будучи инженером и архитектором хранилищ данных и data lake, в этой заметке я изложу свой<strong>подход к инженерной стороне качества данных.</strong></p>

5 <h2>Архитектурный концепт data lake</h2>

6 <p>Ключевое свойство класса решений на data lake - это использование подхода<strong>schema-on-read</strong>: мы принимаем и храним все данные, и рассуждаем об их структуре только в момент чтения для конкретной задачи. Для реализации<strong>schema-on-read</strong>чаще всего используют следующую архитектуру, в очень общем виде:</p>

7 <p>1.Слой базовых или сырых данных: данные доставляются сюда в таком виде, в каком их выдал источник, например, если источник передаёт<strong>CSV-файл</strong>, то в слое сырых данных этот файл будет лежать в формате CSV.</p>

8 <p>2.Слой структурированных или курированных (curated) данных: в этом слое к данным применяют структуру, которую выяснили/предположили/согласовали инженеры, в нашем примере с CSV-файлом мы создадим его копию в формате Avro, и эта копия будет хранится в слое структурированных данных.</p>

9 <p>3.Слой дата продуктов/витрин/аналитических датасетов: в этом слое хранятся данные, преобразованные для решения конкретной бизнес-задачи, говоря языком разработчиков ПО, "здесь появляется бизнес-логика"; возвращаясь к нашему примеру, файл Avro является списком взаимодействий клиентов, и дата продуктом могут быть датасеты в формате ORC, представляющий граф взаимодействий клиентов.</p>

10 <p>Это очень абстрактный архитектурный концепт, он явно не описывает различные пограничные случаи, например, когда данные от источника сразу поступают в структурированном виде (Avro выгрузка из Apache Kafka) или работу с бинарными данными, но детальный разбор этого концепта лежит за рамками данной заметки, он служит нам для иллюстрации проблем и задач, связанных с качеством данных.</p>

11 <h2>Качество на входе, качество на выходе</h2>

12 <p>Разделим задачи качества на две части:</p>

13 <h3>1. Техническое качество данных</h3>

14 <p>Техническое качество данных - это соответствие данных заявленной структуре; если расписать эту формулировку более практическим языком, то это соответствие данных той схеме, которая подразумевается для них в какой-то момент, плюс полнота данных по отношению к предыдущему этапе их обработки. Сюда же мы отнесём сохранность данных при передаче, если такую требуется контролировать.</p>

15 <p>С точки зрения основных задач аналитической платформы, техническое качество - это качество на входе, то есть до того как мы начали интегрировать и агрегировать данные соотнося их с бизнес-логикой. В применении к реляционным СУБД это будет означать, что данные соответствуют определениям типов колонок в таблицах и правилам ссылочной целостности (PK, FK).</p>

16 <p>Такое качество считается и контролируется без знания предметной области, всё, что нам нужно знать - это какая схема нужна для конкретного датасета, причём, так как это data lake, нам подойдет даже обоснованное (на примере тех данных что мы уже собрали) предположение - сырые данные у нас остаются, и в худшем случае нам нужно будет пересчитать какие-то результаты.</p>

17 <h3>2. Бизнес-качество данных</h3>

18 <p>Нам удалось загрузить данные без потерь, они представлены в удобном формате, где не потерялось ни одно значение ни в одной колонке, теперь мы хотим извлекать из данных бизнес-ценность. Как я писал выше, в этом случае нам важна применимость данных для конкретной задачи из нашей предметной области, но также важна и достоверность данных с точки зрения нашей предметной области.</p>

19 <p>Примеры: - у нас есть клиенты и договора обслуживания, у нас может быть правило, что у клиента всегда есть как минимум один договор обслуживания; - у клиента должен быть определенный статус для определённых видов продуктов; - клиент должен существовать в нашем клиентском каталоге (задача интеграции данных); - и многие другие.</p>

20 <p>Я привожу примеры из бизнес-процессов, и по аналогии мы называем такие условия достоверности<strong>бизнес-правилами</strong>. Таким образом, бизнес качество данных - это соответствие данных заданному множеству бизнес-правил. С точки зрения создателей data lake<strong>бизнес качество данных - это качество на выходе</strong>.</p>

21 <h2>Контроль и управление качеством данных в data lake</h2>

22 <p>Предлагаю вашему вниманию следующий подход к контролю и управлению качеством данных:</p>

23 <h3>В слое сырых данных</h3>

24 <p>Согласно принципу schema-on-read мы не форсируем свою схему при записи в data lake (хотя мы, конечно, не откажемся от структурированных данных сразу от источника). Поэтому в слое сырых данных мы можем сделать только следующие проверки: 1. Базовая проверка по формату: нужное количество разделителей в CSV, наличие схемы в Avro или Parquet. 2. Сверка с техническими метаданными, если такие поставляет источник: проверка контрольных сумм, числа строк, и прочее.</p>

25 <p>По моему опыту базовые проверки по формату стоит использовать либо в самом начале жизни платформы, либо по отношению к очень враждебным источникам (мы о них мало что знаем, они вносят изменения в системы выгрузки о которых мы не знаем) - помните, каждая проверка это использование ресурсов вашей платформы, которые даже в самых крупных компаниях не бесконечны. Оптимально делать все проверки отключаемыми (и запускаемыми для прошлых доставок).</p>

26 <h3>В слое структурированных данных</h3>

27 <p>Напомню, что согласно общей концепции мы берём данные из сырого слоя, парсим их, и кладём версию с навязанной схемой в слой структурированных данных. В момент парсинга могут возникнуть атрибуты или целые записи, которые не могут быть распарсены: атрибут не соответствует типу, в строке недостаточное количество колонок/разделителей и так далее. Наша задача - выделить такие атрибуты и записи, и указать, почему они не прошли проверку.</p>

28 <p>К счастью, такая задача легко автоматизируема. Чаще всего один источник оперирует каким-то одним/двумя форматами для выгрузок, и нам достаточно реализовать логику парсинга этих форматов, управляемую параметрами или метаданными джоба. По моему опыту, в любом крупном data lake нужен парсер CSV, JSON и XML.</p>

29 <p>Пример такого джоба можно посмотреть<a>тут</a>. Он принимает на вход JSON-файл со схемой, разбирает CSV-датасет и формирует два результата: основной, куда попадают строчки, которые удалось привести к нужным типам, и INVALID, куда попадают строки, непрошедшие парсинг, с указанием на колонку и атрибут, которые не удалось привести к заданному типу.</p>

30 <p>Как реагировать на появление записей, которые не удалось структурировать? Это проектный вопрос, который решается в каждом конкретном случае: - для каких-то источников появление таких строк может быть признаком того, что наша логика парсинга устарела, и источник провёл изменения - тогда нам нужно обновить нашу схему и повторить парсинг (повторная выгрузка не требуется); - для других источников это может быть ошибка на стороне источника, и нам потребуется провести вторую выгрузку через сырой и структурированный слой.</p>

31 <p>В самом начале жизни такой платформы имеет смысл добавить счетчики "плохих" данных в системы мониторинга, чтобы операционный персонал имел возможность быстрой диагностики таких проблем в случае жалоб пользователей.</p>

32 <h3>В слое дата-продуктов</h3>

33 <p>Дата-продукты - это отражение предметной области и бизнес-логики наших пользователей, поэтому здесь мы контролируем бизнес качество данных.</p>

34 <p>(В слое дата продуктов чаще всего не контролируют техническое качество данных, это делается средствами тестирования аналитических джобов).</p>

35 <p>Проще всего думать о каждом бизнес-правиле, как об отчёте, он может быть агрегированным (количество клиентов Х не удовлетворяют бизнес правилу М), может быть детальным (все клиенты, которые не удовлетворяют правилу М), партицированным (все клиенты в партиции О, которые не удовлетворяют правилу М) или накопленным итогом.</p>

36 <p><strong>Критерии успеха правил бизнес качества</strong>: они прозрачны для специалистов в предметной области, ими затребованы (или согласованы), и адресуют существующую проблему (помните о потреблении ресурсов на каждый тест качества данных).</p>

37 <p>Чаще всего отчёты о бизнес-качестве собраны в отдельную витрину/проект и подключены к системе отображения отчётности, а также чаще всего материализованы, чтобы была возможность сопоставить их с версиями до правок в логике (часто в слое дата-продуктов данные могут перезаписываться).</p>

38 <h2>Итог</h2>

39 <p>В этой заметке вы ознакомились с<strong>классификацией требований по качеству данных</strong>для инженеров, работающих с data lake, и подходом к их реализации: - техническое качество данных рассматривается как соответствие схеме/формату и реализуется в процессе структурирования данных; - бизнес-качество данных рассматривается как соответствие бизнес-правилам и реализуется как система отчетов в процессе создания дата-продуктов.</p>