Б Бёрнс - Распределенные системы. Паттерны проектирования

--replication-factor 3 --partitions 10 --topic photos-$x done

Помимо названия темы и ссылки на сервис ZooKeeper, обра-тите внимание на два интересных параметра: --replication-factor и --partitions . Множитель репликации устанавливает, на сколько машин будет реплицироваться тема. Он характе-ризует степень избыточности, доступной в случае отказа. Рекомендуется использовать значение 3 или 5 . Второй па-раметр — количество разделов в теме. Количество разделов соответствует максимальному числу машин, на которые тема будет распространяться с целью балансирования нагрузки. Поскольку в данном случае мы задали десять разделов, для балансирования нагрузки может использоваться не более десяти копий.

204Часть III. Паттерны проектирования систем пакетных вычислений В созданную только что тему теперь можно отправлять со-общения:

kubectl run kafka-producer --image=solsson/kafka:0.11.0.0 --rm -it --command -- \

./bin/kafka-console-producer.sh

--broker-list kafka-service-kafka:9092 \

--topic photos-1

После выполнения данной команды появится приглашение командной строки Kafka, откуда можно отправлять сообщения в тему (-ы). Для получения сообщений выполним команду: kubectl run kafka-consumer --image=solsson/kafka:0.11.0.0 --rm -it --command -- \

./bin/kafka-console-consumer.sh --bootstrap-server kafka-service-kafka:9092\

--topic photos-1 \

--from-beginning

Запуск этих команд позволяет лишь поверхностно ознакомить-ся с механизмами коммуникации на основе Kafka-сообщений. Чтобы построить настоящую событийно-ориентированную систему пакетной обработки, вам, скорее всего, придется ис-

пользовать настоящий язык программирования и инструмен-тарий разработчика Kafka SDK. С другой стороны, не следует недооценивать мощь хорошего bash-сценария! Этот пример показал вам, как установить инструментарий Kafka в Kubernetes-кластер, и то, насколько сильно он упрощает по-строение систем на основе очередей задач. 12 Координированная пакетная обработкаВ предыдущей главе мы рассмотрели паттерны разделения и сцепления очередей, позволяющие реализовать более слож-ную пакетную обработку. Дублирование и порождение не-скольких наборов выходных данных — значительная часть пакетной обработки, но иногда не менее важным оказывается слияние нескольких выходных потоков данных с целью полу-чения некоторого агрегированного результата. Общая схема подобного паттерна приводится на рис. 12.1. Наиболее типичный пример подобной агрегации — паттерн MapReduce. Нетрудно заметить, что шаг Map соответствует шардированию очереди задач, а шаг Reduce — координирован-ной обработке, в результате которой большое количество дан-ных агрегируется в один ответ. Кроме MapReduce, существует еще несколько паттернов пакетной обработки. В этой главе рассмотрены некоторые из них, а также соответствующие при-ложения.

206Часть III. Паттерны проектирования систем пакетных вычислений

Рис. 12.1. Обобщенная пакетная система распределениязадач и агрегации результатов

Паттерн Join (барьерная синхронизация) В предыдущих главах мы рассмотрели паттерны распределения работы между несколькими вычислительными узлами. В част-ности, разобрались, как шардированная очередь задач может па-раллельно распределять нагрузку на несколько шардов очереди задач. Иногда очередной этап обработки потока задач требует наличия полного набора данных, прежде чем можно будет про-должить вычисления.

Одним из вариантов, как показано в предыдущей главе, будет слияние нескольких очередей воедино. Однако слияние попро-Глава 12. Координированная пакетная обработка 207сту объединяет выходы двух очередей в один поток, который подвергнется дальнейшей обработке. Паттерна слияния в неко-торых случаях достаточно, но он не гарантирует готовность все-го набора данных до момента начала обработки. Следовательно, полнота выполняемой обработки не может быть гарантирована. Кроме того, нет возможности подсчитать агрегированную ста-тистику по обработанным элементам данных. Нам нужен другой примитив пакетной обработки данных, более строгий и координирующий. Таким примитивом и выступает паттерн Join. Паттерн Join по смыслу аналогичен слиянию по-токов. Основная идея данного паттерна состоит в том, что, хотя значительная часть обработки осуществляется параллельно, эле-менты очереди задач не могут выйти из блока Join, пока не будут вычислены все элементы параллельно вычисляемого набора дан-ных. Подобный прием в параллельном программировании также известен под названием «барьерная синхронизация» . Паттерн ко-ординированной пакетной обработки Join изображен на рис. 12.2. Координация с помощью Join гарантирует, что до выполне-ния агрегации (например, суммирования элементов) ни один элемент данных не останется невычисленным. Достоинство паттерна Join в том, что он обеспечивает наличие всех данных в агрегируемом наборе. Недостаток паттерна Join в том, что перед началом вычислений он требует, чтобы все данные были обработаны на предыдущем этапе вычислений. Это снижает до-ступный в рамках пакетной обработки уровень параллелизма, а значит, увеличивает задержку выполнения потока задач. Паттерн Reduce

Как уже было сказано, шардирование может выступать при-мером реализации фазы Map в каноническом алгоритме Map/ Reduce . Следовательно, нам осталось лишь реализовать фазу Reduce . Reduce является примером паттерна координированной 208Часть III. Паттерны проектирования систем пакетных вычислений

Рис. 12.2. Паттерн пакетной обработки Join