WAP Pattern
Знаете ли вы, что такое WAP (Write - Audit - Publish. ) паттерн в дата инженерии? Скорее всего, многие из вас им уже пользуются! 🤔
Я объясню это на коленке, желающим детальных кишочек -> в ссылки снизу. 📌
Представим, я инженер в компании Colt 👍, и мы занимаемся доставкой еды. Моя зона ответственности - end-to-end решение для ежедневной отчетности в разрезе городов (прибыль, количество доставок, средний чек, среднее время доставки, ...).
У меня есть проблема с источником данных по возвратам денег (допустим кому-то что-то не доставили, и вам возвращают денег на счет). Он обновляется непостоянно, так еще и иногда там часто бывают ошибки в данных. 🆗
Когда менеджеры смотрят мой отчет, они недовольны тем, что цифры, которые они видели вчера резко меняются после обновлений. Они не верят нашим данным, поэтому продолжают использовать свои проверенные эксели. А я не получаю свой заслуженный promotion.😂
Что же делать? Мы можем добавить тесты! 👍 Но возникает дилемма - скорость доставки vs качество. Если взять dbt как инструмент, то базовая имплементация тестов выглядит следующим образом -> прогнали модель, запустили тест над моделью, если тест упал, анализируем. Но если это уже презентационный слой, то конечные пользователи уже увидят эти данные. Мы можем настроить алертинг, но кто будет в него смотреть.👨🦳
Поэтому в случае критичных отчетов / дата продуктов, можно применить подход WAP.
- Write. Записываем данные в stage таблицу / объект
- Audit. Проверяем качество и полноту данных на уровне stage таблицы. Есть проблема -> автоматический алерт команде и on-call инженер с радостью разбирается 😮 (можно еще больше автоматизировать в случае повторяемых случаев, например
- Publish. Если все тесты успешно прошли, кладем в Publish слой. Это можно делать как логически (синонимы, линки на файловой системы, переопределение view, alter/modify partition, ...) или физически (ETL).
Есть еще один use-case применения WAP паттерна. Далеко не все системы поддерживают ACID транзакции, а те, которые поддерживают, не всегда готовы часами ждать тяжелых расчетов. Для организации консистентности (ну или чаще уменьшения неконсистентного промежутка по времени) вы можете подготовить свои 20+ таблиц в стейдже, а потом переключить их одновременно в презентационном слое. 🍷
Недостатки? Данные будут устаревшие, поэтому нам надо быстро сообщить об этом пользователям, чтобы они не сообщили об этом нам!🙂
Кроме этого, далеко не всегда причина может быть устранена быстро, но что с этим делать, обсудим в следующих постах.😵
Cсылочки 💻
- Верхнеуровневое обсуждение - https://lakefs.io/blog/data-engineering-patterns-write-audit-publish/
- Пример имплементации - https://lakefs.io/blog/write-audit-publish-with-lakefs/ , продолжение - https://lakefs.io/blog/write-audit-publish-with-lakefs/ и https://dagster.io/blog/python-write-audit-publish
- Видео - https://www.youtube.com/watch?v=fXHdeBnpXrg (в целом хорошее видео, сам WAP pattern с 16 минуты)
- Презентация для Iceberg - https://www.dremio.com/wp-content/uploads/2022/05/Sam-Redai-The-Write-Audit-Publish-Pattern-via-Apache-Iceberg.pdf
