Junping Du commented on YARN-4053:

Hi [~sjlee0] and all, sorry for coming late for this good discussion. 
bq. we're of the opinion that we can start supporting only longs for now (i.e. 
no floating point types), while we can consider adding a floating point type 
(namely double) to the list of supported types.
If applications want to store value of percentage which are all between 0.0 and 
1.0, what should they do? casting decimal number (0.49 and 0.50) directly to 
integer(long) or multiply 100 and divide 100 later?
I agree that only support Long make things much easier. However, it seems 
cannot satisfy some basic requirements and scenarios. Supporting Long and 
Double for the first step (instead of int, long, float and double) sounds like 
a reasonable compromise though. About solutions, I think [~varun_saxena] bring 
up an option in YARN-3816 to use cell tag identify metrics value type which 
sounds good to me. Do we have any concern on this way? I am quite interested in 
this as we may want to apply more meta info (raw or aggregated, etc.) on 
metrics in future. Thoughts?

> 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
>         Attachments: YARN-4053-YARN-2928.01.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