In their widely followed 2017 Hype Cycle for Data Management, Gartner’s declaration that Hadoop was “obsolete before plateau” marked a fascinating milestone in the evolution of big data. Big data hasn’t gone away of course. In fact, according to Dresner Advisory Services’ 2018 Big Data Analytics Market study, it is more relevant than ever with enterprise adoption growing at a CAGR of 36% since 2015. If anything, Hadoop’s premature demise reflects the availability of newer and better tools to manage and analyze big data.
New workloads fuel the rise of Apache Spark
Since exploding on the scene in 2012, Apache Spark (Spark) has enjoyed rapid adoption and become an essential big data technology. It presents a simple programming interface accessible from multiple data-science friendly languages including Python, R, Scala, and Java. It provides a vast number of data connectors and a familiar Spark SQL interface enabling analysts to use a single tool to manipulate data from multiple sources. Also, it provides access to not only data at rest (from diverse sources including S3, DB2, Cassandra or Elasticsearch) but also streaming data using a common programming approach. Finally, its in-memory design and built-in transformation primitives make it fast – up to a hundred times faster than Hadoop MapReduce depending on the algorithm. [Download Spark for Dummies to learn more about Apache Spark]
While all these capabilities are contributors to Spark’s success, it is the perhaps the last characteristic – performance – and native support for scalable Machine Learning algorithms (MLlib) that have been most critical. Machine Learning (the idea that computers can learn from data to get better at performing specific tasks) is not new, but Spark has made it practical to iterate over enormous datasets quickly paving the way to better analytic and predictive models in every industry from financial services to healthcare to transportation to retail.
Despite Spark’s success, there are cracks in the foundation
While Spark provides advantages for iterative machine learning workloads, as these workloads have been deployed in the enterprise they’ve exposed some serious limitations with Spark. Strides have been made in making Spark multitenant, but it continues to exhibit some of the same foundational challenges as Hadoop, it’s predecessor.
Building and maintaining machine learning and deep learning models requires expertise across multiple disciplines. In large organizations, it’s common to find dozens or even hundreds of users across multiple lines of business running and collaborating on Spark applications. Applications range from batch-oriented ETL workflows to ad-hoc queries to shared portal-deployed notebooks such as Jupyter. Data scientists want fast interactive response times and business users need business critical ETL and reporting jobs to complete on time.
But Spark applications are unwieldy beasts under the covers. Each application is assigned a dedicated set of Spark Executors running across cluster nodes in their own Java Virtual Machines (JVMs). In standalone mode (Spark cloud services often operate this way) it is assumed that applications will consume an entire cluster. It’s not practical to give each user a standalone cluster, so managing service levels has become a critical issue.
Why today’s resource managers fall short
Cluster resource managers such as YARN and Mesos help, but what they really provide is coarse-grained resource sharing across applications. The process of dynamically shifting executors between applications is slow and clunky. Also, these resource managers do nothing to optimize execution in the context of Spark applications. Internally, jobs in Spark are divided into stages with different numbers of tasks at each stage. By default, Spark uses simple first-in, first-out (FIFO) queueing executing each multi-stage job in sequence within an application. While it’s possible to share resources within a Spark application context, sharing is modeled after the Hadoop Fair Scheduler. Task-level scheduling in Spark doesn’t account for things like data locality, or that each stage in a job may require different resources. As a result, Spark tends to over-subscribe resources resulting in slower execution and less efficient use of infrastructure.
Different Spark applications frequently operate on the same data. Another painful aspect of Spark’s design is that since each application runs in its own context with its own executors, multiple applications often load the same data resulting in replicated in-memory datasets spread across cluster nodes. This is both slow and inefficient. Ideally, multiple Spark applications should be able to share a context and access the same in-memory datasets.
A better solution for multi-tenant Spark environments
Fortunately, there are new solutions that simplify multi-tenant Spark environments. IBM Spectrum Conductor draws on IBM’s decades of experience managing multi-tenant HPC workloads providing not only resource management but Spark-specific optimizations while maintaining full compatibility with open-source Spark. In an audited benchmark of diverse Spark workloads, IBM Spectrum Conductor was shown to run Spark queries between 30% and 224% faster depending on the operation, and deliver a measured 10x improvement runtime variability – a game changer in multi-tenant data science / AI environments where business users need jobs to complete on time.
While YARN and Mesos assign resources to Spark at the application level, shifting resources between executors, IBM Spectrum Conductor’s Spark-aware session manager performs fine-grain scheduling at the task level. This means that Spark workloads can respond almost instantly to changes in priority, pre-empt lower priority jobs if necessary, and provide elastic scaling of Spark jobs at runtime to meet SLAs while balancing this with the need to ensure fast response times for interactive ad-hoc queries. By leveraging the dynamic resource sharing model used in IBM Spectrum Symphony, initially developed for HPC applications in investment banking, IBM Spectrum Conductor supports the notion of Spark Instance Groups. Each application tenant essentially has their own virtual Spark cluster even running different versions of Spark on the shared environment. By leveraging IBM Spectrum Conductor’s Spark extensions for shared applications, multiple applications performing Spark queries can be attached to the same Spark context and executor process space avoiding unnecessary copies of the same data for dramatic efficiency gains in multi-user environments.
When combined with IBM Spectrum Scale™, IBM Spectrum Conductor provides a highly scalable data- and application-optimized fabric that allows you to access, analyze and protect your data with maximum efficiency, fast deployment and simplified management.