Предприятия, управляемые данными, должны поддерживать свои внутренние и аналитические системы в практически реальном времени синхронизации с клиентскими приложениями. Влияние транзакций, обновлений и изменений должно точно отражаться в комплексных процессах, связанных приложениях и системах обработки транзакций в Сети (OLTP). Терпимая задержка изменений в приложениях OLTP для отражения в подчиненных системах, использующих данные, может быть всего за несколько минут.
В этой статье описывается комплексное решение для обработки данных почти в режиме реального времени для синхронизации данных Lakehouse. Решение использует Центры событий Azure, Azure Synapse Analytics и Azure Data Lake Storage для обработки и анализа данных.
Apache® и Apache Spark являются зарегистрированными товарными знаками или товарными знаками Apache Software Foundation в США и/или других странах. Использование этих меток не подразумевает подтверждения от Apache Software Foundation.
Архитектура
Скачайте файл Visio для этой архитектуры.
Поток данных
Сбор измененных данных является обязательным условием для прослушивания изменений в исходных системах. Соединители Debezium могут подключаться к разным исходным системам и касаться изменений по мере их выполнения. Соединители могут записывать изменения и создавать события из различных систем управления реляционными базами данных (RDBMS). Для установки соединителя Debezium требуется система подключения Kafka.
Соединители извлекают данные об изменениях и отправляют захваченные события в Центры событий Azure. Центры событий могут получать большие объемы данных из нескольких источников.
Центры событий напрямую передают данные в пулы Spark Azure Synapse Analytics или могут отправлять данные в целевую зону Azure Data Lake Storage в необработанном формате.
Другие источники данных пакетной службы могут использовать конвейеры Azure Synapse для копирования данных в Data Lake Storage и сделать его доступным для обработки. Комплексный рабочий процесс извлечения, преобразования и загрузки (ETL) может потребоваться выполнить цепочку различных шагов или добавить зависимости между шагами. Конвейеры Azure Synapse могут оркестрировать зависимости рабочих процессов в общей платформе обработки.
Пулы Azure Synapse Spark используют полностью поддерживаемые API структурированной потоковой передачи Apache Spark для обработки данных в платформе потоковой передачи Spark. Этап обработки данных включает проверки качества данных и высокоуровневые проверки бизнес-правил.
Data Lake Storage сохраняет проверенные данные в открытом формате Delta Lake . Delta Lake обеспечивает атомарность, согласованность, изоляцию и устойчивость (ACID), а также транзакции, масштабируемую обработку метаданных и единую потоковую передачу и пакетную обработку данных для существующих озер данных.
Использование индексов для ускорения запросов расширяет Delta с дальнейшими улучшениями производительности. Данные из проверенной зоны Data Lake Storage также могут быть источником для дальнейшего расширенного анализа и машинного обучения.
Данные из проверенной зоны Data Lake Storage, преобразованные и обогащенные с дополнительными правилами в окончательно обработанном состоянии, загружаются в выделенный пул SQL для выполнения крупномасштабных аналитических запросов.
Power BI использует данные, предоставляемые через выделенный пул SQL, для создания панелей мониторинга и отчетов корпоративного уровня.
Вы также можете использовать захваченные необработанные данные в целевой зоне Data Lake Store и проверенные данные в разностном формате:
- Дальнейший нерегламентированный и исследовательский анализ с помощью бессерверных пулов Azure Synapse SQL.
- Машинное обучение с помощью Машинное обучение Azure.
Для некоторых интерфейсов с низкой задержкой данные должны быть денормализованы для задержки однозначного сервера. Этот сценарий использования в основном предназначен для ответов API. Этот сценарий запрашивает документы в хранилище данных NoSQL, например Azure Cosmos DB, для однозначных миллисекунда ответов.
Стратегия секционирования Azure Cosmos DB может не поддаваться всем шаблонам запросов. Если это так, вы можете расширить решение, индексируя данные, к которым api-интерфейсы должны получить доступ с помощью Когнитивный поиск Azure. Azure Cosmos DB и Когнитивный поиск могут выполнять большинство сценариев, требующих ответов запросов с низкой задержкой.
Компоненты
Это решение использует следующие компоненты Azure:
Центры событий — это управляемая распределенная служба приема данных, которая может масштабироваться до приема больших объемов данных. С помощью механизма подписчика-издателя Центров событий различные приложения могут отправлять сообщения в разделы в Центрах событий, а подчиненные потребители могут подключаться к сообщениям и обрабатывать их. Функция отслеживания центров событий может записывать сообщения в Data Lake Storage в формате AVRO по мере их поступления. Эта возможность обеспечивает простую микро пакетную обработку и долгосрочные сценарии хранения. Центры событий также предлагают API, совместимый с Kafka, и поддерживает реестр схем.
Data Lake Storage формирует подсистему хранения, которая хранит все данные в необработанных и проверенных форматах. Data Lake Storage может обрабатывать транзакции в масштабе и поддерживать различные форматы и размеры файлов. Иерархические пространства имен помогают упорядочивать данные в знакомую структуру папок и поддерживать разрешения переносимой операционной системы для разрешений UniX (POSIX). Драйвер файловой системы BLOB-объектов Azure (ABFS) предлагает API, совместимый с Hadoop.
Azure Synapse Analytics — это безграничная служба аналитики, которая объединяет интеграцию данных, хранение корпоративных данных и аналитику больших данных. Это решение использует следующие функции экосистемы Azure Synapse Analytics:
Пулы Azure Synapse Spark предлагают среду выполнения Spark по запросу, которая добавляет встроенные улучшения производительности в Spark с открытым исходным кодом. Клиенты могут настраивать гибкие параметры автомасштабирования, отправлять задания удаленно через конечную точку Apache Livy и использовать интерфейс записной книжки Synapse Studio для интерактивных возможностей.
Бессерверные пулы AZURE Synapse SQL предоставляют интерфейс для запроса данных Lakehouse с помощью знакомого синтаксиса T-SQL. Инфраструктура не настроена, а развертывание рабочей области Azure Synapse автоматически создает конечную точку. Бессерверные пулы AZURE Synapse SQL позволяют выполнять базовое обнаружение и изучение данных, а также являются хорошим вариантом для анализа пользовательских нерегламентированных запросов.
Выделенные пулы SQL Azure Synapse хранят данные в реляционных таблицах с хранилищем столбцов. Выделенные пулы SQL используют архитектуру горизонтального масштабирования для распределения обработки данных между несколькими узлами. Запросы PolyBase переносят данные в таблицы пула SQL. Таблицы могут подключаться к Power BI для анализа и отчетности.
Power BI предоставляет визуальный интерфейс для создания отчетов и панелей мониторинга и доступа к ней. Power BI Desktop может подключаться к различным источникам данных, объединять источники в модель данных и создавать отчеты или панели мониторинга. С помощью Power BI можно преобразовать данные на основе бизнес-требований и предоставить доступ к визуальным элементам и отчетам другим пользователям с помощью служба Power BI.
Azure Cosmos DB — это управляемая многомодальная база данных NoSQL, которая поддерживает открытые API, такие как MongoDB и Cassandra. Это решение использует Azure Cosmos DB для приложений, требующих однозначных миллисекунд откликов и высокой доступности. Azure Cosmos DB предлагает многорегионную запись во всех регионах Azure. Azure Synapse Link для Azure Cosmos DB можно использовать для получения аналитических сведений и запуска аналитики по данным в режиме реального времени.
Когнитивный поиск Azure — это облачная служба поиска, которая может индексировать данные, необходимые приложениям и API. Когнитивный поиск имеет необязательные функции обогащения ИИ, которые помогают с извлечением текста и выводом текста из нетекстовых файлов. Когнитивный поиск интегрируется со службами, такими как Azure Data Lake Storage и Azure Cosmos DB, чтобы легко получить доступ к данным и индексировать их. Индексированные данные можно запросить с помощью REST API или пакета SDK для .NET. Чтобы получить данные из двух отдельных индексов, их можно объединить в один индекс или использовать сложные типы данных.
Подробности сценария
Для обработки изменений практически в реальном времени требуется сквозный рабочий процесс:
- Технология отслеживания измененных данных (CDC). Приложения OLTP могут иметь разные внутренние хранилища данных, такие как SQL Server, MySQL и Oracle. Первый шаг заключается в том, чтобы прослушивать изменения по мере их выполнения и распространять их вперед.
- Буфер приема для публикации событий изменений в масштабе. Эта служба должна иметь возможность обрабатывать большие объемы данных по мере поступления сообщений. Отдельные подписчики могут подключаться к этой системе и обрабатывать данные.
- Распределенное и масштабируемое хранилище для данных как есть в необработанном формате.
- Распределенная, эффективная система потоковой обработки, которая позволяет пользователям перезапускать состояние и управлять ими.
- Система аналитики, которая выполняется в масштабе для принятия бизнес-решений.
- Интерфейс самостоятельной аналитики.
- Для ответов API с низкой задержкой база данных NoSQL для хранения денормализованного представления данных.
- В некоторых случаях система индексирует данные, обновляет индекс с регулярными интервалами и делает последние данные доступными для нижнего потребления.
Все предыдущие технологии должны использовать соответствующие конструкции безопасности для безопасности периметра, проверки подлинности, авторизации и шифрования данных.
Потенциальные варианты использования
Это решение хорошо подходит для:
- Отрасли, которые должны распространять изменения из OLTP в обработку онлайн-аналитики (OLAP).
- Приложения, требующие преобразования или обогащения данных.
Сценарий обработки данных в режиме реального времени особенно важен для отраслей финансовых услуг. Например, если клиент страхования, кредитной карты или банка выполняет оплату, а затем немедленно обращается к службе клиентов, агент поддержки клиентов должен иметь последнюю информацию.
Аналогичные сценарии применяются к секторам розничной торговли, торговли и здравоохранения. Включение этих сценариев упрощает операции, что приводит к повышению производительности организации и повышению удовлетворенности клиентов.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".
Центры событий предлагают 90-дневное хранение данных на уровнях "Премиум" и "Выделенные". В сценариях отработки отказа можно настроить дополнительное пространство имен в парном регионе и активировать его во время отработки отказа.
Задания пула Azure Synapse Spark перезапускаются каждые семь дней, так как узлы удаляются для обслуживания. Рассмотрим это действие при работе с соглашениями об уровне обслуживания (SLA), связанными с системой. Это ограничение не является проблемой для многих сценариев, когда целевое время восстановления (RTO) составляет около 15 минут.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
Вы можете выбрать разные уровни Центров событий на основе характеристик рабочей нагрузки. Центры событий оплачивают хранение отдельно на основе объема данных, хранящихся в Data Lake Storage.
Рассмотрим управление жизненным циклом объектов с помощью уровней в Azure Data Lake Storage. По мере возраста данных можно перемещать данные из горячего уровня, где необходимо получить доступ к последним данным для аналитики, на холодный уровень хранилища, который значительно ниже. Уровень холодного хранилища является экономичным вариантом долгосрочного хранения.
Вы можете приостановить выделенный пул SQL, если вы не используете его в средах разработки или тестирования. Вы можете запланировать сценарий для приостановки пула по мере необходимости или приостановить пул вручную на портале.
Azure Cosmos DB предлагает различные модели подготовки, такие как бессерверная, подготовленная вручную пропускная способность и автомасштабирование. Рекомендуется использовать бессерверную подготовку для рабочих нагрузок разработки и тестирования. Вы также можете использовать автомасштабирование, где можно задать максимальное количество единиц запросов в секунду (ЕЗ/с) в контейнере. Пропускная способность контейнера масштабируется автоматически в диапазоне от 10% от максимального ЕЗ/с в качестве нижнего порога и максимально настроенного ЕЗ/с.
Оптимизация производительности
Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".
Центры событий можно масштабировать с помощью секционирования. Рассмотрите возможность секционирования данных, чтобы сохранить порядок событий с помощью журнала фиксации. Секционирование позволяет создавать несколько параллельных журналов, максимизируя доступную емкость пропускной способности.
Пулы Azure Synapse Spark можно настроить с небольшими, средними или крупными номерами SKU виртуальных машин на основе рабочей нагрузки. Вы также можете настроить автоматическое масштабирование в пулах Azure Synapse Spark для учетной записи для спичных рабочих нагрузок. Если требуется больше вычислительных ресурсов, кластеры автоматически масштабируется в соответствии с требованиями и масштабируется после завершения обработки.
Используйте рекомендации по проектированию таблиц в выделенном пуле SQL. Применяются связанные ограничения производительности и масштабируемости на основе уровня, на котором работает пул SQL.
Azure Cosmos DB использует секции для масштабирования контейнеров на основе ключа секции. Все данные на основе ключа секции образуют логическую секцию. Убедитесь, что выбрана правильная стратегия секционирования на основе требований рабочей нагрузки. Также можно использовать индексы для ускорения извлечения данных.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Пратима Валавала | Архитектор облачных решений
Другой участник:
- Раджеш Миттал | Архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- соединитель Центры событий Azure для Apache Spark
- Масштабируемость с помощью Центров событий
- Индексирование данных из Azure Cosmos DB
- Что такое Azure Synapse Link для Azure Cosmos DB?
- Рекомендации по использованию выделенного пула SQL
- Рекомендации по использованию бессерверного пула SQL
- Модель, запрос и изучение данных в Azure Synapse
- Создание решений аналитики данных с помощью бессерверных пулов SQL Azure Synapse