►
Description
This talk was given at one of four live meetups as part of Data + AI Summit 2021 on May 26, 2021.
Title: Introduction, principles and origin of Dagster by Nick Schrock
Abstract: Nick will cover the principles and origin of Dagster (https://dagster.io/). Dagster is a new type of workflow engine: a data orchestrator. Moving beyond just managing the ordering & physical execution of data computations, Dagster considers the entire data application lifecycle. Practitioners in Dagster build data-aware dependency graphs designed for local development and testing; deploy those graphs to multi-tenant, cloud-native orchestration engine; and then monitor and observe the data assets produced by those computations.
In this talk, Nick will cover how Dagster differentiates itself across the three stages (dev & test, deploy & execute, monitor & observer) of the application lifecycle. Through a demo and code snippets, the talk aims to show how the Dagit web UI and Dagster programming model can power a variety of data practitioners.
Speaker: Nick Schrock is the founder and CEO of Elementl, the company behind Dagster. Previously, Nick worked at Facebook, where he co-created GraphQL. Databricks is proud to announce that Gartner has named us a Leader in both the 2021 Magic Quadrant for Cloud Database Management Systems and the 2021 Magic Quadrant for Data Science and Machine Learning Platforms. Download the reports here. https://databricks.com/databricks-named-leader-by-gartner
A
A
And
you
know
after
I
left
in
2017.
I
took
some
time
and
started
to
figure
out
what's
next
and
I
was
asking
traditional
companies
and
technology
companies
what
their
biggest
problems
were
and
the
idea
that
data
infrastructure
and
now
infrastructure
and
all
related
activities
were
the
biggest
problem
kept
on
coming
up
over
and
over
again.
A
So
I
looked
into
it
and
you
know
what
I
saw
was
the
biggest
mismatch
between
the
complexity
and
criticality
of
a
problem
domain
and
the
tools
to
support
that
domain,
that
I've
ever
seen
in
my
entire
career
and
when
I
see
something
like
that,
I'm
just
totally
compelled
to
work
on
it
and
after
a
lot
of
an
examination-
and
you
know,
deep
introspection.
Introspection
is
wrong
where
deep
inspection
of
the
of
the
the
domain,
it
really
struck
out.
A
A
A
But
you
know
we
at
dagster
really
think
is
orchestration,
not
as
that's
that
problem
to
solve,
but
an
incredible
opportunity,
and
the
reason
why
is
that
orchestration
is
its
natural
center
of
gravity
for
the
data
platform?
I
like
to
call
the
town
square.
You
know,
like
I
said
before.
Anyone
who
puts
a
data
product
in
production
has
to
show
up
there.
A
They
bring
their
own
toolkit
and
their
tools,
which
means
that
in
the
end,
the
orchestrator
invokes
every
single
computational
runtime
touches
every
tool
touches
every
storage
system
and
we
divide
the
world
into
kind
of
three
roles
that
the
orchestrator
involves.
One
are
practitioners,
so
these
are
people
who
are
responsible
for
the
production
of
data
assets.
This
will
be
your
data
scientist,
your
analytics
engineer,
your
data
engineer,
and
they
spend
a
lot
of
time
in
the
orchestrator
and
the
graphs
they
end
up.
A
Building
in
the
orchestrator
actually
end
up
being
the
structure
of
their
data
application
that
they're
building.
So
we
think
it's
really
important
to
treat
it
as
such
and
treat
it
like
a
proper
software
artifact
with
a
dev
and
test
like
like
and
applying
the
a
proper
software
engineering
life
cycle
to
it.
There's
other
stakeholders
too
right.
Well,
other
groups,
there's
another
group
called
stakeholders.
A
And,
lastly,
you
have
platform
folks
who
are
responsible
for
the
data
infrastructure
and
support
practitioners
and
stakeholders
and
really
they're
one
of
their
primary
jobs
to
enable
end-to-end
ownership
by
practitioners
over
their
data
asset
production.
So
practitioners
shouldn't
have
to
think
about
infrastructure
and
there's
a
natural
center
of
gravity
for
all
this
and
that's
the
orchestrator,
and
you
know
we
really
think
the
orchestrator
needs
to
be
designed
with
the
full
data
life
cycle
in
online.
That's
what
I'm
going
to
talk
about
today,
I'm
going
to
talk
about
dagster,
so
there's
existing
orchestrators
and
workflow
engines.
A
You
know
what
do
we
hear
from
users
of
those
systems?
You
know
these
would
include.
You
know
the
dominant
one
is
airflow
but
there's
luigi
argo
lots
of
different
systems,
and
what
we
hear
are
things
like
this.
You
know
during
the
development
test
phase
when
they're
working,
they
can't
develop
their
dags
locally.
They
can't
test
their
dags.
You
know,
in
effect,
when
they
hit
the
orchestrator
kind
of
everything
grinds
to
a
halt,
because
it's
very
difficult
to
run
locally,
and
typically
you
just
wait
until
you
deploy
to
run
it
actually
in
most
organizations.
A
You
know
this
is
also
notoriously
challenging.
You
know
what
we
hear
is
that
this
is
incredibly
difficult
to
bug.
I
don't
actually
know
what's
going
inside,
what's
going
on
inside
of
one
of
these
dags
that
I
might
not
have
written
and
then,
as
a
result,
there's
kind
of
this
mess
of
data
assets
that's
created
and
no
one
knows
where
the
data
comes
from.
If
you
find
some
arbitrary
table
somewhere,
it's
very
difficult
to
trace
back
what
computation
or
pipeline
produced
it
and
therefore
navigate
through
the
organization.
A
So
there's
huge
opportunities
here
to
improve
life
in
every
phase
of
the
life
cycle,
and
this
is
how
we
kind
of
conceive
of
this
the
outcomes
that
we
want
to
achieve
in
each
of
these
stages.
So
in
developing
tests
we
want
to
be
able
to
efficiently
and
quickly
build
well-structured,
testable
data
computations,
and
we
believe
the
orchestrator
needs
to
be
designed
with
this
in
mind.
In
order
to
achieve
this
outcome
next,
we
want
to
be
able
to
reliably,
deploy
and
schedule
and
execute
these
computations
and
do
so
in
a
way.
A
Now.
The
rest
of
this
presentation
is
framed
with
a
live
demo.
So
wish
me
luck
and
what
this
live
demo
is
going
to
do.
Is
we're
going
to
simulate
a
bunch
of
teams
working
together
to
achieve
an
outcome
and
in
this
case,
they're
going
to
download
data
from
hacker
news
and
build
the
story
recommendation
engine
and
then
also,
if
we
have
time
a
analytics,
engineering
team
is
going
to
build
a
derived
set
of
tables
for
analytics
dashboards.
A
So
this
is
one
of
these
classic
multi-team
multi-technology
data
applications
and
we're
going
to
focus
on
the
first
stage
written
by
data
engineers
where
we
download
we
download
hacker
news
data.
I
guess
I'm
kowtowing
to
the
or
catering
to
the
conference
here.
I'm
gonna
focus
on
the
spark
component
of
this
and
or
the
the
pipeline,
the
the
part
of
the
data
application
that
uses
spark
and
using
spark
to
compact
that
data
into
parquet
and
load
it
into
bigquery.
A
A
And
that
means
that
we
want
to
push
as
much
development
as
much
error
detection
as
early
as
possible
in
the
life
cycle.
While
acknowledging
that,
because
of
the
nature
of
data
that
some
errors
can
only
be
caught
in
production
such
as
data
quality
tests.
But
the
reason
why
this
is
such
a
massive
opportunity
is
that
at
every
stage
that
you
go
later,
it's
an
order
of
magnitude
more
expensive.
So
this
curb
shifting
represents
in
aggregate
a
huge
order
of
magnitude
improvement
in
developer
productivity.
Therefore,
system
quality.
A
Therefore,
the
general
happiness
and
life
satisfaction
of
the
developers
that
work
in
these
systems,
so
we
believe
this
is
incredibly
important,
so
I've
been
talking
for
a
while.
Let's
actually
talk
about
some
code,
so
this
is
what
hello
world
looks
like
in
dexter:
it's
an
open
source
project.
You
can
pick
install
it,
and
so
you
construct
pipelines,
which
consists
of
these
nodes
of
computation
called
solids.
So
solid,
is
essentially
a
vanilla.
Python
function,
that's
decorated
and
you
can
run
whatever
code
you
want
within
it
and
then
a
pipeline
constructs
the
dependency
graph.
A
So
here
the
hello
world
function,
unification
doesn't
actually
invoke
hello
world.
What
it
does
is
it
constructs
a
single
node
dependency
graph
and
then,
as
you
note,
you
can
actually
just
in
a
lightweight
way,
execute
this
directly
in
process
right
from
where
the
script.
If
we
go
to
more
of
a
real
solid-
and
this
is
the
one
we'll
actually
be
running,
this
is
kind
of
what
something
that
does
real
work
right.
This
is
the
solid
which
is
downloading
the
information
from
hacker
news,
and
I
want
to
point
out
a
couple
things
here.
A
One
is
that
solids
are
functions
they
take
in
inputs
and
they
produce
outputs
and
they're
supposed
to
be
logical
inputs
and
outputs.
This
is
contrasted
with
say,
like
airflow,
which
is
effectively
a
graph
of
taskless.
Pardon
me
parameter
was
tasked
generally.
These
inputs
and
outsides
are
also
optionally
typed,
and
that
typing
information
is
surfaced
in
our
tools,
as
I
mentioned
before,
the
body
of
solids
can
be
arbitrary
python,
and
then,
lastly-
and
this
is
a
really
important
point-
is
that
you'll
notice
there's
no
calls
to
two
csv
or
two
part
k
in
this
solid.
A
You
know
this
is
purely
expressed
in
logical
terms,
and
this
is
just
a
critical
property
to
making
the
framework
sing
in
terms
of
embracing
separation
of
I
o
and
compute
right.
So
we
believe
that
these
should
be
effectively
pure
functions
as
much
as
possible
and
that
the
control
of
where
the
inputs
and
outputs
come
from
and
are
persisted
should
be
controlled
on
a
different
with
a
different
separation
of
concern,
with
a
different
abstraction.
A
So,
let's
actually
hop
to
the
demo
here.
So
the
moment
like,
I
said
the
moment
that
you
structure
your
code
in
that
fashion,
you
get
to
load
it
in
tools
and
use
in
tools,
and
so
this
is
our
web
tool.
So
this
is
literally
on
the
command
line.
I
should
probably
actually
do
this
in
the
demo.
I
just
typed,
dag
it
and
it
loads.
This
there's
no
infrastructure
dependencies
and
you
can
go
right
in
here.
I'm
going
to
navigate.
We
have
this
these
nice
global
search.
A
You
know
we
try
to
make
this
a
consumer
grade
ui.
Actually
you
can
navigate
to
your
download
pipeline
and
here's
that
solid
that
I'd,
written
and
you'll
notice.
That
kind
of
all
the
information
that
I
adorned
the
function
with
is
exposed
in
this
tooling
and
you
can
load
it
without
infrastructure,
which
means
you
can
just
get
clone
a
code
base,
run,
dag
it
and
immediately
get
up
to
speed
about
what's
going
on
it
kind
of
moves,
the
pipelines
into
units
of
documentation,
rather
than
just
rather
than
to
just
kind
of
deploy
units
of
execution.
A
You
can
also
use
this
tool
as
sort
of
a
local
ide
for
dags,
so
we
have
this
thing
called
the
playground.
This
allows
us
to
launch
our
computations.
Imagine
we're
doing
local
development
here,
I'm
going
to
go
here
and
imagine
I
made
a
mistake.
I
am
bad
at
programming,
wow,
I'm
typing
accurately.
Today,
that's
not
always
the
case.
Now
I'm
going
to
launch
this
execution,
and
so
this
is
actually
just
launching
a
process
on
my
laptop
and
you
notice.
We
have
all
these
beautiful
tools
at
our
disposal.
A
So
we
have
this
live
updating
gantt
chart
it's
showing.
What's
going
on,
you'll
see
this
kind
of
in
a
more
realistic
context.
Later
we
have
the
structured
event
log
down
here,
which
is
a
basis
of
a
lot
of
our
debugging
and
monitoring
flows.
So
I
see
there's
an
error
here.
What
I
can
do
is,
I
can
actually
filter
down
to
the
failure
boom.
How
fast
with
that,
then
I
can
view
this
message
and
say:
like
oh
okay,
interesting.
A
This
error
happened
in
line
45
49,
I
flip
back
here
I
fix
it
and
now,
for
example,
I
can
say
I
want
to
restart
this
from
failure.
So
imagine
the
computation
before
it
was
incredibly
heavyweight.
It
saved
some
file.
This
just
allows
you
to
you
know
pick
off
where
you
pick
up
from
where
you
left
off
right,
which
is
incredibly
useful
when
developing
these
things
going
back
to
my
deck
here.
You
know
this
isn't
just
a
local
ide.
A
We
also
really
believe
in
local
testability,
and
you
can
invoke
these
computations
very
similar
to
the
way
you
use
invoke.
No
more
python
functions.
You
have
to
you
know.
In
certain
case,
you
have
to
build
this
context.
Object
with
the
system
context
object,
which
is
flowed
through
the
compute
which
I'll
explain
later,
but
we
can
just
unit
test
the
solids
right
here
and
execute
these
tasks
in
isolation
which
can
be
integrated
there.
A
Yeah
other
focuses
I'm
going
to
give
you
a
couple
of
examples
of
where
we
really
focus
on
early
error
detection,
so
here's
an
example
of
cycle
detection.
So
this
is
from
a
presentation
last
summer
at
the
airflow
summit,
where
they're
explaining
how
to
test
airflow
decks-
and
this
is
the
code
that's
necessary
in
order
to
detect
cycles
in
an
airflow
instance
so
effectively.
A
So
literally
you
just
say
a
certain
pipeline
if
it
was
able
to
be
constructed,
you're
good,
to
go
here's
another
example:
we
have
an
opt-in,
schematize,
config
system
for
parameterizing,
our
computations
and
here's
an
example
where
you
know
we
parameterize
this
thing
and
we
say:
hey,
there's
a
partition
date
and
it
requires
a
string
and
you
notice
on
the
right.
We
wrote
a
test
where
we
fat
fingered
and
we
said
partition
date
x,
and
that
was
bad
well
as
a
result.
A
Having
a
schematized
config
system,
we
can
provide
incredibly
rich
errors
and
we
can
clearly
see
that
hey,
there's
an
unexpected
config
entry,
we're
missing
this
required
one.
We
can
fix
it
immediately
rather
than
having
some.
You
know,
opaque
key,
not
found
error
or
just
deploying
this
production.
Accidentally
with
with
this
error,
we
the
moment
we
implemented
this.
We
found
that
it
really
increased
our
productivity,
even
just
internally
in
our
code
base,
but
testing
has
to
go
beyond
what.
A
I
would
call
this
structural
testing,
which
is
about
the
structure
of
the
graphs
and
the
structure
of
the
config.
You
want
to
be
able
to
test
the
business
logic,
but
the
issue
is
that's
really
difficult
in
data
systems,
because
data
systems
often
rely
on
very
heavyweight
external
dependencies,
so
you
know,
for
example,
I
was
able
to
execute
that
thing
on
my
laptop
because
we
had
what
we
call
a
test
mode
and
it
had
different
resources,
so
I
was
using
spark.
I
launched
it
on
my
local
laptop
and
I
was
persisting.
A
The
intermediate
results
to
the
file
system,
but
when
we're
about
to
deploy
it,
we
need
to
switch
and
we
need
to
run
that
spark
computation
in
emr
and
we
need
to
persist
the
intermediates
to
s3,
but
we
want
to
hold
our
business
logic
constant.
So
we
have
this
resources
system
and
a
set
of
resources
indicates
it's
real,
the
the
the
business
logic's
relationship
with
kind
of
its
external
computational
environment.
A
A
Okay,
I've
talked
a
bunch
about
the
programming
model
and
a
ton
about
the
apis.
Now,
let's
actually
deploy
and
execute,
I'm
gonna
I'm
going
to
I'm
going
to
give
this
a
surface
level
explanation,
given
that
our
limited
time,
but
I
want
to
go
over
the
structure
of
like
what
this
looks
like
when
you
actually
deploy
it
to
a
production
cluster,
let's
say
kubernetes
or
something
so
you
we
have
a
couple
long-running
services,
one
is
our
run
scheduler.
A
So
it's
a
long-running
service
whose
job
in
life
is
to
schedule
runs,
and
then
we
have
a
web
server
that
tool.
We
call
dagget.
That's
also
our
deployed
web
server,
and
the
critical
thing
to
note
here
is
that
the
daemon
and
daggett
interact
with
user-defined
code,
the
code
that
you
write
over
an
api
layer
that
crosses
a
process
boundary,
and
this
is
what
makes
this
such
an
operationally
reliable
system,
meaning
that
if
you
push
up
bad
code,
let's
say
that
for
some
reason
totally
blew
up
it
wouldn't
bring
down
the
whole
cluster.
A
A
It's
kind
of
structured
default
tolerance.
So
if
it
goes
down,
it
won't
miss
any
scheduled
runs,
and
you
know,
I
think
the
interesting
thing
for
those
who
are
familiar
with
airflow
is
that
we
actually
manage
sensors
in
the
run
scheduler.
So
we
consider
a
sensor
event
based
schedule,
as
opposed
to
a
long-running
task,
and
we
think
this
is
just
a
much
better
way
to
model
that
concept
and
then,
once
the
daemon
launches
a
run,
we
have
the
architect
system
to
be
very
friendly
to
the
world
of
infinitely
elastic
compute.
A
So
we
allocate
we
generally
allocate
a
federal
computational
resource,
such
as
a
process
or
a
case
pod
and
then
per
run,
and
then
its
responsibilities
to
to
manage
task
scheduling.
So
this
distributes
task
scheduling
across
many
more
computational
resources,
which
generally
leads
to
system
scalability
and
is
very
friendly
to
public
cloud
architectures.
A
You
know
it's
a
very
plugable
system,
so
I've
been
talking
about
kubernetes
because
we
have
the
out
of
box
production
grade
kubernetes
deployment,
it's
actually
pretty
straightforward
to
get
up
and
running,
but
you
can
run
it
on
any
sort
of
infrastructure.
It's
specifically
designed
to
be
infrastructure
agnostic,
as
opposed
to
part
of
me
closing
a
window
here.
It's
specifically
designed
to
be
infrastructure
agnostic,
as
opposed
to
be
saying
vertically
integrated
with
kubernetes.
A
So
what
does
it
look
like
to
actually
interact
with
this
thing
in
prod?
So
I'm
going
to
close
this
window
and
go
to
this
demo
site,
but
this
is
actually
running
out
of
case
cluster
in
aws
and
you
can
use
very
similar
tools,
so,
let's
navigate
to
that
same
download
pipeline.
But
in
this
case
this
thing
is
deployed
and
notice
that
we're
executing
in
production
mode-
and
I
can
still
launch
this
with
ad
hoc
computation.
A
You
know
it's
also
running
on
a
schedule.
Actually
I
actually
probably
should
have
turned
that
off
before
the
demo,
but
that's
okay
won't
go
on
so
here
you
can
see
it's
actually
running
on
a
schedule
as
well.
We
have
this
nice
scheduling
api,
but
if
we
go
back
here,
I've
launched
it
with
ad
hoc
compute.
A
So
if
you
recall
way
back
at
the
beginning
of
this
talk,
I
explained
how
we're
going
to
have
downstream
data
science
teams
consuming
the
data
produced
by
the
data
engineering
team
and
it's
going
to
fetch
data
out
of
bigquery
and
build
a
recommendation
model.
So
you
know
just
stepping
back
for
a
second,
you
know
what's
interesting
about
these
data
platforms,
is
that
it's
multi-role
and
multi-tool,
so
there's
multiple
types
of
people
that
interact
with
it,
so
a
mature
data
platform
must
think
across
roles.
A
So
for
the
beginning
of
this
talk,
we
kind
of
explain
how
a
data,
engineering,
team
or
data
platform
team
could
build
the
front
end
of
this
pipeline
end-to-end
right.
But
we
really
want
that
team
to
also
abstract
away
all
the
infrastructure,
concerns
away
from
say,
data
science
and
analytics
engineering,
because
we
want
them
to
focus
on
their
business
logic,
and
but
we
still
want
data
science
to
own.
The
devon
test.
A
As
self-serve
their
ops,
so
this
is
kind
of
the
grid.
A
mature
data
platform
needs
to
think
about,
so
we're
going
to
show
the
dev
and
test
experience
for
a
data
scientist
and
their
monitor,
observe
experience.
So
this
is
how
you
this
is
a
pipeline
we're
going
to
demonstrate
here.
This
is
actually
how
you
build
a
pipeline
in
dexter,
so
it's
this
kind
of
high
level
dsl,
where
you
can
pass
data
from
functions.
A
A
You're,
a
python
data
scientist-
this
looks
probably
familiar.
These
are
scikit-learn
abstractions.
It
looks
like
vanilla,
python
code
right,
the
only
dagsterism
here-
and
this
is
what
this
is.
What
speaks
to
the
observer
monterey
is
this
thing
called
the
asset
materialization,
so
this
is
the
programmer
in
forming
the
system
that
we
have
created
or
about
to
create
an
asset
that
will
outline
the
scope
of
the
computation
and,
as
you
see
here,
it
gives
various
properties
about
it
which
are
going
to
be
very
useful,
the
system.
A
So
what
is
an
asset?
An
asset
is
any
entity
that
outlives
the
scope
of
the
computation.
So
that's
like
a
data
warehouse
table
as
a
parquet
file
on
a
data
lake,
a
pickled
model-
that's
been
stashed,
god
knows
where,
but
the
reason
why
we
think
it's
so
important
for
an
orchestrator
to
be
asset
aware,
is
that
your
stakeholders
do
not
care
about
your
pipelines.
I
hate
to
break
it
to
you.
They
don't
care.
A
So,
let's
go
back
here
and
I'm
going
to
go
to
the
story
recommender.
So
this
is
that
pipeline
that
we
constructed
here
and
if
you
notice
here,
there's
already
a
run
running
how
that
happened
actually
is.
If
we
go
here,
there's
a
sensor
so
story,
recommender
and
hacker
table
news.
Update
and
you'll
see
that
this
is
this
live
running
sensor
that
pulls
and
and
detects.
Actually,
when
one
of
these
asset
keys
in
our
asset,
catalog
gets
updated,
and
here
it
got
up.
You
know,
fired
you
know
two
minutes
ago
and
it
actually
worked.
A
A
A
A
But
the
other
thing
you
can
do
is
that
imagine
you
know
nothing
about
a
pipeline
but
say
you
found
some
table
somewhere.
That
looks
wrong
and
say
it's
called
comment
stories.
Well,
you
can
actually
just
go
in
here
and
search,
look
for
comment
stories
and
boom.
You
can
open
it
right
here
and
navigate
right
to
it
and
see
what's
been
going
on.
Okay
last
was
touch
653.
A
If
we
go
back
here,
you
know
I
mentioned
the
sensors
and
we
think
we're
going
to
invest
heavily
in
this
area,
because
we
think
sensors,
combined
with
asset
awareness,
is
the
way
that
you
structure
loosely
structured,
loose
dependencies
between
teams.
You
know
so
imagine
that
you
have
team
one.
That's
what
we
just
demonstrate
write
some
asset
key
called
foo,
and
then
the
sensor
monitors
that
asset
key
and
decides
to
kick
off
the
next
run,
and
even
when
we
were
developing
this
internally,
you
know
the
user,
the
person,
the
user.
A
My
teammate,
who
developed
the
data
science
pipeline
was
like.
I
don't
even
know
anything
about
the
python.
It
was
incredible.
We
just
decided
on
an
asset
key
and
where
that
lived,
and
then
I
was
off
to
the
races,
I'm
running
a
little
short
on
time,
so
I'm
going
to
skip
the
last
part
of
the
demo,
but
I
want
to
briefly
talk
about
analytics
engineering
and
dbt.
A
A
You
know:
dbt
graphs
are
effectively
dags
of
functions
that
consume
and
produce
data
and
they're
peer
functions
because
they're
just
select
statements
for
those
of
you
familiar
with
dbt,
and
so
we
really
visualize
this
as
if
you're,
enabling
a
dbt
workflow,
integrating
with
daxter
you're,
keeping
that
dev
and
test
life
cycle
that
analytics
engineers
know
and
love.
But
you
use
dagster
to
orchestrate
dbt
computations
with
computations,
which
are
not
in
sql,
for
example,
spark
computations,
although
spark
actually
can
technically
use
spark
sql,
but
it
typically
doesn't
or
dbt
can
use
spark
sql.
A
A
A
So
thanks
for
listening
we're
an
open
source
project
so
we're
on
github
the
yeah,
you
can
go
and
navigate
star
us,
come
to
our
slack
very
active
and
friendly
slack
and
we've
been
working
really
really
hard
on
our
docs
site,
and
this
is
totally
open
source.
So
you
could
you
know,
right
after
this
presentation,
go
pip,
install
and
go
nuts,
and
with
that
q
a
and
we're
apparently
might
be
kicked
out
of
this
in
a
couple
minutes.
But
all
I
can
take
over
thanks.
B
Nick
yeah,
the
speakers
have
a
chat
with
our
operator
too,
so
he's
giving
us
the
warning
that
we
have
two
minutes
left.
So
we
do
have
a
couple
questions.
Maybe
we
can
get
to
one,
maybe
two
really
quickly
so
nick
first
question:
maybe
last,
do
you
see
dagster
being
used
in
a
cacd
cycle?
If
so,
what
would
be
a
typical
use
case?.