Welcome!

Java IoT Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui, Elizabeth White

Related Topics: Java IoT, Microservices Expo, Microsoft Cloud, Machine Learning , Agile Computing, @DXWorldExpo

Java IoT: Article

Eating Our Own Dog Food – 2x Faster Hadoop MapReduce Jobs

How to analyze and optimize Hadoop jobs beyond just tweaking MapReduce options

For a while now I have been writing about how to analyze and optimize Hadoop jobs beyond just tweaking MapReduce options. The other day I took a look at some of our Outage Analyzer Hadoop jobs and put words into action.

A simple analysis of the Outage Analyzer jobs with Compuware APM 5.5 identified three hotspots and two potential Hadoop problems in one of our biggest jobs. It took the responsible developer a couple of hours to fix it and the result is a 2x improvement overall and a 6x improvement on the Reduce part of the job. Let's see how we achieved that.

About Outage Analyzer
Outage Analyzer is a free service provided by Compuware that displays in real-time any availability problems with the most popular third-party content providers on the Internet. It's available at http://www.outageanalyzer.com. It uses real time analytical process technologies to do anomaly detection and event correlation and classification. It stores billions of measures taken from Compuware's global testing network every day in Hadoop and runs different MapReduce jobs to analyze the data. I examined the performance of these MapReduce jobs.

Identifying Worthwhile Jobs to Analyze
The first thing I did was look for a worthwhile job to analyze. To do this, I looked at cluster utilization broken down by user and job.

This chart visualizes the cluster CPU usage by user giving a good indication about which user executes the most expensive jobs

What I found was that John was the biggest user of our cluster. So I looked at the jobs John was running.

These are all the jobs that John was running over the last several days. It's always the same one, consuming about the same amount of resources

The largest job by far was an analytics simulation of a full day of measurement data. This job is run often to test and tune changes to the analytics algorithms. Except for one of the runs, all of them lasted about 6.5 hours in real time and consumed nearly 100% CPU of the cluster during that time. This looked like a worthy candidate for further analysis.

Identifying Which Job Phase to Focus On
My next step was to look at a breakdown of the job from two angles: consumption and real time. From a real-time perspective, map and reduce took about the same amount of time - roughly 3 hours each. This could also be nicely seen in the resource usage of the job.

This dashboard shows the overall cluster utilization during the time the job ran. 100% of the cluster CPU is used during most of the time

The significant drop in Load Average and the smaller drop in the other charts mark the end of the mapping phase and the start of pure reducing. What is immediately obvious is that the reducing phase, while lasting about the same time, does not consume as many resources as the map phase. The Load Average is significantly lower and the CPU utilization drops in several steps before the job is finished.

On the one hand that is because we have a priority scheduler and reducing does not use all slots, but more important, reducing cannot be parallelized as much as mapping. Every optimization here counts twofold, because you cannot scale things away. While the mapping phase is clearly consuming more resources, the reducing phase is a bottleneck and might therefore benefit even more from optimization.

The breakdown of job phase times shows that the mapping phase consumes twice as much time as reducing, even though we know that the job real time of the two phases is about the same - 3 hours each

As we can see the Map Time (time we spend in the mapping function, excluding merging, spilling and combining) is twice as high as the reduce time. The reduce time here represents the time that tasks were actually spending in the reduce function, excluding shuffle and merge time (which is represented separately). As such those two times represent those portions of the job that are directly impacted by the Map and Reduce code, which is usually custom code - and therefore tuneable by our developers.

Analyzing Map and Reduce Performance
As a next step I used Compuware APM to get a high-level performance breakdown of the job's respective 3 hour mapping and reducing phases. A single click gave me this pretty clear picture of the mapping phase:

This is a hot spot analysis of our 3 hour mapping phase which ran across 10 servers in our hadoop cluster

The hot spot dashboard for the mapping phase shows that we spent the majority of the time (about 70%) in our own code and that it's about 50% CPU time. This indicates a lot of potential for improvement. Next, I looked at the reducing phase.

This hot spot shows that we spend nearly all of our reducing time in all reduce tasks in our own code.

This shows that 99% of the reducing time is spent on our own code and not in any Hadoop framework. Since the reduce phase was clearly the winner in terms of potential, I looked at the details of that hot spot - and immediately found three hot spots that were responsible for the majority of the reduce time.

Three Simple Code Issues Consume 70% of the Reduce Time
This is what the method hot spots dashboard for the reduce phase showed.

These are the method hot spots for the reduce phase, showing that nearly everything is down to only three line items

The top three items in the method hot spot told me everything I needed know. As it turned out nearly all other items listed were sub-hotspots of the top most method:

  1. SimpleDateFormat initialization:
    The five items marked in red are all due to the creation of a SimpleDateFormat object. As most of us find out very painfully during our early career as a Java developer, the SimpleDateFormat is not thread safe and cannot be used as a static variable easily. This is why the developer chose the easiest route and created a new one for every call, leading to about 1.5 billion creations of this object. The initialization of the Formatter is actually very expensive and involves resource lookups, locale lookups and time calculations (seen in the separate line items listed here). This item alone consumed about 40% of our reduce time.
    Solution: We chose to use the well-known Joda framework (the code replacement was easy) and made the Formatter a static final variable; totally removing this big hot spot from the equation.
  2. Regular Expression Matching (line two in the picture)
    In order to split the CSV input we were using java.lang.String.split. It is often forgotten that this method uses regular expressions underneath. RegEx is rather CPU intensive and overkill for such a simple job. This was consuming another 15-20% of the allotted CPU time.
    Solution: We changed this to a simple string tokenizer.
  3. Exception throwing (line three in the picture)
    This example was especially interesting. During the reading of input data we are parsing numeric values, and if the field is not a correct number java.lang.Long.parseLong will throw a NumberFormatException. Our code would catch it, mark the field as invalid and ignore the exception. The fact is that nearly every input record in that feed has an invalid field or an empty field that should contain a number. Throwing this exception billions of times consumed another 10% of our CPU time.
    Solution: We changed the code in a way to avoid the exception altogether.

There we have it - three simple hot spots were consuming about 70% of our reduce CPU time. During analysis of the mapping portion I found the same hot spots again, where they contributed about 20-30% to the CPU time.

I sent this analysis to the developer and we decided to eat our own dog food, fix it and rerun the job to analyze the changes.

Job Done in Half the Time - Sixfold Improvement in Reduce Time
The result of the modified code exceeded our expectations by quite a bit. The immediate changes saw the job time reduced by 50%. Instead of lasting about 6.5 hours, it was done after 3.5. Even more impressive was that while the mapping time only went down by about 15%, the reducing time was slashed from 3 hours to 30 minutes.

This is the jobs cluster CPU Usage and Load Average after we made the changes

The Cluster Utilization shows a very clear picture. The overall utilization and load average during mapping phase actually increased a bit and instead of lasting 3 hours 10 minutes it was done after 2 hours and 40 minutes. While not huge this is still a 15% improvement.

The reduce phase on the other hand shrank dramatically: from roughly 3 hours to 30 minutes. That means a couple of hours of development work lead to an impressive sixfold performance improvement. We also see that the reduce phase is of course still not utilizing the whole cluster and it's actually the 100% phase that got a lot shorter.

Conclusion
Three simple code fixes resulted in a 100% improvement of our biggest job and a sixfold speedup of the reduce portion. Suffice it to say that this totally surprised the owners of the job. The job was utilizing 100% of the cluster, which for them meant that from a Hadoop perspective things were running in an optimal fashion. While this is true, it doesn't mean that the job itself is efficient.

This example shows that optimizing MapReduce jobs beyond tinkering with Hadoop options can lead to a lot more efficiency without adding any more hardware - achieving the same result with fewer resources.

The Hotspot analysis did also reveal some Hadoop-specific hotspots that led us to change some job options and speed things up even more. More on that in my next blog.

More Stories By Michael Kopp

Michael Kopp has over 12 years of experience as an architect and developer in the Enterprise Java space. Before coming to CompuwareAPM dynaTrace he was the Chief Architect at GoldenSource, a major player in the EDM space. In 2009 he joined dynaTrace as a technology strategist in the center of excellence. He specializes application performance management in large scale production environments with special focus on virtualized and cloud environments. His current focus is how to effectively leverage BigData Solutions and how these technologies impact and change the application landscape.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...