ETL или ELT — это вопрос о порядке действий при сборе данных. В ETL данные сначала извлекаются из источника, приводятся к нужному виду и только потом загружаются в хранилище. В ELT они загружаются как есть, а преобразуются уже внутри хранилища. Для компании среднего размера с CRM, 1С, сайтом и рекламой на практике важнее другой выбор: готовые коннекторы, конструктор интеграций или своя интеграция. От него зависят цена, надёжность и то, насколько вы привязаны к стороннему сервису.
ETL: что это и как работает
ETL расшифровывается как Extract, Transform, Load — извлечь, преобразовать, загрузить. Процесс забирает данные из источника по расписанию или по событию, чистит и приводит их к единой модели и складывает в хранилище уже готовыми к отчётам.
На этапе преобразования происходит самое ценное: телефон приводится к единому формату, «ТОО Ромашка» и «Ромашка ТОО» становятся одним контрагентом, «Город» из CRM и «Регион» из 1С сводятся к одному справочнику, дубли склеиваются по телефону, почте и ИИН/БИН. В хранилище попадают только согласованные данные, и BI строит отчёт за минуты.
Минус классического ETL — жёсткость. Если в модели не предусмотрено какое-то поле, его нет в хранилище, и чтобы добавить новый разрез, нужно менять правила загрузки и иногда перезагружать историю.
Отдельный вопрос — как часто запускать загрузку. Расписание раз в сутки подходит для утреннего отчёта собственника, а для контроля заявок нужна загрузка в реальном времени. Обычно мы комбинируем: заявки, звонки и чаты попадают в хранилище сразу, а 1С и рекламные кабинеты — по расписанию от 15 минут. Чем чаще обновление, тем выше нагрузка на источники и требования к инфраструктуре, поэтому режим подбирают под конкретный отчёт, а не «на всякий случай» для всех данных.
ELT: загрузить сначала, преобразовать потом
ELT меняет порядок: Extract, Load, Transform. Данные из источников загружаются в хранилище практически в исходном виде, а преобразования выполняются внутри — SQL-запросами, представлениями, витринами. Подход стал популярным вместе с быстрыми аналитическими базами, которые легко переваривают большие объёмы сырых данных.
Плюс ELT — гибкость: сырые данные уже лежат в хранилище, и новый показатель можно посчитать без повторной загрузки. Минус — порядок в данных не появляется сам собой. Если преобразования никто не спроектировал, хранилище превращается в склад выгрузок, где каждый аналитик считает выручку по-своему.
| Критерий | ETL | ELT |
|---|---|---|
| Где преобразуются данные | До загрузки, в процессе обмена | Внутри хранилища |
| Что лежит в хранилище | Чистые, согласованные данные | Сырые данные плюс витрины поверх них |
| Гибкость для новых отчётов | Ниже: нужно менять правила загрузки | Выше: новый расчёт поверх сырых данных |
| Требования к хранилищу | Умеренные | Выше: хранится больше данных |
| Риск хаоса | Ниже | Выше без дисциплины в моделировании |
ПРАВИЛОСпор ETL или ELT решается не технологией, а моделью данных. Если определено, что такое заявка, сделка и клиент, работают оба подхода. Если нет — не работает ни один.
На практике мы почти всегда используем гибрид. Сырые данные из источников загружаются в хранилище на PostgreSQL или ClickHouse с историей изменений, а склейка, справочники и витрины для отчётов строятся по единой модели. Так новые разрезы добавляются без перезагрузки, а цифры у всех отделов совпадают. Подробно, как это устроено, описано на странице объединения данных в единое хранилище.
ETL-инструменты: три способа собирать данные
Готовые облачные коннекторы
Сервисы, которые по подписке забирают данные из популярных систем — рекламных кабинетов, аналитики, CRM — и складывают их в ваше хранилище. Запуск быстрый, программировать не нужно. Ограничения: каталог коннекторов ориентирован на международные сервисы, и 1С, локальной телефонии или казахстанских платёжных систем в нём часто нет. Стоимость обычно растёт с объёмом данных, а логика загрузки остаётся у вендора.
Конструкторы интеграций
Albato, Make и похожие сервисы хорошо связывают системы между собой: заявка из формы — в CRM, сделка — в таблицу. Для аналитического хранилища они подходят хуже: нет истории изменений, сложно загружать большие объёмы истории и строить справочники. Плюсы и минусы конструкторов для операционных задач мы разобрали в статье «Готовый коннектор, Albato/Make или своя интеграция».
Своя интеграция
Коннекторы, которые пишутся под ваши системы и складывают данные в ваше хранилище. Дороже на старте, но без абонентской платы за объём, без зависимости от каталога сервиса и с полным контролем над логикой. Если у системы есть API, база или хотя бы выгрузка в файл, её можно подключить.
- Быстрый запуск без разработки
- Хорошо работают с популярными зарубежными сервисами
- Подписка растёт с объёмом данных
- 1С и локальные системы часто не поддерживаются
- Любые источники, включая 1С и самописные системы
- Нет абонентской платы за объём
- Логика и данные под вашим контролем
- Дольше и дороже на старте
Надёжность и зависимость от сервиса
Выбор подхода — это ещё и вопрос о том, что будет при сбое. Источник перестал отвечать, поменялся API рекламного кабинета, в CRM добавили обязательное поле. В хорошей интеграции такие ситуации предусмотрены: очереди с повторами, идемпотентные операции, журнал событий, алерты. Данные ждут, а не пропадают, и после восстановления пропущенное догружается.
У готового сервиса эти механизмы есть в том объёме, в каком их сделал вендор. Если коннектор сломался после обновления источника, вы ждёте исправления. Если сервис изменил тарифы или ушёл с рынка, интеграцию придётся строить заново. Для отчёта по рекламе это неприятно, для управленческой отчётности, на которую опирается собственник, — критично.
Своя интеграция тоже не страхует сама по себе — её надёжность зависит от того, заложены ли мониторинг и документация. Мы включаем мониторинг обмена и качества данных в состав работ и передаём документацию по модели и коннекторам, чтобы сопровождать хранилище мог ваш аналитик или любой другой подрядчик.
Проверять только факт обмена. Обмен может «пройти», но принести половину записей: сменилась пагинация API, истёк токен на одном из кабинетов. Проверяйте ещё и объём: если записей пришло подозрительно мало, это такой же сигнал, как полный сбой.
Коннекторы для сбора данных: что проверить перед выбором
- Поддерживаются ли все ваши источники, включая 1С и телефонию
- Можно ли загрузить историю за прошлые годы, а не только новые данные
- Есть ли инкрементальная загрузка, чтобы не перекачивать всё каждый раз
- Что происходит при сбое: очередь, повтор, алерт
- Где физически хранятся данные и можно ли держать их в Казахстане
- Как растёт стоимость при увеличении объёма и числа источников
- Кому принадлежит логика преобразований и можно ли её забрать
Что выбрать под объём и источники компании
Маркетинговая отчётность на данных Google и рекламы. Хватит готовых коннекторов или нативных подключений BI-платформы. Своя разработка здесь избыточна.
CRM, сайт и телефония. Нужна склейка клиентов и единая карточка — это уже хранилище с моделью. Базовый формат объединения трёх источников у нас — от 500 000 ₸ за 3 недели.
1С, несколько CRM, реклама, история за годы. Хранилище с гибридным подходом и своими коннекторами. С 1С и рекламой — от 900 000 ₸ за 4–5 недель, корпоративное хранилище на 10+ систем — от 2 000 000 ₸. Подробная раскладка бюджета — в статье «Сколько стоит объединить данные CRM, 1С и сайта».
Старая ERP, банк-клиент, отраслевое ПО без API. Сначала нужен коннектор к самой системе. Это задача разработки API и нестандартных интеграций: коннектор между двумя системами — от 400 000 ₸, шина данных на 3–5 систем — от 900 000 ₸. Потом данные идут в хранилище по общей схеме.
Как начать без лишних вложений
Начните с аудита: какие системы, какие поля, сколько дублей, кто источник истины по клиентам, товарам и оплатам. Это неделя работы, и по её итогам становится понятно, какие источники закрываются готовыми средствами, а где нужна своя интеграция. Затем подключите три главных источника и получите единую карточку клиента, а остальные добавляйте этапами — модель данных с самого начала проектируется с учётом будущих систем. Ориентиры по ценам на аналитические работы — на странице цен на бизнес-аналитику, а смету на сбор данных в единое хранилище пришлём за один рабочий день.
ETL — что это простыми словами?
Автоматический процесс: забрать данные из источника, привести к единой модели и положить в хранилище. Заменяет ручные выгрузки и работает по расписанию или в реальном времени.
Чем ETL отличается от ELT?
В ETL данные преобразуются до загрузки в хранилище, в ELT — после, уже внутри хранилища. ELT гибче для новых отчётов, ETL даёт более строгий порядок в данных.
Какие ETL-инструменты подходят для 1С?
Готовые облачные коннекторы 1С поддерживают редко, поэтому обычно используется своя интеграция, которая забирает контрагентов, заказы, оплаты и товары по расписанию.
Можно ли обойтись Albato или Make вместо хранилища?
Для передачи заявок между системами — да. Для аналитики с историей, справочниками и большими объёмами лучше хранилище с ETL.