Поделиться через


Сценарий Adatum Corporation для облачной аналитики в Azure

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

Профиль клиента

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

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

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

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

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

Текущая ситуация

Группа корпоративных продаж Adatum использует традиционные системы ERP и CRM для обработки своих транзакций по продажам. Данные из этих систем необходимо экспортировать в отдельную платформу аналитики, чтобы заинтересованные лица в организации могли получить доступ к данным и обогатить их для различных проектов.

Архитектурное решение

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

Посадочная зона управления данными

Важной концепцией для каждой облачной аналитики является одна целевая зона управления данными. Эта подписка содержит ресурсы, общие для всех целевых зон и включают общие сетевые компоненты, такие как брандмауэр и частные зоны DNS. Она также включает ресурсы для управления данными и облаком. Каталог Microsoft Purview и Databricks Unity развертываются как службы на уровне клиента.

Приложения данных

Посадочная площадка имеет два приложения данных . Первая интеграция обрабатывает данные о клиентах. Этот шаг включает записи клиентов и связанные с ними записи (например, адреса, контакты, назначения территорий и журнал контактов). Эти данные импортируются из системы Adatum CRM.

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

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

Продукты данных

В этом примере Adatum имеет один продукт данных. Этот продукт объединяет необработанные данные из двух приложений данных и преобразует их в новый набор данных. Оттуда он может быть выбран бизнес-пользователями для дополнительного анализа и создания отчетов с такими инструментами, как Microsoft Power BI.

схема архитектуры Adatum.

Рис. 1. Схема архитектуры. На схеме представлены не все службы Azure. Это упрощено, чтобы выделить основные понятия о том, как ресурсы организованы в архитектуре.

Логическое обоснование

Почему бы не поместить транзакции продаж и клиентов в собственные целевые зоны данных?

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

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

Почему не разрешать транзакциям продаж и клиентам совместно использовать одно приложение данных?

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

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

Почему группа продаж перемещается на новую платформу данных?

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

Как развиваться в будущем?

Масштабирование выполняется путем добавления новых зон приземления в архитектуру. Эти зоны высадки используют пиринг виртуальных сетей для подключения к зоне управления данными и всем другим зонам высадки. Этот шаблон сетки позволяет предоставлять доступ к продуктам и ресурсам данных между зонами. Разделяя на различные зоны, нагрузки распределяются по подпискам и ресурсам Azure. Этот шаг позволяет предприятиям избежать достижения ограничений служб Azure и продолжать развивать свои массивы данных.

Дальнейшие действия

Перейдите к сценарию Relecloud для облачной аналитики в Azure.

Дополнительные сведения см. в следующем разделе: