ddadmin
4693bc5af9
- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок. - Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки. - Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.
6.8 KiB
Почему повтор покупки завышает выручку
Несколько событий покупки могут относиться к одному заказу. Вы проверите, как они завышают сумму, и составите расчет, который учитывает каждый заказ один раз.
Факультатив доступен после ступени 1. Работайте в DBeaver пользователем
analyst по инструкции.
Дождитесь завершения etl_pipeline; оставьте world_live на паузе и
дождитесь уже начатых прогонов, чтобы данные не менялись между запросами.
Расчет по событиям покупки
В ODS уже устранены повторные доставки событий. Достаточно ли этого,
чтобы сложить суммы всех purchase для витрины заказов? Проверьте на данных.
Возьмите день, за который уже получены все слепки заказов: его дата должна быть не позднее
max(snapshot_date) - 6 из ods.order_v. Во всех запросах к dds.event_v
отбирайте этот event_date и event_type = 'purchase'.
Номер заказа находится в purchase_id[1], заявленная сумма — в
purchase_revenue[1]. По формату источника у события покупки один номер заказа.
Сначала посчитайте число событий и сумму всех заявленных сумм. Затем найдите номера заказов, которые встречаются несколько раз. Если таких нет, выберите другой день с полученными слепками.
Для двух повторившихся покупок выпишите event_id, client_id, event_time,
номер заказа и сумму. Сопоставьте число событий и заказов в dds.order_v.
Расчет по заказам
Напишите запрос с одной строкой на номер заказа. Сохраните в результате номер, число исходных событий и одну заявленную сумму. До выбора суммы проверьте, что во всех событиях заказа она одинакова. Затем посчитайте итог дня по результату этого запроса и сравните с расчетом по событиям.
Проверьте, что номера в результате уникальны, а число строк совпадает с числом разных номеров в исходных событиях. Отдельно проверьте свое решение на случае двух разных заказов с одинаковой суммой: сколько денег оно учтет?
Заказы с повторными событиями
Возьмите один повторившийся номер заказа. Сколько денег он добавил в первый расчет и сколько — во второй? Подтвердите разность его событиями.
Повторите расчет для остальных повторившихся номеров. Сохраните таблицу: номер заказа, число событий и вклад в разность сумм. Проверьте, объясняют ли эти заказы все расхождение за день до копейки.
Слой ODS убирает повторную доставку одного события по его идентификатору;
dds.event_v читает уже это состояние. Сравните число разных event_id
и число разных номеров заказа в выбранных строках. Почему устранение
повторов по первому ключу не дало тот же результат, что по второму?
Подтвердите ответ конкретными идентификаторами.
После собственного расчета найдите эти заказы в dm.purchase_vs_orders_v.
Если у повторившегося заказа класс отличается от duplicate_event, проверьте
его статус и порядок присвоения классов.
Класс витрины не заменяет поиск всех повторов в событиях.
Сравнение с выручкой магазина
Сложите revenue из dm.revenue_daily_v за тот же report_date по всем
категориям. Эта витрина считает стоимость позиций оплаченных заказов,
без скидки и доставки.
Сравните результат с суммой по событиям после устранения повторов. Совпадение не требуется: удаление повторов устраняет одну причину расхождения. Найдите хотя бы один заказ, который объясняет, почему деньги трекера и магазина все еще могут различаться. Для этого сопоставьте события, заказ и готовую сверку.
Рядом с запросом укажите, чему соответствует одна строка результата
и какие поля ее определяют. Обоснуйте, где нужна одна строка на событие,
а где одна на заказ: следует ли ради этого расчета
удалять повторные покупки из dds.event_v? Используйте найденные event_id.
Результат работы
- сохранен запрос с одной строкой на заказ, числом событий и суммой;
- уникальность ключа и полнота набора номеров проверены по источнику;
- разность сумм полностью объяснена вкладом лишних событий;
- обоснованы ключ расчета и место устранения повторов;
- найден случай, показывающий границы расчета денег по трекеру.