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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📎 Бизнес хочет видеть данные в режиме реального времени, а не идеальное состояние.

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

📎 Важно понимать работоспособность своих данных в текущем состоянии на каждом этапе (наблюдаемость).

📎 В работе с данными можно брать принципы из смежных областей, например, DevOps.

Измерение окупаемости инвестиций в качество

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

📎 Стоимость простоя данных = Почасовая стоимость простоя * (Время обнаружения + Время разрешения)

📎 Время обнаружения - время, которое нужно чтобы владелец данных выявил проблемы любого рода. Может составлять недели и месяцы, когда находят последующие потребители. (TTD)

📎 Время разрешения - время, которое нужно для устранения инцидента. Обычно - минуты, часы, реже - дни. (TTR)

📎 Почасовая стоимость простоя - обобщенный показатель, время разработки, потраченное на один час простоя + влияние простоя на потребителей и бизнес-решения.

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

📎 Ежегодная стоимость некачественных данных = зарплата инженеров (=количество инженеров * 130% годового оклада) + риск комплаенса (= около 5% годового дохода) + альтернативные издержки ( = упущенная выгода + штрафы и др)

📎 Выделяют несколько способов взаимодействия и реакции на качество данных:
⤴️ Панель мониторинга, которая показывает время обнаружения, время решения и другие показатели;
⤴️ Соглашения об уровне обслуживания (SLA) - про обещания клиентам (например, доступность 99,99%)
⤴️ Индикаторы уровня обслуживания (SLI) - про цифры (например, 100500 ответов или не больше 100 инцидентов в единицу времени)
⤴️ Цели уровня обслуживания (SLO) - про фактические целевые значения для SLI (99% времени обеспечивать 95% качества)
⤴️ Рейтинг поставщика - насколько потребители довольны результатом работы

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

📎 Шесть ключевых параметров, на основании которых стоит заключать соглашения:
1️⃣Полнота
2️⃣Своевременность
3️⃣Валидность
4️⃣Точность
5️⃣Согласованность
6️⃣Уникальность

📎 SLA, SLO, SLI нужны для обеспечения надёжности и установления понятных ожиданий, приоритезации интересов и реагирования.

📎 Заключение всех этих соглашений "в воздух" бессмысленно, основываться стоит на реальной ситуации и согласовании со всем готовности к сотрудничеству.

📎 Перед заключением соглашений рекомендуют:
1️⃣Узнать бизнес-приоритеты
2️⃣Понять связь с данными
3️⃣Узнать потребность в высоком качестве данных/терпимость к некачественным данным
4️⃣Наблюдать за текущей ситуацией в части возможных договорённостей
5️⃣Скорректировать ожидания, свои и контрагентов

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

📎 Выводы:
➡️ Инвестировать в проверки данных и профилирование стоит заранее и во всех областях
➡️ Отказоустойчивая платформа данных нужна и важна
➡️ Заключение и выполнение соглашений об уровне обслуживания повышают качество результатов работы организации

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

4 часа в ласточке - отличное время, чтобы прочитать ещё одну главу книги по качеству данных!

Наушники от внешнего шума, стук колес для погружения, зелень за окном для медитации. И никто не трогает! Целых четыре часа!

На обратном пути думаю подготовить текст для постов 📝

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

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

📎 Для исправления проблем с качеством данных можно использовать практики DevOps и SRE-инженеров. Всё уже придумано и успешно применяется в разработке. Это позволит применять к качеству данных упреждающий и масштабируемый подход.

📎 Жизненный цикл DevOps включает 8 последовательных этапов, затем повторяется:
1️⃣ Планирование
2️⃣Разработка
3️⃣Сборка
4️⃣Тестирование
5️⃣Выпуск в пром
6️⃣Интеграция в существующую систему
7️⃣Эксплуатация
8️⃣Мониторинг

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

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

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

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

📎 Жизненный цикл надежности данных:
1️⃣Обнаружение
2️⃣Решение
3️⃣Предотвращение

📎 Рабочий процесс управления инцидентами:
1️⃣Обнаружение
2️⃣Реагирование
3️⃣Анализ первопричин
4️⃣Решение
5️⃣Разбор инцидента

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

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

📎 Обнаружение инцидентов – это многоуровневый процесс, который опирается не только на способность обнаруживать инциденты, но и реагировать на них, разрешать и предотвращать итеративным и повторяемым способом.

📎 В этап обнаружения входит не только сам факт знания, что что-то сломалось, но и понимание что именно, почему, где и на что/кого влияет, что дальше делать.

Тут начинается второй этап – реагирование.

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