At the moment, the world is obsessed with “Big Data” yet it sometimes seems that people who use this phrase don’t have a good grasp of its meaning. Like most good buzz-words, “Big Data” sparks the idea of something grand and complicated, while sounding ordinary enough that listeners feel like they have an intuitive understanding of the concept. However “Big Data” actually carries a specific technical meaning which is getting lost as the term becomes more popular.
The phrase’s predecessor, “Data Mining” was equally misunderstood. Originally called “database mining” (a subsequently trademarked term), the term “Data Mining” became common during the 1990s as many businesses rapidly adopted the use of relational database management systems (RDMS) such as Oracle. RDMS store, optimize, and manage large amounts of data on physical disks for the purpose of rapid search, retrieval and update. These large collections of data enabled businesses to extract new knowledge useful to their business practices by examining patterns within their data. Data mining refers to a collection of algorithms that attempt to extract knowledge (in the form of rules or associations) from large amounts of data by processing it in place on the disk, either within the RDMS or within large flat files. This is an important distinction, as the optimization and speed of algorithms that access data from the disk can be quite different from those which examine data within active memory.
A great example of data mining in practice is the use of frequent itemset mining to target customers with coupons and other discounts. Ever wonder why you get a yogurt coupon at the register when you check out? That’s because across thousands of other customers, a subgroup of people with shopping habits similar to yours consistently buys yogurt, and perhaps with a little prompting the grocery vendor can get you to consistently buy yogurt too.
As random access memory (RAM) prices dropped (and virtual memory procedures within operating systems improved), it became much more feasible to process even extremely large datasets within active memory, reducing the need for algorithmic refinements necessary for disk-based processing. But by then, “data mining” (marketed as a way to increase business profits) had become such a popular buzz-word, it was used to refer to any type of data analysis.
In fact, it has been tacked on to numerous books and publications about machine learning methods purely for marketing purposes. Supposedly even some publishers have modified the titles of machine learning books to include the phrase “data mining” with the hope that it will improve sales. As a result, the colloquial meaning of data mining has become “a vaguely defined way to discover patterns in data”. To me, this is a tragedy because we have lost a degree of specificity in our language simply because “data mining” sounds cool and profitable.
Zoom forward to the present day and we see history repeating with the phrase “big data”. With the increasing popularity of cell phone technologies and the internet, the last decade has seen a dramatic growth in data generated by commercial transactions and online websites. Many of these large companies (think Google’s Search Indices or Facebook and LinkedIn network data) generate data on such a large scale that it cannot be managed within traditional database systems. These groups have instead turned to large computing clusters that distribute the data over many, many separate machines and file systems. Partitioning data in this way requires a new class of algorithms that can take advantage of the fact that individual processing units (or nodes of a computing cluster) house their own subset of the overall data. This is a fundamental paradigm of “Big Data” algorithms, making it distinct from other machine learning and data mining techniques.
A great example of a “Big Data” programming model is the MapReduce framework developed by Google. The basic idea is that any data manipulation step has a Map function that can be distributed over many, many nodes on a computing cluster that then filter and sort their own portion of the data. A Reduce function is then performed that combines the selected and sorted data entries into a summary value. This model is implemented by the popular Big Data system Apache Hadoop.
All of the fuss over “Big Data” is driven by these massive producers of data (on the order of hundreds of terabytes a day), yet the ideas behind “Big Data” are being applied on much smaller datasets even when they are not necessary. In fact, a rather amusing read from Microsoft Research describes the overhype of “Big Data” algorithms and the surprisingly few analytic operations that truly need these approaches. The hype is alive and well in the medical and biological research community as well. In fact, there is an NIH initiative to fund “Big Data to Knowledge”. I’m the first to cheer for projects dedicated to large-scale data analysis, but by nearly any definition, right now there is no such thing as biomedical Big Data.
There are certainly processes in biomedical research that produce large amounts of data – first among them is next generation sequencing technology. In sequencing studies, the raw data from sequencers is aligned and processed to extract the meaningful information (i.e. SNP and CNV calls). After processing, a full human genome will nearly fit on a floppy disk, which hardly qualifies as “Big Data”. While there may be some interest in storing the raw underlying data (sequence reads), it may prove much more cost effective to simply regenerate the data. Based on an excellent analysis by Glenn Lockwood, storing four weeks worth of HiSeq X10 raw data may cost nearly $10,000 a month. If instead we store derived features from the raw data, data storage and manipulation is on the order of typical imputed GWAS. There will undoubtedly be a desire to reprocess this raw sequence data with new algorithms, but unless storage prices drop rapidly, regenerating the data will be more cost-effective than storage. Therefore, in my opinion right now the closest thing to qualifying as Big Data would be large multi-center electronic medical record systems, yet even these are typically managed by large-scale relational database systems.