Joep Rottinghuis commented on YARN-4053:

Patch looks good. The converter approach looks nice and clean.

One thing I'm wondering if we need to look up the converter each time in 
FlowScanner line 180 where we do getValueConverter each time in nextInternal.
I'm wondering if we can somehow avoid this. Would it be safe to always assume a 
long converter? What happens if we did end up mixing a long and a non-long 
converter? Perhaps that is not a safe assumption.
Would it be possible to do this once and not each time? I'll chat with 
[~vrushalic] if we can somehow get around iterating over every column for each 
cell. Perhaps we can capture this during the constructor.

> Change the way metric values are stored in HBase Storage
> --------------------------------------------------------
>                 Key: YARN-4053
>                 URL: https://issues.apache.org/jira/browse/YARN-4053
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Varun Saxena
>            Assignee: Varun Saxena
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-4053-YARN-2928.01.patch, 
> YARN-4053-YARN-2928.02.patch, YARN-4053-feature-YARN-2928.03.patch
> Currently HBase implementation uses GenericObjectMapper to convert and store 
> values in backend HBase storage. This converts everything into a string 
> representation(ASCII/UTF-8 encoded byte array).
> While this is fine in most cases, it does not quite serve our use case for 
> metrics. 
> So we need to decide how are we going to encode and decode metric values and 
> store them in HBase.

This message was sent by Atlassian JIRA

Reply via email to