Skip to main content

Revisiting the physician - Hadoop Vaidya


Performance Management is one of the major grey areas that most teams encounter with Apache Hadoop environment. Among the earliest tools to monitor performance has been Hadoop Vaidya, available as a “contrib” project under Apache Hadoop. In a blog post published last week, Vitthal (a.k.a Suhas) Gogate shared the details of plans to re-initiate work on Hadoop Vaidya and integrate it more tightly as part Greenplum HD offering.

This comes as no surprise since a few among the initial team behind Hadoop Vaidya have gelled together again as part of Greenplum HD ‘Team of Rivals’. Suhas had been part of Yahoo team which created Hadoop Vaidya and PMC member of Apache AMBARI project. After his stints at Netflix and Hortonworks, he is now at Greenplum along with Milind Bhandarkar who has taken over the mantle as Chief Scientist, Machine Learning Platform, Greenplum.

As Suhas acknowledges in his post, Vaidya has been dusting around for quite a bit due to lack of community and his own contributions off late. Vaidya, for an introduction, means the Physician in Sanskrit language and has aimed to cure the performance ills of Hadoop environment by offering rule based diagnostics. “It runs a set of predefined tests/rules against job execution statistics to diagnose various performance problems. Each test rule detects a specific performance problem with the Map/Reduce job and provides a targeted advice to the user. This tool generates an XML report based on the evaluation results of individual test rules.”

Some of the key test rules which Vaidya runs include:
  • Balanced Reduce Partitioning
    • This rule tests as to how well the input to reduce tasks is balanced

  • Impact of Map tasks Re-Execution
    • This test rule checks percentage of map task re-execution impacting the job performance

  • Impact of Reduce tasks Re-Execution
    • This test rule checks percentage of reduce task re-execution impacting the job performance

  • Map and/or Reduce tasks reading HDFS data as a side effect
    • This test rule checks if map/reduce tasks are reading data from HDFS as a side effect. More the data read as a side effect can potentially be a bottleneck across parallel execution of map/reduce tasks.

  • Map side disk spill
    • This test rule checks if Map tasks are spilling the data on to the local disk during the map side sorting due to insufficient sort buffer size. The impact is calculated as ratio between local bytes written to map output bytes. Impact is normalized using NormalizationFactor given and any value greater than or equal to normalization factor is treated as maximum (i.e. 1).

Suhas lists integrating Hadoop Vaidya with the Job Tracker History UI as one of his immediate priorities. We know that there have been other projects which have tried to integrate performance metrics with Hadoop Job Tracker UI- so this is probably more of a catch-up step to overcome the XML output critique. Also, he aims to add more diagnostic tests/rules instead of probably just leaving it up to community to keep adding rules as part of extensible framework.
Currently like most performance tools, Vaidya also utilizes Job Configuration and Job History logs as input for analysis. However, as part of long term roadmap, Vaidya intends to integrate with Greenplum Command Center. As per the post, this will enable Vaidya to incorporate “more sources of information from the cluster such as daemon/user logs, audit logs, job queue information and system metrics into its analysis. It will also enable real-time job analysis when running MapReduce jobs.”  We do hope that these features will also eventually be part of the open source code and distribution. Also, it is hoped that subsequently the enhancements will find their way into other commercial offerings like Karmasphere Professional Edition which embrace Vaidya.
The community has long vouched for a comprehensive performance monitoring tool for Apache Hadoop but the reality is that aren’t really a lot of successful options that could be handy for Hadoop performance management. There have been a few viable options like Starfish which have come through but largely people have resorted to performance heuristics or looked to invoke inbuilt adaptive MapReduce features. Without any doubt we look for better performance monitoring tools in the future and Suhas’s team’s effort go in that direction.


Comments

Popular posts from this blog

In-memory data model with Apache Gora

Open source in-memory data model and persistence for big data framework Apache Gora™ version 0.3, was released in May 2013. The 0.3 release offers significant improvements and changes to a number of modules including a number of bug fixes. However, what may be of significant interest to the DynamoDB community will be the addition of a gora-dynamodb datastore for mapping and persisting objects to Amazon's DynamoDB. Additionally the release includes various improvements to the gora-core and gora-cassandra modules as well as a new Web Services API implementation which enables users to extend Gora to any cloud storage platform of their choice. This 2-part post provides commentary on all of the above and a whole lot more, expanding to cover where Gora fits in within the NoSQL and Big Data space, the development challenges and features which have been baked into Gora 0.3 and finally what we have on the road map for the 0.4 development drive.
Introducing Apache Gora Although there are var…

Data deduplication tactics with HDFS and MapReduce

As the amount of data continues to grow exponentially, there has been increased focus on stored data reduction methods. Data compression, single instance store and data deduplication are among the common techniques employed for stored data reduction.
Deduplication often refers to elimination of redundant subfiles (also known as chunks, blocks, or extents). Unlike compression, data is not changed and eliminates storage capacity for identical data. Data deduplication offers significant advantage in terms of reduction in storage, network bandwidth and promises increased scalability.
From a simplistic use case perspective, we can see application in removing duplicates in Call Detail Record (CDR) for a Telecom carrier. Similarly, we may apply the technique to optimize on network traffic carrying the same data packets.
Some of the common methods for data deduplication in storage architecture include hashing, binary comparison and delta differencing. In this post, we focus on how MapReduce and…

Amazon DynamoDB datastore for Gora

What was initially suggested during causal conversation at ApacheCon2011 in November 2011 as a “neat idea”, would soon become prime ground for Gora's first taste of participation within Google's Summer of Code program. Initially, the project, titled Amazon DynamoDB datastore for Gora, merely aimed to extend the Gora framework to Amazon DynamoDB. However, it seem became obvious that the issue would include much more than that simple vision.

The Gora 0.3 Toolbox We briefly digress to discuss some other noticeable additions to Gora in 0.3, namely: Modification of the Query interface: The Query interface was amended from Query<K, T> to Query<K, T extends Persistent> to be more precise and explicit for developers. Consequently all implementors and users of the Query interface can only pass object's of Persistent type. Logging improvements for data store mappings: A key aspect of using Gora well is the establishment and accurate definitio…