09:00. Витрина за вчера пустая, за позавчера удвоена

Тикет №01. «Отчёт врёт»

09:00, 15 марта 2184 года. Ты заступаешь на приёмный уровень станции «Хранилище-9» — тусклый грузовой ярус, куда лента приёмки всю ночь втаскивает архивные снимки и раскладывает их по хранилищу. Утром её работу читает Академия.

В очереди один тикет, открытый в 08:41 смотрителем архива:

«Суточный отчёт врёт. За вчера пусто — как будто лента стояла. За позавчера выручка вдвое больше, чем в самих снимках. Что из этого правда?»

Ответ неприятный: правды в отчёте нет вообще. Вчера лента шла, а позавчера в снимках ровно половина того, что показывает витрина. Обе строки тикета — про один и тот же участок, но про две разные ночи.

Ленту вёл предшественник. С девяти утра она твоя.

КВЕРИ: Доброе утро, архивист. Предшественник оставил тебе журнал прогонов и две недописанные проверки. Я всю ночь дремал в фоновом процессе — и всё видел. Пустая ночь и удвоенная ночь — разные аварии; начни с того, чтобы их различить.

Витрина dm_daily_revenue — конец ленты, последняя полка: одна строка на день и город. Перед ней стоят отдельные слои загрузки. Их устройство разберём в следующем уроке; пока достаточно знать, что витрина хранит итог.

Сегодня задача проще: прочитать показания и назвать аварию своим именем.

Две разные аварии в одной таблице

Показания сняты — теперь назовём то, что видно.

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

Со стороны это выглядит как одна поломка отчёта. На деле поломки две, и лечат их по-разному:

Разница принципиальная. В первом случае повтор — лекарство, во втором — добавка к болезни: он положит в витрину третий комплект строк.

Второй случай требует идемпотентности: свойства шага давать один и тот же результат, сколько бы раз его ни запустили.

Пока запомни симптом: два run_id на один день — это признак повторной загрузки, которая дописала, вместо того чтобы заменить.

Но симптом — ещё не история. Что происходило ночью, показывает журнал прогонов etl_runs. Его ведут не для отчётности: только там остаётся след каждой попытки, в том числе запущенной автоматически.

КВЕРИ: Разворачиваю журнал за обе ночи. Люди помнят, что они запускали. Журнал помнит, что запустилось.

Что случилось ночью

Журнал показывает всю историю — по попыткам, а не по итогу.

13 марта — три попытки одной задачи вместо одной.

• 990001, 02:31–02:33, up_for_retry, rows_out = 0 — попытка не доехала и ничего не записала;
• 990002, 02:41–02:44, success, rows_out = 22 — повтор посчитал день и положил его в витрину: двадцать два города, двадцать две строки;
• 8812, 03:24–03:28, failed, rows_out = 1552 — ещё одна попытка того же дня, которая упала, но уже успела дойти до записи.

Вот и объяснение сорока четырём строкам: день положили в витрину больше одного раза, потому что загрузчик при повторе дописывал к тому, что там уже лежало.

Никто не заметил по простой причине: успешная попытка в списке есть, а зелёная попытка выглядит как «всё хорошо». Авария спряталась не за отсутствием сигнала, а за сигналом об успехе рядом с чужой записью.

Про rows_out у неуспешных попыток. 1552 — это не «столько строк в витрине». Счётчик пишется по ходу работы, и у попытки, которая не дошла до конца, он подтверждает ровно одно: она успела дойти до записи.

Сколько именно строк дошло до витрины и дошли ли они вообще — по нему не определить. Поэтому смотрят сначала на состояние, и только потом на числа.

14 марта. Та же задача до сих пор в состоянии running, finished_at пуст, и rows_out у неё тоже не ноль — но это не доказывает, что строки уже попали в витрину: попытка не завершилась, а дня там нет.

Значит, задача не упала, а зависла. Данных за вчера нет, потому что загрузка их ещё не привезла; что с ними на предыдущих слоях, витрина не говорит.

Чего журнал НЕ говорит: какая именно попытка положила какие именно строки. У витрины свой run_id загрузки, у журнала — свой номер попытки, и связь между ними появится в главе de2.

Но на главный вопрос смены он ответил: попыток было несколько, и одна из них упала, дойдя до записи.

Отсюда правило смены, к которому курс будет возвращаться десять глав подряд:

Сначала спроси у журнала прогонов, что происходило, и только потом — у данных, что в них лежит. Данные показывают следствие, журнал показывает причину.

Голый INSERT — это не загрузка

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

Дописывать правильно только тогда, когда событие происходит один раз. Загрузка за дату — не такое событие: она случается столько раз, сколько её запустят, а запустят её обязательно больше одного раза — ретраем ночью или руками утром.

Нужное свойство шага называется идемпотентность: сколько бы раз его ни выполнили с одними и теми же входами, состояние получается одно и то же. Не «шаг не упадёт при повторе», а именно «после второго прогона в таблице ровно то же, что после первого».

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

Тогда шаг из «посчитать и дописать» превращается в пару:

1. DELETE всего, что относится к этой дате;
2. INSERT … SELECT того, что посчитали сейчас.

Смысл пары виден на повторах. Первый запуск удаляет ноль строк и кладёт двадцать две. Второй удаляет двадцать две и кладёт двадцать две. Десятый — то же самое.

Соседние даты при этом не страдают: удаляется СВОЙ диапазон, а не таблица целиком.

Одна оговорка про прод: без транзакции между DELETE и INSERT витрина пуста за этот день, и отчёт, попавший в эту щель, покажет ноль. В транзакционной базе обе операции поэтому обычно объединяют. В песочнице курса управлять транзакцией нельзя — BEGIN не пропустит валидатор, — поэтому ниже пара идёт просто двумя операторами подряд.

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