Поделиться через

Стиль архитектуры больших данных

Архитектура больших данных предназначена для обработки приема, обработки и анализа данных, слишком больших или сложных для традиционных систем баз данных.

Логическая схема стиля архитектуры больших данных.

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

  • Пакетная обработка неактивных источников больших данных
  • Обработка больших данных в режиме реального времени в движении
  • Интерактивное изучение больших данных
  • Прогнозная аналитика и машинное обучение

Большинство архитектур больших данных включают некоторые или все следующие компоненты:

  • Источники данных: Решения для больших данных могут начинаться с одного или нескольких источников данных.

    • Хранилища данных, такие как реляционные базы данных

    • Файлы, которые создают приложения, такие как файлы журнала веб-сервера и ответы API

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

  • Хранилище данных: Данные для операций пакетной обработки обычно хранятся в распределенном хранилище файлов, которое может содержать большие объемы больших файлов в различных форматах. Такое хранилище часто называется озером данных. Варианты реализации этого хранилища включают Azure Data Lake Storage или Microsoft Fabric OneLake.

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

  • Обработка в режиме реального времени: Если решение включает источники в режиме реального времени, архитектура должна включать способ записи и хранения сообщений в режиме реального времени для потоковой обработки. Данные могут оставаться в движении с момента ее создания с помощью его очистки, преобразования и последующего использования в операционных или аналитических действиях. Многие решения должны поддерживать масштабируемую обработку, надежную доставку и другую семантику очереди сообщений. К ним относятся события Fabric Real-Time Intelligence, Центры событий Azure, Центр Интернета вещей Azure и Apache Kafka.

  • Аналитическое хранилище данных: Многие решения больших данных подготавливают данные для анализа, а затем служат обработанным данным в структурированном формате, который можно запрашивать с помощью аналитических средств. В зависимости от вашего сценария аналитическое хранилище данных, используемое для обслуживания этих запросов, может быть хранилищем событий в Microsoft Fabric для обработки данных в движении, а поток обрабатывается во время полета. Или это может быть объемное хранилище данных, как показано в большинстве традиционных решений бизнес-аналитики (BI) или lakehouse (Бронза, Silver и Gold). Microsoft Fabric предоставляет несколько вариантов, таких как центры событий, склады и озера. Каждый вариант можно запрашивать с помощью SQL или Spark в зависимости от варианта использования. Используйте руководство по принятию решений по хранилищу данных Fabric , чтобы помочь вам принять решение.

  • Анализ и отчеты: Одной из целей решений данных должно быть предоставление аналитических сведений о данных с помощью анализа и создания отчетов. Чтобы пользователи могли анализировать данные, архитектура может включать уровень моделирования данных, например многомерную интерактивную аналитическую обработку (OLAP) или табличную модель данных в Службах Azure Analysis Services. Она также может поддерживать самостоятельную бизнес-аналитику с помощью технологий моделирования и визуализации в Power BI или Excel. Анализ и отчеты также могут принимать форму интерактивного исследования данных специалистами по обработке и анализу данных. В этих сценариях Microsoft Fabric предоставляет такие инструменты, как записные книжки, где пользователи могут выбрать SQL или язык программирования по своему выбору.

  • Действия и оповещения: Еще одной целью решения больших данных должно быть предоставление оперативной информации о текущем состоянии бизнес-процесса. Архитектура должна включать уровень системы действий, который принимает потоки данных в режиме реального времени в процессе обработки и обнаруживает исключения и аномалии, происходящие в организации. Вместо проверки отчета можно использовать эти системы оповещений для упреждающего уведомления пользователей и руководства об аномальных действиях. оповещения активатора аналитики Real-Time обеспечивают такой упреждающий мониторинг.

  • Оркестровка: Решения больших данных могут состоять из повторяющихся операций обработки данных, инкапсулированных в рабочих процессах. Эти рабочие процессы преобразуют исходные данные, перемещают данные между несколькими источниками и приемниками, загружают обработанные данные в аналитическое хранилище данных или передают результаты непосредственно в отчет или панель мониторинга. Для автоматизации этих рабочих процессов можно использовать технологию оркестрации, например конвейеры Фабрики данных Azure или Microsoft Fabric.

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

  • Решения SaaS( программное обеспечение как услуга), такие как Microsoft Fabric

  • Управляемые службы, такие как Data Lake Storage, Azure Stream Analytics, Центры событий, Центр Интернета вещей, Фабрика данных Azure, База данных SQL Azure и Azure Cosmos DB

Когда следует использовать эту архитектуру

Рассмотрим этот стиль архитектуры, когда необходимо выполнить следующие действия:

  • Действовать на основе данных в режиме реального времени при создании данных.
  • Хранение и обработка данных в томах слишком большой для традиционной базы данных.
  • Преобразование неструктурированных данных для анализа и отчетности.
  • Используйте службы Машинного обучения Azure или Azure AI.

Преимущества

  • Варианты технологий: Microsoft Fabric предоставляет многие из этих служб через интерфейс SaaS и подключает различные компоненты заранее. Этот подход упрощает процесс создания комплексных решений для обработки данных. Вы также можете смешивать и сопоставлять управляемые службы Azure, чтобы воспользоваться существующими навыками или технологическими инвестициями.

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

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

  • Взаимодействие с существующими решениями: Компоненты архитектуры больших данных также используются для обработки Интернета вещей и корпоративных решений бизнес-аналитики. Эта гибкость позволяет создавать интегрированное решение для рабочих нагрузок данных.

Сложности

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

  • Безопасность: Решения больших данных обычно используют хранение всех статических данных в централизованном озере данных. Защита доступа к этим данным может быть сложной задачей, особенно если несколько приложений и платформ должны получать и использовать данные.

Лучшие практики

  • Используйте параллелизм. Большинство технологий обработки больших данных распределяют рабочую нагрузку между несколькими единицами обработки. Это распределение требует создания и хранения статических файлов данных в разделенном формате. Распределенные файловые системы, такие как распределенная файловая система Hadoop (HDFS), могут оптимизировать производительность чтения и записи. Несколько узлов кластера параллельно выполняют фактическую обработку, что сокращает общее время задания. Рекомендуется использовать формат разделенных данных, например Parquet.

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

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

  • Обработка пакетных данных по прибытии. Традиционные решения бизнес-аналитики часто используют процесс извлечения, преобразования и загрузки (ETL) для перемещения данных в хранилище данных. Однако с большим объемом данных и большим количеством форматов решения больших данных обычно применяют варианты ETL, такие как извлечение, загрузка и преобразование (ELT).

  • Обработка потоковых данных во время полета. Для потоковых решений преобразуйте полезные данные во время передачи данных. Так как вы работаете с гораздо меньшими пакетами по сети, это гораздо проще преобразовать эти небольшие наборы строк во время создания. Приземлите преобразованный поток в подсистеме, оптимизированной для данных на основе событий, таких как хранилище событий аналитики Real-Time, что делает данные немедленно доступными для действия.

  • Сбалансируйте затраты на использование и время. Для заданий пакетной обработки важно учитывать затраты на единицу вычислительных узлов и затраты на каждую минуту использования этих узлов для завершения задания. Например, пакетное задание может занять восемь часов с четырьмя узлами кластера. Однако может оказаться, что задание использует все четыре узла только в течение первых двух часов, и после этого требуются только два узла. В этом случае выполнение всего задания на двух узлах увеличивает общее время задания, но не удвоит его, поэтому общая стоимость меньше. В некоторых бизнес-сценариях более длительное время обработки может быть предпочтительнее для использования неиспользуемых ресурсов кластера.

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

  • Оркестрация приема данных. В некоторых случаях существующие бизнес-приложения могут записывать файлы данных для пакетной обработки непосредственно в контейнеры BLOB-объектов хранилища Azure, где подчиненные службы, такие как Microsoft Fabric, могут использовать их. Однако часто необходимо оркестрировать прием данных из локальных или внешних источников данных в озеро данных. Используйте рабочий процесс оркестрации или конвейер, например поддерживаемые фабрикой данных Azure или Microsoft Fabric, для обеспечения прогнозируемого и централизованно управляемого перемещения данных.

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

Архитектура Интернета вещей

IoT — это специализированное подмножество решений больших данных. На следующей схеме показана возможная логическая архитектура для Интернета вещей. Схема подчеркивает компоненты потоковой передачи событий архитектуры.

Схема архитектуры Интернета вещей.

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

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

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

Рассмотрим следующие распространенные типы обработки:

  • Данные загружаются в хранилище данных на основе событий, например в хранилище событий в Real-Time Intelligence для контекстуализации устройства Интернета вещей с метаданными, такими как расположение здания и сведения об устройстве.

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

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

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

Серые поля показывают компоненты системы Интернета вещей, которые не связаны напрямую с потоком событий. Они включены здесь для полноты.

  • Реестр устройств — это база данных подготовленных устройств. Он включает идентификаторы устройств и обычно содержит метаданные, такие как расположение.

  • API подготовки — это общий внешний интерфейс для подготовки и регистрации новых устройств.

  • Некоторые решения Интернета вещей позволяют отправлять сообщения команд и управления на устройства.