[
https://issues.apache.org/jira/browse/YARN-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012595#comment-15012595
]
Joep Rottinghuis commented on YARN-4053:
----------------------------------------
[~sjlee0] the ValueConverterImpl is a remnant from earlier implementation where
the enum had anonymous inner classes in the enum values. That is no longer
needed now and we can probably eliminate that indeed.
If we go with the tightened type interface then we would be able to add only
Longs to Longs etc. That by itself is probably not too bad, because the column
would be defined as one or the other. However, in FlowScanner.processSummation
this will be an issue. In that method we don't know what the type for each
column is, so the sum member is defined as a Number to future proof potentially
other conversions. This is why we made the conversion pluggable. The add
method must accept two numbers and emit a number. We could still have the class
accept any T extends Number and if needed use that T later in the class to
ensure that number implements T (or else throw an exception) if we want to
implement the restriction that Vrushali mentions. The add method would still
accept Number in the signature I think.
This did make me think of another thing: right now we add only two numbers,
never more than two. If at some point we want to add three or more Numbers we
would have do to that one at a time. We could change the signature of
NumericConverter from
{code}
public Number add(Number num1, Number num2);
{code}
to
{code}
public Number add(Number... numbers);
{code}
The calling code wouldn't have to change because it passes two numbers, but
then a possible future use-case could add three or more arguments together.
The implementation would change slightly to check for null and return null, or
iterate over the list and return the sum of all values (that aren't null).
That is probably more a matter of which style you like better, because right
now we don't have this use-case.
> 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,
> YARN-4053-feature-YARN-2928.04.patch, YARN-4053-feature-YARN-2928.05.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
(v6.3.4#6332)
