Пакетная или потоковая обработка? Вечная дилемма обработки данных.

«Следует ли обрабатывать данные партиями или в режиме реального времени?» Дело не в выборе между пакетной и потоковой обработкой: вопрос в том, «когда ответ имеет значение?»

Делиться

Если вы хоть немного работали в сфере обработки данных, то наверняка хотя бы раз сталкивались с этим вопросом. Может быть, дважды. Ладно, наверное, раз двенадцать 😉 «Следует ли обрабатывать данные партиями или в режиме реального времени?» И если вы похожи на меня, то наверняка заметили, что ответ обычно начинается со слов: «Ну, это зависит…»

Это правда. Всё зависит от обстоятельств. Но фраза «всё зависит от обстоятельств» полезна только в том случае, если вы действительно знаете, от чего именно она зависит. И именно этот пробел я хочу заполнить этой статьей. Не очередное теоретическое сравнение пакетной и потоковой обработки (надеюсь, вы уже знаете основы). Вместо этого я хочу предложить вам практическую схему для принятия решения о том, какой подход подходит для вашего конкретного сценария, а затем показать, как оба пути выглядят при реализации в Microsoft Fabric.

Дело не в пакетной обработке против потоковой: дело в том, «когда ответ имеет значение?»

Позвольте мне пропустить сухие определения и сразу перейти к тому, что на самом деле отличает эти два подхода: ценность свежести .

У любых данных есть срок годности. Не в том смысле, что они истекают и становятся бесполезными, а в том смысле, что их коммерческая ценность меняется со временем. Обнаружение мошеннической транзакции с кредитной картой за 200 миллисекунд? Бесценно – вы только что предотвратили убытки. Обнаружение той же мошеннической операции через 6 часов в ходе ночной пакетной обработки? Полезно для составления отчетов, но деньги уже потеряны.

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

Итак, первый вопрос не в том, «пакетная или потоковая обработка?». Первый вопрос в том, насколько быстро кто-то (или что-то) должно обработать эти данные, чтобы это имело значение?

Если ответ «секунды или меньше», вы находитесь в области потоковой обработки. Если ответ «часы или дни», пакетная обработка, скорее всего, вам поможет. А если ответ «где-то посередине»… Поздравляем, вы находитесь в самой интересной (и самой распространенной) серой зоне, которую мы рассмотрим чуть позже.

Компромиссы

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

Расходы

Я вас понимаю, я вас понимаю: «Никола, насколько дороже потоковая обработка?» К сожалению, я не могу назвать вам точную цифру, но закономерность очевидна: инфраструктура для потоковой обработки почти всегда дороже, чем пакетная обработка при том же объеме данных. Почему? Потому что потоковая обработка требует, чтобы ресурсы были постоянно включены, прослушивали, обрабатывали и непрерывно записывали данные. Пакетная обработка, с другой стороны, запускается, выполняет свою работу и отключается. Вы платите за вычислительные ресурсы только тогда, когда выполняется задача.

Представьте себе кухню в ресторане. Кухня, работающая по принципу «партии», открывается в определенное время – персонал приходит, готовит, готовит, убирает и уходит домой. Кухня, работающая по принципу «потока», открыта круглосуточно, и персонал всегда находится наготове, готовый начать готовить в момент поступления заказа. Даже в тихие часы, в 3 часа ночи, когда никто ничего не заказывает, кто-то все равно ждет. Это ожидание стоит денег.

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

Сложность

Пакетная обработка концептуально проще. У вас есть определенные входные данные, определенное преобразование и определенный выходной результат. Если что-то не удается, вы перезапускаете задание. Данные никуда не уходят, они хранятся в файле или таблице, терпеливо ожидая.

Потоковая передача данных? Тут всё сложнее. Вы имеете дело с данными, которые поступают непрерывно, возможно, не по порядку, возможно, с дубликатами и возможно с пробелами. Что произойдёт, если датчик отключится на 5 минут, а затем выдаст все свои буферизованные показания одновременно? Что произойдёт, если два события поступят в неправильном порядке? Что произойдёт, если механизм обработки данных выйдет из строя посреди потока? Воспроизвести с начала? С контрольной точки? Как обеспечить обработку ровно один раз?

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

Правильность

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

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

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

Задержка против пропускной способности

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

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

Вопрос в том: в вашем конкретном случае приоритет отдается скорости отклика, а не эффективности, или наоборот?

Итак, когда и что следует использовать?

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

Пакетная обработка — ваш лучший вариант, когда…

• Ваши данные поступают с предсказуемыми интервалами. Ежедневная загрузка файлов с SFTP-серверов, ежечасный экспорт через API, еженедельная загрузка CSV-файлов от поставщиков. Данные не критичны ко времени, и источник в любом случае не поддерживает непрерывную потоковую передачу. Навязывание потоковой архитектуры данным, поступающим раз в день, — это как нанять круглосуточную курьерскую службу для доставки почты, которая приходит только по понедельникам.
• Вам необходимы сложные преобразования, охватывающие весь набор данных. Подумайте об обучении моделей машинного обучения, сравнении данных за разные годы, выполнении масштабных объединений между таблицами фактов и медленно изменяющимися измерениями. Эти операции требуют полной картины, поскольку их невозможно осмысленно разложить на потоковую логику обработки каждой записи отдельно.
• Оптимизация затрат — приоритет. Если ваш бюджет ограничен, а требования к свежести не слишком строгие (часы, а не секунды), пакетная обработка позволяет запускать ресурсоемкие вычисления по запросу и отключать их после завершения. Вы платите за то, что используете, а не за то, что можете использовать в будущем.
• Точность данных важнее скорости. Финансовая сверка, отчетность перед регулирующими органами, журналы аудита… В этих сценариях правильность важнее скорости. Пакетная обработка позволяет обрабатывать полные наборы данных и перезапускать задания в случае возникновения проблем.

Стриминг — это оптимальный вариант, когда…

• Кто-то (или что-то) должно немедленно реагировать на эти данные. Выявление мошенничества, мониторинг аномалий, оповещения IoT, интерактивные панели мониторинга для оперативных групп… Ценность данных быстро снижается со временем. Если реакция бизнеса на устаревшие данные звучит как «ну, теперь они бесполезны», вам необходима потоковая обработка.
• Данные по своей природе непрерывны. Потоковые данные, телеметрия датчиков, журналы приложений и ленты социальных сетей не являются источниками данных, которые обрабатываются пакетами естественным образом. Они непрерывно генерируют события, и обработка их пакетами означает искусственное удержание уже имеющихся данных. Зачем ждать?
• Вы строите архитектуры, управляемые событиями. Микросервисы, взаимодействующие через шины событий, системы обработки заказов, механизмы персонализации в реальном времени — сама архитектура по своей сути является потоковой. Внедрение пакетной обработки нарушило бы принцип управления событиями.
• Необходимо выявлять закономерности во временных интервалах. «Предупреждайте меня, если загрузка ЦП превышает 90% в течение более 5 минут подряд». «Отмечайте любого пользователя, совершившего более 10 неудачных попыток входа в систему в течение 2-минутного интервала». Это, естественно, задачи потоковой обработки данных, требующие непрерывной оценки условий в рамках скользящего окна событий.

А что насчет «серой зоны»?

Отлично! Теперь вы знаете, когда что использовать. Но знаете что? Большинство организаций не делятся на две категории. У вас будут ситуации, когда потоковая обработка данных необходима, и ситуации, которые идеально подходят для пакетной обработки. И это нормально, это не вопрос выбора между двумя крайностями на уровне организации. Это решение принимается для каждой конкретной ситуации.

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

Более практичный вопрос: поддерживает ли ваша платформа оба пути без необходимости создания и поддержки двух совершенно отдельных стеков? И вот здесь начинается самое интересное с Microsoft Fabric…

Как это проявляется в Microsoft Fabric?

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

Позвольте мне рассказать вам, как реализуется каждый из подходов.

Пакетная обработка в Fabric

Для пакетной обработки данных Fabric предлагает множество вариантов в зависимости от ваших навыков и требований:

• Конвейеры данных — это основа оркестрации. Если вы раньше работали с такими сервисами, как Azure Data Factory, это покажется вам знакомым. Вы можете планировать запуск конвейеров в определенное время или запускать их на основе событий. Конвейеры координируют поток данных между источниками и получателями, выполняя такие действия, как копирование данных, потоки данных и выполнение блокнотов.
• Основная работа выполняется в блокнотах Fabric . В них можно писать код на PySpark, Spark SQL, Python или Scala для выполнения сложных преобразований больших наборов данных. Блокноты идеально подходят для сценариев «сложных преобразований, охватывающих весь набор данных», которые мы обсуждали ранее, таких как большие объединения, агрегации и разработка признаков для машинного обучения. Они запускают, обрабатывают и освобождают вычислительные ресурсы по завершении работы.
• Dataflows Gen2 предлагают альтернативу с минимальным или полным отсутствием необходимости в коде, используя привычный интерфейс Power Query. Недавние улучшения производительности (такие как Modern Evaluator и Partitioned Compute) сделали их гораздо более конкурентоспособным вариантом с точки зрения соотношения цены и производительности. Если ваши пакетные преобразования относительно просты, Dataflows могут избавить вас от накладных расходов на написание и поддержку кода Spark.
• Fabric Data Warehouse предоставляет интерфейс на основе T-SQL для тех, кто предпочитает реляционный подход. Вы можете запускать запланированные хранимые процедуры, создавать представления для уровней абстракции и использовать конечную точку SQL-аналитики для выполнения произвольных запросов.

Все эти механизмы записывают свои результаты в виде таблиц Delta в OneLake, что означает, что результаты немедленно становятся доступны любому механизму Fabric, будь то семантическая модель Power BI, другой блокнот или SQL-запрос.

Обработка потоков данных в Fabric

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

• Eventstreams — это уровень приема потоковых данных. Вы можете подключаться к таким источникам, как Azure Event Hubs, Azure IoT Hub, Kafka, пользовательские приложения и даже потоки захвата изменений данных в базах данных (CDC). Eventstreams обрабатывают непрерывный поток событий и направляют их в различные места назначения внутри Fabric.
• Eventhouses (на базе баз данных KQL) — это хранилище и вычислительный механизм для данных в реальном времени. Данные поступают в таблицы KQL и сразу же становятся доступными для запросов с помощью языка запросов Kusto. Если вы читали мою статью о политиках обновления, вы уже знаете, насколько мощными они могут быть для преобразования данных в момент их поступления — без необходимости в отдельном уровне обработки.
• Панели мониторинга в реальном времени позволяют визуализировать потоковые данные с возможностью автоматического обновления. Таким образом, ваша оперативная группа получает актуальную информацию о том, что происходит прямо сейчас, а не о том, что произошло вчера.
• Activator позволяет задавать условия и запускать действия на основе данных в реальном времени. «Если температура превысит 80°C, отправьте уведомление в Teams». «Если количество заказов упадет ниже порогового значения, запустите оповещение». Это та самая функция «немедленного реагирования на данные», о которой мы говорили ранее.

Главное, что нужно помнить: данные Real-Time Intelligence также хранятся в OneLake. Это означает, что ваши потоковые данные и пакетные данные сосуществуют на одном уровне хранения. Блокнот Spark может считывать данные из базы данных KQL. Отчет Power BI может объединять таблицы хранилища данных, обработанные в пакетном режиме, с данными Eventhouse в реальном времени. Границы между пакетными и потоковыми данными начинают размываться, и именно это я пытаюсь здесь подчеркнуть.

Лучшее из двух миров

Теперь давайте рассмотрим конкретный пример того, как пакетная и потоковая обработка данных могут взаимодействовать в Fabric.

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

На стороне пакетной обработки ночной конвейер извлекает данные о транзакциях за день, обогащает их информацией из каталога товаров и сегментами клиентов с помощью блокнота Spark и записывает результаты в Lakehouse. Семантическая модель Power BI, построенная на основе этих таблиц Delta, используется для создания панели мониторинга для руководителей, которая обсуждается на утреннем совещании в понедельник.

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

Практическая модель принятия решений

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

1. Насколько быстро необходимо обработать эти данные? Если секунды — потоковая обработка. Если часы/дни — пакетная обработка. Если «зависит от сценария» — читайте дальше 😊
2. Как поступают данные? Непрерывные события -> потоковая передача — это естественно. Периодическая выгрузка файлов -> пакетная обработка — это естественно. Не пытайтесь противостоять естественному ритму данных.
3. Насколько сложны преобразования? Построчный анализ и фильтрация — оба варианта подходят. Большие объединения, обучение машинного обучения, агрегация полных наборов данных — пакетная обработка имеет преимущество.
4. Какой у вас допустимый бюджет? Постоянная работа вычислительных ресурсов для потоковой обработки данных против вычислительных ресурсов по запросу для пакетной обработки. Рассчитайте оба варианта и сравните.
5. Насколько важна полнота данных? Если вам нужна полная картина перед принятием решений — используйте пакетную обработку. Если приемлемы предварительные результаты — подходит потоковая обработка.
6. Поддерживает ли ваша платформа оба варианта? Если да (а Fabric поддерживает), используйте подходящий инструмент для каждого случая, а не пытайтесь всё реализовать в рамках одной парадигмы.

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

Спасибо за чтение!

Примечание: Визуальные материалы в этой статье созданы с помощью Claude и NotebookLM.

Никола Илич. Все работы Николы Илича.

Источник: towardsdatascience.com