Почему в одной организации возникает рассогласование данных, чем опасна такая рассинхронизация, как ее обнаружить и устранить: подходы и решения для повышения качества данных.
Что такое data silos и как найти локальные «болота данных»
Рассогласование в данных возникает при разной логике обработки одной и той же информации. Это мешает принимать объективные решения, основанные на данных. Например, один отдел агрегирует продажи на уровне региона, а другой — на уровне всей страны. При попытке объединить эти данные для общей картины продаж компания сталкивается с противоречивыми показателями, что мешает точной оценке эффективности бизнеса. Или в одном подразделении используется даты представляются в формате ДД.ММ.ГГГГ, а в другом — ММ/ДД/ГГГГ. При объединении этих данных из разных источников возникает несоответствие в форматах дат, что затрудняет анализ временных трендов и может привести к неверным выводам. А исправление этой ситуации потребует времени и дополнительных ресурсов.
В общем случае рассогласования в данных приводят к следующим последствиям для бизнеса:
- нарушение доверия к данным — разные результаты в аналитических отчетах снижают доверие пользователей к информации;
- задержки в принятии решений из-за необходимости выделить время на выявление и устранение рассогласований;
- увеличение затрат — необходимость выполнения дополнительных работ по стандартизации и синхронизации данных повышает операционные расходы.
Рассинхронизация данных – это не только отличия в форматировании или в самих значениях. Сюда же относятся такие нарушения качества данных, как неполные и пропущенные данные. Это обычно случается, когда наборы данных одного бизнес-подразделения становятся недоступными для других. Иногда потребители данных даже не знают, что нужные им существуют в другом месте организации. Если в бизнесе отсутствует общая структура или стратегия управления данными, одни и те же данные являются противоречивыми. Часто разные бизнес-подразделения полагаются на одни и те же наборы данных, но используют и форматируют их по-разному. Более того, разные бизнес-подразделения крупной корпорации могут выстраивать собственные (локальные) хранилища данных и ETL-конвейеры. Такое дублирование увеличивает расходы на ИТ. Поэтому перед дата-инженерами и архитекторами платформы данных встает задача устранить подобные очаги рассогласования, так называемые локальные «болота данных» (Data silos). Это изолированные хранилища данных внутри организации, которые не взаимодействуют друг с другом. Такие изолированные хранилища формируются из-за функционального или доменного разделения, деления по программным решениям или недостаточной интеграции информационных систем. Присутствие data silos снижает эффективность управления данными в компании, поэтому такие «болота данных» необходимо своевременно устранять. Но для этого их надо сначала обнаружить.
Прежде всего следует выполнить инвентаризацию всех текущих систем и сделать ее регулярной практикой, обновлять по мере появления новых источников данных и исключая те, которые больше не используются.
К явным признакам, указывающим на «болота данных» относятся следующие:
- бизнес-пользователи сообщают о несоответствиях в данных;
- аналитики и специалисты по Data Science не могут найти данные;
- руководители жалуются на нехватку данных;
- все время растут непредвиденные расходы на ИТ.
Устранение рассинхронизации данных
Обнаружив «болота данных», надо разработать стратегию их устранения. Для этого можно предпринять следующие шаги:
- определить, где находятся все данные, как они собираются и насколько они актуальны;
- определить проблемы, связанные с пользовательскими системами управления данными;
- выполнить интеграцию данных с использованием ETL-инструментов или CDC в реальном времени;
- организовать централизованное хранение данных компании в едином DWH или Data Lake;
- обновить культуру и стратегию управления данными, чтобы предотвратить создание новых изолированных хранилищ.
Одним из способов устранения рассинхронизации данных является Data Mesh (сетка данных) — децентрализованный социально-технический подход к управлению данными. Эта архитектура предполагает демократизацию данных, позволяя потребителям выполнять часть работы по организации конвейера данных, которую обычно выполняет дата-инженер. Например, с помощью декларативного описания ETL-процессов в виде YAML-манифестов, что я показывала здесь, здесь и здесь, или федеративных SQL-запросов в Trino. Также Data Mesh рассматривает данные как продукт организации, созданный для потребления конечным пользователем. Это предполагает не только контроль качества самих данных, но и определение их метаданных, шаблонов доступа, а также инфраструктуры их хранения и обработки.
Дополнительно к сетке данных можно применить их виртуализацию, которая создает уровень абстракции, собирающий метаданные из каждого источника для представления пользователям. Все преобразования применяются в реальном времени по мере выполнения запросов. Это позволяет бизнес-пользователям получать доступ к данным из нескольких источников с помощью единого уровня доступа. Однако, у этого подхода есть физические и эксплуатационные ограничения, связанные с объемом данных, которые можно передать по сети. Например, подобную федерализацию SQL-запросов выполняет Trino, используя протокол HTTP как для взаимодействия с внешними клиентами и источниками данных, так и внутри кластера.
Еще одним способом устранить рассогласование данных является кэширование в DWH и Data Lake. Так работают материализованные представления — физический объект базы данных, содержащий результат выполнения запроса. Кэширование этого запроса обеспечит разделение вычислений и хранения, сохраняя довольно высокую производительность. Однако, материализованные представления требуют регулярного обновления для отражения изменений в исходных данных. Это может привести к задержкам между обновлениями данных и их отображением в кэше, что особенно критично для систем, требующих актуальной информации в реальном времени. В хранилищах с большими объемами данных обновление материализованных представлений может оказаться ресурсоемким процессом, снижающим общую производительность системы. Частые обновления повышают нагрузку и могут замедлять другие операции.
Кроме того, хранение результатов запросов в виде материализованных представлений потребляет дополнительное дисковое пространство. В больших системах это может существенно увеличить требования к инфраструктуре хранения данных. Поддержание актуальности и согласованности материализованных представлений требует дополнительных усилий по их администрированию. Необходимо настроить механизмы автоматического обновления и мониторинга состояния представлений.
Также следует учитывать, что материализованные представления оптимизированы под конкретные запросы и сценарии использования. Изменение или расширение требований к аналитике данных потребует создания новых представлений. Поэтому при появлении новых сценариев использования и изменениях структуры исходных данных необходимо синхронизировать эти изменения с материализованными представлениями. Это требует тщательного планирования и тестирования, чтобы избежать несоответствий и ошибок в данных.
Узнайте, как построить согласованную и эффективную архитектуру данных, используя современные средства хранения и преобразования на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
