7.6 Потоковые данные и данные реального времени

Обзор и мотивация

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

Для больших команд потоковая обработка появляется в тот момент, когда задержка начинает иметь значение для бизнеса. Решение о мошенничестве, пришедшее на час позже, бесполезно. Сигнал персонализации, приземлившийся завтра, ничего не персонализирует. Операционная панель, отстающая от реальности на смену, вводит в заблуждение следящих за ней людей. Глава 7.2 (инженерия данных) утверждает, что по умолчанию следует выбирать пакетную обработку и тянуться к потоковой только там, где малая задержка действительно окупается, а эта глава ведёт вас остаток пути: когда реальное время оправдывает свою цену и как построить его, не поджигая операционный бюджет. Потоковая обработка стоит близко к шаблонам событийного обмена сообщениями из главы 3.12 (событийно-ориентированная архитектура и обмен сообщениями), выборам хранения из главы 3.4 (архитектура данных и хранилища) и практикам телеметрии из главы 9.2 (наблюдаемость и телеметрия).

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

Ключевые принципы

Тянитесь к потоковой обработке, только когда у малой задержки есть ясная бизнес-ценность; пакетная дешевле и проще.
Различайте ограниченные (конечные) и неограниченные (бесконечные) данные и проектируйте соответственно.
Воспринимайте время события, а не время прибытия, как источник истины и планируйте запоздавшие и неупорядоченные данные.
Окна и водяные знаки это способ получать конечные ответы из бесконечных потоков.
Предпочитайте результаты «по сути один раз» через идемпотентные приёмники хрупким обещаниям «ровно один раз».
Обработке с состоянием нужны контрольные точки, чтобы она могла восстанавливаться без потерь и двойного подсчёта.
Проектируйте обратное давление и переобработку с первого дня, а не задним числом.
Держите потоковую логику наблюдаемой и проверяемой; молчащий поток хуже упавшего пакета.

Рекомендации

Обоснуйте реальное время, прежде чем строить его

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

Проектируйте вокруг времени события, а не времени обработки

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

Используйте окна и водяные знаки, чтобы получать конечные ответы

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

Делайте приёмники идемпотентными и предпочитайте «по сути один раз»

Гарантии доставки звучат просто и не являются таковыми. Доставка «как минимум один раз» означает, что каждое событие обработано, но некоторые могут быть обработаны более одного раза после повтора, так что подсчёты могут раздуться. «Ровно один раз» звучит идеально, но дорого и, понимаемое буквально через произвольные внешние системы, нередко невозможно. Практическая цель: «по сути один раз», когда наблюдаемый результат таков, словно каждое событие обработано единожды, даже если механизм внизу повторял. Вы достигаете этого, делая идемпотентные приёмники безопасными для повторной записи, используя детерминированные ключи и upsert, так что повторно воспроизведённое событие перезаписывает, а не дублирует. Сочетайте доставку «как минимум один раз» с идемпотентными записями, и вы получите верные результаты, не платя за тяжёлую транзакционную координацию повсюду. Оставьте настоящие механизмы «ровно один раз» для узких мест, которым они действительно нужны.

Ставьте контрольные точки обработке с состоянием, чтобы она могла восстанавливаться

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

Передавайте потоком из операционных баз данных через захват изменений данных

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

Предпочитайте архитектуру «потоковая прежде всего» сопровождению двух кодовых баз

Классическая архитектура Lambda запускает пакетный слой для точной полной истории рядом со слоем скорости для свежих приблизительных результатов, затем объединяет их. Она работает, но заставляет писать и сопровождать одну и ту же бизнес-логику дважды в двух системах и вечно сверять различия. Архитектура Kappa схлопывает это: храните долговечный воспроизводимый журнал событий и ведите всю обработку как потоковую, переобрабатывая историю повторным воспроизведением журнала при изменении логики. Отрасль дрейфует к этой форме «потоковая прежде всего», потому что единая кодовая база драматически дешевле в сопровождении и осмыслении. Если ваши пакетные нужды можно выразить как повторные воспроизведения по сохраняемому журналу событий, вы полностью избегаете налога двух кодовых баз. Используйте брокеры на основе журнала, сохраняющие историю, так что переобработка это перемотка, а не перестройка.

Открывайте потоки как SQL, материализованные представления и OLAP реального времени

Не всякий, кому нужна потоковая обработка, должен писать низкоуровневый код потоковой обработки. Потоковый SQL позволяет аналитикам и инженерам выражать окна, соединения и агрегации на знакомом языке и держит результаты непрерывно актуальными как материализованные представления. Для аналитических запросов с малой задержкой над свежими данными хранилище оперативной аналитической обработки (OLAP) реального времени принимает поток и отвечает на запросы срезов за миллисекунды, что и питает действительно живую операционную панель. Сочетайте их с практиками продуктовой аналитики из главы 7.4 (продуктовая аналитика и эксперименты), когда цель быстрая обратная связь по функциям и экспериментам. Выбирайте эти инструменты более высокого уровня там, где они подходят, и оставляйте написанные вручную потоковые обработчики для логики, которую они выразить не могут.

Планируйте обратное давление и переобработку с самого начала

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

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы	Лучше всего подходит
Пакетная	Просто, дёшево, легко тестировать и заполнять задним числом	Высокая задержка, устаревание между запусками	Отчётность, большая часть аналитики
Микропакеты (минуты)	Почти реальное время, гораздо проще потоковой	Не по-настоящему мгновенно	Панели «реального времени»
Настоящая потоковая (менее секунды)	Мгновенная реакция, непрерывные результаты	Сложно, дорого, трудно тестировать	Мошенничество, оповещения, живая персонализация
«Как минимум один раз» + идемпотентный приёмник	Верные результаты, доступно, устойчиво	Требует дисциплинированного проектирования ключей	Большинство потоковых конвейеров
Механизмы «ровно один раз»	Сильная гарантия от конца до конца	Дорого, ограничено между системами	Узкие пути с высокими ставками
Lambda (пакетный + слой скорости)	Точная история плюс свежий вид	Две кодовые базы для сопровождения	Миграции унаследованных систем
Kappa (потоковая прежде всего)	Одна кодовая база, воспроизводимо	Нужен сохраняемый долговечный журнал	Новые потоковые платформы

Центральное напряжение между задержкой и сложностью. Каждый шаг к реальному времени стоит эксплуатационного бремени, трудности тестирования и денег, и отдача нелинейна: переход от суточной к раз в несколько минут дёшев и нередко достаточен, а переход от минут к долям секунды то место, где концентрируются расходы. Разрешайте напряжение, оценивая решение, а не технологию. Спросите, какое действие делает возможным свежесть и чего стоит опоздание, затем покупайте ровно столько снижения задержки, сколько оправдывает это действие. Когда потоковая обработка вам нужна, опирайтесь на доставку «как минимум один раз» с идемпотентными приёмниками и журнал «потоковая прежде всего», потому что эта комбинация даёт корректность и воспроизводимость без самых тяжёлых гарантий.

Вопросы для обсуждения с командой

Какое решение данные реального времени для нас действительно делают возможным и чего стоит, когда эти данные приходят на минуту позже вместо мгновенного? Этот вопрос должен охранять каждый потоковый проект, потому что потоковая обработка примерно удваивает эксплуатационную цену и сложность по сравнению с пакетной. Большая команда может сжечь кварталы на построение платформы реального времени, обслуживающей панели, которые человек проверяет дважды в день, а это деньги, пущенные на ветер. Принесите конкретное действие, которое двигают данные, будь то блокировка мошеннической транзакции, вызов оператора или изменение того, что видит пользователь, и назначьте число цене задержки для каждого. Если честный ответ в том, что пятиминутный микропакет удовлетворил бы потребность, это находка, достойная празднования, а не сокрытия. Ответ должен прямо изменить, строите ли вы настоящую потоковую обработку, довольствуетесь микропакетами или остаётесь в пакетной.
Как мы обращаемся с запоздавшими и неупорядоченными событиями и что происходит с данными, приходящими после закрытия окна? Запоздавшие и неупорядоченные данные трудная часть потоковой обработки, а команды, пропускающие этот вопрос, обнаруживают его в производстве, когда их числа отказываются сходиться. Конкурирующие давления задержка и корректность: держите окна открытыми дольше, чтобы поймать отставших, и вы задерживаете каждый результат и потребляете больше памяти, закрывайте быстрее, и молча теряете настоящие данные. Принесите свидетельства о том, насколько поздно ваши данные действительно приходят, измеренные как разрыв между временем события и временем обработки по вашим источникам, поскольку мобильный источник в туннелях ведёт себя совсем иначе, чем серверное событие. Решите явно, отбрасываются ли запоздавшие данные, журналируются или вызывают поправку, и убедитесь, что все ниже по течению знают, какое именно. В государственном контексте, где цифры должны быть защитимы, молчаливое отбрасывание запоздавших событий может быть проблемой соответствия, так что политика должна быть намеренной и документированной.
Достаточно ли идемпотентны наши приёмники, чтобы можно было безопасно воспроизводить историю, и хранит ли наш журнал событий достаточно для возможности воспроизведения? Переобработка это возможность, которую команды чаще всего жалеют, что не встроили, и чаще всего не встроили, и она зависит от двух вещей, работающих вместе: идемпотентных приёмников, поглощающих воспроизведённые события без дублирования, и долговечного журнала, хранящего достаточно истории для воспроизведения. Без обоих исправление ошибки логики означает, что вы не можете чисто пересчитать затронутый период и вынуждены править числа вручную под давлением. Принесите ваше нынешнее окно хранения и конкретный тест: выберите настоящую ошибку прошлого квартала и спросите, могли бы вы воспроизвести исправленную логику над затронутыми данными. Тяготение против этого цена, поскольку хранение истории и проектирование идемпотентных записей требует хранилища и дисциплины заранее. Но альтернатива всплывает в худший момент, во время инцидента, так что ответ определяет, сколько вложить в воспроизводимость до того, как она понадобится.
Когда потоковое задание падает, как быстро оно должно восстановиться, сколько состояния ему позволено держать и действительно ли мы засекали восстановление под производственной нагрузкой? Пакетное задание, которое умерло, можно перезапустить завтра, а всегда работающий поток, который умер, это идущий сбой, и задания с состоянием, держащие текущие подсчёты, соединения или модели мошенничества, могут потерять минуты памяти или долго перезагружать состояние после перезапуска. Для большой команды именно здесь непритязательная деталь тихо определяет вашу реальную доступность: неограниченное состояние растёт, пока у задания не кончится память, а медленное восстановление из контрольной точки превращает десятисекундный сбой в десятиминутный. Конкурирующие давления свежесть против безопасности, потому что более частые контрольные точки сокращают восстановление, но добавляют накладные расходы, а щедрое хранение состояния улучшает точность, но рискует исчерпанием памяти. Принесите конкретную цель времени восстановления, нынешний размер состояния и кривую его роста, интервал контрольных точек и результаты настоящих учений по переключению, а не обнадёживающую оценку. В корпоративной и государственной среде, где поток обеспечивает оценку мошенничества или ленту общественной безопасности, непроверенный путь восстановления это эксплуатационный риск, принятый без измерения, поэтому воспринимайте учения как требование, а не желательное.
Ведём ли мы одну кодовую базу «потоковая прежде всего» или отдельный пакетный слой и слой скорости и чего нам стоит держать их сверенными? Шаблон Lambda с пакетным слоем для точной истории плюс слоем скорости для свежих результатов заставляет писать одну и ту же бизнес-логику дважды в двух системах и вечно сверять их ответы, тогда как форма «потоковая прежде всего» (Kappa) хранит долговечный воспроизводимый журнал и ведёт всю обработку как потоковую. Для большой организации дублированная логика то место, где плодятся дрейф и спорные числа, потому что правило меняется в одном слое и не в другом, а инженеры тратят реальное время, объясняя, почему они расходятся. Тяготение к сохранению обоих это инерция и комфорт проверенного пакетного слоя, поэтому взвесьте это против налога на сопровождение честно. Принесите список вычислений, которые вы сейчас запускаете в обоих местах, инциденты, вызванные расхождением двух слоёв, и оценку, хранит ли ваш журнал событий достаточно истории, чтобы выразить пакетные нужды как воспроизведения. В государственном и подвергаемом аудиту корпоративном контекстах два слоя, способные сообщать разные цифры за один период, сами по себе обязательство соответствия, поскольку вы должны уметь сказать, какое число авторитетно и почему.
Кто эксплуатирует эту всегда работающую систему, когда она ломается в три часа ночи, и заложили ли мы в бюджет нагрузку дежурств и редкие навыки, которых она требует, или предполагаем штатное расписание формы пакетной обработки? Потоковая обработка переносит цену со строительства на эксплуатацию: система должна оставаться здоровой каждую секунду, что означает реальное покрытие дежурств, инженеров, свободно владеющих временем события, водяными знаками, состоянием и семантикой доставки, и тестирование труднее, чем для задания, которое запускается и останавливается. Команды регулярно одобряют потоковую платформу из-за её возможностей и никогда не финансируют людей, поддерживающих её жизнь, так что платформа деградирует, а доверие слабеет. Компромисс объём против устойчивости: каждый дополнительный конвейер реального времени ещё одна вещь, способная вызвать кого-то по пейджеру, поэтому вопрос в том, оправдывает ли покупаемая им задержка постоянное эксплуатационное обязательство. Принесите честную опись того, кто владеет каждым потоком в производстве, ваше нынешнее дежурство и его запас и где на самом деле сидит экспертиза времени события: найм, партнёр или управляемый сервис. Для государственного органа или большой корпорации добавьте сроки закупок и найма и любой вариант управляемого сервиса, потому что платформа реального времени, зависящая от редких талантов, которых вы не можете нанять или удержать, это план эксплуатации склонной к сбоям системы с нехваткой персонала.

Взгляд по секторам

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

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

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

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

Примеры

Стартап. Потребительское приложение хочет показывать пользователям живую ленту активности и помечать подозрительные входы по мере их происхождения. Команда сопротивляется подъёму тяжёлой потоковой платформы. Они помещают события в единый сохраняющий брокер на основе журнала, запускают лёгкий потоковый обработчик для логики риска входа и питают хранилище OLAP реального времени, обеспечивающее ленту активности. Каждый приёмник ключевой и идемпотентный, так что повтор «как минимум один раз» никогда не удваивает подсчёт. Когда позже они находят ошибку в правиле риска, они просто воспроизводят журнал через исправленную логику за ночь, потому что хранили неделю истории и никогда не нуждались во второй пакетной кодовой базе.

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Построение потоковой обработки ради престижа, когда микропакет каждые несколько минут удовлетворил бы потребность.
Вычисление по времени обработки, так что ваши числа колеблются вместе с инфраструктурой, а не с миром.
Игнорирование запоздавших и неупорядоченных данных, пока сверка не провалится в производстве.
Погоня за буквальным «ровно один раз» повсюду вместо «как минимум один раз» с идемпотентными приёмниками.
Неограниченное состояние без истечения, тихо растущее, пока у задания не кончится память.
Отсутствие контрольных точек, так что перезапуск теряет состояние или вынуждает полное воспроизведение.
Опрос операционных баз данных по таймеру вместо захвата изменений данных.
Сопровождение пакетного слоя и слоя скорости Lambda с дублированной, дрейфующей логикой.
Окно хранения, слишком короткое для воспроизведения истории при обнаружении ошибки.
Потоки без метрик отставания, пропускной способности или свежести, отказывающие молча.

Модель зрелости

Уровень 1, Начальный: Всё пакетное, или несколько собранных вручную потоковых заданий работают реактивно без мониторинга. Числа вычисляются по времени обработки, запоздавшие данные игнорируются, а перезапуск теряет состояние. Никто не может воспроизвести историю, чтобы исправить ошибку, и проблемы обнаруживаются, когда нижестоящие цифры отказываются сходиться.
Уровень 2, Развитие: Некоторые команды ведут основные потоковые конвейеры на брокере на основе журнала с контрольными точками, различают время события и время обработки и используют базовые окна. Практика непоследовательна от команды к команде: доставка «как минимум один раз», но не все приёмники идемпотентны, обработка запоздавших данных импровизирована, а отставание отслеживается неформально, а не оповещается.
Уровень 3, Стандартизация: Время события, водяные знаки и явная политика запоздавших данных документированы и применяются по организации. Приёмники идемпотентны для результатов «по сути один раз», у состояния есть истечение, а захват изменений данных питает нижестоящие системы по соглашению. Сохраняемый журнал поддерживает воспроизведение, а отставание, пропускная способность и свежесть мониторятся с оповещениями как стандарт организации, а не привычка отдельной команды.
Уровень 4, Управление: Потоковое хозяйство измеряется и контролируется относительно базовых значений. Каждый конвейер несёт цели уровня обслуживания по сквозной задержке, отставанию потребителя, времени восстановления, перекосу времени события, доле запоздавших событий, размеру состояния и цене на миллион событий, всё отслеживается относительно согласованных целей с оповещением о регрессии. Восстановление отрабатывается и засекается, а не предполагается, запас обратного давления и рост состояния наблюдаются как сигналы мощности, а новый поток должен пройти эти метрики перед выходом в производство.
Уровень 5, Оркестрация: Архитектура «потоковая прежде всего» обслуживает и свежие, и исторические нужды из одного воспроизводимого журнала, а потоковый SQL, материализованные представления и OLAP реального времени делают свежие данные широко доступными. Переобработка рутинна и протестирована, платформа автоматически масштабируется и перебалансируется по измеренной нагрузке и цене, а потоки выводятся, пересматриваются или заменяются по свидетельствам. Потоковая обработка интегрирована с бизнес-планированием и планированием рисков, и каждый поток наблюдаем и проверяем от конца до конца по мере сдвигов нагрузки и цены.

Идеи для обсуждения

Где в вашем стеке «реальное время» действительно оправдывает свою цену, а где это непроверенное желание?
Насколько велик разрыв между временем события и временем обработки по вашим источникам и измеряете ли вы его?
Могли бы вы схлопнуть установку Lambda с пакетным слоем и слоем скорости в единую кодовую базу «потоковая прежде всего» и что этому помешает?
Какие из ваших приёмников действительно идемпотентны и могли бы вы сегодня безопасно воспроизвести данные прошлого квартала через исправленную логику?
Какова ваша политика для данных, приходящих после закрытия окна, и знают ли о ней все ниже по течению?
Как захват изменений данных изменил бы то, как вы держите поиск, кэши и аналитику синхронизированными?

Главные выводы

Тянитесь к потоковой обработке, только когда чувствительное к задержке решение за неё платит; пакетная и микропакеты более дешёвые умолчания.
Вычисляйте по времени события и воспринимайте запоздавшие и неупорядоченные данные как основную проблему, решаемую окнами и водяными знаками.
Предпочитайте доставку «как минимум один раз» с идемпотентными приёмниками ради результатов «по сути один раз» буквальному «ровно один раз» повсюду.
Ставьте контрольные точки обработке с состоянием, ограничивайте состояние и мониторьте отставание потребителя как заглавную метрику.
Используйте захват изменений данных для потоковой передачи из операционных баз данных вместо опроса.
Отдавайте предпочтение архитектуре «потоковая прежде всего» на сохраняемом воспроизводимом журнале перед сопровождением двух кодовых баз.
Открывайте потоки через потоковый SQL, материализованные представления и OLAP реального времени и держите каждый поток наблюдаемым и проверяемым.

Источники и дополнительное чтение

Tyler Akidau, Slava Chernyak, and Reuven Lax, “Streaming Systems.”
Martin Kleppmann, “Designing Data-Intensive Applications.”
Nathan Marz and James Warren, “Big Data” (Lambda architecture).
Jay Kreps, “Questioning the Lambda Architecture” (O’Reilly Radar).
Fabian Hueske and Vasiliki Kalavri, “Stream Processing with Apache Flink.”
Ben Stopford, “Designing Event-Driven Systems.”
Tyler Akidau and colleagues, “The Dataflow Model” (VLDB paper on windowing and watermarks).