Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Предприятия, управляемые данными, должны синхронизировать бэкэндовые и аналитические системы с пользовательскими приложениями практически в реальном времени. Последствия транзакций, обновлений и изменений должны точно отражаться в комплексных процессах, связанных приложениях и системах обработки транзакций в Сети (OLTP). Терпимая задержка изменений в приложениях OLTP для отражения в подчиненных системах, использующих данные, может быть всего несколько минут.
В этой статье описывается комплексное решение для обработки данных почти в режиме реального времени для синхронизации данных Lakehouse. Решение использует Центры событий Azure, Azure Synapse Analytics и Azure Data Lake Storage для обработки и анализа данных.
Замечание
Вы можете реализовать аналогичную архитектуру с помощью Microsoft Fabric, которая предоставляет единую платформу программного обеспечения как услуги (SaaS) для приема данных, преобразования, хранения и аналитики. В этом случае Fabric заменяет компоненты Azure Synapse Analytics архитектуры и предоставляет интегрированные возможности для обработки и анализа данных в режиме реального времени. Для получения дополнительной информации см. "Интеллект в реальном времени для Fabric".
Apache® и Apache Spark являются зарегистрированными товарными знаками или товарными знаками Apache Software Foundation в США и /или других странах. Использование этих меток не подразумевает подтверждения от Apache Software Foundation.
Архитектура
Скачайте файл Visio этой архитектуры.
Поток данных
Следующий поток данных соответствует предыдущей схеме:
Сбор изменяющихся данных (CDC) является необходимым условием для мониторинга изменений в исходных системах. Соединители Debezium могут подключаться к разным исходным системам и отслеживать изменения по мере их возникновения. Соединители могут записывать изменения и создавать события из различных систем управления реляционными базами данных (RDBMS). Для установки соединителя Debezium требуется система подключения Kafka.
Соединители извлекают измененные данные и отправляют захваченные события в Центры событий. Центры событий могут получать большие объемы данных из нескольких источников.
Центры событий напрямую передают данные в пулы Spark Azure Synapse Analytics или отправляют данные в целевую зону Data Lake Storage в необработанном формате.
Другие пакетные источники данных могут использовать конвейеры Azure Synapse Analytics для копирования данных в Data Lake Storage и сделать их доступными для обработки. Комплексный рабочий процесс извлечения, преобразования и загрузки (ETL) может потребовать последовательного выполнения различных этапов или создания зависимостей между этапами. Конвейеры Azure Synapse Analytics могут управлять зависимостями рабочих процессов в общей платформе обработки.
Пулы Spark Azure Synapse Analytics используют полностью поддерживаемые структурированные потоковые API Apache Spark для обработки данных в структурированном потоковом фреймворке Spark. Этап обработки данных включает проверки качества данных и высокоуровневые проверки бизнес-правил.
Data Lake Storage сохраняет проверенные данные в открытом формате Delta Lake . Delta Lake обеспечивает атомарность, согласованность, изоляцию и устойчивость (ACID), а также транзакции, масштабируемую обработку метаданных и единую потоковую передачу и пакетную обработку данных для существующих озер данных.
Использование индексов для ускорения запросов повышает производительность Delta Lake. Данные из проверенной зоны Data Lake Storage также могут быть источником для дальнейшего расширенного анализа и машинного обучения.
Данные из валидированной зоны хранилища данных Data Lake, преобразованные и обогащенные дополнительными правилами в конечное обработанное состояние, загружаются в выделенный пул SQL для выполнения масштабных аналитических запросов.
Power BI использует данные, предоставляемые через выделенный пул SQL, для создания панелей мониторинга и отчетов корпоративного уровня.
Вы также можете использовать необработанные данные в Data Lake Storage и проверенные данные в разностном формате для следующих задач:
Непредусмотренный и исследовательский анализ через бесcерверные пулы SQL в Azure Synapse Analytics
Обучение и развертывание модели машинного обучения с помощью Машинного обучения Azure
Для некоторых интерфейсов с низкой задержкой данные должны быть денормализованы для достижения задержек в пределах однозначных миллисекунд на сервере. Этот вариант использования в основном предназначен для ответов API. Этот сценарий запрашивает документы в хранилище данных NoSQL, например, Azure Cosmos DB, с временем отклика в пределах одноразрядных миллисекунд.
Стратегия секционирования Azure Cosmos DB может не поддерживать все шаблоны запросов. Если это так, вы можете расширить решение, индексируя данные, к которым api-интерфейсы должны получить доступ с помощью поиска ИИ Azure. Azure Cosmos DB и поиск ИИ могут выполнять большинство сценариев, требующих ответов запросов с низкой задержкой. Например, в розничном приложении хранятся данные каталога продуктов в Azure Cosmos DB, но требуются возможности полнотекстового поиска и гибкое индексирование. Поиск ИИ может индексировать данные и предоставлять расширенные функции поиска, такие как автозавершение, синонимы и семантический ранжирование. Эти функции полезны, если ограничения индексирования Azure Cosmos DB ограничивают сложные сценарии поиска.
Компоненты
Это решение использует следующие компоненты Azure:
Центры событий — это управляемая распределенная служба приема данных, которая может масштабироваться до приема больших объемов данных. Используя механизм издателя Центров событий, различные приложения могут отправлять сообщения в разделы Центров событий, а подчиненные потребители могут подключаться к этим сообщениям и обрабатывать их. Функция отслеживания Центров событий может записывать сообщения в Data Lake Storage в формате Avro по мере их поступления. Эта возможность обеспечивает простую микро пакетную обработку и долгосрочные сценарии хранения. Центры событий также предоставляют API, совместимый с Kafka, и поддерживает реестр схем. В этой архитектуре Центры событий получают события CDC из нескольких источников и распределяют их для подчиненных потребителей.
Data Lake Storage — это масштабируемое и безопасное решение озера данных. Она формирует подсистему хранения, которая хранит все данные в необработанных и проверенных форматах. В этой архитектуре Data Lake Storage обрабатывает транзакции в масштабе и поддерживает различные форматы и размеры файлов. Иерархические пространства имен помогают организовывать данные в привычную структуру каталогов и поддерживают разрешения POSIX (Portable Operating System Interface для Unix). Драйвер Файловой системы BLOB-объектов Azure (ABFS) предоставляет API, совместимый с Hadoop.
Azure Synapse Analytics — это бесграничная служба аналитики, которая объединяет интеграцию данных, хранение корпоративных данных и аналитику больших данных. Это решение использует следующие функции экосистемы Azure Synapse Analytics:
Azure Synapse Analytics Spark пулы — это кластеры, которые предоставляют среду выполнения Spark по требованию, включающую встроенные улучшения производительности для Spark с открытым исходным кодом. В этой архитектуре клиенты могут настраивать гибкие параметры автомасштабирования, отправлять задания удаленно через конечную точку Apache Livy и использовать интерфейс записной книжки Synapse Studio для интерактивного взаимодействия.
Бессерверные пулы SQL в Azure Synapse Analytics — это функция запросов по требованию, которая предоставляет интерфейс для выполнения запросов к данным lakehouse с использованием знакомого синтаксиса T-SQL. Отсутствует необходимость в настройке инфраструктуры, а развертывание рабочей области Azure Synapse Analytics автоматически создает конечную точку. В этой архитектуре бессерверные пулы SQL Azure Synapse Analytics обеспечивают базовое обнаружение и изучение данных на месте для незапланированного анализа запросов.
Выделенные SQL-пулы Azure Synapse Analytics — это предоставленные ресурсы для хранения данных. Они хранят данные в реляционных таблицах с помощью хранилища столбцов. В этой архитектуре выделенные пулы SQL используют масштабируемую архитектуру для распределения обработки данных между несколькими узлами. Запросы PolyBase переносят данные в таблицы пула SQL. Таблицы могут подключаться к Power BI для анализа и отчетности.
Power BI — это служба бизнес-аналитики, которая предоставляет визуальный интерфейс для создания и доступа к отчетам и панелям мониторинга. Power BI Desktop может подключаться к различным источникам данных, объединять источники в модель данных и создавать отчеты или панели мониторинга. В этой архитектуре можно использовать Power BI для преобразования данных на основе бизнес-требований и совместного использования визуальных элементов и отчетов клиентами.
Azure Cosmos DB — это глобально распределенная служба базы данных NoSQL. Это решение использует базу данных Azure Cosmos DB для приложений, требующих задержек отклика в пределах нескольких миллисекунд и высокой доступности. Azure Cosmos DB предоставляет возможность записи в нескольких регионах во всех регионах Azure.
Поиск ИИ — это платформа, основанная на искусственном интеллекте как услуга (PaaS), которая позволяет разработчикам создавать широкие возможности поиска для своих приложений и веб-сайтов. Используйте поиск ИИ в этом решении, если модель индексирования Azure Cosmos DB слишком жестка для расширенных сценариев поиска. Поиск ИИ обеспечивает гибкие запросы с такими функциями, как терпимость к опечаткам, автозавершение, семантический ранжирование и сопоставление синонимов. Индексированные данные можно запрашивать с помощью REST API или пакета SDK для .NET. Если необходимо получить данные из нескольких индексов, их можно объединить в один индекс или использовать сложные типы данных для моделирования вложенных структур.
Подробности сценария
Для обработки изменений практически в реальном времени требуется сквозный рабочий процесс:
Технология CDC. Приложения OLTP могут иметь разные внутренние хранилища данных, такие как SQL Server, MySQL и Oracle. Первый шаг заключается в том, чтобы отслеживать изменения по мере их возникновения и распространять их дальше.
Буфер приема для публикации событий изменений в большом масштабе. Эта служба должна иметь возможность обрабатывать большие объемы данных по мере поступления сообщений. Отдельные подписчики могут подключаться к этой системе и обрабатывать данные.
Распределенное и масштабируемое хранилище для данных как есть в необработанном формате.
Распределенная, эффективная система потоковой обработки, которая позволяет пользователям перезапускать систему и управлять состоянием.
Система аналитики, работающая в масштабе, чтобы поддерживать бизнес-решения.
Интерфейс самостоятельной аналитики.
Для обеспечения низкой задержки ответов API следует использовать базу данных NoSQL для хранения денормализованных представлений данных.
В некоторых случаях система индексирует данные, обновляет индекс с регулярными интервалами и делает последние данные доступными для нижнего потребления.
Все предыдущие технологии должны использовать соответствующие конструкции безопасности для безопасности периметра, проверки подлинности, авторизации и шифрования данных.
Потенциальные варианты использования
Это решение подходит для следующих вариантов использования:
Отрасли, которые должны распространять изменения из OLTP в онлайн аналитическую обработку (OLAP).
Приложения, требующие преобразования или обогащения данных.
Сценарий обработки данных в режиме реального времени особенно важен для отраслей финансовых услуг. Например, если клиент страхования, кредитной карты или банка выполняет оплату, а затем немедленно обращается к службе клиентов, агент поддержки клиентов должен иметь последнюю информацию.
Аналогичные сценарии применяются к секторам розничной торговли, торговли и здравоохранения. Включение этих сценариев упрощает операции и приводит к повышению производительности организации и повышению удовлетворенности клиентов.
Рекомендации
Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в Хорошо спроектированной архитектурной модели.
Надежность
Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. контрольный список проверки проектирования на надежность.
Центры событий обеспечивают 90-дневное хранение данных на уровнях "Премиум" и "Выделенные". В сценариях отказоустойчивости вы можете настроить резервное пространство имен в парном регионе и активировать его во время сбоя. Включите избыточность зоны, чтобы обеспечить устойчивость к сбоям центра обработки данных. Вы можете использовать функцию сбора центров событий для сохранения данных в Data Lake Storage для сценариев воспроизведения и восстановления.
Задания пула Spark в Azure Synapse Analytics перезапускаются каждые семь дней, так как узлы отключаются для обслуживания. Рассмотрим это действие при работе с целями уровня обслуживания (SLOS), связанными с системой. Это ограничение не является проблемой для многих сценариев, когда цель времени восстановления (RTO) составляет около 15 минут. Убедитесь, что автомасштабирование настроено для обработки пиков нагрузки и сбоев узлов.
Используйте выделенные пулы SQL, имеющие георезервное копирование и хранилище с избыточностью между зонами (ZRS) для защиты от региональных и зональных сбоев.
Оптимизация затрат
Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проверки дизайна для оптимизации затрат.
Вы можете выбрать разные уровни Центров событий на основе характеристик рабочей нагрузки. Центры событий выставляют счета за хранилище данных отдельно на основе объема данных, хранящихся в Data Lake Storage.
Рассмотрим управление жизненным циклом объектов с помощью уровней в Data Lake Storage. По мере возраста данных можно перемещать данные из горячего уровня, где необходимо получить доступ к последним данным для аналитики, на холодный уровень хранилища, который стоит меньше. Уровень холодного хранилища является экономичным вариантом долгосрочного хранения.
Вы можете приостановить выделенный пул SQL, если вы не используете его в средах разработки или тестирования. Вы можете запланировать сценарий для приостановки пула по мере необходимости или приостановить пул вручную на портале.
Для пулов Spark в Azure Synapse Analytics используйте автоматическое масштабирование для динамического выделения ресурсов на основе спроса на рабочую нагрузку и для предотвращения чрезмерного резервирования. Выберите наименьший размер пула, соответствующий потребностям производительности, и используйте параметры автоматического завершения, чтобы быстро завершить работу пулов бездействия. Оптимизация заданий Spark путем минимизации операций перетасовки, кэширования промежуточных результатов и настройки размеров секций для уменьшения времени выполнения и потребления ресурсов. Отслеживайте использование с помощью средств мониторинга Azure Synapse Analytics и настраивайте конфигурации на основе тенденций производительности заданий и затрат.
Чтобы оптимизировать экономичность в Azure Cosmos DB, настройте политики индексирования, чтобы включить только необходимые пути, что снижает потребление единиц хранения и единиц запросов (ЕЗ). Выберите соответствующий API и уровень согласованности, чтобы соответствовать потребностям рабочей нагрузки без избыточного резервирования. Используйте пропускную способность автомасштабирования для динамической настройки RUs на основе спроса и сокращения количества контейнеров, по возможности, чтобы свести к минимуму накладные расходы. Регулярно отслеживайте использование с помощью Управление затратами Microsoft и настраивайте оповещения, чтобы избежать непредвиденных расходов.
Используйте калькулятор цен Azure для оценки цен.
Эффективность производительности
Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Дополнительные сведения см. в разделе контрольного списка для проверки проектирования на эффективность производительности.
Центры событий можно масштабировать с помощью секционирования, которая распределяет события между несколькими параллельными журналами (секциями) для повышения пропускной способности. Чтобы сохранить порядок связанных событий, таких как события одного клиента или устройства, используйте согласованный ключ секции при публикации событий. Эта практика гарантирует, что все связанные события направляются в одну секцию, где Центры событий поддерживают их порядок. Настройте единицы пропускной способности (ТПЕ) на основе ожидаемого объема событий. Используйте функцию записи для записи непосредственно в Data Lake Storage в формате Avro или Parquet для эффективной последующей обработки.
Вы можете настроить пулы Spark в Azure Synapse Analytics, используя виртуальные машины (VM) с небольшими, средними или большими типами в зависимости от рабочей нагрузки. Вы также можете настроить автомасштабирование для пулов Spark в Azure Synapse Analytics, чтобы учитывать спайки активности в рабочих нагрузках. Если требуется больше вычислительных ресурсов, кластеры автоматически масштабируются до удовлетворения спроса и обратно уменьшатся после завершения обработки.
Delta Lake играет центральную роль в обеспечении высокопроизводительной, надежной и масштабируемой обработки данных в этой архитектуре:
Включите функции автоматической оптимизации и автоматического сжатия в Delta Lake для автоматического управления небольшими файлами и оптимизации макета данных во время операций записи. Эти функции идеально подходят для потоковой передачи или частых сценариев приема микропакетов, так как они снижают потребность в ручном вмешательстве.
Используйте
OPTIMIZEдля ручного сжатия небольших файлов в более крупные. Эта практика особенно полезна, если вы хотите повысить эффективность чтения и сократить затраты на метаданные после того, как потоковая загрузка создает множество небольших файлов.Используйте
OPTIMIZEсZORDER BYна часто запрашиваемых столбцах, таких как метки времени или идентификаторы клиентов, для объединения связанных данных. Этот запрос повышает производительность запросов, уменьшая объем данных, которые сканируются во время чтения.
Чтобы оптимизировать производительность в выделенных пулах SQL для аналитики в режиме реального времени, выполните следующие задачи:
- Используйте соответствующие методы распространения, такие как хэш, циркуляция по кругу, реплицированные методы.
- Секционирование больших таблиц по времени или регионам для улучшения обрезки запросов.
- Используйте материализованные представления и кэширование результирующих наборов для часто доступных данных.
- Сохраняйте статистику и индексы up-to-date для эффективного выполнения запросов.
- Назначьте классы ресурсов для управления памятью и параллелизмом.
- Отслеживайте производительность с помощью встроенных средств, таких как SQL Insights и динамические административные представления (DMV).
Эти методики помогают обеспечить низкую задержку, высокую пропускную способность в крупномасштабных аналитических рабочих нагрузках.
Чтобы оптимизировать Azure Cosmos DB для повышения производительности в сценариях аналитики в режиме реального времени, настройте соответствующие политики индексирования для снижения задержки запросов и затрат на хранение и выберите правильный уровень согласованности, чтобы сбалансировать производительность с точностью данных. Используйте секционирование эффективно для равномерного распределения рабочих нагрузок и предотвращения горячих секций. Включите операции записи для нескольких регионов, чтобы обеспечить глобальный доступ с низкой задержкой и отслеживать пропускную способность, используя единицы RUs для динамического масштабирования в зависимости от спроса. Эти методики помогают обеспечить быструю, масштабируемую эффективность для рабочих нагрузок с высоким уровнем поступления данных и низкой задержкой.
Соавторы
Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.
Основной автор:
- Пратима Валавала | Архитектор облачных решений
Другой участник:
- Раджеш Миттал | Архитектор облачных решений
Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Масштабируемость с помощью Центров событий
- Индексирование данных из Azure Cosmos DB
- Рекомендации по выделенным пулам SQL
- Рекомендации по использованию бессерверных пулов SQL
- Создание решений аналитики данных с помощью бессерверных пулов SQL Azure Synapse Analytics
- Выполнение запросов озера данных или Lakehouse с использованием бессерверных SQL-пулов в Azure Synapse Analytics