Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Learning Real-time Analytics with Storm and Cassandra

You're reading from   Learning Real-time Analytics with Storm and Cassandra Solve real-time analytics problems effectively using Storm and Cassandra

Arrow left icon
Product type Paperback
Published in Mar 2015
Publisher
ISBN-13 9781784395490
Length 220 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Author (1):
Arrow left icon
Shilpi Saxena Shilpi Saxena
Author Profile Icon Shilpi Saxena
Shilpi Saxena
Arrow right icon
View More author details
Toc

Table of Contents (14) Chapters Close

Preface 1. Let's Understand Storm 2. Getting Started with Your First Topology FREE CHAPTER 3. Understanding Storm Internals by Examples 4. Storm in a Clustered Mode 5. Storm High Availability and Failover 6. Adding NoSQL Persistence to Storm 7. Cassandra Partitioning, High Availability, and Consistency 8. Cassandra Management and Maintenance 9. Storm Management and Maintenance 10. Advance Concepts in Storm 11. Distributed Cache and CEP with Storm A. Quiz Answers Index

Delving into the internals of Storm

Now that we know which physical components are present in a Storm cluster, let's understand what happens inside various Storm components when a topology is submitted. When we say topology submission, it means that we have submitted a distributed job to Storm Nimbus for execution over the cluster of supervisors. In this section, we will explain the various steps that are executed in various Storm components when a Storm topology is executed:

  • Topology is submitted on the Nimbus node.
  • Nimbus uploads the code jars on all the supervisors and instructs the supervisors to launch workers as per the NumWorker configuration or the TOPOLOGY_WORKERS configuration defined in Storm.
  • During the same duration all the Storm nodes (Nimbus and Supervisors) constantly co-ordinate with the Zookeeper clusters to maintain a log of workers and their activities.

As per the following figure, we have depicted the topology and distribution of the topology components, which are the same across clusters:

Delving into the internals of Storm

In our case, let's assume that our cluster constitutes of one Nimbus node, three Zookeepers in a Zookeeper cluster, and one supervisor node.

By default, we have four slots allocated to each supervisor, so four workers would be launched per Storm supervisor node unless the configuration is tweaked.

Let's assume that the depicted topology is allocated four workers, and it has two bolts each with a parallelism of two and one spout with a parallelism of four. So in total, we have eight tasks to be distributed across four workers.

So this is how the topology would be executed: two workers on each supervisor and two executors within each worker, as shown in the following figure:

Delving into the internals of Storm
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image