Refactoring hraven for multiple sink support

[angadsingh]

Generic object model and abstraction for output records of JobFileProcessor's mapper instead of directly emitting Hbase puts at the lowest level of code hierarchy. Used MultipleOutputs to allow sinking to different sinks (graphite, hbase, etc.) and handle specifically writing of records at the sink's OutputFormat level. Added graphite sink and refactored hbase storage to work as a sink. Changes no hraven behaviour.

[angadsingh]

2 more changes which are subsequent to this one. will create PRs when this one is accepted:
angadsingh/hraven@twitter:master...optional-task-history-processing
angadsingh/hraven@twitter:master...graphite-key-mapping

[jrottinghuis]

drop authors

[jrottinghuis]

Definitely need a little more time to grok this change.
On the face of it, it sounds great to separate out HBase and add an additional sink.
How would that work for cases where we need to rely on HBase CAS or increment operations ?

In theory one could store this data in a regular SQL DB as well, however, we rely heavily on efficient HBase scans to be able to efficiently pull data out of tables that contain tens of billions of task records for about a dozen clusters.

If we do support an additional sink we need some serious unit test cases to make sure that any additional changes to hRaven don't break compatibility for Graphite.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Angad Singh seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}