incubator-chukwa-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Yang <ey...@yahoo-inc.com>
Subject Re: speeding up demux
Date Wed, 01 Jun 2011 20:33:28 GMT
Hi James,

1) Trunk is most stable than any previous release, but it needs more documentation.
2) Performance is the same for sequence file writer, and 200-300X faster data availability,
if the data is streamed to HBase.
3) Check out http://svn.apache.org/repos/asf/incubator/chukwa/trunk/CHANGES.txt
4) Yes it does.  Let us know if there is any questions.

The setup instruction is located at: http://wiki.apache.org/hadoop/Chukwa_Quick_Start

Hope it works for you. :)

Regards,
Eric

On 6/1/11 1:01 PM, "James Seigel" <james@tynt.com> wrote:

Hello!

I am seriously considering what you are suggesting in this email, even though it goes against
what would seem to make sense.  I have a couple of questions if anyone has the time to answer.

1) How stable is trunk right now?
2) Any performance improvements/degredations since 0.3
3) Is there a pseudo change log between "trunk" and 0.4 that I could take a peak at at this
point
4) does it compile ;)

Cheers and thanks for your time!

James.


On 2011-05-27, at 9:58 AM, Eric Yang wrote:

I would recommend to skip Chukwa 0.4 and go to the trunk.  In addition, use HBaseWriter to
stream data into HBase in parallel, hence, the data can be processed in near real time for
demux.

Regards,
Eric

On 5/26/11 8:30 PM, "Bill Graham" <billgraham@gmail.com <x-msg://109/billgraham@gmail.com>
> wrote:

This seems possible, but one thing that would need to be changed is the directories that demux
uses. For example:
demuxProcessing/mrInput
demuxProcessing/mrOutput

These would need to dynamic directories with the timestamp or something else in them to keep
two jobs from interfering with each other.

On Thu, May 26, 2011 at 8:23 PM, Corbin Hoenes <corbin@tynt.com <x-msg://109/corbin@tynt.com>
> wrote:
Finding demux to be a bit too slow for our needs.  It seems like only 1 runs at a time; is
there some technical reason why we couldn't run a couple in parallel?  If so any hints on
how difficult it would be to run multiple demuxers at a time?







Mime
View raw message