image

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»


В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.


Содержание




Рыночные тенденции: «связанный мир»


Сначала разберемся, почему Kafka сейчас повсюду используется. Это говорит о том, что рынку позарез нужен инструмент для потоковой передачи событий, но в то же время свидетельствует о том, что универсального решения для всех задач не существует. Kafka — НЕ универсальное решение для достижения «цифрового мира» (connected world), однако критически важный компонент!


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


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


«Связанные» автомобили (connected cars): огромные объемы телеметрии и послепродажное обслуживание


Компания Allied Market Research опубликовала отчет Global Opportunity Analysis and Industry Forecast, 2020–2027.


image

Согласно отчету, рынок «связанных» автомобилей с сетевыми возможностями подразумевает куда более широкий набор отраслей и сценариев использования, чем представляет большинство из вас. Вот несколько примеров: сетевая инфраструктура и связь, безопасность, развлечения, розничная торговля, послепродажное обслуживание, страхование автомобилей, использование данных третьими сторонами (например, в умном городе) и многое другое.

Игры: миллиарды игроков и огромные прибыли


Игровая индустрия уже больше всех остальных медиаотраслей, вместе взятых, и это все еще лишь начало новой эры, как считают в Bitkraft:


image

Ежемесячно по всему миру к игровому сообществу присоединяются миллионы новых игроков. В менее богатых странах востребованы связь и дешевые смартфоны. Новые бизнес-модели наподобие play to earn меняют игровую культуру следующего поколения игроков. Более масштабируемые и быстрые технологии вроде 5G предлагают и новые сценарии использования. Блокчейн и NFT навсегда меняют подходы к монетизации и рынок коллекционирования.

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

Чем является и чем не является Apache Kafka?


С Kafka часто возникает недопонимание. К примеру, все еще слишком часто встречаю мнение, что это очередь сообщений. Отчасти причина в том, что некоторые вендоры предлагают Kafka лишь для решения конкретной задачи (вроде передачи данных в озеро или хранилище), чтобы продать свой продукт. Так что, если вкратце, Kafka — это:


  • масштабируемая платформа сообщений реального времени, обрабатывающая миллионы сообщений в секунду;
  • платформа потоковой передачи сообщений для аналитики больших данных и маленьких объемов транзакционной обработки;
  • распределенное хранилище, обеспечивающее настоящее разделение для обработки замедленной обратной связи, с поддержкой различных протоколов соединений и воспроизведением событий в нужном порядке;
  • фреймворк интеграции данных для потоковой передачи ETL;
  • фреймворк обработки данных для непрерывной обработки stateless- или stateful-потоков.

Такое сочетание возможностей в единой платформе делает Kafka уникальным (и успешным) инструментом.


Kafka — это НЕ:


  • прокси-сервер для миллионов клиентов (вроде мобильных приложений), но существуют Kafka-нативные прокси вроде REST или MQTT;
  • платформа управления API, но эти инструменты обычно сопутствуют и используются для создания, управления жизненным циклом или монетизации API Kafka;
  • база данных для сложных запросов и пакетной аналитики, но он подходит для транзакционных запросов и относительно простых агрегаций, особенно с ksqlDB;
  • IoT-платформа с функциями управления устройствами, но возможна прямая Kafka-нативная интеграция с (некоторыми) IoT-протоколами вроде MQTT или OPC-UA;
  • технология для приложений строго в реальном времени вроде критических для безопасности или детерминистских систем, но это верно и для любого другого фреймворка. Встроенное ПО — другое дело!

То есть Kafka дополняет, но не конкурирует с подобными технологиями. Выбирайте для решения задачи правильный инструмент!


Примеры использования Apache Kafka в связанном мире


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


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


  • Audi: платформа для подключения к сети автомобилей, работающая в разных регионах и у разных облачных провайдеров.
  • BMW: умные заводы для оптимизации цепочек поставок и логистики.
  • SolarPower: полноценные решения и сервисы на основе солнечной энергии по всему миру.
  • Royal Caribbean: развлечения на круизных лайнерах с автономными edge-сервисами и агрегированием в гибридном облаке.
  • Disney+ Hotstar: мобильный интерактивный медиаконтент, игры и ставки для миллионов пользователей.

И многое другое.


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


Когда стоит использовать Apache Kafka?


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


Kafka обрабатывает в реальном времени большие объемы IoT- и мобильных данных


Обработка огромных объемов в реальном времени — одна из главных особенностей Kafka. Tesla — не просто автопроизводитель, это технологическая компания, которая создает много инновационного и передового ПО. Они предоставляют энергетическую инфраструктуру для автомобилей со своими Tesla Supercharger, вырабатывают электричество из солнечной энергии на своих Gigafactory и многое другое. Важная составляющая их успеха — это обработка и анализ данных от автомобилей, умных электросетей и фабрик, а также интеграция с бэкендом ИТ-сервисов в реальном времени. Tesla создала инфраструктуру платформы данных на основе Kafka «для поддержки миллионов устройств и триллионов точек данных в день». А в 2019-м компания показала впечатляющую историю развития их применения Kafka:


image

Напомню, что Kafka способен делать гораздо больше, чем просто обрабатывать сообщения. Я повторяю это постоянно, и все же слишком многие этого не понимают. Kafka — это слой распределенного хранения, который отделяет производителей от потребителей. Кроме того, Kafka-нативные обработчики вроде Kafka Streams and ksqlDB обеспечивают обработку в реальном времени.

Kafka сопоставляет транзакционные и IoT-данные из MES- и ERP-систем


Масштабная интеграция данных в реальном временем необходима для аналитики и использования транзакционных систем вроде ERP и MES. Для решения этой задачи ядро потоковой передачи дополняет Kafka Connect и стороннее промежуточное ПО.


BMW использует критически важные данные из Kafka в edge- (например, на умных фабриках) и в публичных облаках. Kafka обеспечивает разделение, прозрачность и инновационность, а продукты и экспертиза из Confluent добавляет стабильности. Последнее необходимо для успешного производства, потому что каждая минута простоя обходится в целое состояние. Почитайте мою статью Apache Kafka as Data Historian – an IIoT / Industry 4.0 Real-Time Data Lake, чтобы понять, как Kafka улучшает общую эффективность оборудования (Overall Equipment Effectiveness, OEE) на производстве.


BMW оптимизирует свои цепочки поставок в реальном времени. Система предоставляет информацию о нужных запасах физически и в транзакционных системах вроде ERP на основе SAP. Девиз «в нужном месте и в нужное время» крайне важен для многих критических приложений. Интеграция между Kafka и SAP необходима для почти половины моих читателей. Kafka лежит в основе не только интеграционных механизмов, но и многих транзакционных ERP- и MES-платформ следующего поколения.


В корпоративном секторе Kafka интегрируется со всеми не-IoT-системами в edge-, гибридных или мультиоблачных средах


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


Полное разделение разных интерфейсов — уникальное преимущество Kafka по сравнению с другими брокерами сообщений, такими как IBM MQ, RabbitMQ и MQTT. Я подробно рассмотрел это в своей статье о Domain-driven-архитектуре с Kafka.


В отрасли стало привычным модернизировать инфраструктуру и создавать гибридные облачные архитектуры с помощью Apache Kafka.


Одна из моих любимых историй успеха — история Unity. Эта компания предлагает платформу трехмерного моделирования в реальном времени для игровой индустрии, а также для внедрения функций дополненной и виртуальной реальности в других отраслях. К 2019 году продукты компании уже установили 33 млрд раз, на 3 миллиардах устройств по всему миру. Unity управляет одной из крупнейших сетей монетизации. Они перенесли свою платформу с самоуправляемого Kafka в полностью управляемое Confluent Cloud. Команда проекта выполнила переключение без простоев и потери данных. Почитайте об этом в блоге Confluent.


Kafka — масштабируемый бэкенд реального времени для мобильных сервисов, игровых платформ и тотализаторов


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


  • Сервисы перемещений: Uber, Lyft, FREE NOW, Grab, Otonomo, Here Technologies и пр.
  • Игровые сервисы: Disney+ Hotstar, Sony Playstation, Tencent, Big Fish Games и пр.
  • Тотализаторы: William Hill, Sky Betting и пр.

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


А эти сценарии использования не менее важны, чем платежные процессы в основной банковской платформе. Крайне важно соблюдать законодательство и не допускать каких-либо потерь данных. Межрегиональные кластеры (например, Kafka-кластер, распределенный между восточным побережьем США, центральной частью и западным побережьем) обеспечивают высокую доступность без простоев и потерь данных в случае аварий.


image

Автомобили, техника или IoT-устройства привязаны к одному брокеру Kafka


Edge-вычисления с нами надолго. В некоторых случаях требуется разворачивать Kafka-кластер или отдельный Kafka-сервер вне ЦОД. Низкая задержка, экономичность, кибербезопасность или отсутствие интернета — вот причины, из-за которых для работы с Kafka выбирают edge. Вот несколько примеров:


  • Автономный edge в логистике для сохранения журналов, информации с датчиков и изображений при отсутствии доступа к интернету (например, когда грузовик в пути или дрон летает вокруг корабля), пока не появится возможность выгрузить все это по сети.
  • Взаимодействие Vehicle-to-Everything (V2X) в маленьких локальных ЦОДах вроде AWS Outposts (через шлюз наподобие MQTT в случае больших расстояний, большего количества устройств или неустойчивой сети) либо через прямое соединение с Kafka-клиентами для сотен единиц техники, например, на умном производстве.
  • Автономные сервисы перемещений наподобие интеграции автомобильной инфраструктуры с играми, ГИС или движками рекомендаций локально обслуживаемых партнерских сервисов (например, следующий «Макдоналдс» будет через 16 километров, вот скидка).

Круизный оператор Royal Caribbean — прекрасный пример успешного использования Kafka. Компания управляет четырьмя крупнейшими пассажирскими лайнерами в мире. В январе 2021 года в ее флот входило 24 корабля и еще шесть было заказано. Royal Caribbean реализовала один из самых известных примеров использования Kafka в граничных сетях. На каждом лайнере развернут локальный кластер, обеспечивающий обработку платежей и данных по программе лояльности, рекомендации о покупках и т.д.


image

Я уже рассказывал об этом и других примерах использования Kafka в граничных сетях: описывал такой сценарий, рассказывал об архитектуре для Kafka и 5G-развертываниях с низкой задержкой на основе Kafka.



Когда НЕ нужно использовать Apache Kafka?


Наконец-то мы переходим к тому, что вы так все ждали, верно? Но ведь важно было сначала понять, когда стоит применять Kafka, чтобы легко было объяснить, когда этого делать не следует.


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


Kafka не предназначен для работы строго в реальном времени


С определением термина «реальное время» не все так просто. Зачастую это лишь маркетинговый термин. Программы реального времени обязаны гарантировать отклик в течение определенного периода времени. Kafka — и все остальные фреймворки, продукты и облачные сервисы, используемые в этом контексте, — относится к приложениям «мягкого» реального времени. А многие IoT-приложения должны работать строго в реальном времени без задержек.


image

«Мягкое» реальное время используется для:
  • Обмена сообщениями между приложениями.
  • Сбора данных из разных источников одним или несколькими потребителями.
  • Обработки и сопоставления данных (часто называют потоковой передачей событий или обработкой потока событий).

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


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


В большинстве сценариев в реальном времени требуется «всего лишь» обрабатывать данные в диапазоне от миллисекунды до секунды. В этом случае Kafka подходит идеально. Многие финтех-компании полагаются на него при работе с критически важными транзакционными данными, даже в трейдинге. Еще один хороший пример потоковой передачи с низкой задержкой с помощью Kafka и облачной 5G-инфраструктуры — это MEC, multi-access edge computing.


Kafka не является детерминистским для встроенных и критически важных для безопасности систем


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


Вот несколько примеров, где Kafka НЕЛЬЗЯ использовать:


  • Критически важная обработка данных в автомобиле или другой технике. Для этого есть Autosar, MINRA C, ассемблер и другие подобные технологии.
  • Связь по шине CAN между электронными блоками управления.
  • Робототехника. Для этого есть C / C++ или другие низкоуровневые языки в сочетании с фреймворками вроде Industrial ROS (Robot Operating System).
  • Критически важное машинное обучение или глубокое обучение (например, в автономном вождении).
  • Связь между транспортными средствами (Vehicle-to-Vehicle, V2V). Для этого есть прямое соединение 5G без посредников вроде Kafka.

Подробнее на эту тему я рассказал в статье Apache Kafka is NOT Hard Real-Time BUT Used Everywhere in Automotive and Industrial IoT.


Подытоживая, связанную с безопасностью обработку данных нужно реализовывать на отдельном низкоуровневом языке и соответствующих решениях. Но не на Kafka! Это верно и для любого другого ПО для взаимодействия ИТ-систем. Поэтому замена Kafka на IBM MQ, Flink, Spark, Snowflake или другой подобный инструмент не поможет.


Kafka НЕ предназначен для плохих сетей


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


Из этого правила есть несколько исключений, но вообще используйте технологии, специально разработанные для решения проблемы плохих сетей. Самый известный пример — MQTT. То есть Kafka и MQTT — это друзья, а не враги. Их сочетание обладает огромными возможностями и широко используется во многих отраслях, я написал о нем целую серию статей. С помощью MQTT, Kafka и Tensorflow в архитектуре Kappa мы сделали инфраструктуру для подключения автомобилей, которая обрабатывает 100 000 потоков для прогнозирования в реальном времени.


Kafka НЕ обеспечивает подключение десятков тысяч клиентских приложений


Другой особенностью, не позволяющей считать Kafka интеграционным решением, является невозможность подключаться к десяткам тысяч клиентов. Если вам нужно сделать инфраструктуру для подключения автомобилей или мобильную игровую платформу (например, для тех же автомобилей или смартфонов), то вы не сможете подключаться к Kafka напрямую. Правильным посредником между тысячами клиентов и Kafka для серверной обработки в реальном времени и интеграции с будущими потребителями в виде озер данных, хранилищ или самописных приложений будет выделенный прокси — HTTP-шлюз или брокер MQTT.


Какие ограничения по количеству подключений к Kafka? Как это часто бывает, сложно сказать. У меня были заказчики, которые подключались из заводского цеха напрямую через .NET и из клиентов Java Kafka напрямую к облаку с кластером Kafka. Прямые гибридные соединения обычно работают хорошо, если количество машин, участков передачи данных по электросетям, IoT-шлюзов и IoT-устройств измеряется сотнями. А если их больше, то вам нужно решить: а) нужен ли промежуточный прокси или б) разворачивать ли «edge-вычисления» с Kafka или без него для снижения задержки и расходов.


Когда ВЕРОЯТНО можно использовать Apache Kafka?


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


Kafka (обычно) НЕ заменяет другую базу данных


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


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


  • Kafka вечно может хранить данные надежно и с высокой доступностью, в соответствии с критериями ACID.
  • Kafka предлагает дополнительные возможности по работе с архивными данными.
  • Нативные для Kafka дополнения вроде ksqlDB и Tiered Storage еще больше расширяют его возможности по обработке и долгосрочному хранению сообщений.
  • Можно создавать stateful-приложения, работающие с клиентами Kafka (микросервисы, бизнес-приложения) без дополнительных внешних СУБД.
  • Kafka не заменяет существующие базы данных, хранилища или озера данных вроде MySQL, MongoDB, Elasticsearch, Hadoop, Snowflake, Google BigQuery и т. д.
  • Kafka и другие базы дополняют друг друга, поэтому выбирайте инструмент в соответствии с задачей. Зачастую из центральной инфраструктуры на основе событий вырастают и обновляются в реальном времени специализированные материализованные представления.
  • Есть дополнительные возможности для двунаправленной pull- и push-интеграции между Kafka и другими базами данных, что позволяет им еще лучше дополнять друг друга.

Подробнее об использовании Kafka в качестве базы данных рассказано в статье Can Apache Kafka replace a database, data warehouse, or data lake?


Kafka (обычно) НЕ обрабатывает большие сообщения


Kafka не предназначен для больших сообщений. Точка.


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


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


image

Знайте о разных шаблонах проектирования и выбирайте для своей задачи правильную технологию. Подробнее о сценариях обработки больших файлов с помощью Kafka читайте в этой статье: Handling Large Messages with Apache Kafka (CSV, XML, Image, Video, Audio, Files).

Kafka (обычно) НЕ IoT-шлюз для конечной интеграции промышленных протоколов


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


Предположим, что TCP-соединение с Kafka-клиентом не имеет смысла или невозможно. В таких ситуациях самое популярное решение — REST-прокси в качестве посредника между клиентами и Kafka-кластером. Клиенты взаимодействуют с потоковой платформой через синхронный HTTP(S).


Сценарии использования HTTP и API REST с Apache Kafka включают в себя слой управления, слой данных, который производит и потребляет сообщения, автоматизацию и соответствующие DevOps-задачи


К сожалению, многие IoT-проекты требуют гораздо более сложной интеграции, и я не имею в виду относительно простые интеграции через коннектор MQTT или OPC-UA. К сложностям в промышленных IoT-проектах относится:


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

Таким образом, многие IoT-проекты дополняют Kafka специально разработанной IoT-платформой. Большинство IoT-продуктов и облачных сервисов имеют закрытый код, но предоставляют открытые интерфейсы и архитектуру. Сфера open-source в этой отрасли мала. Отличной альтернативой (в некоторых сценариях) является Apache PLC4X — этот фреймворк интегрируется со многими закрытыми старыми протоколами, такими как Siemens S7, Modbus, Allen Bradley, Beckhoff ADS и другими. Также PLC4X предоставляет коннектор Kafka Connect для нативной и масштабируемой интеграции с Kafka.


Современные архивные хранилища — открытые и гибкие. В основе многих стратегических проектов IoT-модернизации производств и гибридных облаков лежит потоковая передача событий:


image

Kafka НЕ блокчейн (но актуален для web3, криптоторговли, NFT, off-chain, сайдчейнов и оракулов)


Kafka — это распределенный журнал фиксаций. Заложенные в него идеи очень похожи на блокчейн, я подробно рассматривал это в статье Apache Kafka and Blockchain — Comparison and a Kafka-native Implementation.


Блокчейн следует использовать ТОЛЬКО в тех случаях, когда необходимо сотрудничество различных недоверенных сторон. Для большинства корпоративных проектов это будет ненужным усложнением. Достаточно распределенного журнала регистраций (Kafka) или защищенной распределенной книги учета (расширенный Kafka).


Учитывая это, особенно интересно, что я вижу все больше компаний, которые используют Kafka в торговых криптоплатформах, биржах и NFT-магазинах.


Подчеркну: на этих платформах Kafka НЕ блокчейн. Блокчейн — это криптовалюты вроде Bitcoin или платформы смарт-контрактов вроде Ethereum, на основе которых люди создают новые распределенные приложения, например, NFT для игровой индустрии и индустрии искусств. Kafka — это потоковая платформа для соединения этих блокчейнов с прочими «ораклами» (не блокчейн-приложениями) наподобие CRM, озер данных, хранилищ и т. д.


image

TokenAnalyst — превосходный пример использования Kafka для интеграции блокчейн-данных из Bitcoin и Ethereum с их аналитическими инструментами. Kafka Streams предлагает потоковое stateful-приложение для защиты от использования некорректных блоков в последующих агрегирующих вычислениях. К примеру, в TokenAnalyst разработали компонент подтверждения новых блоков, который разрешает ситуации реорганизации с помощью временного удерживания блоков и их передачи только после достижения определенного количества подтверждений (при этом дочерние элементы этих блоков продолжают вычисляться).

В некоторых продвинутых сценариях Kafka используют для реализации сайдчейна или off-chain-платформ, когда оригинальные блокчейны недостаточно хорошо масштабируются (блокчейн относят к on-chain-данным). Проблема обработки только однозначной (!) транзакции в секунду характерна не только для Bitcoin. Большинство современных блокчейнов не способны и близко масштабироваться до рабочих нагрузок Kafka в реальном времени.


Всем, от DAO до самых крупных компаний, необходимо отслеживать состояние блокчейн-инфраструктуры и IoT-компонентов даже в распределенных сетях, чтобы избегать простоев, защищаться от злоумышленников и обеспечивать доступность данных блокчейна. Kafka позволяет предоставлять эти данные заинтересованным сторонам без использования программных агентов, при необходимости масштабируя и обеспечивая отображение информации нужным пользователям до потери узла. Это актуально для передовых web3- и IoT-проектов вроде Helium или более простых, закрытых, распределенных бухгалтерских книг, таких как R3 Corda.


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


Подводя итоги, Kafka НЕ…


…замена вашей любимой базе данных или хранилищу;
…работает строго в реальном времени для критически важных встроенных нагрузок;
…прокси для тысяч клиентов в плохих сетях;
…решение для управления API;
…IoT-шлюз;
…блокчейн.


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


Вебинар по Apache Kafka


Всех, кто дочитал до конца, приглашаем 11 апреля в 11.00 на бесплатный практический вебинар, посвященный работе с Apache Kafka в микросервисном приложении.


На вебинаре мы не только разберем теорию по брокерам сообщений Apache Kafka, но и развернем кластер Apache Kafka в облаке и подключим его к микросервисному приложению.


Регистрация здесь.

Комментарии (0)