Как избежать ограничений Кафки? [закрытый]

Мы пытаемся построить BI-систему, которая будет собирать очень большие объемы данных, которые должны обрабатываться другими компонентами.
Мы решили, что будет хорошей идеей иметь промежуточный слой для сбора, хранения и распространения данных.

Данные представлены большим набором сообщений журнала. Каждое сообщение журнала имеет:

  • продукт
  • тип действия
  • дата
  • полезная нагрузка сообщения

Особенности системы:

  • среднее значение: 1,5 миллион сообщений в минуту
  • пик: 15 миллионов сообщений в минуту
  • средний размер сообщения: 700 байт (приблизительно 1,3 ТБ / день)
  • у нас есть 200 продуктов
  • у нас есть 1100 типов действий
  • данные следует проглатывать каждые 5 минут
    • Потребительские приложения обычно нуждаются в продукте 1-2-3 с типами действий 1-2-3 (нам нужен быстрый доступ для 1 продукта / 1 типа действий)

Мы думали, что Кафка сделает эту работу, но мы столкнулись с несколькими проблемы.
Мы попытались создать тему для каждого типа действий и раздел для каждого продукта. Делая это, мы могли бы извлечь 1 продукт / 1 тип действия, который будет потребляться.

Изначально у нас была проблема с "слишком большим количеством открытых файлов", но после того, как мы изменили конфигурацию сервера для поддержки большего количества файлов, мы получаем ошибку нехватки памяти (12 ГБ выделено / узел)
Кроме того, у нас были проблемы со стабильностью Кафки. На большом количестве тем Кафка склонен замирать.

Наши вопросы:

    Подходит ли Кафка для нашего сценария использования? Может ли он поддерживать такое большое количество тем / разделов?
  • можем ли мы организовать данные в Kafka другим способом, чтобы избежать этих проблем, но все же иметь хорошую скорость доступа для 1 типа продукта / 1 действия?
  • Вы рекомендуете другие варианты Кафки, которые лучше подходят для этого?
1 8
apache-kafka bigdata business-intelligence

1 ответ:

Я публикую этот ответ, чтобы другие пользователи могли увидеть принятое нами решение.

Из-за ограничений Кафки (большое нет. разделов, которые приводят к тому, что ОС достигает почти максимального количества открытых файлов) и несколько слабой производительности мы решили построить пользовательский фреймворк именно для наших нужд , используя библиотеки, такие как apache commons, guava, trove и т. д., Чтобы достичь необходимой нам производительности.

Вся система (распределенная и масштабируемая) состоит из 3 основных частей:

  1. ETL (читает данные, обрабатывает их и записывает в двоичные файлы)

  2. Ядро фреймворка (используется для чтения из двоичных файлов и вычисления статистики)

  3. API (используется многими системами для получения данных для отображения)

В качестве примечания: мы пробовали другие решения, такие как HBase, Storm и т. д., Но ни одно из них не соответствует нашим потребностям.

3