fix(dq): устранено переполнение памяти проверок

- Зачем:
  - параллельный DQ выгружал деловые ключи в Python и исчерпывал 640 МиБ планировщика.
- Что:
  - четыре сверки агрегируют дневные итоги и ограниченную диагностику в ClickHouse.
  - коробка планировщика поднята до 1,5 ГиБ, локальные пределы задач удалены.
  - измерения и граница между SQL и Python записаны в документации.
- Проверка:
  - make lint, make config-test, make smoke, make check-clickhouse, make check-services.
  - полный etl_pipeline, красный и восстановительный прогоны dq_check.
This commit is contained in:
ddadmin committed 2026-08-27 11:25:19 -04:00
1 parent 26b2e5fea1
commit 54686651df
10 files changed
+295 -190

No files matched your search

+14 -6
View File
@@ -195,12 +195,20 @@ Distributed-таблица вернула бы каждый непарный з
подтверждает, что до витрины доехал записанный в описи мир, но не проверяет
сам генератор: у настоящего магазина такого оракула нет.
Пять сборок пишут в общий донор. Только после их успеха даг заменяет все
проверенные дневные партиции, затем именованные задачи читают опубликованную
сводку и падают при `failed_rows > 0`. Расхождение успевает сохраниться до
красного завершения, а ошибка сборки не затирает прежний результат. Красная
задача печатает не больше двадцати нарушенных ключей со значениями сторон;
полный список воспроизводится запросом проверки.
Четыре SQL-сверки считают дневные итоги в ClickHouse и возвращают Airflow
только сводку и малый срез диагностики. Техническая сверка с описью читает
небольшой файл JSON в Python. Все пять сборок пишут в общий донор. После их
успеха даг заменяет проверенные дневные партиции. Затем именованные задачи
читают опубликованную сводку и падают при `failed_rows > 0`. Расхождение успевает
сохраниться до красного завершения, а ошибка сборки не затирает прежний
результат. Красная задача печатает не больше двадцати нарушенных ключей за
проверку со значениями сторон. Для полного списка итоговую агрегацию SQL-сверки
заменяют на `SELECT * FROM comparison WHERE failed ORDER BY data_date,
business_key`.
Если после починки день исчез с обеих сторон, его больше нет и в новом доноре.
Такой день удаляется из сводки отдельно: старая красная строка не должна
превращаться в историю попыток.
## Даг самопроверки