Большинство корпоративных данных не так уж сложно получить. Проблема лишь в том, что их копировали столько раз, что никто не уверен, какая версия является версией истины.
Каждая архитектурная схема рассказывает одну и ту же историю. Система учета слева. Уровень интеграции посередине. Хранилище, озеро данных, кэш, синхронизация, шина событий, хранилище признаков — справа. Каждый блок здесь не просто так. Каждый из них был правильным ответом на проблему в момент своего появления. И каждый из них теперь является местом, где данные должны поддерживаться в актуальном состоянии по отношению ко всем остальным местам.
Это и есть налог на копирование. Предприятия платят его уже десять лет, и большинство решило, что это оправданно, поскольку альтернативой было полное отсутствие аналитики. Бизнес-оркестрация и автоматизация меняют этот расчет. Как только данные начинают управлять исполнением задач агентами, роботами, рабочими процессами и приложениями — а не просто наполнять дашборды — стоимость устаревших данных начинает проявляться в самой работе, а не только в отчетности.
Почему модель «копирование и синхронизация» достигает своего предела
Модель копирования была создана для мира, где данные перемещались по расписанию. Каждую ночь процессы ETL (извлечение, преобразование и загрузка) наполняли хранилище. Почасовая синхронизация обновляла кэш. Еженедельные выгрузки наполняли озеро данных. Задержка измерялась часами и была допустимой, потому что потребителем данных был дашборд или отчет, а они обновляются по графику.
Агенты работают иначе. Агенты действуют.
Когда агент решает, одобрить ли счет, направить ли претензию, эскалировать ли тикет или рекомендовать кредитный лимит, он принимает решение, которое бизнес будет исполнять. Если данные, лежащие в основе этого решения, устарели на шесть часов, последствием будет не устаревший график. Последствием будет неверное действие — пропущенный срок оплаты, повторный возврат средств, отказ клиенту в услуге, на которую он на самом деле имеет право. Терпимость предприятия к задержкам ETL в аналитике исчезает в тот момент, когда данные начинают управлять исполнением.
Это и есть точка архитектурного напряжения. Тот же уровень данных, который успешно обслуживал отчетность, не может эффективно обслуживать агентов, роботов и рабочие процессы, воздействующие на бизнес в режиме, близком к реальному времени. Что-то должно измениться.
Что на самом деле означает «нулевое копирование»
Подключение с нулевым копированием — это архитектурная альтернатива перемещению данных каждый раз, когда они вам нужны. Вместо того чтобы реплицировать данные из источника в другую систему, уровень нулевого копирования объединяет запросы к источнику в момент их поступления. Данные остаются там, где они живут. Потребитель видит их так, как будто они локальны. Это отличается от функций клонирования и совместного использования с нулевым копированием внутри платформы: ничего не дублируется и не перемещается в UiPath.
Это не новая идея в инженерии данных. Новым является то, что она становится фундаментом для того, как корпоративная автоматизация получает доступ к данным, а не только для того, как аналитика делает к ним запросы.
В UiPath Data Fabric федеративные сущности являются примитивом нулевого копирования. Сущность указывает на «живую» внешнюю систему — Snowflake, Databricks, SAP, Salesforce, ServiceNow, операционную базу данных — и выполняет запросы к ней по требованию. В UiPath ничего не копируется. Сущность — это модель того, как данные структурированы и как они связаны с другими сущностями, а не дубликат самих данных.
А поскольку одна сущность может охватывать несколько исходных систем, агенты и средства автоматизации могут выполнять запросы к ним, не дожидаясь, пока кто-то консолидирует эти данные в одном месте.
Практический эффект заключается в том, что агент, рабочий процесс или приложение, запрашивающее сущность клиента, счета или заказа, считывает источник истины в данный момент. Не снимок. Не кэшированную копию. А текущее состояние.
Стоимость копирования в конкретных цифрах
Легко недооценить, во что на самом деле обходится предприятию модель копирования, поскольку расходы распределены между командами и бюджетами. Если собрать их вместе, они выглядят так:
- Накладные расходы на сверку. Каждая копия — это место, где данные могут разойтись. Команды создают конвейеры для обнаружения расхождений, задания для их исправления, дашборды для мониторинга и дежурства для реагирования на сбои.
Накладные расходы на сверку. Каждая копия — это место, где данные могут разойтись. Команды создают конвейеры для обнаружения расхождений, задания для их исправления, дашборды для мониторинга и дежурства для реагирования на сбои.
- Зона ответственности управления данными. Каждая копия — это еще одно место, где необходимо обеспечивать политику доступа, происхождение, хранение и аудит. Команду по комплаенсу неявно просят управлять N копиями одних и тех же данных, причем N постоянно растет.
Зона ответственности управления данными. Каждая копия — это еще одно место, где необходимо обеспечивать политику доступа, происхождение, хранение и аудит. Команду по комплаенсу неявно просят управлять N копиями одних и тех же данных, причем N постоянно растет.
- Перестройка интеграций. Каждый новый сценарий использования, требующий данных из системы, обычно приводит к созданию собственных соединений, преобразований и путей доступа. Одна и та же логика переписывается в разных проектах, потому что нет общей модели для использования.
Перестройка интеграций. Каждый новый сценарий использования, требующий данных из системы, обычно приводит к созданию собственных соединений, преобразований и путей доступа. Одна и та же логика переписывается в разных проектах, потому что нет общей модели для использования.
- Задержка, которую замечает бизнес. К тому времени, когда скопированные данные становятся достаточно актуальными для действий, момент для этих действий может быть упущен. Для аналитики это было неудобством. Для агентов — это режим отказа.
Задержка, которую замечает бизнес. К тому времени, когда скопированные данные становятся достаточно актуальными для действий, момент для этих действий может быть упущен. Для аналитики это было неудобством. Для агентов — это режим отказа.
Нулевое копирование устраняет источник этих затрат, а не просто смягчает их. Нет расхождений между источником и копией, если нет копии. Нет зоны ответственности управления для дубликата, которого не существует. Нет интеграций, которые нужно перестраивать, если каждый потребитель считывает данные из одной и той же федеративной сущности.
Роль UiPath в экосистеме нулевого копирования
Нулевое копирование — это не изобретение UiPath, и мы не пытаемся заменить платформы данных, которым уже доверяют предприятия. Snowflake и Databricks — это места, где современные предприятия консолидируют аналитику, ИИ и операционные данные. Они созданы для этой роли и отлично с ней справляются.
Чего не хватало предприятиям, так это уровня, который сделал бы данные в этих платформах — а также в SAP, Salesforce, ServiceNow и операционных базах данных — непосредственно пригодными для использования автоматизацией, управляющей бизнесом. Не через очередную копию. Не через очередную синхронизацию. А как управляемый, структурированный контекст, который агенты и рабочие процессы потребляют на месте, в «живом» режиме или режиме, близком к реальному времени.
Именно эту роль играет UiPath Data Fabric. Snowflake и Databricks остаются системами учета для данных, которые они содержат. UiPath становится уровнем контекста с нулевым копированием, который позволяет этим данным управлять исполнением задач агентами, оркестрацией, приложениями и средствами автоматизации на платформе UiPath.
Платформы данных хранят данные. Data Fabric делает их пригодными для автоматизации, которая управляет бизнесом — без их перемещения.
Что это означает для следующего поколения автоматизации
Агенты, которые будут работать на предприятии через два года, будут отличаться от тех, что создаются сегодня. Модели изменятся. Фреймворки изменятся. Коннекторы изменятся. Неизменными останутся данные и системы, в которых они хранятся.
Именно на это делается ставка при использовании уровня данных с нулевым копированием (zero-copy). Если данные остаются там, где они живут, и моделируются один раз как управляемые федеративные сущности, каждый агент, рабочий процесс и приложение, созданные с этого момента, будут использовать один и тот же доверенный контекст. Новые сценарии использования выстраиваются поверх того же фундамента, а не создаются заново. Платформы данных, в которые предприятия уже инвестировали, сохраняют свое место. «Налог на копирование» перестает расти.
Именно для этого и нужно нулевое копирование. Не для того, чтобы избежать перемещения данных как самоцели, а для того, чтобы обеспечить бизнес-оркестрацию и автоматизацию фундаментом данных, который выдерживает масштабы предприятия.
Узнайте, как UiPath Data Fabric применяет нулевое копирование на практике, предоставляя агентам управляемый контекст в режиме реального времени или почти в реальном времени по всем вашим корпоративным системам.
