Облачный доступ к объектному хранилищу обеспечивает практически неограниченную емкость, что означает, что вы можете держать данные в потоке до тех пор, пока это имеет смысл, пишет на портале The New Stack Майкл Дрогалис, главный технолог в офисе технического директора компании Confluent.

Потоковая передача событий в реальном времени стала в последнее десятилетие одним из самых заметных инструментов для инженеров-программистов. В опросе разработчиков Stack Overflow «2022 Developer Survey» платформа де-факто для потоковой передачи событий Apache Kafka вошла в число самых любимых фреймворков, а ее знание — в число самых высокооплачиваемых технических навыков.

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

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

Фактор 1. Временная зависимость ценности ваших данных

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

Старые данные обычно не упоминаются в одном ряду с потоковыми. Почему? До недавнего времени большинство стриминговых платформ создавались с относительно небольшим объемом памяти. Это имело смысл для их первоначального размещения в «голых» (bare-metal) дата-центрах, но с тех пор, как почти все переместилось в облако, эта модель стала несостоятельной. Облачный доступ к объектным хранилищам обеспечивает практически неограниченную емкость хранения.

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

Одним из наиболее интересных вариантов использования потоков исторических данных является бэктестинг онлайн-моделей машинного обучения. Команды часто сталкиваются с тем, что при развертывании обученной модели в производстве возникает необходимость внести в нее какие-либо изменения. Но как они могут быть уверены, что обновленная модель работает хорошо? Самый лучший способ — это протестировать ее на всем историческом трафике, а поскольку потоковая передача данных происходит без потерь, именно это вы и получаете.

Если соотношение времени и ценности ваших данных имеет смысл, потоковая передача — отличный способ получить ценность.

Фактор 2. Направление потока данных

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

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

Когда вы размышляете о том, полезны ли потоки для вашей задачи, отбросьте тему задержки и спросите себя: выгодна ли моей системе такая пуш-модель? Важны ли обновления без потерь?

Фактор 3. Стратегия истечения срока действия

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

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

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

Трудно предсказать будущее ПО, но одно неизменно — на горизонте всегда будут появляться новые технологии. Когда вы рассматриваете потоковую передачу данных для своего сценария использования, важно подумать над следующими ключевыми вопросами. Полезна ли пуш-модель? Полезен ли упорядоченный доступ к старым данным? Имеется ли простой способ удаления старых данных? Если на эти вопросы ответ положительный, то вы инвестируете в технологию потоковой передачи данных по правильным причинам.