Мы
большие поклонники Кассандры . Мы также используем
Storm в качестве нашего механизма распределенной обработки. Мы добились большого успеха, используя наш
Cassandra Bolt, чтобы создать успешный брак между ними. На сегодняшний день мы используем Storm для интеграции с нашими устаревшими технологиями через
JMS Spout . Теперь мы стремимся расширить его роль за пределы традиционной системной интеграции.
В новой роли Storm рабочая нагрузка на несколько порядков выше, и, хотя JMS хорошо работал в предыдущих сценариях интеграции, мы знали, что это может быть не лучшим решением с учетом ожидаемого объема работы. Нам нужно поддерживать миллионы сообщений в очередях. Это не типичное применение JMS и это точно
Причина, по которой LinkedIn открыла исходный код Кафки :
«Сначала мы рассмотрели несколько существующих решений для организации очередей на рынке. Наиболее популярные из них основаны на JMS. Хотя JMS предлагает богатый набор функций, он также добавляет значительные издержки в представлении сообщений. Кроме того, некоторые реализации JMS оптимизированы для случая, когда все сообщения могут быть кэшированы в памяти, и их производительность начинает значительно ухудшаться, когда буфер в памяти переполняется. Наконец, большинство существующих решений не имеют чистого дизайна для масштабирования ».
Чтобы подтвердить наши предположения, нам нужно было продвинуть Кафку в ногу. Это означало подключить его к нашей топологии Storm. Для тех, кто не знает Storm, представьте себе «ESB больших данных», оптимизированный для обработки потоков данных, которые разбиты на отдельные пакеты, называемые кортежами. Носики испускают кортежи. Болты их поглощают. Storm играет роль маршрутизатора сообщений между компонентами.
У нас уже был наш Болт Кассандры на месте. Все, что мне нужно было сделать, это заменить наш носик JMS на носик
Кафки . Вот как выглядела топология:
TopologyBuilder builder = new TopologyBuilder();
List hosts = new ArrayList();
hosts.add("localhost");
SpoutConfig spoutConfig = SpoutConfig.fromHostStrings(hosts, 1, "test", "/foo", "foo");
spoutConfig.zkServers = ImmutableList.of("localhost");
spoutConfig.zkPort = 2181;
spoutConfig.scheme = new StringScheme();
builder.setSpout("spout", new KafkaSpout(spoutConfig));
DefaultBatchingCassandraBolt bolt = new DefaultBatchingCassandraBolt(new MyColumnFamilyMapper(), new MyRowKeyMapper(), new MyColumnsMapper());
bolt.setAckStrategy(AckStrategy.ACK_ON_WRITE);
builder.setBolt("loader", bolt).shuffleGrouping("spout");
Эта топология просто соединяет носик Кафки с болтом Кассандры.
(ПРЕДУПРЕЖДЕНИЕ. Приведенный выше код использует изменение болта Кассандры, которое все еще находится только в моем форке. Это может не сработать для вас.
Посмотрите этот запрос на извлечение. )
Затем я поставил в очередь 10 миллионов записей JSON в Кафке. (что заняло около 5 минут локального запуска на macbookpro) Затем я применил топологию.
Теперь Кафка * быстрый *. При запуске Kafka Spout я легко воспроизвел утверждение Кафки о том, что вы можете потреблять
«сотни тысяч сообщений в секунду»., Когда я впервые запустил топологию, все пошло хорошо в течение первой минуты, но затем быстро рухнуло, поскольку носик Кафки слишком быстро испустил выброс, чтобы Болт Кассандры не успел. Несмотря на то, что Кассандра тоже быстрая, она все равно на несколько порядков медленнее, чем Кафка.
К счастью, поскольку Storm взаимодействует со своим Spout с использованием модели извлечения, он предоставляет способ отрегулировать обмен сообщениями. Я добавил следующий параметр в Config.
config.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, 5000);
Это ограничивает количество непакетированных кортежей в системе. С AckStrategy, установленным в ACK_ON_WRITE внутри Болта Кассандры, это обеспечило безопасный способ для Болта сообщать обратно Носителю, что он «готов к еще большему».
С этой топологией мы видели постоянную пропускную способность 5000 записей в секунду для Cassandra. (работает локально на моем MBP). Это будет хорошо работать при развертывании в кластере. =) У
Kafka есть и другие приятные характеристики, которые делают его хорошо подходящим для приложений с большими данными. Я подробно расскажу о них в следующем посте.
* Слава
Тейлор Гетц . Он проделал большую работу над компонентами шторма, которые сделали это возможным.