Comments 6
Интересненько, но много мемов в огромном разрешении и не по делу.
Миграции, ddl и git - это все как мне кажется достаточно тривиальные для автоматизации вещи.. а вот самое интересное, как вы приделали это к данным. Откатились и приехали, потеряли данные.
Круто, что у вас это реализовано. Нам пришлось повозиться с т.з. стандартов в первую очередь.
К данным, я так понимаю, вопрос к DML, т.е. к конкретным значениям. Естественно мы не храним инсертов на 6,5ПБ в гите - это было бы странно. Мы храним DDL и DML в качестве датафиксов, либо инициализирующий загрузки таблицы. В гите у нас так же обвязка - в виде ETL. Это все к тому: 1) Откат для нас = накат нового альтера. Этот сценарий разработчик может приложить к поставке. 2) При откатах мы откатываем всю обвязку в т.ч. ETL (который знает про структуру таблицы нужной версии).
В целом, на практике, дешевле просто откатить DDL и перелить данные заново, просто запустив ETL соответствующей версии. Само-собой, технически, мы можем воссоздать объект "с-начала-времен", или откатить структуру таблиц, но обычно это штучные кейсы, когда встречается таблица с очень большим объемом данных.
Я надеюсь, ответил на вопрос. Если нет - можем продолжить тут или в телеге по желанию.
Василий, спасибо тебе и твоей команде, вышли на новый уровень.
парсинг sql - возможно самое важное, что нужно в дата платформах, на мой взгляд.. только так можно уберечься от человеческих ошибок..
Интересно, сколько человек задействовано в выкатке витрины и цена этой выкатки в соответствии с ценой, сколько эта витрина приносит пользы.. где в этой истории дата менеджмент? ручной лайнэдж - тоже такая себе затея, с каких пор мы стали доверять людям??
А если нужно будет сменить движок бд, то по старинним российским обычаям это затянется на минимум несколько лет...
Я идейно с вами согласен. Парсинг очень хочется. Только вот, написание такого функционала - долго и дорого (во всяком случае, для меня). Ну и, чем больше СУБД (читай, диалектов SQL) тем еще сложнее.
Я в статье описал ролевой состав. Можете прикинуть количество людей=) Наш подход к разработке и автоматизации наоборот построен на принципе "разработчик ЛУЧШЕ знает, что он хочет". Ограничения мы вводим только там, где без них нельзя обойтись.
Касательно смены движка - для нас это просто еще один драйвер. Основной кост на смену движка в освоении нового диалекта и нюансов СУБД разработчиком.
Спасибо интересная тема. Для нас больная тема, большая логика проекта хранится в хранимых процедурах. А почему выбран кастомный подход работы с гитом? есть же готовые решения версионирования в visual studio data tools и dbforge. Зачем постоянно создавать новый файл на alter table, если можно хранить только create, а его дифф генерировать в alter?
Разработчики стали счастливыми после прихода devops? Мне кажется что у них появилось больше работы с гитом. Нет сопротивление от них, что раньше было проще выводить в ручном режиме?
Не публиковали свой пайплайн в открытые источники? Интересно посмотреть на скрипт сборки tar файла
Делаем ТруЪ-DevOps в мире хранилищ данных