Спасибо за содержательный фидбек! 🙏 Решение оставить DataPortal как интерфейс для бизнес-пользователей оказалось удачным и последние NPS это подтверждают. Пользователи отмечают, что если нужно быстро посмотреть информацию о таблице, они идут в DataPortal, а если нужны технические детали и связи то в DataHub.
Мы вообще пришли к этой архитектуре не сразу - это результат многолетнего использования DataPortal. За это время мы хорошо поняли, какие сценарии удобны бизнес-пользователям, а какие требуют более мощного инструмента вроде DataHub.
В остальном вы только в начале пути. Посмотрите в сторону метамодели, семантических слоёв и графов знаний.
Спасибо за совет - полностью согласен с направлением
Ну и не увидел, как каталог встроен в производственный процесс и процессы data governance. Не боитесь деградации каталога?
Деградация - это действительно ключевой момент. Каталог встроен в процессы Data Governance и Data Quality - метаданные обновляются автоматически и валидируются командами. Плюс поддержка data пользователей постоянно черпает знания из каталогов, поэтому информация там поддерживается актуальной. Все новые витрины проходят автоматическую проверку перед публикацией, а также есть регулярные проверки на заполненность описаний, актуальность владельцев и других атрибутов.
Мы стараемся, чтобы каталог оставался живым инструментом, а не просто витриной - и пока это работает 👍
Да, интеграций действительно много. В целом такие случаи решаются контрактами и их автоматической проверкой. Сейчас мы как раз реализуем Data Contracts — тоже на базе open-source-решения. Когда всё заработает, надеюсь, расскажем подробнее, что получилось.
Dagster мы не рассматривали, потому что в Островке уже используется Airflow, за поддержку и развитие которого отвечает отдельная команда. Поэтому логично было остаться в рамках стандартного для компании инструмента — это упрощает поддержку и снижает операционные издержки.
Great Expectations действительно был одним из кандидатов. Перед выбором стека я провёл сравнительный анализ по нескольким критериям: — поддержка подключения к нашим базам данных; — возможность описывать проверки в SQL; — автогенерация тестов на основе профилирования данных; — простота внедрения и поддержки; — наличие инструментов для отчётности.
GX набрал хорошие баллы, и я знаком с этим инструментом и его сообществом, но на практике столкнулся с ограничениями при подключении к нашей аналитической БД. Кроме того, Soda реализует более простую и гибкую поддержку SQL-нативных тестов — можно не только описывать классические проверки в формате failed rows, но и реализовывать другие типы проверок.
Очень рад, что вам понравился опыт :)
Спасибо за содержательный фидбек! 🙏
Решение оставить DataPortal как интерфейс для бизнес-пользователей оказалось удачным и последние NPS это подтверждают. Пользователи отмечают, что если нужно быстро посмотреть информацию о таблице, они идут в DataPortal, а если нужны технические детали и связи то в DataHub.
Мы вообще пришли к этой архитектуре не сразу - это результат многолетнего использования DataPortal. За это время мы хорошо поняли, какие сценарии удобны бизнес-пользователям, а какие требуют более мощного инструмента вроде DataHub.
Спасибо за совет - полностью согласен с направлением
Деградация - это действительно ключевой момент. Каталог встроен в процессы Data Governance и Data Quality - метаданные обновляются автоматически и валидируются командами. Плюс поддержка data пользователей постоянно черпает знания из каталогов, поэтому информация там поддерживается актуальной.
Все новые витрины проходят автоматическую проверку перед публикацией, а также есть регулярные проверки на заполненность описаний, актуальность владельцев и других атрибутов.
Мы стараемся, чтобы каталог оставался живым инструментом, а не просто витриной - и пока это работает 👍
Это точно. у меня даже картинка на эту тему есть
Да, интеграций действительно много. В целом такие случаи решаются контрактами и их автоматической проверкой. Сейчас мы как раз реализуем Data Contracts — тоже на базе open-source-решения. Когда всё заработает, надеюсь, расскажем подробнее, что получилось.
Привет! Спасибо за вопрос.
Отвечу по частям.
Dagster мы не рассматривали, потому что в Островке уже используется Airflow, за поддержку и развитие которого отвечает отдельная команда. Поэтому логично было остаться в рамках стандартного для компании инструмента — это упрощает поддержку и снижает операционные издержки.
Great Expectations действительно был одним из кандидатов. Перед выбором стека я провёл сравнительный анализ по нескольким критериям:
— поддержка подключения к нашим базам данных;
— возможность описывать проверки в SQL;
— автогенерация тестов на основе профилирования данных;
— простота внедрения и поддержки;
— наличие инструментов для отчётности.
GX набрал хорошие баллы, и я знаком с этим инструментом и его сообществом, но на практике столкнулся с ограничениями при подключении к нашей аналитической БД. Кроме того, Soda реализует более простую и гибкую поддержку SQL-нативных тестов — можно не только описывать классические проверки в формате failed rows, но и реализовывать другие типы проверок.
В итоге, я выбрал Soda