Архитектуры корпоративных данных редко используются в одной системе. Salesforce управляет взаимодействием по вовлечению клиентов, ожидаемым продажам и обслуживанию. Аналитические платформы, например, Snowflake, хранят архивные транзакции, финансовые записи, данные об использовании и операционные показатели. Традиционно соединение этих двух миров означало строительство и обслуживание трубопроводов ETL: запланированные задания, которые извлекают данные из источника, трансформируют их и загружают копии в Salesforce. В результате этих ожидаемых продаж данные поступают с задержкой, политики управления множатся в разных системах, а ожидаемые продажи требуют постоянного оперативного ухода.

Salesforce Data Virtualization предлагает другую модель. Вместо переноса данных в Salesforce система позволяет Salesforce запрашивать данные напрямую в источнике, во время выполнения, без репликации. Пользователи видят оперативные внешние данные посредством стандартных интерфейсов Salesforce. Данные не покидают своего авторитетного дома. Данный документ объясняет, как работает схема, когда ее использовать и как начать работу, используя Snowflake в качестве конкретного отработанного примера.

Salesforce Data Virtualization - это схема архитектуры интеграции, которая позволяет Salesforce запрашивать данные напрямую из внешних систем во время выполнения, не копируя и не реплицируя эти данные в хранилище Salesforce. Вместо перемещения данных платформа отправляет запрос.

Таким образом, пользователи Salesforce взаимодействуют с внешними данными посредством привычных интерфейсов Salesforce (например, макеты страниц, связанные списки, отчеты или потоки), в то время как данные остаются в авторитетной исходной системе. Управление, контроль доступа и резидентство данных остаются на своих местах.

Эта схема построена на едином архитектурном принципе: данные остаются в источнике. Вычисления перемещаются в данные.

Большинство корпоративных развертываний Salesforce интегрируются во внешние платформы данных (например, хранилища данных, операционные базы данных или аналитические магазины) посредством ожидаемых продаж репликации. Конвейеры извлекают, трансформируют и загружают данные в Salesforce по расписанию. Этот метод работает, но репликация вносит структурные преимущества:

• Воспроизводимые данные всегда задерживаются. Конвейеры внедряют задержки и устаревшие данные приводят к неправильным решениям.
• Каждая копия данных расширяет область соответствия. Конфиденциальные данные (например, персональные данные, финансовые записи или данные о здоровье) в нескольких системах требуют сохранения нескольких политик управления.
• Конвейеры требуют постоянных операционных инвестиций, мониторинга, обработки сбоев, управления отклонением схемы и логики повторной обработки.

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

Salesforce Connect - это возможность платформы, которая включает виртуализацию данных в Salesforce. Он предоставляет инфраструктуру адаптера, которая переводит запросы SOQL на язык запросов внешней системы, управляет проверенными выносками и соотносит наборы результатов с типами полей Salesforce. Он поддерживает внешние объекты, конструкцию метаданных Salesforce, которая отображает внешние данные в качестве запрашиваемых объектов платформы без репликации данных в хранилище Salesforce. Внешние объекты действуют как стандартные объекты Salesforce, отображаемые в макетах страниц, связанных списках и отчетах и доступные посредством SOQL и стандартных API, но не содержат данных. Внешние объекты - это проекция схемы над исходной системой.

Внешние объекты - это основной механизм, посредством которого виртуализация данных отображает внешние данные в Salesforce. Они действуют как стандартные объекты Salesforce: запрос посредством SOQL, доступный в макетах страниц и связанных списках и доступный посредством стандартных Salesforce API. Ключевым отличием является отсутствие данных в Salesforce. Внешний объект является проекцией схемы: определение внешнего вида внешних данных, а не копия самих данных.

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

Когда Salesforce выполняет запрос SOQL к внешнему объекту, он переводит фильтры (условия WHERE), порядки сортировки (ПОРЯДОК ОТ) и ограничения (LIMIT) в эквивалентный SQL и отправляет их во внешнюю систему. Внешняя система выполняет запрос в собственном вычислительном механизме и возвращает только отфильтрованный набор результатов. Работа происходит там, где живут данные, и только ответ возвращается в Salesforce.

Виртуализация данных внедряет два независимых уровня безопасности одновременно. Внешняя система применяет собственные средства управления доступом во время выполнения запроса, включительно с безопасностью строки, маскировкой столбцов и доступом на основе роли. Salesforce применяет собственную модель безопасности сверху: профили, наборы полномочий, безопасность поля и правила общего доступа. Оба слоя активны в каждом запросе. Ни один из них не заменяет другой.

Архитекторы часто описывают виртуализацию данных как схему с «нулевой копией». Нулевая копия означает отсутствие постоянной репликации в хранилище Salesforce. Конвейеры ETL не записывают записи в объекты Salesforce. Нет запланированной синхронизации, создающей локальную копию. Внешний объект не содержит строк.

Нулевая копия не означает нулевой передачи данных. При каждом запросе внешнего объекта набор результатов перемещается из внешней системы в Salesforce по сети. Для больших наборов результатов или высокой частоты запросов стоимость выхода данных и сетевая задержка являются реальными факторами для проектирования архитекторами. Это не является ограничением для сокрытия: это является конструктивным ограничением для учета.

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

Snowflake - одна из самых распространенных внешних систем, подключенных к Salesforce посредством виртуализации данных. Он служит конкретным примером работы схемы от конца до конца.

В этой конфигурации Salesforce подключается к Snowflake посредством Salesforce Connect с адаптером SQL для Snowflake. Таблицы и представления Snowflake отображаются в Salesforce как внешние объекты. Когда пользователь запрашивает внешний объект, Salesforce переводит SOQL на SQL и отправляет его в Snowflake Statements API посредством проверенной выноски HTTPS. Snowflake выполняет запрос на виртуальном складе, применяет собственную безопасность строки и маскировку столбцов и возвращает только набор результатов. Данные не записываются в хранилище Salesforce.

Salesforce Connect использует делегированную модель OAuth 2.0 для проверки подлинности посредством Snowflake. Ключевыми компонентами являются:

• Поставщик проверки подлинности: Управление рукопожатием OAuth с помощью Snowflake. Обрабатывает запросы маркеров и соотносит возвращенный маркер с регистрационными данными Salesforce.
• Внешние регистрационные данные: Безопасно удерживает маркеры доступа и обновления OAuth в хранилище зашифрованных регистрационных данных Salesforce и внедряет их в исходящие выноски.
• Именованные регистрационные данные: Определяет URL-адрес конечной точки Snowflake и ссылается на внешние регистрационные данные.
• Интеграция безопасности Snowflake: Регистрирует Salesforce в качестве надежного клиента OAuth в Snowflake. Определяет разрешенный URI-адрес переадресации, потоки OAuth и TTL маркера.

Данные компоненты образуют цепочку зависимости: Внешний источник данных ссылается на именованные регистрационные данные, которые ссылаются на внешние регистрационные данные, которые ссылаются на поставщика проверки подлинности. Понимание этой цепочки необходимо при устранении неполадок подключения или сбоев доступа.

Salesforce поддерживает две модели делегирования удостоверений при проверке подлинности посредством Snowflake:

• Названный субъект: Одна общедоступная организация службы проверяет подлинность всех пользователей Salesforce по Snowflake. Это проще настроить, но не имеет возможности проверки на пользователя или точного контроля доступа Snowflake.
• Принципал пользователя: Каждый пользователь Salesforce проходит проверку подлинности с помощью собственного маркера OAuth. Это включает безопасность строки Snowflake и полный контрольный журнал для каждого пользователя, с компромиссом более высокого управления маркерами (потоки OAuth для каждого пользователя, обновление, отзыв).

Рекомендации по принятию решения: Используйте «На пользователя» для регламентированных данных или персональных данных (PII). Используйте «Названный субъект», если правила общего доступа Salesforce предоставляют достаточный контроль доступа и простота является приоритетом.

Ниже перечислены контролирующие ограничения Salesforce, которые напрямую определяют дизайн решения при использовании внешних объектов в Snowflake:

• Ограничение выноски: 100 на транзакцию Apex. Страницы или потоки с несколькими запросами внешних объектов могут быстро достичь этого ограничения.
• Время ожидания выноски: Максимум 120 секунд. Долговременные запросы Snowflake приводят к исключению среды выполнения.
• Ограничение строк SOQL: 50 000 строк. Пагинация больших наборов результатов.
• Ограничения асинхронизации: Пакетный Apex и большинство асинхронных контекстов ограничивают выноски. Поддерживайте доступ к внешнему объекту в пределах синхронных границ транзакций. Для сценариев асинхронного использования, запрашивающих внешние объекты, рассмотрите выноски продолжения для инициированных пользователем асинхронных взаимодействий или создайте поток для выполнения доступа к внешним данным в синхронной транзакции и передачи результатов асинхронно.

Рекомендации по проектированию: Не запрашивайте внешние объекты в циклах. Нажмите фильтрацию условия WHERE в Snowflake, чтобы уменьшить размер результата и частоту выноски.

Каждый запрос, отправляемый Salesforce в Snowflake, регистрируется в журнале запросов Snowflake с полными метаданными выполнения: задержка, сканирование строк, использование склада и удостоверение исполнителя. Этот журнал предоставляет комплексную возможность проверки от действия пользователя Salesforce до выполнения Snowflake и является основным инструментом диагностики для настройки производительности и проверки доступа.

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

Используйте его, когда:

• Главным требованием является аналитический доступ с высокой степенью чтения. Если пользователям нужно запросить и отобразить внешние данные в пользовательских интерфейсах Salesforce, отчетах или потоках без обратной записи, виртуализация данных исключает накладные расходы ожидаемых продаж для сценариев только для чтения.
• Свежесть данных очень важна. Если устаревшие реплицированные данные создают бизнес-риск (например, устаревшие финансовые балансы, уровни запаса или статус соответствия), интегрированная модель гарантирует отображение оперативных данных в каждом запросе.
• Требования к управлению и резидентству данных строгие. Если нормативные или договорные ограничения запрещают копирование конфиденциальных данных в Salesforce, виртуализация сохраняет данные в их авторитетном расположении, делая их доступными в Salesforce. Данные хранятся только в одной системе.
• Необходим двухуровневый контроль доступа. Если одновременно применяются как собственные средства управления доступом внешней системы, так и модель безопасности Salesforce, федеративная модель применяет оба средства без дублирования данных.
• Внешняя система уже является авторитетной системой записи. Если данные уже чистые, управляемые и запрашиваемые в исходной системе, их виртуализация позволяет избежать лишней трансформации, стоимости хранения и риска расхождения.

Избегайте этого, если:

• Требуются записи с низкой задержкой. Внешние объекты доступны только для чтения. Сценарии использования обратной записи требуют другой схемы интеграции.
• Требуются сложные многообъектные объединения. SOQL в нескольких внешних объектах не поддерживает присоединения. Предварительно материализуйте составные данные как единое представление в исходной системе.
• Для функций Salesforce AI или Agentforce требуются собственные данные. В настоящее время функции Einstein и Agentforce (включая заземление для Einstein Copilot, прогнозирование рейтингов и действия Agentforce) работают над нативными объектами Salesforce. Эти функции не поддерживают внешние объекты в качестве источника данных заземления или активации. Если активация на основе искусственного интеллекта входит в область этих данных, Salesforce Data 360 является рекомендованным дополнительным решением.
• Высокочастотные схемы массового доступа. Внешние объекты созданы для доступа по запросу. Загруженность, которая запускает сотни запросов в минуту, истощает контролирующие ограничения и ухудшает производительность.

Следующие сценарии использования иллюстрируют, как виртуализация данных Salesforce применяется в общих сценариях предприятия. Каждый пример использует Snowflake в качестве внешней системы, но основная схема применяется к любому источнику данных, совместимому с SQL, поддерживаемому Salesforce Connect.

Вызов: Группы поддержки нуждались в объединенных отчетах, сочетающих данные обращений Salesforce с объемом билетов, временем решения и показателями расширения, сохраненными в Snowflake. Создание и обслуживание ожидаемых продаж репликации для этих данных внесло задержку и добавило операционные расходы для сценария использования отчетов только для чтения.

Решение: Группа предоставила представления Snowflake, содержащие показатели билетов в качестве внешних объектов в Salesforce. Группа настроила отчеты Salesforce на объединение собственных объектов обращений с внешними данными билетов.

Результат:

• Отчеты всегда отображают оперативные данные Snowflake. Отставания нет.
• Управление конфиденциальными показателями поддержки остается в Snowflake.
• Нет ожидаемых продаж ETL для создания, мониторинга или обслуживания.

Вызов: Финансовая группа вела авторитетные данные кредитного лимита и баланса в Snowflake. Репликация этих значений в Salesforce посредством обратного ETL ввела лаг репликации, заставив торговых представителей заключать сделки на основе устаревших кредитных сведений. Группа по соблюдению также отметила риск хранения конфиденциальных финансовых данных в хранилище Salesforce.

Решение: Группа виртуализировала финансовое представление Snowflake как внешний объект и отобразила его в макете страницы организации. Торговые представители теперь видят статус оперативного кредита как часть стандартного представления организации в Salesforce.

Результат:

• Кредитные данные в реальном времени на каждой странице организации. Нет задержек.
• Конвейеры обратного ETL исключены для финансовых данных.
• Конфиденциальные финансовые данные никогда не копировались в хранилище Salesforce. Область соответствия остается в Snowflake.

Вызов: Во время объединения компании-приобретения нужно было предоставить пользователям Salesforce доступ к операционным данным из 6 массовых наборов данных Snowflake, охватывающих транзакции, выставление счетов и использование. Репликация терабайт данных в Salesforce была нежизнеспособна на временной шкале слияния, и создание настраиваемых ожидаемых продаж ETL для каждого набора данных потребовало бы значительных инженерных инвестиций.

Решение: Группа настроила внешние объекты для всех 6 наборов данных Snowflake посредством Salesforce Connect с ролью интеграции с наименьшими правами. Настраиваемый код не требуется. Запросы выполняются напрямую в Snowflake, а все действия регистрируются в журнале запросов Snowflake для составления отчетов о соответствии.

Результат:

• Полностью декларативная конфигурация. Настраиваемый код или ожидаемые продажи не требуются.
• Свежесть данных гарантирована. Каждый запрос отображает оперативные данные Snowflake во время выполнения.
• Полный контрольный журнал в журнале запросов Snowflake для составления отчетов по регулированию и соответствию.

Виртуализация данных представляет отдельный операционный профиль. Создание для следующих сценариев сбоев:

• Истечение срока действия маркера OAuth: Маркеры имеют конечное время жизни (TTL). Просроченные маркеры приводят к ошибкам выноски. Отслеживайте наличие 401 неавторизованного ответа и внедряйте логику обновления.
• Холодный запуск склада (характеристика Snowflake): Автоматически подвешиваемые склады добавляют 5-30 секунд при первом запросе. Для сценариев использования, ориентированных на пользователя, с требованиями к задержке, предварительно согрейте запланированным облегченным запросом в рабочие часы.
• Несоответствие ролей: Некорректно настроенная роль во внешней системе может возвращать нулевые строки молча, а не ошибку. Проверьте привилегии между объектами во внешней системе независимо от Salesforce.
• Переполнение набора результатов: Негабаритные полезные данные превышают ограничения API. Всегда применяйте условия LIMIT и открывайте отфильтрованные представления, а не исходные таблицы.
• Отключение внешней системы: Резервная копия или кэш не существует. Завершите выноски в состояниях проб/выловов и поверхностных информативных ошибок в пользовательском интерфейсе. Для важных данных рекомендуем использовать многоуровневый подход: виртуализируются для доступа в режиме реального времени и поддерживают облегченную реплицированную резервную копию для самых важных полей, чтобы гарантировать доступность во время сбоев исходной системы.

Виртуализация данных Salesforce соответствует следующим компонентам инфраструктуры Salesforce.

• Trust: Делегированная модель OAuth 2.0 и рекомендации по ролям с наименьшими правами соответствуют Trust. Двухуровневое управление доступом (исходная система + Salesforce) обеспечивает глубокую защиту.
• Надежность (допустимые ошибки): Раздел режимов сбоя напрямую касается надежности: истечение срока действия маркера, холодный запуск, неправильная конфигурация роли, переполнение набора результатов и обработка отключения представляют собой отдельный класс сбоев с документированным путем разрешения.
• Надежность (масштабируемость): Выноска запроса, рекомендации по размеру склада и осведомленность об ограничении выноски оптимизируют эффективность выполнения в ограничениях управляющего Salesforce, что является проблемой надежности решений, работающих в большом масштабе.
• Оперативное совершенство: Журнал запросов Snowflake в качестве основного инструмента наблюдения поддерживает высокое качество работы: архитекторы делают обдуманный, отслеживаемый выбор в пользу использования нативного инструмента платформы для комплексной аудита и диагностики производительности, а не создания настраиваемой инфраструктуры регистрации.

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

Прежде чем начать работу по настройке, убедитесь в следующем.

• Право на лицензию: Salesforce Connect входит не во все версии Salesforce. Адаптер SQL для Snowflake требует отдельной дополнительной лицензии, выходящей за рамки базового права Salesforce Connect. Проверьте оба параметра в организации, прежде чем продолжить.
• Sandbox first: Выполните все этапы в безопасной среде, прежде чем продвигать конфигурацию в производственную.
• Доступ к Snowflake: Подтвердите наличие полномочия на создание интеграции безопасности в Snowflake и доступа к целевой базе данных, схеме и объектам.
• Версия адаптера: Убедитесь, что адаптер SQL для Snowflake доступен в версии вашей организации и что URL-адрес вашей организации Snowflake не содержит подчеркивания (замените дефисами, если они есть). Это ограничение платформы Salesforce для разрешения имени хоста выноски).

Настройка виртуализации данных посредством внешней системы SQL, например, Snowflake, является декларативным процессом, управляемым конфигурацией, не требующим настраиваемого кода. Настройка выполняется в три последовательных этапа: создание identity and Trust, настройка поверхности данных и предоставление данных конечным пользователям.

На этом этапе создается безопасная делегированная цепочка OAuth 2.0 Trust между Salesforce и внешней системой. Выполните этот этап перед началом настройки поверхности данных.

1. Создание поставщика проверки подлинности в Salesforce. Используйте тип OpenID Connect. Используйте значения структурного нуля на данном этапе — вернитесь для его выполнения после извлечения значений из внешней системы. После сохранения Salesforce создает URL-адрес обратного вызова. Сохраните это значение.
2. Регистрация Salesforce в качестве клиента OAuth во внешней системе. В Snowflake это означает создание интеграции безопасности (OAuth, тип конфиденциального клиента). Предоставьте URL-адрес обратного вызова Salesforce в качестве URI-адреса переадресации. Извлеките код клиента, секрет клиента, URL-адрес авторизации и URL-адрес маркера из интеграции после создания.
3. Завершите конфигурацию поставщика проверки подлинности. Вернитесь к поставщику проверки подлинности Salesforce и заполните его значениями, извлеченными из внешней системы: Ключ пользователя, секрет пользователя, URL-адрес авторизации и URL-адрес маркера.
4. Создание внешних регистрационных данных. Задайте протоколу значение OAuth 2.0, свяжите его с поставщиком проверки подлинности и добавьте субъект («Названный» или «На пользователя», в зависимости от решения модели удостоверения). Этот объект управляет жизненным циклом маркера OAuth.
5. Создание именованных регистрационных данных. Установите конечную точку на URL-адрес API внешней системы (например, https://<account>.snowflakecomputing.com/api/v2/statements/) и свяжите его с внешними регистрационными данными.
6. Предоставить профилю доступ к внешним регистрационным данным. Без этого шага пользователи не могут вызывать федеративные запросы, даже если все остальные конфигурации верны.
7. Запустите поток OAuth для завершения проверки подлинности. Запустите рукопожатие OAuth из Salesforce. Платформа перенаправляет на вход во внешнюю систему, проверяет регистрационные данные и безопасно сохраняет итоговые маркеры во внешних регистрационных данных. Этот шаг связывает контекст пользователя с действительным маркером. Все интегрированные запросы не выполняются до завершения этого этапа.

На этом этапе Salesforce подключается к схеме внешних данных и создает определения внешнего объекта, запрашиваемые пользователями и платформой.

1. Создание внешнего источника данных. Выберите соответствующий адаптер (например, адаптер SQL для Snowflake), укажите его на целевую базу данных и схему и свяжите с именованными регистрационными данными, созданными на этапе 1.
2. Проверьте подключение. Используйте встроенную проверку во внешнем источнике данных. Успешный результат подтверждает завершение цепочки OAuth Trust и доступность внешней системы.
3. Метаданные синхронизации. Запустите синхронизацию метаданных из внешнего источника данных. Salesforce интроспектирует целевую схему и создает определения внешних объектов, соотнося внешние столбцы с типами полей Salesforce.
4. Выберите и откройте нужные таблицы или представления. Выберите внешние таблицы или представления для отображения в качестве внешних объектов. Рекомендуем открывать не исходные таблицы, а рекомендованные представления. Просмотры позволяют предварительно фильтровать столбцы, ограничивать уровень строк и более жестко контролировать доступность слоя Salesforce.

Этот этап делает внешние объекты видимыми и доступными для использования конечными пользователями в Salesforce Lightning Experience.

1. Создание вкладок для внешних объектов. Вкладки делают внешние объекты напрямую доступными для навигации в приложениях Lightning.
2. Добавить внешние объекты в макеты страниц. Появите актуальные внешние данные вместе с собственными записями Salesforce (например, добавьте финансовое представление Snowflake в макет страницы организации).
3. Добавить в связанные списки. Добавьте «Внешние объекты» в связанные списки, чтобы предоставить пользователям объединенное представление собственных и внешних данных в контексте.
4. Проверка интегрирования запросов. Загрузите страницу или выполните запрос, ссылающийся на внешний объект. Потом просмотрите журнал запросов внешней системы (например, журнал запросов Snowflake), чтобы убедиться, что запрос выполнен в источнике. Убедитесь, что запрос выполнен правильно: роль, склад и удостоверение.

После завершения всех трех этапов пользователи Salesforce могут взаимодействовать с оперативными внешними данными посредством стандартных интерфейсов Salesforce, не зная, что данные поступают извне Salesforce.

Salesforce Data Virtualization заменяет интеграцию на основе репликации федерацией времени запроса. Данные остаются в авторитетном источнике; пользователи Salesforce взаимодействуют с ними посредством стандартных интерфейсов платформы. Нет ожидаемых продаж для создания, копии для управления и отставания для управления.

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

Snowflake хорошо иллюстрирует схему: управляемое интегрированное подключение с запросом времени, декларативно установленное без настраиваемого кода, наблюдаемое из конца в журнале запросов Snowflake и реализуемое посредством собственных средств контроля доступа Snowflake и полной модели безопасности Salesforce.

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

Югандхар Бора является архитектором программного обеспечения в Salesforce, специализируется на архитектуре данных в платформе приложений Data & Intelligence. Он руководит инициативами Совета по проверке архитектуры предприятия (EARB), сосредоточенными на управлении данными и объединенных моделях данных, одновременно внося вклад в автоматизированные решения инициализации платформы.