Friday, 20 March 2015

Big Data in Cancer

We recently organised a workshop on 'Big Data in Cancer', as part of a year-long programme to launch Warwick's new Data Science Institute.  It was a fascinating day, with four brilliant speakers (Florian Markowetz, Andrew Teschendorff, Paul Moss, and Sean Grimmond) and covered a lot of important topics.

Florian was first to speak, and led off with some conceptual and philosophical points about Big Data, which I think are hugely important.  There is, of course, a lot of hype surrounding Big Data and what it's capable of.  The more 'enthusiastic' supporters even argue that it makes the scientific method obsolete.  I share Florian's view that this is kind of silly; no matter how much data you have, there is still a difference between correlation and establishing a causal link, for example.  And patterns in data are not the same as establishing underlying general rules.  Yes, you can map out a rule using data if you have enough of it, but wouldn't you rather just have a simple formula?  Rather, Big Data is a technical challenge (how do we handle it), with the pay-off being smaller variance in our estimates, more detail about the things we are studying and the like.  For example, getting a much more detailed description of the heterogeneity and evolutionary history of a given tumour.

Andrew told us about some of his work in epigenomics.  This is a fascinating topic that I'm trying to learn more about, but is seems that tumours come with an explosion of epigenetic modification throughout the genome, which contains potentially all sorts of information that may allow us to diagnose cancer, its type, and its likely progression.  The early detection of cancer is a hugely important area of translational research, which makes this doubly exciting.

Paul gave us a whistle-stop tour of some areas of cancer research.  He talked a lot about the potential for electronic health records and Health Episode Statistics data, something in which the Queen Elizabeth Hospital in Birmingham is really leading the way, with a serious informatics infrastucture. To my mind, this is part of a coming revolution in healthcare where all relevant medical data are stored electronically in integrated databases, which turns medical research into a software/algorithms problem.  Evidence from other areas of human endeavour suggest that this will be a huge driver of the pace of innovation.

Finally, we were treated to a great talk by Sean, who's heavily involved in the International Cancer Genome Consortium and has recently moved to the UK to pursue the translational aspects of genomic medicine (note: the NHS and the UK's science base makes us world-leading in this area, and this means we can attract the world's best researchers).  I was really grabbed by just how rapidly genomic medicine is scaling, in terms of data volume.  The cost to sequence a whole human genome has dropped from ~$100m (2001) to ~$1000 (2014), an incredible 5 orders of magnitude in 13 years (think about that for a moment...).  With the UK's 100,000 genome project already underway, the US recently announcing a 1,000,000 genome project, and China undertaking a similar scale project, we are just about to be awash in genomic data.

The limiting factor in translational cancer research is about to become our ability to effectively handle and use the flood of data that we're just seeing the first trickles of.  This is a hugely exciting time to be involved in cancer research, but we all might need to buy bigger computers...

Monday, 31 March 2014

Big Data - in the process of growing up

A very good article was published in the FT online a few days ago.  Its title is 'Big Data: are we making a big mistake', and it's a commendably well thought out discussion of some of the challenges of Big Data.  And perhaps a bit of a warning to not get too carried away :-)

You should go and read the full article, because it's got loads of great stuff in it.  A few of the concepts that leapt out at me in particular were the following.

One of the interesting things about modeling data in order to make predictions (as opposed to explain the data), is that features that are correlated to (but not causal for) the outcome of interest are still useful. But, the FT article makes the really good point that even in this case, correlations can be more fragile than genuinely causal features.  This is because while a cause is likely to remain a cause, correlations can more easily change over time (covariate drift).  This doesn't mean we can't use correlation as a way to inform predictions, but it does mean that we need to be much more careful and be aware that the correlations may change.

The article also discusses sample variance and sample bias.  This is in many ways the crux of the matter for Big Data.  In principle, very large data sets offer us the chance to drive sample variance towards zero.  But it really has much less to offer in terms of sample bias, and indeed (as the article points out) many of largest data sets, because of the way they're generated, are actually very vulnerable to high levels of sample bias.  This is not to say that one can't have both (the large particle physics and astrophysics data sets are great examples where both sample variance and sample bias are addressed very seriously), but it is a warning that just because your data set is huge, it doesn't mean that is is free from sample bias.  Far from it.

I've felt for a while that 'Big Data' (and data science) are currently going through a rapid phase of growing up, which I suppose is pretty inevitable because they're in many ways new disciplines.  They've gotten up to speed on the algorithmic/computer science side of things very rapidly, but are still very much in the process of learning many of the lessons that are well-known to the statistics community.  I think this is just a transition phase (these things take a bit of time), but it seems clear that a big part of the maturation of Big Data/data science lies in getting fully up to speed on the knowledge and skills of statistics.

Friday, 20 December 2013

Programming for Scientists

I used to co-write a blog called 'Programming for Scientists'.  All the posts from that blog can now be found here, under the tag Programming for Scientists.  Go take a look!

My co-author on that blog was my good friend Ben, who's a professional programmer, so between the two of us (programmer-interested-in-science and scientist-interested-in-programming), there should be some articles there that have stood the test of time :-)

The 'About' for this blog was this:

Just another blog about programming?

Well, not so much.  This is a blog about building better (scientific) software.  We’re making two important distinctions here.  The first is that developing a piece of software is about much more than just writing the code, important though that is.  The second is that for many people, scientists for example, building software is something they do in order to achieve their primary goal.  What we mean by this is that scientists’ primary goal is to do great science.  But to do this, they sometimes need to write some software.  So while they need as many software development skills as possible, they really need the ones that will allow them to build the tools they need and, critically, do a good job as quickly as possible so they can produce more good science.  We suspect there are lots of people for whom this is true, not just scientists.  

The aim of this blog is to explore ways of building better software, but to do so bearing in mind that the ultimate goal is to produce as much great science as possible.  This doesn’t mean coding as quickly as possible, which produces buggy, horrible software; it means drawing from the huge body of software development knowledge for minimising the amount of time it takes to build really reliable software that you can then use confidently to do your science.  We won’t be telling you the “best” way to do anything (there’s usually more than one) and we won’t be handing down stone tablets saying that you must do something without good reason.  What we will do is present a range of techniques, thoughts and considerations and try to explain why we think they’re helpful.  You should use somewhere between none and all of these, depending on what you find most useful.  

We’re not here to tell you how you should go about developing your software, we’d just like to suggest a few things that other people, ourselves included, have found useful. 

We hope you enjoy the blog and find it useful!  

Thursday, 12 September 2013

The DREAM Toxicogenetics Challenge

So, we entered a team (WarwickDataScience) into the DREAM Toxicogenetics Challenge and we've managed to win the leaderboard stage!  It's a really interesting (and challenging) problem, so we're really pleased :-)

I wrote a blog post detailing our approach to the modelling, which can be found here.

Tuesday, 8 January 2013

What is Science?

I think a lot about science and the scientific method.  These are very complex topics, but the more I think about it the more I'm convinced their fundamental basis is very simple.

Science is evidence-based reasoning.

Everything else is implementation detail.

This is a very powerful thought because it's hugely general.  We have a provably unique set of mathematical rules that underpin it (probability theory), the human brain has an excellent track record at generating new scientific ideas, and we're getting better and better at generating new empirical evidence (data).

It also begs an interesting question:  If this is the essence of science, how can we improve our ability to do it effectively?

Food for thought...