Компактное представление истории нерегулярно меняющихся данных

Тема данного поста навеяна чтением Ральфа Кимбалла, который выделяет три вида таблиц фактов при построении хранилищ данных: транзакционные, снэпшотные и накопительные. В первых каждой строке соответствует отдельная транзакция (бизнес-операция, факт снятия показаний, зарегистрированное уникальное событие), загружаемая в хранилище данных из системы-источника. Вторые формруются из периодически загружаемых моментальных снимков (снэпшотов), где каждый снэпшот содержит множество строк. Третьи допускают многократное обновление строк, поскольку их строки описывают некие эволюционирующие сущности, например, заказы с этапами жизненного цикла или продажи за месяц при ежедневном обновлении.

Поговорим о снэпшотных таблицах фактов. И начнем с определения контекста.

Как мы интегрировали системы через шину данных

В торговой сети "Бубль-Гум" десяток взаимодействующих информационных систем, а в качестве шины данных у нас Apache Kafka.

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

Еще раз о ловле и обработке изменений в реляционной БД

Часто возникает задача получения изменений в таблице БД за период для их обработки. Существуют такие основные варианты решения:

1. маркирование каждой измененной записи тем или иным образом,
2. регистрация каждого изменения в отдельной таблице с помощью триггера (см. подробнее Захват и обработка изменений в БД...),
3. получение изменений за период с помощью разности с более ранним снэпшотом (см. подробнее Передача изменений между БД: подход в духе KISS).

Если у вас есть выбор, какой из вариантов реализовать, то сделать этот выбор правильно помогут ответы на следующие вопросы: