Та-дам!
А вот и статья 📝

https://habr.com/ru/companies/oleg-bunin/articles/899742/

Новичкам привет! Расскажите немного о себе?

Основы качества данных, глава третья, часть 4/5.

Мысли про обработку и преобразование данных.

📎 Пакетная или потоковая обработка - зависит от задач и желаемого результата, у каждого способа свои плюсы и минусы.

📎 Основная разница - в объёме данных, обрабатываемых в каждом пакете и скорости обработки. Качество данных у пакетной обычно выше.

📎 Преобразование данных - неотъемлемая часть работы с данными. Включает в себя:
1️⃣Нормализацию данных. Тут под нормализацией понимается приведение к конечному формату
2️⃣ Работу с разнородными источниками данных, и здесь могут быть свои подводные камни:
➡️ Задержка и рассинхрон данных, особенно при потоковой обработке
➡️ Отсутствие иерархии, вместо "БД+схема+таблица" возможно полотно текста
➡️ Необработанные форматы файлов, например с датчиков
➡️ Необязательные поля
➡️ Гетерогенность данных и необходимость приводить их в структурированную форму
3️⃣Проверку схемы и приведение типов

📎 Изменение схем - основной источник повреждения данных.

📎 Достижение синтаксической и семантической однозначности в данных очень важно! Особенно в рамках одной команды/продукта, на всех этапах работы с данными. Например, поле "dr" можно воспринять как "др." - другое, а можно как "дорогая редакция" - что-то важное. Способ округления чисел, вверх или вниз, имеет значение, а еще стоит учитывать числа с плавающей точкой.
Желающие могут погуглить анекдот про возврат товара с надписью "Х" и "П", он наглядно демонстрирует последствия отсутствия договоренности.

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

📎 Ничего не сломать при ETL/ELТ (особенно в части преобразования) - возможно. Если очень постараться)

#качестводанных #dataquality #dqf

Основы качества данных, глава третья, часть 5/5.

Мысли о проверках данных.

📎 При проверке тест-кейсы пишут с учетом логики работы системы, но она тоже может сломаться

📎 Распространённые проверки:
➡️ Нулевые значения
➡️ Неизвестные значения (NULL)
➡️ Объём
➡️ Факт получения данных и их размер
➡️ Допустимость диапазона данных
➡️ Инварианты

📎 Проверки желательно проводить перед преобразованием и после каждого этапа процесса преобразования, на всех этапах обработки, от приема данных до передачи их дальше

📎 Рекомендуется использовать разные виды проверок:
➡️ Сингулярные (индивидуальные, для конкретной схемы/таблицы/атрибута)
➡️ Модульные (для продукта, схемы, какой-то части данных)
➡️ Общие (шаблонные, которые легко масштабировать):
1️⃣Уникальность
2️⃣Полнота not_null
3️⃣Принадлежность конечному набору данных
4️⃣Ссылочная целостность

📎 Необходимо регулярно актуализировать проверки при изменении/доработке скрипта обработки данных, удалять лишние и добавлять новые

📎 Quality Gate или "автоматический выключатель" - важная штука для качества данных. Если данные не проходят пороговые значения критичных проверок - они не идут дальше по тракту. Стоит использовать только для проверок, ошибки в которых могут привести к серьезным последствиям

📎 Даже при самых жестких проверках могут остаться ошибки в данных.

#качестводанных #dataquality #dqf

Основы качества данных, глава четвертая, часть 1/2.

Мысли о мониторинге и обнаружении аномалий в данных.

📎 Аномалии в данных могут появиться из-за причин, не связанных с самими данными (🔥 если такое было)

📎 Чаще всего аномалии выявляются с помощью простых проверок.

📎 Раньше проверка данных считалась полезной, но не обязательной. Сейчас данных больше, их ценность и значимость выше и управление данными, качество данных - уже неотъемлемый атрибут работы с данными.

📎 Можно выделить два основных типа проблем с данными:
1️⃣Известные неизвестные (можно предсказать или предположить, что может пойти не так, большинство можно поймать проверками)
2️⃣Неизвестные неизвестные (как суслик - его никто не видит, а он есть. Например, изменение схемы другой командой, изменение кода, изменение историчных данных, если на это нет отдельных проверок)

📎 Если есть понимание, какие данные считать "хорошими", легче найти "плохие".

📎 Алгоритм обнаружения аномалий:
1️⃣Мониторинг актуальности. Когда данные были обновлены последний раз? Какой период времени приемлем после последнего обновления?
2️⃣Понимание распределения. Какими должны быть ваши данные? Сколько их? Каждый день по 100 строк с похожими цифрами? От чего может завистеть? Есть ли "сезонность" (от времени суток, дня недели, времени года, места)? Предсказуемые колебания? Тут речь про нормальное распределение (распределение Гаусса) и Центральную предельную теорему — сумма большого количества слабо зависимых случайных величин, имеющих примерно одинаковые масштабы, имеет распределение, близкое к нормальному. Готовь сани летом, а покупай зимой, чтобы не сломать магазинам проверки :)
3️⃣Контекст. Какие ранее осуществлённые манипуляции могут быть причиной? Что может быть затронуто еще? На что влияют эти аномалии?

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

#качестводанных #dataquality #dqf

Основы качества данных, глава четвертая, часть 2/2.

Мысли о мониторинге и обнаружении аномалий в данных.

📎 Аномалии можно описывать кратко и полно, и это будет влиять на скорость устранения. Полное и подробное описание может ускорить решение проблемы.

📎 Основные столпы наблюдения за данными (они же - следующие пункты для поиска аномалий):
4️⃣Схема данных и её изменения.
5️⃣Граф зависимостей данных, их происхождение и путь.

📎 Эвристика, (а на деле - глубокое погружение в процессы и данные), ускоряют поиск аномалий и их устранение.

📎 Гарантировать, что все проблемы, выявленные мониторингом, подлинные - невозможно.

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

📎 Для поиска золотой середины и параметров настройки можно использовать метрики точности моделей для машинного обучения (насколько часто предупреждения верны).

📎 Ложноположительный результат лучше, чем ложноотрицательный (согласны?)

📎 Параметр точности не может быть одинаковым для разных данных.

📎 Лучшие алгоритмы обнаружения аномалий делают три вещи:
1️⃣обнаруживают проблемы как можно раньше
2️⃣сообщают о них тем, кому нужно знать
3️⃣предоставляют информацию, которая поможет сократить простои данных

📎 Лучшие практики мониторингов:
➡️ Определение правил и порогов
➡️Использование авторегрессии (проверка прошлых периодов для прогноза будущих и сравнение реального с прошлым)
➡️ Использование экспоненциального сглаживания

📎 Основные различия между алгоритмом поиска аномалий для DWH и Data Lake
1️⃣Количество точек входа
2️⃣Сбор и хранение метаданных
3️⃣Доступ к метаданным

📎 Должна быть точка оборы - какая-либо базовая истина.

#качестводанных #dataquality #dqf

Основы качества данных, глава пятая, часть 1/2.

Мысли об архитектуре для обеспечения надёжности данных.

📎 Большие корпорации уже больше 5 лет говорят о том, что качественные данные лежат в их основе.

📎 Надёжность данных является результатом высокого качества данных. Это способность обеспечить доступность и работоспособность данных.

📎 Её нужно целенаправленно встраивать на все уровни.

📎 Качество принимаемых решений зависит от данных.

📎 Обнаружение проблем с данными в момент их приёма может свести к минимуму большие проблемы в дальнейшем.

📎 Обогащение данных может повысить их ценность, сделать более полезными и надёжными.

📎 Основные типы тестирования качества данных:
⤵️ Модульное
⤵️ Функциональное
⤵️ Интеграционное

📎 Общие проверки ККД:
✅ На нулевые значения
✅ На null
✅ На актуальность
✅ На объем
✅ На выбросы в диапазоне
✅ На отсутствующие значения

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

📎 Тестирование выявит только ожидаемые проблемы.

📎 Данные сильно меняются на своём пути, их нужно регулярно проверять.

📎 Обеспечение качества данных в процессе обработки основывается на:
🟢 Свежесть (не то же самое, что актуальность)
🟢 Распределение
🟢 Объём
🟢 Схема
🟢 Происхождение

📎 На дашборды можно выводить общую информацию:
➡️ Соотношение всех данных к неактуальным или ошибочным
➡️ Количество нулевых или отсутствующих значений
➡️ Процент повторяющихся значений
➡️Согласованность данных
➡️ Количество функциональных групп, которые используют эти данные (потребителей)

📎 Основные слои платформы данных:
📊 Приём
📊 Хранение и обработка
📊 Преобразование и моделирование
📊 Аналитика всех видов
📊 Качество данных и наблюдаемость
📊 Обнаружение и управление данными

📎 Данные, проверенные при приёме не обязательно останутся надёжными по мере их продвижения

📎 Основные типы хранения данных, без приоритезации. Ни одно не лучше другого, для разных организаций или на разных этапах могут меняться:
1️⃣ Data Base
2️⃣ Data Lake
3️⃣ Data Warehouse

📎 Преобразование - подготовка для анализа и составления отчетов.

📎 Моделирование - определение ключевых концепций и связей.

📎 Без визуализации данные практически недоступны и их сложно использовать.

📎 Экосистемы становятся больше и сложнее и используют большие объемы неструктурированных и бессхемных данных, каталоги данных могут отказаться неэффективными из-за отсутствия автоматизации и неспособности масштабироваться.

#качестводанных #dataquality #dqf