Методология успеха реализации Synapse: оценка проекта рабочей области

Примечание.

Эта статья входит в серию статей, посвященных успешному внедрению Azure Synapse, предпосылки к которому закладываются изначально. Общие сведения о серии см. в статье "Внедрение Azure Synapse — успешно по умолчанию".

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

Проверка проекта рабочей области Synapse

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

Определите, какие элементы или службы в каждой рабочей области будут общими и с какими ресурсами. К ресурсам могут относиться озера данных, среды выполнения интеграции (IR), метаданные или конфигурации, а также код. Определите, почему был выбран именно этот проект с точки зрения потенциального взаимодействия. Спросите себя, оправдывает ли это взаимодействие дополнительные затраты и накладные расходы на управление.

Проверка проекта озера данных

Рекомендуется, чтобы озеро данных (если оно является частью решения) было правильно разделено на уровни. Озеро данных необходимо разделить на три основные области, связанные с наборами данных уровней Bronze, Silver и Gold. Уровень Bronze (или необработанный уровень) может находиться в отдельной учетной записи хранения, так как она имеет более строгие элементы управления доступом из-за немаскированных конфиденциальных данных, которые она может хранить.

Проверка проекта системы безопасности

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

Данные бессерверных пулов SQL и таблиц Apache Spark хранятся в контейнере Azure Data Lake 2-го поколения (ADLS Gen2), связанном с рабочей областью. Установленные пользователем библиотеки Apache Spark также управляются в этой же учетной записи хранения. Чтобы реализовать эти варианты использования, необходимо предоставить пользователям и MSI рабочей области доступ уровня Участник для данных BLOB-объектов хранилища к этому контейнеру хранилища ADLS 2-го поколения. Проверьте это требование на соответствие с требованиям безопасности.

Выделенные пулы SQL предоставляют широкий набор функций безопасности для шифрования и маскирования конфиденциальных данных. Выделенные и бессерверные пулы SQL обеспечивают полную область разрешений SQL Server, включая встроенные роли, определяемые пользователем роли, проверку подлинности SQL и проверку подлинности Microsoft Entra. Проверьте проект системы безопасности для выделенного пула SQL решения и данные и доступ к бессерверному пулу SQL.

Проверьте план безопасности для озера данных и всех учетных записей хранения ADLS 2-го поколения (и других), которые будут входить в решение Azure Synapse Analytics. Хранилище ADLS 2-го поколения не является системой вычислений, поэтому у него нет встроенной возможности выборочно маскировать атрибуты данных. Разрешения ADLS 2-го поколения можно применять на уровне учетной записи хранения или контейнера с помощью управления доступом на основе ролей (RBAC) и (или) на уровне папки или файла с помощью списков управления доступом (ACL). Тщательно проверьте проект и старайтесь избежать ненужных сложностей.

Ниже приведены некоторые моменты, которые следует учитывать при проектировании системы безопасности.

• Убедитесь, что требования к настройке идентификатора Microsoft Entra включены в проект.
• Проверьте наличие межклиентских сценариев. Такие проблемы могут возникнуть из-за того, что некоторые данные находятся в другом клиенте Azure, или их необходимо переместить в другой клиент, или они должны быть доступны пользователям из другого клиента. Убедитесь, что эти сценарии учитываются при проектировании.
• Какие роли существуют для каждой рабочей области? Как они будут использовать рабочую область?
• Каким образом обеспечивается безопасность в рабочей области?
  • Кто может просматривать все скрипты, записные книжки и конвейеры?
  • Кто может выполнять скрипты и конвейеры?
  • Кто может создавать, приостанавливать и возобновлять работу пулов SQL и Spark?
  • Кто может публиковать изменения в рабочую область?
  • Кто может фиксировать изменения в системе управления версиями?
• Будут ли конвейеры получать доступ к данным с помощью сохраненных учетных данных или управляемого удостоверения рабочей области?
• Есть ли у пользователей соответствующие права доступа к озеру данных для просмотра данных в Synapse Studio?
• Защищено озеро данных надлежащим образом с помощью соответствующего сочетания RBAC и списков управления доступом?
• Правильно ли заданы разрешения пользователей пула SQL для каждой роли (специалиста по обработке и анализу данных, разработчика, администратора, бизнес-пользователя и других пользователей)?

Проверка проекта сети

Ниже приведены некоторые моменты, которые следует учитывать при проектировании сети.

• Разработано ли подключение между всеми ресурсами?
• Какой сетевой механизм используется (Azure ExpressRoute, общедоступный Интернет или частные конечные точки)?
• Требуется ли безопасное подключение к Synapse Studio?
• Принята ли во внимание кража данных?
• Нужно ли подключаться к локальным источникам данных?
• Нужно ли подключаться к другим облачным источникам данных или системам вычислений, таким как Машинное обучение Azure?
• Проверены ли сетевые компоненты Azure, например группы безопасности сети (NSG), для обеспечения правильного подключения и перемещения данных?
• Учтена ли интеграция с частными зонами DNS?
• Вам требуется возможность просматривать озеро данных из Synapse Studio или просто запрашивать данные в озере данных с помощью бессерверного SQL или PolyBase?

Наконец, определите всех потребителей данных и убедитесь, что в проекте учитываются их возможности подключения. Убедитесь, что шлюзы сети и безопасности позволяют службе получать доступ к необходимым локальным источникам, и что поддерживаются ее протоколы и механизмы проверки подлинности. В некоторых сценариях может потребоваться несколько локальных сред IR или шлюзов данных для решений SaaS, таких как Microsoft Power BI.

Проверка проекта мониторинга

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

Ниже приведены некоторые моменты, которые следует учитывать при проектировании мониторинга.

• Кто может отслеживать каждый тип ресурса (конвейеры, пулы и др.)?
• Сколько времени необходимо хранить журналы действий базы данных?
• Что будет использоваться для рабочей области и хранения журналов базы данных: Log Analytics или служба хранилища Azure?
• Будут ли активироваться оповещения в случае ошибки конвейера? Если да, кто должен получать уведомления?
• На каком пороговом уровне пула SQL должно активироваться оповещение? Кто должен получать уведомления?

Проверка проекта системы управления версиями

По умолчанию рабочая область Synapse применяет изменения непосредственно к службе Synapse с помощью встроенной функции публикации. Вы можете включить интеграцию системы управления версиями, которая предоставляет множество преимуществ. В их число входят улучшенная совместная работа, управление версиями, утверждения и конвейеры выпуска для продвижения изменений в среды разработки, тестирования и производства. Azure Synapse позволяет использовать один репозиторий системы управления версиями для каждой рабочей области. Это может быть Azure DevOps Git или GitHub.

Ниже приведены некоторые моменты, которые следует учитывать при проектировании системы управления версиями.

• Если вы используете Azure DevOps Git, рабочая область Synapse и ее репозиторий находятся в одном клиенте?
• Кто сможет получать доступ к системе управления версиями?
• Какие разрешения будут предоставлены каждому пользователю в системе управления версиями?
• Разработана ли стратегия ветвления и объединения?
• Будут ли разработаны конвейеры выпуска для развертывания в разных средах?
• Будет ли использоваться процесс утверждения для объединения и для конвейеров выпуска?

Примечание.

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

Следующие шаги

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