#kafka #статьи
Проблема сквозного шифрования в Kafka
Apache Kafka часто используется в качестве middleware-слоя для асинхронной интеграции множества приложений и для взаимодействия компонентов микросервисной архитектуры. Каждая часть такой сложной системы является независимым элементом развертывания и обычно реализована с помощью уникального стека технологий. Поэтому наивный подход с шифрованием чувствительных данных в полезной нагрузке на стороне продюсера и расшифровкой на потребителе, становится неудобным. Например, данные, зашифрованные с помощью Python-библиотеки, проблематично расшифровать с помощью Java.
Помимо обеспечения языковой совместимости, необходимо также обеспечить управление ротацией ключей. Это требует более сложного контракта интерфейса или хранения ключей в заголовках записей, проходящих через библиотеку шифрования. По мере включения в потоковый конвейер новых приложений с разными библиотеками шифрации/дешифрации данных возникает потребность в матрице совместимости, чтобы каждая команда, ответственная за разработку нового сервиса знала об ограничениях стека технологий.
Кроме постоянной поддержки такой матрицы совместимости и развития инструмента сквозного шифрования, необходимо также определять политики доступа к операции шифрования, что усложняет развертывание и интеграционное тестирование. Сквозное шифрование требует много скоординированных усилий, общего понимания, общих целей и ответственности, чего сложно достичь в крупной распределенной экосистеме.
Упростить проблему шифрования данных в Apache Kafka можно с помощью Java-приложения Conductor Gateway, которое полностью совместимо с протоколом Kafka и не зависит от провайдера платформы.
Что оно собой представляет, рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
Проблема сквозного шифрования в Kafka
Apache Kafka часто используется в качестве middleware-слоя для асинхронной интеграции множества приложений и для взаимодействия компонентов микросервисной архитектуры. Каждая часть такой сложной системы является независимым элементом развертывания и обычно реализована с помощью уникального стека технологий. Поэтому наивный подход с шифрованием чувствительных данных в полезной нагрузке на стороне продюсера и расшифровкой на потребителе, становится неудобным. Например, данные, зашифрованные с помощью Python-библиотеки, проблематично расшифровать с помощью Java.
Помимо обеспечения языковой совместимости, необходимо также обеспечить управление ротацией ключей. Это требует более сложного контракта интерфейса или хранения ключей в заголовках записей, проходящих через библиотеку шифрования. По мере включения в потоковый конвейер новых приложений с разными библиотеками шифрации/дешифрации данных возникает потребность в матрице совместимости, чтобы каждая команда, ответственная за разработку нового сервиса знала об ограничениях стека технологий.
Кроме постоянной поддержки такой матрицы совместимости и развития инструмента сквозного шифрования, необходимо также определять политики доступа к операции шифрования, что усложняет развертывание и интеграционное тестирование. Сквозное шифрование требует много скоординированных усилий, общего понимания, общих целей и ответственности, чего сложно достичь в крупной распределенной экосистеме.
Упростить проблему шифрования данных в Apache Kafka можно с помощью Java-приложения Conductor Gateway, которое полностью совместимо с протоколом Kafka и не зависит от провайдера платформы.
Что оно собой представляет, рассмотрим далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Зачем вам Conduktor Gateway для Apache Kafka
Как улучшить управляемость шифрования конфиденциальных данных в Apache Kafka с Conduktor Gateway: разбор Java-приложения для EDA-систем
#kafka #статьи
Что такое Conduktor Gateway
Ядро Conduktor Gateway используется в качестве транспортного уровня между клиентскими приложениями Kafka и кластерами Kafka.
Этот транспортный уровень расширяется за счет взаимодействия с Kafka, изменения данных или выполнения логических операций для повышения ценности.
Сам шлюз состоит из двух концептуальных частей: ядра и перехватчиков, обеспечивая следующие функции:
✔️виртуализация кластеров для клиентов посредством мультиарендности;
✔️шифрование на уровне полей в записях Kafka;
✔️хаос-инжиниринг для тестирования сбоев по различным сценариям;
✔️защита структуры и правильного использования среды Kafka.
Продолжим разбирать на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
Что такое Conduktor Gateway
Ядро Conduktor Gateway используется в качестве транспортного уровня между клиентскими приложениями Kafka и кластерами Kafka.
Этот транспортный уровень расширяется за счет взаимодействия с Kafka, изменения данных или выполнения логических операций для повышения ценности.
Сам шлюз состоит из двух концептуальных частей: ядра и перехватчиков, обеспечивая следующие функции:
✔️виртуализация кластеров для клиентов посредством мультиарендности;
✔️шифрование на уровне полей в записях Kafka;
✔️хаос-инжиниринг для тестирования сбоев по различным сценариям;
✔️защита структуры и правильного использования среды Kafka.
Продолжим разбирать на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
#kafka @BigDataSchool_ru
Тест на основы Kafka
В каком виде хранятся данные потоков в KSQL?
Тест на основы Kafka
В каком виде хранятся данные потоков в KSQL?
Anonymous Quiz
29%
в виде упорядоченных коллекций
59%
в виде пар ключ/значение
0%
в виде массивов
12%
в виде списков
#kafka #статьи
Шифрование и дешифрация полезной нагрузки в Apache Kafka с Conduktor Gateway
Поскольку Conduktor Gateway полностью соответствует протоколу Kafka, cквозное шифрование с этим шлюзом не требует никаких изменений в клиентских приложениях.
При этом обеспечивается полная независимость от языка и даже поддерживается работа с kafka-console-consumer.sh.
Таким образом, разработчики контролируют свои данные, не беспокоясь о безопасности, версий и совместимости на всех языках. Инженеры по безопасности могут выявлять, маркировать и применять адаптированные правила шифрования, поскольку все инструменты для этого консолидированы в одном месте. Инженеры по эксплуатации способствуют плавной интеграции усилий разработчиков и команды безопасности, делая сложный механизм операций с данными невидимым для постороннего глаза.
Такое эффективное разграничение ролей повышает эффективность каждой команды и приводит к слаженной работе, обеспечивающей безопасную и бесперебойную эксплуатацию Apache Kafka.
Рассмотрим пример, когда инженеры по безопасности определили правила шифрования/расшифровки полей password и visa в топике customers (продолжим по ссылке).
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
Шифрование и дешифрация полезной нагрузки в Apache Kafka с Conduktor Gateway
Поскольку Conduktor Gateway полностью соответствует протоколу Kafka, cквозное шифрование с этим шлюзом не требует никаких изменений в клиентских приложениях.
При этом обеспечивается полная независимость от языка и даже поддерживается работа с kafka-console-consumer.sh.
Таким образом, разработчики контролируют свои данные, не беспокоясь о безопасности, версий и совместимости на всех языках. Инженеры по безопасности могут выявлять, маркировать и применять адаптированные правила шифрования, поскольку все инструменты для этого консолидированы в одном месте. Инженеры по эксплуатации способствуют плавной интеграции усилий разработчиков и команды безопасности, делая сложный механизм операций с данными невидимым для постороннего глаза.
Такое эффективное разграничение ролей повышает эффективность каждой команды и приводит к слаженной работе, обеспечивающей безопасную и бесперебойную эксплуатацию Apache Kafka.
Рассмотрим пример, когда инженеры по безопасности определили правила шифрования/расшифровки полей password и visa в топике customers (продолжим по ссылке).
@BigDataSchool_ru
https://bigdataschool.ru/blog/what-is-conduktor-gateway-for-apache-kafka.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Зачем вам Conduktor Gateway для Apache Kafka
Как улучшить управляемость шифрования конфиденциальных данных в Apache Kafka с Conduktor Gateway: разбор Java-приложения для EDA-систем
#kafka @BigDataSchool_ru
Тест на основы Kafka.
Что такое перебалансировка данных в Kafka?
Тест на основы Kafka.
Что такое перебалансировка данных в Kafka?
Anonymous Quiz
20%
передача раздела от неактивного подписчика активному
45%
распределение данных по брокерам
10%
распределение новых подписчиков по топикам
25%
перераспределение данных по топикам
#kafka @BigDataSchool_ru
Тест по основам Kafka.
Какие параметры используются для полного удаления потребительской группы?
Тест по основам Kafka.
Какие параметры используются для полного удаления потребительской группы?
Anonymous Quiz
14%
—erase, —group
0%
—destroy
62%
—delete, —group
24%
—destroy, —group
#kafka #статьи
6 стратегий устранения сбоев в Apache Kafka
1️⃣Первым вариантом устранения сбоев является удаление неудавшихся сообщений. Эта стратегия более известна как сброс нагрузки. Когда обработчик обратного вызова получает временную ошибку, связанную с отправленным сообщением, он удаляет связанные данные из вышестоящих структур данных и не выполняет никаких дальнейших действий. Приложение может зарегистрировать событие. Эта ситуация должна быть видна операторам извне посредством мониторинга.
2️⃣Вторым вариантом является создание обратного давления в приложении-потребителе и повторная отправка данных продюсером. Продюсер повторно отправляет сообщения об истечении времени ожидания в клиентскую библиотеку. В случае сбоя Kafka и невозможности публикации сообщений приложение-потребитель прекращает ожидать входящего трафика до тех пор, пока сообщения не начнут поступать снова. Достоинством этого решения является отсутствие внешних зависимостей и потерь сообщений.
Но недостатки тут следующие:
➖реализация повторных попыток поверх клиентских библиотек Kafka не рекомендуется, поскольку клиентская библиотека уже содержат механизм повтора, который поддерживает порядок сообщений и обеспечивает идемпотентную выработку.
➖порядок сообщений теряется;
➖потребитель может получить одну и ту же полезную нагрузку дважды, если продюсер повторно отправляет сообщение, время ожидания которого истекло после отправки брокеру и первоначально не получил ответа;
➖блокировка системы входящего трафика фактически закрывает сервис без предупреждения внешних сторон.
➖изменение конструкции приложения для оказания обратного давления может потребовать явного изменения контракта API на границе системы.
3️⃣Альтернативной стратегией является запись всех сообщений локально и их асинхронная запись в Kafka. В случае сбоя приложение-продюсер отправляет все сообщения в альтернативное локальное хранилище. Этот вариант менее сложен варианта с автоматическим выключателем: приложение может продолжать принимать входящий трафик гораздо дольше. Для возврата в нормальное рабочее состояние не требуется никакого ручного вмешательства. Нет потерь сообщений. Однако, локальное хранилище будет менее надежным, чем кластер, который оно защищает, и станет потенциальной единственной точкой отказа. Также возникает дополнительная сквозная задержка.
4️⃣Вместо этого можно отправлять сообщения об истечении тайм-аута в локальное хранилище и их загрузка в Kafka с помощью дополнительного побочного процесса. Этот вариант использует локальное хранилище в качестве канала недоставленных сообщений. Пакетный процесс импортирует эти сообщения в Kafka, как только система вернется в нормальное состояние.
Плюсами этого варианта является низкая сложность реализации, а также приложение может продолжать принимать входящий трафик намного дольше. Нет потерь сообщений, хотя их порядок теряется.
Недостатком этой стратегии становится сложность записи в локальное хранилище и необходимость ручного вмешательства для каждого экземпляра приложения, чтобы восстановить все сообщения.
5️⃣Вместо этого можно внедрить автоматический выключатель для временной отправки сообщений в локальное хранилище. Но это довольно сложно с точки зрения реализации: система отключает поток данных в Kafka в случае сбоя этой платформы и перенаправляет сообщения в локальное хранилище. Приложение воспроизводит эти сообщения из локального хранилища и повторно отправляет их после восстановления Kafka. Затем возобновляется регулярный поток.
Сложность в том, что несколько сообщений будут находиться в очередях продюсера. Проблемы с синхронизацией могут возникнуть при размыкании и замыкании автоматического выключателя. Чтобы понять, когда следует размыкать автоматический выключатель, надо знать состояние кластера на основе клиента Kafka через JMX в Java или статистику библиотеки librdkafka. Вместо этого следует отслеживать частоту ошибок в данных, например, отчеты об доставке с ошибками.
Последний 6️⃣ разберем на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-prevent-kafka-failures.html
6 стратегий устранения сбоев в Apache Kafka
1️⃣Первым вариантом устранения сбоев является удаление неудавшихся сообщений. Эта стратегия более известна как сброс нагрузки. Когда обработчик обратного вызова получает временную ошибку, связанную с отправленным сообщением, он удаляет связанные данные из вышестоящих структур данных и не выполняет никаких дальнейших действий. Приложение может зарегистрировать событие. Эта ситуация должна быть видна операторам извне посредством мониторинга.
2️⃣Вторым вариантом является создание обратного давления в приложении-потребителе и повторная отправка данных продюсером. Продюсер повторно отправляет сообщения об истечении времени ожидания в клиентскую библиотеку. В случае сбоя Kafka и невозможности публикации сообщений приложение-потребитель прекращает ожидать входящего трафика до тех пор, пока сообщения не начнут поступать снова. Достоинством этого решения является отсутствие внешних зависимостей и потерь сообщений.
Но недостатки тут следующие:
➖реализация повторных попыток поверх клиентских библиотек Kafka не рекомендуется, поскольку клиентская библиотека уже содержат механизм повтора, который поддерживает порядок сообщений и обеспечивает идемпотентную выработку.
➖порядок сообщений теряется;
➖потребитель может получить одну и ту же полезную нагрузку дважды, если продюсер повторно отправляет сообщение, время ожидания которого истекло после отправки брокеру и первоначально не получил ответа;
➖блокировка системы входящего трафика фактически закрывает сервис без предупреждения внешних сторон.
➖изменение конструкции приложения для оказания обратного давления может потребовать явного изменения контракта API на границе системы.
3️⃣Альтернативной стратегией является запись всех сообщений локально и их асинхронная запись в Kafka. В случае сбоя приложение-продюсер отправляет все сообщения в альтернативное локальное хранилище. Этот вариант менее сложен варианта с автоматическим выключателем: приложение может продолжать принимать входящий трафик гораздо дольше. Для возврата в нормальное рабочее состояние не требуется никакого ручного вмешательства. Нет потерь сообщений. Однако, локальное хранилище будет менее надежным, чем кластер, который оно защищает, и станет потенциальной единственной точкой отказа. Также возникает дополнительная сквозная задержка.
4️⃣Вместо этого можно отправлять сообщения об истечении тайм-аута в локальное хранилище и их загрузка в Kafka с помощью дополнительного побочного процесса. Этот вариант использует локальное хранилище в качестве канала недоставленных сообщений. Пакетный процесс импортирует эти сообщения в Kafka, как только система вернется в нормальное состояние.
Плюсами этого варианта является низкая сложность реализации, а также приложение может продолжать принимать входящий трафик намного дольше. Нет потерь сообщений, хотя их порядок теряется.
Недостатком этой стратегии становится сложность записи в локальное хранилище и необходимость ручного вмешательства для каждого экземпляра приложения, чтобы восстановить все сообщения.
5️⃣Вместо этого можно внедрить автоматический выключатель для временной отправки сообщений в локальное хранилище. Но это довольно сложно с точки зрения реализации: система отключает поток данных в Kafka в случае сбоя этой платформы и перенаправляет сообщения в локальное хранилище. Приложение воспроизводит эти сообщения из локального хранилища и повторно отправляет их после восстановления Kafka. Затем возобновляется регулярный поток.
Сложность в том, что несколько сообщений будут находиться в очередях продюсера. Проблемы с синхронизацией могут возникнуть при размыкании и замыкании автоматического выключателя. Чтобы понять, когда следует размыкать автоматический выключатель, надо знать состояние кластера на основе клиента Kafka через JMX в Java или статистику библиотеки librdkafka. Вместо этого следует отслеживать частоту ошибок в данных, например, отчеты об доставке с ошибками.
Последний 6️⃣ разберем на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-prevent-kafka-failures.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Как повысить надежность кластера Apache Kafka: сбои публикации и стратегии их устранения
Какие меры принять администратору кластера Apache Kafka, чтобы повысить надежность потоково
#kafka @BigDataSchool_ru
Тест по основам Kafka.
Где устанавливаются плагины-коннекторы?
Тест по основам Kafka.
Где устанавливаются плагины-коннекторы?
Anonymous Quiz
21%
в ZooKeper’е
10%
на каждом процессе-исполнителе
24%
на центральном узле в кластере
45%
на каждом рабочем узле
#kafka #статьи
Один или несколько кластеров Apache Kafka?
Сегодня рассмотрим, когда и зачем нужно разворачивать новый кластер вместо масштабирования существующего. Хотя платформа отлично поддерживает горизонтальное масштабирование, безопасный физический предел одного кластера составляет около 200 000 разделов всего или 4000 разделов на один брокер.
Разумеется, эти показатели могут быть выше при использовании высокопроизводительного оборудования, в т.ч. пропускная способность сети, выделенное хранилище, процессор и память.
В любом случае, запускать слишком много приложений-продюсеров и потребителей в одном кластере Kafka может привести к нарушению SLA по задержке обработки данных из-за большой вариативности сценариев использования.
Поэтому вескими причинами для использования нескольких кластеров Kafka будут следующие:
✔️строгие правила изоляции данных, которые нельзя смешивать, например, персональных данные клиентов или сотрудников, данные платежных карт и пр. требуют очень высоких гарантий безопасности;
✔️распределение по разным географическим регионам. Чтобы сократить время обработки данных проще иметь отдельный кластер Kafka в каждом регионе, где работают приложения.
✔️Разные требования к доступности данных. RPO, RTO и SLA могут сильно отличаться для различных конвейеров потоковой обработки. Поэтому разные кластера Apache Kafka проще настроить по-разному для различных бизнес-подразделения и приложений независимо друг от друга, с теми настройками, которые подходят лучше всего для конкретного случая.
При развертывании нескольких изолированных кластеров, которые не могут обмениваться данными, возрастает количество хранилищ, которые нужно администрировать и сопровождать. С другой стороны, преимуществом одного кластера Kafka будет более быстрая обработка данных и простота централизованного управления.
Таким образом, администратору кластера Kafka надо найти баланс между количеством кластеров, развернутых в локальной инфраструктуре компании или в облаке.
Сократить расходы на обслуживание нескольких больших кластеров, которые используются многими корпоративными приложениями, поможет сервисный подход (KaaS, Kafka as a Service).
Чтобы внедрить его, прежде всего, следует определить общие компоненты любого кластера Kafka: брокеры, Apache ZooKeeper и реестр схем (Schema Registry). А такие компоненты, как ACL-списки управления доступом, пользователи, сертификаты TLS, хранилище и схемы данных могут различаться от кластера к кластеру, но вполне могут управляться одной командой администраторов.
Как организовать процессы управления кластерами и общими службами? - читайте далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/when-you-need-new-cluster-kafka-and-how-manage-it.html
Один или несколько кластеров Apache Kafka?
Сегодня рассмотрим, когда и зачем нужно разворачивать новый кластер вместо масштабирования существующего. Хотя платформа отлично поддерживает горизонтальное масштабирование, безопасный физический предел одного кластера составляет около 200 000 разделов всего или 4000 разделов на один брокер.
Разумеется, эти показатели могут быть выше при использовании высокопроизводительного оборудования, в т.ч. пропускная способность сети, выделенное хранилище, процессор и память.
В любом случае, запускать слишком много приложений-продюсеров и потребителей в одном кластере Kafka может привести к нарушению SLA по задержке обработки данных из-за большой вариативности сценариев использования.
Поэтому вескими причинами для использования нескольких кластеров Kafka будут следующие:
✔️строгие правила изоляции данных, которые нельзя смешивать, например, персональных данные клиентов или сотрудников, данные платежных карт и пр. требуют очень высоких гарантий безопасности;
✔️распределение по разным географическим регионам. Чтобы сократить время обработки данных проще иметь отдельный кластер Kafka в каждом регионе, где работают приложения.
✔️Разные требования к доступности данных. RPO, RTO и SLA могут сильно отличаться для различных конвейеров потоковой обработки. Поэтому разные кластера Apache Kafka проще настроить по-разному для различных бизнес-подразделения и приложений независимо друг от друга, с теми настройками, которые подходят лучше всего для конкретного случая.
При развертывании нескольких изолированных кластеров, которые не могут обмениваться данными, возрастает количество хранилищ, которые нужно администрировать и сопровождать. С другой стороны, преимуществом одного кластера Kafka будет более быстрая обработка данных и простота централизованного управления.
Таким образом, администратору кластера Kafka надо найти баланс между количеством кластеров, развернутых в локальной инфраструктуре компании или в облаке.
Сократить расходы на обслуживание нескольких больших кластеров, которые используются многими корпоративными приложениями, поможет сервисный подход (KaaS, Kafka as a Service).
Чтобы внедрить его, прежде всего, следует определить общие компоненты любого кластера Kafka: брокеры, Apache ZooKeeper и реестр схем (Schema Registry). А такие компоненты, как ACL-списки управления доступом, пользователи, сертификаты TLS, хранилище и схемы данных могут различаться от кластера к кластеру, но вполне могут управляться одной командой администраторов.
Как организовать процессы управления кластерами и общими службами? - читайте далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/when-you-need-new-cluster-kafka-and-how-manage-it.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Когда развернуть еще один кластер Apache Kafka и как им управлять?
Что лучше: один или несколько кластеров Apache Kafka, когда и зачем разворачивать новый класт
#kafka #статьи
Как организовать процессы управления кластерами и общими службами?
Если не все управление корпоративными кластерами централизовано и локальные администраторы (DevOps-инженеры), эксплуатирующие Kafka, могут задавать собственные настройки, надо ограничить их пороговыми значениями.
Например, задать допустимый лимит количества топиков, которые можно создавать в день, срок и объем хранения данных в них, а также установить максимальную пропускную способность. Обеспечить соблюдение квот потребления пропускной способности для каждой команды можно с помощью механизма квотирования. Это позволит равномерно утилизировать ресурсы кластера, чтобы каждая команда разработчиков приложений не могла потреблять больше, чем ей выделено.
Аналогичным образом следует решить вопрос с автоматическим масштабированием, чтобы с помощью внешних (по отношению к Kafka) инструментов системного администрирования иметь возможность выделять или освобождать вычислительные ресурсы, (память, ЦП и дисковое пространство) пропорционально трафику сообщений и без прямого вмешательства человека. Поскольку Kafka отлично поддерживает горизонтальное масштабирование, можно добавить больше узлов-брокеров в существующие кластеры или сократить их количество при снижении нагрузки. Особенно удобно делать это при развертывании Kafka в виде контейнера на платформе Kubernetes.
Можно повысить пропускную способность кластера, добавив больше разделов в топик, чтобы потреблять данные несколькими параллельными потребителями, если общий хронологический порядок сообщений не важен. Поскольку Kafka гарантирует упорядоченность сообщений только в рамках раздела, изменение количества разделов в уже существующем топике приведет к потере хронологии событий. Также придется заранее определить количество разделов для топика с учетом количества экземпляров приложений-потребителей, т.к. число разделов в топиках Kafka не меняется автоматически по числу развернутых приложений-потребителей.
Впрочем, можно определить количество разделов топика Kafka по следующему набору эмпирических правил:
✔️в общем случае количество разделов должно быть больше или равно количества экземпляров приложений-потребителей;
✔️в периоды низкой нагрузки количество разделов должно превышать количество экземпляров потребителей;
✔️в периоды пиковой нагрузки количество разделов должно быть равно количество экземпляров потребителей;
✔️количество разделов обычно растет с увеличением бизнеса.
В качестве инструментов самообслуживания для настройки кластера Kafka в соответствии с требованиями конкретной команды, централизованная служба сопровождения обычно предоставляет локальным Devops-инженерам соответствующие интерфейсы: API, CLI или GUI, интегрированные со средствами CI/CD.
Таким образом, локальные Devops-инженеры могут управлять операциями в своих кластерах Kafka, настраивать и администрировать их, а также запрашивать ресурсы у глобальной команды сопровождения KaaS-решения.
Кроме этого, в зоне ответственности локального DevOps-инженера остается управление схемами данных, которые описываю структуру сообщений интеграционного обмена между приложениями-продюсерами и потребителями. Если топик и схемы данных используются одной командой, они могут оставаться полностью приватными, когда все права доступа имеет лишь команда-владелец данных.
Но в случае распределенного между разными командами использования данных в кластере Kafka следует тщательно продумать процесс управления ими. Для этого можно использовать подход федеративного управления вычислениями в сетке данных (Data Mesh), поддоменами которой являются кластеры Kafka, управляемые локальными командами.
В заключение отметим важность эффективного управления кластером с точки зрения экономики.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/when-you-need-new-cluster-kafka-and-how-manage-it.html
Как организовать процессы управления кластерами и общими службами?
Если не все управление корпоративными кластерами централизовано и локальные администраторы (DevOps-инженеры), эксплуатирующие Kafka, могут задавать собственные настройки, надо ограничить их пороговыми значениями.
Например, задать допустимый лимит количества топиков, которые можно создавать в день, срок и объем хранения данных в них, а также установить максимальную пропускную способность. Обеспечить соблюдение квот потребления пропускной способности для каждой команды можно с помощью механизма квотирования. Это позволит равномерно утилизировать ресурсы кластера, чтобы каждая команда разработчиков приложений не могла потреблять больше, чем ей выделено.
Аналогичным образом следует решить вопрос с автоматическим масштабированием, чтобы с помощью внешних (по отношению к Kafka) инструментов системного администрирования иметь возможность выделять или освобождать вычислительные ресурсы, (память, ЦП и дисковое пространство) пропорционально трафику сообщений и без прямого вмешательства человека. Поскольку Kafka отлично поддерживает горизонтальное масштабирование, можно добавить больше узлов-брокеров в существующие кластеры или сократить их количество при снижении нагрузки. Особенно удобно делать это при развертывании Kafka в виде контейнера на платформе Kubernetes.
Можно повысить пропускную способность кластера, добавив больше разделов в топик, чтобы потреблять данные несколькими параллельными потребителями, если общий хронологический порядок сообщений не важен. Поскольку Kafka гарантирует упорядоченность сообщений только в рамках раздела, изменение количества разделов в уже существующем топике приведет к потере хронологии событий. Также придется заранее определить количество разделов для топика с учетом количества экземпляров приложений-потребителей, т.к. число разделов в топиках Kafka не меняется автоматически по числу развернутых приложений-потребителей.
Впрочем, можно определить количество разделов топика Kafka по следующему набору эмпирических правил:
✔️в общем случае количество разделов должно быть больше или равно количества экземпляров приложений-потребителей;
✔️в периоды низкой нагрузки количество разделов должно превышать количество экземпляров потребителей;
✔️в периоды пиковой нагрузки количество разделов должно быть равно количество экземпляров потребителей;
✔️количество разделов обычно растет с увеличением бизнеса.
В качестве инструментов самообслуживания для настройки кластера Kafka в соответствии с требованиями конкретной команды, централизованная служба сопровождения обычно предоставляет локальным Devops-инженерам соответствующие интерфейсы: API, CLI или GUI, интегрированные со средствами CI/CD.
Таким образом, локальные Devops-инженеры могут управлять операциями в своих кластерах Kafka, настраивать и администрировать их, а также запрашивать ресурсы у глобальной команды сопровождения KaaS-решения.
Кроме этого, в зоне ответственности локального DevOps-инженера остается управление схемами данных, которые описываю структуру сообщений интеграционного обмена между приложениями-продюсерами и потребителями. Если топик и схемы данных используются одной командой, они могут оставаться полностью приватными, когда все права доступа имеет лишь команда-владелец данных.
Но в случае распределенного между разными командами использования данных в кластере Kafka следует тщательно продумать процесс управления ими. Для этого можно использовать подход федеративного управления вычислениями в сетке данных (Data Mesh), поддоменами которой являются кластеры Kafka, управляемые локальными командами.
В заключение отметим важность эффективного управления кластером с точки зрения экономики.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/when-you-need-new-cluster-kafka-and-how-manage-it.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Когда развернуть еще один кластер Apache Kafka и как им управлять?
Что лучше: один или несколько кластеров Apache Kafka, когда и зачем разворачивать новый класт
#kafka #статьи
Что учитывать при разделении топика Apache Kafka
При решении вопроса о том, стоит ли делить топик на разделы, надо учитывать следующие факторы:
✔️количество потребителей и вариативность их поведения, включая надежность и скорость обработки сообщений;
✔️разницу в пропускной способности публикации и потребления сообщений, чтобы увеличить скорость потребления в случае высокопроизводительного продюсера, масштабировав количество потребителей, т.е. увеличив число разделов;
✔️семантику партиционирования на основе какого-либо бизнес-признака, а не только с целью балансировки нагрузки;
✔️толерантность к упорядоченности сообщений, которая гарантируется только в рамках раздела, а не является сквозной по всему топику;
✔️ресурсные возможности узла, на котором развернут экземпляр Kafka, т.е. объем свободного места на диске для сохранения сообщений и памяти для буферизации.
Разумеется, этот список не является исчерпывающим, и может быть расширен другими соображениями при проектировании отдельно взятого потокового конвейера.
Однако, он содержит ключевые моменты, которые следует учесть при определении EDA-архитектуры данных на основе Apache Kafka.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/key-factors-to-define-quantity-of-partitions-in-kafka-topic.html
Что учитывать при разделении топика Apache Kafka
При решении вопроса о том, стоит ли делить топик на разделы, надо учитывать следующие факторы:
✔️количество потребителей и вариативность их поведения, включая надежность и скорость обработки сообщений;
✔️разницу в пропускной способности публикации и потребления сообщений, чтобы увеличить скорость потребления в случае высокопроизводительного продюсера, масштабировав количество потребителей, т.е. увеличив число разделов;
✔️семантику партиционирования на основе какого-либо бизнес-признака, а не только с целью балансировки нагрузки;
✔️толерантность к упорядоченности сообщений, которая гарантируется только в рамках раздела, а не является сквозной по всему топику;
✔️ресурсные возможности узла, на котором развернут экземпляр Kafka, т.е. объем свободного места на диске для сохранения сообщений и памяти для буферизации.
Разумеется, этот список не является исчерпывающим, и может быть расширен другими соображениями при проектировании отдельно взятого потокового конвейера.
Однако, он содержит ключевые моменты, которые следует учесть при определении EDA-архитектуры данных на основе Apache Kafka.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/key-factors-to-define-quantity-of-partitions-in-kafka-topic.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Разделять ли топик Apache Kafka: 5 главных соображений
Почему раздел называется единицей параллелизма и как определить оптимальное число раз
#kafka #статьи
Изменения в брокерах, продюсера, контроллерах и Admin Client
27 февраля выпущена версия Apache Kafka 3.7, которая содержит 6 новых фич, более 45 улучшений и почти 80 исправленных ошибок. Одним из достаточно значимых изменений стала обработка сбоя диска брокера JBOD в KRaft, чтобы полностью отказаться от Zookeeper. В релизе 3.7 добавлена поддержка JBOD (Just a Bunch Of Disks) в кластерах на базе KRaft, позволяющая вести несколько каталогов журналов для каждого брокера. JBOD стал важной функцией Kafka, позволяющей запускать крупные развертывания с несколькими устройствами хранения на каждого брокера. Чтобы обеспечить доступность кластера, в случае сбоя лидера раздела контроллер должен выбрать нового лидера из одной из других синхронизированных реплик.
Ранее контроллер не проверял корректность работы лидера, предполагая, что каждый брокер работает корректно, если он еще является активным членом кластера. Однако, поскольку в KRaft членство в кластере основано на своевременных запросах подтверждения, отправляемых каждым брокером активному контроллеру, а не на эфемерном zNode в /brokers/ids, как в в ZooKeeper, при сбое одного каталога журналов брокер не сможет быть ни ведущим, ни ведомым для каких-либо разделов в этом каталоге журналов. Тогда контроллер не знает, что ему необходимо обновить лидерство и ISR для реплик в этом каталоге журналов, поскольку брокер будет продолжать отправлять контрольные запросы. Поэтому поддержка JBOD в KRaft позволяет избежать необходимости делать RPC-вызовы для перечисления всех разделов в каталоге журналов. Хотя эта функция пока не рекомендуется для производственного использования, в будущем с ее помощью можно ускорить отказ от ZooKeeper.
Еще одной интересной функцией раннего доступа можно назвать новый упрощенный протокол перебалансировки потребителей, который переносит сложность с потребителя на координатора группы внутри брокера и полностью обновляет протокол, делая его инкрементным по своей природе. Он обеспечивает те же гарантии, что и текущий протокол, но лучше и эффективнее, в том числе больше не полагаясь на барьер глобальной синхронизации. Также сокращено время, необходимое клиенту для обнаружения нового лидера раздела, что сокращает сквозную задержку запросов на создание/выборку при смене лидера, включая перезапуск брокера, переназначение раздела и пр. Здесь же можно отметить про экспоненциальную отсрочку для клиентов Kafka, которая изменяет время задержки повторной попытки повтора неудачных запросов. Это позволит уменьшить медленную конвергенцию метаданных после сбоя брокера из-за перегрузки.
В новом релизе AdminClient может напрямую общаться с кворумом контроллера KRaft и добавить регистрацию контроллера для динамического изменения уровней log4j на контроллере KRaft. Это помогает при отладке сценариев, когда другие части системы не работают.
В релизе 3.7 добавлена защита транзакций на стороне сервера, предотвращающая их зависание для смещения потребителей в разделах топика. А, чтобы лучше отслеживать производительность, устранять и предотвращать проблемы с многоуровневым хранилищем Kafka, поддерживаются дополнительные метрики этой функции. Все версии клиентских запросов старше Apache Kafka 2.1 теперь помечены как устаревшие и вводит новые метрики для мониторинга наличия таких запросов.
Поддержка этих запросов будет прекращена в выпуске 4.0.
Далее читайте: Другие разрешения и Новинки Kafka Streams и Connect.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/kafka-3-7-release-overview.html
Изменения в брокерах, продюсера, контроллерах и Admin Client
27 февраля выпущена версия Apache Kafka 3.7, которая содержит 6 новых фич, более 45 улучшений и почти 80 исправленных ошибок. Одним из достаточно значимых изменений стала обработка сбоя диска брокера JBOD в KRaft, чтобы полностью отказаться от Zookeeper. В релизе 3.7 добавлена поддержка JBOD (Just a Bunch Of Disks) в кластерах на базе KRaft, позволяющая вести несколько каталогов журналов для каждого брокера. JBOD стал важной функцией Kafka, позволяющей запускать крупные развертывания с несколькими устройствами хранения на каждого брокера. Чтобы обеспечить доступность кластера, в случае сбоя лидера раздела контроллер должен выбрать нового лидера из одной из других синхронизированных реплик.
Ранее контроллер не проверял корректность работы лидера, предполагая, что каждый брокер работает корректно, если он еще является активным членом кластера. Однако, поскольку в KRaft членство в кластере основано на своевременных запросах подтверждения, отправляемых каждым брокером активному контроллеру, а не на эфемерном zNode в /brokers/ids, как в в ZooKeeper, при сбое одного каталога журналов брокер не сможет быть ни ведущим, ни ведомым для каких-либо разделов в этом каталоге журналов. Тогда контроллер не знает, что ему необходимо обновить лидерство и ISR для реплик в этом каталоге журналов, поскольку брокер будет продолжать отправлять контрольные запросы. Поэтому поддержка JBOD в KRaft позволяет избежать необходимости делать RPC-вызовы для перечисления всех разделов в каталоге журналов. Хотя эта функция пока не рекомендуется для производственного использования, в будущем с ее помощью можно ускорить отказ от ZooKeeper.
Еще одной интересной функцией раннего доступа можно назвать новый упрощенный протокол перебалансировки потребителей, который переносит сложность с потребителя на координатора группы внутри брокера и полностью обновляет протокол, делая его инкрементным по своей природе. Он обеспечивает те же гарантии, что и текущий протокол, но лучше и эффективнее, в том числе больше не полагаясь на барьер глобальной синхронизации. Также сокращено время, необходимое клиенту для обнаружения нового лидера раздела, что сокращает сквозную задержку запросов на создание/выборку при смене лидера, включая перезапуск брокера, переназначение раздела и пр. Здесь же можно отметить про экспоненциальную отсрочку для клиентов Kafka, которая изменяет время задержки повторной попытки повтора неудачных запросов. Это позволит уменьшить медленную конвергенцию метаданных после сбоя брокера из-за перегрузки.
В новом релизе AdminClient может напрямую общаться с кворумом контроллера KRaft и добавить регистрацию контроллера для динамического изменения уровней log4j на контроллере KRaft. Это помогает при отладке сценариев, когда другие части системы не работают.
В релизе 3.7 добавлена защита транзакций на стороне сервера, предотвращающая их зависание для смещения потребителей в разделах топика. А, чтобы лучше отслеживать производительность, устранять и предотвращать проблемы с многоуровневым хранилищем Kafka, поддерживаются дополнительные метрики этой функции. Все версии клиентских запросов старше Apache Kafka 2.1 теперь помечены как устаревшие и вводит новые метрики для мониторинга наличия таких запросов.
Поддержка этих запросов будет прекращена в выпуске 4.0.
Далее читайте: Другие разрешения и Новинки Kafka Streams и Connect.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/kafka-3-7-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Новинки Apache Kafka 3.7: обзор свежего релиза
В конце февраля вышел очередной релиз Apache Kafka за номером 3.7. Поддержка JBOD в KRaft-кластерах,
#kafka #статьи
Новинки Kafka Streams и Connect
Для повышения надежности в Kafka Streams добавлена вторая стратегия назначения задач с учетом стойки. Теперь информация о том, на какой стойке кластера развернуты клиенты, есть в интерфейсе назначения разделов, чтобы учитывать это при их назначении на разделы топика Kafka. Это позволит сократить трафик между стойками и ускорить обработку данных. При этом протокол перебалансировки клиентов остается прежним, изменена только логика назначения: путь чтения в лидере группы на клиентах.
Для этого добавлен новый интерфейс для обработки случаев, когда резервные задачи имеют зарегистрированные хранилища состояний, загрузку пакета записей и остановку обновлений. Также конфигурации хранилища DSL по умолчанию расширена до пользовательских типов, чтобы разработчик мог подключать любые хранилища состояний, используя новый интерфейс, поддерживающий в т.ч. RocksDB и резидентные хранилища. Еще введено версионирование хранилищ состояний, обращаться к которым можно с помощью запросов VersionedKeyQuery и MultiVersionedKeyQuery. Они позволяют выполнять поиск одного ключа, запрашивать самое последнее значение, историческое значение или диапазон исторических значений для предоставленного ключа. Упрощены требования к ненулевому ключу в Kafka Streams, которые ранее не допускались.
Также добавлены новые интерактивные запросы TimestampedKeyQuery и TimestampedRangeQuery с меткой времени для хранилищ состояний «ключ-значение» с меткой времени. Это изменение повышает безопасность типов API, возвращая значение, только если оно выдано в хранилище значений ключа с меткой времени. Запросы типа RangeQueries позволяют запрашивать диапазон ключей, результаты выполнения которых теперь можно упорядочить для каждого раздела в порядке возрастания или убывания или оставить порядок неуказанным.
Также стоит отметить изменения в Kafka Connect, среди которых динамическая настройка лога для всего кластера и отдельных рабочих процессов. Новые коннекторы теперь можно создавать в состоянии «ОСТАНОВЛЕНО» или «ПАУЗА», что облегчает их миграцию. В частности, при создании коннектора у него можно заполнить новое необязательное поле с начальным состоянием.
Еще в Kafka Connect добавлен конвертер BooleanConverter, поддерживающий сериализацию и десериализацию логического примитива в схеме благодаря изменениям в org.apache.kafka.connect.storage.Converter и org.apache.kafka.connect.storage.HeaderConverter. Наконец, устарела избыточная конечная точка для получения конфигураций задач Connect, которая будет удалена в выпуске 4.0.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/kafka-3-7-release-overview.html
Новинки Kafka Streams и Connect
Для повышения надежности в Kafka Streams добавлена вторая стратегия назначения задач с учетом стойки. Теперь информация о том, на какой стойке кластера развернуты клиенты, есть в интерфейсе назначения разделов, чтобы учитывать это при их назначении на разделы топика Kafka. Это позволит сократить трафик между стойками и ускорить обработку данных. При этом протокол перебалансировки клиентов остается прежним, изменена только логика назначения: путь чтения в лидере группы на клиентах.
Для этого добавлен новый интерфейс для обработки случаев, когда резервные задачи имеют зарегистрированные хранилища состояний, загрузку пакета записей и остановку обновлений. Также конфигурации хранилища DSL по умолчанию расширена до пользовательских типов, чтобы разработчик мог подключать любые хранилища состояний, используя новый интерфейс, поддерживающий в т.ч. RocksDB и резидентные хранилища. Еще введено версионирование хранилищ состояний, обращаться к которым можно с помощью запросов VersionedKeyQuery и MultiVersionedKeyQuery. Они позволяют выполнять поиск одного ключа, запрашивать самое последнее значение, историческое значение или диапазон исторических значений для предоставленного ключа. Упрощены требования к ненулевому ключу в Kafka Streams, которые ранее не допускались.
Также добавлены новые интерактивные запросы TimestampedKeyQuery и TimestampedRangeQuery с меткой времени для хранилищ состояний «ключ-значение» с меткой времени. Это изменение повышает безопасность типов API, возвращая значение, только если оно выдано в хранилище значений ключа с меткой времени. Запросы типа RangeQueries позволяют запрашивать диапазон ключей, результаты выполнения которых теперь можно упорядочить для каждого раздела в порядке возрастания или убывания или оставить порядок неуказанным.
Также стоит отметить изменения в Kafka Connect, среди которых динамическая настройка лога для всего кластера и отдельных рабочих процессов. Новые коннекторы теперь можно создавать в состоянии «ОСТАНОВЛЕНО» или «ПАУЗА», что облегчает их миграцию. В частности, при создании коннектора у него можно заполнить новое необязательное поле с начальным состоянием.
Еще в Kafka Connect добавлен конвертер BooleanConverter, поддерживающий сериализацию и десериализацию логического примитива в схеме благодаря изменениям в org.apache.kafka.connect.storage.Converter и org.apache.kafka.connect.storage.HeaderConverter. Наконец, устарела избыточная конечная точка для получения конфигураций задач Connect, которая будет удалена в выпуске 4.0.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/kafka/kafka-3-7-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Новинки Apache Kafka 3.7: обзор свежего релиза
В конце февраля вышел очередной релиз Apache Kafka за номером 3.7. Поддержка JBOD в KRaft-кластерах,
#Kafka #Decodable #SQL
Пример потокового конвейера из Kafka в Elasticsearch на платформе Decodable
Практическая демонстрация потокового SQL-конвейера, который преобразует данные, потребленные из Apache Kafka, и записывает результаты в Elasticsearch, используя Debezium-коннекторы и задания Apache Flink в облачной платформе Decodable.
Полная статья: https://bigdataschool.ru/blog/news/kafka/from-kafka-to-elasticsearch-with-sql-pipeline-on-decodable.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-basics https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Пример потокового конвейера из Kafka в Elasticsearch на платформе Decodable
Практическая демонстрация потокового SQL-конвейера, который преобразует данные, потребленные из Apache Kafka, и записывает результаты в Elasticsearch, используя Debezium-коннекторы и задания Apache Flink в облачной платформе Decodable.
Полная статья: https://bigdataschool.ru/blog/news/kafka/from-kafka-to-elasticsearch-with-sql-pipeline-on-decodable.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-basics https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Kafka #транзакции #API
Изоляция транзакций в Apache Kafka при потреблении сообщений
Как Apache Kafka реализует требование к изоляции потребления сообщений, опубликованных транзакционно, и где это настроить в клиентских API, зачем отслеживать LSO, для чего прерывать транзакцию, и какими методами это обеспечивается в библиотеке confluent_kafka.
Транзакционое потребление: изоляция чтения сообщений в Apache Kafka
Полная статья: https://bigdataschool.ru/blog/news/kafka/kafka-transaction-consume-isolation-level.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Изоляция транзакций в Apache Kafka при потреблении сообщений
Как Apache Kafka реализует требование к изоляции потребления сообщений, опубликованных транзакционно, и где это настроить в клиентских API, зачем отслеживать LSO, для чего прерывать транзакцию, и какими методами это обеспечивается в библиотеке confluent_kafka.
Транзакционое потребление: изоляция чтения сообщений в Apache Kafka
Полная статья: https://bigdataschool.ru/blog/news/kafka/kafka-transaction-consume-isolation-level.html
Курсы: https://bigdataschool.ru/courses/apache-kafka-developers https://bigdataschool.ru/courses/apache-kafka-administrator-course https://bigdataschool.ru/courses/arenadata-streaming-kafka-cluster-administrator
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#ApacheNiFi #200M4 #Kafka
Apache NiFi 2.0.0-M4: июльские новинки мажорного релиза
1 июля 2024 г. опубликован очередной выпуск Apache NiFi 2.0.0. Знакомимся с его наиболее интересными добавлениями и улучшениями: критические изменения, обновленная интеграция с Kafka и новые процессоры для работы с файлами разных форматов.
Обновленная интеграция с Kafka и другие новинки Apache NiFi 2.0.0-M4
Выпуск мажорного релиза не всегда происходит одним этапом. Например, разработчики Apache NiFi публикуют обновления пошагово. В начале июля вышла четвертое дополнение релиза 2.0.0, которое включает довольно много изменений, в том числе критических.
Статья
Курс: NIFI3
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Apache NiFi 2.0.0-M4: июльские новинки мажорного релиза
1 июля 2024 г. опубликован очередной выпуск Apache NiFi 2.0.0. Знакомимся с его наиболее интересными добавлениями и улучшениями: критические изменения, обновленная интеграция с Kafka и новые процессоры для работы с файлами разных форматов.
Обновленная интеграция с Kafka и другие новинки Apache NiFi 2.0.0-M4
Выпуск мажорного релиза не всегда происходит одним этапом. Например, разработчики Apache NiFi публикуют обновления пошагово. В начале июля вышла четвертое дополнение релиза 2.0.0, которое включает довольно много изменений, в том числе критических.
Статья
Курс: NIFI3
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Python #Kafka #confluentkafka
Что выбрать Python-разработчику для работы с Kafka: confluent-kafka vs kafka-python
Почему производительность confluent-kafka выше, чем у kafka-python, чем еще отличаются эти Python-библиотеки для разработки клиентов Apache Kafka, и что выбирать.
Сравнение Python-библиотек для разработки клиентов Kafka
Хотя Java считается более подходящей для создания высоконагруженных приложений, многие разработчики используют Python, который намного проще. Этот язык программирования подходит даже для написания продюсеров и потребителей Apache Kafka. Но в этом случае перед разработчиком встает выбор: какую библиотеку использовать. Например, раньше я обычно пользовалась библиотекой kafka-python. Однако, у нее есть альтернатива — confluent-kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Что выбрать Python-разработчику для работы с Kafka: confluent-kafka vs kafka-python
Почему производительность confluent-kafka выше, чем у kafka-python, чем еще отличаются эти Python-библиотеки для разработки клиентов Apache Kafka, и что выбирать.
Сравнение Python-библиотек для разработки клиентов Kafka
Хотя Java считается более подходящей для создания высоконагруженных приложений, многие разработчики используют Python, который намного проще. Этот язык программирования подходит даже для написания продюсеров и потребителей Apache Kafka. Но в этом случае перед разработчиком встает выбор: какую библиотеку использовать. Например, раньше я обычно пользовалась библиотекой kafka-python. Однако, у нее есть альтернатива — confluent-kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Потоковыесоединения #Kafka #Python #JSONсхема
Потоковые соединения из Kafka на Python: практический пример
Сегодня я покажу простую демонстрацию потоковой агрегации данных из разных топиков Apache Kafka на примере Python-приложений для соединения событий пользовательского поведения с информацией о самом пользователе.
Постановка задачи
Рассмотрим примере кликстрима, т.е. потокового поступления данных о событиях пользовательского поведения на страницах сайта. Предположим, данные о самом пользователе: его идентификаторе, электронном адресе и имени попадают в топик под названием CorpAppsTopic. JSON-схема полезной нагрузки выглядит так:
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковые соединения из Kafka на Python: практический пример
Сегодня я покажу простую демонстрацию потоковой агрегации данных из разных топиков Apache Kafka на примере Python-приложений для соединения событий пользовательского поведения с информацией о самом пользователе.
Постановка задачи
Рассмотрим примере кликстрима, т.е. потокового поступления данных о событиях пользовательского поведения на страницах сайта. Предположим, данные о самом пользователе: его идентификаторе, электронном адресе и имени попадают в топик под названием CorpAppsTopic. JSON-схема полезной нагрузки выглядит так:
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#Kafka #SQL #RisingWave
Потоковая агрегация данных из Kafka на SQL в RisingWave: пример
Как соединить данные из разных топиков Apache Kafka с помощью пары SQL-запросов: коннекторы, материализованные представления и потоковая база данных вместо полноценного потребителя. Подробная демонстрация запросов в RisingWave.
Проектирование и реализация потоковой агрегации данных из Kafka в RisingWave
Вчера я показывала пример потоковой агрегации данных из разных топиков Kafka с помощью Python-приложения, которое потребляет данные о пользователях и событиях их поведения на сайтах из разных топиков Kafka и соединяет их по ключевому идентификатору. Сегодня рассмотрим, как решить эту задачу быстрее с помощью потоковой базы данных RisingWave и коннекторов к Kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковая агрегация данных из Kafka на SQL в RisingWave: пример
Как соединить данные из разных топиков Apache Kafka с помощью пары SQL-запросов: коннекторы, материализованные представления и потоковая база данных вместо полноценного потребителя. Подробная демонстрация запросов в RisingWave.
Проектирование и реализация потоковой агрегации данных из Kafka в RisingWave
Вчера я показывала пример потоковой агрегации данных из разных топиков Kafka с помощью Python-приложения, которое потребляет данные о пользователях и событиях их поведения на сайтах из разных топиков Kafka и соединяет их по ключевому идентификатору. Сегодня рассмотрим, как решить эту задачу быстрее с помощью потоковой базы данных RisingWave и коннекторов к Kafka.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#SQL #Kafka #Redis #RisingWave
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis: демонстрация ETL-конвейера на материализованных представлениях в RisingWave.
Постановка задачи и проектирование потоковой системы
Продолжая недавний пример потоковой агрегации данных из разных топиков Kafka с помощью SQL-запросов, сегодня расширим потоковый конвейер в RisingWave, добавив приемник данных – key-value хранилище Redis. RisingWave – это распределенная реляционная СУБД, которая позволяет работать с потоками данных как с обычными таблицами через типовые SQL-запросы.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis: демонстрация ETL-конвейера на материализованных представлениях в RisingWave.
Постановка задачи и проектирование потоковой системы
Продолжая недавний пример потоковой агрегации данных из разных топиков Kafka с помощью SQL-запросов, сегодня расширим потоковый конвейер в RisingWave, добавив приемник данных – key-value хранилище Redis. RisingWave – это распределенная реляционная СУБД, которая позволяет работать с потоками данных как с обычными таблицами через типовые SQL-запросы.
Статья
Курсы: DEVKI KAFKA ADS-KAFKA
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Потоковая агрегация и передача данных из Kafka в Redis через SQL-запросы в RisingWave
Как SQL-запросами соединить потоки из разных топиков Apache Kafka и отправить результаты в Redis: