LEE FLEMING: Good evening.
I am really pleased to welcome you all to "Leaders in Big
Data" hosted by Google and the Fung Institute of Engineering
Leadership at UC Berkeley.
I'm Lee Fleming.
I'm director of the Institute and this is a Ikhlaq Sidhu,
chief scientist and co-founder.
The first and most important thing is to thank Google for
hosting the event.
So thank you very, very much.
There's a couple people in particular, Irena Coffman and
Gail Hernandez--
thank you-- and also Arnav Anant, our entrepreneur in
residence at the Fung Institute.
So here's Arnav.
AUDIENCE: A lot of work.
LEE FLEMING: Huge amount of work.
The Fung Institute-- we were founded about two years ago.
And the intent is to do research and pedagogical
development in topics of engineering leadership.
We have our degree, the Master's of Engineering--
professional Master's of Engineering M. Eng. program--
mainly around the Institute.
We also have ties though across the campus, as you'll
see shortly.
This is our intent to have a series of talks on topics of
interest to engineering leaders.
As it turns out, this Wednesday we
have our next talk.
It's sponsored by [? Thai ?] and the Fung Institute.
And the topic is entrepreneurship--
being an entrepreneur within your firm.
And fittingly, we have representatives from Google,
and Cisco, and SAP.
That's Wednesday.
Consult the Fung website or the [? Thai ?] website for
details on that.
So besides enjoying a good discussion tonight, we have an
ulterior motive, as you can probably tell.
We're trying to advertise all of our fantastic programs in
big data at Cal.
Now, whether you're interested in computation, or inference,
or application, or some combination of those things,
we've got the right program for you.
As I mentioned, the professional Masters of
Engineering, or M. Eng., across all the different
engineering departments--
one year degree.
We have another one-year degree in the stats
department-- a professional degree.
There's a two-year degree in the Information School.
And finally, there's the Haas MBA.
Tonight we've got people from all these programs.
You can find their tables, ask them questions, and hopefully
we'll see you see at Cal soon.
And we also have an additional executive and other programs
associated with each of those departments
and schools as well.
Ikhlaq will now introduce our speakers.
IKHLAQ SIDHU: OK, thanks.
So let me see.
LEE FLEMING: Just slide this here.
IKHLAQ SIDHU: All right.
Welcome, I want to also thank a couple of people.
One is [? Claus Nickoli ?], who is not here at the moment,
but to you in the ether, he's just not at the meeting.
But he's our host here, and so thank you.
You guys can tell him that I thanked him.
And also, many of you I've seen here are basically
friends, and so thanks for coming.
It's good to see you again.
This is an event on big data.
And so I'm going to give you a little data on
who is speaking today--
who is here.
And the way I think of this is, what we've got is three
perspectives of big data from leading firms--
from people who represent leading firms in the area.
And so let's start with NetApp.
We've got Gustav Horn.
He is a senior consulting engineer with 25 years of
experience.
And he's built some of the largest enterprise-class
Hadoop systems in the world-- on the planet.
And from Google, Theodore Vassilakis, and he's a
principal engineer at Google.
He's ahead of the team that works on data analytics.
And he's been responsible for numerous contributions to
Google in terms [? about ?] search, and the visualization
and representation of the results.
And from VMware, Charles Fan, who's senior VP of strategic
R&D. He co-founded Rainfinity and was CTO of the company
prior to its acquisition by EMC in 2005.
And our distinguished set of speakers is moderated by our
distinguished moderator, Hal Varian.
He is chief economist here at Google.
He's an emeritus professor at UC Berkeley and the founding
dean of the School of Information.
So with that, there's hardly anything more I
could possibly say.
Come on up Hal and take it away.
HAL VARIAN: Thank you.
I'm very impressed with the turnout tonight, seeing as
you're missing both the debate and the baseball game.
But at least it eliminates a difficult
choice for many people.
I will say that I'm going to follow the same rules as the
presidential debates.
So no kicking, biting, scratching, or bean balls are
allowed during this performance.
We're going to talk about foreign policy, wasn't that
the agreement?
No.
All right.
In any event, what I thought we'd would do is, we'd have
each person talk for about five minutes, lay out their
theme, where they're coming from, what their perspective
is on big data.
And I will take some notes, and then ask some questions,
get a conversation going.
And I think we'll have a little time at the end for
some questions from the floor.
So, take it away.
THEO VASSILAKIS: Sure.
So, should I start, Hal?
HAL VARIAN: Yes.
THEO VASSILAKIS: All right.
Well, hey it's a real pleasure to be here.
Thank you guys also, and thank you guys for coming.
It's a huge, huge audience.
Just a couple of words.
As you heard, my name is Theo.
I lead some of our analytical systems.
So I'm responsible--
well, actually up until two weeks ago, I was responsible
for a stack that had parallel data warehousing components,
query engines, pieces like Dremel, and Tenzing systems
that let you query this data, and
visualization layers on top.
And that's one of the many, many systems at Google that I
think, outside, one would think of as
big-data type of systems.
And so I'll try to give you my perspective at least on the
Google view of big data.
And hopefully someone will cut me off when it's time.
I think I'll probably go for five minutes.
This could take a while.
AUDIENCE: [INAUDIBLE]
THEO VASSILAKIS: All right, sounds good.
Thank you.
I think, as you guys know, Google's business is primarily
about taking data and organizing the world's
information, and making it universally
accessible and useful.
So a lot of what the company does is really about sucking
in data-- whether it be the web, whether it be the imagery
from Street View, or satellite imagery, or maps information,
or Android pings, or you name it.
And then transforming it into usable forms.
So really, Google is kind of a big data
machine in some sense.
And I think the term big data came into
currency relatively recently.
And we all said, yeah, OK, that speaks to what we do.
Because we don't really have a word for it.
We just kind of knew that the data was large.
But just to try to put maybe more structure on to that, I
think the Google view on a lot of "what is big data
processing" kind of splits up into probably what I would
call ingestion type of processes--
things like the crawlers, things like all those Street
View cars running through all the streets of the world.
And then goes into transaction processing systems, where
perhaps we capture data through interactions on a lot
of our web properties, or a lot of the web properties that
we partner with.
This means people clicking on search, or people interacting
with docs, or people interacting with maps.
All generate many, many clicks and many, many interactions
that then become transactional big data.
Of course, that also includes people using let's say Google
Analytics on their sites to measure traffic on their
properties, which then generates huge volumes of
pings into Google--
many tens of thousands of QPS of pings.
So that's kind of the second big component.
And then probably the third component is the processing
side of all of that.
The process side includes things like map [? reduce, ?]
analysis, generating insights from that data--
maybe in the form of building machine learning models.
Maybe in the form of building, for example, Zeitgeist top
queries that can then be served out to the world to
say, hey here is what people are searching for.
Maybe in the form of engrams of all the books that Google
scanned over many, many years of its ingestion processes.
But it's really baking all of that information and then
presenting it in some usable form, either through a system
such as our ad system that takes models and decides what
ads to show, or in a more direct
form such as the engrams.
Just to say, OK, here are those three broad classes--
ingestion, transaction processing, and analytical
processing.
To dig a little bit deeper into each of those areas, I
would say the ingestion processes, especially the very
large scale ingestion processes, are
highly custom systems.
If you think about our web crawlers, if you think about
the Street View cars, if you think about maps stitching, or
satellite imagery stitching--
those are very, very custom processes that I think, at
least to this date, don't have a clear analog
in the general industry.
And maybe this is something that you guys might address or
might see differently than how I see the version.
They're still highly-specialized systems
that produce very large images.
And they're very high performance, very complex
systems that are run by dedicated engineering teams.
The transaction processing systems or the storage systems
are things like the Google File System.
These are things like Big Table.
These are things like Megastore.
Those are the ones that we've actually published papers
about and that are now reasonably well
known in the industry--
have evolved a little bit past the purely custom stage, where
they're fairly general purpose.
And there was a time at Google where actually most people did
their own storage in some form or another, until these
GFS-like systems evolved to the point where they were good
enough that more than one team could use them.
And actually, that evolution had many steps in which, for
example, everybody ran their own GFS.
And so maybe the ads team had their own GFS cells, and the
search team maybe had their own GFS cells.
And in time, the systems matured to the point where
actually we could have a centrally-managed file system.
And I think recently you may have seen, we've now talked
about this global file system called Spanner which takes
that to yet another level of transactions and global
availability.
And then the third step, which is I think still in a
relatively immature stage compared to some of the
storage systems, is the analysis.
And I think a lot of people know about MapReduce and some
of the systems that have been built on top of that.
So for example, Flume is the way of chaining MapReduces in
a more programmer-friendly way so that you don't end up with
50 MapReduce stages that are individually managed.
But rather, you end up with one program that can then be
pushed down into many MapReduces that are
automatically managed.
The process there is still very engineering focused and
essentially requires engineering teams to process
this large data.
And so I think what we're seeing in that area is the
same maturation that we saw in the storage and transaction
processing systems.
Where little by little, systems such as Dremel, such
as Tenzing--
such as many others inside of Google that we haven't talked
about externally--
are aggregating a lot of that usage, and saying hey, we
really should do it in a much simpler manner.
And not really require people to have a full engineering
team to get the value out of all that big data.
Because at the end of the day, that's what
Google wants as a whole.
And that's what Google's customers want as a whole.
How do we get the value out of those big pieces of
information?
I would just leave you with those three big pieces.
And also this idea that, this is evolving into a
higher-level service that people can use without
necessarily being very, very
low-level engineering oriented.
And that more and more value is being derived out of that,
and hopefully something that you're seeing in Google's
properties and Google's services.
I don't know how much if I'm over, but I
can hand over here.
Thank you.
GUSTAV HORN: I'm Gus Horn, and thanks again for everybody for
coming tonight.
I know it's a big baseball night and you probably want us
to get done quick.
I come to it from a different approach in a sense and feel,
because Theo has--
Google has-- really been at the forefront of big data, big
data analytics, and in
particular Hadoop and MapReduce.
So I'm not going to go on the premise that everybody in this
room understands what MapReduce is, or what big data
is, and what data scientists are.
These are all buzz words that are really evolving.
I think what I found in my travels globally is that we're
really at the forefront right now of big data analytics.
I have a presentation that really characterizes it more
like a tsunami of data.
It's relentless, and it's coming at us.
It's coming at us from our Android
phones, from our iPhones.
It's coming at us from cameras that are everywhere, from our
TiVo boxes, from our PVR boxes, from everything we do
and touch in our world today.
We're generating data.
And the question is, do we either let the data fall on
the floor--
and we do nothing with it-- or are we going to pick that data
up and actually do intelligent things with it?
And we're finding more and more commercial applications.
Google I look at from a pragmatic perspective.
It's a commercial entity, but they are having a much more
philanthropic and broad approach to the world as well.
It was great back in 2003 that they defined GFS and gave us
MapReduce, which brought us back to the
mainframe days of old IBM.
But this is basically what it feels like to me, right?
Because it's batch-oriented processing at that time, when
we're talking MapReduce jobs.
But basically that was the genesis or the beginning of
what we call the Hadoop as we know it--
the Facebooks, the Yahoos, the LinkedIn--
all of these companies that are embracing this technology.
But now we look at companies like Progressive Insurance,
where they're giving you these dongles to plug into your car.
They're generating data.
They're collecting data on your habits,
your driving habits.
Health care industry is looking at how often do you
see the doctor, what are your statistics?
I was at the Mayo Clinic recently, and they have a
human genome initiative where they are looking at all of
their patients.
And they're actually doing a full genetic map all of their
cancer patients.
And their following these people for their entire life
expectancy.
And they want to keep their data 25 years, post mortem.
They want to build a repository where they can
understand exactly how does that one genetic mutation
affect your propensity to be carrying a disease.
Because they recognize that diseases
aren't just on or off.
There can't just be one mutation that
gives you that problem.
It's your environment, the mutation.
And that builds a susceptibility.
They're trying to really paint a huge picture, and that's a
big data problem.
So I see big data problems from health care.
I see big data problems in consumer-related industries,
whether they be the Walmarts, the Targets.
And not everybody is trying to be evil about this.
If you think about Target or Walmart, they would much
rather show you an advertisement that you care
about than to bore you to tears with something that
doesn't matter.
Just as Google doesn't want you to see a pop-up ad for
baby diapers if you're 60 years old and you're not going
to have a baby.
It doesn't do them many good, it doesn't do you any good.
There are a lot of positive things to take away from a lot
of this big data, and there's some negative things, too.
I'll focus on the positive in that I look at what companies
like the auto manufacturers in Europe are doing.
You look at BMW.
All of these cars are data-generating monsters.
And nowadays, you don't even know when you have to go for
an oil change, because they're predictively analyzing the
fluids in that car.
And they're determining when is it time for you to get that
oil change.
It's not like, oh I have to do to every 4,000 miles.
Your car tells you when you need to get it done because of
viscosity changes and because of analytical testing.
And they're collecting all of this data.
I think we're very lucky that we are at this forefront.
And I think that big data-- big data scientists--
are going to become more and more important.
And I think that, as Theo said, that it's going to get
to the point where, you don't have to become a
MapReduce job expert.
You really need to become a logical thinker and be able to
articulate the questions you're asking against a data
set, where you don't even care where the data came from.
You just know that all the data is in there.
And that's the key-- is to have a repository that's able
to hold all the data, and be able to allow for this kind of
processing to take place on that data, and produce results
in a timely fashion.
And what I've done is, I'm approaching it from more of a
corporate perspective, where people are looking at
enterprise-class systems, versus what we call white box
or dirt cheap.
And there're different kind of cut-offs for companies.
And I think as you go through your process at UC Berkeley,
and you're learning about where you want to go, you'll
see that you have to pick and choose your battles when it
comes to big data.
And the battle you have to choose is, am I going to be
setting up my data centers and my infrastructure to support
commodity-based platforms, and this-- do I want to own all
the data internally?
Do I want to virtualize the data in the cloud?
At what point do I bring that data internally.
Do I want to use services from Google?
They're all inflection points that you are going to be
making decisions over the next five years to
decide how to do that.
And this is what I'm dealing with all the time.
I think, hopefully, we all learn a lot from this
experience.
CHARLES FAN: Thank you for coming.
My name is Charles.
And unlike presidential debate, I agree with
what they just said.
Big data is like an elephant.
We were told we are allowed to touch this elephant from
different angles, from different perspectives.
But before that, I'll just try to repeat what Theo and Gus
just mentioned.
First, I think Internet is pretty big in terms of its
impact to our lives.
And not only to our lives, but also to enterprise IT.
And I think what we have seen in the last 20 years has been
the repeated tidal waves that's caused by the Internet
and the leaders in the Internet
space, including Google.
The advances they are making, and how those are hitting the
enterprise world.
And I think big data is the latest of such a tidal wave.
Essentially what the scale of data that the Internet
providers are dealing with, with consumers, the
enterprises are facing the same.
And now the challenge is, how do we adopt and massage this
technology so it's consumable by the various people inside
the enterprise worlds.
And that's what's behind the big data world we see.
And I think, like what Gus said.
Enterprises are working different sectors.
There are people doing retailing--
selling stuff.
There are people doing a manufacturing--
building cars.
There are people in health care.
There are people doing financial trading.
In almost every field, they are generating
more and more data.
And almost every field has many questions they need to
ask based on those data.
And they need to make decisions based on those data.
And unlike the DWBI world, which has been around also for
20 years, the amount of data, the variety of data, and the
speed of data coming at you are going beyond the existing
infrastructure can take.
And that's why to answer these different questions in
different verticals, everybody is seeing a need for new
infrastructure, a new database, a new storage to be
created to support the decision making based on all
these data.
What's different in those data, besides just the size or
the volume of it?
When people typically refer to big data, they call it the
"three v," which is volume, velocity and variety of data.
Some of them call them "four s." It's the source--
there more data sources--
the size, the speed, and structure of data that are
very different.
And I have another name for it, which is probably less
elegant, but also I think it's pretty true.
When we look at the old data, the small data, or the classic
data, they're typically record-based data, especially
those generated by transactional applications.
They usually have people generate it.
And they go through the whole life cycle.
So we typically call them CRUD data that you need to create,
read, update, and delete.
I'm sure all of you Berkeley students know
the CRUD data word.
You manage on the storage front.
You also have database design for it.
But with the new data, more and more of
them are machine generated.
We just have more and more devices that's connected to
the Internet.
Not all of them have a warm body sitting behind them.
There're both servers, as well as sensors, RFID, mobile
devices, cameras, and so on.
And they're all generating Google Cars, they're all
generating tons and tons of data, without people sitting
behind them.
But you still need to create them, but you don't update
them that much.
Those are usually write once and read many type of data.
So there's not much update.
And there's not much delete.
You need to retain data 25 years after people die.
And even after 20 years--
25 years-- people don't remember to delete them.
So there's not much delete, not much update.
There are a lot of application.
So instead of CRUD, now it's like
create, replicate, append.
There's more and more append.
All the data in append-only mode.
And process--
there's a constant need to process them in real-time,
during ingestion, or interactive.
So it's just crap data, is what big data is.
It's C-R-A-P--
create, replicate, append, process.
And when we are talking about structured data verses
unstructured data, we say there are more and more data
that are unstructured than structured.
I think it's just because the database technology or the
underlying technology is not scalable enough to put them in
a schema or in some kind of structure.
That's why they are all CRAP.
But you still need to process them in a more efficient way.
And that causes a lot of your challenges.
I think essentially whoever designs the new data
management system for CRAP and makes them consumable by
enterprises, is going to be the winner of
this big data race.
GUSTAV HORN: So Google invented the new crapper?
HAL VARIAN: Yes, OK, thank you for starting us out on such
provocative comments.
I wanted to follow up on your own your little troika there
with the ingestion, transaction, and analytical.
I come at the end of that food chain.
So what we get is, the data's been pulled in, the data is
available to us, and we're working on
the analytical side.
I want to say a few words about that.
When we have these analytical systems at Google, one of the
things you can do is just monitor the system and make
sure everything's running the way we expect it to.
And these guys have done a fantastic job, because now you
can take almost anything that's gathering data at
Google and create a dashboard with about 20 minutes of work,
which is a fantastic thing for running the business.
The other you can do is, you can build the machine-learning
models that he alluded to and engage in this kind of
predictive analytics.
That's very in-vogue these days and it's a
great thing to do.
But the thing that a lot of people miss, I think, is you
can use that data to conduct experiments.
And that's really the secret sauce at Google.
Our leader of the search team, Amit Singhal, said that a
couple years ago, we did over 5,000 experiments with the
search algorithm-- made 400 changes.
On the ad side, we're running roughly 500
experiments at any one time.
Any time you're logged into Google-- or any time you're
accessing Google, I should say--
you're probably in a dozen or more experiments.
And it's having the capability to manage that data, not just
for the current incarnation of the system, but all the
variations you might contemplate, is really a
fantastic help in moving the whole system forward.
So that experimentation rule is very, very
important at Google.
I wanted to raise a question of standards and
interoperability.
You mentioned Hadoop.
That's really become an industry
standard here at Google.
We have our own internal staff.
It's a lot easier to enforce these standards for
interoperability internally, than industry wide.
But to make this system work--
of starting with ingestion and transactions,
and then the analysis--
outside of Google, or outside of other big data companies,
you've got to have this kind of standards to interconnect
the flow of data.
And Charles, why don't you say a few things about what's
going on in that area
CHARLES FAN: I do think we are at the early
stage of this industry.
And right now there is no standards, per se, to my
knowledge that has emerged.
Hadoop has been a very popular technology that's born out of
the open source community's effort to--
based on the Google papers-- to create the MapReduce and
the GFS, as well as the other things they
built on top of it.
And I think, in lieu of standards, my perspective is,
open source plays a huge role here.
That in terms of overall data management as I mentioned, we
are going from a world that every thing is relational.
You basically have your relational data model, which
is the standard across all--
SQL being the standard query language.
Go into a more chaotic world, where there's many kinds of
data stores, many kinds of queries.
Even on Hadoop, there are various ways you can
query on top of it.
And open source really gives people the choice.
In this chaotic period, it is the choice.
It's basically the developers and users who's going to
decide which will become the standard.
And open source really provide this way to make it happen.
GUSTAV HORN: I just want to make one comment.
I think open source actually is the best way to make sure
that you don't get yourself pigeonholed into anything
that's proprietary.
And I think that with Hadoop and big data, as I look five
or ten years down the road, I think that standards aren't
going to provide structure.
It'll be more of an inhibitor than it's going to be of a
benefit in this area.
I think one of the key attributes--
and I think you can maybe talk more about that-- is the fact
that you want to be able to connect or stitch together a
bunch of disparate data sets.
You want to be able to look at things where you don't have to
be rigidly defined from the standard.
You want to be able to look at strange queries where weather
patterns, and people's buying habits, and the cars they
drive have some correlation.
And if you start imposing standards on top of something
that is that robust, I think it's going to probably stifle
development.
So I think the key here is open source.
The key is to have published innovations so that people are
publishing their works.
And I think as we get better and better at natural-language
processing and being able to get away from having to be
hard-core programmers, to glean insight into any of this
data store, it's going to be more beneficial.
I think in the next decade you'll find that you'll
probably be doing less and less Java programming and more
and more just natural language logic, I would think.
HAL VARIAN: Theo, I hope you're going to say a word or
two about protocol buffers.
THEO VASSILAKIS: Protocol buffers, yes, of course.
I'll plug protocol buffers for sure.
HAL VARIAN: Which you made as an open standard, right?
THEO VASSILAKIS: Right.
It's actually an open source system.
But before that, I was actually going to say I really
agree with your point about experimentation.
And I actually remember a time at Google where, if you wanted
to run an experiment--
for example, on search-- there was one engineer who is one of
our distinguished engineers now, Diane.
And you had to go ask her for some cookies on which you
could run your experiment.
It was sort of like, she would allot you some cookies.
Those days are over, but they really do generate a lot of
this CRAP data, because all of those experiments accumulate
over the years.
And yet it's really important to have the historical view of
hey, we tried this.
Here's what happened then.
And I think actually this plugs directly into this
problem of standards, because the way that all of the
engineers years back recorded their results, was very, very
different than the ways that engineers today
record their results.
So maybe, at the time, some of them didn't
have protocol buffers.
Which is, if you like, a kind of XML-like format for
representing data that Google created, but is a much more
efficient to represent type of format.
And so I think the problem comes because we want to
integrate all of this variety of data.
And what I would say is, I agree with Gus that I don't
see a lot of appetite for very generic standards.
But I do see people having a need to bridge all of their
old data and the new data.
And I would basically make two analogs here-- is that I think
one of the things that really helped the development of data
warehousing was fairly standard SQL.
And it was never a standard standard.
Like, there existed a standard, but no one really
followed the standard very closely.
But if it was close enough, you could get
your systems to work.
And I think the other aspect is file formats.
If you can take a file format and feed it into different
systems, that will really help.
And so until now, CSV was the end-all, be-all file format
for interchange.
I think we'll see more of these as we need to trade data
that's more structured--
that has protocol buffers or XML.
THEO VASSILAKIS: And if I could, let me add a plug for
VMware, as well.
As we mentioned, I think we are agreeing that we should
allow the chaos to continue for a little awhile.
However, there are certain parts I think we can help
people to make it easier.
Which is how do you stand things up.
Hadoop has a great system, but as Gus can probably tell you,
it's not so easy for enterprises to stand up a
Hadoop cluster.
Often the enterprise needs to stand up many of
those Hadoop clusters.
And some will need to stand up other type of data stores.
And that's where VMware is a leader in the virtualization
software and cloud infrastructure.
And we are building tools which includes some open
source project called Serengeti, which is helping
people to easily stand up their Hadoop clusters, as well
as other data stores--
really automate some of those headaches or tough work.
And so they can focus on the work that matters.
HAL VARIAN: Let me put in a good word about standards.
Because when you look at companies, how do they grow?
They grow through acquisition.
When they grow through acquisition, you end up with
data silos everywhere.
And data silos are the enemy of big data.
And the amazing thing about Google, because of the work
that Theo and his team do, is we have no
data silos at Google.
Now that's not 100% true, of course, but when we bring an
acquisition in, we spend a lot of time trying to get their
data infrastructure aligned with our own internal
infrastructure.
And what it means is, you can basically pick an engineer off
of one project and move them on to another project,
completely at the other side of the company.
And they're productive in the first week because of having
that standardized infrastructure that we have.
And that is not something that most companies have the luxury
of dealing with.
The biggest problem that most companies face in data
management is trying to get this interoperation among the
different legacy systems.
You know, there's this old line, how did God create the
world in only six days?
And the answer is, he didn't have a legacy
system to worry about.
So everybody in the business faces, how's
that going to be solved?
That's my question.
How do you solve that?
GUSTAV HORN: I think you're right.
There are a lot of heterogeneous databases and a
lot of things that need to be stitched together.
And I think that big data--
again from the Hadoop prospective-- . there are lots
of connectors out there-- from Flume, from Scoop.
And I think that's key.
You'll find that a lot of these big database companies
are having to embrace open source.
They're having to embrace Hadoop, because if they don't
embrace it, they're going to become roadkill.
So they're looking for ways to monetize it, from consulting
services and things like that.
And also how then can they play in this market and become
leaders in this market, so they retain
their customer base.
Because the bottom line is, the Oracles of the world, the
SAPs, these people make money through selling licenses.
Hadoop is a license killer.
So that's going to directly impact their ability to be
profitable from a stock market perspective.
They need to find ways to innovate that allow them to
keep that trajectory.
And then the other thing I would say is, that a lot of
times the biggest problem I've found in industry, when I go
meeting with big customers or potential customers, is that
they don't know where to start.
They have a huge data problem, not just a big data problem.
They have data everywhere and silos in different corners of
the organization.
And they don't have one person who is competent enough from a
technical perspective to know how to move forward.
They have individual islands or teams that are looking at
how they can move forward.
And the real strength in big data and big data analytics is
the heterogeneous nature of the data.
That's one of the key strengths
of this entire industry--
is the fact that you want to stitch together all of these
different data sources, and then be able to find those
correlations amongst them.
It doesn't do anybody any good to do a structured database in
Hadoop, and you're just doing the same old thing.
What's the benefit?
There is no benefit.
The benefit is when you're able to combine all of these
sources into one place and you find that
needle in the haystack.
Or you're able to better understand your customer.
Because fundamentally, all of these things
are customer driven.
I don't care whether it's Google.
I don't care whether it's VMware.
If the customer isn't happy, they're not
going to come back.
They're not going to like your website.
They're not going to like your product.
So the bottom line is, how can you find ways to modify what
you're doing to make it better for the customer.
And if you're able to find those needles because you can
stitch together all of these different sources--
including social media, including global search
engines and global communities--
and find out what people are doing, you'll find out those
subtle differences that really become the real game changer.
And that's really what big data is about.
CHARLES FAN: Yeah and I think another way I'll dissect the
big data, is that it can be looked at as four layers of
functionalities.
From the very top is the big data applications.
And to the second layer, which is big data analytics--
the various machine learning and other
algorithms you can apply.
The third layer is the big data management--
the query engines and so on, that you can query the data.
And the bottom layer is the data infrastructure--
the storage, and so on where you store the data.
I think to the question, the more bottom the layer, I think
it's closer to standardization.
I think there is, maybe to Theo's comment, there probably
can be a unified big data store, where all the bits, all
the CRAP, eventually end up somewhere.
There's a sync, a common sync for all the CRAP.
And they come into here.
I think right now we should still allow various different
ways for them to be queried.
Even in our Hadoop system, some people like to use Pick,
some people to use Hide, some people like to just do H-based
direct on HDFS.
Some people like to, Dremel is another way you can
interact with it.
And I'm sure there are new innovations coming out of
Google, out of everywhere in the ecosystem.
And like in [INAUDIBLE].
When I talk about standardization chaos,
sometimes I'll go back to the history--
for me, it's Chinese history.
Where, for those of you who have read the Chinese book
called "The Romance of Three Kingdoms," where the first
line of the novel is, "After unification it's chaos.
After chaos, it's unification. "
And it's describing how often of all the warlords fighting
chaos, inevitably somebody's struggle will emerge
and unify the land.
And that will be your emperor.
And also inevitably, whether it's after he gets old or,
whether he dies and his kids get weak, that it will fall
back into chaos.
And this is traditional dynasties that repeat about a
dozen times.
That's 4,000 years of Chinese history.
And I think that can apply to the history of anywhere else.
As well, it can apply to the data processing, the data
management here.
Where we are in this period, going from a more unified SQL
interface, a more unified data management query engines, to a
more diversified world.
But I would predict in ten years, there will be leading
standards or ad hoc standards-- de facto
standards-- that's going to emerge where the majority of
the big data problem going to be solved in that way.
THEO VASSILAKIS: Yeah, I agree with that.
I don't know if it'll be in the form of a W3C standard or
something like that, but I think that's a little bit the
dynamic that Hal was referring to inside of Google.
That after n years of fighting with all of the different
varieties of things, people kind of said, well we
understand now that it's not the purpose of our team here
over in maps to really build that entire stack.
Because now that we know what all that entire stack entails,
we realize that it's really far too big for us
to do on our own.
And so we're willing to concentrate further up the
stack in the parts that we really care about.
And that then led lots of groups of Google to look
around and say, OK well, what is a piece of technology that
exists, and is reasonably mature.
And a lot of people will use it, and it
gives us this advantage.
And so that's how some of the components such as Dremel and
others emerged as de facto standards of
how we analyze data.
And I think that those de facto standards will in time,
probably lead into some kind of more formal standards that
can be adopted across companies and across
organizations.
HAL VARIAN: Let me switch gears and turn to the
infrastructure, the hardware infrastructure.
So there's two models out there.
You could buy your infrastructure, and people to
maintain it, and run it in-house.
Or you can lease it on the cloud.
And what do you see as the advantages and disadvantages
of those two approaches?
GUSTAV HORN: I think that there's a place for both, to
be honest with you.
I think that you'll find that the cloud is a great place to
get started.
It's a great place for you to kick the tires.
I think you're always going to have the open source-- what I
call white box, commodity-based approach.
And a lot of groups where you're going to be doing your
sandbox, your proof of concept, you're going to be
testing out your code, from an infrastructure perspective.
And also I think that there's a place even for what's being
done over at VMware, where they're looking at
fundamentally providing an infrastructure and product in
a box, so that people can go to service providers and spin
up map producers and build their file systems.
At some point in time there is going to be again, like I
said, a decision where companies are either going to
embrace the technology because that internal leadership or
their leader within the company has proven
the value of this.
And that's going to be the tough slog that everybody in
this room is going to have to deal with over the next five
years-- is that you're going to be battling internal
processes, internal fights with in every organization
that I've met.
Where you have the legacy database people-- the people
who said this is how we do it, this is why we do it.
We have these checks and balances.
We have these constraints.
That data has to stay within our walls.
And then you're going to have the leaders, who are more
aware of what's available in technology with
virtualization, with cloud-based technology.
And in some cases, it does make sense.
There're regulations and laws that are going to dictate
where data resides, or where it can reside, or
where it has to be.
And there're going to be places where the cloud is
going to be paramount.
But you're going to find in the next five years, that
you're going to be fighting more political battles than
doing anything else.
THEO VASSILAKIS: I agree with that.
I think there will certainly be lots of ways to run
infrastructure locally, as well as on the cloud.
I think though, that what people will realize over time
is that a lot of the reason why it may sometimes appear
cheaper to run locally than it is to run on the cloud these
days, is because with cloud services, you get a lot of
services by default.
So perhaps you would get back-up by default, perhaps
you would get certain compliance
functionality by default.
Whereas sort of on reasonably bare machine, in perhaps your
own data center, you wouldn't get these automatically.
And I think over time, as more of this computation becomes a
commodity, in that you just expect it to
work and that's it--
you won't be able to live without some of those things
that are today considered value-added services.
And I think there will be a crossover point where it'll
start to be more expensive to actually do all of these
things on your own appliance, than it will be to do it at
scale in somebody's data center.
And I think the fatter and fatter pipes that connect us
to these data centers are going to make that a
possibility.
HAL VARIAN: Go ahead.
CHARLES FAN: Again, in the anti-presidential presidential
debate style, I agree with both Theo and Gus.
And VMware's view is that it's a hybrid cloud where that we
want to provide the same benefit to customers, whether
they are running things in their data centers or out of a
cloud service provider.
All that being said, I do think there will be an
increasing amount of infrastructure moving out of
data center, over time, to the cloud services.
Meaning the applications will be more and more delivered as
a service to the enterprise customers, as opposed to as a
packaged software today.
That will take time, but I think that will happen.
But even after that happens, even after the infrastructure
is outsourced so called, to the cloud service providers,
ownership of the data, of the big data, medium data, small
data, still is with the enterprises.
And it is still their responsibility to be able to
make their decisions based on the data that they own.
Even some of the data may be sitting at the service
provider, at the cloud provider.
It is still their responsibility to analyze
those data and to make decisions based on those.
THEO VASSILAKIS: And clearly, security is going to be one of
those big items.
And so if anyone's working on cryptography, that's going to
continue to be a pretty hot thing.
HAL VARIAN: It's always good to have a job
where there's an adversary.
Coming back to the elections again--
same model.
Let's come down to the query language.
We've seen SQL mentioned a few times.
What about NoSQL?
Tell me what's the role of that in today's world?
Is SQL going to be obsolete?
Or are we going to continue to rely on that
as our query basis?
CHARLES FAN: OK I'll start.
I'm sure Gus and Theo have more to add.
I think NoSQL is sort of part of this common, chaotic
phenomenon that we are seeing.
It's driven by a few factors.
Still by far, SQL is the most popular query language today.
But NoSQL is one out of the need for people for looking
for more flexible schema.
And they're developing applications.
Sometimes they have the data stay the same, but they want
to structure them differently.
And they want to do that in a more easier way.
And they want to relax some of the consistency requirement of
their databases so they can deal with scale in a much
easier and much better way.
And it's basically driven through
various different needs.
So there are different flavors of new
query model that emerged.
And I think there are no better name.
So the easiest to one is you call them what they are not.
It's just NoSQL.
I do see that there is a strong trend in terms of
developers embracing them.
But again there is no clear new winners
in the query languages.
And I think in different companies there may be
different preferences being set up.
It doesn't mean five, ten years from now,
there won't be one.
I think right now, it [? is in ?] the model, let
developers decide--
let the developers of the world decide--
whether there is a newer querying language that can
replace SQL as a new one.
GUSTAV HORN: I would only say that SQL is going to be around
for a long time to come.
I still run into companies that are running
COBOL, of all things.
It's not going anywhere, any time soon.
I think what NoSQL is-- versus SQL, versus any
of these other things--
is yet another way of exposing all these internal politics
and battles that happen in big industry.
And that you're going to have legacy databases that that's
the only way you can talk to that.
And you're going to have next generation things coming out.
And if it wins the battle, which I think it will, you'll
find NoSQL becoming more and more popular.
And you'll find more and more of these aggregate,
heterogeneous kind of data stores becoming more popular--
provided they provide the answers that
they're supposed to.
Which just means that they have to be faster.
They have to be infinite in volume and size,
and they can grow.
And they have to never forget anything.
That's kind of the key.
When we talk big data, I always get a laugh sometimes
because they say, well we only need a 200-node system.
I said, well, that's today.
What are you going to do in five years?
How are you going to grow that?
I mean the most important thing in big data--
it's not the complete computational engines.
That's the most volatile thing in your big data system.
You want to get rid of that old crap
anyway, every two years.
You don't want to have to then re-migrate all your data.
The most important thing-- and OK, so this little plug for me
from NetApp-- is that the data is what's important.
The thing that it runs on this the most volatile or least
important thing.
It's the thing that you want to be able to flush out, and
read, and make faster--
over and over again-- provided that data stays and you don't
have to move it.
Because moving stuff is a waste.
And in Google, you don't want to be moving data either.
That's wasted energy.
THEO VASSILAKIS: Absolutely.
And I agree with that point, that the systems change.
Many, many systems have changed over
the years at Google.
And we'd migrate it forward and the older storage
systems have died.
But the data is always there.
I'm pretty sure that Jim Gray, who's a Turing Award winner,
felt like he needed to apologize for SQL in his
Turing Award acceptance speech-- sorry for SQL.
And as a builder SQL systems, I think SQL will stay.
It's great.
But actually the only thing I would point out about it is, I
think it's main and most positive attribute is that
it's a declarative language.
Meaning, it doesn't say how to compute what you want to
compute, but it just says what you want as the answer.
And I think that that's the key characteristic that--
whatever the language is, be it SQL, be it something else--
will be important.
Because the bigger the computation is, the more
complex the program is that you would have to write if
you're writing a real procedural program.
And so you're going to need systems to actually turn that
into computation for you.
So whatever the language is-- maybe it's SQL, maybe it's a
variant, maybe it's something else--
if it's declarative, then it gives the maximum ability to
the execution system to actually do
the right thing fast.
HAL VARIAN: We do have a few minutes for
questions from the audience.
We have a hard stop at seven because of a plane leaving.
But questions?
Back there.
Speak loudly please.
AUDIENCE: [INAUDIBLE]
THEO VASSILAKIS: Sure.
Privacy and what are we going to do.
So the question is, what are we going to
do about data privacy?
How are we going to make these systems protect people's data?
I can give you one view from Google which is, obviously
privacy is one of the critical things that we do here.
In the sense that if people don't trust
Google, none of it works.
And I think I would go back to this point
about declarative languages.
I think in the early stages of the development of analytical
systems, you wrote things down to the metal
because you had to.
There was no other way to do it.
And that gave no safeguards for what people
did with the data.
That you had to give them a code of conduct and say hey,
you should only apply it like this.
But actually when you go up the stack and up the
abstraction level, and you say, look tell me what you
want to compute.
And the system will actually compute it for you, then you
have a lot of opportunity to actually apply policy--
privacy policy in particular--
in an automatic manner.
So I think that ultimately, that's kind of
the long-term answer--
is that there will be mediation between the people
asking the questions, and systems that are executing the
queries, that then apply the right policies there.
CHARLES FAN: And I think this question mostly apply to the
service provider-- the cloud analytics, big data analytics,
the service provider.
And VMware recently bought a company called Cetas.
And we're looking at the same problem.
There's customers of various online gaming companies
uploading their data into our services.
And there are various technology encryptions around
to protect the privacy.
But I think more important than technology, is really the
business model.
It's like you're operating an information bank, similar to a
bank for money.
So you can argue that, why would you give your money to
another service provider, rather than
keep it in your home.
But the thing is, as Google, as Cetas--
if you breach that, they cannot continue
to exist as a business.
So it's in every interest of the operating company, of the
service, to protect the privacy of their customers so
that it can continue to exist as a bank--
as a service provider, just like bank do to the money.
So arguably, in most countries in the world, putting money in
the bank is safer--
we have the chief accountant can tell if I'm wrong here--
than putting your money under mattress.
And similar, it can be argued is already better protection
of the privacy of data if you entrust it to a service
provider in most cases.
GUSTAV HORN: So in short, trust no one.
And I actually mean that.
I mean you shouldn't really trust the banks almost.
And you shouldn't trust service providers
to any great extent.
It has to be earned.
And this is always proven, time and time again.
I think Google has done a very good job.
For better or worse, people have argued about how privacy
statements can be morphed and changed.
Think nothing stays consistent.
Nothing will stay the same.
It will always change.
So the minute you let any of your private information out
there, even if you believe it to be private, and only
amongst a small circle of people, I would never make
that assumption.
If you want to keep something private,
you keep it to yourself.
That's the only way.
HAL VARIAN: Yes.
AUDIENCE: I have a similar question for both of you.
[INAUDIBLE]
Also, the four layers that you discussed, [INAUDIBLE]
GUSTAV HORN: You can have privacy in the data.
You can have control of your data.
For example, you can encrypt the data on the drive.
So you can encrypt the data throughout the past.
But if you hand the key to that data out to anyone, then
you've already basically unlocked the door.
So I think compliance, privacy, protection of data,
that's a very tough problem.
HAL VARIAN: I think that Theo's point was really an
excellent one.
That you can build a lot of this
compliance into the system.
So you just can't link this with that, unless you have
some specific override from higher up.
And one of the advantage of having those declarative
languages is exactly that.
That the system can enforce compliance in
ways that humans can't.
THEO VASSILAKIS: Right.
I think I would sort of see privacy as a special case of
compliance.
You want the data in your organization, in your cloud,
to be managed according to a set of rules.
Now those rules will sometimes be about protecting
individuals.
But sometimes they'll be about financial regulations, and
whether revenues can be viewed by certain people, or modified
by certain people, or whatever it is.
And so exactly.
I'm actually responsible-- or was up until recently-- for a
lot of our billing-related computation.
And those are a lot of the questions as well.
Who gets to be able to touch any of that
data along that path.
And I think I agree with you, trust no one.
But I would apply that more to people than to systems.
I hope that we can get the systems where the systems are
proven over time to have the right behaviors.
CHARLES FAN: Right.
And to the four layers, I do think compliance cuts across
the entire stack--
the entire environment.
From my experience, I had more experience with
the bottom two layers.
Compliance certainly big with both of those layers.
But I can imagine there're probably things on the
application layer that you need to pay
attention to as well.
OK.
HAL VARIAN: Well, on that note, let us thank the group,
and thanks for coming.
Thanks to all of you.