Why Big Data Needs InfiniBand to Continue Evolving

Increasingly, it’s a Big Data world we live in.  Just in case you’ve been living under a rock and need proof of that, a major retailer can use an unimaginable number of data points to predict the pregnancy of a teenage girl outside Minneapolis before she gets a chance to tell her family.  That’s just one example, but there are countless others that point to the idea that mining huge data volumes can uncover gold nuggets of actionable proportions (although sometimes they freak people out – for example that girl’s father). 

We’re still at the dawn of this Big Data era and as the market is showing, one-size-fits-all data processing is no longer adequate.  To take the next step in this evolution, specialized Big Data software can improve not only by using cloud computing, but also by utilizing specialized networking infrastructure, InfiniBand, from the supercomputing community.  Before understanding why, though, you need to understand the history of how we got to this Big Data world in the first place.

How Did We Get Here? The Birth of the Relational Database

1970 isn’t just the year of the Unix Epoch, it’s also the year that the granddaddy of all Relational Database (RDB) papers was written.  IBM Researcher E. F. Codd wrote “A Relational Model for Large Shared Data Banks” for Communications of the ACM magazine in June of that year, and it became the defining work on data layouts for decades.  Codd’s model would be refined over the next 40 years, but what he proposed evolved into a generic toolset for structuring and manipulating data that was used for everything from managing bank assets to storing food recipes.

This general-purpose data analysis software also ran exceptionally well on general-purpose computing hardware.  The two got along great, actually, since all you really needed was a disk big enough to handle the structured data and enough CPU and RAM to perform the queries.  In fact, some hardware manufacturers such as Hewlett-Packard would give away database software when you purchased the hardware to run it on.  For the Enterprise especially, the Relational Database was the killer app of the data center hardware business.

At this point, everybody was happily solving problems and making money.  Then something happened that changed everything and completely disrupted this ecosystem forever.  It was called Google.

Then Google Happened

During the Nixon Administration, copying the entire Internet was not a difficult problem given its diminutive size.  But this was not so by the late 1990s, when the first wave of search engines like Lycos and Alta Vista had supposedly solved the problem of finding information online.  Shortly thereafter, Google happened and disrupted not only the online search industry but also data processing.

It turns out that if you can keep a copy of the modern Internet at all times, you can do some amazing things in determining relevance and, therefore, return better search results.  However, you can’t use a traditional RDB to tackle that problem for several reasons.  First of all, to solve this problem you need to store a lot of data.  So much so, it becomes impractical to rely solely on vertical scaling by adding more disk/CPU/Ram to a system and a RDB does not scale horizontally very well.  Adding more machines to a RDB does not improve its execution or ability to store more data.  That disk/CPU/RAM marriage has been around for 40 years and it’s not easy to break apart.

Further, as the size of the data set in an RDB gets larger the query speed generally degrades.  For a financial services company querying trends on stock prices that may be acceptable, since that influences the time of a handful of analysts who can do something else while that processing is going on.  But for an Internet search company trying to deliver sub 3-second responses to millions of customers simultaneously that just won’t fly.

Finally, given the large data volumes and the query speed required for Internet searches, the necessity for data redundancy is implied since the data is needed at all times.  As such, the simple master-slave model employed by most RDB deployments over the last four decades is a lot less bullet proof than what is needed when you are trying to constantly copy the entire Internet.  One big mirror simply won’t cut it.

Distributed File Systems and Map/Reduce Change Everything

If Codd’s seminal RDB paper had grandchildren, they would be a pair of papers released by Google that described how they conquered their data problem.  Published in 2003, “The Google File System” by Sanjay Ghermawat, Howard Gobioff, and Shun-tak Leung described how a new way of storing data across many, many different machines provided a mechanism for dealing with huge volumes in a much more economical way than the traditional RDB. 

The follow-up paper from 2004 entitled, “MapReduce: Simplified Data Processing on Large Clusters” by Ghermawat and Jeffrey Dean further revealed that Google performs queries across its large, distributed data set by breaking up the problem into smaller parts, sending those smaller parts to nodes out on the distributed system (the Map step), and finally assembling the results of the smaller solution (the Reduce step) into a whole.

Together, these two papers created a data processing renaissance.  While RDBs still have their place, they are no longer the single solution to all problems in the data processing world.  For problems involving large data volumes in particular, solutions derived from these two papers have emerged over the past decade to give developers and architects far more choice than they had in the RDB exclusive world that existed previously.

Hadoop Democratizes Big Data; Now Where Are You Going to Run It?

The next logical step in this evolution in an era of Open Source programming was for somebody to take the theories laid out in these Google papers and transform them into a reality that everyone could use.  This is precisely what Doug Cutting and Michael J. Cafarella did, and they called the result Hadoop.  With Hadoop, anyone now had the software to tackle huge data volumes and perform sophisticated queries.  What not everybody could afford, however, was the hardware to run it on.

Enter cloud computing, specifically Infrastructure as a Service (IaaS).  Primarily invented by Amazon with its Amazon Web Services offering, anyone could lease the 100s if not 1000s of compute nodes necessary to run big Hadoop jobs instead of purchasing the physical machines necessary for the job.  Combine that idea with orchestration software from folks like OpsCode or Puppet Labs and you could automate the creation of your virtualized hardware, the installation and configuration of the Hadoop software, and the loading of large data volumes to minimize the costs of performing these queries.

Again, everybody is happily solving problems and making money.  But we aren’t done.  There’s another step to this evolution, and it’s happening now.

InfiniBand: Making Hadoop Faster and More Economical

Processing Hadoop and other Big Data queries on IaaS produces results, but slowly.  This combination is praised for the answers it can find but at the cost of reduced speed.  We saw a data processing revolution sparked by different software approaches than those pioneered in the 1970’s.   Better-performing Hadoop clusters, with all the network traffic they produce in their Map and Reduce steps, can be found by taking a similar approach with a different network infrastructure.

Ethernet, the most widely used network infrastructure technology today, has followed a path similar to that of RDBs.  Invented in 1980, Ethernet uses a hierarchal structure of subnets to string computers together on a network.  It is so common that, like RDBs 10 years ago, most people don’t think they have a choice of something different.

The performance problem with Ethernet comes in its basic structure.  With hierarchies of subnets connected by routers, network packets have exactly one path they can traverse between any two points on the network.  You can increase the size of the pipe between those two points slightly, but fundamentally you still just have the one path.

Born in the supercomputing community during the 21^st Century, InfiniBand instead uses a grid system which enables multiple paths for network packets to traverse between two points.  Smart routing that knows what part of the grid is currently busy, akin to automobile traffic reporting found on smart phone map apps, keeps the flow of traffic throughout the system working optimally.  A typical Ethernet-based network runs at 1 Gigabit per second (Gb/s), and a fast one runs at 10 Gb/s.  A dual-channel InfiniBand network runs at 80 Gb/s, making it a great compliment to Map/Reduce steps on a Hadoop cluster.

We’ve seen how a software revolution getting us past the exclusive use of RDBs has enabled data mining that was previously unimaginable.  Open Source and cloud computing have made Big Data approachable to a wider audience.  Better speed, resulting in shorter query times and time reductions needed in leasing IaaS space, is achievable using public cloud providers offering InfiniBand.  This is the next step in the data processing revolution and the next generation of Cloud Computing services (also known as Cloud Computing 2.0) bring InfiniBand to the public cloud.  ProfitBricks is the first provider to offer supercomputing like performance to the public cloud at an affordable price.  Data is becoming democratized, and now High Performance Computing is as well.