Создание событийных озер данных с безсерверными технологиями

Что такое озеро данных, управляемое событиями?

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

Основная идея заключается в том, что каждый новый фрагмент данных запускает цепочку бессерверных функций, которые проверяют, преобразуют, обогащают и загружают данные в озеро. Этот шаблон естественным образом соответствует хранилищам облачных объектов (таких как Amazon S3 или Azure Blob Storage) и бессерверным вычислительным службам (таким как AWS Lambda, Azure Functions или Google Cloud Functions). Устраняя неработающие вычислительные ресурсы и платя только за фактическую обработку, организации могут обрабатывать непредсказуемые объемы данных без чрезмерного предоставления.

Характеристики событийно-ориентированных озер данных

Event-Driven vs. Batch-Driven Data Lakes (англ.) (недоступная ссылка).

В традиционном озере данных, основанном на пакетах, данные собираются через окно (например, почасово или ежедневно) и затем обрабатываются оптом. В то время как более простые для реализации пакетные режимы вводят задержку и могут пропускать переходные шаблоны. Подход, основанный на событиях, отдает приоритет своевременности и отзывчивости, часто используя очереди сообщений (например, Amazon SQS или Azure Event Hubs) для буферизации входящих событий до того, как их подберут бессерверные функции. компромисс заключается в том, что системы, управляемые событиями, требуют более тщательной обработки состояния, повторов и точной семантики - темы, которые мы рассмотрим позже в этой статье.

Роль безсерверных технологий

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

Масштабируемость

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

Эффективность затрат

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

Сокращение операционных накладных расходов

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

Гибкость и интеграция

Большинство облачных провайдеров предлагают бессерверные функции, которые интегрируются изначально с десятками сервисов: базами данных, брокерами сообщений, хранилищем объектов, API машинного обучения и сторонними инструментами SaaS. Например, событие загрузки S3 может вызвать функцию Lambda, которая вызывает Amazon Rekognition для метки изображений, а затем хранит метаданные в базе данных — все без предоставления сервера.

Однако бессерверные системы не являются «серебряной пулей». Холодные запуски, ограничения времени выполнения (например, 15 минут для AWS Lambda) и ограничения на разработку без состояния означают, что длительные сложные преобразования могут по-прежнему требовать альтернативных вычислительных опций, таких как AWS Fargate или Azure Container Instances.

Ключевые компоненты архитектуры озера данных без сервера

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

Источники событий

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

Проглатывание и очередь событий

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

Вычислительный/процессорный уровень

Бессерверные функции составляют сердце обрабатывающего слоя. Они вызываются в ответ на события, поступающие в очередь или поток, и выполняют такие задачи, как валидация данных, фильтрация, преобразование (ETL), обогащение внешними API и маршрутизация к хранению. Для более тяжелых рабочих нагрузок используются некоторые реализации:

  • AWS Lambda (максимальное 15-минутное исполнение, 10 ГБ памяти) для легких преобразований.
  • Лазурные функции с планом потребления или премиальным планом для более длительных периодов выполнения.
  • Google Cloud Functions или Cloud Run для контейнерной обработки событий.
  • Шаговые функции или прочные функции для организации многоступенчатых рабочих процессов, обработки сбоев и управления состоянием в нескольких функциях.

Слой хранения

Объектное хранение является основой любого озера данных. Такие сервисы, как Amazon S3, Azure Blob и Google Cloud Storage, обеспечивают бесконечную масштабируемость, высокую долговечность и политику жизненного цикла для привязки данных к более дешевым классам хранения по мере старения. Общая схема заключается в организации хранения в зоны или слои:

  • Сырая/посадочная зона — Немодифицированные входящие данные, хранящиеся в нативных форматах (JSON, CSV, Avro, Parquet).
  • Очистленная/куратурированная зона — данные после валидации, дедупликации и базовых преобразований.
  • Совокупная / Аналитическая зона — Данные, структурированные для запроса, часто в колоночных форматах (Parquet) и разделенные по дате или ключу.

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

Аналитика и визуализация

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

  • AWS Athena — сервис с оплатой за запрос на основе престо для работы SQL непосредственно на данных в S3.
  • Azure Synapse Serverless SQL pool — Запрос данных озерных файлов по запросу.
  • Google BigQuery — хранилище данных без сервера, которое может запрашивать внешние таблицы в облачном хранилище.
  • Amazon Redshift Spectrum — расширяет Redshift для запроса данных в S3.

Инструменты визуализации, такие как Amazon QuickSight, Power BI или Looker, подключаются к этим двигателям для приборных панелей. С помощью событийного конвейера обеспечивается отражение самых последних данных с минимальной задержкой.

Архитектурные шаблоны для событийных озер данных

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

Fan-Out с бессерверными функциями

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

Архитектура Lambda с безсерверными слоями

Традиционная архитектура Lambda использует пакетный слой для исторической точности и скоростной слой для обновлений с низкой задержкой. В безсерверной реализации пакетный слой может быть запланированной бессерверной функцией (например, ежедневной работой AWS Lambda), которая пересчитывает агрегаты, в то время как скоростной слой является бессерверным потоковым процессором, управляемым событиями. Примером является объединение Amazon Kinesis Data Analytics (потоковая передача) с запланированными заданиями Lambda, которые пишут разделы Parquet на S3.

Архитектура Каппа (Pure Streaming)

Для команд, которые хотят избежать сохранения двух кодовых баз, архитектура Kappa рассматривает все данные как поток. Безсерверные функции потребители обрабатывают поток в режиме реального времени, а обработанные результаты хранятся в озере данных. Сам поток (сохраненный в журнале, таком как Kafka или Kinesis) служит источником истины. Историческое повторение достигается путем повторной обработки потока с контрольной точки. Этот шаблон хорошо работает, когда вы можете терпеть возможную согласованность и должны минимизировать дублирование.

Озеро данных, управляемое событиями

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

Шаг 1: Определите источники данных и определите схему событий

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

Шаг 2: Настройте проглатывание событий

Выберите службу очереди или потокового вещания, которая соответствует вашим требованиям к пропускной способности и задержке. Настройте источники событий для публикации своих данных в этом буфере. Например, включите уведомления о событиях S3 для отправки событий создания объектов в очередь SQS, которая затем запускает функцию Lambda. Убедитесь, что в очереди есть очередь с мертвой буквой (DLQ) для обработки сбоев.

Шаг 3: Проектирование архитектуры хранения

Типичная иерархия включает в себя: , и . Используйте разделение (например, по дате, региону или типу события) для оптимизации производительности запроса. Настройте политики жизненного цикла для автоматического перемещения старых данных в архивное хранилище (S3 Glacier или Azure Archive).

Шаг 4: Внедрение функций обработки данных

Записывайте бессерверные функции, которые потребляют события из очереди, выполняйте логику преобразования (например, анализ JSON, преобразование CSV в Parquet, дедупликацию) и записывайте результаты в зону посадки в озере данных. Для сложных ETL цепь множественных функций с использованием службы оркестровки рабочего процесса (Step Functions). Обеспечьте идемпотентность: одно и то же событие должно безопасно обрабатываться несколько раз в случае повторных запросов.

Шаг 5: Установить безопасность и управление

Применять наименее привилегированные роли IAM к каждой функции без сервера. Шифровать данные в состоянии покоя (используя S3 SSE-KMS или Azure Storage Service Encryption) и в пути (TLS). Используйте мелкозернистые элементы управления доступом (например, AWS Lake Formation, Azure Purview) для управления разрешениями на уровне столбца или строки. Настройте журналирование аудита, отправив журналы выполнения функций в центральную раковину журнала.

Шаг 6: Настройка мониторинга и оповещения

Мониторинг ключевых показателей: вызовы функций, частота ошибок, задержка и глубина очереди. Используйте облачные инструменты, такие как Amazon CloudWatch, Azure Monitor или Google Cloud Operations. Настройте оповещения для аномалий, таких как внезапный всплеск сообщений DLQ или падение пропускной способности обработки. Внедрите оповещения о расходах, чтобы предотвратить перерасход бюджета.

Лучшие практики для озер данных без серверов

Идемпотентная обработка

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

Оптимизация для холодных стартов

При использовании AWS Lambda минимизируйте задержку холодного запуска:

  • Выбор времени выполнения с более быстрой инициализацией (Node.js, Python) по сравнению с Java/C#.
  • Использование предусмотренной параллели для критических функций.
  • Сохранение зависимостей небольшими и использование слоев.

Используйте компрессию и колонные форматы

Преобразование потоковых данных в Parquet или ORC как можно скорее. Это снижает затраты на хранение и резко улучшает производительность запросов в безсерверных SQL-движках. Для небольших файлов пакетируйте их с помощью механизма окна (например, буферные записи на 1 минуту или 1000 записей, затем записывайте один файл).

Управлять поставщиком Lock-In

В то время как облачные сервисы удобны, подумайте об использовании компонентов с открытым исходным кодом, где это возможно. Например, используйте Apache Kafka в качестве шины событий (через Confluent Cloud или самоуправляемую), а не фирменную услугу. Используйте объектное хранилище с S3-совместимыми API (MinIO) для гибридных или многооблачных настроек. Это сохраняет переносимость.

Проблемы и соображения

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

Последовательность данных и порядок

В распределенных системах, управляемых событиями, события, не имеющие порядка, и дублирующие поставки неизбежны. Используйте время события (метка времени, встроенная в полезную нагрузку), а не время обработки для заказа событий. Внедряйте слой дедупликации с использованием кэша (например, Redis или DynamoDB), который отслеживает недавно обработанные идентификаторы событий.

Управление затратами

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

Риски безопасности

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

Продавец Lock-In

Как уже упоминалось, зависимость от проприетарных сервисов (таких как уведомления о событиях S3, триггеры Lambda или Event Grid) может затруднить миграцию. Mitigate может быть абстрагирован путем абстрагирования уровня обработки событий за интерфейсом (например, с помощью реестра схем EventBridge) и с помощью открытых стандартов (CloudEvents).

Задержка холодного запуска для систем реального времени

Для требований с низкой задержкой (до 500 мс) холодные запуски могут быть проблематичными. Дотеплые функции с запланированным пингсом или использование обеспеченной параллели. Альтернативно, используйте бессерверные контейнерные службы (AWS Fargate, Cloud Run), которые имеют меньшие следы холодного запуска, чем Lambda или Функции.

Реальные случаи использования

Потоковая аналитика Clickstream

Компания электронной коммерции собирает данные о потоках кликов пользователей со своего веб-сайта через AWS Kinesis. Функции Lambda анализируют и обогащают события метаданными продукта, а затем записывают их в S3 в формате Parquet. Отдельный безсерверный SQL-запрос (Athena) обеспечивает интерактивные панели мониторинга, показывающие воронки конверсии в реальном времени. Природа событий позволяет им обнаруживать и реагировать на изменения поведения пользователей в течение нескольких секунд.

IoT-телеметрия и прогнозируемое техническое обслуживание

Производственная фирма получает показания датчиков от тысяч машин через Azure IoT Hub. События отправляются в Event Hubs, где Azure Functions фильтрует аномалии и хранит необработанные данные в хранилище Blob. Модель ML, работающая на Azure ML (срабатывающая с помощью функции таймера), предсказывает сбои оборудования и отправляет оповещения обратно в цех. Безсерверное озеро хранит петабайт исторических данных для переподготовки моделей.

Обнаружение финансового мошенничества

Финтех-компания обрабатывает события транзакций в режиме реального времени с помощью Google Cloud Pub/Sub. Cloud Functions оценивает каждую транзакцию с помощью предварительно обученной модели, развернутой на Vertex AI. Легитимные транзакции совершаются в BigQuery для отчетности, а подозрительные помечаются для ручного обзора. Архитектура, управляемая событиями, гарантирует, что ни одна транзакция не задерживается более чем на несколько сотен миллисекунд.

Заключение

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

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

Для дальнейшего чтения изучите официальную документацию по Создание озера данных, управляемого событиями, с использованием AWS Lambda и Amazon S3, Архитектура озера данных, управляемого событиями Microsoft и Решения Data Lake от Google Cloud.