ddadmin
3e9249933b
Зачем: результатом лабораторных должны быть обоснованные решения о подготовке данных для витрин. Что: добавлены проверяемые результаты сверки полноты, выбора ключа, точного разбора и правила пересчета; обновлены программа и индекс, убран подсчет долей потерь. Проверка: SELECT-запросы под analyst, расчеты по сохраненной истории девяти наблюдений, 54 локальные ссылки, git diff --check и независимое техническое ревью.
6.6 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.
Что должно получиться
- сохранен запрос с одной строкой на заказ, числом событий и суммой;
- уникальность ключа и полнота набора номеров проверены по источнику;
- разность сумм полностью объяснена вкладом лишних событий;
- обоснованы ключ расчета и место устранения повторов;
- найден случай, показывающий границы расчета денег по трекеру.