Сегодня разберем распространенные трудности корпоративных платформ обработки и хранения Big Data, а также как избежать этих проблем, используя современные методы и средства проектирования дата-архитектур и инструменты инженерии данных.
7 главных проблем с платформами данных
Обычно каждая data-driven компания органично развивает свои платформы данных, усложняя их архитектуры. Но этот процесс эволюционного развития может привести к проблемам, которые в конечном итоге ограничат эффективность управления на основе данных. В частности, можно столкнуться со следующими проблемами:
- Отсутствие определения данных, что мешает правильно интерпретировать их значения. Единый источник определения данных исключает случаи, когда разные команды имеют разные значения одних и тех же данных. Решить эту проблему поможет центральный каталог определений данных и бизнес-глоссарий. Здесь же можно отметить важность сохранения истории изменения данных, включая их версионирование. Это решается инструментальными средствами построения современных дата-архитектур, например, через создание моментальных снимков в таблице Delta Lake или Apache Iceberg, о чем мы писали в этой статье.
- межсистемное несоответствие, когда каждая команда имеет собственное представление данных, включая разные форматы или типы. Избежать этого поможет механизм единогласного отображения данных в системе, включая схемы данных и таблицы их сопоставления. Значения по умолчанию должны быть идентифицированы и обработаны определенным образом. Например, 1 января 1970 года, что является начальной датой в Unix-системах. Это можно решить с помощью каталогов, где в определениях данных явно указано их значение по умолчанию.
- отсутствие данных, включая атрибуты, значения и сами записи. Например, ключевые столбцы отсутствуют в источнике данных, что может быть связано с проблемой в системе сбора или с ошибкой во время передачи данных из источника в конвейер данных. На практике отсутствующие атрибуты могут привести к сбою нижестоящего конвейера. Лучший способ исправить это — внедрить валидацию схемы данных и контроль структуры согласования. Иногда в некоторых ячейках могут отсутствовать значения, и нужна правильная стратегия для обработки этих записей: заполнение значений по умолчанию или отбрасывание пустых значений. А если фактическое количество записей не соответствует ожидаемому, следует использовать метаданные для проверки согласованности данных. Это можно реализовать, запросив у источника данных файл метаданных, содержащий схему данных и количество строк. Кроме того, можно проверять тенденции изменения данных, чтобы увидеть, попадает ли фактическое количество строк в диапазон допустимых значений, например, +/- 5% от количества записей за последние 15 дней.
- потерянные данные, когда данные фактически есть в платформе, но ни одна система не владеет ими. Например, файлы данных есть в хранилище объектов, но в каталоге Hive нет таблицы, ссылающейся на них. Такое часто происходит это из-за неправильной обработки данных в объектном хранилище. В идеале все файлы данных должны быть проиндексированы/каталогизированы, а их жизненный цикл должен быть связан с системой каталога/индексации. Если таблица удалена, архивирована или выпущена ее новая версия, то же самое должно произойти и с данными. Аналогичная проблема случается, когда данные есть в одной части системы, а в другой части нет соответствующей информации об этом. К примеру, клиент существует в таблице клиентских систем, но его учетная запись не существует ни в одной таблице систем, связанных с учетными записями. Здесь же можно отметить проблему нерелевантных данных, которые фактически нигде не используются, но на их хранение тратятся ресурсы.
- опоздание данных, когда сообщения поступают с опозданием. Чтобы они обрабатывались корректно, нужны соответствующие конвейеры обработки этих опоздавших данных. Причем важно, чтобы эти конвейеры работали с минимальным временем простоя.
- дублирование записей в платформе данных может возникнуть по многим причинам, например, неидемпотентные конвейеры или продюсеры. Исправить это поможет проверка уникальности на пре- и постэтапах задач преобразования и загрузки данных. Этот элемент управления будет проверять наличие точных дубликатов записей и должен/может очистить одну запись.
- разная производительность источников и приемников данных, когда приложения-продюсеры и приложения потребители работают с разной скоростью. Это может создать бутылочные горлышки в конвейерах обработки данных и привести к ситуации, когда потребитель не справляется с потоком входящих данных. Для этого в потоковых системах есть механизм обратного давления (back pressure), о чем мы недавно писали здесь на примере Apache NiFi.
Больше приемов по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
