apache storm - правильно запускать jar в одном узле, но не в нескольких узлах - PullRequest
Новая
       31

apache storm - правильно запускать jar в одном узле, но не в нескольких узлах

0 голосов
/ 10 января 2019

Я новичок в Apache Storm, я написал код, который включает в себя 1 носик и 2 болта, когда я запускаю эти 3 части на одном работнике, код генерирует вывод правильно, но когда я запускаю код на трех рабочих, что 1 рабочий выполняет носик, еще один ходовой болт 1 и последний ходовой болт 2, выходные данные не будут генерироваться. конкретная ситуация: когда я вставляю болт 1 и 2 в одного рабочего, генерируется результат!

Я должен сказать, что emit работает успешно и с переменными emit проблем нет.

Подробно: я создал дерево в структуре hashmap в болте 1, и я хочу добыть это дерево в болте 2. Идентификатор объектов, которые вставляются в дерево в болте 1, похож на «MyTreeNode @ e70014d5», и когда я получил это кортеж (hashmap) в болте 2, идентификатор изменился на что-то вроде этого "MyTreeNode @ z5542r12".

в чем основная проблема?

Проблема из-за смены идентификатора объекта? если да, не могли бы вы сообщить мне, как я могу решить эту проблему?

1 Ответ

0 голосов
/ 15 января 2019

Давайте рассмотрим пример топологии.

Допустим, ваша топология выходит из носика -> bolt1, и вы излучаете экземпляры MyObject из носика.

Допустим, вы настроили топологию для запуска на 1 работнике.

Когда из носика выходит кортеж (например, MyObject @ 1234), Storm проверит, должен ли кортеж перейти к другому работнику. Если нет, он просто передает ссылку на объект на bolt1. Это то, что вы видите, когда у вас есть только один работник. Когда MyObject @ 1234 необходимо перенести с носика на болт, Storm просто вручает болту ссылку MyObject @ 1234.

Теперь допустим, что вы указали топологии использовать 2 рабочих, и Storm решает поместить носик в рабочий 1 и болт в рабочий 2. Вспомните, что каждый рабочий - это отдельный процесс JVM, поэтому передача ссылки на объект от рабочего 1 для работника 2 не будет работать.

Когда кортеж выходит из носика, Storm увидит, что он отправляется другому работнику, и сериализует его, используя сериализацию Kryo или Java, в зависимости от вашей конфигурации. Это означает, что MyObject @ 1234 будет сериализован. Шторм передает сериализованную форму работнику 2, который десериализует ее. Когда он десериализован, ему очень разумно присваивается новый адрес памяти (например, MyObject @ 6789).

Это не проблема, если вы спроектировали свои болты так, чтобы они предполагали, что они не работают в одной и той же JVM, что вам абсолютно необходимо сделать. Например, если вы хотите перенести MyObject с работника 1 на работника 2, вы можете сделать его сериализуемым или зарегистрировать его в Kryo (см., Как на https://storm.apache.org/releases/2.0.0-SNAPSHOT/Serialization.html). Вам нужно сделать это, чтобы Storm мог поместить ваш носики и болты в отдельных JVM без нарушения вашей топологии.

Когда вы тестируете свою топологию, вы должны включить https://storm.apache.org/releases/1.2.2/javadocs/org/apache/storm/Config.html#TOPOLOGY_TESTING_ALWAYS_TRY_SERIALIZE. Это заставит Storm всегда сериализовать ваши кортежи, даже если кортеж не передается между работниками. Это может помочь вам выявить проблемы с сериализацией до того, как они попадут в производство.

Кроме того, вы всегда должны предпочитать сериализацию Kryo сериализации Java. Kryo сериализация намного быстрее.

...