Спроектируйте репликацию данных сервисов в хранилище через CDC
Вопрос
20 микросервисов на PostgreSQL, в сумме 300 таблиц, крупнейшие на миллиард строк. Сейчас ночные полные выгрузки идут 7 часов и нагружают базы. Нужно: данные в хранилище с задержкой до 15 минут, удаления и история изменений, минимальная нагрузка на источники. Спроектируйте решение.
Коротко
Что должно быть в решении
- 1Требования: свежесть 15 минут, удаления, история, какие таблицы критичны, ПДн, нагрузка на источники
- 2Захват: Debezium на Kafka Connect, логическая репликация, слоты и публикации, права, начальные снимки по очереди
- 3Транспорт: топик на таблицу, ключ по первичному ключу, Schema Registry, retention под переигрывание
- 4Загрузка: сырой журнал изменений в хранилище (append) и текущее состояние через MERGE или ReplacingMergeTree по позиции журнала
- 5Удаления и история: мягкое удаление в текущем состоянии, SCD 2 из журнала изменений
- 6Изменения схем: правила совместимости, контракты с командами сервисов
- 7Эксплуатация: мониторинг отставания слотов и WAL на источниках, lag консьюмеров, сверки ключей и сумм, план повторной инициализации
Что спросит интервьюер
- Что делать, если коннектор лежал сутки?
- Как сделать начальную загрузку таблицы на миллиард строк без нагрузки на прод?
- Как поступить с колонками с персональными данными?
Разбор
Сильное решение: log-based CDC вместо выгрузок, сырой журнал изменений как источник истины в хранилище и производное текущее состояние, применённое по позиции журнала. Особое внимание эксплуатации: слоты на боевых базах мониторятся и имеют предел удерживаемого WAL, начальные снимки больших таблиц делаются по частям или с реплики, изменения схем согласуются контрактами. Персональные данные маскируются на входе или не реплицируются вовсе. Регулярная сверка с источником ловит тихие расхождения.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.