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

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

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

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

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

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

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

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

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

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

  • Хранилища данных приложения, такие как реляционные базы данных.
  • Статические файлы, создаваемые приложениями, например файлы журнала веб-сервера.
  • Источники данных в режиме реального времени, такие как устройства Интернета вещей (IoT).

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

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

  • Выполнение заданий U-SQL в Azure Data Lake Analytics.

  • Используйте задания Hive, Pig или пользовательские задания MapReduce в кластере Azure HDInsight Hadoop.

  • Используйте программы Java, Scala или Python в кластере HDInsight Spark.

  • Используйте язык Python, Scala или SQL в записных книжках Azure Databricks.

  • Используйте язык Python, Scala или SQL в записных книжках Fabric.

• Прием сообщений в режиме реального времени: Если решение включает источники в режиме реального времени, архитектура должна записывать и хранить сообщения в режиме реального времени для потоковой обработки. Например, можно использовать простое хранилище данных, которое собирает входящие сообщения для обработки. Однако во многих решениях требуется хранилище приема сообщений, которое служит буфером для сообщений, а также для поддержки горизонтальной обработки, надежной доставки и другой семантики очереди сообщений. Эта часть архитектуры потоковой передачи часто называется буферизацией потоков. Варианты: Центры событий Azure, Центр Интернета вещей и Kafka.

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

  • Azure Stream Analytics — это управляемая служба потоковой обработки, которая использует непрерывно выполняющиеся запросы SQL, работающие на несвязанных потоках.

  • Вы можете использовать технологии потоковой передачи Apache с открытым кодом, такие как Потоковая передача Spark, в кластере HDInsight или Azure Databricks.

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

  • Fabric поддерживает обработку данных в режиме реального времени с помощью потоков событий и обработки Spark.

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

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

• Аналитическое хранилище данных: Многие решения больших данных подготавливают данные для анализа, а затем служат обработанным данным в структурированном формате, который аналитические средства могут запрашивать. Аналитическое хранилище данных, которое обслуживает эти запросы, может быть реляционным хранилищем реляционных данных в стиле Кимбола. Большинство традиционных решений бизнес-аналитики (BI) используют этот тип хранилища данных. Кроме того, данные можно представить с помощью технологии NoSQL с низкой задержкой, например HBase, или интерактивной базы данных Hive, которая обеспечивает абстрагирование метаданных по файлам данных в распределенном хранилище данных.

  • Azure Synapse Analytics — это управляемая служба для крупномасштабных облачных хранилищ данных.

  • HDInsight поддерживает Интерактивный Hive, HBase и Spark SQL. Эти средства могут служить данными для анализа.

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

  • Azure предоставляет другие аналитические хранилища данных, такие как Azure Databricks, Azure Data Explorer, База данных SQL Azure и Azure Cosmos DB.

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

  Специалисты по обработке и анализу данных также могут анализировать и сообщать с помощью интерактивного исследования данных. В этих сценариях многие службы Azure поддерживают аналитические записные книжки, такие как Jupyter, чтобы позволить этим пользователям использовать имеющиеся навыки с Python или Microsoft R. Для крупномасштабных исследований данных можно использовать Microsoft R Server, автономный или с Spark. Можно также использовать Fabric для редактирования моделей данных, что обеспечивает гибкость и эффективность моделирования и анализа данных.

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

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

  Чтобы автоматизировать эти рабочие процессы, используйте технологию оркестрации, например Фабрику данных Azure, Fabric или Apache Oozie и Apache Sqoop.

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

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

Лямбда-архитектура решает эту проблему, создавая два пути для потока данных. Все данные, поступающие в систему, проходят через следующие два пути:

• Пакетный слой (холодный путь) сохраняет все входящие данные в необработанной форме и выполняет пакетную обработку данных. Результат этой обработки хранится в виде пакетного представления.

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

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

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

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

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

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

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

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

Как и пакетный слой лямбда-архитектуры, данные события неизменяемы, и все это собирается вместо подмножества данных. Данные передаются в виде потока событий в распределенный, отказоустойчивый единый журнал. Эти события упорядочиваются, и текущее состояние события изменяется только при добавлении нового события. Аналогично уровню скорости Лямбда-архитектуры, все события обрабатываются во входном потоке и сохраняются в режиме реального времени.

Если необходимо перекомпитировать весь набор данных (эквивалентно тому, что выполняет пакетный слой в лямбда-архитектуре), можно воспроизвести поток. Этот процесс обычно использует параллелизм для своевременного завершения вычислений.

Озеро данных — это централизованный репозиторий данных, в который хранятся структурированные данные (таблицы базы данных), полуструктурированные данные (XML-файлы) и неструктурированные данные (изображения и звуковые файлы). Эти данные являются необработанным, исходным форматом и не требуют предопределенной схемы. Озеро данных может обрабатывать большие объемы данных, поэтому оно подходит для обработки и анализа больших данных. Хранилища данных используют недорогие решения для хранения, что позволяет экономно хранить большие объемы данных.

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

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

Распространенные варианты использования архитектуры Lakehouse включают:

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

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

• Управление данными: Обеспечивает соответствие требованиям и качество данных в больших наборах данных

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

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

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

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

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

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

Распространенные типы обработки включают:

• Запись данных событий в холодное хранилище для архивации или пакетной аналитики.

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

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

• Обучение машины.

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

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

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

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

• Центр IoT
• Центры событий
• Stream Analytics
• Обозреватель данных Azure
• Ткань
• Azure Databricks

• архитектуры Интернета вещей
• Стиль архитектуры больших данных
• Современная архитектура аналитики с помощью Azure Databricks
• Архитектура больших данных с помощью Fabric