Соблюдение GDPR через сжатую тему Kafka

Я хотел бы задать вам несколько вопросов по apache kafka и сжатым темам. Мы хотим предоставить некоторые данные PII по сжатой теме kafka. Мы хотим удалить данные по этой теме через надгробие. В настоящее время есть несколько вопросов, по которым мы хотим проверить наши предположения:

  1. Есть ли другая компания, которая выполняет требование gdpr (право на забвение) в kafka через сжатую тему с генерацией надгробных памятников, такую ​​как KIP-354, предлагает https://cwiki.apache.org/confluence/display/KAFKA/KIP-354%3A+Add+a+Maximum+Log+Compaction+Lag?
  2. Верно ли наше предположение, что уплотнение запускается только в том случае, если запись отсутствует в файле активного сегмента. Итак, с нашей точки зрения, документацию kafka необходимо изменить, добавив это в пункт 4.8 документации kafka: max.compaction.lag.ms темы можно использовать для гарантии максимальной задержки между написанием сообщения. и время, когда сообщение становится пригодным для сжатия. Здесь следует добавить условие, что сообщение, которое мы хотим сжать, не должно находиться в файле активного сегмента. Это ошибка функции max.compaction.lag.ms или все так, как задумано? На данный момент мы не уверены.
  3. Срабатывает ли уплотнение только после вставки нового сообщения? Или есть еще асинхронный процесс, который сжимает файлы неактивных сегментов?

Спасибо за ответы ;-)


apache-kafka kafka-topic confluent-platform kafka-producer-api tombstone
person holzleube    schedule 12.08.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы в значительной степени правы.

  1. Удаление сообщения в сжатой теме Kafka более или менее похоже на удаление строки в базе данных. Это просто не происходит сразу после отправки сообщения-захоронения.
  2. Да, активный сегмент журнала не уплотняется. Если вы хотите ускорить процесс сжатия для этой конкретной темы (чтобы удовлетворить пункт 1), вы можете уменьшить максимальный размер сегмента (segment.bytes, по умолчанию 1 ГБ) и максимальный сегмент MS (segment.ms, по умолчанию 604800000 = 1 неделя) до более низких значений, например 100 МБ и 1. Вам следует изучить min.cleanable.dirty.ratio и установить более агрессивное значение, опять же в зависимости от требований (пункт 1).
  3. Сжатие происходит асинхронно, и не имеет значения, были ли отправлены какие-либо сообщения после захоронения или нет. На каждом брокере Kafka работает компонент LogCleaner, который за это отвечает.
person Martin Ivanov    schedule 30.08.2020
comment
Привет, Мартин, спасибо за ответ. У меня вопрос к твоему ответу. Вы говорите, что сжатие происходит асинхронно, но не важно, что новое сообщение написано. По нашему опыту, сжатие в очистителе журналов запускается только после того, как сообщение написано. У вас есть ссылки на исходники кафки? - person holzleube; 16.09.2020
comment
Мы нашли метод MaybeRoll: github.com/apache/kafka/blob/ - person holzleube; 16.09.2020
comment
mightRoll решает, нужно ли свернуть новый сегмент журнала. Отметьте пункт 2 в моем первоначальном ответе. - person Martin Ivanov; 17.09.2020