привет, очень важное замечание, спасибо! не стал акцентировать внимание на том, кто такой duckdb - очень уж много статей по этому поводу есть в целом duckdb и используем как инструмент для подготовки данных, а не для транзакционной нагрузки
статейки, кстати прикрепил, чтобы быстро вкатиться в использование этой базёнки
p.s. "Уткин М. пишет про утиную БД (совпадение?) " - самоирония превыше всего)
Сложность заключается в поддержания баланса между t2m разработки и качеством дата продукта, так как внедрение контрактов по своей сути затрагивает оба аспекта.
@dblmokk, Привет! Спасибо за балдёжную статью. Классные архитектурные решения! Подскажи каким образом выделяете нейминги сущностей (таблицы/колонки) из витрин, чтобы сформировать yaml, по которому далее lineage отрисовывается в OpenMetaData?
Есть витрина и её кто-то поддерживает, то есть за качество поставки данных отвечает владелец. Аналитик пользуется по факту конечным результатом, как data source для bi-систем (c агрегацией или трансформацией), в конечном счёте для дэшиков или ковыряют результаты запросами.
Если так получается, что аналитик начинает создавать витринки, которыми пользуется другие пользователи - получается что этот аналитик становится владельцем данным который должен поддерживать качество, но у него скорее всего не хватит прав, доступов и так далее для поддержания data quality. Тогда выглядит так что дата контрактом должен заниматься дата инженер и это его работа встраивание на каком-то этапе пайплайна.
Но если этот аналитик один пользуется своими витринками и строит свой тракт до bi-систем, то за качество данных отвечает он сам, так как это уже бизнес логика, которая отражается в sql-запросах и далее на дэшиках, с точки зрения контракта и проверки данных рулит он сам в этом кейса, Возможно у аналитика (например дата аналитика) достаточно тех.скиллов и прав на реализацию, то в зависимости от используемого стека, можно реализовать контракт в виде проверки данных на этапе перед обновлением конечной витрины.
дата контракт это скорее поддержания согласованности данных на этапе их поставки из источников, как дата продукта или построения DWH, а не отлавливание логики запросов аналитиков, но не исключено встраивание контракта и в таком кейсе, но пока я не встречал.
зависит от конкретного кейса и от зоны ответственности дата продукта. по-хорошему заставлять нужно владельца данных. Скорее всего, если построены тракты поставки данных до DWH, то отслеживанием дата изменений занимается дата инженер, который выстраивает etl-процессы и навешивает проверки качества поставки данных, используя инструменты data quality. Это конечно выглядит как идеальный мир.
на вопрос, как заставить? - ответом может служить, например kpi по инцидентам связанным с дата изменениями, или если есть человеко-ресурсы на реализацию имплементации дата контракта - то можно попробовать встроить в тестовый дата продукт и далее масштабировать.
правильнее сказать не "заставлять кого-то юзать", а закрывать проблемы и потребности, которые может покрыть дата контракт (в любой его интерпретации)
привет!
есть таблица объёмом ~ 14Gb, в ней ~500млн записей
p.s. никаких совпадений по никнейму, не наблюдается)
привет, очень важное замечание, спасибо!
не стал акцентировать внимание на том, кто такой duckdb - очень уж много статей по этому поводу есть
в целом duckdb и используем как инструмент для подготовки данных, а не для транзакционной нагрузки
статейки, кстати прикрепил, чтобы быстро вкатиться в использование этой базёнки
p.s. "Уткин М. пишет про утиную БД (совпадение?) " - самоирония превыше всего)
Интересный проект!
Сложность заключается в поддержания баланса между t2m разработки и качеством дата продукта, так как внедрение контрактов по своей сути затрагивает оба аспекта.
@dblmokk, Привет! Спасибо за балдёжную статью. Классные архитектурные решения!
Подскажи каким образом выделяете нейминги сущностей (таблицы/колонки) из витрин, чтобы сформировать yaml, по которому далее lineage отрисовывается в OpenMetaData?
Есть витрина и её кто-то поддерживает, то есть за качество поставки данных отвечает владелец. Аналитик пользуется по факту конечным результатом, как data source для bi-систем (c агрегацией или трансформацией), в конечном счёте для дэшиков или ковыряют результаты запросами.
Если так получается, что аналитик начинает создавать витринки, которыми пользуется другие пользователи - получается что этот аналитик становится владельцем данным который должен поддерживать качество, но у него скорее всего не хватит прав, доступов и так далее для поддержания data quality. Тогда выглядит так что дата контрактом должен заниматься дата инженер и это его работа встраивание на каком-то этапе пайплайна.
Но если этот аналитик один пользуется своими витринками и строит свой тракт до bi-систем, то за качество данных отвечает он сам, так как это уже бизнес логика, которая отражается в sql-запросах и далее на дэшиках, с точки зрения контракта и проверки данных рулит он сам в этом кейса, Возможно у аналитика (например дата аналитика) достаточно тех.скиллов и прав на реализацию, то в зависимости от используемого стека, можно реализовать контракт в виде проверки данных на этапе перед обновлением конечной витрины.
дата контракт это скорее поддержания согласованности данных на этапе их поставки из источников, как дата продукта или построения DWH, а не отлавливание логики запросов аналитиков, но не исключено встраивание контракта и в таком кейсе, но пока я не встречал.
привет!, спасибо за вопрос!
зависит от конкретного кейса и от зоны ответственности дата продукта. по-хорошему заставлять нужно владельца данных. Скорее всего, если построены тракты поставки данных до DWH, то отслеживанием дата изменений занимается дата инженер, который выстраивает etl-процессы и навешивает проверки качества поставки данных, используя инструменты data quality. Это конечно выглядит как идеальный мир.
на вопрос, как заставить? - ответом может служить, например kpi по инцидентам связанным с дата изменениями, или если есть человеко-ресурсы на реализацию имплементации дата контракта - то можно попробовать встроить в тестовый дата продукт и далее масштабировать.
правильнее сказать не "заставлять кого-то юзать", а закрывать проблемы и потребности, которые может покрыть дата контракт (в любой его интерпретации)
информационное поле темы очень широкое
может для кого-то послужит стартом в мир дата контрактов или расширит знания