разминаю мозги, пытаясь понять для чего этот их
zero-etl ↑ будет хорош, а для чего не очень.+
из позитивного: я бы не отказался, если бы автоматика взяла на себя базовый сценарий «сделай мне данные как в источнике, но в двх». В компании всегда найдутся потребители и задачи, для которых этого будет достаточно (тем более с секундными задержками-то!).
либо на ранней стадии, когда двх ещё нет, но селектить прод-данные в операционной бд уже больно — клик-клик в админке! — и рядом развёрнут отдельный кластерочек для полутора аналитиков.
в целом, похоже на ещё один инструмент в ящике дата-инженера.
-
Старший коллега, которому я с горящими глазами рассказывал как эта автоматика заменит всё двх, смотрит на это всё крайне скептически — мол, проблема таких магических подкапотных систем, оно всё работает пока работает; а когда перестанет работать будет непонятно как его чинить.
Плюс остаётся вопрос моделирования данных. В тех немногих проектах, где я успел поработать, модель данных в хранилище отличалась от операционной. Что логично: их в принципе дизайнили под разные задачи и разное окружение.
И что там с изменением схемы данных? что будет с этой хвалёной магической репликацией, когда на бэке решат удалить-добавить-поменять полюшко?
Ещё в голову приходит бекфил: вдруг настолько повезло, что захочется перезалить данные с источника ещё раз. Эт как тут?
Ну и данные из стороннего АПИ эта штука тоже не затащит конечно. В любом случае придётся рядом поднимать дополнительно ещё что-то, чтобы покрыть весь спектр задач.
в общем, с дивана ничего не понятно — надо пробовать (желательно сначала на чужой системе!)