Модель ИИ хороша ровно настолько, насколько хороши данные, которые до неё реально доходят, а эти данные почти никогда не бывают с самого начала чистыми, централизованными или свежими. Обычно они разбросаны по CRM, нескольким SaaS-инструментам, паре баз данных и, вероятно, по таблице Excel, которую кто-то до сих пор пересылает по почте.

Превращение всего этого в форму, пригодную для использования ИИ-системой, — самостоятельная дисциплина, и эта категория только что пережила настоящую волну консолидации: два её крупнейших независимых игрока были поглощены более крупными компаниями с разницей в несколько месяцев. Это важно не только для закупок: когда инструмент, который доставляет ваши данные, и инструмент, который их преобразует, оказываются под одной крышей, вопрос о том, каким слоем управляет вендор, становится стратегическим для каждого покупателя. Вот десять платформ, которые реально перемещают данные внутри компаний сегодня, независимо или в составе крупных игроков.

Fivetran

Fivetran заработала репутацию на том, что полностью устранила боль из перемещения данных. Она предлагает автоматизированные пайплайны, собирающие данные более чем из семисот источников, при этом изменения схемы обрабатываются автоматически, а не ломают пайплайн при каждом изменении поля в исходном приложении.

Платформа полностью управляемая, и именно это привлекает команды, у которых нет выделенных инженеров данных для присмотра за самописными скриптами. Это удобство имеет реальную цену: тарификация по использованию, привязанная к ежемесячным активным строкам, может быстро расти с увеличением объёма данных, а изменение тарификации в 2026 году добавило выставление счетов на уровне подключений.

Главная новость — с кем Fivetran объединилась в октябре 2025 года: сделка полностью на акции с dbt Labs объединила две компании с примерно 600 миллионами долларов годовой регулярной выручки, фактически объединив слой инжестии и слой трансформации в рамках отношений с одним вендором. Стоит следить, сохранит ли объединённая компания одинаковую открытость обоих продуктов к конкурирующим стекам, поскольку значительная часть их исторической клиентской базы комбинирует инструменты разных вендоров.

dbt Labs (dbt)

dbt занимает узкую нишу в этом стеке и почти определяется тем, чего он сознательно не делает: он вообще не умеет перемещать данные. Это инструмент трансформации, а не ETL-инструмент, то есть ему всегда нужен отдельный слой инжестии, например Fivetran или Airbyte, чтобы загрузить сырые данные в хранилище, прежде чем моделирование на основе SQL и Jinja в dbt сможет с ними работать.

То, что он делает, он делает хорошо: контролируемая версиями, протестированная и задокументированная логика трансформации, которая обеспечивает согласованность метрик во всех последующих BI-инструментах. Это чрезвычайно важно, когда ИИ-приложение начинает обращаться к тому же хранилищу и исходные числа должны означать одно и то же везде.

После слияния с Fivetran клиенты фактически получают отношения с одним вендором вместо двух контрактов — реальное упрощение для команд, которые и так использовали их вместе.

Airbyte

Airbyte сделала противоположную ставку по сравнению с Fivetran. Вместо полностью управляемого «чёрного ящика» она создала open-source ELT-платформу с огромным каталогом коннекторов, поддерживаемых сообществом, позволяя командам самостоятельно размещать её бесплатно и платить только за собственную инфраструктуру, а не за лицензию вендора за каждую строку.

Эта открытость по-настоящему привлекает инженерные организации, которым нужен полный контроль над пайплайнами и отсутствие привязки к дорожной карте одного вендора — соображение, ставшее более острым на фоне консолидации конкурентов. Недавно Airbyte добавила ИИ-ассистированный конструктор коннекторов, ускоряющий покрытие источников, которых пока нет в каталоге.

Компромисс ровно тот, которого можно ожидать от open-source-инфраструктуры: качество коннекторов различается, особенно для интеграций, поддерживаемых сообществом, а качественная эксплуатация требует реальных усилий DevOps, которые полностью управляемая платформа взяла бы на себя.

Informatica (IDMC)

Informatica уже около двух десятилетий остаётся корпоративным стандартом для действительно сложных сред данных, и её Intelligent Data Management Cloud по-прежнему охватывает весь диапазон, за который большинство конкурентов даже не берётся: интеграцию, качество данных, управление (governance) и управление мастер-данными в одной платформе, а её ИИ-движок CLAIRE отвечает за обнаружение метаданных по всей этой системе.

Более крупная новость носит структурный, а не технический характер: Salesforce приобрела Informatica в сделке на 8 миллиардов долларов, закрытой в конце 2025 года, и теперь это полностью принадлежащая ей дочерняя компания, а не независимая публичная компания.

Базовый продукт пока не изменился, но долгосрочный вопрос, который теперь должен задать каждый покупатель: продолжит ли Salesforce приоритизировать функции для клиентов вне экосистемы Salesforce или будет постепенно смещать дорожную карту в сторону собственных амбиций Data Cloud и Agentforce. То, как будет развиваться эта дорожная карта, также станет ранним сигналом того, как более широкий стек данных будет консолидироваться вокруг крупнейших ИИ-платформенных вендоров.

MuleSoft

MuleSoft занимает сторону этой категории, ориентированную на API, а не на инжестию в хранилища. Это интеграционное ядро Salesforce, обслуживающее очень крупную базу клиентов Salesforce, которым нужно связывать десятки систем через переиспользуемые, управляемые API, а не разовые точечные подключения.

Его язык трансформации DataWeave выполняет собственно манипуляции с данными, а недавно добавлена поддержка протокола Model Context Protocol, что позиционирует MuleSoft как инфраструктуру, в которую агentic-ИИ-процессы могут обращаться напрямую, а не только как инструмент интеграции для людей.

Для организаций, уже глубоко встроенных в экосистему Salesforce, такое позиционирование — естественное совпадение, а с учётом того, что Informatica теперь также принадлежит Salesforce, компания фактически владеет двумя смежными слоями рынка интеграции данных. Для компаний вне этой экосистемы корпоративные тарифы MuleSoft и сроки внедрения обосновать гораздо сложнее.

Databricks

Databricks выстроила всю свою архитектуру на иной предпосылке, нежели традиционные ETL-вендоры. Это lakehouse, объединяющий разработку данных, аналитику и машинное обучение в одной платформе, а не рассматривающий «подготовку данных» и «построение ИИ поверх них» как две отдельные системы, требующие собственного слоя интеграции между ними.

Это всё важнее именно для ИИ-приложений, поскольку пайплайну обучения или инференса модели часто нужны одни и те же управляемые данные и для аналитики, и для самой ИИ-нагрузки, а их синхронизация между двумя несвязанными платформами — регулярно повторяющаяся проблема.

Внедрять её тяжелее, чем точечный ELT-инструмент, но для организаций, уже выполняющих серьёзные ML-нагрузки, совместное использование платформы слоем данных и слоем ИИ устраняет целый класс проблем синхронизации.

Snowflake

Ключевое предложение Snowflake всегда заключалось в по-настоящему эластичном, отдельно масштабируемом хранилище данных, а её слой Cortex AI строится прямо поверх тех же управляемых данных, без отдельного шага экспорта, прежде чем ИИ-приложение сможет их запрашивать.

Это важно по той же причине, что и унифицированная архитектура Databricks: каждый дополнительный переход данных между «хранилищем» и «ИИ-системой» — ещё одно место, где могут возникнуть устаревание данных, несоответствие прав доступа или простой дрейф данных.

Snowflake и Databricks всё чаще конкуруют лоб в лоб именно с этим предложением, и для большинства покупателей выбор сводится скорее к существующим облачным обязательствам и навыкам команды, чем к решающему разрыву в функциональности между ними.

Confluent

Confluent, построенная вокруг Apache Kafka, работает в совершенно ином темпе, чем ориентированные на пакеты инструменты выше: потоковая передача в реальном времени для ситуаций, когда ИИ-система действительно не может ждать ночного пакетного задания — например, обнаружение мошенничества или движки живых рекомендаций, которым нужно реагировать на событие за секунды, а не часы.

Эта основа реального времени стала более актуальной именно из-за ИИ-агентов, которым всё чаще нужно действовать на основе максимально свежего состояния системы, а не анализировать вчерашний снимок.

Это более тяжёлое операционное обязательство, чем управляемый ELT-инструмент, и явный перебор для компании, которой нужны лишь ночные отчёты, но для задачи передачи ИИ-системе данных возрастом в секунды, а не в день, реальной альтернативы нет.

Matillion

Matillion выстроила свою нишу вокруг команд, работающих внутри одного из крупных облачных хранилищ — Snowflake, BigQuery или Redshift, — предлагая более визуальный ETL/ELT-опыт с перетаскиванием вместо написания кода пайплайнов, при этом тяжёлая работа по трансформации по-прежнему выполняется вычислительными ресурсами самого хранилища, а не промежуточным движком.

Эта ориентация на хранилище и есть ключевое отличие от более источнико-независимых инструментов вроде Fivetran или Airbyte: сильные стороны Matillion проявляются, когда организация уже стандартизирована на одном из этих трёх хранилищ и хочет более доступный интерфейс для логики трансформации поверх него.

Estuary

Estuary делает действительно иную архитектурную ставку, чем большинство названий в этом списке. Вместо того чтобы считать пакетный ELT и потоковую передачу в реальном времени двумя отдельными категориями, требующими двух инструментов, Estuary создала единую платформу, обрабатывающую change-data-capture и пакетную репликацию в одной системе, стремясь к свежести данных менее секунды без операционных издержек развертывания полноценного Kafka-кластера ради этой цели.

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

В совокупности сквозная линия этого списка в том, что выбор инфраструктуры данных всё больше следует за ИИ-стратегией: консолидируется ли компания на стеке одного вендора или собирает лучшие слои по отдельности, именно интерфейсы между инжестией, трансформацией, хранением и ИИ — то место, где сейчас сосредоточены и основная активность консолидации, и основной риск покупателя.

Статья 10 Enterprise Data Platforms Supporting AI And Analytics впервые появилась на Metaverse Post.