Важно: Данный раздел актуален для Платформы данных в Публичном облаке и On-Premise.
Настоящий документ включает описание системы RT.StreamingKafka, ее возможности и архитектурные особенности.
Документ может быть полезен администраторам, программистам, разработчикам и сотрудникам подразделений информационных технологий, осуществляющих внедрение и сопровождение системы.
Наименование системы: RT.StreamingKafka.
RT.StreamingKafka — платформа потоковой передачи событий.
С технической точки зрения потоковая передача событий — это:
Таким образом, потоковая передача событий обеспечивает непрерывный поток и интерпретацию данных, так что нужная информация оказывается в нужном месте и в нужное время.
Потоковая передача событий может использоваться в различных отраслях и в различных целях организаций, например:
В настоящем документе использованы и определены следующие термины и сокращения:
Термин\сокращение | Определение |
---|---|
RT.StreamingKafka |
Платформа потоковой передачи событий с открытым исходным кодом, которая обеспечивает унифицированную, высокопроизводительную, отказоустойчивую, масштабируемую, распределённую и безопасную платформу потоковой передачи данных с низкой задержкой. Это система обмена сообщениями с концепцией “публикация-подписка”, которая позволяет распределённым приложениям принимать, обрабатывать и обмениваться данными в режиме реального времени. |
Admin API | API REST RT.StreamingKafka, который позволяет администраторам управлять кластерами, топиками, брокерами и другими компонентами RT.StreamingKafka и отслеживать их. |
Avro |
Платформа сериализации и обмена данными, которая предоставляет структуры данных, удалённый вызов процедур (RPC), компактный бинарный формат данных, файл-контейнер и использует JSON для представления схем. Схемы Avro гарантируют, что каждое поле правильно описано и документировано для использования с сериализаторами и десериализаторами. Вы можете либо отправлять схему с каждым сообщением, либо использовать Schema Registry для хранения и получения схем для использования потребителями и поставщиками для экономии полосы пропускания и места для хранения. |
Connect API | API RT.StreamingKafka, который позволяет коннектору читать стримы событий из исходной системы и записывать их в целевую систему. |
Connector, Коннектор | Абстрактный механизм, который обеспечивает связь, координацию или сотрудничество между компонентами путём передачи элементов данных из одного интерфейса в другой без изменения данных. |
Consumer, Потребитель |
Клиентское приложение RT.StreamingKafka, которое подписывается (т.е. читает и обрабатывает) сообщения о событиях из топика RT.StreamingKafka. Streams API и Consumer API — это два API, которые позволяют потребителям читать стримы событий из топиков RT.StreamingKafka. |
Consumer API |
API RT.StreamingKafka, используемый для получения (т.е. чтения) сообщений о событиях или записей из топиков RT.StreamingKafka и позволяющий потребителю RT.StreamingKafka подписаться на топик и читать сообщения о событиях по мере их поступления. Пакетная обработка — распространенный вариант использования Consumer API. |
Consumer group, Группа потребителей |
Единый логический потребитель, реализованный с несколькими физическими потребителями в целях пропускной способности и устойчивости. Разделив топики среди потребителей в группе на партиции, потребители в группе могут обрабатывать сообщения параллельно, увеличивая пропускную способность сообщений и обеспечивая балансировку нагрузки. |
Consumer offset, Потребительское смещение |
Уникальное и монотонно увеличивающееся целочисленное значение, которое однозначно определяет положение записи события в партиции. Когда потребитель подтверждает получение и обработку сообщения, он фиксирует значение смещения, которое сохраняется в специальном внутреннем топике __commit_offsets. |
Data mapping, Маппинг данных |
Процесс определения отношений или ассоциаций между элементами исходных данных и элементами целевых данных. Важный процесс интеграции, миграции и преобразования данных, обеспечивающий точное и последовательное представление данных при их перемещении или объединении. |
Data serialization, Сериализация данных |
Процесс преобразования структур данных или объектов в формат, который можно хранить или передавать, а затем восстанавливать в той же или другой компьютерной среде. Распространённый метод реализации сохранения данных, межпроцессного взаимодействия и взаимодействия объектов. |
Data stream, Стрим данных | Непрерывный поток записей данных, которые создаются и потребляются приложениями. |
Dead letter queue, DLQ, Очередь недоставленных писем | Очередь, в которую помещаются сообщения, которые не удалось успешно обработать коннектором приёмника. Вместо остановки коннектор приёмника отправляет сообщения, которые не удалось успешно записать в виде записей событий, в топик DLQ, в то время как коннектор приёмника продолжает обрабатывать сообщения. |
Deserializer, Десериализатор | Инструмент, который преобразует последовательный стрим байт обратно в объекты и параллельные данные. Десериализаторы работают с сериализаторами (известными вместе как Serdes) для обеспечения эффективного хранения и высокоскоростной передачи данных по сети. |
Event, Событие |
Значимое действие или возникновение чего-то, что произошло. События, которые могут быть распознаны программой, либо сгенерированные человеком, либо инициированные программным обеспечением, могут быть записаны в файл лога или другое хранилище данных. |
Event message, Сообщение о событии |
Запись события, отправленная в топик RT.StreamingKafka, представленная в виде пары ключ-значение. Каждое сообщение о событии состоит из пары ключ-значение, метки времени, типа сжатия, заголовков для метаданных (необязательно), а также идентификатора партиции и смещения (после записи сообщения). Ключ не является обязательным и может использоваться для идентификации события. Значение является обязательным и содержит сведения о произошедшем событии. |
Event record, Запись события |
Запись события, хранящаяся в топике RT.StreamingKafka. Записи о событиях организованы и надёжно хранятся в топиках. Примеры событий включают заказы, платежи, действия или измерения. Событие обычно содержит одно или несколько полей данных, описывающих факт, а также метку времени, обозначающую, когда событие было создано его источником. Событие также может содержать различные метаданные, такие как источник его происхождения (например, приложение или облачный сервис, создавший событие) и информацию уровня хранения (например, его положение в стриме событий). |
Event sink, Приёмник событий | Потребитель событий, который может включать приложения, облачные службы, базы данных, датчики Интернета вещей и многое другое. |
Event source, Источник событий | Поставщик событий, который может включать облачные службы, базы данных, датчики Интернета вещей, мэйнфреймы и многое другое. |
Event stream, Стрим событий | Непрерывный поток сообщений о событиях, создаваемых источником событий и потребляемых одним или несколькими потребителями. |
Event streaming, Потоковая передача событий |
Практика сбора данных о событиях из источников данных в режиме реального времени. Форма потоковой передачи данных, которая используется для сбора, хранения, обработки и реагирования на данные в режиме реального времени или ретроспективно. |
Event streaming platform, Платформа потоковой передачи событий | Платформа, на которую события могут быть записаны один раз, что позволяет распределённым функциям внутри организации реагировать в реальном времени. |
Event time, Время события | Время, когда событие произошло на машине поставщика, а не время, когда событие было обработано или записано. Время события часто используется в потоковой обработке для определения порядка событий и выполнения оконных операций. |
Exactly-once semantics, Семантика «точно один раз» |
Гарантия того, что сообщение будет доставлено ровно один раз и в том порядке, в котором оно было отправлено. Даже если поставщик попытается отправить сообщение или потребитель попытается обработать сообщение, сообщение будет доставлено ровно один раз. Эта гарантия достигается за счёт того, что брокер присваивает каждому сообщению уникальный идентификатор и сохраняет этот идентификатор в смещении потребителя. Смещение потребителя передаётся брокеру только после обработки сообщения. Если потребителю не удаётся обработать сообщение, оно доставляется повторно и обрабатывается снова. |
Internal topic, Внутренний топик |
Топик с префиксом двойного подчёркивания («__»), который автоматически создаётся компонентом RT.StreamingKafka для хранения метаданных о брокере, назначении партиций, смещениях потребителей и другой информации. Примеры внутренних топиков: __cluster_metadata, __consumer_offsets, __transaction_state. |
JSON Schema | Декларативный язык, используемый для сериализации и обмена данными для определения структур данных, указания форматов и валидации документов JSON. Это способ кодирования ожидаемых типов данных, свойств и ограничений, чтобы гарантировать, что все поля правильно описаны для использования с сериализаторами и десериализаторами. |
Bootstrap server, Сервер начальной загрузки |
Брокер RT.StreamingKafka, который клиент RT.StreamingKafka инициирует соединение с кластером RT.StreamingKafka и возвращает метаданные, которые включают адреса всех брокеров в кластере RT.StreamingKafka. Хотя для подключения к кластеру RT.StreamingKafka требуется только один сервер начальной загрузки, в списке серверов начальной загрузки можно указать несколько брокеров, чтобы обеспечить высокую доступность и отказоустойчивость в случае недоступности брокера. |
Broker, Брокер |
Сервер на уровне хранения RT.StreamingKafka, который хранит стримы событий из одного или нескольких источников. Кластер RT.StreamingKafka обычно состоит из нескольких брокеров. Каждый брокер в кластере также является сервером начальной загрузки. Это означает, что если вы можете подключиться к одному брокеру в кластере, вы сможете подключиться к каждому брокеру. |
Client, Клиент |
Клиент RT.StreamingKafka позволяет писать распределённые приложения и микросервисы, которые читают, записывают и обрабатывают стримы событий параллельно, масштабируемо и отказоустойчиво, даже в случае сетевых проблем или сбоев компьютеров. Клиентская библиотека RT.StreamingKafka предоставляет функции, классы и утилиты, которые позволяют разработчикам создавать клиентов-поставщиков RT.StreamingKafka (поставщики) и клиентов-потребителей (потребители) с использованием различных языков программирования. Основной способ создания готовых к работе поставщиков и потребителей — использовать предпочитаемый вами язык программирования и клиентскую библиотеку RT.StreamingKafka. |
Cluster, Кластер |
Группа взаимосвязанных брокеров RT.StreamingKafka, которые управляют и распределяют потоковую передачу, обработку и хранение данных в реальном времени, как если бы они были единой системой. Распределяя задачи и сервисы между несколькими брокерами RT.StreamingKafka, кластер RT.StreamingKafka повышает доступность, надёжность и производительность. |
Kafka Connect |
Компонент RT.StreamingKafka, который обеспечивает интеграцию данных между базами данных, хранилищами ключей, поисковыми индексами, файловыми системами и брокерами RT.StreamingKafka. Это экосистема клиентского приложения и подключаемых коннекторов. В качестве клиентского приложения Connect представляет собой серверный процесс, который работает на оборудовании, независимом от самих брокеров RT.StreamingKafka. Он масштабируем и отказоустойчив, что означает, что вы можете запустить кластер воркеров Connect, которые разделят нагрузку по перемещению данных в RT.StreamingKafka и из внешних систем, и в них. Connect также абстрагирует работу кода от пользователя и вместо этого требует для запуска только конфигурации JSON. |
Controller, Контроллер | Нода в кластере RT.StreamingKafka, которая отвечает за управление метаданными кластера и их изменение. Эта нода также передаёт изменения метаданных остальной части кластера. Когда RT.StreamingKafka использует ZooKeeper для управления метаданными, контроллер является брокером, а брокер сохраняет метаданные в ZooKeeper для резервного копирования и восстановления. С KRaft вы выделяете ноды RT.StreamingKafka для работы в качестве контроллеров, а метаданные хранятся в самой RT.StreamingKafka и не сохраняются в ZooKeeper. Благодаря этому KRaft обеспечивает более быстрое восстановление. |
Listener, Слушатель |
Эндпоинт, который брокеры RT.StreamingKafka обязаны использовать для связи с клиентами. Для кластеров RT.StreamingKafka слушатели настраиваются в свойстве listeners файла server.properties. Объявленные слушатели — это общедоступные эндпоинты, которые используются клиентами для подключения к кластеру RT.StreamingKafka. |
Metadata, Метаданные |
Информация о кластере RT.StreamingKafka и топиках, которые в нём хранятся. Эта информация включает в себя такие сведения, как: брокеры в кластере, доступные топики, партиции в каждом топике и расположение лидера для каждой партиции. Метаданные RT.StreamingKafka используются клиентами для обнаружения доступных брокеров и топиков, а также для определения того, какой брокер является лидером для определённой партиции. Эта информация важна для того, чтобы клиенты могли отправлять и получать сообщения в RT.StreamingKafka и обратно. |
Kafka Streams |
Библиотека обработки стримов для создания потоковых приложений и микросервисов, которые преобразуют (фильтруют, группируют, объединяют, объединяют и т.д.) входящие стримы событий в режиме реального времени в топики, хранящиеся в кластере RT.StreamingKafka. Streams API можно использовать для создания приложений, которые обрабатывают данные в режиме реального времени, непрерывно анализируют данные и создают конвейеры данных. |
Topic, Топик |
Определяемая пользователем категория или имя канала, в котором сообщения о событиях хранятся и публикуются поставщиками и на которые подписываются потребители. Каждый топик представляет собой лог сообщений о событиях. Топики хранятся в одной или нескольких партициях, которые распределяют брокеры записей топиков в кластере RT.StreamingKafka. Каждая партиция представляет собой упорядоченную неизменяемую последовательность записей, которые постоянно добавляются к топику. |
KRaft, Apache Kafka Raft | Консенсусный протокол, представленный в Kafka 2.4 для обеспечения управления метаданными RT.StreamingKafka с целью замены ZooKeeper. KRaft упрощает RT.StreamingKafka, поскольку позволяет управлять метаданными в самом RT.StreamingKafka, а не разделять их между ZooKeeper и RT.StreamingKafka. |
Offset, Смещение |
Целое число, присвоенное каждому сообщению, которое уникальным образом представляет его позицию в партиции топика RT.StreamingKafka, гарантируя порядок записей и позволяя потребителям воспроизводить сообщения в любой момент времени. Смещения хранятся у брокера RT.StreamingKafka, и потребители несут ответственность за внесение собственных смещений. RT.StreamingKafka не отслеживает, какие записи были прочитаны потребителем, а какие нет. Потребитель должен отслеживать эту информацию. |
Offset commit, Коммит смещения |
Процесс подтверждения потребителем того, что сообщение о событии было использовано, и сохранения текущей позиции смещения для определённой партиции в группе потребителей. Когда потребитель коммитит своё смещение, он коммитит смещение для следующего сообщения, которое он будет использовать. Например, если потребитель имеет смещение 5, он потребил сообщения с 0 по 4, а затем будет потреблять сообщение 5. Если потребитель выходит из строя или завершает работу, его партиции переназначаются другому потребителю, который инициирует потребление из последнего закоммиченного смещения каждой партиции. Коммит смещения хранится у брокера RT.StreamingKafka. Когда потребитель коммитит смещение, он отправляет запрос на коммит в кластер RT.StreamingKafka, указывая партицию и смещение, которое он хочет закоммитить для конкретной группы потребителей. Брокер RT.StreamingKafka, получающий запрос на коммит, затем сохраняет это смещение во внутреннем топике __consumer_offsets. |
Partition, Партиция |
Единица хранения данных, которая делит топик на несколько параллельных стримов событий, каждый из которых хранится на отдельных брокерах RT.StreamingKafka и может использоваться независимо. Партиционирование — ключевая концепция RT.StreamingKafka, поскольку оно позволяет RT.StreamingKafka масштабироваться горизонтально за счёт добавления в кластер дополнительных брокеров. Партиции также являются единицей параллелизма в RT.StreamingKafka. Топик может иметь одну или несколько партиций, и каждая партиция представляет собой упорядоченную неизменяемую последовательность записей событий, которая постоянно добавляется в лог партиции. |
Producer, Поставщик |
Клиентское приложение, которое публикует (записывает) данные в топик в кластере RT.StreamingKafka. Поставщики записывают данные в топик и являются единственными клиентами, которые могут записывать данные в топик. Каждая запись, записанная в топик, добавляется к партиции топика, выбранной поставщиком. |
Producer API |
API RT.StreamingKafka, который позволяет записывать данные в топик в кластере RT.StreamingKafka. Producer API используется клиентами-поставщиками для публикации данных в топике в кластере RT.StreamingKafka. |
Rebalancing, Перебалансировка |
Процесс перераспределения партиций топика между потребителями группы потребителей для повышения производительности и масштабируемости. Перебалансировка может произойти, если у потребителя произошёл сбой контрольного сигнала (heratbeat) и он был исключён из группы, он добровольно покинул группу, были обновлены метаданные для потребителя или потребитель присоединился к группе. |
Replication, Репликация | Процесс создания и обслуживания нескольких копий (или реплик) данных на разных нодах распределённой системы для повышения доступности и надёжности. |
Replication factor, Коэффициент\Фактор репликации | Количество реплик партиции, которые распределяются между брокерами в кластере. |
Schema, Схема |
Структурированное определение или схема, используемая для описания формата и структуры сообщений о событиях, отправляемых через платформу потоковой передачи событий RT.StreamingKafka. Схемы используются для проверки структуры данных в сообщениях о событиях и гарантируют, что поставщики и потребители отправляют и получают данные в одном и том же формате. Схемы определяются в Schema Registry. |
Schema Registry |
Централизованное хранилище для управления и валидации схем для данных сообщений топиков, в котором хранятся и управляются схемы для топиков RT.StreamingKafka. Это служба RESTful, которая хранит схемы для топиков RT.StreamingKafka и управляет ими. Schema Registry интегрирован с RT.StreamingKafka и Connect и обеспечивает центральное место для управления схемами и валидации данных. Поставщики и потребители топиков RT.StreamingKafka используют схемы для обеспечения согласованности и совместимости данных по мере развития схем. Schema Registry является ключевым компонентом управления стримами. |
Serializer, Сериализатор | Инструмент, который преобразует объекты и распараллеливает данные в последовательный стрим байтов. Сериализаторы работают с десериализаторами (известными вместе как Serdes) для обеспечения эффективного хранения и высокоскоростной передачи данных по сети. |
Streams API |
API RT.StreamingKafka, который позволяет создавать потоковые приложения и микросервисы, которые преобразуют (например, фильтруют, группируют, объединяют) входящие стримы событий в режиме реального времени в топики, хранящиеся в кластере RT.StreamingKafka. Streams API используется клиентами потоковой обработки для обработки данных в режиме реального времени, непрерывного анализа данных и построения конвейеров данных. |
RT.StreamingKafka — платформа потоковой передачи событий, которая сочетает в себе три необходимые ключевые возможности, поэтому с помощью неё можно реализовать различные варианты использования сквозной потоковой передачи событий:
И вся эта функциональность предоставляется распределённым, хорошо масштабируемым, гибким, отказоустойчивым и безопасным способом. RT.StreamingKafka можно развернуть на физическом оборудовании, виртуальных машинах и контейнерах, как локально, так и в облаке.
RT.StreamingKafka — распределённая система, состоящая из Серверов и Клиентов, которые обмениваются данными через высокопроизводительный сетевой протокол TCP. Её можно развернуть на физическом оборудовании, виртуальных машинах и контейнерах как в локальных, так и в облачных средах.
Серверы. RT.StreamingKafka запускается как кластер из одного или нескольких серверов, который может охватывать несколько центров обработки данных или облачных регионов. Некоторые из этих серверов образуют уровень хранения, называемый Брокерами. На других серверах запущен Kafka Connect, обеспечивающий непрерывный импорт и экспорт данных в виде стримов событий и в целом интеграцию RT.StreamingKafka с подключёнными системами, такими как реляционные базы данных и, например, с другими кластерами RT.StreamingKafka. Для реализации критически важных сценарией использования, кластер RT.StreamingKafka обладает высокой масштабируемостью и отказоустойчивостью: если какой-либо из его серверов выйдет из строя, другие серверы возьмут на себя его работу, чтобы обеспечить непрерывную работу без потери данных.
Клиенты позволяют писать распределённые приложения и микросервисы, которые читают, записывают и обрабатывают стримы событий параллельно, масштабируемо и отказоустойчиво даже в случае возникновения сетевых проблем или сбоев компьютеров. RT.StreamingKafka поставляется с некоторыми такими клиентами: доступны клиенты для Java и Scala, включая библиотеку Kafka Streams, для Go, Python, C/C++ и многих других языков программирования, а также REST API.
Событие фиксирует тот факт, что «что-то произошло» в мире или в вашем бизнесе. В документации оно также называется записью или сообщением. Когда вы читаете или записываете данные в RT.StreamingKafka, вы делаете это в форме событий. Концептуально событие имеет ключ, значение, метку времени и дополнительные заголовки метаданных. Вот пример события:
Поставщики — те клиентские приложения, которые публикуют (т.е. записывают) события в RT.StreamingKafka, а Потребители — те, которые подписываются (т.е. читают и обрабатывают) эти события. В RT.StreamingKafka поставщики и потребители полностью отделены друг от друга и не зависят друг от друга, что является ключевым элементом дизайна для достижения высокой масштабируемости RT.StreamingKafka. Например, поставщикам никогда не придётся ждать потребителей. RT.StreamingKafka предоставляет различные гарантии, такие как возможность обрабатывать события ровно один раз.
События организованы и надёжно хранятся в Топиках. Если простыми словами, то топик похож на папку в файловой системе, а события — это файлы в этой папке. Примером названия топика может быть Платежи. Топики в RT.StreamingKafka могут иметь ноль, одного или множество поставщиков, записывающих в него события, а также ноль, одного или множество потребителей, которые подписываются на эти события. События в топике можно читать так часто, как это необходимо — в отличие от традиционных систем обмена сообщениями, события не удаляются после использования. Вместо этого вы определяете, как долго RT.StreamingKafka должен хранить ваши события с помощью настройки конфигурации для каждого топика, после чего старые события будут удалены. Производительность RT.StreamingKafka практически не зависит от размера данных, поэтому хранить данные в течение длительного времени вполне нормально.
Топики разделены на Партиции, то есть топик распределён по нескольким «корзинам», расположенным у разных брокеров RT.StreamingKafka. Такое распределённое размещение данных очень важно для масштабируемости, поскольку оно позволяет клиентским приложениям одновременно читать и записывать данные от/на множество брокеров. Когда новое событие публикуется в топике, оно фактически добавляется в одну из партиций топика. События с одним и тем же ключом события (например, идентификатором клиента или транспортного средства) записываются в одну и ту же партицию, и RT.StreamingKafka гарантирует, что любой потребитель данной партиции топика всегда будет читать события этой партиции в том же порядке, в котором они были записаны.
Чтобы сделать данные отказоустойчивыми и высокодоступными, каждый топик можно реплицировать, даже между географическими регионами или центрами обработки данных, чтобы всегда было несколько брокеров, у которых есть копия данных на тот случай, если что-то пойдет не так. Обычно для производственных сред для коэффициента репликации устанавливается значение 3, т.е. всегда будет три копии данных. Эта репликация осуществляется на уровне топиков-партиций.
Архитектура RT.StreamingKafka состоит из двух уровней: