►
From YouTube: Emilie and Taylor discuss DataOps
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
the
goal
for
this
conversation
today
is
to
talk
a
little
bit
about
data
ops
and
there's
a
lot
of
conversations
out
there
around
what
data
house
is
and
I'd
love
to
get
a
sense
of
like
what
do
you
think
it
is?
What
do
you
think
it
isn't
what
it's
like,
maybe
being
put
on
there,
this
umbrella?
That
is
your
relevant
and
then
how
to
use,
get
lab.
4
data,
ops,
yeah,.
B
So
I
recently
gave
a
talk
about
this
and
was
doing
some
sleuthing
on
Wikipedia
and
all
these
pages
and
in
general
I
think
data
ops
is
really
about
driving
valley.
It's
it's
driving
value
to
it,
to
a
customer
decreasing
cycle
time
on
analytics
and
implementing
like
processes
and
methodologies.
Kind
of
with
that
guiding
principle
in
mind.
A
B
A
B
One
is
it's:
it's
managing
state,
essentially,
so
DevOps
does
interact
with
data
there's,
clearly
a
database
backing
most
applications,
but
the
volumes
that
we're
talking
about
are
generally
reasonable
and
the
application
can
be
developed
without
too
much
of
a
sense
of
of
the
underlying
data,
whereas
data
Ops
is
like
is
all
about
the
data.
It's
all
about
the
current
past,
the
future
state
of
the
data.
The
volumes
can
be
tremendous
and
it's
just
like
a
different
level
of
complexity
and
challenge.
I.
Think
that's
where
I
kind
of
see
the
dividing
line
a
bit
I.
A
A
B
Fair
yeah,
it's
it
in
the
narrow
sense.
It's
like
business
intelligence,
it's
it's
delivering
a
dashboard,
but
there
is
a
component
of
it
that
is
taking
that
border
and
some
additional
data
and
applying
additional
insight
like
in
different
methodologies
or
whatever
your
expertise,
to
tease
out
information.
So
there's
a
bit
of
art
to
it.
Maybe
that's
not
encapsulated
in
a
technical
piece.
It's
just
like
staring
at
the
data
and
coming
up
with
reasonable
hypotheses.
I
wonder:
do
you
know
there's
like
good?
Is
that.
A
B
A
Which
one
so
looking
at
that
figure,
eight,
which
I
think
it's
like
there
are
some
stages
that
are
more
obviously
suited
to
draw
parallels
right
plan
create
verify,
are
like
kinda,
I
would
say
the
the
first,
the
easiest
stages
to
a
doctor.
Eight
yeah!
B
So
I'm
looking
so
the
ones
you
really
didn't
mention
package
release,
configure,
monitor
package
and
release
is
a
little
different,
but
I
can
come
up
with
some
parallel
piece
where
there's
like.
Maybe
you
are
on
a
data
team
or
part
of
a
larger
organization
that
is
responsible
for
generating
some
sort
of
data
output?
Managing
that
like
we
don't
do
that
currently
I
think,
but
you
can
say,
like
hey,
you
know
we're
responsible
for
putting
out
a
daily
data
dump
of
this
data
set.
How
do
you
package
that?
How
do
you
version
it?
B
How
do
you
make
it
available
to
people
like
I?
Think?
That's
absolutely
a
concern,
just
with
the
extra
concern
of
if
this
data
set
is
600.
You
know
gigabytes.
How
do
you?
How
do
you
manage
that
configure
and
monitor
I'm
thinking
more
I?
Think
configures
is,
as
I
understand,
it's
applicable
because
it's
like
you
have
to
configure
your
data
environment
around
like
permissioning
size
like
I.
Do
that,
instead
of
like
all
the
time
worried
about
warehouse
sizes
and
who
has
access
to
what
so
this
is
a
very
random
out.
A
Thinking
about
package
I
would
say
that
does
like
the
snowplow
packet
or
snowflake
package
that
we
have
the
snowflake
spending
package
like
that
is
a
DBT
package
that
we
have
to
release
as
if
it
were
software
right
like
it,
has
a
cadence
in
it
an
iteration
that
makes
sense
to
me
yeah
well,
configured,
okay,
so
package
release
configure
what
about
monitoring
yeah.
B
Monitor
is
something
I,
don't
have
a
ton
of
experience
with
in
the
data
world
and
we're
actually
talking
about
that
actively.
So,
like
snowflake,
has
built-in
monitoring
of
all
queries,
but
you
know
we
want
to
be
alerted.
If
somebody
it's
clearing,
you
know
some
sensitive
data,
yeah,
there's
monitoring
of
the
orchestration
piece
like
absolutely
you
need
to
it's
kind
of
tied
in
with
verify,
but
monitor
is
more
about.
Like
hey
you've
set
up
this
whole
data
pipeline.
Is
it
working?
Is
it
failing?
What
do
you
do
when
a
job
fails?
A
A
A
B
I
mean
it's
today:
it's
like
you
want
to
protect
your
customer
user
application
data.
The
code
can
only
because
the
code
can
only
do
so
much
I
think
we
live
that
by,
like
our
entire
analytic
stack
is
open
source
because
it's
the
the
proprietary,
valuable
information
isn't
that
it's
the
actual
data
behind
the
scenes,
yeah.
B
B
So
from
a
technical
perspective,
I
think
it's
just
it's
about
starting
with
version
control,
and
then
you
can
build
things
up
from
there
if
you're,
not
if
you
have
sequel
scripts,
that
you're
running
manually
that
are
and
random
files
like
put
that
into
some
sort
of
version
control,
so
you
can
understand
the
you
know
the
history
and
have
that
that
control
over
it
and
then
from
there
you
can
build
into
automated
job
separate
environment.
So
kind
of
this
whole
stack
and
you
know,
building
into
testing
which
is
kind
of
our
DBT
comes
in.
B
So
that's
that's
one
area
to
start.
If
you
are
focused
on
kind
of
like
the
technical
thing,
I
think
there's
a
higher
level
conversation
to
be
had
about
data
ops
within
the
organization.
What
does
that
actually
look
like
and
I
think
that
has
to
be
driven
at
a
you
know
at
yes,
Anna
I,
see
level
but
like
at
the
the
senior
manager
director
c-suite
level
like
I.
Think
D
lab
is
a
really
cool
place
because
we
kind
of
have
that
DevOps.
We
do
have
that
DevOps
culture
built
in,
but
you've
also
on
the
data
side.
B
B
It
starts
with
a
lot
of
conversations
with
somebody
who
cares
a
lot
about
it
and
knows
the
end
state
that
they
want
to
get
to
and
to
find
out
where
different
members
of
your
organization
are,
because
if
your
CEO
doesn't
believe
and
kind
of
what
a
strong
data
team
can
do,
yeah,
that's
gonna
be
really
hard.
So.
B
A
lot
really
good
data
teams
it
so,
let's
maybe
separate
a
little
bit
between
like
business
intelligence
versus
like
product
intelligence.
So,
like
strong
business
intelligence,
you
can
have
an
excellent
understanding
of
what
the
organization
is
doing,
because
a
lot
like
a
lot
of
these
SAS
tools
that
we
use.
If
you
think
about
it,
it's
all
about
kind
of
monitoring
and
surveillance
of
different
parts
of
the
organization.
B
It's
really
that
data
integration
piece
that
David
seems
our
curve
should
be
really
good
at.
So
that's
on,
like
the
business
intelligence
side,
I
think
I,
look
for
the
product
intelligence
side
is
being
able
to
understand
what
the
pain
points
are
and
figure
out
and
test
better
paths
to
making
them
product
better.
So,
like
data
is
the
data
that's
generated
from
a
product
is
like
the
evolutionary
driver
of
growth
and
change
in
the
product,
and,
if
you,
if
you
don't
have
that
inside,
it's
all
I
granted
mutations.
A
That
makes
a
lot
of
sense
to
me.
Do
you
know
here,
I'm
gonna,
send
you
this
link
real
fast
I
know:
we've
talked
about
this
article
before
so.
It's
not
gonna
come
as
a
surprise.
This
data
science
hierarchy
of
needs
chart
and
the
foundation
here
is
collect
when
I
think
about
data
ops
as
I
see
it
in
my
head,
move
and
store,
explore
and
transform,
and
aggravate
and
label,
and
probably
even
like,
learn
an
optimized
and
up
like
that
part
I
see
how
it
fits
into
data.
A
B
Think
it
should
be
a
part
of
it
I
this
like
to
me
this
day
of
science
hierarchy
of
needs.
Chart
is
it's
like
a
small
slice
of
data
management
and
it's
with
a
specific
target
in
mind
of
implementing
predictive
modeling
kind
of
at
the
peak
yeah,
because
what
you
don't
have
in
here
or
any
of
the
connections
between
kind
of
the
organization
and
does
they
really
talk
about
like
it'll
talk
about
like
documentation
so
kind
of
all
the
like
all
the
people
things
this
is
like.
B
B
Part
of
the
like
I
would
argue
part
of
the
data
ops
kind
of
iteration
is
that
the
feedback
mechanism
that
then
says
hey
we've
got
testing
and
monitoring
in
place
to
help
you
improve
data
quality
upstream
to
improve
the
collection
which
then
improves
kind
of
the
whole
downstream
part
of
it.
This
is
a
nice
thing
about
a
term
like
data
ops.
B
Is
it
can
kind
of
be
whatever
you
want
it
to
be,
so
I
can
make
an
argument
either
way,
but
I
tend
to
think
that
most
of
like
a
people
in
an
organization
are
generating
a
lot
of
data,
and
if
you
want
insight
into
that
it,
it
becomes
part
of
this
data,
ops
philosophy
and
how
you
think
about
how
that
data
is
generated,
managed.
You
know,
stored,
analyzed,
reviewed.
A
B
A
Clocking
in
and
out
right,
it's
not
even
those
of
us
who
sit
at
our
computers
all
day
like
if
you
clocking
in
at
and
out
at
any
job
in
the
world
right,
that's
generating
data
yeah,
so
I
totally
see
that
you
know
you
and
I
have
talked
about
this.
A
little
bit
that
I
have
this
like
three
tiered
framework
for
analyses
in
my
head
and
I
recently
renamed
it
with
the
help
of
a
dear
friend,
Claire
reporting,
whoops,
reporting,
insights,
predictions,
okay
and
so
I'm
curious,
like
there
are
lots
of
words.
A
B
B
But
it's
then,
when
you
want
to
go
back
tweak
some
parameters
run
it
again,
six
months
down
the
line,
can
you
do
that?
Mm-Hmm?
That's
where
I
think
the
it's
the
yeah
so
by
may
be
part
of
updating.
This
definition
is
like
it's,
the
repeatability
of
your
analyses
of
your
work,
and
some
of
it
clearly
doesn't
need
to
be
repeated,
but
of
the
things
that
are
and
there's
there's,
certainly
components
of
like
these
fancy
predictive
things.
If
you
would,
we
would
want
to
reuse,
yeah
well,.
B
A
So
I
think
of
scalability.
First
in,
like
a
people
function
way
like.
If
your
work
is
repeatable,
you
need
less
people
to
do
the
work
that
needs
to
get
done,
whereas
if
you're
running
at
hoc
work
all
the
time,
then
you
need
more
people
to
do
the
same
amount
of
work
and
I
would
make
the
case
that
scalability
of
people
and
scalability
of
like
can
your
code.
Little
terabytes
of
data
is
a
different
like
you
can
solve
for
one
without
solving
for
the
other
yeah.
B
A
B
C
A
Yeah,
like
if
someone
says
okay
I
use,
get
lab
in
my
work.
What
I
use
get
my
software
team
I'm
a
start-up
of
one?
My
software
team
is
using
get
lab.
My
I
know
my
data
team
should
be
using
data.
Ops
like
how
do
do
not.
Let's
get
low.
B
A
I
mean
that,
like
melt,
no
can
go
on
top
of
like
a
version.
Control
NCI
system
like
melt
on
I
was
like
a
ship
with
fridge
in
control
right.
B
And
that's
actually,
a
distinction
like
I
want
to
talk
about
that
nailh
more
about
is
like
how
did
how
do
you
see
these
two
working
together?
Is
it
gonna
be
an
integrated
product
because
I
don't
want
to
have
and
I
said
this
from
the
beginning:
I
want
to
use
both
your
lab
and
melt
on.
Oh
yeah,
I
love.
All
the
parts
like
the
plan
create
manage
all
that
fun
stuff.
B
Yeah,
so
if
you
don't,
if,
like
none
of
the
product,
isn't
the
right
fit
and
kind
of
have
your
own
tools?
I
still
do
think
it's
like
I'm,
very
biased,
obviously,
but
like
it
let
the
product
is
like.
Okay
start
start
centering
your
work
like
as
an
analyst
or
an
engineer
around
issues
and
start
implementing
version,
control
and
start
thinking
like
I
know
when
you
came
on
like
we
were
thinking
like
how
can
we
route
everything
through
a
merge
request,
because
it's
like
the
ultimate
change
control?
A
B
Everybody
needs
to
understand
the
high-level
concepts
of
version
control.
I
would
not
expect
everyone
to
understand
the
underlying
data
structure
of
git
and
how
it's
a
dag
and
do
all
these
crazy,
I
don't
even
understand
like
every
time.
I
do
anything
besides,
you
know
basic
stuff
and
kid
I'll.
Look
it
up,
but
it's
such
a
powerful
tool
and
a
great
way
of
making
those
changes
in
a
controlled
manner
that
you
want
people.
Thinking
about
that,
like
you
want
people
thinking
about
that
history
and
that
state
of
things
like
or
we
lose
information.
B
If
we
do
something
with
this
I,
don't
think
everything
necessarily
needs
to
be
version.
Control,
like
some
things,
do
I
think
have
a
right
to
be
forgotten,
like
that's
old
GPR
thing
everything
but
like
oh
yeah,
birth
control,
the
high
level
now
technical
level,
I
think
it
has
power
for
everybody.
Honestly,
okay,.
A
A
B
B
So
so,
there's
a
couple
of
things
well,
one
I
would
think
is
like
take
a
step
back
and
think
about
what
you're
trying
to
do
with
your
data
team
and
understand
kind
of
the
Charter.
And
what's
what's
the
state
that
you
kind
of
want
to
get
to
or
like
the
next
kind
of
incremental
level,
with
your
data
team.
B
The
second
part
is
like
realizing:
you're
gonna
have
to
put
some
investment
into
that.
It's
either
going
to
be
some
money
or
some
people
investment.
But
if
you
want
to
get
your
data
out
of
Salesforce,
you
can
either
pay
somebody
to
write
a
custom
extractor
or
you
can
pay
standard
five
training
you're
going
to
need
a
data
warehouse.
You
can
start
simply.
B
Where
you
can
document
it,
you
know,
even
if
it's
internal
or
like
just
for
you,
have
a
handbook
get
into
that
habit.
I
think
it's
about
being
operationally
mature.
I
say
that
to
a
lot
of
people's
like
it,
lab
is
very
operationally
mature
because
we
have
to
be
because
we're
all
remote,
we
have
our
handbook
and
then,
from
kind
of
once
you
have
that
it's
then
start
thinking
about.
How
can
I
do
things
in
the
context
of
a
merge
request?
B
How
can
I
control
the
change
on
this
better,
whether
that's
hey
I
needed
to
be
taking
you
know,
snapshots
with
DBT
or
I
need
to
put
this
into
version.
Control
to
you
know,
make
more
requests
and
then,
unlike
the
technical
side,
I
think
things
kind
of
fall
out
from
there.
You
start
looking
into
like
automated
jobs,
separate
environments,
automated
testing
kind
of
built-in
documentation,
which
you
know
and
help
with
that
in
DBT.
B
You
can
help
with
that,
but
then
it's
also
scaling
out
the
operational
and
data-driven
side
of
the
organization,
with
good
documentation,
making
sure
everyone
can
contribute
that
it's
clear
where
things
are,
as
you
know,
to
the
best
of
your
ability
that
you
have
communicated.
What's
the
cue?
What's,
how
do
you
get
things
done
with
the
data
team?
Do
I
make
an
issue?
Do
I
do
what
I
think?
That's
that's!
B
B
Yeah,
like
arguably,
if
I
were
to
go
to
an
organization
as
a
single
data
person
like
you,
don't
you
hire
somebody
to
bring
the
dev
team,
you
don't
bring
in
the
technology
necessarily
to
get
started,
and
so
that
person,
what
are
they
going
to
do
like
yeah?