- PVSM.RU - https://www.pvsm.ru -
В русскоязычной части интернета присутствует много статей по теме паттернов разработки, однако я не нашел никакой информации о паттернах работы с данными.
В данной статье я хочу рассказать о паттерне Write-Audit-Publish, о предпосылках его появления, а также наглядно рассмотреть как он работает.
С момента появления концепции data lake, компании старались собирать как можно данных, иногда не слишком задумываясь об их качестве. Появилось четкое понимание, что данные "когда-нибудь" могут быть использованы. Так, согласно исследованиям market.us [1] объемы данных хранящихся в мире выросли приблизительно в 90 раз за 15 лет.
Концепция Map-Reduce отлично подходит для работы с большими данными, учитывает непостоянство схем и прочее, однако, действительно годный отчет можно построить только на качественных данных. А эволюция слоевой модели данных (те самые raw, ods/dds/dm и ещё миллиарды аббревиатур, которые придумают разработчики в каждой отдельной компании) привела к тому, что получив незначительную ошибку в начале pipeline данных, поймать её проблематично из-за обилия этих самых слоев и join'ов, необходимых для формирования итогового отчета.
Ответом на такую проблему стало развитие data-quality направления. Суть заключается в том, чтобы написать какие-то условия для данных, пройдя которые, мы можем считать, что с данными все хорошо. И в идеале, написав quality-check'и для всех элементов pipeline на каждом слое ведь мы не копируем проверки из слоя в слой за счет их уникальности мы можем быстро отследить, с какого момента начал рушиться финальный отчет.
В 2017 году инженеры Netflix опубликовали доклад Whoops the Numbers are wrong! Scaling Data Quality @ Netflix. [2], в котором описали проблемы некачественных данных и описали новый подход к управлению качеством данных, который назвали Write-Audit-Publish.
Для начала условимся, WAP - именно патерн. Это общий подход, не дающий указаний как конкретно его релизовывать. Как есть несколько реализаций Singleton в зависимости от языка программирования, так есть несколько реализаций WAP, в зависимости от используемых в вашем кластере решений.
В основе WAP подхода лежит стремление обеспечить доверие к данным. Представим, что у нас есть поставщик данных и потребитель. Они заключают между собой некоторый контракт [3]. Однако, чтобы потребитель был уверен в их качестве, он должен самостоятельно проверить данные. Но при этом, сделать это так, чтобы до момента проверки данные были недоступны внутри остальным пользователям.
Приведу абстрактный пример, чтобы понимать о чем идет речь. Представим, что у нас есть маркетплейс. И мы строим ежедневные отчеты о сумме проданных товаров в каждом городе. Для этого мы читаем каждый день таблицу Orders, в которой есть информация о дате заказа, сумме, и городе назначения. Что-то вроде такого:
Несмотря на очевидную корректность типов данных, мы видим заказ с отрицательной суммой. Очевидно, что сумма заказа не может быть отрицательной. Использование таких данных в процессах приведет к наслоению ошибок в показателях среднего чека, в проценте выкупа. Возможно даже, что маркетологи попросят дополнительный бюджет на рекламные акции, увидев понижение спроса. Все это ведет к прямым денежным потерям, а также негативному пользовательскому опыту, что особенно важно ввиду высокой конкуренции маркетплейсов. Поэтому, получив такие данные, мы должны их отвергнуть, чтобы менеджмент компании мог отчитаться о росте не вносить погрешности в показатели.
Давайте разберем на примере, как же нужно работать с таблицей Orders так, чтобы данные можно было проверить, но до проверки они не были доступны читателям raw слоя.
Представим, что сегодня 1 августа 2025 года и мы хотим добавить и обработать данные за прошедший день. При этом, у нас в кластере в таблице Orders имеются данные до 31 июля и потенциально к ним могут обратиться в любой момент времени.
Чтобы загрузить данные безопасно, применим паттерн WAP
Запишите обрабатываемые данные в место, недоступное для чтения последующими пользователями. Это может быть некоторая временная таблица/директория, бранч. Есть реализации с флагом "enabled".
Таким образом данные уже в нашем datalake, и мы можем их анализировать, но это никак не влияет на работу пайплайнов данных.
Проверьте данные с помощью Quality checks. Тут все просто, есть большое множество фреймворков вроде spark-expectations [4], soda [5]. В нашем случае для проверки положительности суммы заказа достаточно простого sql запроса. Единственное, я рекомендую хранить где-то результаты проверок, чтобы иметь статистику корректности данных.
Опубликуйте данные для чтения из таблицы Orders. Есть варианты с изменением флага в таблице таким образом, чтобы пользователи, выполняющие запросы, теперь включали эти данные в свои результаты. Коллеги по цеху из Netflix придумали систему с 2 таблицами, которые смотрят на один и тот же каталог в s3, что позволяет уменьшить количество движения данных (а в S3 это важно), но на мой взгляд это довольно сложная система и на текущий день есть более оптимальные решения.
Таким образом, мы за 3 довольно простых шага смогли загрузить данные так, чтобы гарантировать качество поставляемых данных. Отмечу, что почему-то многие стремятся реализовать WAP как одну жирную джобу. Это излишнее требование, так как WAP не накладывает никаких требований атомарности. Например, вполне допускается, что разработчик quality-check проверок ошибся и проверял все ордера на отрицательность сумм. И как раз отсутствие атомарности позволяет нам быстро поправить datacontract и перезапустить проверку без дополнительных загрузок.
Вообще, тема WAP обработки данных несмотря на кажущуюся простоту довольно обширна и требует изменений, как на уровне ETL задач, так и изменений на уровне скедулинга pipeline. На мой взгляд именно этот паттерн дал огромный импульс индустрии в целом и хранилищ данных в частности, поэтому важно понимать проблему, которую он решает, а также как именно можно его реализовать.
Буду рад узнать ваше мнение относительно данного паттерна и насколько вы применяете его в работе!
Автор: ozero17
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/big-data/428236
Ссылки в тексте:
[1] market.us: http://market.us
[2] Whoops the Numbers are wrong! Scaling Data Quality @ Netflix.: https://www.youtube.com/watch?v=fXHdeBnpXrg
[3] контракт: https://datacontract.com/
[4] spark-expectations: https://github.com/Nike-Inc/spark-expectations
[5] soda: https://www.soda.io/
[6] Источник: https://habr.com/ru/articles/937738/?utm_source=habrahabr&utm_medium=rss&utm_campaign=937738
Нажмите здесь для печати.