tradein/domclick: данные о доме с карточки не доезжают до houses — 400 домов против 3061 объявления #3253

New issue

Open

opened 2026-08-29 20:04:31 +00:00 by lekss361 · 1 comment

lekss361 commented

2026-08-29 20:04:31 +00:00

Owner

Что не так

Карточка Домклика несёт заметный блок про дом — houseInfo.info (тип стен, тип перекрытий, число подъездов, число квартир, энергоэффективность, серия дома) плюс productCard.address.guid (GUID здания у Домклика). Парсер это читает, но складывает целиком в listings.raw_payload, а в таблицу houses не переносит. В коде решение зафиксировано комментарием:

wall/floor type ОСТАЮТСЯ тут, НЕ пишем в listings.house_type (кросс-источниковый словарь грязный)

Отказ от listings.house_type обоснован — словарь типов у разных площадок несравним. Но из этого не следует, что данные не нужны и в houses, где для них есть отдельные колонки: material_walls, material_floors, total_floors, total_units, year_built, house_class.

Цифры на 29.08

источник	домов в `houses`	стены	год	этажей
derived	3815	3119	3349	3788
avito	2343	1583	1635	2312
cian	2105	1697	1983	2092
yandex	819	665	812	817
domklik	400	292	376	397

400 домов при 3061 активном объявлении Домклика — заметно меньше, чем у соседних площадок при сопоставимых объёмах.

Отдельно: total_units = 0 у ВСЕХ источников без исключения. Колонка есть, её никто никогда не заполнял. У Домклика в houseInfo.info.quartersCount это число прямо лежит и уже читается парсером в raw_payload.quarters_count — то есть данные в базе есть, просто не в той колонке.

Что сделать

Понять, откуда вообще берутся 400 домклик-домов — какой путь их создаёт (house_coords_from_listings? house_dedup_merge? свип?) и почему остальные не создаются.
Перенести дом-поля из raw_payload в колонки houses: quarters_count → total_units, wall_type → material_walls, floor_type → material_floors, плюс building_series / energy_efficiency / entrance_count (последним трём колонок нет — решить, заводить или оставить в raw_payload).
domclick_building_guid — проверить, годится ли как ключ связи объявления с домом (у Домклика это GUID здания, потенциально стабильнее адресного матчинга).
Заполнить total_units задним числом из уже собранных raw_payload — данные лежат, переливка не требует ни одного запроса к площадке.

Осторожно

Разбор 29.08 напоминает: доля заполненности по активным объявлениям обманчива — массовое обогащение 18.07 ушло в неактивные. Мерить покрытие домов надо по всем объявлениям, а не только по активным, иначе выводы будут о жизненном цикле объявлений, а не о сборе.

Связано

#3252 (аудит полноты карточки), #3250, #3246.

## Что не так Карточка Домклика несёт заметный блок про дом — `houseInfo.info` (тип стен, тип перекрытий, число подъездов, число квартир, энергоэффективность, серия дома) плюс `productCard.address.guid` (GUID здания у Домклика). Парсер это читает, но складывает **целиком в `listings.raw_payload`**, а в таблицу `houses` не переносит. В коде решение зафиксировано комментарием: > wall/floor type ОСТАЮТСЯ тут, НЕ пишем в listings.house_type (кросс-источниковый словарь грязный) Отказ от `listings.house_type` обоснован — словарь типов у разных площадок несравним. Но из этого не следует, что данные не нужны и в `houses`, где для них есть отдельные колонки: `material_walls`, `material_floors`, `total_floors`, `total_units`, `year_built`, `house_class`. ## Цифры на 29.08 | источник | домов в `houses` | стены | год | этажей | квартир | |---|---|---|---|---|---| | derived | 3815 | 3119 | 3349 | 3788 | 0 | | avito | 2343 | 1583 | 1635 | 2312 | 0 | | cian | 2105 | 1697 | 1983 | 2092 | 0 | | yandex | 819 | 665 | 812 | 817 | 0 | | **domklik** | **400** | 292 | 376 | 397 | 0 | 400 домов при 3061 активном объявлении Домклика — заметно меньше, чем у соседних площадок при сопоставимых объёмах. Отдельно: **`total_units` = 0 у ВСЕХ источников без исключения.** Колонка есть, её никто никогда не заполнял. У Домклика в `houseInfo.info.quartersCount` это число прямо лежит и уже читается парсером в `raw_payload.quarters_count` — то есть данные в базе есть, просто не в той колонке. ## Что сделать 1. Понять, откуда вообще берутся 400 домклик-домов — какой путь их создаёт (`house_coords_from_listings`? `house_dedup_merge`? свип?) и почему остальные не создаются. 2. Перенести дом-поля из `raw_payload` в колонки `houses`: `quarters_count` → `total_units`, `wall_type` → `material_walls`, `floor_type` → `material_floors`, плюс `building_series` / `energy_efficiency` / `entrance_count` (последним трём колонок нет — решить, заводить или оставить в `raw_payload`). 3. `domclick_building_guid` — проверить, годится ли как ключ связи объявления с домом (у Домклика это GUID здания, потенциально стабильнее адресного матчинга). 4. Заполнить `total_units` задним числом из уже собранных `raw_payload` — данные лежат, переливка не требует ни одного запроса к площадке. ## Осторожно Разбор 29.08 напоминает: доля заполненности по активным объявлениям обманчива — массовое обогащение 18.07 ушло в неактивные. Мерить покрытие домов надо по всем объявлениям, а не только по активным, иначе выводы будут о жизненном цикле объявлений, а не о сборе. ## Связано #3252 (аудит полноты карточки), #3250, #3246.

lekss361 referenced this issue

2026-08-30 12:23:07 +00:00

tradein/cian: добор карточек работает без единого отказа, но квота 100/сутки — остаток разгребается 190 дней #3284

Light1YT referenced this issue from a commit

2026-09-05 17:57:19 +00:00

fix(tradein/domclick): дом-поля карточки → houses, backfill total_units (#3253)

bot-backend referenced this issue

2026-09-05 18:01:24 +00:00

fix(tradein/domclick): дом-поля карточки → houses, backfill total_units/material_* из raw_payload (миграция 284) #3356

bot-backend commented

2026-09-05 18:34:36 +00:00

Collaborator

Прод-приёмка PR #3356 (05.09, ~18:35 UTC), миграция 284 применилась деплоем:

houses.total_units IS NOT NULL: 0 → 3198 — ровно предзамер (fill_total_units=3198 из SQL воркера до мержа);
material_walls в словаре ДОМ.РФ (кирпич | железобетонная панель | монолит | иное): 7454 → 7724 (+270); из 367 сырых значений Домклика 97 не попали в маппинг и честно остались NULL (warning в логе detail-пути покажет, какие);
строк с сырым домклик-текстом (заглавная кириллица) в material_walls: 0 — колонка осталась однословарной;
конфликтов «непустое ≠ raw» до миграции было 0 → COALESCE ничего не перезаписал.

Закрыты пп. 1 (факт: 400 домов = где Домклик пришёл первым; остальные сели на чужие дома по матчеру), 2 (перенос в detail-пути с каноном), 4 (backfill). Открыт п. 3 — domclick_building_guid как стабильный ключ дома (нужен замер схлопывания; отдельный заход). Колонки под серию/энергоэффективность/подъезды не заводились — данные остаются в raw_payload.

Датированный хвост (до 12.09): следующий domclick detail-прогон должен обновлять дома через _HOUSE_PARAMS_SQL — проверить count(total_units) растёт после прогона, а не только от бэкфилла.

Прод-приёмка PR #3356 (05.09, ~18:35 UTC), миграция 284 применилась деплоем: - `houses.total_units IS NOT NULL`: **0 → 3198** — ровно предзамер (`fill_total_units=3198` из SQL воркера до мержа); - `material_walls` в словаре ДОМ.РФ (`кирпич | железобетонная панель | монолит | иное`): 7454 → **7724** (+270); из 367 сырых значений Домклика 97 не попали в маппинг и честно остались NULL (warning в логе detail-пути покажет, какие); - строк с сырым домклик-текстом (заглавная кириллица) в `material_walls`: **0** — колонка осталась однословарной; - конфликтов «непустое ≠ raw» до миграции было 0 → COALESCE ничего не перезаписал. Закрыты пп. 1 (факт: 400 домов = где Домклик пришёл первым; остальные сели на чужие дома по матчеру), 2 (перенос в detail-пути с каноном), 4 (backfill). **Открыт п. 3** — `domclick_building_guid` как стабильный ключ дома (нужен замер схлопывания; отдельный заход). Колонки под серию/энергоэффективность/подъезды не заводились — данные остаются в `raw_payload`. Датированный хвост (до 12.09): следующий domclick detail-прогон должен обновлять дома через `_HOUSE_PARAMS_SQL` — проверить `count(total_units)` растёт после прогона, а не только от бэкфилла.