Факты и измерения: как читать хранилище и не ошибиться с зерном

«Кубик» вырос из одной базы: у магазина появились инженеры данных, и они собрали настоящее хранилище. Мира рада, финансисты нет. В чате агентства с утра два числа, которые не сходятся.

Ким прав: это вопрос урока 01, «откуда цифра?», только теперь цифра пришла не из сырой таблицы, а из хранилища. Если ответить «да, врёт», Мира перестанет верить своим инженерам. Если «нет, верно», она понесёт 9 215 заказов на планёрку.

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

Протокол и справочники

Вспомни протокол футбольного матча. Каждая строка это событие: минута, игрок, что случилось. Строк много, и все устроены одинаково. А кто такой игрок под номером 10 и за какую команду он играет, написано в заявке команды, в отдельном списке.

В хранилище так же. Таблица событий растёт каждый день, это таблица фактов. Списки, которые эти события описывают, почти не меняются: это измерения. Числа в факте, которые складывают и усредняют, называют мерами.

«Кубик» как звезда

Разложим знакомую базу «Кубика»:

• order_items факт продаж. Одна строка это одна позиция заказа: какая игра, сколько штук, по какой цене. Меры: qty и выручка позиции qty * price;
• orders факт уровня заказа, «шапка» чека: когда, кто, со статусом и промокодом;
• products измерение товаров: жанр, издатель, цена в каталоге;
• customers измерение клиентов: город, канал привлечения;
• календаря в базе нет, его строят из generate_series, как в уроке про дыры в датах.

             calendar (из generate_series)
                       │
products ── order_items ── orders ── customers
                                 └── promo_codes

В рабочем хранилище дату и клиента обычно копируют прямо в факт позиций, чтобы от него до любого измерения был один JOIN. Факт в центре, измерения лучами вокруг: это звезда.

Бывает и иначе. Если измерение само разложено на справочники, например у товара ключ издателя, а у издателя ключ страны, получается снежинка. В «Кубике» маленький кусочек снежинки уже есть: у дополнения products.base_id указывает на базовую игру в той же таблице. Для аналитика разница простая: в снежинке до нужного признака идти через несколько JOIN, и на каждом можно ошибиться.

Первый вопрос к любой таблице

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

SELECT count(*) AS rows, count(DISTINCT order_id) AS keys
FROM deliveries;

таблица	заявленное зерно	строк	ключей
orders	заказ	6 555	6 555
order_items	позиция: заказ и игра	11 283	11 283
deliveries	заказ?	6 597	6 179

У доставок строк больше, чем заказов: зерно не «заказ», а «попытка доставки». Это те самые 418 повторных доставок из урока про размножение строк.