Архитектура данных

Как безопасно изменить схему события, если его одновременно читают независимо разворачиваемые потребители?

В аналитической системе один запрос читает малую долю столбцов из очень широкой таблицы. Как выбор строкового или колоночного хранения повлияет на стоимость такого запроса?

Поток CDC повторно доставляет одно изменение в аналитическое хранилище. Какой механизм должен обеспечить корректный итог?

В интернет-магазине тяжёлый отчёт запускают прямо в базе заказов. Какое архитектурное последствие следует ожидать?

Объясните механизм, позволяющий аналитической витрине оставаться согласованной с транзакционной системой при задержке обновления.

Поток событий содержит сообщения с разным временем доставки. Как механизм должен определить момент закрытия временного окна, чтобы учесть опоздавшие события?

events:
  - id: A
    event_time: "10:00"
    arrival_time: "10:01"
  - id: B
    event_time: "09:58"
    arrival_time: "10:05"
window: "09:55-10:00"
allowed_lateness: "5 minutes"

В аналитической витрине таблица партиционирована по дате загрузки, но отчёты фильтруют дату события. Разберите, какой побочный эффект даст такой выбор ключа.

CREATE TABLE events (
  event_id       BIGINT,
  event_time     TIMESTAMP,
  ingestion_date DATE,
  payload        JSON
) PARTITION BY RANGE (ingestion_date);

SELECT count(*)
FROM events
WHERE event_time >= TIMESTAMP '2025-01-01'
  AND event_time <  TIMESTAMP '2025-02-01';

Сравните нормализованную и денормализованную модели хранения для аналитической нагрузки: какой архитектурный компромисс возникает при отказе от части связей между сущностями?

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

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

В отчёте за прошлый год имя клиента должно соответствовать его значению на дату заказа. Как организовать хранение измерения?

Сервис хранит состояние сущности только как последовательность неизменяемых событий. Как получить её текущее состояние при чтении?

Сервис после успешной записи читает данные из реплики базы и иногда получает прежнее состояние. Какой архитектурный механизм это объясняет?

Потребитель потока не успевает обрабатывать сообщения. Как механизм обратного давления должен изменить поведение системы?

Представьте, что аналитический отчёт постоянно пересчитывает одну агрегацию. Что меняется в системе при переносе этого расчёта в материализованную витрину?

Во время формирования отчёта чтение нескольких связанных таблиц должно отражать единый момент времени, хотя записи продолжаются. Какой механизм транзакционной СУБД это обеспечивает?

В аналитическом хранилище запросы часто выбирают узкий диапазон времени. Как физический порядок строк может уменьшить объём чтения?

Сравните пакетную и потоковую обработку данных для аналитической витрины: какой компромисс возникает при уменьшении задержки обновления?

Как предотвратить попадание в аналитическое хранилище событий, несовместимых с согласованной схемой?

Система удаляет запись в источнике, но аналитическая витрина продолжает считать её действительной. Какой сигнал должен передать поток данных, чтобы удаление не потерялось?