Comments 9
Спасибо за статью! Хотелось бы узнать, как у вас устроен обмен знаниями с командами, которые разрабатывают микросервисы: поля, таблицы и т.д. все это может быстро протухать или изменять свое значение, вчера разрабы хранили статусы как integer, завтра решили вынести это в отдельную табличку. Как в этом хаосе поддерживать аналитику в актуальном состоянии?
Спасибо за интерес! Каждое утро мы проверяем, как изменились схемы каждой конкретной БД. Если появились новые столбцы или новые таблицы, если какие-то столбцы или таблицы исчезли или если у столбцов сменился тип данных, мы рассылаем оповещение со списком изменений команде аналитиков. К счастью, удаления столбцов/таблиц и смена типов происходит не слишком часто и по процессу о них команды должны предупреждать заранее, однако да, случаются и инциденты, когда из-за внезапных изменений что-то в аналитике ломается. В таких случаях оперативно оповещаем и помогаем аналитикам привести все в порядок.
Спасибо за ответ. Следить за изменениями в схеме бд – хорошая история, но кажется, что этого не достаточно, ведь может, например, появился новый тип в строковом поле и в статистику полезут лишние сущности или наоборот окажется недобор оных. И самое страшное при этом, что отчетность не сломается – она просто перестанет отображать реальную картину и через сколько такую ошибку найдет аналитик или бизнес – большой вопрос. Может у вас есть какие-то лайф-чекапы рядом с аналитическими отчетами или вся надежда на коммуникацию?
К сожалению, об изменениях внутри поля сейчас не узнаем. На критически важные сущности, от которых зависит бóльшая часть аналитики, настраиваем отдельные проверки вместе с командой, отвечающей за качество данных. Они, например, помогают следить за изменением динамики каких-то метрик, чтобы улавливать подобные моменты.
Стандартизированного решения для всего массива данных пока нет, если есть какие-то интересные идеи/предложения, с радостью послушаем и обдумаем!
Стандартизированного решения для всего массива данных пока нет, если есть какие-то интересные идеи/предложения, с радостью послушаем и обдумаем!
Спасибо было интересно! жду продолжения по джойнам с разных серверов. Много было шишек по этой теме, от настройки серверов БД до построения вьюх.
Интересно было бы прочитать трюки с JOIN. Как я понял в FDW нет ничего похожего на распределенный JOIN, как в Hive или Impala. Мы, к сожалению, тоже имели глупость распилить доменку на части и, собирая аналитику, с разных схем тоже пришли к FDW, но не стали мудрить с оптимизацией запросов, а перешли к MATERIALIZED VIEW по типу —
CREATE MATERIALIZED orders_v AS SELECT * FROM orders.orders; 
Можно было построить полноценное хранилище — мы даже пробовали, но, если честно, так и не удалось подружить достаточно частые изменения в логике с достаточно медленным процессом построения хранилища и внесения в него изменений (если у кого-то получилось, напишите в комментариях как)Вообще странно, что не получилось… Не очень понимаю в чем суть проблемы — у Вас спринты недельные и нет документирования доработок как класса? Навскидку не назову тех кто имеет норм DWH и появился после старта хайпа микросервисной архитектуры, но явно ведь есть такие.
Но если выбрать правильный инструмент для аналитики — MPP колоночную БД и политическое решение собственников тратиться на качественную аналитику, то проблемы быть не должно. Глядя на Ваш стэк предположу, что пытались на Greenplum сделать хранилище? Бесплатно, но трудозатратно и местами больно.
PS: у нас (телеком с солид переходящим на микросервисы) DWH появилось задолго до хайпа микросервисов и на офигительной Vertica — нет смысла делиться опытом, т.к. изначальные условия разные
Sign up to leave a comment.
Оперативная аналитика в микросервисной архитектуре: п̶о̶н̶я̶т̶ь̶ ̶и̶ ̶п̶р̶о̶с̶т̶и̶т̶ь̶ помочь и подсказать Postgres FDW