Как вытащить аналитику из Битрикса и не поймать бан по дороге

Битрикс отдаёт данные по 50 штук за раз и банит за жадность. Рассказываю, как построить на этом нормальную аналитику.

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

А вот и нет. У Битрикса REST API, который выдаёт записи порциями по 50 штук и блокирует тебя, стоит начать частить. Несговорчивый свидетель, из которого показания вытягиваешь по чуть-чуть.

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

Облачный Битрикс живёт по лимитам. Базовый = два запроса в секунду. Превысил, ловишь ошибку и блокировку.

Работает так: каждый твой запрос увеличивает внутренний счётчик. Перебрал порог — следующие запросы отлетают с 503-й ошибкой, пока счётчик не остынет.

Есть и второй лимит, по времени: если методы суммарно молотят дольше положенного за десять минут, метод встаёт на паузу.

Представь очередь в одну кассу. Подходишь по одному, всех обслужат. Пытаешься протолкнуть сразу сотню, касса закрывается на переучёт.

Поэтому «выкачать по-быстрому всё» не выйдет. Нужен контур, который забирает данные аккуратно и хранит их у себя.

Схема называется ELT. Extract, Load, Transform. Сначала вытащили сырьё, сложили к себе, и только потом крутим.

Главное правило: не заставляй Битрикс что-либо считать и трансформировать. Его дело — отдать сырые данные. Вся аналитическая магия происходит уже в твоей базе, в Postgres.

Поток выглядит так:

Битрикс → raw → clean → marts → BI

Между Битриксом и дашбордом стоит Postgres, разбитый на три слоя. Каждый слой — своя зона ответственности.

Представь склад. Обычный, с зонами.

Плюс служебная зона, без которой всё развалится: метка последней выгрузки, журнал прогонов и кэш словарей. О них дальше.

Четыре приёма, которые экономят нервы.

Батчи. Не дёргай API по одной записи. Метод batch пакует до 50 операций в один запрос. Вместо пятидесяти обращений — одно.

Инкремент вместо полной выгрузки. Не тащи всю базу каждый раз. Забирай только изменённое с прошлого прогона — по полю с датой изменения. А дату последней успешной выгрузки запоминай в служебной таблице. Это и есть watermark, водяная метка. Полную выгрузку оставь для редкой сверки.

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

Паузы и повторы. Словил временную ошибку — не долби сразу, подожди и повтори. Пара запросов в секунду с паузами вывезет миллионы записей. Жадность вывезет только бан.

BI-система подключается напрямую к Postgres. С одним условием.

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

Выглядит как занудство. Но именно из-за таких занудных мелочей потом никто не гадает, почему в отчёте цифры поехали.

1. Гонят полную выгрузку каждый раз. База растёт, выгрузка удлиняется, в один день упирается в лимиты и встаёт колом. Инкремент с самого начала.

2. Забывают про удаления. Битрикс через список отдаёт живые записи и молчит про удалённые. В витрине копятся мертвяки — сделки, которых уже нет. Нужна периодическая сверка по id: чего нет в Битриксе, то помечаем удалённым.

3. Резолвят словари построчно. На каждую сделку — отдельный запрос за именем менеджера. Тысяча сделок — тысяча лишних запросов. Кэш снимает вопрос.

4. Строят трансформации внутри Битрикса. Нагружают портал, упираются в лимит по времени, тормозят всех вокруг. Трансформации — в Postgres, Битрикс только отдаёт сырьё.

5. Пускают BI в сырые данные. Дашборд лезет в raw, аналитик видит кашу вместо витрины, а права на запись открывают дорогу к случайной порче.

Лимиты REST API.
Habr, «Как делать приложения и не сойти с ума».
Redsoft, подводные камни.
RDN, путеводитель по API.
Интерволга, полный гайд.

А вы как забираете данные из Битрикса — тянете батчами по расписанию или ловите изменения вебхуками на события? И где храните: Postgres, ClickHouse, что-то своё?

Делитесь в комментариях, интересно собрать разные подходы.

Подписывайтесь на мой телеграм-канал Data Дзен.