►
From YouTube: Simon + Denny AUA: Data Mesh (2022-10-18)
Description
For this session, let’s talk about Data Mesh! Simon’s been getting a lot of questions from his recent video post “Behind the Hype: Why Data Mesh is not right for you.” Do you want to ask questions to these two data nerds around the fundamentals behind the hype? Well, wait no more! Come with your questions, we (hopefully) will have answers!
Quick links:
https://delta.io/
https://go.delta.io/slack
https://github.com/delta-io/delta/releases
https://groups.google.com/g/delta-users
A
We
are
starting
off
the
next
session
of
Simon
and
Denny.
Ask
us
anything.
Today's
theme
is
data
mesh,
we're
gonna,
wait
a
few
minutes
for
people
to
trickle
in
from
all
three
locations
of
LinkedIn
plus
YouTube.
Hopefully,
if
that
works
today
and
of
course,
the
latest
Foundation
Zoom,
so
just
give
us
a
few
minutes.
If
you
want
to
chime
in
and
into
the
chat
and
tell
us
where
you're
based
out
of
Simon,
you
are
based
out
of
I.
A
B
I'm
gonna
go
ahead
and
just
remind
people
watching
we
don't
have
many
questions
in
yet.
So,
if
you
want
to
know,
if
you've
got
any
burning
questions,
then
please
put
them
in
either
in
the
chat
here
in
the
chat
in
YouTube
in
the
chatting
LinkedIn
anywhere.
You
are
watching
feel
free
to
ping
some
questions
and
we'll
try
and
just
pick
up
as
many
as
we
can
generally
on
the
theme
of
data
pretty
much
today,
which
could
be
what
is
it
could
be?
Why
is
it
could
be?
How
do
you
achieve
it
could
be?
A
Awesome
and
it
looks
like
we
are
good
to
go.
We
are
Live
on
YouTube,
we
are
live
on
LinkedIn,
so
for
all
the
folks
that
are
chiming
in.
Let
us
know
where
you're
based
out
of
hey.
We
got
high
Vinnie
from
Ireland.
You
can
welcome
aboard
for
the
folks
here
in
Zoom
the
links
Foundation
Zoom
cool,
welcome
on
board
and
also
for
the
looks
from
YouTube
Welcome
Aboard,
all
right,
perfect.
Well.
B
Yeah
I
mean
I
I
will
I
will
hold
my
hand
up
and
thoroughly
apologize
to
the
data
mesh
Community
for
the
the
perhaps
harsh
words
I
might
have
put
it
in
my
rats.
Yeah.
No,
perhaps
wasn't
wasn't
the
kindest
to
the
movement.
Basically,
we
had
big
data
London
over
in
the
UK
recently
and
there's
a
massive
massive
explosion
of
people
going
yes,
mesh
is
amazing.
B
I
want
to
make
sure
we'll
talk
about
what
meshes
we'll
talk
about.
My
rent
specifically
isn't
about
data
mesh.
It's
not
saying
data
mesh
is
a
concept.
Is
flawed
I'm
just
annoyed
that
there
are
so
many
people
currently
out
in
the
world
trying
to
sell
the
whole
of
it,
everything
that
is
dynamesh
two
organizations
when
they're
just
not
ready
for
it,
because
it's
it's
kind
of
a
big
thing.
A
So
so
as
much
as
we
joke,
or
tease
about
the
fact
that
there's
a
rant
going
back
and
forth
the
reality
is
no
I,
think
you're
exactly
right.
There
is
a
complexity
that
people
forget
about
when
it
comes
to
how
to
build
data
meshes
correctly
and
so
yeah.
Why
don't
we
start
with
the
definitions?
First,
and
then
we
can
go
from
there
because,
like
I,
don't
actually
think
you
need
to
apologize
to
anybody
in
the
dimension
Community,
because
it's
like
you
know
you
you
just
being
you
right.
A
A
No,
no
I
actually
think
procurement
and
Logistics
is
actually
freaking
amazing
by
the
way.
So,
actually
before
we
started
the
session,
I
was
actually
talking
about.
If
you
there's
a
really
good
YouTuber
named
p-run
peroon
excuse
me
p-e-r-u-n.
He
actually
talks
about
the
logistics
and
procurement
processes
for,
for
example,
the
Ukrainian
War,
which
is
actually
really
really
interesting
by
the
way.
So
so,
no
quite
the
opposite.
A
Procurement
is
actually
a
really
interesting
topic,
but
I
will
not
do
it
because
I'm
not
as
talented
as
him
when
it
comes
to
it,
even
though
I
I'm
a
bit
of
a
nerd
on
that
topic,
but
back
to
the
point
in
hand
datamesh
by
the
way
we
do
already
have
some
questions
kicking
in,
but
let's
provide
some
context
first
before
we
go
ahead
and
start
answering
questions.
Okay,.
B
I
mean
so
probably
just
easier
to
cover
you
know.
So
the
introductory
parts
of
everything
you
read
about
the
four
pillars
right,
the
four,
the
four
Central
tenets
of
data
mesh.
In
a
nutshell,
it's
it's.
The
whole
idea
of
going
things
are
too
centralized.
Currently,
data
Engineers
become
too
specialized.
It's
two.
B
It's
two
axes,
everything's
going
through
a
tight
tunnel
of
where
we
should
be
getting
data
from
how
we
should
be
getting
data
from
a
variety
of
operational
sources
through
to
the
analytics
users
who
need
to
use
it
and
saying
it's
time
for
a
change.
We
need
to
shake
things
up
and
the
whole
thing
is
basically
saying:
the
entire
organization
should
be
restructured
around
this
idea
of
decentralized
data
ownership.
So
you've
got
these
four
main
things,
so
one
decentralized
data
ownership
saying
actually
it's
not
a
central
team.
There
isn't
a
data
team.
B
We've
been
trying
desperately
from
data
governance
for
years
to
say:
can
you
just
please
take
responsibility
for
the
data
you're,
giving
us
over
and
over
again
and
that's
what
data
governance
is
about
data
stewardships
about
pushing
measuring
data
quality,
but
then
putting
accountability
for
the
quality
of
data
back
on
the
people
producing
it.
So
it's
a
spin
on
that,
but
organizing
and
treating
it
seriously
and
taking
accountability
for
who
owns
the
actual
data
is
a
product
the
next
tense
and
that's
the
seriousness
of
data
right,
saying
well.
B
Actually,
data
is
so
important,
treat
it
as
the
end
product
of
the
out.
The
output
of
your
labor
is
then
treat
it
as
of
something
that
has
intrinsic
value,
make
sure
it's
testable
make
sure
it
is
valuable
quiz
quality.
It's
if
you're
going
to
make
sure
the
software
you
build
is
good
quality
software.
You
should
make
sure
that
the
data
produced
by
that
is
of
equivalent
to
value
or
even
in
greater
value
than
the
the
software
that
produces
it.
So
it's
about
changing
the
mindset
about
data
data,
not
a
side
effect.
B
They
did
not
a
thing
that
just
trickles
out
the
side
of
the
application
you've
built
data
is
the
golden
thing.
That's
actually
coming
out
and
treating
it
with.
The
due
respecter
needs
absolutely
makes
a
lot
of
sense,
self-serve
data
infrastructure
as
a
platform,
and
this
is
kind
of
a
hard
one,
and
this
is
I,
think
the
one
that
so
many
Tech
vendors
have
jumped
on
going
hey
what
you
you
want.
B
You
want
technology
that
allows
you
to
share
data
great
Implement,
our
tool,
and
you
have
a
magical
mesh
and
absolutely
one
of
the
central
things
is
to
make
it
really
easy
for
people
to
share
data.
That's
the
fundamental
thing:
if
it
becomes
easy
and
you
don't
need
massive
specialist
skills,
you
don't
need
serious
data.
Engineering
I've
been
doing
data
engineering
for
15
years,
so
only
I
can
share
data.
Make
it
really
easy
for
people
to
spin
up
copies
of
this
kind
of
real
easy
self-serve
day
instruction
and
share
it.
B
If
you
have
all
those
things
in,
it
enables
the
mesh,
but
it's
not
the
mesh
in
itself
and
then,
like
Federated,
governments
are
from
actually
managing
how
you
do
that
who's
actually
Computing
it.
How
much
are
you
paying
for
that
stuff?
How?
How
much
are
you
actually
spending
getting
all
this
stuff
working?
B
So
there's
like
the
balance
of
those
four
things
is
a
huge
expenditure
of
work
and
organizational
change
and
people.
It's
about
changing
the
structure
of
teams,
it's
about
changing
the
skills
and
expectations
and
accountability
of
teams,
and
then,
when
you've
reorganized
your
entire
structure,
so
that
every
team
is
focused
on
the
data
they
produce.
B
Then
you
can
enable
it
with
technology
to
actually
then
stand
up
something
like
a
mesh
and
yeah
the
rant's
all
about
people
going
and
going
right.
You
need
to
build
a
mesh,
here's
a
technology
and
it's
not
taking
account
of
the
rest
amount
of
organizational
change
that
we
need
to
happen
to
do
that,
but
also
the
technology
maturity.
B
B
You
know,
you're
still
going
to
have
to
have
a
centralized
team
who
gets
the
other
data
saying
we
have
this
Nirvana
of
distributed
data
nodes
that
stood
up
in
nice
things
and
they're,
easily
accessible
by
apis
and
they're
enshriners
products,
but
actually
there's
90
of
the
company's
data
still
go
through
the
centralized
team
doesn't
really
affect
you.
It
doesn't
really
kind
of
tick
that
problem
right.
B
So
yeah,
that's
that's
what
we're
talking
about
we're
talking
about
this!
This
big
shift
towards
decentralization
a
shift
towards
the
how
differently
we
think
about
data
and
thinking
of
it
as
a
product,
but
also
thinking
about
there's
a
bit
of
a
gold
rush.
After
many
many
companies
being
told
they
have
to
have
a
mesh
and
so
they're
jumping
on
it,
even
if
they're
not
culturally
ready
for
it
right.
A
So,
to
add
to
your
point
and
I'm,
going
to
take
a
more
of
a
software
engineering
standpoint,
it's
just
like
when
we
back
in
the
Arts.
We
made
that
shift
to
SOA,
sorry
or
architectures.
Where
and
you
know
the
the
I.
Don't
have
the
diagram
handy
and
we
don't
do
diagrams
here
anyways,
but
right.
There's
that
there's
that
diagram
of,
if
you
look
at
all
these
services
within
Amazon
and
how
they
actually
interact
with
each
other.
A
Basically,
it's
a
gigantic
graph
of
nodes,
interacting
with
each
other
and
in
the
past,
like
a
software
engineering
architect
that
person
he
or
she
would
be
able
to
go
ahead
and
tell
you
what
the
entire
architecture
was
from
end
to
end.
And
when
you
looked
at
the
Amazon
Services
we're
talking
about
tens
of
thousands
of
services
interacting
with
each
other.
A
It
was
impossible
for
one
person
to
know
how
every
single
one
of
these
Services
worked,
and
so
the
whole
purpose
was
to
go
ahead
and
say:
okay,
you're
responsible
for
the
input,
there's
a
contract
for
what
the
output
is,
and
so
this
is
sort
of
the
same
concept.
When
it
came
to
this
idea
of
data
mesh,
it's
like
okay,
there,
you,
you
have
a
contract
for
what
the
input
is.
You
have
a
contract
for
what
the
output
is.
A
Each
team
is
now
then
responsible
for
that
product
service
of
data
that
they're
producing
and
ensuring
its
quality.
If
exactly
to
your
point,
just
like
during
the
Gold
Rush
of
everybody's,
you
know
it's
service,
service,
everything's
service
and,
of
course,
now
we're
into
serverless
for
that
matter.
But
that's
besides
the
point
we'll
wait
for
that
debate
on
a
later
day.
A
The
the
context
is
that
all
sudden
we
we're
having
people
that
did
not
have
who
are
like,
for
example,
still
doing
waterfall
methods
as
opposed
to
Agile
development,
not
understand
the
concept
of
devops
they're,
also
going
and
trying
to
say:
oh
no,
we've
got
ourselves
a
service
and
we're
like.
Okay,
you
still
have
a
monolithic
environment.
All
you
did
to
put
a
rest
API
in
front
of
it
that
that's
not
making
a
rest.
Api
does
not
make
it
a
service.
It's
right.
A
You
actually
have
to
break
it
down
to
its
vital
points,
and
your
team
actually
needs
to
understand
how
to
do
everything
end
in
it's
not
just
about
the
development
they
actually
have
to
do
the
testing
they
have
to
actually
make
sure
it
goes
to
production.
That's
why
devops
became
popular
because
we
they
actually
have
to
care
about
what
services
that
they
maintain
and
that
they
also
produce
themselves
and
if
they
don't,
if
they
don't
care
about
that,
all
sudden.
This
thing
falls
apart
and
they're.
The
only
people
to
blame
data
mesh.
A
Is
this
exact
same
concept.
When
it
comes
to
data
right,
you
actually
have
to
have
the
people
themselves,
the
process,
these
cells
actually
ready
for
all
of
us,
and
you
don't
have
the
people
and
processes
put
in
place,
guess
what
it
doesn't
matter.
What
tech
you
throw
on
it
it'll
still
fail
fair
enough,
yeah,
absolutely
cool,
so
we
you,
you
and
I,
have
equally
both
on
our
little
bit
of
ranch,
but
then
let's
go
ahead
and
start
going
and
actually
answering
some
questions.
A
A
B
Is
so
I'll
help
out
too?
Don't
worry,
I
mean
so.
Firstly,
yeah
I
mean
it's
it's.
It
depends
if
you're
trying
to
say
the
company
is
entirely
shifting
to
an
entire
mesh
architecture.
If
they're
saying
we're
gonna,
culturally
reorganize,
how
we
speak
about
it
and
how
we
do
things
and
that's
that's,
find
it
too
huge
to
be
achievable
for
most
companies
that
aren't
one
an
absolute
Greenfield
startup
doing
it
from
the
very
start
or
two
just
have
so
much
money
in
time.
They
just
fancy
doing
something
slightly
crazy.
B
You
can
start
investing
in
it,
so
it
one
if
your
Tech
firmer,
helps
so
a
lot
of
the
way
that
they
likes
of
you
know
the
books
and
the
principles
talk
about.
It
is
if
you're
building
an
application
and
your
application
is
already
producing
and
maintaining
the
core
sources
of
data,
then
starting
to
organize
those
things
around
and
treating
their
data
as
products
and
starting
tackling
it,
one
by
one
standing
up
these
things
and
actually
sort
of
treating
them
seriously
as
products
and
iterating
it
over
starting.
B
So
you
can
then
actually
start
to
put
in
the
processes
put
in
the
practices
put
in
the
the
repeatable.
You
know
kind
of
self-serve
bits
that
you
can
then
stand
up
to
support
estimate,
because,
if
you're
trying
to
do
a
big
bang
roll
out
across
an
entire
organization,
it's
way
too
much
that
most
places
can
actually
do.
B
The
challenge
is,
when
you
start
talking
about.
You
know
the
analytical
side
of
things
and
again
Crossing
that
bridge
right,
Crossing,
that
bridge
between
all
my
various
different
application
data
products.
If
you
started
to
manage
to
stand
up
those
and
treat
them
in
products
over
to
actually
here's
all
my
different
uses
of
analytics,
there's
all
my
different
ways.
I've
taken
my
I
know
my
my
customer
Master
data
list.
B
My
my
stats
around
kind
of
you
know
my
most
sales
sold
products,
various
different
analytical
products
that
you're
creating
trying
to
treat
those
as
reusable
components,
kind
of
funny,
because
that's
kind
of
what
warehousing
and
things
have
been
trying
to
do
for
years.
Until
it's
you
know,
Consolidated
conform
dimensions,
but
trying
to
treat
those
as
individual
things
not
tied
to
a
data
model,
and
that
again,
it
just
requires
a
lot
of
investment.
B
A
Yeah,
no
and
I'd
love
to
add
to
exactly
what
your
callouts
here
so,
for
example,
I'm
going
to
go
back
to
the
software
cycle
because
part
of
the
reason
why
I
actually
like
doing
this
is
not
just
because
I
bring
a
different
perspective,
but
also
that,
if
you
look
at
the
way
data
engineering
is
these
days.
The
software
development
life
cycle
in
the
data
engineering
life
cycle
they're
actually
merging
together
right.
A
The
concept
is
that
in
the
past
a
data
engineer
could
be
just
somebody
who
did
SQL
and
they're
good
to
go,
and
this
idea
of
repeatability
or
versioning
of
code
is
pretty
much
non-existent,
and
so
nowadays,
the
the
data
engineer
that
person
is
seen
as
very
similar,
if
not
the
same
person
as
a
software
engineer,
just
because
of
the
fact
that
they
actually
have
to
have
that
same
repeatability
testability.
All
these
other
aspects
and
the
reason
I
bring
that
up
is
because
it
goes
back
to
that
same
concept
of
devops
right.
A
So,
for
example,
one
of
the
companies
I
had
worked
with
in
the
past
was
a
company
called
concur
great
company
loved
working
there.
But
the
reason
I
wanted
to
bring
that
up
is
because
we
were
just
trying
to
switch
to
Agile
from
waterfall.
That's
something
as
simple
as
that.
This
was
a
process
that
took
us
over
a
year.
Okay,
we
actually
had
to
train
all
2000
of
our
employees,
not
not
just
the
developers.
A
The
business
people
actually
realized
that
if
they
themselves
switched
over
to
Agile
Dome,
they
could
actually
stay
more
in
sync
with
their
own
development
teams,
so
the
business
themselves
could
actually
go
ahead
and
actually
get
their
features
out
faster,
so
they
themselves
realized.
Oh,
this
is
actually
beneficial
for
us
too.
This
isn't
just
a
software
problem.
So
what
was
really
cool
about
the
company?
Is
that
then
it
was.
It
was
a
massive
cultural
shift
for
the
entire
company,
and
so
it
wasn't
just
the
software
developers.
It
was
everybody,
including
procurement,
right
the
whole.
A
The
whole
premise
was
that
we
would
actually
change,
and
so
there
are
multiple
training
sessions
we
would
go
off-site
and
we
are
going
to
have
these
training
sessions
at
like
these
big
hotel
conference
rooms
specifically
to
go
ahead
and
get
us
up
to
speed,
and
that's
just
one
small
aspect
right.
This
is
just
going
from
waterfall
to
Agile
that,
and
obviously
Building
Services
is
much
more
than
just
that.
So
the
other
things
we
did
or
simple
things
are
like.
A
We
had
small
teams
that
start
off
first,
that
would
go
ahead
and
experiment
to
see
what
worked
and
what
didn't
work.
We
would
not
go
ahead
and
try
to
take
the
biggest
systems
and
try
to
convert
them
right
away.
We'd,
take
smaller
systems
or
newer
systems
that
could
go
ahead
and
be
built
as
Services
first
and
get
the
into
the
idea
of
the
cloud
right
away
and
then
over
time.
We
would
then
take
those
Lessons
Learned
apply
that
to
everybody
and
Train
everybody,
and
so
this
is
a
process
that
takes
time.
A
This
isn't
something
that
happens
overnight.
It
took
us
basically
about
two
years
for
that
conversion
to
actually
happen,
and
data
mesh,
basically,
is
the
same
concept
right
it'll
take
time
not
so
much
because
of
Technology,
but
because
it
you
actually
have
to
change
the
culture
of
your
organization
to
do
such
a
thing.
B
Yeah
and
again
I
do
think,
there's
elements
of
it,
which
is
fairly
naive
to
expect
large
companies
to
do
it.
You
know
kind
of
expecting
the
the
pure
business
teams
expecting
your
marketing
teams
and
those
kind
of
people
to
actually
take
technical
ownership
for
the
maintenance
of
a
product
yeah-
and
you
know
you
go
through
kind
of
you
go
through
the
daily
mesh
book
and
it's
talking
about
the
emergence
of
technology
generalists
and
everyone
having
to
be
a
little
bit
Technical
and
it's
like
really
yeah
I'm
not
going
to
go
into
a
like.
B
You
know
kind
of
a
an
operational
team.
You
know
so
the
team
of
the
procurement
team,
the
marketing
team,
the
HR
team
or
whoever
that
might
be
and
go
right.
You
guys
have
got
some
data.
You
now
have
to
be
techies,
you
know,
are
looking
after
a
technical
product
and
that's
kind
of
what
it's
angling
and
going
and
data
to
everyone's
responsibility.
And
absolutely
it's
true.
B
But
all
saying,
but
also
the
technical
ownership
of
the
textual
production
of
the
data
is
everyone's
responsibility.
It's
kind
of
fundamental
to
some
of
the
concepts
in
it
and
I
think.
That's
just
a
little
bit
unrealistic,
I.
Think
that's
I!
Think
many
many
companies
are
going
to
really
struggle
to
adopt
that
kind
of
mindset
and
I'm,
not
gonna
I'm
gonna
dive
into
a
business
and
go
hey.
You,
you
gotta,
learn
some
tests
because
I'm
gonna
get
pushed
back.
A
No,
that's
actually
a
good
call
out
dude
and
actually,
in
fact,
you
I'm,
hoping
I'm,
seeing
his
name
correctly.
Arunuka
Prasad
from
LinkedIn
actually
was
asking
that
question
is
what
are
the
data
meshes
not
good
at
I?
Think
you
literally
just
answered
that
question
so
I
think
that's
perfect,
so
perfect,
all
right!
Let's
go
to
the
next
question
now.
This
is
this
a
little
bit
more
specific
is,
is
a
data
lake
house
better
than
the
data
mesh
and
the
data
fabric?
Okay,
and
that's
a
little
bit
interesting.
A
No
problem,
okay,
well,
I,
won't
say
formal.
It
is
me,
so
that's
that's
debatable
whether
you
want
to
say
formal.
Okay,
the
problem
is
right.
Now
is
actually
the
definitions.
Okay,
remember,
data
mesh
is
not
is
more
about
the
processes
that
you
put
in
place.
Okay
in
terms
of
actually
saying
okay
do
I
have
which
parts
of
it
are
centralized
and
in
general
data
mesh
is
trying
to
decentralize
everything,
but
in
all
seriousness,
most
successful
at
least
to
what
I've
seen
data
meshes
have.
A
Yes,
there
is
technical
responsibility
that
is
decentralized
out,
but
there
still
is
a
central
core
team
that,
if,
if
for
no
other
reason
at
minimums,
establishes
data
dictionary,
governance
and
processes
at
maximum
provide
consulting
services
or
Professional
Services
to
the
various
teams,
so
that
way,
they
all
run
on
same
standardization.
It's
okay
for
secret
argument
that
one
team
wants
to
run
their
data
processing
on
Rust,
because
I
love,
rust
and
then
another
team
runs
on
python.
A
That's
fair,
but
by
the
same
token,
maybe
the
the
central
core
team
has
decided
that
they're
going
to
standardize
on
python.
So,
in
other
words,
the
team
that
wants
to
go
rust,
you're
more
than
welcome
to
do
it,
but
guess
what
you're
responsible
for
fulfilling
these
contracts?
If
you
do
such
a
thing,
which
is
versus
the
pre
team
that
goes
on
python,
they'll
go
ahead
and
already
have
templates
put
in
place
for
Safe
Harbor.
That's
really
what
the
concept
of
the
data
meshes
about,
that
centralization
decentralization
pushed
back
and
forth.
A
The
data
lake
house
is
a
different
concept
altogether
right.
The
lake
house
is
basically
saying
I'm
taking
this
idea
of
the
warehouse.
Okay,
the
data
warehouse
of
the
past
right.
In
other
words,
this
is
typically
okay,
because
I'm
an
oh
I'm,
an
old
fogy
from
the
SQL
Server
years.
The
concept
is
the
V1
of
business
data.
Is
the
database
makes
it
version
one
right?
Basically,
we
put
everything
in
a
database.
We,
especially
when
I
was
a
SQL
Server
like
we.
Basically,
every
single
solution
involved
us
basically
shoving
all
the
data
in
SQL
into
SQL.
A
Server
we
built
store
procedures,
is
a
cursor
function,
doesn't
matter
we'll
figure
out
how
to
write
a
stored
procedure
that
that
figures
out
how
to
do?
How
to
do
the
equivalent
of
a
cursor
function
without
being
cursor
fraction,
so
it'll
be
fast.
Okay,
that
was
great,
but
it
really
did
not
provide
us
that
flexibility,
okay
versus,
especially
when
it
came
to
data
science
in
terms
of
being
able
to
go
ahead
and
process
lots
of
semi-structured
data
version.
Two.
This
is
concept
of
data
Lakes.
A
That's
great
I
was
actually
partially
to
blame
for
parts
of
it,
because
I
kept
on
going
scheme
on
read
I
still
want
to
apologize
for
pushing
that
that
lasted
three
months
and
then
I
realized
I
was
full
of
you
know
BS,
so
I
I'm
playing
still
paying
Penance
today
for
pushing
that
idea.
But
the
context
was
that
you
have
a
data
Lake.
A
Often
it's
hdfs
or
Cloud
object
storage,
where
you
can
put
all
your
data
inside
there,
except
there
was
no
structure
to
it,
and
so
the
lake
house
is
version
three
It's,
the
Best
of
Both
Worlds,
it's
the
best
of
taking
the
transactional
concept
of
your
database,
plus
the
go.
The
concept
of
the
flexibility
of
your
data,
Lake
merging
them
together,
I.E
Best
of
Both
Worlds
I.E.
That's
the
data
lake
house,
the
data
mesh
and
the
lake
house
are
actually
orthogonal
to
each
other.
You
can
absolutely
build
a
mesh
with
multiple
lake
houses.
A
Okay,
so
it's
it.
Those
are
two
very
different
concepts
and
now,
when
it
comes
to
data
fabric
honestly,
it
really
depends
on
what
you
mean
by
data
fabric.
Okay,
so
often
more
times
than
not.
The
fabric
is,
for
example,
if
I
was
to
go
Microsoft
on
you,
I
would
say
things
like
the
service
fabric
I.E.
What
is
the
services
that
you
spin
up
to
go
ahead
and
operate?
A
Various
spin
up
various
VMS
there's
been
a
various
resources
for
your
system.
On
the
other
hand,
when
it
comes
to
data
fabric,
it's
more
like
is:
did
you
build
an
infrastructure
right
that
goes
ahead
and
actually
suffices
all
your
data
needs,
for
example,
for
machine
learning
for
streaming
and
everything
else.
Some
people
will
claim
the
data
fabric
would
be
like
well
since
I'm
from
databricks
databricks
is
the
data
fabric
using
that
example,
there
are
services
from
Amazon
Google
Microsoft
that
actually
do
the
same
thing.
A
By
the
same
token,
other
people
will
Define
data
fabric
as
much
lower
level,
so
it
really
depends
on
what
your
definition
of
fabric
I
do
not
think
there
is
a
solidified
answer
to
that
particular
question.
So
I'm
not
gonna.
So
that's
why
I'm
leaving
it
like
this,
because
I'm
going,
we
can
literally
go
on
for
hours
just
on
that
particular
debate
on
what's
the
definition
of
fabric,
but
the
key
concept
is:
these
are
all
also
orthogonal
from
each
from
the
concept
of
data
lake
house
and
also
data
mesh.
B
I
I
think
that
makes
sense.
Honestly
said.
Lake
house
is
a
is
a
place.
You
can
stand
up
several
products,
several
data
products,
it's
just
a
a
tech
platform.
You
can
use
to
stand
things
up.
The
mesh.
The
fabric
is
more
the
organizational
wide
estate
of
everything
that
might
be
and,
as
you
said,
you
can
have
a
measure
lake
houses.
You
can
have
a
mesh,
that's
a
couple
of
lake
houses.
Some
other
stuff
depends
on
size
and
shape
right.
B
There's
another
question
in
LinkedIn:
I
was
going
to
pick
up
with
the
MDM.
Please
do
it
so
if
we're
talking
about
master
data
management
again
as
an
old
school
data
warehouse,
so
it's
a
thing
close
to
my
heart.
Right.
I
spent
a
lot
of
Time
Master
data
management.
Doing
you
know
golden
customer
records
all
of
that
kind
of
stuff
and
that
that
one
is
one
that
fits
really
easy
into
the
concept
of
of
mesh.
B
It's
one
of
the
few
things
that
actually
just
easily
makes
sense
right,
because
it's
essentially
you
can
treat
it
like
a
microservice
having
something
we're
saying:
I
input,
all
of
my
customers.
I,
do
you
know
whatever
kind
of
fuzzy
matching
whatever
golden
record
establishment
I
can
do
and
building
up
standing
up,
something
that
is
like
a
web
service
to
say,
here's
this
customer
return
me
the
golden
record.
B
B
So,
as
you
get
all
these
different
analytical
products
that
you
can
argue
whatever
do
you
need
to
separate?
Do
they
needed
for
like
decentralization
how
easy
it
is
to
pull
them
apart
and
make
them.
You
know
microservices
MDM,
you
know,
Master
data
management
absolutely
lends
itself
to
being
a
decentralized
service
that
various
different,
both
operational
and
analytical
products
should
be
talking
to
and
consuming
as
their
source
of
Master
data.
B
B
B
A
A
Datamesh
is
very
much
about
this
concept
of
merging
processes
with
the
tech
and
honestly,
it's
more
about
the
processes
which
actually
was
going
to
segue
to
one
of
the
questions
that
was
asked
in
in
the
Zoom,
so
we'll
go
to
that
one
next,
but
very
much.
The
concept
is
that
it
is
much
more
about
the
processes
and
how
you
decentralize-
yes,
I
I
mean
since
I'm
from
databricks
I,
obviously
will
be
biased
toward
let's
not
pretend
I'm,
not
biased,
but
I'm,
certainly
not
stating
that
this
is
the
only
attack.
Quite
the
opposite.
A
B
I
mean
in
terms
of
the
when
we
talk
about
tech,
we're
like
right
at
the
start,
we
talked
about
the
the
central,
the
four
pillars,
and
one
of
them
is
a
self-service
kind
of
analytics
infrastructure,
a
a
real
cookie
cutter.
Then
you
can
just
deploy
stand
up
that
allows
people
to
start
surfacing
a
lot
of
people
like
standing
up
these
data
product
apis
without
a
huge
load
of
tech
work
around
and
that
could
be.
It
could
be
some
little
Services
you've
written.
B
It
could
be
something
custom
and
bespoke
that
you've
done
it
could
be.
That
is
a
virtualization
service.
That's
kind
of
you're
sitting
there
and
you're
registering
your
various
different
things
in
there.
So
databricks
have
answers
where,
if
you
wanted
databricks
as
part
of
that
technology
stack
you're
using
to
standing
up
a
mesh,
then
we've
talked
you
know:
Unity
catalog
is
there
as
a
central
metadata
system,
that's
available
if
you're
using
data
bricks,
so
you
have
lots
of
different
database
workspaces.
B
That's
the
way
of
sharing
things
amongst
it,
but
Delta
sharing
being
the
more
like
true
mesh
thing.
When
you're
standing
up
an
API,
you're
standing
up
a
server
with
a
various
different
apis,
you
stand
up
an
API
for
each
of
the
different
shares
that
you're
doing
and
it
so
you
could
have
a
mesh
that
is
made
up
of
various
different
things
like
the
application
server,
just
standing
up
apis
on
its
own,
because
it's
a
web
service
or
a
website.
The
beta
breaks
itself
standing
up
apis
via
the
Delta
sharing
server
inside
unit
catalog.
B
Another
thing
standing
up
an
API,
Via,
Real
virtualization
thing,
and
the
whole
thing
is
having
that
idea
of
these
different
Services
being
poked
up
all
our
micro
services.
That
is
how
you
get
your
data
from
various
different
things.
So
can
my
current
database
be
part
of
a
mesh
sure
because
the
technology
that's
in
there
to
enable
you
to
stand
up
apis
that
you
could
use
as
part
of
a
wide
array
of
different
technologies
that
you're
implementing
your
message,
part
of
is
the
only
way
to
do
a
mesh
anyway,
it's
nah.
B
That's
it
there's
many
different
ways
to
skin
that
cat.
But
that
is
just
addressing
that
one
of
the
principles
which
is
make
it
easy
with
the
tech
and
it
does
not
work
if
you
haven't
done
the
hard
part
of
the
organizational
ownership,
the
concept
of
treating
data
like
a
product,
the
concept
of
decentralizing
ownership.
It's
just
not
there
with
a
quick,
Tech,
sticky
plaster.
B
B
A
Absolutely
all
right,
let's,
let's
dive,
we
got
some
other
really
good
questions
I
want
to
dive
into
so
I.
Hopefully,
I'm
saying
your
name
correctly.
Dalabor
asked
a
question
from
the
Linux
Foundation
zoom
and
the
question
is:
do
you
really
agree
with
the
authors
of
data
mesh
principles
that
data
owners
should
recruit
from
the
business
side
of
a
domain?
A
Do
you
think
that
it's
realistic
and
now
this
is
his
personal
opinion?
He
says
he
doesn't
believe
that
they
possess
the
skills
and,
more
importantly,
the
attitude
to
carry
on
such
a
mesh,
a
mash
of
data
that
they
must
work
with.
Okay,
I
want
to
tackle
that.
First.
Would
you
like
me
to
tackle
that
first.
B
I
mean
it's,
it
depends
on
time
scales
right
because
there
was
there
was
a
time
a
long
time
ago.
Back,
you
know
when
we
started
talking
about
the
last
wave
of
decentralization
that
the
industry
went
through,
which
is
everyone
should
do
their
own
reporting
I.
You
know,
I,
don't
want
to
get
sent
an
email
that
has
like
sort
of
a
PDF
in
there.
I
want
like
users
to
go
in,
explore,
cut
and
slice
data
open
up,
Excel
and
there's
this
similar
backlash,
you're
going.
Why
should
I
do
my
own
reporting?
B
That's
the
data
team's
job
I
I
I'm,
not
a
data
monkey
you're!
A
data
monkey
make
make
me
some
reports,
data
monkey
and
that's
you
know,
there's
pushback
in
terms
of
the
the
upskill,
the
data
literacy,
how
data
literate
should
the
general
business
be,
and
if
you
look
now
compared
to
10
years
ago,
compared
to
20
years
ago,
the
data
literacy
of
people
just
generally
in
the
workplace
is
massively
different
and
I
think
that's
almost
kind
of
what
we're
talking
about
in
this
kind
of
future
kind
of
saying.
B
Maybe
is
it
right
to
say
we
shouldn't
have
that
vision
and
shouldn't
expect
in
10
years
time
in
15
years
time
than
actual
generally,
businesses
will
be
that
level
of
tech
maturity
higher
that
not
saying
that
everyone's
going
to
be
attacking
everyone's
going
to
be
sitting
there
coding
away,
but
saying
actually
the
to
have
a
slight
bit
of
software
mentality,
a
slight
bit
of
thinking
about
products
and
thinking
about
product
ownership
to
permeate
through
various
different
business
domains.
Is
that
unrealistic?
Maybe
not?
Is
it
right
right
now,
not
for
everybody?
B
Absolutely
not
I,
don't
know
whether
that's
the
way,
the
world's
going
but
I
think
we're
talking
about
that
kind
of
time
scales.
If
we
do
go
that
way,
it's
in
a
norm,
it's
a
basically
a
whole
cultural
shift
of
the
industry.
That
generally
people
in
these
roles
are
getting
more
technical
of
getting
more.
At
least
more
data
Savvy
a
little
more
Savvy
about
how
these
things
work.
So
right
now,
no,
but
is
there
something
we
should
aspire
to,
not
to
say
that
we
shouldn't
be
heading
in
that
direction?
A
Pivot,
then
also
Excel
with
power,
bi
and
then
power
bi
itself
has
its
own
tool
like
in
the
end.
A
lot
of
this
is
exactly
and
exactly
what
Simon
called
out.
It
is
about
time.
It
is
about
progression.
The
teams
that
will
end
up
getting
the
most
out
of
their
data
are
are
going
to
be
the
ones
that
actually
can
work
well
with
the
people
in
the
business
right,
because
the
business
are
the
ones
whether
they
meant
to
be
or
not.
They're.
A
The
product
managers
quote
unquote
to
Define
what
metrics
they
need
to
get
out
of
their
data
and
then
they're
going
to
use
those
metrics
to
make
decisions
on
where
the
business
goes,
and
so,
unless
you're
working
closely
with
the
business
in
the
first
place
and
the
or
the
business
working
closely
with
the
data.
Folks
you're
not
going
to
actually
get
people
to
actually
collaborate
on
this
front
and
if
they're
not
then
also
you're,
not
getting
the
most
of
the
maximum
out
of
the
data.
A
You
have
that's
what
it
boils
down
to,
and
so
exactly
like
Simon
called
out.
Are
we
able
to
go
ahead
and
have
them
run
just
for
the
fun
of
it?
Do
I
expect,
like
you
know
the
business,
the
main
person
to
run
Flink
jobs?
Absolutely
not
never,
okay,
I,
absolutely
don't
expect
them
to
do
that.
Do
I
expect
Soul
Flink
to
get
easier
over
time,
and
so
that
way
you
don't
have
to
be
an
Uber
expert
with
it.
A
Absolutely
I
do
exactly
and
that's
the
progression
of
the
technology
with
the
business
over
time,
we're
going
to
make
the
technology
a
little
bit
easier
and
the
people
who
are
in
the
business
are
going
to
become
more
data,
literate,
more
data
Savvy,
and
that's
that's
always
what's
going
to
happen.
Basically,.
B
But
then,
obviously
we
talk
about
that
cultural
shift
right
and
there's
still
companies
out
there
now
who
onto
that
level
of
maturity,
there's
still
companies
now
who
they're
not
data
driven
they're,
not
thinking
about
Data,
Insights,
they're,
not
decentralized
reporting,
and
they
think
about
things
in
very
like
old
school
ways
and
there's
companies
who
are
way
ahead
of
it.
It's
not
like
we're
all
in
the
same
line
kind
of
maturing
at
the
same
Pace.
B
A
Cool
okay,
I
just
realized.
We
actually
have
a
lot
of
questions
in
LinkedIn
that
we
have
not
answered
so,
let's
go
through
them
and,
let's,
let's
you
and
I
both
actually
stop
talking
so
much
all
right,
so
I'm
calling
myself
out
too
here
so
Daniel
Clark
has
asked
a
question
from
LinkedIn
hi
guys
big
fan.
Thank
you
very
much.
Do
you
have
any
eyes
on
existing
tools
or
Tech
that
would
open
data
ownership
to
the
non-techy,
Layman
or
average
business
user.
B
B
You
could
just
grab
a
shot,
a
lake
house
and
just
as
long
as
every
data
source
is
registered
wherever
it
might
be,
you
could
say
that's
kind
of
a
mesh
because
you've
got
technology
standards.
Now
the
management
of
that
is
very
centralized.
It's
it's
not
as
truly
open.
It's
not
as
completely
kind
of
domain
agnostic,
completely
self-managing.
B
If
you
go
and
complete
the
other
way
and
saying
everything
has
to
stand
up
a
web
service,
everything
is
purist.
It's
an
API
in
the
most
pure
definition
of
an
API.
That's
really
hard
to
get
people
to
adopt
it.
So
I,
don't
think
there
is
a
technical
standard.
I,
don't
think
there
is
a
a
thing
that
makes
it
super
super
easy
right
now.
I
think
the
closest
that
we
have
is
the
kind
of
semantic
layers
you
see
in
various
different
biitals,
just
being
able
to
collect
and
register
that
still
requires.
B
Someone
Central
usually
still
requires
someone
to
go
around
and
connect
up
all
these
different
data
sources.
The
virtualization
tools
that
you
know
kind
of
do
that
kind
of
thing
of
saying:
right,
we're
just
a
virtual
layer.
Your
data
can
be
anywhere
we'll
plug
you
all
in
most
of
them
require
infra
tin.
B
Someone
needs
to
manage
it,
so
we
need
to
look
after
that
stuff
and
again
that
requires
its
own
level
of
management,
so
plenty
of
tools
that
make
it
easy
for
business
people
to
connect
and
register
something,
but
not
to
spin
it
up
and
manage
it
themselves.
That
still
has
to
be.
Someone
provides
a
platform,
someone
manages
our
platform
and
then
there's
different
flavors
that
allow
users
to
go
and
hook
tables
in
Hook
Tech
in,
but
as
a
single
thing
that
enables
business
users
to
stand
up
their
own
in
a
real
layperson
way.
A
No
great
great
answer:
let
me
dive
into
the
next
question
just
because,
like
I
said,
we've
got
other
ones.
Pedro
has
basically
asked
the
question:
how
should
data
governance
be
handled
in
the
mesh
concept
from
a
real
technical
perspective
here
so
and
he's
saying,
don't
give
us
beautiful
answers,
get
your
hands
dirty,
no
problem,
so
Pedro
I'm
going
to
give
you
a
a
a
beautiful
answer.
First,
only
because
it's
it's
actually
pointing
to
you
to
a
long
answer.
A
A
couple
weeks
ago
there
was
a
d3l2
session
that
I
did
with
Ryan
Harris
about
cyber
security
and
datamesh.
That
actually
gives
you
the
the
the
context
of
exactly.
How
do
you
do
data
governance,
because
that's
exactly
what
it
was
this
is
at
HSBC.
How
do
they
apply
governance
to
their
model?
Long
story
short,
though
the
tldr
version
of
this?
Basically,
so
that
way
you
you
understand
in
the
end,
when
it
comes
to
going
and
saying
governance,
you
actually
have
to
build
policies.
A
I
know
that
doesn't
sound
like
a
technical
answer,
but
that's
actually
the
first
thing
you
have
to
do.
There
actually
has
to
be
policies
on
on
your
data
to
Define
like,
for
example,
there's
often
people
categorized
as
it
like.
Is
it
hbi,
MBI
or
LBI
like
a
high
business
impact,
medium
business
impact,
low
business
impact
and
there's
very
security
associations
or
privacy
that
goes
with
that?
A
Okay,
because
that's
one
of
the
first
things
that
data
from
a
data
mesh,
you
actually
have
to
worry
worried
about
when
you
share
data,
what
data
can
you
share
and
who
can
you
share
it
with?
Okay,
if
you
have
not
built
these
policies
in
place
in
the
first
place,
you
can't
even
do
the
concept
of
sharing
your
data
forget
about
mesh,
just
sharing
the
data
to
it
even
to
another
organization.
That's
right!
A
Next
to
you,
okay,
you
you,
because
what
ends
up
happening
is
that
there's
always
fiduciary
responsibilities
when
it
comes
to
the
governance
of
your
data.
Okay,
whether
you're
talking
about
sarbane
socks,
HIPAA
Health
act,
whatever
gdpr
I,
don't
care
like
there
there's
all
of
these
different
acronyms
for
governance
and,
in
the
end,
what
it
boils
down
to
is
that
you
have
to
know
exactly
what
happens
to
your
data
who
modified
it
and
who
are
you
sharing
it
with
and
just,
as
importantly,
how
to
delete
it
and
ensure
that
you've
actually
deleted
correctly?
Okay.
A
So
that's
what
I'm
saying
this
is.
This
is
a
very
dirty
answer,
okay,
because,
but
it
starts
with
the
beautiful
answer
of
basically
building
the
policies
when
you
actually
apply
the
Technologies
literally,
we
can
take
a
whole
session
just
to
talk
about
gdpr,
okay,
in
fact,
I
think
one
of
the
such
as
we
were
supposed
to
do
was
actually
so
maybe
we
will
go
back
and
bring
this
back
session
back
out.
So,
for
example,
some
cases
are
simple
things
like
okay.
A
If
you're
going
to
delete
the
data,
some
people
say:
okay,
you
must
delete
the
data
and
have
a
transaction
log
that
goes
with
it.
For
example,
since
we
talk
about
Delta
Lake
a
lot,
that's
exactly
what
happened!
You
delete
the
data
you
go
ahead
and
actually
have
a
log
that
specifies
that
the
data
was
deleted,
but
in
some
cases
people
say
no.
A
You
can't
do
that
because
you
actually
update
it
first
and
update
it
to
null
why
you
keep
the
ID
so
that
way,
Downstream
systems
know
that
they
have
to
go
ahead
and
delete
their
data
too.
So
that
way,
there's
a
lineage
that
allows
you
to
understand
that.
Not
only
did
you
delete
it
from
The
Source
system,
you
delete
it
from
the
target
system
and
so
forth
and
so
forth.
So,
in
the
end
everything
I'm
talking
about
isn't
so
much
of
a
technical
aspect.
A
It's
actually
about
saying
what
are
your
policies
and
then
writing
the
code
to
do
that.
There
are
different
technological
solutions
that
come
into
place
from
different
vendors
that
do
various
degrees
of
that.
But
even
if
you
were
to
take
all
of
them
together,
you
will
still
need
to
glue
it
all
together.
Okay,
so
in
the
end,
it's
still
work
that
you
have
to
do
and
again
just
a
harp
on
this
point.
A
One
more
time
you
have
to
define
the
policy
first
and
and
then
finally,
when
it
comes
to
the
concept
of
data
mesh
typically
more
times
than
not,
there
will
be
a
central
governance
team
that
will
Define
that,
okay,
because
in
the
end
your
business
is
going
to
have
to
Define.
Yes,
that
particular
ID
is
an
hbi.
It
can
never
be
shared,
ver
or,
and
then
that
has
to
be
applied
to
everything
else.
And
when
you
delete
the
data
from
a
gdpr
context.
Yes,
the
source
system
is
deleted.
A
What
is
the
lineage
to
track
every
single
system
that
potentially
had
utilized
this
information
and
delete
that
as
well?
So
all
of
these
things
in
the
end
are
about
policies.
Hopefully
that
provides
you
at
least
a
high
level
concept.
I've
already
talked
a
little
too
much
as
it
is,
and
but
again
check
out
the
dl32
d3l2
session,
cyber
security
with
Ryan
Harris
HSBC.
That
provides
you
a
lot
more
of
those
details,
because
this
is
a
banking
environment
in
which
we
were
talking
about
data
measure
governance.
So
hopefully
that
answers
that
question.
B
I
I
would
say
that
and
yes,
absolutely
answers
data
governance
as
a
plane
of
how
you
govern
a
data
estate,
I'd,
say:
there's
another
angle.
That
also
needs
to
be
taken
into
account,
which
is
the
database
product,
because
when
you
build
a
bit
of
software
when
you're
picking
something
off
the
backlog
and
you're
delivering
a
feature,
that
feature
has
acceptance
criteria
and
has
a
definition
of
done
so
to
the
other
angle
of
governance.
In
terms
of
saying
how
good's
a
data
product,
how
do
you
make
sure
I
mean?
B
So
what
are
the
traditional
parts
of
data
governance
in
a
traditional
analytics
architecture?
Is
a
data
Steward
measuring
quantity,
metrics,
saying
the
quality
of
this
product
is
80?
How
do
you
define
that?
What
are
the
standards?
What
are
the
metrics
that
use
to
Define
quality
and
DQ?
Is
that
for
me,
the
other
pillar
of
data
governance
right,
so
you've
got
the
regulatory
governance
the
who
can
see
what
data
who's
allowed
to
see
things?
How
do
we
categorize
it?
What
data
is
exposed
across
my
entire
estate,
but
you've
got
the?
B
How
do
you
hold
people
accountable
for
standing
up
that
data
product?
How
do
they
before
they
deliver
something
they
go?
No,
this
doesn't
meet
my
quality.
Gates
I
can't
deploy
my
application
because
it's
going
to
drop
my
data
products,
it's
going
to
ruin
the
quality
of
my
daily
product.
Therefore,
it's
not
meant
it's
application.
It's
it's
acceptance
criteria,
so
it's
about
kind
of,
as
well
as
having
kind
of
the
governance
artifacts
with
a
regulatory
point
of
view.
B
It's
about
baking
in
that
a
whole,
the
metrics,
how
you
define
that
what
things
people
have
to
tick
before
they're
allowed
to
stand
up
or
before
they
take
their
own
Pride,
hopefully
their
own
accountability,
to
stand
up
a
data
product.
How
do
you
define
that
and
having
that
common
set
of
standards?
And
it
might
be
that
Central
governance
team-
it
might
be
another
kind
of
bodies
coming
up
with,
essentially
one
there
might
be
a
technology
fixed
I
mean
how
are
you
measuring
dead
quality?
B
There
might
be
a
set
of
tools
and
rules
and
things
that
you
apply
to
it.
It
might
just
be
a
set
of
processes
that
each
team
who
is
standing
up
a
data
product
adhes
to
and
they
publish
and
go
right.
Here's
our
data
quality
metrics.
We
promise
that
for
this
product
we
will
always
meet
these
things
and
they
publish
it
and
that's
a
data
set
of
their
own
and
part
of
a
you
know
a
good
working
mesh.
You
should
be
able
to
say
of
all
the
various
different
products
out
there.
A
You
want
to
same,
have
the
same
quality
issues.
For
example,
one
of
the
things
that
we're
doing
with
Delta
Lake,
which
isn't
so
much
a
data
problem
though
it
technically
is
because
it
involves
Delta
Lake
itself-
is
that
we
actually
built
a
new
process
called
that
Delta
acceptance
testing
it's
it's
boring,
but
it
allowed
me
to
go
ahead
and
name
the
new
sessions.
A
What's
up
with
that,
so
that's
just
me
being
a
a
geek,
a
dork
excuse
me,
but
the
context
is
that
we
have
so
many
different
Integrations
like,
for
example,
the
golang
upcoming
golang
one.
We
have
Flink
Presto
trino
Athena,
whatever
the
rust
apis
call
for
Delta
just
yet.
Okay,
we
have
so
many
different
systems
that
are
trying
to
interact
with
Delta
that
we
actually
have
to
have
centralized
testing.
A
Okay.
Now
the
testing
isn't
centralized
from
the
standpoint
of
like
sorry,
I
want
to
clarify
the
centralizing
is
not
the
actual
test.
It's
that
each
one
of
these
projects
is
responsible
for
testing
it
and
outputting
those
metrics,
but
there's
a
centralized
location
to
Define.
What
are
we
testing
Define?
How
we're
supposed
to
measure
it,
and
so
that
way
we
can
all
go
ahead
and
say:
Yes,
Delta
rust
does
X
Y
and
Z
Delta.
A
B
Okay,
I'm.
Sorry,
one
final
point,
one
final
point
to
close:
that
down
the
big.
The
big
message
which
again
most
of
the
people
who
spoke
to
me
after
I,
was
ranting
online
about
mesh
being
a
terrible
thing
to
try
and
Implement
wholeheartedly
we're
like.
But
that's
not
the
point,
you're
not
meant
to
try
and
Implement
all
of
it
now
and
that
that
idea
of
data
as
a
product,
essentially
treating
data
as
a
thing
that
has
acceptance,
criteria
that
has
kind
of
a
set
of
rules
has
a
definition
of
done.
B
You
can
just
Implement
that
as
its
own
as
a
process,
you
start
trying
to
embed
throughout
your
organization.
You
don't
have
to
try
and
embrace
a
build,
a
mess.
You
don't
have
to
say
yeah
we're
building
mesh
absolutely
everywhere.
You
can
just
say
right:
we're
going
to
implement
load
of
processes
to
implement
data
as
a
product
and
try
and
build
that
community
that
sense
of
Pride
the
sense
of
accountability
in
those
metrics
and
people
have
been
doing
that
as
a
governance
thing
for
years,
and
it's
got
a
shiny,
new
name
cool.
B
But
it's
not
saying
that,
because
part
of
this
big
likes
of
you
know
kind
of
this
big
organizational
change
that
there's
ideas
that
you
can't
just
adopt
and
go
we'll
do
that
bit
and
that
has
real
intrinsic
value.
So
yeah,
don't
just
say:
I'm,
not
gonna.
Do
the
whole
thing.
Therefore,
I'm
not
gonna
do
anything.
A
A
And
so
the
quick
answer
is
that
yes
and
no
and
the
reason
I'm
saying
yes
or
no,
is
because
the
whole
purpose
of
having
a
data
mesh
is
that
the
individual
teams,
the
people
that
own
the
lake
house
they're
the
ones
that
actually
control
both
the
input?
What
data
goes
into
the
system
and
just,
as
importantly,
more
importantly,
in
fact,
what's
the
output?
In
other
words,
these
are.
A
These
are
the
contracts
that
we
put
in
place
on
exactly
what
data
we
are
delivering
and
how
fast
or
the
frequency
or
latency
by
which
we're
delivering
that
data.
So
you
are
going
to
need
more
expertise,
but
the
context
is
the
expertise
on
each
individual
lake
house.
It's
not
necessarily
for
the
whole
mesh
yeah
and
going
back
to
the
way
we
described
it.
Yes,
there
could
be.
There
usually
is
for
successful
at
least
I've
found
in
general
for
most
successful
data
meshes.
A
There
is
a
central
core
team,
often
for
governance,
but
often
also
for
and
not
just
for
governance.
But
like
sorry,
the
def
definitions
of
data
which
often
is
deemed
under
governance
is
also
included
in
that
concept,
and
so
they
might
not
necessarily
build
everything,
but
they
will
ask
at
least
at
a
minimum
Define
everything
and
more
times
than
that
they're,
usually
building
some
Central
core
system
anyways.
So
that's
usually
when
it
ends
up
happening,
and
so
there
is
going
to
be
more
expertise
overall.
A
But
it's
not
specifically
to
say
that
you
need
more
data
mesh
experts
per
se.
There
will
be
some
in
from
a
centralized
governance
perspective,
but
the
thing
is
that
even
from
a
centralized
governance
perspective,
you
always
need
the
governance,
whether
it
was
a
lake
house
or
a
mesh
in
the
first
place.
B
Yeah
yeah,
it
kind
of
comes
into
that.
The
pragmatic
approach
that
we
end
up
building
for
people
who
are
like
we
want
to
do
Federated
analytics.
We
want
to
stand
up
very
different
business
domains,
doing
analytics
different
analytics
teams
embedded
into
different
parts
of
the
business.
So
we're
not
talking
about
changing
all
sources
of
data
into
this
massive
mesh
and
changing
the
entire.
The
entire
organization,
we're
saying
we're
pulling
data
from
all
these
different
operational
sources.
B
B
But
you
can
still
take
the
principles
and
the
learnings
and
treating
each
thing
as
an
analytical
product,
treating
each
team
as
a
decentralized
team,
treating
each
one
with
some
self-service
analytics
infrastructure
that
can
spin
up
all
of
those
lessons
still
absolutely
make
sense
to
it.
Have
you
implemented
a
data
mesh
technically?
No,
are
you
doing
things
at
the
best
way
for
your
business
yeah,
great
good,
then
you're,
delivering
value
and
you're
actually
serving
the
purpose.
A
Yes,
I
think
we
should
both
stop
renting
now
it's
already
9
52
a.m,
Pacific,
so
we're
a
little
past
the
time,
but
so
apologies
for
us
not
answering
all
your
questions.
If
some
of
the
questions
we
might
have
missed
so
I
apologies,
this
was
not
on
purpose.
We
were
surprised
by
the
number
of
questions
that
came
through
at
the
last.
Second,
please.
If
you've
got
any
questions,
just
join
us
at
the
Delta
user,
slack
go
dot,
Delta,
dot,
IO
slack,
we're
on
there
to
answer
questions
there
too.
A
If
data
mesh
ends
up
becoming
a
popular
enough
concept,
we'll
create
a
Delta
Data
mesh
Channel,
and
then
we
can
start
ranting
in
there
as
well.
So
just
just
join,
and
let
us
know
with
that.
Thanks
very
much.
Everybody
I
really
appreciate
your
time.
Simon.
Thank
you.
Like
always
always
a
pleasure
perfect
well
see
us
in
a
month,
Well
Bread
thing
about
something
else,
so
appreciate
it.
Everybody
thanks
very
much
for
joining
today.