how's it going everybody if I if I talk like this
can everyone hear me
if I speak loudly it'll go on the microphone
it's all good
I always like think when I when I do like
talks at conferences people are like why
is this homeless person like up on the
stage talking to us about data science
I basically dress like a high school
sophomore still so this is me my name is
Josh Wills the head of data engineering
at Slack ... I've been in Slack for about
seven months before that I was at
Cloudera and I was at Google and I was
other places I'm like most people I'm
famous and important because I wrote a
tweet once but I'm kind of tired of
talking about it if you're really
interested you can google me and find
the tweet it's totally fine and that is
the only hat I own which unfortunately I
did not bring with me today ... at Cloudera
and Google and other places I have run
both data engineering teams and data
science teams and so now I'm back doing
data engineering at Slack and I want to
talk about the relationship between data
science and data engineering and how we
can make it better and the first natural
question whenever someone wants to do
this is say why bother
is there really any upside to actually
improving the relationship between data
scientists between people who analyze
data and the engineers who provide them
with it we are sort of like a very sort
of unhappy married couple who ... like
need to go to couples therapy or
something like that just in order to be
able to honestly look at one another
like it's a really really bad
relationship in the grand scheme of
things except apparently at Netflix as
Kurt Brown will tell us later and this
is really kind of sad to me this is sort
of heartbreaking because I like ... I kind
of think like for my next career I want
to be like a therapist for data
engineers like I actually I sort of
think that I could actually make much
more money if I was just like ...
... sort of the executive coach or
whatever for like data engineers because
I swear to God if I had a nickel for
every time some like the first data
engineer or the first data scientist at
some little startup emails me or sends
me a LinkedIn message and is like hey
I could use some advice on what it's
like to be the first person at whatever
and they're all like really kind of sad
and miserable like it's just they're
very unhappy um you either have like a
data engineer who's spending all their
time like writing SQL queries and
creating dashboards and answering
questions for business users when they
really want to be doing cool data
engineering stuff or you have a data
science analytics type person who is
spending all their time running around
logging collecting data trying to run
experiments trying to convince engineers
to do stuff for them and they would just
really give anything for a data engineer
so like data scientist data engineer
they would really like when it's just
them by themselves they're very lonely
and and so that's sad and they kind of
want they want like each other they want
that good relationship but somehow
things go wrong and I I think about like
why why do things go wrong it's
fundamentally because we really want
different things data engineers and data analysts we really
want different stuff um data analysts
want to basically do really interesting
analytics and find insights and build
machine learning models because those
are the things you do to get to come
talk at conferences like this and look
really cool in front of all the other
data scientists data engineers on the
other hand they want scalability because
scalability is like the word we're doing
stuff at scale scale this doesn't matter
what it is we're doing we just long as
we're doing it at scale I can go to a
conference like this and talk about it
how awesome I am that I'm doing whatever
at scale it's just so stupid guys really
like anyway this is like the world we
live in though we want sort of fundamentally
different things and the fact
that we want different things causes
tension I've sort of given this talk a
couple of times now people always
resonate with this slide so let's kind
of go around seriously I think it's
funny and everything but it's also super
important because this is like a real
this is a real ... like photos and
stuff like that I appreciate that
let's go around the infinite loop of
sadness let's talk about how the
infinite loop of sadness works basically
sort of this way around the loop
like basically what happens is the
business makes unreasonable ridiculous
requests of the data science team the
data science team makes unreasonable
ridiculous requests of the data
engineering team the data engineering
team makes ridiculous unreasonable
requests of the ops team and the ops
team in goes to the business that says
hey we need a crapload of money to
support all of the ridiculous
unreasonable requests we've received and
it just goes on and on and on like this
basically forever this is the infinite
loop of sadness it basically ... literally
spirals out of control it's funny but in
that kind of like cringe inducing way
it's funny right this is this is funny
except unless you've lived through it
and then it's just you know infinitely
sad alright so as a result of this kind
of stuff as a result of our different
goals and as a result of the way that we
are structured and the kind of
incentives we have we end up like alone
together we're just sort of like there
and we're together and maybe we have
lunch together sometimes but
fundamentally we're just you know kind
of living these independent lives next
to each other and it's very sad and way
less good than it could be so let's go
back to first principles let's talk
about how we can repair this
relationship and some thoughts on
this kind of stuff and first principle
one for data engineering by far in order
to build data infrastructure you only
need to understand and appreciate two
things Apache Kafka and Franz Kafka
I think the Apache Kafka part is pretty
obvious to everyone at this point but
the Franz Kafka part for that I'm gonna
I'm going to turn to my old friend David
Foster Wallace who wrote this great
great article sort of one of his books
about Kafka's humor like how funny Kafka
is and how how students how college
students can have a hard time
understanding Kafka's humor because
people are trained to think of humor as
something you get the same way that
we're taught that a self is something
that you just have and so you can't
really appreciate the truly central
Kafka joke that the horrific struggle
to establish a human self results in a
self whose humanity is inseparable from
that horrific struggle in the same way
the horrific struggle to build data
infrastructure results in a data
infrastructure that is inseparable from
that horrific struggle everything in
data is terrible like it's just a big
you know steaming dumpster ...
dumpster fire of garbage it's just awful
but we make it work and again it's it's
you're trying to always kind of escape the
horribleness
trying to like free yourself from the
dumpster fire when you don't realize the
dumpster fire is your home the dumpster
fire is it's where you belong in some
like non-trivial sense that is the
central joke of data infrastructure and
so first things first let's all
appreciate that we are in basically like
The Trial or The Judgment we essentially
are living in a Kafkaesque universe when
we're doing data stuff so that's thing
one um thing two is to understand the
infinite loop of sadness and replace it
with the infinite loop of empathy
especially for data engineering and data
science understand that like from the
data science ... like the data scientists
need to know that the data engineers
have the exact same relationship with
the Ops people that the data scientists
have with the data engineers and the
data engineers need to know that the
unreasonable requests from the data
scientists are usually generated by
unreasonable requests from the business
we're in the same boat your problems are
my problems the people are a little bit
different but we really are in this boat
together and so that's like the second
thing we need empathy for each other we
need to understand each other before we
can really start working together well
how do we solve this problem one of the
ways really one of the shortcuts to kind
of creating that that sort of bonding
and that empathy between data
engineering data science is to build
machine learning models if you are
building like full lifecycle machine
learning models where you are like
taking in data ... building models
offline deploying them back into
production that ... nothing is more
effective at unifying the data
engineering and data science teams than
building and productionizing machine
learning models because you get to
really see the other person's problems
in a very very visceral sense so any
kind of company that's doing a lot of ad tech stuff or doing any kind of payment
stuff where fraud modeling is a really
big problem generally has a great data
culture and that's why all the best data
scientists and data engineers want to
work at finance companies and ad tech
companies it's because that's where data
is like the central thing and it's a
really really really good working
environment however not all of us
work at companies that have to do big
like hard machine learning models but
all of us working companies that have to
do some form of ETL and I love this this
cartoon it's just like I shouldn't swear
right it's really really funny
it's like everybody poops everybody ETLs
no matter where you are no matter what
you do everyone takes some data in one
place and transforms it to another place
it's just it's worth you know like
Google like everybody poops funny
Google Images this is worth checking out
longer you guys can't see it
everybody ETLs and I would ... my claim is
that the way that you do ETL says a lot
about your data culture and the
relationship between your data engineers
and your data scientists various options
I've seen I'm so glad I got to reference
the Bobby table's thing from the
previous talk so this is this is one of
the advantages of doing your slides five
minutes before your talk is you get to
like insert jokes at the last possible
second option one is SQL centric ETL
and Facebook is for me kind of the
canonical example of sequel centric ETL
Facebook does almost all of their ETL in
Hive they do it almost all in SQL
this is Hive and Presto all that kind of
stuff analysts are constantly like
creating new SQL jobs generating new
tables big complicated pipelines and the
data engineers are ... indentured servant
isn't like the right term but it's
something like that
it's if you ever if you ever come across
a facebook data engineer like give them
a hug they have a they have a terrible
job is anyone here a facebook
data engineer you don't want to admit it
I understand it's okay we can have like
sort of a you know come-to-Jesus kind of
session for you there's a roughly
roughly two to one relationship between
analysts at Facebook and data engineers
and the data engineer's job is to take
the steaming pile a SQL garbage these
data analysts write and turn it into
something remotely scalable and is
remotely coordinated across ...
all Facebook's data pipelines they write
a lot of UDF's
to make things like possible and
efficient and like I mean seriously
writing a Hive UDF ... has anyone actually
ever had to do that it is the worst it is
like absolutely absolutely terrible so
this is option one and a lot of
companies end up in this state a lot of
companies end up in the state it is a
very natural very easy state for folks
to slide into but it's a very very sad
place to do data engineering option
number two is JVM-centric ETL and I'm
going to call out Twitter as sort of the
the home of JVM-centric ETL at Twitter
for a long time all of their ETL was
done via Scalding which is a Scala DSL
for writing MapReduce jobs it has all
kinds of crazy like I swear to God like
advanced abstract algebra concepts like
sort of piled on top of it for doing
various kinds of aggregations where like
you need basically a graduate degree in
math to like understand like what's
going on and as we all know math is way
harder than something stupid like
physics so like any of the physicists
who've talked so far would not be smart
enough to work at Twitter so but like if
you're if you know you're like you know
you're like groups and rings and fields
and principal ideal domains like Twitter
is a great place to be and the result of
sort of JVM-centric ETL is the data
engineers basically turn into like the
high priests of data right where the
analyst says please data engineer be
... so kind as to modify your
magical like ETL abstractions to
generate the statistic that I want to
analyze right and I don't necessarily
know that this is a good ... I mean I sort
of would like to be worshipped like a
god that sounds great
I didn't sort of deliver that I actually
I was I made the mistake of actually
being honest in the talk didn't I okay
anyway but like this isn't a great sort
of data engineering like data analyst
relationship either like we don't really
want to constrain the analysts to not be
able to go off and do things and
experiment with new metrics whenever
they feel like it like that's not
necessarily a bad thing either
so let's come up with a third way
third ways have sort of a general
problem and that everyone kind of hates
them like roughly speaking like that's
sort of the way you know you're like
onto a good Third Way as everyone is
unhappy so I'm gonna talk a little bit
about the third way that we're working
on it's Slack which hasn't like
succeeded yet like most third ways but
I'm like reasonably optimistic about as
sort of my way of kind of coming with a
different sort of relationship and a
different different model for data
engineering and data science to interact
with each other and it's based around
sort of the state of the world as it is
now the state of data engineering the
state of data science as it is at this
moment in 2016 where we find ourselves
um the first sort of fact of things is
the rise of Spark ... if data is the new oil Spark is the new Standard Oil ... I just I
love that joke like no one else finds
that funny seriously like none of this
is the kind of the octopus that's got
its ... anyway
that kind of thing I'm Spark is like ...
Spark is completely taking over
everything like they are they have their
tentacles and streaming stuff and GPU
stuff and machine learning and ... just
everything there's Hive integrations and
I love it and I wish it all worked
better like more than anything I love
Spark and I wish it worked better ... I love Kafka do you guys love Kafka ... I love
Kafka ... Kafka does its thing and it does
it extraordinarily well and it doesn't
do anything else and I love that Spark ...
Spark there's a lot of things it does
all of them pretty well like but there's
always just little you know just ...
it just drives me crazy anyway
that said Spark is the new reality Spark
is like the default go to sort of data
processing engine that almost anyone is
going to use at any new company anywhere
you go these days Spark is taking over
so that's sort of fact one fact - there
are way too many streaming engines out
there right now at Google we had this
joke that there are two ways to solve
any problem the way that is deprecated
and the way that doesn't work yet wasn't
actually wasn't so much a joke because
it was like a statement about reality
actually now that I think about it and
right now batch processing is deprecated
and stream processing doesn't work yet
that is the world we find ourselves in
there is Spark streaming Samsa Kafka's
got a new thing there's Flink there's
Storm there's all these different
engines out there and none of them
really work that well like honestly like
we have not solved the streaming problem
yet in any kind of remote sense and I as
someone who would like to write some
streaming data pipelines so I can move on
to the new hotness I'm sort of left with
trying to decide between all these
different engines which one should I
choose I have literally no idea they all
seem like basically terrible terrible
ideas to me I'm gonna choose one it's
gonna be the wrong choice it doesn't
matter which one it is like it's you
know it's like Russian roulette or
something like that right it's just a
horrible kind of situation so there's
too many streaming engines and I don't
know which one is going to win and this
makes me sad um ... thing three is sort of
this this knowledge and this awareness
of streaming design patterns and I
actually give a lot of credit to the
Google folks - Google's like cloud
dataflow and Apache Beam and all that
kind of stuff they're doing for like
talking
about streaming data pipelines and sort
of the abstractions and ideas behind
them in a way that is even like remotely
intelligible to human beings like it's
it takes some work it's hard but I keep
having conversations with people at
various companies around the valley and
around San Francisco where like they are
clearly onto something with this stuff
like there's there's ideas here around
windowing and stuff like that that
resonate with a lot of different people
that I'm optimistic about even though I
don't know which of those different
streaming open-source streaming engines
I just mentioned those ideas are
actually gonna truly manifest themselves
in in a way that is workable operational
monitorable doesn't need to be
restarted every 24 hours because its
garbage collection is ... anyway I don't
know what's gonna happen there but I
feel like we're starting to have the
right conversations around how to design
these systems and haven't designed these
pipelines um and last but not least I
think and I'm sort of hopeful that maybe
for the first time ever in data
engineering we can stop talking about
scalability like that would just be
absolutely fantastic if we could stop
talking about scale because scale is
like solved if you ... unless you are like
Google or Facebook or LinkedIn or
Twitter scale is solved use the thing
that Facebook Twitter Google LinkedIn
has open sourced use that it scales
that's it problem solved no more
conferences on scalability please right
that's it
No Mas the real problem is change the
real problem is change the real problem
is the fact that all of this stuff the
underlying data the downstream metrics
all the machine learning models
everything is changing all the time
change is the real problem how do we
manage change in a sort of reasonably
I'm gonna cringe when I say a scalable
way we need like a different word like a
better word but that's that's the real
problem change is the real problem let's
stop talking about scale and start
talking about how we manage change all
right so the approach that I've been
I've been sort of talking about with my
team and I've been trying to convince
everyone to sort of adopt is inspired a
little bit from deep learning in
particular it's sort of the core deep
learning libraries like Torch and Theano
they all have sort of a very low-level
systems implementation done in C++ or
you know using CUDA libraries or
whatever they're leveraged GPUs and
super super high performant and then a
high-level scripting language for doing
most of the actual configuration stuff
that you need to do to run a model and
that can be Lua or Python or whatever
don't really care but it's that melding
of like low-level optimized systems
programming for the really really hard
compute intensive tasks and a high-level
scripting language for all of just the
real-world stuff you need to do
relatively quickly that's kind of
tedious and blah blah blah blah blah and
I like this model a lot and I would like
to adopt it for more and more of the
data engineering data science work we do
um one of the other things that I think
this is actually one of the things I
think Spark has really made possible for
me like the thing I love about Spark and
I think most people ... like the gateway
drug for Spark is the REPL ... is being
able to like load up a few terabytes of
data into memory and just sit there and
interactively query it and come up with
an idea and like interactively query it
and change your function it's magical
demos incredibly well it's absolutely
fantastic then you like ... it's not
until like weeks later the years have to
go read the like hundred long page of
configuration options in order to get
the damn thing to actually run at scale
leave that aside it's a really really
great demo and the ability to like cache
data sets in memory gives us a lot more
flexibility around our tooling relative
to MapReduce with MapReduce pipelines I
was a massive fan of static typing for
everything because there's nothing worse
than writing a huge complex MapReduce
pipeline and having it fail at the last
step because of like some stupid string
to long conversion right now because I
have the REPL and because I can like
be caching intermediate datasets as I go
if I screw up a type ... eh it's kind of
annoying but it's not that big of a deal
right I can just kind of fix it quickly
in Python or whatever and then go on to
the next problem
so I'm ... more and more I think I see us
moving towards this model in JavaScript
in PHP via hack and stuff like that to
like not quite static typing to sort of
like ... loosening sort of the
requirements for static typing at least
a little bit around data engineering in
order for folks to be able to move
faster ... Slack origin myth ... Slack once upon a time was this game called Glitch so so
Stewart and Kyle and the other sort of
founders of Slack they have this model
where they come up with these games they
think are super cool and like no one agrees
but they have some little cool niche
feature that people say that's actually
kind of cool like that's pretty cool and
that happened with like Flickr and they
did it again with Slack basically so so
Glitch was this really cool very
interesting game the Slack founders
tried to make successful and failed um
and one of the things that's like really
cool about Glitch is that it was it was
a game and that meant we had like a game
engine and this game engine was written
in Java and we had a sort of Rhino-based ... or sorry
Nashorn-based JavaScript engine for
actually like writing the levels inside
of this game engine so high-level
scripting language for designing levels
doing the kind of like fast work that
you want to do all the time very low
level Java engine for doing the heavily
heavily optimized systems programming
stuff much like not for nothing all the
deep learning libraries out there just
done in Java um so what we've been
playing with is taking this Java and
JavaScript engine that was written for
this game and applying it to our data
engineering problems at Slack and in
particular um creating like high level
JavaScript definitions of tables that
have various aggregations performed upon
them all the aggregations themselves are
actually done in a very low-level Java
Scala library but most of the actual
like high-level descriptive business
logic extract this field fill in
this default value performed this
transform is all done in JavaScript at a
high level and then we feed the
JavaScript into the Java engine the Java
engine goes and grabs all the JavaScipt
dependencies kind of like Node.js
style and then it deploys them out to
the cluster and runs an optimized Spark
job that is designed to compute all of
the different aggregations in a single
pass over a cache dataset kind of weird
right yeah I'll post these slides up on
the Internet so like folks can read them
later and hopefully we'll open-source
this thing once we you know actually get
it working but nonetheless this is
like the way I'm thinking about these
problems it's sort of like slowly gently
statically typed environment that you
can still like hack in very very quickly
um no one likes JavaScript like everyone
hates it I think that's probably a fair
statement like but everyone like knows
it the nice thing about having a
language everyone hates is it's like
embarrassing if you can't write it you
know what I mean and so it's like if you
can't write it then like well what's
what's wrong with you how could you
consider yourself not even or not even
an engineer but an analyst right
everyone can write
scripts and that's kind of great so
table declarations can be done code can
be written you can write sort of these ...
this is actually like actual little
snippets of the code that processes our
logs which are called slogs our client
logs are called clogs our job queue logs
are called jogs they got a little out of
hand
as these naming conventions can but
nonetheless um you can process these
these objects which are just Thrift
records via JavaScript to do whatever
extractions on them you want do whatever
kind of complex logic you like without
having to drop down into say Java to
write UDF's for Hive or whatever other
language you're talking about but also
not requiring that everything be in
Scala or everything being whatever all
the time and last but not least one of
the nice things about doing all the
stuff on Spark is Spark SQL again
Spark SQL mostly works and when you
need to basically do something simple in
SQL as part of a precursor to like
one of your JavaScript functions you can
just do that just declare that and we
will execute your SQL using Sparl
SQL for you and then propagate that
information so JavaScript whenever you
need to do scripting whenever you need
to write custom logic ... SQL when you
don't ... very very cool
so yeah that is roughly like the brave
new world that we're aiming for and I
sort of pride myself on getting
conferences that are running late back
on schedule
and ... so with that thank you all very
much ... oh yeah we're hiring
any questions yeah ... we've
got time for a couple of questions ...
yes ma'am yes of course how you doing yeah ... okay how you doing ... mic check ...
how are you ... good thank you ...
so thank you for your talk ... I do what I
can ... we all do we try I wanted to start
off by saying I love Slack we actually ...
I'm a MIDS student and we we use Slack at MIDS ... in this program ... and at the
company I work at we actually started
using Slack and it just took off ...
I'm so glad that's wonderful yeah that's
just like ... I just ... like dollar signs to me
that's just fantastic ... I mean yeah I had ...
I had a real question actually ... in
your infinite loop of sadness or empathy
or whichever one it is ... yeah ... you had a
quadrant that said business ... yes ... and I
work in product management ... yes ... and
I wonder ... you're in that quadrant ...
well I I figured you were implying that
when you showed the infinite loop of sadness ... now I'm explicitly stating it ... oh yes
and it is explicitly understood but my
question is when you talk about kind of
like reconciling that loop of sadness
and making it like the hoop empathy at Slack
particularly what role does product
management play and the reason why I'm
asking is because when you look at ... when I look at Slack or what I hear about
Slack I mean you've been around for
three years ... two years ... yep three ... two
years ... and yeah and you
have what like you're pushing I'm told
like three million active users a day
that's right so there's a product
component there somewhere how do you fit into the mix ... oh that is a great question
okay this is something like we're
recording this right so so here's the
problem it's like I basically think
Steward Butterfield is like roughly ... and
this is just gonna is his
cringe-inducing and I hate that we're
recording it I think he's basically like
what we have he's like Steve Jobs
roughly speaking for our ... he's been
trying to do Slack for like 15 years
like this is not a new thing for him he
has always done some IRC on steroids
thing and every company has ever had and
it just kind of finally came together
and I just I mean it's gonna sound kind
of weird but I mean data doesn't like
give birth to companies you need
products sort of visionary like you need
a vision right you can't like optimize
something that doesn't exist
you need product vision to guide you and
this is gonna sound like a terrible
answer but I mean like Slack is not
really a data-driven company yet in most
ways I still think Stewart has a vision
that will carry us forward for like at
least another 18 months or so before
like really we need to get into truly
scaling out the company through metrics
and data and you have a question okay so
yeah yeah
yes yes yes but that's just like the
right thing to do I mean it's like you
don't need any data to tell you that's
like the right thing to do ... it is it's my
secret plan don't tell anybody
oh my god no one please here don't say
anything it'll be fine .. you did so it's fairly
transparent is what you're saying
okay gotcha ... it's good not a very good
plan then yeah no it is and it will be
and it will be one of the great data-driven companies in the world but it's
not yet yeah and ... so I think it's
all about hiring I think the reality is
as you scale and as you grow and as the
opportunity becomes bigger we hire more
and more product managers who are used
to working in data-driven environments
as opposed to like sort of very early
stage startup vision-driven environments
and that's basically the transition I
had this sort of ridiculous idea in my
head that I could go to a company and
just show up and bring data and be like here
you go here's all your data and people
would suddenly become data-driven as a
result does not remotely work that way
it's all about the hiring it's all about
people in the room asking the right
questions and it's just it's like the
nature of a company it's just like the
lifecycle of a company as it grows and
changes to become much much more
data-driven just cuz you have to there's
not a way to scale one person's vision
beyond a certain point without
leveraging data ... let's take one final
question sorry it was a super long
question yeah how you doing ... hey Josh I'm good thank
you that was awesome ... it really was ... I
thought so ... I was laughing a little
too much but um at the company that I work and I wanted to get your insight on this
we've been transitioning for the last
year so something had we named a
DPaaS so data platform as a service
... and what they're trying to do is to
kind of like step away from I guess the
hellhole that you were describing and
and basically give data tools and the
ability for their product manager or
data scientist who really interact with
the data pipeline and not really need
the the data engineer to have to like
build everything ... yep so away from like
the high priest kind of model roughly ...
away from the high priest piece they
literally just set it there and you can
kind of like walk along and set up your
own MapReduce job or or whatever on your own
without having the knowledge of what's
going on ... is that something that
maybe could fit in to that brave new
world you're talking about her and have
you thought about something like that oh
so I think we're already in that world I
think roughly like I don't consider
Slack to be like one of the high priest
sort of shops we have like a quite a few
Scala pipelines written in Spark that
you've liked fairly fundamental things
that you know generally like our very
core logs and our very core data but
downstream of that there's like a ton of
SQL and the analysts are free to go
write and run whatever they want like as
well they should be I'm hoping like ... the
problem I have with like SQL as a
long-term strategy is the whole batch is
deprecated thing like I would like to
move them over to JavaScript and Java
land if only because I want to make it
easy to move the computations they
define onto streaming pipelines as
well as batch ones and so that's sort of
like the ... tooling wise what I'm trying to
aim for in terms of like the data platform stuff I feel like at least at Slack
we're like already there it's not a
problem for anyone to go get access to
data or you know like modulo like you
know basic policy and security kind of
stuff like that right like no one can
access like messages and stuff like that
that's the sort of a no-brainer
so yeah it's more of like it's a ... I
guess it's a little bit higher up like
once you have that platform and you have
it available for everyone to use what
tools should you like make available to
them for the really sort of standardized
canonical stuff you do because I still
don't want to end up in a world where I
have like 800 different tables that have
slightly different columns that do
slightly different things that mean
slightly different things and I have to
track down the person who created it to
figure out what's going on it's I mean
it's sort of I'm trying to like strike a
balance between the high priest model
and that's sort of like just crazy chaos
model basically it's not necessarily
superhuman driven I guess I don't really
like people I work in data
cool good perfect thanks very much
thanks everybody
