Разработка парсера на Python для 1С-Битрикс

Python-парсер для Битрикс: архитектура и реализация

Вы столкнулись с ситуацией, когда стандартный импорт через CSV или PHP-скрипт упирается в производительность? Например, нужно собрать 50 000 товаров с сайта конкурента, но PHP не тянет headless-браузер, а каталог партнёра отдаёт данные только через SPA. Мы решаем такие задачи: проектируем парсер на Python, который загружает данные в промежуточное хранилище, а PHP-импортёр переносит их в инфоблоки Битрикс. За 5 лет работы мы реализовали свыше 40 парсеров для интернет-магазинов на Битрикс — от простых RSS-агрегаторов до систем машинного обучения для классификации контента.

Многие владельцы крупных каталогов на Битрикс сталкиваются с проблемами при обновлении товаров: ручной ввод занимает дни, импорт из Excel сбивает кодировку, а партнёры не предоставляют API. Наш подход — Python для сбора, Битрикс для хранения и выдачи. Это даёт экономию времени до 70% и полную прозрачность процесса.

Почему Python, а не PHP

Конкретные причины, а не абстрактные преимущества:

• Асинхронность. asyncio + aiohttp обрабатывают 100+ запросов параллельно. PHP curl_multi на практике даёт 20–50 соединений.
• Headless-браузер. Playwright для Python стабильно работает с React-сайтами. PHP-обёртки Puppeteer менее надёжны.
• NLP и ML. Классификация текстов, извлечение сущностей — библиотеки spaCy, transformers не имеют аналогов в PHP.
• Библиотеки. BeautifulSoup, lxml, Scrapy — проверенные инструменты с большим сообществом.

Как устроена архитектура парсера?

Парсер на Python работает как отдельный сервис. Данные проходят через промежуточное хранилище — таблицы в общей базе данных или очереди RabbitMQ. Python пишет сырые данные, PHP-агент забирает их и пишет в инфоблоки с помощью CIBlockElement::Add.

Варианты хранилища

Для большинства проектов оптимальна общая база данных: Python пишет в промежуточную таблицу, PHP импортирует пакетами каждые 5–15 минут через cron.

Сравнение подходов: Python vs PHP для парсинга

Пример реализации на Scrapy

Scrapy — фреймворк, который берёт на себя очереди URL, retry, throttling. Spider для каталога:

import scrapy class CatalogSpider(scrapy.Spider): name = 'catalog' start_urls = ['https://example.com/catalog/'] def parse(self, response): for product in response.css('.product-card'): yield { 'name': product.css('h2::text').get(), 'price': product.css('.price::text').get(), 'description': product.css('.desc::text').get(), 'image': product.css('img::attr(src)').get(), 'url': product.css('a::attr(href)').get(), } next_page = response.css('.pagination .next::attr(href)').get() if next_page: yield response.follow(next_page, self.parse) 

Pipeline для записи в промежуточную таблицу:

import psycopg2 class BitrixPipeline: def open_spider(self, spider): self.conn = psycopg2.connect( host='localhost', port=5433, dbname='bitrix_db', user='bitrix' ) def process_item(self, item, spider): cursor = self.conn.cursor() cursor.execute(""" INSERT INTO parser_staging (name, price, description, image_url, source_url, status) VALUES (%s, %s, %s, %s, %s, 'new') ON CONFLICT (source_url) DO UPDATE SET price = EXCLUDED.price, updated_at = NOW() """, (item['name'], item['price'], item['description'], item['image'], item['url'])) self.conn.commit() return item 

Headless-браузер для SPA

Сайты на React или Vue отдают пустой HTML. Playwright решает это:

from playwright.async_api import async_playwright async def parse_spa(url): async with async_playwright() as p: browser = await p.chromium.launch(headless=True) page = await browser.new_page() await page.goto(url, wait_until='networkidle') content = await page.content() await browser.close() return content 

Ресурсоёмкость: каждый экземпляр Chromium потребляет 100–300 МБ RAM. Для массового парсинга используйте пул из 3–5 экземпляров и очередь задач.

Как передать данные в Битрикс?

PHP-скрипт на стороне Битрикс забирает данные из промежуточной таблицы:

$rows = $DB->Query("SELECT * FROM parser_staging WHERE status = 'new' LIMIT 100"); while ($row = $rows->Fetch()) { $elementId = (new CIBlockElement())->Add([ 'IBLOCK_ID' => CATALOG_IBLOCK_ID, 'NAME' => $row['name'], 'XML_ID' => md5($row['source_url']), // ... ]); if ($elementId) { $DB->Query("UPDATE parser_staging SET status='imported', bx_id={$elementId} WHERE id={$row['id']}"); } } 

Скрипт запускается по cron каждые 5–15 минут и обрабатывает новые записи пакетами.

Деплой и мониторинг

Python-парсер деплоится отдельно от Битрикс. Используйте systemd-сервис или cron для запуска по расписанию. Virtual environment (venv) изолирует зависимости. Логирование через модуль logging с ротацией. Мониторинг — скрипт проверяет, что парсер отработал за последние N часов, и отправляет алерт при зависании.

Типичный crontab:

0 1 * * * cd /opt/parsers && /opt/parsers/venv/bin/scrapy crawl catalog 2>> /var/log/parser.log 0 */4 * * * cd /opt/parsers && /opt/parsers/venv/bin/python news_parser.py 2>> /var/log/parser.log 

Мы используем custom healthcheck: каждые 4 часа проверяем, что парсер отработал без ошибок. Если завис — автоматический перезапуск и уведомление в Telegram. Для критичных проектов добавляем систему алертов на базе Prometheus и Grafana.

Когда нужен Python-парсер, а не PHP?

Если источник — SPA (React/Vue/Angular), объём данных превышает 10 000 элементов, требуется классификация контента или защита от DDoS — Python даёт значительное преимущество. Сравнение: Scrapy обрабатывает 10 000 URL за 5–10 минут, а PHP-решение с curl_multi — за 30–40 минут. Playwright в 3 раза стабильнее PHP-обёрток Puppeteer за счёт более глубокой поддержки браузера.

Как мы разрабатываем парсер

Мы предоставляем полный цикл разработки:

1. Анализ источника и согласование архитектуры.
2. Разработка паука на Scrapy или асинхронного парсера на aiohttp.
3. Настройка импортёра для Битрикс (инфоблоки, HL-блоки, торговые предложения).
4. Создание промежуточной базы данных и скриптов синхронизации.
5. Деплой на сервер (systemd, cron, мониторинг).
6. Документация по эксплуатации и обучение администратора.

Ориентировочные сроки

Срок разработки парсера — от 5 до 20 рабочих дней в зависимости от сложности источника и объёма данных. Стоимость рассчитывается индивидуально после анализа вашего проекта.

Мы гарантируем стабильную работу парсера 24/7 и предоставляем поддержку после запуска. Закажите консультацию: расскажите о вашем источнике данных, и мы предложим оптимальное решение в течение дня.

Разработка парсеров для 1С-Битрикс: с чего начать?

XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (CSV с CP1251, XML в CommerceML, Excel с объединёнными ячейками) превращаются в единый каталог с общей системой свойств инфоблока.
• Обогащение карточек — подтягиваем характеристики, инструкции, 3D-модели с сайтов производителей. Без этого карточка товара — пустышка для SEO.
• Обновление ассортимента — товары, пропавшие из фида поставщика, деактивируются через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Новые — создаются. Каталог синхронизирован.

Какие инструменты используем в разработке парсеров?

Статические сайты — PHP (Goutte, Symfony DomCrawler) или Python (Scrapy, lxml). Скорость: 50–100 страниц/сек. Хватает для каталогов без JS-рендеринга.

SPA и динамические сайты — Puppeteer или Playwright. Бесконечный скролл, AJAX-фильтры, lazy-load картинок — headless-браузер всё это обработает. Скорость падает до 1–10 страниц/сек, но альтернативы нет: данные существуют только после выполнения JavaScript.

Файлы поставщиков:

• Excel (XLS, XLSX) — PhpSpreadsheet. Осторожно с объединёнными ячейками и формулами — они ломают автоматический маппинг.
• CSV — fgetcsv() с правильной кодировкой. Поставщики любят CP1251, BOM в UTF-8 и точку с запятой вместо запятой. Всё это нужно детектить и обрабатывать.
• XML/YML — XMLReader для больших файлов, SimpleXML для фидов до 50 МБ.
• CommerceML — стандартный формат обмена с 1С. Разбираем import.xml и offers.xml, маппим на структуру инфоблоков.

API — REST-эндпоинты поставщиков, API маркетплейсов (Ozon Seller API, Wildberries API). Работаем в рамках rate limits, обрабатываем пагинацию.

Как устроен пайплайн автонаполнения?

Четыре этапа. Каждый может сломаться по-своему.

1. Сбор. Парсер обходит источники по cron-расписанию. Сырые данные пишем в промежуточную таблицу — не сразу в b_iblock_element. Логируем всё: сколько страниц обошли, сколько элементов распарсили, где получили 403 или timeout. Без логов отладка парсера — гадание на кофейной гуще.

2. Нормализация. Здесь основная работа:

   • Очистка HTML-тегов, лишних пробелов, Unicode-мусора
   • Единицы измерения: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Маппинг категорий поставщика → разделы инфоблока Битрикс. У одного поставщика «Ноутбуки», у другого «Ноутбуки и планшеты», у третьего «Laptops» — всё в одну секцию
   • Дедупликация по артикулу, EAN/GTIN. Один товар от трёх поставщиков не должен появиться трижды

   Загрузка в Битрикс. Через CIBlockElement::Add() для новых элементов, CIBlockElement::Update() для существующих. Изображения: скачиваем, ресайзим через CFile::ResizeImageGet(), конвертируем в WebP. Свойства — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генерируем из транслитерации названия.

   Обновление. Ключевой момент — не затереть ручные правки контент-менеджера. Обновляем только цену, остатки, активность. Описание и фото, доработанные вручную, помечаем флагом UF_MANUAL_EDIT в свойствах элемента и пропускаем при импорте. Товары, пропавшие из фида — деактивируем, но не удаляем.

   Почему мониторинг цен конкурентов необходим?

   Отдельная подсистема со своей спецификой:

   Параметр	Как устроено
   Частота	От раза в день до каждых 2 часов — зависит от волатильности рынка
   Сопоставление	По артикулу, EAN, нечёткое сравнение названий через расстояние Левенштейна
   Хранение	Своя таблица vendor_price_monitor с историей, не инфоблоки
   Алерты	Telegram/email при отклонении цены конкурента более чем на X%
   Автоправила	«Держать цену на 3% ниже минимальной среди конкурентов, но не ниже себестоимости + 15%»

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

   Модуль импорта CSV/XML: настройка под ваш формат

   Для файлов от поставщиков — кастомный модуль с админкой:

   • Настраиваемый маппинг: «колонка B в файле → свойство BRAND инфоблока»
   • Автодетект кодировки (CP1251, UTF-8, UTF-16) через mb_detect_encoding() с проверкой
   • Загрузка изображений по URL с очередью — чтобы не забить канал
   • Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
   • Cron-расписание, отчёт: создано 145, обновлено 892, ошибок 3 (с деталями)

   Большие файлы: CSV обрабатываем батчами по 1000 строк через fgetcsv(), XML потоково через XMLReader, фоновое выполнение через очередь агентов Битрикс — никаких PHP-таймаутов.

   Правовая сторона — что важно учесть

   • robots.txt — уважаем. Crawl-delay — соблюдаем.
   • Частота запросов — 1–2 в секунду, не больше. Не нужно DDoS-ить чужой сайт.
   • Контент производителей — используем. Уникальные авторские тексты — не копируем.
   • Персональные данные — не собираем.

   Что входит в разработку парсера под ключ?

   Составляющая	Описание
   Прототип	Парсер 1–2 источников за 2–3 дня для оценки качества данных
   Основной парсер	Полный сбор данных с одного источника (статический/динамический)
   Модуль импорта в Битрикс	Нормализация, загрузка, обновление, админка маппинга
   Мониторинг цен	Если требуется – система сбора и алертов (до 10 конкурентов)
   Документация	Описание архитектуры, инструкция по обновлению селекторов
   Поддержка	Гарантия 3 месяца на бесперебойную работу, правка при изменении вёрстки донора

   Как мы работаем и сроки

   1. Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
   2. Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
   3. Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
   4. Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
   5. Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.

   Задача	Сроки
   Парсер одного сайта (статический HTML)	3–5 дней
   Парсер SPA-сайта (Puppeteer/Playwright, обход защиты)	1–2 недели
   Модуль импорта CSV/XML в Битрикс	1–2 недели
   Система мониторинга цен (5–10 конкурентов)	2–4 недели
   Комплексная система автонаполнения	4–8 недель
   Поддержка и адаптация парсеров	по подписке

   Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.