Насколько актуальны данные в дашборде по отношению к источнику.
$$\text{Freshness} = \text{now()} - \text{max(event_at)} \text{ в источнике}$$
Или: $$\text{Lag} = \text{loaded_at} - \text{event_at}$$
Что это
Сколько прошло времени между событием в реальности и его отображением в твоей аналитической системе.
Типичные SLA по freshness
| Тип данных | Freshness |
|---|---|
| Реалтайм дашборды (operations) | < 1 минута |
| Дневные дашборды (продакты) | < 1 час |
| Месячные финансовые отчёты | < 24 часа |
| ML-фичи в проде | < 5 минут |
Тонкости
Источник truth — не "когда строка попала в DWH", а «когда произошло событие в реальности». Если транзакция случилась в 14:00, а в DWH попала в 14:30 — freshness = 30 минут, не «свежо».
Two-tier freshness — для дашборда: что устарело? Заголовок KPI (свежесть критична) или таблица последних 100 событий (можно отстать на 5 мин). Часть данных может требовать 1-минутной свежести, часть — часовой.
Monitoring — настрой алёрт если max(event_at) в источнике > 1 часа назад. Это значит ETL сломался, или источник перестал писать.
Частые причины «несвежих» данных
SQL чек на свежесть
Часто пишут как гейтер в CI/CD: если freshness > threshold — алерт в Slack.
-- Простой чек: насколько устарели события в orders
select max(event_at) as latest_event,
extract(epoch from (now() - max(event_at)))/60 as lag_minutes
from events
where event_name = 'order_paid';
-- Если lag_minutes > 10 — критический алерт