Начало работы со Storm, включая обучение

Java Большое количество данных

предисловие

Только лысая голова может стать сильнее.

Текст был включен в мою избранную статью на GitHub, Welcome Star.:GitHub.com/Zhongf UC очень…

Студенты, которые слышали о больших данных, должны были услышать об этом.StormБар? На самом деле, система, за которую я отвечаю, теперь использует Storm.Когда я впервые взял систему, я вообще ничего не знал о Storm (сейчас я знаю только половину)

Так как я недавно разбирал систему, мне потребовалось некоторое время, чтобы начать работу со Storm, между прочим (потребовалось некоторое время, чтобы изменить его несколько дней назад, и после того, как он вышел в онлайн, было много ошибок, поэтому я решил откатить обратно.)

В этой статье рассказывается о простом использовании простого Storm, ничего сложного. После прочтения этой статьи, когда вы возьмете на себя код Storm, вы «вероятно» и «должны» понять код Storm.

Что такое шторм

Давайте сначала взглянем на официальное представление Storm:

Apache Storm is a free and open source distributed realtime computation system

Шторм - этоРаспределенная вычислительная система реального времени.

Распределенная: я написал много распределенных систем, таких как Kafka/HDFS/Elasticsearch и так далее. Теперь, когда я вижу, что слово распределено, Санвэй первой реакцией будет: «Его хранение или вычисление передано вна нескольких серверахЗакончено и, наконец, собрано для достижения окончательного эффекта».

В режиме реального времени: скорость обработки в миллисекундах или секундах.

Расчет: его можно просто понимать как обработку данных, например, очистку данных (регулирование данных и удаление полезных данных).

Что мы делаем со Штормом?

Платформа управления сообщениями, над которой я сейчас работаю, может отправлять все виды сообщений (IM/PUSH/SMS/WeChat и т. д.).Мы определенно хотим знать, как эта новость была опубликована.(Успешно ли оно было отправлено, если пользователь его не получил, почему пользователь не получил его, был ли клик по сообщению и т.д.).

Вопрос о том, успешно ли доставлено сообщение пользователю, часто волнует операции и обслуживание клиентов.

Эффект доставки сообщений, который вызывает большую озабоченность у операций

Основываясь на поставленном выше вопросе, мы использовалиШторм составил свой собственный план захоронения, чтобы помочь нам быстро подтвердить сообщениеУспешно ли он доставлен пользователюи статистикаЭффект доставки сообщения.

Звучит потрясающе. Позвольте мне объяснить предысторию. После прочтения вы обнаружите, что это совсем не сложно.

фон спроса

Хотя платформа управления сообщениями, кажется, только отправляет сообщения, в дизайне системы все же что-то есть. Мы используем "Микросервисы«думая взглянуть на эту систему, онаИзвлечение различных функциональных модулей в разные системыиз.

Среди них PUSH-ссылка самая длинная, и есть 7 серверных систем, через которые отправляется сообщение, как показано ниже:

Эти 7 систем могли «убить» это сообщение, в результате чего пользователь не получил его. Было бы слишком медленно, если бы нам приходилось проверять каждую систему одну за другой каждый раз, когда мы проверяем проблему.

Во многих случаях проблемы, о которых сообщает служба поддержки клиентов, возникают в тот же день или даже в первые несколько минут.своевременная обратная связьВ службу поддержки клиентов, чтобы помочь пользователям выяснить, почему они не получают сообщения.

Таким образом, мы выполняем две функции:

  1. Возможность опроса пользователейденьВсе выпуски новостей. (Может быстро определить, какая система заставляет пользователя не получать сообщение)
  2. запрос сообщенияв реальном времениОбщая раздача. (Возможность быстро просмотреть общее распределение сообщения, включая объем распространения, объем, отфильтрованный посередине, и объем кликов)

Если просто проверить проблему, будем собирать логи каждой системы в Kafka, а потом писать в Elasticsearch.Это совсем не проблема (сейчас делаем так же)

Когда дело доходит до статистики, у нас есть собственный набор скрытых планов.Эта функция удобна для статистики данных, а также может завершить часть исследования..

Реализация спроса

«Погребенная точка», упомянутая ранее, на самом дележурнал попаданий. По сути, это запись журнала в ключевых местах для облегчения устранения неполадок.

Например, теперь у нас есть 7 систем, каждая система может привести к тому, что сообщение не будет отправлено при выполнении сообщения (возможно, сообщение дедуплицировано, номер мобильного телефона пользователя может быть неверным, или пользователь слишком долго не входил в систему). возможны и др.). Мы в этих "ключевая позиция' отмечены журналом, который нам удобно исследовать.

Мы даем ему все эти «ключевые позиции»имя с простыми цифрами. Например: мы используем «11», чтобы обозначить, что у пользователя нет привязанного к нему номера мобильного телефона, «12», чтобы обозначить, что пользователь получил точно такое же сообщение 10 минут назад, и «13», чтобы обозначить, что пользователь заблокировал сообщение... ..

«11», «12», «13», «14», «15», «16», они называются «точка», и записывать эти точки в ключевые позиции, это называется «Похороненный"

С закопанными точками все, что нам нужно сделать, это поставить этисбор очковвверх, а затем равномерно перерабатываются в наш формат и выводятся в источник данных.

Хорошо, это три шага:

  1. Собирать журналы
  2. журнал очистки
  3. вывод в источник данных

Для сбора журналов у нас есть logAgent, который помогает нам их собирать.Kafka, журнал очистки в реальном времени, который мы используем,Storm, после очистки мы выводим в Redis (в реальном времени)/Hive (в автономном режиме).

Storm обычно находится на уровне обработки (очистки), а восходящий и нисходящий потоки Storm также очень понятны (восходящий поток — это очередь сообщений, а нисходящий поток записывается в различные источники данных, что встречается чаще всего):

Storm очищен и помещен в Redis, и мы можем легко проверить общую доставку сообщения через интерфейс, например:

Здесь я в основном хочу объяснить, что мы используем Storm дляочистка в реальном времениДейта, давайте поговорим об основном использовании Шторма~

Начало работы со Штормом

Начнем с самого простого фрагмента кода Storm, сначала посмотрим на следующий код:

Если вы вообще не читали код Storm, как вы будете анализировать приведенный выше код? Я такой:

  • Во-первых, есть вещь TopologyBuilder, это может быть конструктор Storm или что-то в этом роде.
  • Затем настройте Spout и Bolt (но я не знаю, для чего используются эти две вещи, но я могу нажать на объект и посмотреть, что сделано)
  • Затем установите конфигурацию Config (должно быть сколько памяти выделяет Storm, сколько потоков и т. д., в любом случае, это связано с конфигурацией)
  • Наконец, используйте StormSubmitter для отправки задачи и отправки конфигурации и содержимого TopologyBuilder.

Мы просто ищем, вы можете найти, что его процесс примерно такой:

Носикисточник данных, обычно мы используем его для получения данных, Spout отправляет его в Bolt после получения данных,Данные обработки болтов(уборка). После того, как Bolt очистил данные, их можно записать в источник данных или передать следующему Bolt для продолжения очистки.

TopologyсвязанныйОпределяем Носик и Болт в программе. После того, как различные Spout и Bolt соединены вместе, это становится Topology, а Topology — приложением Storm.

Spout передает данные в Bolt, а Bolt передает данные в Bolt.Процесс этой передачи называетсяStream, Поток проходит один за другимTuple.

Теперь вопрос в том, как связаны наши Носик и Болт? Как связаны Болт и Болт?

На приведенном выше рисунке мы знаем, что топология будет иметь несколько носиков и несколько болтов, поэтому как я узнаю, что данные, передаваемые этим носиком, относятся к этому болту, а данные, передаваемые этим болтом, относятся к другому болту? (Грубо говоря, это на картинке вышестрелаКак это связано? )

В Шторме естьGroupingМеханизм заключается в том, чтобы определить, к какому болту передаются данные носика, а данные болта передаются к следующему болту.

Улучшитьпараллелизм, когда мы устанавливаем Bolt, мы можем указать количество нитей Bolt, что является так называемымExecutor(Носик также может указывать количество потоков, но на этот раз я беру в качестве примера Bolt). Наша структура может выглядеть так:

Стратегии группировки следующие:

  • 1)shuffleGrouping(случайная группировка)
  • 2) fieldsGrouping (группировка по полям, где одно и то же слово можно отправить только одному Болту)
  • 3) allGrouping (рассылка, то есть каждый Кортеж, каждый Болт получит)
  • 4) globalGrouping (глобальная группировка, назначьте Tuple задаче с наименьшим значением идентификатора задачи)
  • 5) noneGrouping (случайное назначение)
  • 6) directGrouping (прямая группировка, указание соответствующих отношений отправки между Tuple и Bolt)
  • 7) Локальная или случайная группировка
  • 8) partialKeyGrouping (группировка ключевых слов, очень похожа на группировку по полям, но его распределение более сбалансировано)
  • 9) customGrouping (пользовательская группировка)

Мы чаще всего используем стратегию shuffleGrouping.Например, на картинке выше два носика, мы будем использовать кортеж этих двух носиковуниформаРаспространяется на каждый Болт для исполнения.

Сказав это, давайте вернемся и посмотрим на исходный код,я добавлю заметку, вы должны быть в состоянии понять:

Нарисую еще одну картинку:

Сложен ли процесс начала работы? Не сложный. Грубо говоря, Spout получает данные, а данные Spout передает Bolt для обработки через механизм группировки.После того, как Bolt их обработает, необходимо продолжить обработку.При необходимости они будут переданы следующему Болтать, а если нет, то будет записано в источник данных., настроить интерфейс и т.д.

Штормовая архитектура

Что происходит, когда мы отправляем задачу? Давайте взглянем.

  1. После того, как задание отправлено, оно будет загружено вNimbusНа узле это главный узел, отвечающий за выделение кода, организацию задач и обнаружение ошибок.
  2. Нимб пойдетZookeeperПрочитайте информацию всего кластера и передайте задачуSupervisor, который является рабочим узлом, отвечающим за создание и выполнение задач.
  3. SupervisorСоздайте рабочие процессы, каждый рабочий соответствует подмножеству топологии. Worker — это контейнер Task, а Task — настоящий исполнитель задачи.

Процесс примерно такой:

И Nimbus, и Supervisor являются узлами (серверами), и Storm использует Zookeeper для управления информацией узлов Supervisor.

Рабочие процессы создаются в узле Supervisor, а количество создаваемых рабочих процессов определяется файлом конфигурации Conf. Поток Executor генерируется процессом и используется для выполнения задач, количество потоков Executor определяется при использовании setBolt и setSpout. Task является настоящим исполнителем задачи, а Task фактически является оболочкой для экземпляра Bolt/Spout.

Что касается отношений между Worker, Executor и Task, на официальном сайте есть пример, можем посмотреть. Сначала отпустите код:

Внутреннее изображение:

объяснять:

  • по умолчанию:Если не указать количество Задач, то у потока будет одна Задача
  • conf.setNumWorkers(2)Делегат создаст два рабочих процесса
  • setSpout("blue-spout", new BlueSpout(), 2)Синий носик будет обрабатываться двумя потоками, потому что процессов два, поэтому у одного процесса будет синий поток носика.
  • topologyBuilder.setBolt("green-bolt", new GreenBolt(), 2).setNumTasks(4)Зеленый Bolt будет обрабатываться двумя потоками, потому что есть два рабочих процесса, поэтому один процесс будет иметь один зеленый поток Bolt. И поскольку количество задач установлено равным 4, поток выделит две зеленые задачи.
  • topologyBuilder.setBolt("yellow-bolt", new YellowBolt(), 6).shuffleGrouping("green-bolt"). Yellow Bolt будет иметь 6 потоков для обработки, потому что создаются два процесса, поэтому один процесс будет иметь 3 потока Yellow Bolt. Отдельной книги задач нет, поэтому у потока по умолчанию одна задача.

Из вышеизложенного мы можем знатьthreads ≤ tasksКоличество потоков обязательноменьше или равноколичество задач. Вам любопытно, что ваш малыш спросит: "Storm использует потоки, поэтому существует ли небезопасность потоков?(На самом деле, это вопрос, который Санвэй только что выучил)

Вообще говоря, нет, потому что во многих случаях поток соответствует Задаче (Задачу можно понимать как экземпляр Bolt/Spout).Поскольку каждый поток обрабатывает свой собственный экземпляр, конечно, не будет проблем с потокобезопасностью. (Конечно, если вы установите его в Bolt/Spoutстатическая переменная-член, все равно будут проблемы с безопасностью потоков)

наконец

Эта статья кратко представляет Storm.На самом деле в Storm есть много вещей, включая механизм подтверждения. Теперь идем к официалам искать документы, все в главном пушTridentТеперь заинтересованные студенты могут продолжить смотреть вниз.

Опять же, наша компания также продвигаетFlinkТеперь, если есть план последующей миграции для этой части, я также собираюсь изучить и сделать это, а затем я поделюсь и поделюсь вводной статьей.

Использованная литература:

Резюме различных точек знаний

Следующие статьи имеют соответствующиеоригинально и красивоPDF, в постоянном обновлении, вы можете прийти ко мне, чтобы призвать к обновлению ~

Проект с открытым исходным кодом, охватывающий все точки знаний о бэкэнде Java (уже 7 тысяч звезд):GitHub.com/Zhongf UC очень…

Если хочешьв реальном времениЕсли вы обратите внимание на мои обновленные статьи и галантерейные товары, которыми я делюсь, поищите в WeChat.Java3y.

Содержимое PDF-документоввсе вручнуюЕсли вы не понимаете, вы можете напрямуюСпроси меня(В официальном аккаунте есть мои контактные данные).

В этой статье используется

Категории