►
Description
1.) With each device comes an implicit contract with the end user: you give us the data, we give you the results. Now. Not tomorrow. Not even fifteen minutes from now.
2.) The flip side of getting data in real time is that users expect results in real time.
3.) In return for being wired into the internet 24x7 customers demand a similar level of responsiveness and even better availability.
__
Spark Streaming and Cassandra form the ideal combination of high velocity CEP and analytics with a high velocity and always on database.
Today's solutions don't scale to the Internet of tomorrow. The always-on nature of the emerging Internet of Things space means you need to process information at previously unseen scale and, more difficult, make sense out of that data.
Cassandra is the leader in large scale, high velocity, time series data workloads. While the Hadoop world has been stuck with legacy "batch analytics" technology, Cassandra users have been increasingly focused on the "now". Fast answers to easy questions about your data, at any velocity, and any scale. But Cassandra has always been weak on the "complex questions" problem. DataStax integrated with Hadoop to overcome this limitation, but it was always an awkward fit. Slow batch analytics on top of fast moving data really doesn't do you much good.
But Spark, and in this case, Spark Streaming, make high velocity streaming analytics at scale easier than ever, similar to how Cassandra pioneered high-velocity data management at scale.
Hadoop is the right choice for batch analytics. Until recently, nobody really knew what the right solution is for real-time processing. We believe that Spark and Cassandra are the clear answer.
---
Tupshin has been helping Cassandra users and DataStax customers build large scale, high velocity applications for years. As both a Solutions Architect as well as the lead Field Strategist for DataStax, he has seen deployments of every scale and in every sector. Recently specializing in the financial services space, he has worked with numerous banking industry customers to build and refine their mission critical, enterprise scale, operational data stores based on Cassandra and DataStax Enterprise. After 18 years in the Bay Area start-up scene, he recently packed up and moved to New York City.
Al is a father, technologist, musician, and open source advocate working for DataStax. While attending Central Michigan University as a music major, Al got into MUDs, C, and Linux, eventually ending up with a career as a sysadmin. Over the last 15 years, Al has worked on everything from kernel changes to modern web applications, mostly from inside operations teams. These days he goes by the title Open Source Mechanic, which means he tries to do interesting things with Cassandra and other open source software.
A
A
A
A
A
Cap
theorem
very
essential
to
everything
that
we're
doing
basically
saying
that
you
cannot
be
both
strongly
consistent
and
strongly
available
at
geographic
scale.
There's
some
nuances
around
that
happy
to
talk
about
them.
You
know
later,
but
it
really
goes
to
the
core
of
everything
distributed
system-wise
a
little
fun
here,
not
a
big
fan
personally,
so
I'll
just
move
past
that
one
hi
eric.
A
This
is
what
we
did
to
hadoop.
We
took
the
complexity
that
you
saw
in
all
those
layers
and
we
took
advantage
of
cassandra's
multi-data
center
awareness
and
said:
hey.
Why
not
just
deploy
additional
functionality
in
one
or
more
of
those
data
centers,
so
with
much
less
configuration
than
you'd
ever
have
to
do
with
a
traditional
hadoop
with
much
less
deployment.
You
basically
install
datasack's
enterprise.
B
A
A
A
Would
you
like
to
talk
about
the
internet
of
things?
Okay,
so
internet
of
things
is
both
a
a
meme.
It's
a
marketing
ploy,
but
it's
also
a
bit
of
a
reality
wikipedia
you
know.
Furley
basically
says
it's
refers
to
uniquely
identifiable
objects
and
their
virtual
representations
in
an
internet-like
structure.
A
Basically,
that
just
says
you
have
devices
they're
connected
they're,
sending
data
to
you
and
you're
doing
stuff
in
response
pretty
basic.
No,
but
really
what
is
it
it's
the
act
of
connecting
and
it
actually
predates
the
world
wide
web?
The
first
toaster
was
connected
to
the
internet
in
1990.
First
web
page
deployed
in
1991
internet
of
things
is
not
new.
That's
that's
really
the
reason
why
I'm
calling
it
a
quote
revolution
and
really
shouldn't
be
surprising
to
anybody.
A
A
A
B
B
So
the
the
big
difference
and
the
reason
why
I
believe
that
iot
is
becoming
a
real
thing.
Is
it's
a
problem
of
scale?
If
you
look,
if
you
talk
to,
I
have
friends
who
work
for
smart
meter
companies
right.
If
you
see
the
newer
meters
on
a
lot
of
houses,
they
actually
have
a
wireless
transceiver
in
them,
and
a
lot
of
them
have
ipv6
addresses
and
the
power
companies
are
early
adopters
of
ipv6,
specifically
because
they
couldn't
get
enough
address
range
in
ipv4
to
do
what
they
wanted.
B
They
wanted
to
use
commodity
ip,
so
they
moved
to
that
and
millions
of
homes
wired
up.
This
is
a
problem
of
scale
in
that
how
many
samples
do
they
want
to
take
every
second
or
every
hour
off
of
a
meter?
The
the
more
frequently
you
take
samples
or
the
more
higher
resolution
of
the
data
is
the
more
useful
it
is
for
things
like
trending
right.
B
So
now,
if
a
power
company
is
looking
at
data
across
all
of
their
meters
and
they're
they're
doing
analytics
on
that
data,
they
can
start
to
do
things
like
predicting
load,
spikes
and
start
to
do
power.
Grooming
across
the
grid-
so
that's
just
one
very
real,
already
existing
use
of
the
same
technology.
B
We're
talking
about,
and
so
cassandra
comes
into
play
because,
when
you're
gathering
all
these
metrics,
you
got
to
have
somewhere
where
you
can
put
them
in
real
time
and
be
able
to
scale
out
that
storage
linearly
as
the
number
of
devices
grows,
as
your
sample
rate
grows.
As
you
change
your
product
over
time
and
add
more
data
in
the
more
data
you
have,
the
more
insights
you
get,
the
happier
you
can
make
your
customers
right.
This
is
where
the
cool
stuff
comes
from.
B
Well,
we
have
customers
from
anywhere
from
one
node.
You
know
developing
small
applications
on
a
single
host,
all
the
way
up
to
many
thousands
of
nodes.
The
biggest
rings
I
think,
we've
seen
are
a
thousand
nodes
right
around
that
range.
Our
goal
is
to
hit
10
000
sometime
this
year
at
least
test
it
and
make
sure
it
works.
So
that's
something
that
that's
our
goal
for
data
stacks.
A
B
So
cassandra
chooses
eventually
consistent,
which
means
you
do
your
right
to
your
coordinator
and
it
says:
okay,
I
got
it
and
it
takes
care
of
replication
in
the
background
it's
tunable
in
that
you
can
say,
don't
tell
me
it's
done
until
it's
done
or
you
can
say
tell
me
when
you
have
the
data
and
I
can
go
off
and
do
other
things
right.
There's
it's
tunable
in
that
sense,
and
then
we
have
things
like
lwt,
so
our
lightweight
transactions,
which
are
based
on
paxos
that
let
you
say
no
really.
A
So
the
emphasis
on
a
fundamental
trade-off-
I
want
to
you,
know,
stress
how
important
that
is
when
you're
dealing
with
a
single
system
that
spans
the
globe
say
or
as
a
thought
experiment
was
like.
Okay,
what?
If
we
had
a
single
cluster
that
spanned
you
know,
earth
to
moon
or
earth
to
mars
you're
talking
about
latencies
that
are
inherently
not
interactive,
and
you
at
that
point
just
can't
treat
a
remote
data
center
as
ever
technically
up
or
down.
A
So
if
you
are
going
for
strong
consistency
that
says
I
will
always
have
the
same
view
of
my
data
from
any
you
know,
location.
You
can
no
longer
guarantee
that
at
even
global
scale.
Once
you're
talking
about
you,
know
hundreds
of
milliseconds
round
trips,
your
you
know,
users
aren't
going
to
wait
for
that
for
to
achieve
complete
consistency
or
immediate
consistency
for
every
operation,
so
you
actually
have
to
adopt
some
kind
of
eventual
consistency
model.
A
Get
back
thanks
for
derailing
me
now,
one
sec,
okay,
so
something
like
just
really
doesn't
try
to
address
that
directly.
They're
master
at
one
location.
Only
couch
base
is
another
strongly
consistent
system
locally,
but
they
actually
adopted
eventual
consistency
for
replication
between
clusters,
which
is
their
method
of
doing
remote
geography.
B
B
If
you
have
sites
in
multiple
geographies,
what
you
can
all
of
a
sudden
they
do
is
now
you
can
ingest
those
metrics
as
close
to
the
customer
as
possible,
which
provides
lower
latency,
it's
higher
more
highly
available.
If
you
have
internet
cuts
in
the
middle
of
the
country,
you
don't
have
to
lose
data,
because
all
of
a
sudden,
your
data
center
on
the
west
coast
can't
get
data
from
the
east
coast.
You
have
data
centers
on
either
and
what
that
makes
cassandra
makes
that
possible
through
data
center
replication.
B
B
It
manages
all
the
routes
across
the
internet
and
it
manages
all
the
failures
so
that
if
a
router
fails
somewhere
between
you
and
your
destination,
it
will
automatically
take
care
of
setting
up
new
routes
to
route
around
it,
and
this
is
all
automatic
and
the
whole
internet
works
this
way
and
there's
a
trick.
You
can
play
with
dns
where
you
actually
advertise
the
same
address
from
multiple
data
centers
and
then,
when
you
go
to
do
that,
dns
query.
B
So
when
you
type
www.datastacks.com
into
your
browser,
it's
going
to
send
out
a
udp
packet
and
if
it
goes
to
that
address,
it's
going
to
go
shortest
hop
to
the
local
data
center.
This
is
how
cdns
work,
by
the
way,
if
you
didn't
know
that
it
goes
to
the
closest
data
center,
that
dns
server
replies
with
a
local
address,
and
then
your
tcp
connection
goes
to
that
data
center.
B
You
can
do
all
this
stuff
on
top
of
cassandra,
your
application
on
top
of
cassandra,
so
that
you
can
have
the
same
data
in
all
your
locations,
whether
it's
ingest
or
egress,
and
have
your
application,
be
highly
available
and
spread
across
multiple
geographies
using
this
technology
without
it.
So
you
can
do
things
like
take
data
centers
offline.
You
can
survive
internet
cuts
all
these
different
things
using
technology
that
we've
been
using
for
years
on
the
internet.
A
So
spark
emerged
out
of
actually
both
berkeley
and
mit
as
really
a
alternative
to
hadoop,
recognizing
that
some
of
the
fundamental
limitations
of
the
mapreduce
model
of
hadoop
were
really
holding
it
back.
Besides,
some
very
questionable
architectural
choices,
but
really
the
the
the
initial
driver
was,
was
to
address
the
limitations
of
a
a
flow.
That
is
a
fundamentally.
You
know
two
phases
you
map
over
a
very
large
set
of
data.
Typically,
then
you
reduce
it
within
each.
A
You
know
region
and
then
you
know,
merge
data
across
those
those
different
splits
that
is
powerful,
but
it's
not
flexible.
You
can't
do
exploratory
analytics
that
way
very
easily
or
really
at
all
in
any
kind
of
a
reasonable
time
frame.
So
the
addition
that
spark
brought
to
that
world
is
dag,
directed
acyclic
graph.
It
basically
means
that
you
have
a
lot
more
control
over
how
the
execution
of
a
batch
process
works.
A
You
can
go,
you
know
if
you
treat
your
data
set
as
a
graph,
even
if
you're
talking
about
relational
tables
you're
talking
about
traversing
between
portions
of
those
tables,
a
direct-to-basic
graph
approach
says
you
can
go
from
here
and
then
maybe
do
a
fan
out
to
n
number
of
locations
from
there
within
your
data
set
and
then
from
each
of
those.
You
can
go
back
to
the
original
location
or
back
to
some
others
and
just
keep
doing
additional
processing.
A
You
know
also
spark
it
was
designed
to,
as
I
said,
address
a
number
of
the
architectural.
You
know:
challenges
and
limitations
of
hadoop,
hadoop's,
sort
of
notorious
for
having
single
points
of
failure.
In
terms
of
you
know,
name,
nodes
and
and
various
complexities
in
their
deployments
and
pretty
much
every
additional
api
and
system
that's
been
layered
on
top
of
hadoop
has
had
a
bunch
of
those
same
challenges
as
a
result.
A
Spark
adopts
much
of
the
hadoop
ecosystem.
It
allows
you
to
use
things
that
you're
familiar
with
like
hdfs
as
a
file
system.
You
can,
even
you
know,
talk
to
hbase
as
a
database
for
it
you
can
use
ports
of
hive,
for
example,
is
now
called
shark
on
top
of
spark.
Pig
has
now
called
spork
on
top
of
a
spark.
Yes,
but
fundamental
yeah,
but
but
those
are
are
also
a
bit
limited
in
that
they
come
from
the
mapreduce
ecosystem
and
mindset.
A
A
The
other
thing
from
a
performance
point
of
view
is
a
very
intelligent
use
of
caching
spark
incorporated
what
are
called
rdds
resilient
data.
Damn
it
really
resilient
distributed.
Data
sets
thank
you
which
are
they
carry
with
them
the
chain
of
history
or
provenance
of
how
they
were
created.
So
if
you
actually
have
an
rdd
that
is
generated
from
from
a
query
that
can
be
cached
that
can
be
stored
and
used
later.
A
A
lot
of
people
are
doing
that
too,
to
pull
data
into
hadoop
or
cassandra
or
many
other
systems.
A
spark
incorporates
streaming,
and
that's
really
what
we're
going
to
be
doing
a
lot
of
talking
about
into
your
batch
execution
platform
to
make
it
a
first
class
citizen
with
respect
to
processing
your
data.
A
B
So
putting
this
in
context
for
those
of
you,
who've
worked
with
cassandra
before
how
many
times
have
you
sat
down,
created
a
couple
tables
and
went
crap
now
I
gotta
join
right.
You
want
to
join
and,
and
you
you
call
you,
you
email
me
or
the
mailing
list,
and
they
say:
oh,
you
have
to
put
them
in
the
same
table
materialize
it.
I
could
reference
a
certain
comic.
That's
been
going
around
big
data
circles,
but
I
won't
go
have
fun
with
yourself.
This
is
kind
of
the
answer
a
lot
of
times.
B
What
spark
does
and
the
reason
why
we're
so
excited
about
it
is
sitting
on
top
of
cassandra.
Is
we
didn't
want
to
get
in
the
business
of
writing
a
distributed?
Query,
planner
and
execution
engine
and
it's
an
incredibly
complicated
topic.
The
spark
guys
have
been
at
it
for
actually
what
seven
years
now
they've
been
working
on
it,
it's
almost
as
old
as
cassandra,
and
so
they've
already
done
all
of
this
work,
and
it
turns
out
it's
a
really
good
fit
for
cassandra.
B
So
what
spark
is
going
to
be
giving
us
is
the
ability
that
query
execution
engine
distributed
directly
like
acyclic
graph,
which
means
you
can
just
have
a
bunch
of
jobs
that
are
connected
and
it
takes
care
of
figuring
out
where
to
run
them
when
to
run
them
and
what
order
to
run
them
in
and
it
paralyzes
them
across
nodes
in
a
way
that
hadoop
never
really
did
it
very
well.
Hadoop
was
a
simple
first
generation
system,
it's
kind
of
showing
its
age.
B
So
one
of
the
one
of
the
great
use
cases
for
us
is
time
series
most
of
the
iot
stuff
that
that
we're
seeing
out
in
the
field
is
time,
series
data
right,
your
thermostat
reports
every
few
seconds
or
every
minute
what
the
temperature
in
your
house
is.
What
is
the
setting?
What's
the
humidity
all
these
different
dimensions
of
data
that
goes
into
a
time
series
schema
getting
meaning
from
that.
B
A
It's
really
the
time
to
get
your
answer
in
the
you
know
increasingly
connected
world
in
the
and
you
know,
frankly,
just
the
increased
competition.
Everybody
wants
answers
from
their
data
faster
and
faster.
You
know
when
hadoop
first
became
available.
You
know
people
were
so
happy
that
they
could
get
really
good
meaningful
results
out
of
their
data
overnight.
That
was
good.
You
know,
then
various
efforts
have
accelerated
things
that
are,
you
know
it's
now
reasonable
to
get.
A
You
know,
map-reduced
jobs
that
run
in
minutes
or
hours
or
but
never
really,
like
second
wait
and
see,
or
a
few
second
wait
and
see.
So
if
you
need
to
you
know,
be
doing
ad
hoc
queries
you're
going
to
be
sitting
there
waiting
if
you
need
to
be
able
to
take
immediate
action
in
response
to
an
event
and
that's
where
streaming
comes
in
then
you're
not
going
to
be
able
to
do
that.
B
I
don't
want
to
report
on
data.
Oh
yes,
you
do
well
it's
just.
What
we're
saying
is
that
the
meaning
turns
into
a
report
that
you're
going
to
show
to
your
users,
or
maybe
there's
more
interesting
things
you
do
right
is
the
the
bigger
the
scale
of
the
data,
the
larger
the
query,
so
you
can,
if
I'm
talking
about
a
particular
user,
usually
a
single
user
will
fit
in
a
single
partition
on
a
single
node.
That's
fine
right!
All
my
thermostat
data
for
my
whole
life
would
easily
fit
on
the
hard
drive
in
my
computer.
B
But
if
I
want
to
go
and
say
well,
I
want
to
see
behavior
of
user
populations
across
everybody
in
this
room,
then,
all
of
a
sudden.
Now
we
don't
fit
on
one
hard
drive.
If
we
do
it
across
new
york
city,
it's
not
going
to
fit
on
one
node
right
and
that
that's
where
it
really
starts
to
get
interesting
and
what
the
reporting
is.
A
Netflix
was
testing
to
make
sure
that
it
could
meet
their
scalability
needs
and
they
scaled
it
up
to
this
case,
300
nodes
million
writes
per
second,
and
but
you
know
the
numbers
there
didn't
matter
that
much
what
mattered
was
they
had
predictable
increase
in
performance,
no
matter
how
many
nodes
they
added
as
al
says
we're
now
up
to
a
thousand
plus.
I
actually
think
there's
some
production
clusters
in
the
2000
range,
but
yeah
we're
definitely
headed
further
and
further.
You
know
out
horizontally
with
the
sheer
number
of
nodes
in
a
single
cluster.
A
We
can,
you
know,
add
data
centers,
I've.
You
know
seen
deployments
up
to
12
data
centers
spanning
the
globe.
You
know
hundreds
of
nodes
in
each
data
center.
At
no
point
are
we
failing
to
achieve
that
linear
scale
up
that
you
really
need
if
your
data
and
your
use
cases
are
likely
to
scale
up
as
well
any
system
that
doesn't
allow
you
to
horizontally
scale
out
or
doesn't
allow
you
to
do
it
linearly
is
going
to
be
an
obstacle
to
your
growth.
If
you're
a
startup,
it's
going
to
be
an
obstacle
to
your.
A
A
A
A
What
spark
streaming
does
is
it
divides
those
streams
into
what
are
called
d
streams,
discretized
streams
which
chunk
it
up
into
small
windows
of
time
like
five.
Second
windows
are
typical
in
order
to
achieve
efficiency
in
batching
and
achieve
various
windowing
algorithms
that
you
couldn't
do
if
you're
just
looking
at
a
single
data
set
at
a
single,
you
know
point
in
time
at
a
time.
A
The
key,
though,
is
that
you're
actually
able
to
apply
virtually
all
the
same
types
of
algorithms
that
you
do
to
a
mapreduce
or
dag
direct
is
a
cyclic
graph
spark
job
at
ingest
time
at
streaming
time
before
the
data
or
simultaneously,
while
the
data
gets
into
your
database.
That's
what
allows
you
to
to
do.
You
know
immediate,
you
know
anomaly
detection
and
what's
what
allows
you
to
take
immediate?
You
know
proactive
action.
A
B
The
other
so
spark
streaming
really.
I
see
it
as
filling
a
couple
of
different
niches.
One
is
when
you
want
to
do
real-time
reaction
to
basically
what
we
call
cep
before
right.
You
want
to
have
a
stream
of
events
coming
in
and
you
want
to
do
things
on
the
data
as
it
arrives
and
make
decisions
at
that
instant.
B
The
other
one
is
roll
ups
kind
of
real
time
right.
You
have
a
bunch
of
metrics
data
coming
in
you
want
to
go
over
a
window,
you
want
to
basically
save
averages
and
maybe
throw
away
the
high
resolution
data
for
storage
efficiency,
but
the
other
big
thing,
that's
kind
of
a
side
effect
of
having
the
system
is.
We
don't
have
to
write
all
these
stupid
ingest
systems
from
scratch,
anymore,
right,
who's,
tired
of
writing,
ingest
systems.
B
I
mean
I
am
I've
written
a
whole
bunch
of
them
and
it
sucks
it's
always
tricky
and
getting
the
high
availability
right
is
tricky
and
there
aren't
haven't
been
many
good
tool
kits.
A
lot
of
people
are
using
storm,
storm's,
okay,
but
it
comes
with
zookeeper,
which
is
not
okay,
you
know.
Well,
so
it's
it's!
A
provably
reliable
system,
it's
just
operating
it's
kind
of
a
pain
in
the
butt,
so
that
that's
kind
of
the
other
part
of
spark
streaming
that
I
find
really
interesting.
Having
built
some
of
this
stuff.
B
Before
so,
we
we
kind
of
like-
or
I
kind
of
like,
because
I
come
out
of
an
operations
background
to
think
about
this
in
terms
of
well
just
managing
our
own
data,
centers
right
kind
of
dog
fooding
this
this
stuff,
so
we've
had
for
a
long
time
monitoring
systems
that
are
basically
just
canned
reports.
It's
just
a
whole
bunch
of
canned
reports.
It's
the
is
the
host
up
and
down
you.
You
open
your
page
and
your
monitoring
system.
B
You
see
all
the
little
graphs
and
stuff,
but
that's
all
old
data
that
has
been
sitting
on
a
hard
drive
for
at
least
a
few
seconds,
and
you
can't
do
much
with
correlation
across
different
metrics
and
things
like
that,
after
the
fact
to
make
really
intelligent
decisions
about
what's
happening
in
your
network
right.
This
is
kind
of
the
holy
grail
of
monitoring
is
to
be
able
to
do
things
like
what
spark
streaming
allows
you
to
do
and
say.
B
B
You
need
to
be
able
to
actually
drill
down
from
say
this
high
level
aggregate
that
we
did
across
multiple
different
metrics
and
be
able
to
go
and
see
the
raw
metrics
to
make
decisions
and
obviously
alerting
comes
out
of
that
aggregation.
We
already
talked
about
one
of
the
most
popular
questions
that
I
get
all
the
time
is
I
didn't
introduce
myself,
I'm
evangelist
for
apache
cassandra
at
datastax
is
how
do
I
do
top
k
in
cassandra?
B
It's
one
of
the
most
popular
questions
we
get
all
the
time
and
the
answer
now
is
to
do
it
through
spark,
but
in
the
case
of
spark
streaming,
you
can
actually
build
these
top
k
lists,
as
the
events
come
in
and
just
serialize
them
to
cassandra
or
actually
wherever
and
then
the
ml
stuff
I'll.
Let
you
talk
about
it's
more
hit
space.
B
A
A
Okay,
all
right!
So
just
a
quick
point
here.
Take
action
at
scale.
Best
practice
with
cassandra
has
long
been
to
have
a
bank
of
application
servers
co-located
with
your
cassandra
data
centers,
and
this
is
a
key
to
the
high
availability
store.
You
want,
the
you
know,
hurricane
sandy
wiped
out.
You
know
outbrain
their
new
york
data
center.
They
kept
going
without
any
problems
because
they
had
full
availability
through
multiple
other
data.
A
Centers
and
all
they
had
to
do
was
route
their
traffic
around
if
they
had
data
application
server
interdependencies
between
those
data
centers
huge
problem.
So
basically
the
the
architecture
and
the
topology
here
is
the
blue
is
cassandra.
The
green
is
spark
and,
if
you
add
in
your
own
application
servers
it's
another.
You
know
you
know,
bank
of
machines
co-located
with
each
of
those.
A
The
other
pattern,
if
you
want
to
go
with
getting
data
into
cassandra,
because
durability
is
key,
cassandra's
consistency,
levels
being
tunable,
allow
you
to
guarantee
that
you
have
at
least
you
know
n
number
of
nodes
that
have
received
a
a
message
before
acknowledging
success
back
to
that
customer.
If
you
want
to
be
relying
on
that
durability,
you
can
still
write
into
cassandra
and
then
various
methods
and
we're
going
to
make
that
even
easier
moving
forward.
A
The
multi
dc,
though,
is
really
the
key
in
this
case
you're,
just
you
know,
fanning
it
out
to
any
location
where
you
need
to
be
now.
People
choose
multi
dc
with
cassandra
for
multiple
reasons,
including
just
bear.
You
know
high
availability,
and
for
that
they
could
be.
You
know
a
few
hundred
miles
away.
That
would
be
sufficient,
but
often
you
need
them
to
be.
A
You
know
in
remote
locations
to
ensure
low
latency
response
time
between
the
devices
or
the
people
that
are
interacting
with
it
cassandra's
one
of
the
very
very
few
products
out
there.
That's
able
to
scale
out
and
be
able
to
do
master
master
absolutely
everywhere.
Thankfully,
our
spark
architecture
allows
us
to
do
the
same
thing
there
by
having
spark
co-processors
as
I'm
thinking
of
them
now,
alongside
each
cassandra,
node
you're
able
to
do
that.