Основы качества данных, глава третья, часть 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️⃣ Цель. Опять же, зачем эти данные собираются: для обучения моделей или решения задач, основанных на логике? В первом случае важен объем, во вторых - минимальная задержка.

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