Email delivery: Hate phishing emails? You'll love DMARC

While supercomputers and workstations have Linpack to rank their number-crunching performance, when it comes to sorting algorithms to rank Big Data systems, there is a collection of tests known as the Sort Benchmarks. And this year it looks like Hadoop is back on top after commercial distie MapR Technologies beat the MinuteSort benchmark on a virtual cluster on Google's Compute Engine service. The victory of the MapR guys marks the end to a one-year Hadoop hiatus - Microsoft researchers and techies from its Bing search division scored a shock win on 2012's MinuteSort test.

The Sort Benchmarks come out of the former Digital Equipment, which put forth two of the original data-sorting tests in 1994. Like many DEC employees, Jim Gray, who administered the Sort Benchmarks, moved to Microsoft, and others have taken over the task since Gray was lost at sea in 2007. (Not metaphorically, but quite sadly, literally.)

The two current tests that are used are the MinuteSort and the PennySort. The MinuteSort test counts how many bytes of data you can sort using the benchmark code in 60 seconds. That data consists of 100-byte records, which have a 10-byte key and 90-bytes of actual data. The data is randomized and you have to either sort it in ascending or descending order - the test counts how much data you can sort in 60 seconds. The PennySort test measures the amount of data you can sort for a penny's worth of system time on a machine or cluster. Other tests, such as GraySort and TeraByte Sort, have been deprecated. The tests come in a "Daytona" version, which is like a stock car test that doesn't allow specific kinds of tuning, and an "Indy" version that does allow tweaks and tuning to push up performance.

Microsoft Research made big waves last May in the Hadoop world with a new algorithm called Flat Datacenter Storage, or FDS, which threw the MapReduce approach used in Hadoop into the garbage can. Microsoft was very vague about how FDS worked, but it looks like server nodes were hooked to an external data storage array by a 10 Gigabit Ethernet network arranged as a CLOS network with full-bisection bandwidth.

Here's the trick: That FDS storage array allowed the entire data set for the MinuteSort to be stored as a single object, and the 256 servers running the test randomly grabbed storage addresses on the data set blob, chewed through them and assembled the results very quickly. At the time the MinuteSort test was done, the Microsoft FDS MinuteSort research paper was not available, but you can see it here now (PDF). The important thing is that in Daytona mode, Microsoft could chew through 1,401GB of data in the test in 59 seconds and in Indy mode it could do 1,470GB in 59.4 seconds.

That Microsoft FDS setup kicked the tar out of a cluster setup by Yahoo! in 2009 running an early version of Hadoop that had 1,406 nodes and 5,624 disks that could process 500GB in a minute. This was a Daytona configuration of the MinuteSort - Yahoo! did not do an Indy version. A team at the University of California San Diego won the Indy MinuteSort race in 2010 with a 52-node cluster of HP ProLiant DL360 G6 servers and a Cisco Systems Nexus 5096 switch. This machine, called TritonSort (PDF), was able to sort 1,353GB of data in 60 seconds.

Enter MapR last week with a virtual cluster built inside of Google Compute Engine. The official result has not been published on the Sort Benchmark page yet, but in a blog post, MapR techies Yuliya Feldman, Amit Hadke, Gera Shegalov, and MC Srivas say they have put Hadoop back on top in the MinuteSort test.

MapR threw a lot of virtual iron at the problem, and left all of the normal logging and data replication features of its M5 Hadoop distribution running during the test. So presumably this is a Daytona version of the test, not an Indy version. MapR slapped the MinuteSort test code on 2,103 instances on the Google Compute engine infrastructure cloud. It chose the n1-standard-4-d virtual server instances, which have four virtual cores, 15GB of virtual memory, one virtual Ethernet adapter, and one 1.7TB virtual disk each. MapR put one mapper and one reducer on each virtual server, for a total of 2,099 each, with four virtual nodes to manage the cluster.

The way the MapR MinuteSort works is like this: Each mapper reads 714MB of the randomized data from the disk on each virtual node, sorts it like a bat out of hell, and then writes it to 2,099 separate partitions of 341KB each. Each partition on each node is a separate file, and the entire Hadoop stack creates 4.4 million files in about 10 seconds. Then, the reducers grab the partitions from the nodes and do a 2,099-way merge, which is called the shuffle phase, and it takes about 20 seconds to fetch the data and about 17 seconds to merge-sort the data. There's another 5 seconds for straggler tasks that don't finish on time.

In doing the 1.5TB MinuteSort test runs, MapR saw that the cluster would stop dead for two to four seconds between the various phases, which is a long time in a 60-second test. To stop this and make Hadoop run more smoothly, MapR hacked the JobTracker and TaskTracker workloads schedulers. MapR also did some work to make its reducers parallel, as it has already done with the mappers.

This is a big jump for MapR, which demonstrated that it could sort 1TB in a minute last October on a 1,256-node virtual cluster that was also built atop Google Compute Engine. ®

5 ways to reduce advertising network latency