chukwa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <>
Subject [jira] Commented: (CHUKWA-444) Redefine Chukwa time series storage
Date Mon, 28 Jun 2010 22:08:48 GMT


Eric Yang commented on CHUKWA-444:

HBase writer is optional, and it is currently compatible with other components of Chukwa data
processing pipeline.  In the future, if HBaseWriter is voted to be the standard, then we can
optimize the demux parser to be more efficient for HBaseWriter.  There is no stricted schema
as long as parser must be loaded ahead of time and parser's ReducerType must match the column
family in HBase table.  HBase table will also help on range scan to retrieve data for hourly
and daily report of map reduce job.  This approach is more efficient than periodically roll
up and manages spill files.

If hbase is not available, it throws WriterException, hence, the chunk is uncommitted.  It
should not have any impact to collector other than reject  the chunk.

I like to update Chukwa architecture to reflect this change.  This may help us steer clear
of having relational database on the critical path.

> Redefine Chukwa time series storage
> -----------------------------------
>                 Key: CHUKWA-444
>                 URL:
>             Project: Hadoop Chukwa
>          Issue Type: New Feature
>          Components: Data Processors
>         Environment: Redhat EL 5.1, Java 6
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>         Attachments: CHUKWA-444.patch
> The current Chukwa Record format is not suitable for data visualization.  It is more
like an archive format which combines data from multiple sources (hosts), and group them into
a sorted time partitioned sequence file.  Most of people collected data for two reasons, archive
and data analysis.  The current chukwa record format is fine for archive, but it is not so
great for data analysis.  Data analysis could be further break down into two different types.
 1) Data can be aggregated and summarized, such as metrics.  2) Data that can not be summarized,
like job history.  Type 1 data is useful for visualization by graph, and type 2 data is useful
by plain text viewing or search for a particular event.
> By the above rational, it probably makes sense to restructure Chukwa Records for data
analysis.  Outside of Hadoop world, rrdtools is great for time series data storage, and optimized
for metrics from a single source, i.e. a host.  RRD data file fragments badly when there are
hundred of thousands of sources.  Chukwa time series data storage should be able to combine
multiple data sources into one Chukwa file to combat file fragmentation problem.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message