Справочник

Данные организованы в фиксированном табличном макете с предопределенной схемой (строки и столбцы), например, каталог продуктов или финансовые записи.

→Представляйте как структурированные данные.

Почему: Структурированные данные соответствуют жесткой схеме, идеально подходят для реляционных баз данных (OLTP). В отличие от полуструктурированных (JSON/XML) и неструктурированных (изображения/аудио).

Данные имеют некоторую организационную структуру (теги, ключи), но не имеют жесткой схемы. Каждая запись может иметь разные поля, например, JSON-документы датчиков IoT.

→Представляйте как полуструктурированные данные (например, JSON, XML).

Почему: JSON и XML являются самоописываемыми, предлагая гибкость по сравнению с фиксированными схемами структурированных данных. Идеально подходят для баз данных NoSQL и озер данных.

Хранение больших файлов без предопределенной схемы или организационной структуры, таких как МРТ-сканы, видео или аудиозаписи.

→Представляйте как неструктурированные данные.

Почему: Этот тип данных не может храниться в традиционных строковых/столбцовых базах данных. Требует объектного хранилища, такого как Azure Blob Storage.

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

→Используйте OLTP (Online Transaction Processing) для высокообъемных транзакций с низкой задержкой (например, заказов электронной коммерции). Используйте OLAP (Online Analytical Processing) для сложных запросов к большим историческим наборам данных (например, анализ тенденций продаж).

Почему: Системы OLTP нормализованы и оптимизированы для быстрых операций записи. Системы OLAP денормализованы (схема "звезда") и оптимизированы для быстрых операций чтения и агрегирования.

Выберите шаблон интеграции данных для хранилища данных.

→Используйте ETL (Extract, Transform, Load), когда логика преобразования сложна и выполняется на промежуточном сервере перед загрузкой. Используйте ELT (Extract, Load, Transform) для загрузки необработанных данных в мощную целевую систему (например, Synapse Analytics) и используйте ее вычислительные ресурсы для преобразований.

Почему: ELT — это современный облачный шаблон, использующий масштабируемые вычислительные ресурсы в целевом хранилище данных (хранилище данных/озеро данных) и упрощающий загрузку.

Распределение ответственности за задачи платформы данных.

→Инженер данных: строит и поддерживает конвейеры ETL/ELT. Администратор базы данных: управляет безопасностью, производительностью и доступностью базы данных. Аналитик данных: создает отчеты и визуализации (например, Power BI) для бизнес-аналитики.

Почему: Четко определенные роли необходимы. Ключевое различие — это создание (инженер), управление (администратор БД) и анализ (аналитик).

Обработка больших объемов данных с различными требованиями к задержке.

→Используйте пакетную обработку для данных в состоянии покоя, обрабатываемых через запланированные интервалы (например, ночные отчеты). Используйте потоковую обработку для данных в движении, обрабатываемых непрерывно по мере их поступления (например, обнаружение мошенничества в реальном времени).

Почему: Ключевой компромисс — задержка против стоимости/пропускной способности. Потоковая обработка обеспечивает низкую задержку, но требует постоянно работающих ресурсов. Пакетная обработка имеет высокую задержку, но экономически эффективна для больших объемов.

Разработка схемы для хранилища данных для поддержки аналитических запросов.

→Используйте схему "звезда", состоящую из центральной таблицы фактов (содержащей числовые показатели), соединенной с несколькими таблицами измерений (содержащими описательные атрибуты).

Почему: Эта денормализованная структура минимизирует соединения для аналитических запросов, улучшая производительность по сравнению с нормализованной (OLTP) схемой. Она проще и быстрее для большинства инструментов BI, чем схема "снежинка".

Выбор центрального репозитория для аналитики.

→Используйте озеро данных (например, Azure Data Lake Storage) для хранения огромных объемов необработанных данных в их исходном формате (схема при чтении). Используйте хранилище данных (например, Synapse Dedicated SQL Pool) для хранения структурированных, обработанных данных для BI и отчетности (схема при записи).

Почему: Озера данных предлагают гибкость для науки о данных и исследования необработанных данных. Хранилища данных обеспечивают высокую производительность и структуру для бизнес-аналитики.

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

→Используйте Azure SQL Database.

Почему: Это предложение PaaS с автоматическим исправлением, резервным копированием и высокой доступностью. Идеально подходит для стандартных рабочих нагрузок SQL, где доступ на уровне ОС не требуется.

Источник↗

Миграция методом "lift-and-shift" рабочей нагрузки SQL Server из локальной среды, использующей функции уровня экземпляра, такие как SQL Server Agent, кросс-базовые запросы или Service Broker.

→Используйте Azure SQL Managed Instance.

Почему: SQL MI обеспечивает почти 100% совместимость с локальным движком SQL Server, минимизируя изменения при миграции. Azure SQL Database не поддерживает эти функции на уровне экземпляра.

Источник↗

Миграция базы данных SQL Server в Azure, требующая полного контроля над ОС, конкретными версиями SQL Server или функциями с ограниченной поддержкой PaaS (например, некоторыми сборками CLR).

→Используйте SQL Server на виртуальных машинах Azure.

Почему: Этот вариант IaaS обеспечивает максимальную совместимость и контроль, но требует от пользователя управления ОС, исправлением и резервным копированием, в отличие от предложений PaaS.

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

→Используйте бессерверный уровень вычислений для Azure SQL Database.

Почему: Serverless автоматически масштабирует вычислительные ресурсы в зависимости от спроса и может автоматически приостанавливать работу базы данных, взимая плату только за хранение в периоды простоя. Идеально подходит для переменных рабочих нагрузок.

Источник↗

Размещение нескольких небольших баз данных для разных арендаторов (SaaS) с переменными рабочими нагрузками. Необходимо совместно использовать ресурсы для сокращения затрат.

→Используйте эластичные пулы Azure SQL Database.

Почему: Эластичные пулы позволяют нескольким базам данных совместно использовать предварительно выделенный набор ресурсов (DTU или vCore), предоставляя экономически эффективное решение для многопользовательских приложений.

База данных, как ожидается, вырастет до более чем 4 ТБ (до 100 ТБ) и требует быстрого масштабирования, а также почти мгновенных резервных копий и восстановлений, независимо от размера.

→Используйте уровень обслуживания Hyperscale для Azure SQL Database.

Почему: Hyperscale использует уникальную распределенную архитектуру для очень больших баз данных (VLDB), снимая ограничения по размеру других уровней и обеспечивая операции с базой данных за постоянное время.

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

→Используйте Azure Database for PostgreSQL - Flexible Server.

Почему: Flexible Server является рекомендуемым предложением, обеспечивающим зоны-избыточную HA, настраиваемые окна обслуживания и лучшую оптимизацию затрат по сравнению со старой моделью Single Server.

Защитите конфиденциальные данные (например, номера кредитных карт), чтобы они оставались зашифрованными в состоянии покоя, при передаче И во время использования (в памяти) на сервере. Даже администраторы баз данных не должны видеть данные в открытом виде.

→Используйте Always Encrypted.

Почему: Always Encrypted — это технология шифрования на стороне клиента, где ключи хранятся у клиента, гарантируя, что данные никогда не расшифровываются на сервере. TDE защищает данные только в состоянии покоя.

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

→Используйте динамическое маскирование данных.

Почему: DDM применяет правила маскирования во время запроса на основе разрешений пользователя. Это функция безопасности для ограничения раскрытия данных, а не функция шифрования.

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

→Настройте группу автоматического перехода на другой ресурс.

Почему: Группы автоматического перехода на другой ресурс предоставляют единую конечную точку прослушивателя, которая автоматически перенаправляет трафик после сбоя, упрощая проектирование приложений для DR. Это обеспечивает более низкие RPO/RTO, чем восстановление из гео-избыточных резервных копий.

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

→Используйте Azure Blob Storage.

Почему: Blob Storage — это служба объектного хранилища, оптимизированная для хранения петабайтов неструктурированных данных. Она не подходит для рабочих нагрузок структурированных запросов.

Источник↗

Оптимизируйте затраты на хранение данных с различными шаблонами доступа.

→Используйте уровни доступа Azure Blob Storage: Hot (часто используемый), Cool (редко используемый, >30 дней), Archive (очень редко используемый, >180 дней).

Почему: Уровни обеспечивают компромисс в затратах: Hot имеет самую высокую стоимость хранения, но самую низкую стоимость доступа. Archive имеет самую низкую стоимость хранения, но самую высокую стоимость доступа и задержку извлечения (часы).

Автоматически перемещайте блобы между уровнями Hot, Cool и Archive на основе их возраста или времени последнего доступа для оптимизации затрат.

→Настройте политику управления жизненным циклом для учетной записи хранения.

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

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

→Используйте Azure File Storage.

Почему: Azure Files предоставляет полностью управляемые файловые ресурсы в облаке, доступные по протоколам SMB и NFS, что делает его прямой заменой локальным файловым серверам.

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

→Используйте Azure Data Lake Storage Gen2.

Почему: ADLS Gen2 основан на Blob Storage и добавляет иерархическое пространство имен (для атомарных операций с каталогами) и поддержку ACL, совместимых с POSIX, что критически важно для производительности и безопасности в фреймворках больших данных, таких как Spark.

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

→Используйте Azure Cosmos DB.

Почему: Cosmos DB разработан для глобально распределенных, критически важных приложений, обеспечивая готовое глобальное распределение, гарантированные SLA с низкой задержкой и несколько моделей согласованности.

Источник↗

Выбор модели данных и API для нового приложения Cosmos DB.

→Используйте API для NoSQL (документ), MongoDB API (документ), Apache Gremlin API (граф), Table API (ключ-значение) или Apache Cassandra API (широкий столбец).

Почему: Выберите API, который наилучшим образом соответствует вашей модели данных и существующему стеку приложений. Используйте NoSQL для новых приложений на основе JSON, Gremlin для данных с большим количеством связей, а другие — для миграции существующих рабочих нагрузок (MongoDB, Cassandra, Table Storage).

Балансировка согласованности чтения, доступности и производительности для приложения Cosmos DB.

→Выберите один из пяти уровней согласованности: Strong, Bounded Staleness, Session (по умолчанию), Consistent Prefix, Eventual.

Почему: Strong обеспечивает наивысшую согласованность, но и наивысшую задержку. Eventual обеспечивает наименьшую задержку, но наислабейшую согласованность. Session является наиболее распространенной, гарантируя, что пользователь читает свои собственные записи в рамках своей сессии.

Нижестоящей службе необходимо реагировать в почти реальном времени на любые данные, созданные или обновленные в контейнере Cosmos DB (например, для обновления поискового индекса).

→Используйте канал изменений Cosmos DB.

Почему: Канал изменений предоставляет постоянный, упорядоченный журнал изменений. Он обычно используется функцией Azure для создания событийных архитектур без опроса базы данных.

Необходимо выполнять сложные аналитические запросы к операционным данным Cosmos DB без влияния на производительность транзакционной рабочей нагрузки (HTAP).

→Включите аналитическое хранилище Azure Cosmos DB и используйте Azure Synapse Link.

Почему: Аналитическое хранилище — это полностью изолированное, автоматически синхронизируемое столбчатое представление ваших транзакционных данных. Оно позволяет выполнять аналитические запросы через Synapse без потребления транзакционных единиц запроса (RU).

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

→Используйте Azure Table Storage.

Почему: Table Storage — это хранилище "ключ-значение" NoSQL, оптимизированное для больших объемов простых поисков с использованием PartitionKey и RowKey. Оно значительно дешевле, чем Cosmos DB, когда не требуются SLA с низкой задержкой и глобальное распределение.

Требуется простая, надежная система обмена сообщениями для разделения компонентов приложения, где сообщения обрабатываются асинхронно.

→Используйте Azure Queue Storage.

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

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

→Используйте Azure Data Factory (ADF).

Почему: ADF — это управляемая облачная служба оркестрации для создания и управления конвейерами ETL/ELT в масштабе, с обширными возможностями подключения и мониторинга.

Источник↗

Конвейеру Azure Data Factory требуется доступ к источнику данных, расположенному локально за корпоративным брандмауэром.

→Установите Self-hosted Integration Runtime (IR) на машине в локальной сети.

Почему: Self-hosted IR действует как безопасный шлюз, позволяя ADF в облаке подключаться к локальным источникам данных и перемещать данные из них, не раскрывая их публичному интернету.

Требуется единая интегрированная платформа для хранилища данных (SQL), аналитики больших данных (Spark), исследования данных (бессерверный SQL) и интеграции данных.

→Используйте Azure Synapse Analytics.

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

Выбор движка SQL-запросов в Synapse Analytics.

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

Почему: Бессерверный предназначен для непредсказуемого исследования и обнаружения. Выделенный предназначен для производственной BI и отчетности с SLA по производительности.

Необходимо обрабатывать и анализировать высокообъемные потоковые данные в реальном времени из таких источников, как IoT Hub или Event Hubs, для поддержки динамических панелей мониторинга или запуска оповещений.

→Используйте Azure Stream Analytics.

Почему: Stream Analytics — это движок обработки событий в реальном времени, который использует простой SQL-подобный язык запросов для анализа данных в движении с низкой задержкой.

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

→Используйте Azure Databricks.

Почему: Databricks предоставляет оптимизированную среду выполнения Spark, совместные ноутбуки и интегрированные возможности ML (MLflow), что делает ее ведущей платформой для расширенной аналитики и ML в Azure.

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

→Используйте Azure Event Hubs.

Почему: Event Hubs — это платформа потоковой передачи больших данных, разработанная для высокопроизводительной передачи событий. Она действует как "входная дверь" для потоковых данных, разделяя производителей и потребителей.

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

→Используйте Microsoft Fabric.

Почему: Fabric предоставляет комплексное аналитическое решение на основе SaaS, построенное на едином озере данных (OneLake). Оно упрощает архитектуру и уменьшает накладные расходы на интеграцию по сравнению с построением с использованием отдельных служб PaaS.

Источник↗

В рамках Microsoft Fabric требуется единый артефакт для хранения данных в открытом формате Delta Lake, который может быть доступен как движками Spark (для инженерии данных), так и движками SQL (для BI).

→Используйте Microsoft Fabric Lakehouse.

Почему: Lakehouse — это основной архитектурный шаблон в Fabric. Он сочетает масштабируемость и гибкость озера данных с гарантиями транзакций и возможностями SQL-запросов хранилища данных.

Отчет Power BI в Microsoft Fabric должен запрашивать большие объемы данных напрямую из OneLake с производительностью режима импорта, но с актуальностью данных DirectQuery.

→Используйте режим Direct Lake в Power BI.

Почему: Direct Lake — это уникальная функция Fabric, которая загружает файлы Parquet/Delta непосредственно в память движка Power BI по требованию, избегая дублирования данных и задержки запросов, обеспечивая при этом доступ к данным в почти реальном времени.

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

→Используйте Power BI.

Почему: Power BI — это служба бизнес-аналитики Microsoft для создания интерактивных визуализаций данных. Используйте Power BI Desktop для создания и Power BI Service для совместного использования и сотрудничества.

Разграничение между многостраничным интерактивным анализом и одностраничным общим обзором в Power BI.

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

Почему: Отчеты предназначены для глубокого анализа. Панели мониторинга предназначены для отслеживания ключевых показателей.

Единый отчет Power BI должен быть доступен нескольким пользователям, но каждый пользователь должен видеть только те данные, которые относятся к нему (например, менеджер по продажам видит только данные своего региона).

→Реализуйте безопасность на уровне строк (RLS).

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

Необходимо генерировать высокоформатированные, пиксель-идеальные отчеты (например, счета-фактуры или финансовые отчеты), оптимизированные для печати или экспорта в PDF.

→Используйте Power BI Paginated Reports.

Почему: Отчеты с разбивкой на страницы предназначены для макетов, готовых к печати, с точным контролем над заголовками, нижними колонтитулами и разрывами страниц, в отличие от стандартных интерактивных отчетов Power BI, которые предназначены для просмотра на экране.

Обновление набора данных Power BI, содержащего миллиарды строк, занимает слишком много времени. Только данные за последние несколько дней часто меняются.

→Настройте инкрементное обновление для набора данных.

Почему: Инкрементное обновление разбивает данные на разделы (обычно по дате) и обновляет только самые последние разделы, что значительно сокращает время обновления и использование ресурсов для больших наборов данных.

Единый отчет Power BI должен комбинировать предварительно загруженные, высокопроизводительные данные (режим Import) с данными в реальном времени из операционного источника (режим DirectQuery).

→Используйте составные модели Power BI.

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

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

→Используйте Microsoft Purview.

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