Комментарии 9
Это просто кладезь ценной информации!
А как заставить кого-то юзать эти имеющиеся дата контракты??
привет!, спасибо за вопрос!
зависит от конкретного кейса и от зоны ответственности дата продукта. по-хорошему заставлять нужно владельца данных. Скорее всего, если построены тракты поставки данных до DWH, то отслеживанием дата изменений занимается дата инженер, который выстраивает etl-процессы и навешивает проверки качества поставки данных, используя инструменты data quality. Это конечно выглядит как идеальный мир.
на вопрос, как заставить? - ответом может служить, например kpi по инцидентам связанным с дата изменениями, или если есть человеко-ресурсы на реализацию имплементации дата контракта - то можно попробовать встроить в тестовый дата продукт и далее масштабировать.
правильнее сказать не "заставлять кого-то юзать", а закрывать проблемы и потребности, которые может покрыть дата контракт (в любой его интерпретации)
Ну пример- есть дата продукт в виде витрины данных, хорошей, нужной, с контрактом, всё дела. Юзают её репорты а-ля powerBi и иногда аналитики напрямую кверят и себе в эксельки утаскивают. Где тут им нужен дата контракт?? И даже если нужен как его тут использовать?
Есть витрина и её кто-то поддерживает, то есть за качество поставки данных отвечает владелец. Аналитик пользуется по факту конечным результатом, как data source для bi-систем (c агрегацией или трансформацией), в конечном счёте для дэшиков или ковыряют результаты запросами.
Если так получается, что аналитик начинает создавать витринки, которыми пользуется другие пользователи - получается что этот аналитик становится владельцем данным который должен поддерживать качество, но у него скорее всего не хватит прав, доступов и так далее для поддержания data quality. Тогда выглядит так что дата контрактом должен заниматься дата инженер и это его работа встраивание на каком-то этапе пайплайна.
Но если этот аналитик один пользуется своими витринками и строит свой тракт до bi-систем, то за качество данных отвечает он сам, так как это уже бизнес логика, которая отражается в sql-запросах и далее на дэшиках, с точки зрения контракта и проверки данных рулит он сам в этом кейса, Возможно у аналитика (например дата аналитика) достаточно тех.скиллов и прав на реализацию, то в зависимости от используемого стека, можно реализовать контракт в виде проверки данных на этапе перед обновлением конечной витрины.
дата контракт это скорее поддержания согласованности данных на этапе их поставки из источников, как дата продукта или построения DWH, а не отлавливание логики запросов аналитиков, но не исключено встраивание контракта и в таком кейсе, но пока я не встречал.
Пользователям данных контракт почти не нужен. Небольшая польза может быть в том, что об изменениях в контракте можно узнать до того как начнёшь работать с новыми данными.
Одним из неочевидных плюсов контрактов, это построение процессов/культуры в компании. Многие даже не задумываются, что маленькое изменение на их стороне, ломает последующие шаги в цепочке.
Data сontract: давайте попробуем договориться