Rohit Karlupia has been mainly writing high performance server applications, ever since completing his Bachelors of Technology in Computer Science and Engineering from IIT Delhi in 2001. He has deep expertise in the domain of messaging, API gateways and mobile applications. His primary research interests are performance and scalability of cloud applications. At Qubole, his primary focus is making Big Data as a Service, debuggable, scalable and performant. His current work includes SparkLens (open source Spark profiler), GC/CPU aware task scheduling for spark and Qubole Chunked Hadoop File System.
One of the common requests we receive from customers (at Qubole) is debugging slow spark application. Usually this process is done with trial and error, which takes time and requires running clusters beyond normal usage (read wasted resources). Moreover, it doesn't tell us where to looks for further improvements. We at Qubole are looking into making this process more self-serve. Towards this goal we have built a tool (OSS https://github.com/qubole/sparklens) based on spark event listener framework. From a single run of the application, Sparklens provides insights about scalability limits of given spark application. In this talk we will cover what Sparklens does and theory behind Sparklens. We will talk about how structure of spark application puts important constraints on its scalability. How can we find these structural constraints and how to use these constraints as a guide in solving performance and scalability problems of spark applications. This talk will help audience in answering the following questions about their spark applications: 1) Will their application run faster with more executors? 2) How will cluster utilization change as number of executors change? 3) What is the absolute minimum time this application will take even if we give it infinite executors? 4) What is the expected wall clock time for the application when we fix the most important structural limits of these application? Sparklens makes the ROI of additional executor extremely obvious for a given application and needs just a single run of the application to determine how application with behave with different executor counts. Specifically, it will help managers take the correct side of the tradeoff between spending developer time optimising applications vs spending money on compute bills. Session hashtag: #SAISDev17