How to Performance-Tune Apache Spark Applications in Large Clusters

Omkar Joshi offers an overview on how performance challenges were addressed at Uber while rolling out its newly built flagship ingestion system, Marmaray (open-sourced) for data ingestion from various sources like Kafka, MySQL, Cassandra, and Hadoop. This system is rolled out in production and has been running for over a year now, with more ingestion systems onboarded on top of it. Omkar and team heavily used jvm-profiler during their analysis to give them valuable insights. This new system is built using the Spark framework for data ingestion. It’s designed to ingest billions of Kafka messages per topic from thousands of topics every 30 minutes. The amount of data handled by the pipeline is of the order hundreds of TBs. At this scale, every byte and millisecond saved counts. Omkar detail how to tackle such problems and insights into the optimizations already done in production.

Some key highlights are:

- how to understand your bottlenecks in Spark applications, to cache or not to cache your Spark DAG to avoid rereading your input data
- how to effectively use accumulators to avoid unnecessary Spark actions
- how to inspect your heap and non heap memory usage across hundreds of executors
- how you can change the layout of your data to save long-term storage cost
- how to effectively use serializers and compression to save network and disk traffic
- how to reduce amortized cost of your application by multiplexing your jobs.

They used different techniques for reducing memory footprint, runtime, and on-disk usage for the running applications. In terms of savings, they were able to significantly (~10% – 40%) reduce memory footprint, runtime, and disk usage.

About:
Databricks provides a unified data analytics platform, powered by Apache Spark™, that accelerates innovation by unifying data science, engineering and business.

Connect with us:

[catchritesh]

This is enterprise level explanation which is highly useful. Great work Omkar !!

[oldschoolwreak]

Probably the best talk so far citing the real life issues faced and their solutions.

[thomsondcruz]

Loved this talk. Just one comment at 8:36 (Referring to example provided of 100 rows) Parquet is not purely columnar. It is actually hybrid, where the rows are divided into RowGroups and each RowGroup is stored in a columnar format. This hybrid format actually helps in row reconstruction. Also, with Apache Delta coming becoming more mainstream (which also uses Parquet but with a commit log) there is little reason to use pure Parquet :)

[BuvanAlmighty]

Very useful ideas from real life scenarios

[MrTigerman]

@omkar thanks for your talk and just to let u know we are facing yarn memory overhead issue with spark 2.4 as well when we are doing spark sql joins

[shubhamshingi]

I am new to spark. Can anyone please tell me exactly for which operations 5 stages in left diagram and 2 stages in right diagram are formed?