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

О журналах приложений (они же логи), ответах API и данных датчиков.

📎 Данные в логах - результат действий в ПО, пользовательских или внутренних.

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

📎 На что обратить внимание при работе с логами, как источником данных:
1️⃣ Структура, она же формат
2️⃣ Временные метки и их формат
3️⃣ Уровни логов:
➡️ Информация
➡️ Предупреждение
➡️ Ошибка
4️⃣ Цель
➡️ Диагностика
➡️ Аудит

📎 Почему часть инфо берётся через API - потому что своё приложение не может делать всё.

📎 На что обратить внимание при получении данных по API:
1️⃣ Объекты - что нам присылают, JSON, XML что-то ещё
2️⃣ Коды ответов. Например, коды состояния http (200 ok, 404 not found, 500 internal server error и тд) или другие стандарты
3️⃣ Цель использования. От этого зависит, на что обращать внимание, вариант использования может влиять на то, какая информация имеет значение.

📎 Данные датчиков. Тут про интернет вещей (IoT) или исследовательское оборудование с простой логикой.

📎 Важные моменты при работе с данными от датчиков:
1️⃣ Шум. Скорее всего, часть данных будет не репрезентативной и нужно быть готовым к их очистке, поэтому рекомендуется иметь устойчивый последовательный поток.
2️⃣ Режимы отказа. Важно понимать, как каждый из датчиков, с которых собираются данные, сообщает о неполадках: может выдавать ошибку, перестает поставлять данные или показывает рандомную температуру на Марсе.
3️⃣ Цель. Опять же, зачем эти данные собираются: для обучения моделей или решения задач, основанных на логике? В первом случае важен объем, во вторых - минимальная задержка.

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

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