Как синхронизировать инженеров приложений (Postgres) с инженерами данных (Redshift) в схеме

Question

Я работаю инженером данных в веб-компании среднего размера. У нас есть ежедневный ETL, который доставляет данные из наших баз данных приложений (например, Cassandra и Postgres) и сохраняет их в нашем хранилище данных (Redshift).

Наша текущая система передачи данных настроена относительно простым образом (для нашей базы данных Postgres): у нас есть реплика чтения базы данных Postgres, которую мы используем для загрузки инкрементных данных в S3, а затем копируем их в Redshift столы.

Код, выполняющий эту передачу данных, находится в репозитории группы данных, совершенно отдельно от репозитория приложений.

Мы часто сталкиваемся со следующей проблемой: разработчики приложений вносят изменения в схему. Они меняют имя столбца, они меняют ограничение, они добавляют столбец и т. Д. Они не сообщают нам об этом. Эти изменения иногда нарушают наш процесс ETL (на QA, но все же), и мы должны немедленно решить проблему, играя в догонялки.

Мы тратим усилия на улучшение коммуникации, чтобы убедиться, что разработчики приложений знают, что сделанные ими изменения должны быть доведены до нас, прежде чем они выйдут. Однако мне кажется, что должен быть лучший способ решить эту проблему. Есть ли программный способ решить это? Можем ли мы иметь дополнительный общий репозиторий с разработчиками, который запускает эти сценарии передачи? Таким образом, обе стороны должны были бы одобрить изменения, чтобы они прошли.

Как другие организации решают эту проблему?

Answer 1

Это зависит от бизнес-целей хранилища данных. Должен ли он содержать все детали, изменять типы столбцов, добавлять новые столбцы и т. Д., Т. Е. Должен ли он сразу следовать за базой данных приложения?

В большинстве случаев этого не следует делать, но хранилище данных обеспечивает другое представление данных. Итак, давайте явно добавим это к нашим процессам: создадим представление поверх базы данных приложения с фиксированной схемой вывода. Заставьте инженеров приложений поддерживать это представление и проверять его совместимость при изменении схемы. Если представление работает, инженеры хранилища данных получают небольшие сюрпризы.

Конечно, склад данных тоже эволюционирует, и периодически следует добавлять новые столбцы из базы данных приложения и т. Д. Каждая из этих эволюций представляет собой небольшой проект, совместно используемый инженерами приложений и хранилища данных. Он начинается с определения нового представления, которое включает новые данные. После того, как это будет сделано, инженеры хранилища данных подберут его, протестируют представление и отрегулируют свои процессы для загрузки данных с использованием нового представления. Во время такого проекта производственный код все еще использует старое представление, после того как все сделано, производство переключается на новый код, который использует новое представление. Старый вид после этого удалился.