Безопасность, доступ и операции для миграций Teradata
Эта статья — третья из семи публикаций, посвященных рекомендациям по переходу от Teradata к Azure Synapse Analytics. В центре внимания этой статьи — рекомендации по операциям безопасного доступа.
Вопросы безопасности
В этой статье рассматриваются методы подключения для существующих устаревших сред Teradata и способы их переноса в Azure Synapse Analytics с минимальным риском и воздействием на пользователей.
В этой статье предполагается, что вам требуется перенести существующие методы подключения, а также структуру пользователей, ролей и разрешений в исходном виде. Если это не так, используйте портал Azure для создания нового режима безопасности и управления им.
Дополнительные сведения о параметрах безопасности Azure Synapse см. в техническом документе по безопасности.
Подключение и проверка подлинности
Параметры авторизации Teradata
Совет
Проверка подлинности в Teradata и Azure Synapse может осуществляться "в базе данных" или с помощью внешних методов.
Teradata поддерживает несколько механизмов подключения и авторизации. Допустимые значения механизма:
TD1, который выбирает Teradata 1 в качестве механизма проверки подлинности. Необходимо указать имя пользователя и пароль.
TD2, который выбирает Teradata 2 в качестве механизма проверки подлинности. Необходимо указать имя пользователя и пароль.
TDNEGO, который выбирает один из механизмов проверки подлинности автоматически на основе политики без участия пользователя.
LDAP, который выбирает протокол LDAP в качестве механизма проверки подлинности. Приложение предоставляет имя пользователя и пароль.
KRB5, который выбирает Kerberos (KRB5) для клиентов Windows, работающих с серверами Windows. Чтобы войти с помощью KRB5, пользователю необходимо указать домен, имя пользователя и пароль. Домен указывается путем задания имени пользователя
MyUserName@MyDomain.NTLM, который выбирает NTLM для клиентов Windows, работающих с серверами Windows. Приложение предоставляет имя пользователя и пароль.
Kerberos (KRB5), совместимость Kerberos (KRB5C), NT LAN Manager (NTLM) и NT LAN Manager Compatibility (NTLMC) предназначены только для Windows.
Параметры авторизации Azure Synapse
Azure Synapse поддерживает два основных варианта подключения и авторизации:
Проверка подлинности SQL. Проверка подлинности SQL осуществляется через подключение к базе данных, включающее идентификатор базы данных, идентификатор пользователя и пароль, а также дополнительные параметры. Это функционально эквивалентно подключениям Teradata TD1, TD2 и подключениям по умолчанию.
Проверка подлинности Microsoft Entra: с помощью проверки подлинности Microsoft Entra можно централизованно управлять удостоверениями пользователей базы данных и другими службы Майкрософт в одном центральном расположении. Централизованное управление удостоверениями позволяет использовать единое расположение для управления пользователями хранилища данных SQL и упрощает управление разрешениями. Идентификатор Microsoft Entra также может поддерживать подключения к службам LDAP и Kerberos, например идентификатор Microsoft Entra можно использовать для подключения к существующим каталогам LDAP, если они останутся на месте после миграции базы данных.
Пользователи, роли и разрешения
Обзор
Совет
Высокоуровневое планирование имеет важное значение для успешного проекта миграции.
Teradata и Azure Synapse реализуют управление доступом к базе данных через комбинацию пользователей, ролей и разрешений. Используйте стандартные инструкции SQL CREATE USER и CREATE ROLE для определения пользователей и ролей, а также инструкции GRANT и REVOKE для назначения или удаления разрешений для этих пользователей и/или ролей.
Совет
Автоматизация процессов миграции рекомендуется для сокращения временных затрат и минимизации потенциальных ошибок.
Концептуально эти две базы данных похожи, и в некоторой степени можно автоматизировать перенос существующих ИД пользователей, ролей и разрешений. Переносите такие данные путем извлечения существующих устаревших сведений о пользователях и ролях из таблиц системного каталога Teradata и создания соответствующих эквивалентов инструкций CREATE USER и CREATE ROLE, которые будут выполняться в Azure Synapse для повторного создания той же иерархии пользователей и ролей.
После извлечения данных используйте таблицы системного каталога Teradata для создания эквивалентных инструкций GRANT для назначения разрешений (где существует эквивалентная). На следующей схеме показано, как использовать существующие метаданные для создания необходимых SQL.
Пользователи и роли
Совет
Для миграции хранилища данных требуются не только таблицы, представления и инструкции SQL.
Сведения о текущих пользователях и ролях в системе Teradata находятся в таблицах DBC.USERS (или DBC.DATABASES) и DBC.ROLEMEMBERS системного каталога. Запросите эти таблицы (если у пользователя есть доступ SELECT к этим таблицам), чтобы получить текущие списки пользователей и ролей, определенных в системе. Ниже приведены примеры запросов для отдельных пользователей:
/***SQL to find all users***/
SELECT
DatabaseName AS UserName
FROM DBC.Databases
WHERE dbkind = 'u';
/***SQL to find all roles***/
SELECT A.ROLENAME, A.GRANTEE, A.GRANTOR,
A.DefaultRole,
A.WithAdmin,
B.DATABASENAME,
B.TABLENAME,
B.COLUMNNAME,
B.GRANTORNAME,
B.AccessRight
FROM DBC.ROLEMEMBERS A
JOIN DBC.ALLROLERIGHTS B
ON A.ROLENAME = B.ROLENAME
GROUP BY 1,2,3,4,5,6,7
ORDER BY 2,1,6;
Данные примеры меняют инструкции SELECT, чтобы создать результирующий набор, который является серией инструкций CREATE USER и CREATE ROLE, включив соответствующий текст в качестве литерала в инструкцию SELECT.
Получить существующие пароли невозможно, поэтому необходимо реализовать схему выделения новых начальных паролей на Azure Synapse.
Разрешения
Совет
Существуют эквивалентные разрешения Azure Synapse для базовых операций базы данных, таких как DML и DDL.
В системе Teradata системные таблицы DBC.ALLRIGHTS и DBC.ALLROLERIGHTS содержат права доступа для пользователей и ролей. Запросите эти таблицы (если у пользователя есть доступ SELECT к этим таблицам), чтобы получить текущие списки прав доступа, определенных в системе. Ниже приведены примеры запросов для отдельных пользователей:
/**SQL for AccessRights held by a USER***/
SELECT UserName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE
ALRTS.AccessRight
END AS AccessRight, GrantAuthority, GrantorName, AllnessFlag, CreatorName, CreateTimeStamp
FROM DBC.ALLRIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv Abbv
ON ALRTS.AccessRight = Abbv.AccessRight
WHERE UserName='UserXYZ'
Order By 2,3,4,5;
/**SQL for AccessRights held by a ROLE***/
SELECT RoleName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE
ALRTS.AccessRight
END AS AccessRight, GrantorName, CreateTimeStamp
FROM DBC.ALLROLERIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv
Abbv
ON ALRTS.AccessRight = Abbv.AccessRight
WHERE RoleName='BI_DEVELOPER'
Order By 2,3,4,5;
Измените эти примеры инструкции SELECT, чтобы создать результирующий набор, который является серией инструкций GRANT, включив соответствующий текст в качестве литерала в инструкцию SELECT.
Используйте таблицу AccessRightsAbbv для поиска полного текста права доступа, так как ключ соединения — это сокращенное поле type. Список прав доступа Teradata и их эквивалент в Azure Synapse см. в следующей таблице.
| Имя разрешения Teradata | Тип Teradata | Эквивалент Azure Synapse |
|---|---|---|
| ABORT SESSION | AS | KILL DATABASE CONNECTION |
| ALTER EXTERNAL PROCEDURE | AE | 4 |
| ALTER FUNCTION | AF | ALTER FUNCTION |
| ALTER PROCEDURE | Доступности и устойчивости к разделению сети | ALTER PROCEDURE |
| CHECKPOINT | CP | CHECKPOINT |
| CREATE AUTHORIZATION | Целостности и доступности | CREATE LOGIN |
| CREATE DATABASE | CD | СОЗДАТЬ БАЗУ ДАННЫХ |
| CREATE EXTERNALPROCEDURE | CE | 4 |
| CREATE FUNCTION | CF | CREATE FUNCTION |
| CREATE GLOP | GC | 3 |
| CREATE MACRO | ТМ | CREATE PROCEDURE 2 |
| CREATE OWNER PROCEDURE | OP | СОЗДАТЬ ПРОЦЕДУРУ |
| CREATE PROCEDURE | ПК | СОЗДАТЬ ПРОЦЕДУРУ |
| CREATE PROFILE | CO | CREATE LOGIN 1 |
| CREATE ROLE | CR | CREATE ROLE |
| DROP DATABASE | DD | DROP DATABASE |
| DROP FUNCTION; | DF | DROP FUNCTION; |
| DROP GLOP | GD | 3 |
| DROP MACRO | DM | DROP PROCEDURE 2 |
| DROP PROCEDURE | PD | DELETE PROCEDURE |
| DROP PROFILE | DO | DROP LOGIN 1 |
| DROP ROLE | DR | DELETE ROLE |
| DROP TABLE | DT | DROP TABLE |
| DROP TRIGGER | DG | 3 |
| DROP USER | DU | DROP USER |
| DROP VIEW | DV | DROP VIEW |
| ДАМПА | DP | 4 |
| EXECUTE | E | ВЫПОЛНИТЬ |
| EXECUTE FUNCTION | EF | ВЫПОЛНИТЬ |
| EXECUTE PROCEDURE | PE | ВЫПОЛНИТЬ |
| GLOP MEMBER | GM | 3 |
| INDEX | IX | CREATE INDEX |
| INSERT | I | ВСТАВИТЬ |
| MONRESOURCE | МИ | 5 |
| MONSESSION | MS | 5 |
| OVERRIDE DUMP CONSTRAINT | QA | 4 |
| OVERRIDE RESTORE CONSTRAINT | ИЛИ | 4 |
| REFERENCES | RF | ССЫЛКИ |
| REPLCONTROL | 0 | 5 |
| RESTORE | RS | 4 |
| SELECT | R | ВЫБРАТЬ |
| SETRESRATE | SR | 5 |
| SETSESSRATE | SS | 5 |
| SHOW | SH | 3 |
| UPDATE | U | ОБНОВИТЬ |
AccessRightsAbbvпримечания к таблице:
PROFILEв Teradata функционально эквивалентенLOGINв Azure Synapse.В следующей таблице перечислены различия между макросами и хранимыми процедурами в Teradata. В Azure Synapse процедуры обеспечивают функциональные возможности, описанные в таблице.
Макрос Хранимая процедура Содержит SQL Содержит SQL Может содержать команды с точкой BTEQ Содержит комплексный SPL Может получать переданные ему значения параметров Может получать переданные ему значения параметров Может извлечь одну или нескольких строк Должен использовать курсор для извлечения нескольких строк Хранится в пространстве PERM DBC Хранится в DATABASE или USER PERM Возвращает строки клиенту Может возвращать клиенту одно или несколько значений в качестве параметров SHOW,GLOPиTRIGGERне имеют прямого эквивалента в Azure Synapse.В Azure Synapse управление этими функциями осуществляется системой автоматически. См. Рекомендации по эксплуатации.
В Azure Synapse эти функции обрабатываются за пределами базы данных.
Дополнительные сведения о правах доступа в Azure Synapse см. в статье Разрешения безопасности Azure Synapse Analytics.
Рабочие соображения
Совет
Операционные задачи необходимы для эффективной работы любого хранилища данных.
В этом разделе описывается, как реализовать типичные рабочие задачи Teradata в Azure Synapse с минимальным риском и воздействием на пользователей.
Как и в случае со всеми остальными продуктами хранилища данных, в рабочей среде выполняются текущие задачи управления, необходимые для эффективной работы системы и предоставления данных для мониторинга и аудита. Использование ресурсов и планирование загрузки для будущего роста также попадают в эту категорию, как и резервное копирование и восстановление данных.
Хотя концептуально задачи управления и операций для разных хранилищ данных похожи, отдельные случаи реализации могут отличаться. Как правило, современные облачные продукты, такие как Azure Synapse, включают более автоматизированный и "управляемый системой" подход (в отличие от более ручного подхода в устаревших хранилищах данных, таких как Teradata).
В следующих разделах сравниваются параметры Teradata и Azure Synapse для различных операционных задач.
Задачи по обслуживанию
Совет
Задачи по обслуживанию обеспечивают эффективную работу рабочего хранилища данных и оптимизируют использование таких ресурсов, как хранилище.
В большинстве устаревших сред хранилища данных требуется выполнять обычные задачи по обслуживанию, такие как освобождение места на диске, которое можно освободить, удалив старые версии обновленных или удаленных строк, или реорганизация файлов журнала данных или блоков индекса для повышения эффективности. Сбор статистики также является потенциально трудоемкой задачей. Сбор статистики требуется после приема массовых данных, чтобы предоставить оптимизатору запросов актуальные данные для создания базы планов выполнения запросов.
Teradata рекомендует собирать статистику следующим образом:
Сбор статистики по незаполненным таблицам для настройки гистограммы интервала, используемой во внутренней обработке. Такой начальный сбор статистики ускоряет ее последующий сбор. Не забудьте повторно собрать статистику после добавления данных.
Сбор статистики этапа прототипа для вновь заполненных таблиц.
Сбор статистики этапа производства, после значительного процента изменений в таблице или секции (около 10 % строк). Для больших объемов неуникальных значений, таких как даты или метки времени, может быть полезно повторно собрать статистику при 7%.
Сбор статистики этапа производства после создания пользователей и применения реальных запросов к базе данных (до трех месяцев).
Сбор статистики за первые несколько недель после обновления или миграции в периоды низкой загрузки ЦП.
Сбором статистики можно управлять вручную с помощью открытых API-интерфейсов автоматизированного управления статистикой или автоматически с помощью порталета диспетчера статистики Teradata Viewpoint Stats Manager.
Совет
Автоматизация и мониторинг задач по обслуживанию в Azure.
База данных Teradata содержит множество таблиц журналов в словаре данных, которые накапливают данные автоматически или после включения определенных функций. Поскольку объем данных журнала увеличивается с течением времени, очищайте его от старых сведений, чтобы не исчерпать постоянное пространство. Существуют варианты автоматизации обслуживания этих журналов. Далее рассматриваются таблицы словаря Teradata, требующие обслуживания.
Таблицы словарей для обслуживания
Сбросьте накопленные и пиковые значения с помощью представления DBC.AMPUsage и макроса ClearPeakDisk, предоставленного программным обеспечением:
DBC.Acctg: использование ресурсов по учетной записи или пользователюDBC.DataBaseSpace: учет базы данных и табличного пространства
Teradata автоматически поддерживает эти таблицы, но следование рекомендациям может уменьшить их размер:
DBC.AccessRights: права пользователя на объектыDBC.RoleGrants: права роли на объектыDBC.Roles: определяемые ролиDBC.Accounts: коды учетных записей по пользователю
Заархивируйте эти таблицы ведения журнала (при необходимости) и очистите информацию 60–90 дней давности. Хранение зависит от требований клиентов:
DBC.SW_Event_Log: журнал консоли базы данныхDBC.ResUsage: таблицы мониторинга ресурсовDBC.EventLog: журнал входа в сеанс или выхода из сеансаDBC.AccLogTbl: зарегистрированные события пользователя или объектаDBC.DBQL tables: зарегистрированное действие пользователя или SQL.NETSecPolicyLogTbl: регистрирует журналы аудита динамической политики безопасности.NETSecPolicyLogRuleTbl: определяет, когда и как регистрируется динамическая политика безопасности
Очистка этих таблиц при истечении срока действия и перезаписи соответствующего съемного носителя:
DBC.RCEvent: события архивации и восстановленияDBC.RCConfiguration: конфигурация архивации и восстановленияDBC.RCMedia: VolSerial для архивации и восстановления
Azure Synapse имеет возможность автоматически создавать статистику, которую можно будет использовать по мере необходимости. Выполняйте дефрагментацию индексов и блоков данных вручную, по расписанию или автоматически. Использование собственных встроенных возможностей Azure может сократить усилия, необходимые для выполнения миграции.
Мониторинг и аудит
Совет
Со временем реализовано несколько различных средств для мониторинга и ведения журнала систем Teradata.
Teradata предоставляет несколько средств для мониторинга операции, включая точку просмотра (Teradata Viewpoint) и диспетчер экосистем (Ecosystem Manager). Что касается ведения журнала запросов, журнал запросов базы данных (DBQL) — это функция базы данных Teradata, предоставляющая ряд предопределенных таблиц, которые могут хранить архивные записи запросов и их длительность, производительность и целевое действие на основе определяемых пользователем правил.
Администраторы базы данных могут использовать Teradata Viewpoint для определения состояния системы, тенденций и состояния отдельных запросов. Наблюдая за тенденциями использования системы, системные администраторы могут более эффективно планировать реализацию проектов, пакетные задания и обслуживание, чтобы избежать пиковых периодов использования. Бизнес-пользователи могут использовать Teradata Viewpoint для быстрого доступа к состоянию отчетов и запросов и детализации сведений.
Совет
Портал Azure предоставляет пользовательский интерфейс для управления задачами мониторинга и аудита для всех данных и процессов Azure.
Аналогичным образом Azure Synapse предоставляет широкие возможности мониторинга в рамках портала Azure, обеспечивая аналитические сведения о рабочей нагрузке хранилища данных. Портал Azure — рекомендуемый инструмент мониторинга хранилища данных, так как он предоставляет настраиваемые периоды хранения, оповещения, рекомендации, индивидуальные диаграммы и панели мониторинга для метрик и журналов.
На портале также можно выполнить интеграцию с другими службами мониторинга Azure, такими как Operations Management Suite (OMS) и Azure Monitor, чтобы обеспечить комплексные возможности мониторинга не только для хранилища данных, но и для всей платформы аналитики Azure.
Совет
Низкоуровневые и системные метрики автоматически регистрируются в Azure Synapse.
Статистика использования ресурсов для Azure Synapse автоматически регистрируется в системе. Метрики для каждого запроса включают статистику использования ЦП, памяти, кэша, ввода-вывода и временной рабочей области, а также сведения о подключении, такие как неудачные попытки подключения.
Azure Synapse предоставляет набор динамических административных представлений (DMV). Эти представления полезны в том случае, если вы активно устраняете неполадки и выявляете узкие места производительности в рабочей нагрузке.
Дополнительные сведения см. в разделе операций и параметров управления Azure Synapse.
Высокая доступность (HA) и аварийное восстановление (DR)
Teradata реализует такие функции, как FALLBACK, служебная программа восстановления архива (ARC) и архитектура потока данных (DSA), чтобы обеспечить защиту от потери данных и высокой доступности (HA) с помощью репликации и архивации данных. Варианты аварийного восстановления (DR) включают двойное активное решение, аварийное восстановление как услугу или систему замены в зависимости от требований к времени восстановления.
Совет
Azure Synapse автоматически создает моментальные снимки, чтобы обеспечить быстрое время восстановления.
Azure Synapse использует моментальные снимки базы данных для обеспечения высокого уровня доступности хранилища. Моментальный снимок хранилища данных создает точку восстановления, которую можно использовать для копирования или восстановления хранилища данных до предыдущего состояния. Поскольку Azure Synapse — это распределенная система, моментальный снимок хранилища данных состоит из множества файлов, находящихся в службе хранилища Azure. Моментальные снимки фиксируют добавочные изменения в данных, содержащихся в хранилище данных.
Azure Synapse автоматически делает моментальные снимки в течение дня, чтобы создать точки восстановления, доступные в течение семи дней. Этот период хранения невозможно изменить. Azure Synapse поддерживает восьмичасовую целевую точку восстановления (RPO). Можно восстановить хранилище данных в основном регионе из любого моментального снимка, сделанного за последние семь дней.
Совет
Используйте пользовательские моментальные снимки для определения точки восстановления перед обновлениями ключей.
Пользовательские точки восстановления также поддерживаются, позволяя вручную запускать моментальные снимки для создания точек восстановления хранилища данных до и после больших изменений. Эта возможность гарантирует, что точки восстановления логически согласованы, что обеспечивает дополнительную защиту данных в случае любых прерываний рабочей нагрузки или пользовательских ошибок для желаемой целевой точки восстановления, составляющей менее 8 часов.
Совет
Microsoft Azure предоставляет автоматическое резервное копирование в отдельное географическое расположение для включения аварийного восстановления.
Кроме моментальных снимков, описанных ранее, Azure Synapse также по умолчанию выполняет геоизбыточное резервное копирование один раз в день в сопряженный центр обработки данных. Целевая точка восстановления для геовосстановления составляет 24 часа. Можно восстановить географическую резервную копию на сервере в любом другом регионе, где поддерживается Azure Synapse. Геоизбыточное резервное копирование гарантирует, что хранилище данных может быть восстановлено в случае, если точки восстановления в основном регионе недоступны.
Управление рабочей нагрузкой
Совет
В производственном хранилище данных обычно одновременно выполняются смешанные рабочие нагрузки с различными характеристиками использования ресурсов.
Рабочая нагрузка — это класс запросов к базе данных с общими чертами, чьим доступом к базе данных можно управлять с помощью набора правил. Рабочие нагрузки полезны для следующих задач:
Задание разных приоритетов доступа для различных типов запросов.
Мониторинг шаблонов использования ресурсов, настройки производительности и планирования ресурсов.
Ограничение количества запросов или сеансов, которые могут выполняться одновременно.
В системе Teradata управление рабочей нагрузкой — это акт управления производительностью рабочей нагрузки путем мониторинга активности системы и действий при достижении предварительно определенных ограничений. Управление рабочей нагрузкой использует правила, и каждое правило применяется только к некоторым запросам базы данных. Однако коллекция всех правил применяется ко всем активным действиям на платформе. Teradata Active System Management (TASM) выполняет полное управление рабочей нагрузкой в базе данных Teradata.
В Azure Synapse классы ресурсов представляют собой предопределенные ограничения ресурсов, которые управляют вычислительными ресурсами и параллелизмом для выполнения запроса. Классы ресурсов позволяют управлять рабочей нагрузкой путем установки ограничений на количество параллельно выполняющихся запросов и на вычислительные ресурсы, назначенные для каждого запроса. Между требованиями к памяти и параллелизму существует зависимость.
Azure Synapse автоматически регистрирует статистику использования ресурсов. Метрики включают статистику использования ЦП, памяти, кэша, операций ввода-вывода и временной рабочей области для каждого запроса. Azure Synapse также регистрирует информацию о подключении, например неудачные попытки подключения.
Совет
Низкоуровневые и общесистемные метрики автоматически регистрируются в Azure.
Azure Synapse поддерживает следующие основные концепции управления рабочей нагрузкой:
Классификация рабочей нагрузки: вы можете назначить запрос группе рабочей нагрузки, чтобы установить уровни важности.
Важность рабочей нагрузки: вы можете влиять на порядок, в котором запрос получает доступ к ресурсам. По умолчанию запросы освобождаются из очереди по мере того, как ресурсы становятся доступными. Важность рабочей нагрузки позволяет запросам с более высоким приоритетом получать ресурсы немедленно, независимо от очереди.
Изоляция рабочей нагрузки: вы можете резервировать ресурсы для группы рабочей нагрузки, назначать максимальное и минимальное использование для различных ресурсов, ограничивать ресурсы, которые может потреблять группа запросов, и устанавливать значение времени ожидания для автоматического завершения неконтролируемых запросов.
Выполнение смешанных рабочих нагрузок может усложнять процесс распределения ресурсов на загруженных системах. Успешная схема управления рабочей нагрузкой позволяет эффективно управлять ресурсами, обеспечивает их высокоэффективное использование и максимально увеличивает рентабельность инвестиций. Классификация рабочей нагрузки, важность рабочей нагрузки и изоляция рабочей нагрузки позволяют лучше контролировать использование системных ресурсов рабочей нагрузкой.
В руководстве по управлению рабочей нагрузкой описаны методы анализа рабочей нагрузки, управления и мониторинга важности рабочей нагрузки](../../sql-data-warehouse/sql-data-warehouse-how-to-manage-and-monitor-workload-importance.md) и действия по преобразованию класса ресурсов в группу рабочей нагрузки. Используйте портал Azure и запросы T-SQL к DMV, чтобы отслеживать рабочую нагрузку и обеспечивать эффективное использование применимых ресурсов. Azure Synapse предоставляет набор динамических административных представлений (DMV) для мониторинга всех аспектов управления рабочей нагрузкой. Эти представления полезны при активном устранении неполадок и выявлении узких мест производительности в вашей рабочей нагрузке.
Эти сведения также можно использовать для планирования загрузки, определяя ресурсы, необходимые для дополнительных пользователей или рабочей нагрузки приложений. Это также относится к планированию увеличения и уменьшения масштаба вычислительных ресурсов для экономичной поддержки пиковых рабочих нагрузок.
Дополнительные сведения об управлении рабочей нагрузкой в Azure Synapse см. в разделе Управление рабочей нагрузкой с помощью классов ресурсов.
Масштабирование вычислительных ресурсов
Совет
Основным преимуществом Azure является возможность независимо масштабировать вычислительные ресурсы по требованию для эффективной обработки пиковых рабочих нагрузок.
Архитектура Azure Synapse разделяет хранилище и вычислительные ресурсы, что позволяет масштабировать их независимо друг от друга. В результате можно масштабировать вычислительные ресурсы в соответствии с требованиями к производительности независимо от хранилища данных. Кроме того, можно приостанавливать и возобновлять работу вычислительных ресурсов. Преимуществом такой архитектуры является отдельное выставление счетов за вычислительные ресурсы и ресурсы хранилища. Если хранилище данных не используется, вы можете сэкономить на затратах на вычисления за счет приостановки вычислений.
Вычислительные ресурсы можно масштабировать в сторону увеличения или сокращения, корректируя параметры единиц хранилища данных для хранилища данных. Добавление единиц использования хранилища данных позволяет линейно повышать производительность загрузки и запросов.
Добавление дополнительных вычислительных узлов увеличивает вычислительные мощности и возможность использовать более параллельную обработку. При увеличении количества вычислительных узлов количество распределений на каждом вычислительном узле уменьшается, что обеспечивает дополнительную вычислительную мощность и параллельную обработку для запросов. Точно так же уменьшение количества единиц использования хранилища данных приводит к уменьшению числа вычислительных узлов, и для обработки запросов становится доступно меньше вычислительных ресурсов.
Следующие шаги
Дополнительные сведения о визуализации и отчетах см. в следующей статье этой серии: Визуализация и создание отчетов для миграций Teradata.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по