Python-парсер для Битрикс: архитектура и реализация
Вы столкнулись с ситуацией, когда стандартный импорт через CSV или PHP-скрипт упирается в производительность? Например, нужно собрать 50 000 товаров с сайта конкурента, но PHP не тянет headless-браузер, а каталог партнёра отдаёт данные только через SPA. Мы решаем такие задачи: проектируем парсер на Python, который загружает данные в промежуточное хранилище, а PHP-импортёр переносит их в инфоблоки Битрикс. За 5 лет работы мы реализовали свыше 40 парсеров для интернет-магазинов на Битрикс — от простых RSS-агрегаторов до систем машинного обучения для классификации контента.
Многие владельцы крупных каталогов на Битрикс сталкиваются с проблемами при обновлении товаров: ручной ввод занимает дни, импорт из Excel сбивает кодировку, а партнёры не предоставляют API. Наш подход — Python для сбора, Битрикс для хранения и выдачи. Это даёт экономию времени до 70% и полную прозрачность процесса.
Почему Python, а не PHP
Конкретные причины, а не абстрактные преимущества:
- Асинхронность.
asyncio+aiohttpобрабатывают 100+ запросов параллельно. PHPcurl_multiна практике даёт 20–50 соединений. - Headless-браузер. Playwright для Python стабильно работает с React-сайтами. PHP-обёртки Puppeteer менее надёжны.
- NLP и ML. Классификация текстов, извлечение сущностей — библиотеки
spaCy,transformersне имеют аналогов в PHP. - Библиотеки. BeautifulSoup, lxml, Scrapy — проверенные инструменты с большим сообществом.
Как устроена архитектура парсера?
Парсер на Python работает как отдельный сервис. Данные проходят через промежуточное хранилище — таблицы в общей базе данных или очереди RabbitMQ. Python пишет сырые данные, PHP-агент забирает их и пишет в инфоблоки с помощью CIBlockElement::Add.
Варианты хранилища
| Способ | Объём данных | Особенность |
|---|---|---|
| JSON-файлы | до 1 000 | Просто, без зависимостей |
| PostgreSQL/MySQL | 1 000–100 000 | Индексы, транзакции |
| REST API Битрикс | любой | Прямая запись, но HTTP overhead |
| Redis/RabbitMQ | потоковая | Очереди, масштабирование |
Для большинства проектов оптимальна общая база данных: Python пишет в промежуточную таблицу, PHP импортирует пакетами каждые 5–15 минут через cron.
Сравнение подходов: Python vs PHP для парсинга
| Критерий | Python | PHP |
|---|---|---|
| Асинхронные запросы | asyncio + aiohttp (100+ параллельно) | curl_multi (20-50) |
| Headless-браузер | Playwright (стабильный) | Puppeteer (менее надёжный) |
| NLP/ML | spaCy, transformers | отсутствуют |
| Экосистема парсинга | Scrapy (полноценный фреймворк) | Goutte (ограниченный) |
Пример реализации на 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 за счёт более глубокой поддержки браузера.
Как мы разрабатываем парсер
Мы предоставляем полный цикл разработки:
- Анализ источника и согласование архитектуры.
- Разработка паука на Scrapy или асинхронного парсера на aiohttp.
- Настройка импортёра для Битрикс (инфоблоки, HL-блоки, торговые предложения).
- Создание промежуточной базы данных и скриптов синхронизации.
- Деплой на сервер (systemd, cron, мониторинг).
- Документация по эксплуатации и обучение администратора.
Ориентировочные сроки
Срок разработки парсера — от 5 до 20 рабочих дней в зависимости от сложности источника и объёма данных. Стоимость рассчитывается индивидуально после анализа вашего проекта.
Мы гарантируем стабильную работу парсера 24/7 и предоставляем поддержку после запуска. Закажите консультацию: расскажите о вашем источнике данных, и мы предложим оптимальное решение в течение дня.