Microsoft AZ-104: Базы данных Azure и службы данных — Руководство по подготовке

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Часть Microsoft Azure Administrator Associate AZ-104 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Сервисы баз данных и обработки данных Azure охватывают управляемые реляционные СУБД, глобально распределенные NoSQL, кэширование в памяти, крупномасштабную аналитику и интеграцию/оркестрацию. Как администратор, вы должны понимать модели приобретения, уровни служб, топологию сети и безопасности, семантику резервного копирования/аварийного восстановления и способы комбинирования сервисов для достижения производительности, экономичности и отказоустойчивости. Этот раздел посвящен операционным решениям и функциям платформы, которые вы настраиваете в повседневной работе: модели подготовки (DTU и vCore), эластичные пулы, резервное копирование и долгосрочное хранение, георепликацию и отработку отказа, управляемые экземпляры с внедрением в VNet, распределение и согласованность данных в Cosmos DB, реплики чтения/высокой доступности для реляционных СУБД с открытым исходным кодом, движки Synapse и среды выполнения Data Factory.

Реляционные базы данных Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database предлагает две модели приобретения. Модель DTU объединяет CPU, память и IOPS в единицы транзакций базы данных (Database Transaction Units) с уровнями Basic, Standard и Premium; она проста, но непрозрачна, и хорошо подходит для стабильных, предсказуемых рабочих нагрузок и определения размеров по устаревшим методикам. Модель vCore предоставляет доступ к поколению/количеству CPU и памяти в паре с элементами управления хранилищем и IOPS. vCore обеспечивает прозрачность при определении размеров, позволяет использовать Azure Hybrid Benefit и скидки за зарезервированную емкость (Reserved Capacity). В рамках модели vCore уровни служб соответствуют различным типам рабочих нагрузок и моделям доступности: General Purpose использует удаленное хранилище Premium SSD или Azure Premium со стандартной архитектурой доступности; Business Critical размещает вычислительные ресурсы и хранилище на локальных SSD с несколькими репликами, обеспечивая низкую задержку и встроенное горизонтальное масштабирование для чтения; Hyperscale разделяет вычислительные ресурсы и хранилище с помощью серверов страниц (page servers) для почти мгновенного масштабирования и поддержки очень больших баз данных. Для отдельных баз данных бессерверный (serverless) вычислительный уровень (vCore) эластично масштабирует CPU и может автоматически приостанавливаться для сокращения затрат в периоды простоя.

Эластичные пулы (Elastic pools) разделяют вычислительные ресурсы между несколькими базами данных, чтобы справляться с пиковыми, несинхронными нагрузками при меньших совокупных затратах. Пулы доступны в вариантах DTU (eDTU) и vCore. Вы устанавливаете минимальные/максимальные ограничения для каждой базы данных, чтобы изолировать «шумных соседей», и максимальное ограничение для пула, чтобы контролировать расходы. Избыточная подписка (oversubscription) допустима, когда всплески активности короткие и не коррелируют между собой. Определение размера пула зависит от суммарного среднего потребления плюс запас для параллельной работы; мониторинг метрик каждой базы данных и пула имеет решающее значение для соблюдения SLO.

Резервное копирование выполняется автоматически. Azure SQL поддерживает полные, дифференциальные резервные копии и резервные копии журналов транзакций с возможностью восстановления на определенный момент времени (PITR) с точностью до секунды в пределах окна хранения (обычно 7–35 дней в зависимости от уровня и конфигурации хранилища). Долгосрочное хранение (LTR) сохраняет еженедельные полные резервные копии на годы в хранилище RA-GRS; вы можете восстановить резервную копию LTR как новую базу данных на любом сервере в той же подписке и наборе регионов, а межрегиональное восстановление доступно, если включено геоизбыточное хранилище резервных копий. При восстановлении создается новая база данных; существующая база данных не перезаписывается.

Варианты георепликации включают активную георепликацию для отдельных баз данных и пулов (до четырех читаемых вторичных реплик с асинхронной репликацией) и группы автоматической отработки отказа (auto-failover groups) на уровне логического сервера. Группы отработки отказа объединяют несколько баз данных (или весь сервер) с гео-DR, конечной точкой прослушивателя для чтения и записи, конечной точкой только для чтения для разгрузки операций чтения, автоматической отработкой отказа на основе состояния работоспособности и перенаправлением на основе DNS. Уровень Business Critical также предоставляет горизонтальное масштабирование для чтения (read scale-out) через локальную читаемую реплику, что позволяет немедленно разгрузить рабочую нагрузку чтения без сложностей, связанных с межрегиональным взаимодействием.

Azure SQL Managed Instance (MI) обеспечивает почти 100% совместимость с движком SQL Server, включая SQL Agent, межбазовые запросы, CLR, связанные серверы (linked servers), Service Broker и нативное резервное копирование/восстановление файлов .bak из Azure Blob Storage. MI внедряется в VNet: вы развертываете его в выделенной, делегированной подсети с частными IP-адресами и элементами управления NSG/UDR; планируйте размер подсети и адресное пространство заранее, так как последующее изменение размера подсетей является сложной задачей. Пути миграции включают Azure Database Migration Service (онлайн/офлайн-переключения), нативное резервное копирование/восстановление по URL в MI и транзакционную репликацию с локального SQL Server в MI. Выбирайте MI, когда вам требуется паритет по функциональной поверхности (surface-area parity) или функции уровня экземпляра, которые недоступны в отдельных базах данных.

Azure Database for MySQL и Azure Database for PostgreSQL (Flexible Server) предоставляют управляемые движки OSS с контролем над окнами обслуживания, возможностью остановки/запуска для экономии средств, вычислительными ресурсами с переменной производительностью (burstable) и общего назначения, автоматическим увеличением хранилища и интеграцией с VNet. Flexible Server предлагает высокую доступность с синхронной репликацией; вы можете выбрать отказоустойчивость с избыточностью между зонами (zone-redundant HA) в разных Зонах доступности для более надежной изоляции сбоев или отказоустойчивость в той же зоне (same-zone HA) для меньшей задержки при записи. Реплики чтения (Read replicas) доступны для горизонтального масштабирования операций чтения и могут быть развернуты внутри региона или между регионами; они используют асинхронную репликацию и идеально подходят для аналитики, отчетности или микросервисов с высокой нагрузкой на чтение. При необходимости повысьте реплику для отработки отказа или регионального расширения, принимая во внимание возможную задержку репликации.

Распределенные данные и кэширование (Cosmos DB и Azure Cache for Redis)

Azure Cosmos DB — это глобально распределенная мультимодельная база данных, предлагающая API для Core (SQL), MongoDB, Cassandra, Gremlin (графы) и Table. Выбор API определяет совместимость клиентских драйверов и семантику модели данных; в операционном плане вы управляете пропускной способностью (подготовленные ЕЗ или автомасштабирование) и секциями независимо от API. Данные горизонтально секционируются по ключу секционирования, который должен обладать высокой кардинальностью и равномерным распределением доступа во избежание «горячих» секций; избегайте монотонно возрастающих ключей и рассмотрите иерархические ключи секционирования при наличии сложных шаблонов доступа. Запросы между секциями поддерживаются, но потребляют больше ЕЗ; по возможности размещайте связанные данные в одной секции с помощью общего ключа.

Уровни согласованности настраиваются для учетной записи, базы данных или запроса: Strong (Строгий) гарантирует линеаризуемость; Bounded Staleness (Ограниченное устаревание) ограничивает устаревание по времени или версии; Session (Сеанс, по умолчанию) обеспечивает чтение собственных записей в рамках сеанса; Consistent Prefix (Согласованный префикс) гарантирует порядок без полной согласованности; Eventual (Конечный) максимизирует доступность и производительность. Для записи в нескольких регионах выберите подходящую политику разрешения конфликтов (LastWriterWins или пользовательскую через хранимые процедуры) и определите приоритеты отработки отказа. Глобальное распределение позволяет добавлять регионы одним щелчком мыши; служба управляет репликацией, отработкой отказа и маршрутизацией с оптимизацией задержки, предоставляя SLA на пропускную способность, задержку, доступность и согласованность.

Azure Cache for Redis обеспечивает задержку менее миллисекунды, работая на базе Redis. Уровни обслуживания различаются по возможностям: Basic (один узел, для разработки/тестирования), Standard (реплицированный двухузловой кластер «основной/реплика» с SLA), Premium (большие размеры, кластеризация, сохраняемость, внедрение в VNet, георепликация и модули Redis, такие как Bloom), Enterprise и Enterprise Flash (на базе Redis Enterprise с расширенной кластеризацией, активной георепликацией для записи с несколькими основными узлами и кэшами большего размера на основе Flash). Политики вытеснения определяют поведение при нехватке памяти: noeviction (ошибки при записи), allkeys-lru/lfu/random (рассматриваются все ключи) и volatile-lru/lfu/ttl/random (рассматриваются только ключи с TTL). Для кэширования сеансов используйте уровень Premium или выше для обеспечения сохраняемости, если потеря сеансов недопустима, включите TTL для ключей, чтобы ограничить рост, и рассмотрите возможность кластеризации для увеличения пропускной способности и масштаба. Размещайте кэш в том же регионе и виртуальной сети, что и серверы приложений, чтобы минимизировать задержку; используйте Managed Identity или ключи доступа и обеспечивайте сетевую изоляцию с помощью Private Link или внедрения в VNet.

Аналитика и интеграция (Synapse Analytics и Data Factory)

Azure Synapse Analytics объединяет хранилища данных, большие данные и интеграцию данных. Выделенный пул SQL (ранее SQL DW) — это MPP-система с хэш-распределением/циклическим распределением, реплицированными таблицами и кэшированием наборов результатов. Вы можете масштабировать вычислительные ресурсы для соответствия окнам SLA и приостанавливать их, чтобы платить только за хранилище. Изоляция рабочих нагрузок может быть достигнута с помощью групп рабочих нагрузок и настроек важности для защиты критически важных запросов. Бессерверный пул SQL предоставляет T-SQL по запросу для данных в Azure Data Lake Storage Gen2 без выделения ресурсов; вы платите за терабайт отсканированных данных и можете выносить схемы вовне с помощью представлений для семантических слоев. Пулы Spark добавляют Apache Spark в Synapse с автомасштабированием и кластерами по запросу, позволяя использовать записные книжки, Delta Lake и машинное обучение с интегрированной безопасностью и отслеживанием происхождения данных; вы можете совместно использовать данные lakehouse между системами Spark и SQL.

Azure Data Factory (ADF) организует перемещение и преобразование данных. Конвейеры координируют действия, такие как Copy (Копирование), Data Flow (потоки данных на основе Spark) и внешние вычисления (Databricks, Synapse, Functions). Наборы данных определяют структуру и расположение данных, а связанные службы инкапсулируют детали подключения (аутентификация, конечные точки) к источникам/приемникам. Среды выполнения интеграции (Integration runtimes, IR) предоставляют вычислительные и сетевые ресурсы: Azure IR для облачного перемещения и преобразования, Self-hosted IR для локальных источников или источников в частной сети через исходящий HTTPS, и Azure-SSIS IR для переноса (lift-and-shift) пакетов SSIS. Триггеры (по расписанию, “перекатывающееся” окно, на основе событий) обеспечивают повторяемую оркестрацию; управляемая виртуальная сеть и частные конечные точки могут быть включены для защиты от утечки данных и обеспечения совместимого подключения. Параметризация и интеграция с Key Vault поддерживают повторно используемые, безопасные шаблоны для продвижения между средами (разработка/тестирование/производство).

Обеспечение непрерывности бизнеса, геофункции и эластичные пулы

Стратегии резервного копирования и восстановления различаются в зависимости от службы, но имеют общие ключевые принципы: автоматизация, регулярное тестирование восстановления и разделение PITR (для операционных ошибок) и LTR (для соответствия требованиям). В Azure SQL используйте PITR для восстановления после случайного удаления или неудачных развертываний; храните еженедельные полные резервные копии LTR в RA-GRS для соблюдения нормативных требований к хранению и для аварийного восстановления в другом регионе. Для Flexible Server для MySQL/PostgreSQL включите автоматическое резервное копирование с геоизбыточным хранилищем (где это поддерживается), установите срок хранения в соответствии с политикой и проверяйте восстановление на определенный момент времени на альтернативные серверы. Учетные записи Cosmos DB с несколькими регионами поддерживают автоматическую отработку отказа; сочетайте это с записью в несколько регионов, когда RPO должен быть равен нулю, а приложение может детерминированно разрешать конфликты.

Георепликация и группы автоматической отработки отказа (auto-failover groups) в Azure SQL обеспечивают аварийное восстановление (DR) и разгрузку операций чтения. Используйте активную георепликацию для одной базы данных или пула, когда вы хотите явно управлять вторичными репликами; используйте группы автоматической отработки отказа для объединения множества баз данных и получения прослушивателей на основе DNS, а также автоматической отработки отказа. Если важны операции чтения с низкой задержкой, но аварийное восстановление не является целью, используйте масштабирование чтения (read scale-out) на уровне Business Critical или именованные реплики Hyperscale, чтобы перенести аналитику и отчетность с основной реплики. Отслеживайте задержку репликации и сигналы о состоянии отработки отказа, а также проводите учения по отработке отказа для проверки RTO/RPO.

Эластичные пулы — это рычаг оптимизации затрат для многопользовательских SaaS-приложений и парков небольших баз данных. В пулах на основе DTU выделяйте eDTU с ограничениями для каждой базы данных; в пулах на основе vCore выделяйте vCore, память и пропускную способность ввода-вывода с максимальным количеством vCore на базу данных и управлением вводом-выводом. Подбирайте правильный размер, измеряя использование на уровне 95-го процентиля для каждой базы данных и согласовывая емкость пула с шаблонами одновременных подключений; повышайте лимиты для отдельных баз данных для клиентов с более высокими SLO и рассмотрите возможность разделения пулов по классу рабочей нагрузки (например, для «тяжелых» и «легких» клиентов). Используйте оповещения о достижении лимитов пула и отдельных баз данных для раннего обнаружения насыщения. Когда несколько баз данных постоянно достигают максимальных лимитов, переместите их на выделенные вычислительные ресурсы или в отдельный пул для поддержания предсказуемости.

Практический сценарий

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

Секционировать операционное хранилище данных:

Выбрать Azure Cosmos DB (Core SQL API) для хранения данных о взаимодействиях с клиентами и событиях программы лояльности, чтобы обеспечить глобальное распределение с низкой задержкой. Настроить запись в несколько регионов, расположенных рядом с основными группами клиентов, и установить уровень согласованности Session, чтобы сбалансировать чтение собственных записей (read-your-writes) и производительность. Выбрать ключ секционирования с высокой кардинальностью, например customerId или составной иерархический ключ (customerId, eventMonth), для распределения пропускной способности и поддержки распространенных шаблонов запросов.

Реализовать хранение транзакционных данных об учетных записях и каталогах:

Развернуть Azure SQL Managed Instance для балансов счетов, списаний бонусов и каталога SKU, поскольку требуется почти 100% совместимость с SQL Server для существующих хранимых процедур и межбазовой логики. Разместить MI в выделенной, делегированной подсети с NSG и таблицами маршрутизации, как того требует внедрение в VNet (VNet injection), обеспечив частный доступ из подсетей приложений и ExpressRoute.

Обеспечить глобальное масштабирование чтения и DR для реляционных рабочих нагрузок:

Для новых микросервисов, использующих Azure SQL Database, использовать уровень vCore Business Critical для низкой задержки и масштабирования чтения (read scale-out). Создать группу автоматической отработки отказа (auto-failover group) в парном регионе с конечными точками прослушивателя только для чтения (read-only listener endpoints) для локализованных операций чтения и автоматической отработки отказа для достижения целей DR.

Добавить управление сессиями с низкой задержкой:

Развернуть Azure Cache for Redis уровня Premium с кластеризацией и сохранением данных (data persistence) для токенов сессий веб- и мобильных приложений. Установить политику вытеснения allkeys-lfu, чтобы хранить в памяти часто используемые сессии. Интегрировать кэш в ту же VNet и регион, что и уровень приложений, для минимизации задержки.

Организовать перемещение данных и построить аналитику:

Использовать Azure Data Factory для копирования операционных данных (из канала изменений Cosmos DB и SQL MI) в Azure Data Lake Storage Gen2. Применить Managed VNet IR с частными конечными точками (private endpoints) для предотвращения утечки данных. Параметризовать конвейеры и использовать триггеры «переворачивающегося окна» (tumbling window triggers) для гарантии упорядоченной обработки.

Включить корпоративную аналитику с эластичным контролем затрат:

В Azure Synapse Analytics использовать бессерверный пул SQL (serverless SQL pool) для нерегламентированных исследований данных в формате parquet и выделенный пул SQL (dedicated SQL pool) для подготовленных BI-моделей с высокой степенью параллелизма и предсказуемой производительностью. Создать пулы Spark для разработки признаков (feature engineering) на основе поведения в программе лояльности и записывать таблицы Delta в data lake для обеспечения взаимодействия между Spark и SQL.

Управление, резервное копирование и хранение:

Настроить приоритеты автоматической отработки отказа в Cosmos DB и отслеживать конфликты, используя политику LastWriterWins с полем временной метки. Для Azure SQL Database и MI проверить окна PITR и включить LTR для соблюдения требований к хранению данных. Для экземпляров Flexible Server, поддерживающих вспомогательные OSS-службы (например, телеметрию региональных магазинов в PostgreSQL), включить отказоустойчивость между зонами (zone-redundant HA) и настроить реплики чтения для отчетности.

Почему выбраны именно эти службы: Глобальное распределение и настраиваемая согласованность Cosmos DB решают проблему чувствительных к задержкам взаимодействий по всему миру; MI сохраняет сложные функции SQL Server, предоставляя при этом управляемые операции; базы данных уровня Business Critical обеспечивают локальное масштабирование чтения без задержек между регионами; Redis гарантирует доступ к сессиям за доли миллисекунды во время пиков трафика; ADF обеспечивает безопасное, управляемое перемещение данных из частных сетей; Synapse сочетает аналитику по требованию и подготовленную аналитику для экономически эффективных, масштабируемых выводов. Такая композиция позволяет достичь SLO по производительности во время акций, сокращает ручной труд администраторов за счет управляемых PaaS-сервисов и устанавливает четкие границы для RTO/RPO и соответствия требованиям.

← Azure App Service и вычислительные ресурсы PaaS · Все домены · Azure Monitor →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →