Hyperacceleration with Bigstream Technology

Figure 3: Scaling Up vs. Scaling Out

Figure 3 illustrates these two approaches to scaling. In this example, both approaches increase the number of virtual CPUs (vCPUs), increasing the computing power. It is also possible to scale in other ways, such as adjusting network connections, memory, disk, or other resources. 

In almost all cases, scaling yields a sub-linear performance increase as resources are added. That is, as the cluster is scaled by a factor of N, performance increase is less than N. This diminishing return is severe at large scale. The technical reasons for this are listed below:

Scale Up

• Increased I/O overhead/throttling
• Shared resource contention (memory, L2 cache)
• Scheduling complexity increase

Scale Out

• Increased network overhead
• Straggler effect exacerbated
• Failure rate increase

Bigstream Hyperacceleration improves scaling in two ways: 

1. It reduces the size of the cluster needed to yield a given performance level. 
2. It reduces the overhead of some of the above factors—such as network and I/O)—thus reducing their impact.

Figure 4: The Scaling Issue—Experiment Results

Figure 4 illustrates the scaling issue. In this example, we conducted experiments showing scale up. We ran two TPC-DS () benchmark queries on Amazon EMR using Spark, in various cluster scenarios. Moving from left to right, each point represents the performance for a given number of vCPUs. The cluster size doubles with each step to the right (16; 32; 64; 128; 256 vCPUs). The vertical axis, “Speedup,” is calculated relative to the “Base.” The speedup performance of both benchmarks fall off from the grey linear line as the cluster scales, as predicted above.

Figure 5. Results of Scale Up Experiment with Spark and Accelerated Spark 

Next we ran the same experiment on clusters equipped with Bigstream software-based acceleration. Figure 5 shows the combined results—the dashed lines are the unaccelerated runs from Figure 4, and the solid lines are Bigstream accelerated. 

he accelerated curve displays a much more gentle falloff with scaling than the Spark curve.  So for a given cluster size, Bigstream generates significantly more speedup than Spark alone (the vertical difference between the two lines). Another way of analyzing this, though, is to note the horizontal distance and the fact that Bigstream provides nearly the same speedup at 64 vCPUs as Spark does alone with 256 vCPUs. 

We see similar results with scale-out experiments. These results indicate that acceleration can work synergistically with scaling, to provide maximum performance and a wide variety of performant configuration choices for the user. This, in turn, can result in total cost of ownership (TCO) savings. Cloud users can use smaller clusters or use of the same cluster for a shorter time period for a given analysis. Users with on-premises clusters will be able to run faster applications and accomplish more in a given time period. 

FPGA Acceleration

As discussed, hardware-based acceleration has the highest performance potential. Adding an FPGA to a server can be a cost-effective way to speed up big data platforms, if it doesn’t come with additional complexity. These chips are typically a fraction of the cost of a full CPU-based server.

Figure 6: Bigstream Acceleration Benchmark Tests 

*Each query was run in 5-node clusters, first on AWS R5.2xlarge instances and then F1.2xlarge instances with Bigstream.

Figure 6 illustrates the results of a separate set of benchmark tests comparing Spark alone versus Spark with Bigstream FPGA-based acceleration. 104 TPC-DS benchmark queries were run with Spark in a CPU-only platform as the baseline, and then again using Spark along with Bigstream and a FPGA platform. 

The average speedup across the 104 queries was 5.5x, with some queries as much as 8x faster with Bigstream and FPGAs. As with all Bigstream Hyperacceleration, no Spark code needed to be changed in the accelerated runs.