[MUSIC PLAYING]
BRUNO AZIZA: Welcome to another episode of "Data Journeys."
I'm Bruno Aziza, and this is the place
you come to learn from data and analytics
leaders, their successes, their growth, their best practices,
and their worst practices.
And today, I have the pleasure to talk to Matt.
He's the chief data architect at MoneySuperMarket Group.
Matt, Thank you so much for taking the time
to talk to us today.
MATT CRESSWELL: Thank you for having me, Bruno.
BRUNO AZIZA: All right.
Well, so you won one of the Customer of the Year awards
this year, and you've got lots of best practices.
But let's get started with the basics.
What does the company do?
MATT CRESSWELL: Well, we set out-- our purpose
and our mission is to save UK households money.
So we're one of the UK's leading price comparison websites,
so offering insurance products, home services, and money
products to the entire UK.
BRUNO AZIZA: That's excellent.
And tell us a little bit about your data situation, federated
and siloed data, the need for agility.
What's the picture for your company for data?
MATT CRESSWELL: Well, this is actually the third marketplace
business I've worked in.
And a marketplaces are great for data.
And MoneySuperMarket is a data business.
So we get so much information from customers
when they're buying products and filling question sets.
But what we have found is lots of our data
is just siloed in different tech stacks for different channels.
And the business has grown really well commercially
and successfully.
But the cost of that has been just that siloed piece of data.
So we find lots of projects that start,
and you know where it begins.
And so can we get the data, and it's working
with different tech teams.
And we are a digital business, and we've just
got so many engineers making changes
across all those channels.
So keeping up with the rate of change and evolving schemas
has been a real challenge for us.
It's something that we're trying to solve
now through for a bit of a platform play,
really, to try and bring all this data together
into a central place.
BRUNO AZIZA: So take us through that journey.
What does it look like when you produce so much data, and data
from everywhere, really, and then try and bring it
into one place?
What does the journey look like?
MATT CRESSWELL: It's really interesting for me.
I think being the receiver and the consumer of all this data
can be really challenging.
So one of the tech principles which I think is really good
is, the front end is very event-based.
So we have lots of semi-structured, low-latency
data flowing through, through Kafka.
So really our challenge was, how do we
start to build our data platform so it's event-driven,
so it works well with that event architecture?
I think where we came from is, you
can fall into a bit of a trap where you just want to try
and batch that event data up to ingest it
through traditional ETL tools.
And I think one thing that we've really focused on
with our journey with GCP is, how do we
be event-first in terms of how we collect that data across all
of those different teams?
BRUNO AZIZA: Now, 2 million events per day--
what types of data are you using?
What is the data that's coming through,
and what do you do with it?
MATT CRESSWELL: I mean, that's the biggest question for us,
where the most value is.
So yeah, we do ingest 2 million events per day.
They come from a whole range of different microservices.
It could be events that are related to customers running
inquiries on the website.
It could be results coming back to them.
It can also be click-out events, where
they're clicking through to one of our providers
to complete a purchase.
Or it could be a new product going live.
Our real challenge is, how do we collect all of that data
and bring it into one place?
One of the biggest use cases we have for data,
and I think loads of people relate to this,
is how can we use our data to be more efficient in how
we acquire customers?
So if we know about our customers,
and we know how many inquiries they've done,
how can we tell who our best customers are?
And then when they're in the PPC world
or trying to search through web or Google,
how can we target them with the better offers and better
prices?
But there are a whole host of other use cases, too.
I think one area we want to get to over the next year
is definitely how we make our business more efficient.
So how do we give them more data so they
can make better-led decisions than they do today?
BRUNO AZIZA: Now of course, you've
got all types of data, some unstructured, structured.
Some of it's sensitive.
Some of it's less sensitive.
So tell us a little bit about how
you deal with the sensitivity of your data.
MATT CRESSWELL: I think that's one of the things we're
most proud of.
So for the last year, we've set ourselves out
on a strategy to re-platform and bring our data together
in BigQuery.
And we deliberately picked BigQuery because
of its use of policy tags.
So within those 2 million events we ingest per day,
there's a total of around 64,000 columns of data points.
So our challenge, really, what we're trying to solve for,
is, how do we give people access to those 64,000 columns
without letting them see sensitive information?
And using policy tags to enforce our data classification
was key to our success.
So you can almost imagine, we built this taxonomy,
this hierarchy of what our data looks like in terms
of classifications, and we've applied that
into our data via BigQuery.
So as soon as you open BigQuery now,
you can see all of the columns, but you can see
what classification they have.
So that's been a big win for us.
BRUNO AZIZA: And the architecture
looks like Pub/Sub, Dataflow, BigQuery.
Take us a little bit through the stack
and how you organize yourself, as well as
the talent around this new architecture
you've been building over the last few years.
MATT CRESSWELL: It's really interesting.
So before, we had an 11-step process
that got data from source into a data platform.
It's a bit like "Dancing With the Stars," to be honest.
How many of the routines have that many steps?
So we actually managed to simplify it quite a lot.
So we have a consumer that brings the data over
from Kafka, and we land it into Pub/Sub, which is great.
So we've always got a copy of our data
in Pub/Sub for us to start processing.
At that point in time, we use Dataflow to bring that data
into BigQuery.
And it's got a few tricks.
So that classification process I talked about--
Dataflow is the tool that we use to enforce all of that.
It's also the tool that we use to take some quite gnarly JSON
and put it into a nice, friendly BigQuery table.
So if you looked in our environment,
you would just see a simple--
here's an event that just flows through
into its own destination table.
And we have one table per topic.
What that means is that if you're an analyst,
you can just write a simple few lines of SQL
to get hold of any raw data.
So bye-bye to building Jupyter Notebooks and Python
code to open flat files.
It's all there waiting for you.
That process, Pub/Sub, Dataflow, BigQuery,
takes about three seconds.
So that's the average time we see
an event loading from Kafka right
the way through into BigQuery.
BRUNO AZIZA: And so you mentioned many steps before.
How many steps do you have now, and what's
been the strategy for scaling to new volumes of data?
MATT CRESSWELL: So I think it's three to four
steps now, depending on which route the data takes,
which is great.
So that's really helped us get really close to, I guess,
where our customers are putting in data
and where our analysts can see that information in real time.
Our strategy-- again, that reinforced why
we picked Pub/Sub and Dataflow.
So we had a task to--
we built this data platform, we launched it,
we collected all the new data.
But we have three years of history sitting in S3.
So over a weekend, we set ourselves the challenge
of ingesting all of that data, replaying it
through our pipeline.
And it took the weekend, but it was around--
our pipeline scaled up to 150 workers.
So normally, it's around four workers in Dataflow.
It scaled to 150, processed almost 7 million flat files
and 150 terabytes of data.
And it did that without anyone having to do anything.
It automatically scaled.
So our analysts went home on Friday
night just seeing a bit of recent data.
They came back Monday morning, and there was three years
of history sitting in BigQuery.
So that was phenomenal.
BRUNO AZIZA: That's pretty amazing.
From a different cloud into the Google Cloud over a weekend--
that's not a surprise, then, that you got
the Customer of the Year award.
Now let's drive into your experience
beyond just this company.
This is not your first rodeo in the data world
and building intelligent data lakes like this one.
What are your best and worst practices?
Let's start with the best practices.
Let's start with the good news.
What are the few things that you think is essential for anyone
starting on a journey that's similar to yours?
What should they be thinking about first?
MATT CRESSWELL: One, I think simplify.
Try and keep things simple.
And there's a couple of best practices
that I think I've learned along the way.
One is, the technology has moved on
so much that you don't have to worry about transforming data
before you store it.
So I think things like BigQuery and storing raw data
and just loading it--
so you get source data, and you just
load it into the same format.
You don't try and restructure it or transform it.
I think that simplifies things.
And you hear this term called "dark data."
And I really point at that term, where people are
trying to transform the data.
And you get all this raw data that just disappears.
And we found about 80% of the data that
was flowing through the business never was seen by an analyst.
So I think to try and solve that, just landing
data in its raw format is a good option.
I think the other thing I've learned in the amount of jobs
I've been into, where there's been capacity problems
on a Monday morning or at month end,
and trying to plan how much infrastructure you need.
Do you plan for the peak?
Do you plan for the median?
Do you sacrifice if you go for the median
that people are going to be complaining that things
run slow on a Monday?
That's a thing of the past with serverless as well.
So it doesn't take the problem away completely,
but I think it really gives people
the opportunity to focusing on building,
rather than trying to solve a gnarly problem like how
much infrastructure you need.
And so I think they would be the two
big things from typical projects I've experienced in the past.
I think the final one would be, privacy
is becoming more of a thing.
And I think in the UK, legislation
around GDPR and cookies is only going one way.
So it's going to become a bigger thing.
So I think focusing on privacy from the start
is a lot easier than trying to do it once you've
launched a platform.
So again, it might take a little bit longer.
But focusing on classification policy tags,
getting people used to using pseudonymized data and not
real data, is a big thing to focus on.
BRUNO AZIZA: This is interesting what
you're saying around the switching from ETL
to ELT, because so much of the data gets lost in the shuffle
if you do it the other way.
I'm sure that's a good one for people to take on.
Now, what about the opposite of that?
What are the worst practices, maybe the lessons
that you've learned, either personally
or you've witnessed others, and that you think
you've got to watch out for it?
It might make sense at first, but actually is not
the first thing to start with.
MATT CRESSWELL: That's a really good question.
You sort of warmed me up to this before,
and I was trying to think to it.
There's been loads of mistakes that we've made along the way.
If I look back to previous roles,
we ended up building a lot more than we perhaps should have.
So definitely, things are moving so fast in the data space.
So using things like Composer, using things like Workflow,
really saves your time rather than building
your own orchestration element or framework
for processing data.
I think that would be one.
And I think the other piece is probably around capacity
as well.
So I hadn't realized how flexible it
is to think about your project structure in GCP,
and what things you put where, and what users you put where,
and service accounts.
And I think that plays a big part as well.
So we spent a lot of time cleaning up
where our service accounts live, what project,
and how many slots that project gets,
versus where all our users sit and how many slots they get.
So I think it would be, spend a bit of time on the things
that you don't really appreciate have a big impact.
BRUNO AZIZA: Well, Matt, thank you
so much for the insights today.
Going from ETL to ELT, to discover that dark data,
thinking about privacy administration first--
even though that might sound boring, it's essential.
I want to thank you for the time today.
MATT CRESSWELL: Thanks for having me.
BRUNO AZIZA: And I hope this is just
the beginning of a conversation, that people will reach out
to you.
In fact, if they want to hear more stories just
like this one, click on the link down below.
Until next time, I'm Bruno Aziza.
[MUSIC PLAYING]