Чем целостность данных отличается от их качества и как реализуются ACID-свойства распределенных транзакций в Big Data системах. Разбираем понятия и технологии, важные для обучения ИТ-архитекторов и дата-инженеров.
Целостность и качество данных: versus или вместе?
Целостность данных и качество данных — связанные, но разные понятия, важные для дата-инженера. Целостность описывает точность и согласованность данных, включая обеспечение того, чтобы данные не были повреждены или изменены во время конвейера их обработки. Это может включать проверки, чтобы убедиться, что данные не были подделаны или изменены, а также тесты на согласованность.
С другой стороны, качество данных говорит про оценку их надежности, а также включает выявление и исправление ошибок или несоответствий. Сюда могут входить такие методы, как профилирование, очистка и проверки на выявление и исправления ошибок или несоответствий. Можно сказать, что целостность данных является частью их качества, но эти два термина определяются отдельно и трактуются по-разному.
Целостность данных фокусируется на обеспечение того, чтобы данные не были повреждены или изменены во время ETL-конвейера. Например, если данные в электронных медицинских картах пациентов не защищены, случайно или преднамеренно изменены, это может иметь серьезные последствия для лечения пациентов. В частности, изменение истории болезни пациента может привести к неправильной диагностике и лечению, что будет иметь серьезные последствия для здоровья.
Другим примером нарушения целостности данных может быть ситуация, когда данные потеряны или удалены из-за технической проблемы или стихийного бедствия. Например, если база данных клиентов потеряна из-за аппаратного сбоя или стихийного бедствия, компания может не выполнить сои обязательства по доставке товаров и оказанию услуг, что чревато для бизнеса. Поэтому целостность данных очень важна, и для ее обеспечения можно использовать следующие методы:
- хеширование данных, что включает уникального отпечатка для каждой записи в наборе данных, чтобы использовать его для обнаружения любых изменений или модификаций исходника, поскольку любые изменения приведут к другому отпечатку;
- алгоритмы контрольной суммы — математические функции, которые можно использовать для создания уникального значения для набора данных. Это значение можно использовать для обнаружения любых изменений или модификаций, поскольку любые изменения данных приведут к другому значению контрольной суммы.
- репликация данных, включая создание нескольких копий набора данных и их хранение в разных местах. Это поможет обеспечить целостность данных, поскольку любые изменения или модификации в одной копии будут обнаружены при сравнении с другими копиями.
- регулярное резервное копирование данных позволит использовать резервные копии для восстановления исходных данных в случае их потери или повреждения;
- шифрование данных, включая кодирование данных с использованием секретного ключа, который затрудняет доступ или изменение данных неавторизованным лицам.
Качество данных включает в себя их оценку и проверку надежности, а также выявление и исправление ошибок или несоответствий. Как и целостность, качество данных оказывает важнейшее влияние на управленческие решение, особенно для data-driven бизнеса. Для обеспечения качества данных важно рассматривать их со следующих точек зрения:
- точность, что имеет решающее значение для обеспечения их надежности и доверия. Данные должны быть верны и соответствовать ожидаемым значениям или диапазонам.
- полнота, включая проверку на наличие отсутствующих или неполных значений для обеспечения их надежности;
- непротиворечивость, что предполагает согласованность данных с самими собой и другими источниками для обеспечения их точности и надежности.
- Своевременность – устаревшие или неактуальные данные могут быть ненадежными.
Вспомнив разницу между целостностью и качеством данных, рассмотрим технологии реализации этих понятий в мире Big Data.
Транзакции в распределенных системах
Поддержка ACID-требований к транзакциям считается одним из главных преимуществ в реляционных СУБД. Но с появлением потоковой передачи и NoSQL транзакции стали считаться сложными для реализации на платформах больших данных. Для таких платформ стала нормой конечная согласованность, где некоторые распределенные узлы могут быть несовместимы между собой — возвращая разные значения в отдельные моменты времени, в итоге приходя к согласованным результатам спустя какой-то период. С одной стороны, это противоречит идее целостности данных и нарушает их качество. С другой стороны, нельзя сказать, что системы Big Data и NoSQL-хранилища вообще не поддерживают транзакции. Они реализуют это по-своему. Чтобы показать отличия от традиционных РСУБД, вспомним изначальный смысл ACID-требований к транзакциям. Транзакцию можно рассматривать как группу операций, инкапсулированных операциями Begin и Commit/Abort, имеющими следующие ACID-свойства:
- Атомарность — выполняются либо все операции, либо ни одна из них. В случае сбоя или отмены последствия любой операции, принадлежащей транзакции, отменяются, т.е. выполняется откат назад.
- Непротиворечивость — каждая транзакция переводит систему из одного согласованного состояния в другое;
- Изоляция – для повышения производительности системы несколько транзакций могут выполняться одновременно, не влияя друг на друга. Эффекты такого одновременного выполнения эквивалентны последствиям их последовательного выполнения. Это достигается за счет того, что промежуточные результаты транзакции не фиксируются до ее успешного завершения.
- Долговечность — после того, как транзакция зафиксирована, ее последствия являются устойчивыми, т.е. не подвержены системному или программному сбою.
Программное обеспечение, отвечающее за реализацию транзакций, часто называют диспетчером транзакций (TM, Transaction Manager), который состоит из следующих компонентов:
- диспетчер управления параллелизмом (CCM, Concurrency Control Manager) для обеспечения изоляции. Механизмы управления параллелизмом позволяют контролируемым образом распределять ресурсы между параллельными транзакциями.
- диспетчер восстановления (RM, Recovery Manager) для обеспечения атомарности и устойчивости в случае программного или аппаратного сбоя.
- диспетчер журналов (LM, Log Manager), отвечающий за запись сведений о выполнении в постоянное хранилище. Хотя журнал нужен и для восстановления данных, он также используется для анализа и повышения производительности и эффективности системы.
Реализовать все эти понятия в распределенной среде не так-то просто. Распределенные транзакции состоят из операций, которые выполняются в разных системах, соединенных коммуникационной сетью. Основные отличия обработки транзакций в централизованной и распределенной системе заключаются в следующем:
- характер принятия решения о совершении или отмене транзакции не ограничивается одним ТМ , вовлекаются ТМ всех участников процесса;
- множественные точки отказа — в централизованных системах система либо работает, либо не работает. А в распределенной системе могут быть частичные сбои, когда некоторые из задействованных участников вышли из строя, в то время как другие все еще работают.
Поэтому нужен протокол, который гарантирует, что одно и то же решение (фиксация или отмена транзакции) последовательно выполняется на всех задействованных участниках, независимо от частичных сбоев. Для этого часто применяется протокол двухфазной фиксации (2PC, Two phase commit). ТМ на инициаторе транзакции выступает в роли координатора, а ТМ на всех других задействованных сайтах берут на себя роль участников. Как следует из названия, протокол 2PC состоит из двух фаз. На первом этапе ТМ-координатор отправляет сообщение PREPARE всем ТМ-участникам, которое свидетельствует о подготовке транзакции. Каждый участник ТМ отвечает, может ли он зафиксировать транзакцию или прервать ее. Если TM-координатор получает согласие на транзакцию от всех своих участников TM, то он начинает вторую фазу протокола, отправляя сообщения COMMIT. Но, получив отказ от фиксации хотя бы от одного из TM-участников, TM-координатор инициирует вторую фазу, отправляя сообщение об отказе (ABORT). Наконец, координатор TM ожидает подтверждения от участников TM для завершения второй фазы.
2PC хорошо работает для сильно связанных распределенных приложений, но его применимость к долго работающим и слабо связанным приложениям ограничена, поскольку для обеспечения свойств ACID в централизованном сценарии необходимо удерживать блокировки до фиксации транзакций. Это нежелательная ситуация с точки зрения производительности, особенно для длительных транзакций, т.к. надо удерживать блокировки до тех пор, пока все вовлеченные стороны (координатор и участник) не будут готовы к фиксации.
Обойти это ограничение позволяет концепция вложенных транзакций, которые позволяют транзакциям на участниках снимать свои блокировки после локального завершения транзакции, контролируемым образом фиксируя промежуточные результаты. По сути, глобальная транзакция, отправляемая в корневой TM, делится на несколько подтранзакций, которые могут выполняться одновременно. В то время как свойства ACID гарантированы для глобальной транзакции, подтранзакции не полностью изолированы, поскольку их результаты доступны своим родителям. Даже долговечность подтранзакций не гарантируется, так как их эффекты, возможно, придется отменить после того, как они были зафиксированы, если их родитель прервется.
Хотя концепция вложенных транзакций в некоторой степени решает проблему производительности, она по-прежнему требует определенных гарантий от задействованных ТМ. Однако, такие гарантии не всегда могут быть выполнимы, учитывая требования к автономии и гетерогенности слабосвязанных распределенных систем. Решить эту проблему позволяют паттерны Saga и Open Nested Transactions, позволяя промежуточным результатам, созданным подтранзакциями, открываться без ограничений.
Saga опирается на концепцию компенсирующих транзакций для обеспечения атомарности в случае сбоя. По сути, для каждой транзакции указывается компенсирующая, способная семантически отменить последствия исходной. В случае сбоя атомарность гарантируется выполнением компенсирующих транзакций в порядке, обратном исходной последовательности выполнения соответствующих транзакций. Однако, в реальности компенсация часто реализуется на разных уровнях с разными затратами. Например, потеря визового сбора при отказе от оформления визы в рамках бронирования путешествия.
Архитектура Данных
Код курса
ARMG
Ближайшая дата курса
16 декабря, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
В системах больших данных ACID-транзакции реализуются с помощью таких технологий, как Delta Lake на Apache Spark от Databrics, Apache Hudi и Iceberg, о чем мы писали здесь и здесь. В Delta Lake ACID-транзакции обеспечивают ключевую функцию «путешествия во времени», которая позволяет исследовать данные в определенный момент времени, обеспечивая доступ и откат к более ранним версиям данных, что имеет решающее значение для аудита и воспроизводимости их качества. Hudi следует традиционному подходу на основе журнала транзакций, файлами данных с временными метками и файлами журналов, которые отслеживают изменения в записях в файлах данных. Iceberg обеспечивает поддержку ACID, используя следующую иерархию метаданных:
- таблица файлов метаданных;
- списки манифеста, соответствующие моментальному снимку таблицы;
- манифесты, которые определяют группы файлов данных как часть нескольких снимков.
Запись таблицы создает новый снимок, который может выполняться параллельно с несколькими запросами, возвращая значение последнего снимка. Параллельные записи следуют оптимистичному протоколу управления параллелизмом, при этом первая транзакция, которая фиксируется, завершается успешно, перезапуская все другие конфликтующие одновременно выполняемые транзакции. Как ACID-требования к транзакциям реализуются в графовой MPP-СУБД TigerGraph, читайте в нашей новой статье. А здесь мы рассказываем про управление распределенными транзакциями в MPP-СУБД Greenplum.
Узнайте больше подробностей по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Архитектура Данных
- Практическое применение Big Data Аналитики для решения бизнес-задач
- Аналитика больших данных для руководителей
Источники
