Комментарии 9
Этот пункт был выведен эмпирическим путем, когда мы поняли, что инсталляция Kafka больше, чем на 12 Тб на единицу кластера драматически рушит производительность.
Можно пояснить, что такое "единица кластера"?
Мы пробовали сделать это с помощью реляционных баз данных, но они себя тоже не оправдали. Еще использовали Hadoop, но он медленный, как и RabbitMQ.
А какое "железо" используется, на котором "реляционные БД" и Rabbit не способны обеспечить 15 тысяч RPS?
Маловато чтото , у нас около 70к\с как у насдака. Но мы используем ksqldb очень во многих местах, вместо самописных экстернал приложений
В Кафке есть индекс по timestamp, поэтому можно быстро спозиционировать консумента на самую первую запись с заданным временем. А для того, чтобы примерно посчитать количество данных, можно использовать разницу оффсетов(инструмент GetOffsetShell)
Стремный подход, как по мне
Если держать в кафке данные за 5 лет, то менеджить ее будет адом. Даже банальный ребаланс при увеличении количества партиций на таком объеме это жесть. А если одна нода на 10ТБ упадет физически, и надо восстановить, и при этом это все под постоянной записью, тоже, чувствую, задача не то, чтобы тривиальная.
Не понимаю, почему не пойти по бест практисам, и не перекладывать данные раз в день с кафки в архивы по 1-10ГБ каждый на s3-совместимое хранилище/в HDFS/тупо в файловую систему на машинах по 20+ механических дисков в рейде?
Про ребаланс Consumer group - проблема уже не актуально, год как при ребалансе все не встает колом
Рецепт готовки Apache Kafka: как создавался Data Lake на 80 Тb