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

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