[
https://issues.apache.org/jira/browse/YARN-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514466#comment-14514466
]
Sangjin Lee commented on YARN-3411:
-----------------------------------
bq. In detail thinking, HBase relies on Hadoop/HDFS only (not YARN), so it
should be fine for YARN to rely on HBase component especially it is downloading
jar rather than build from source?
OK I got clearer about this. "hbase-client" does depend on YARN indirectly as
it depends on hadoop-mapreduce-client-core. But since timelineservice is high
enough in terms of YARN project dependency hierarchy so they don't form a
cycle. I think this specific situation might be OK, so we can move forward. As
a to-do item, though, I think we want to think about the code structure of
adding library dependencies that depend on hadoop, as things like versions can
become issues. Are there any precedents?
bq. Do we have solid case for non-numeric metrics so far? Boolean case should
be fine as we can represent true and false with 1 and 0.
I think we should stick with numbers (perhaps java.lang.Number as the base
class for types). I'm not even sure how boolean "aggregation" would work so we
may just decide not to support it.
> [Storage implementation] explore the native HBase write schema for storage
> --------------------------------------------------------------------------
>
> Key: YARN-3411
> URL: https://issues.apache.org/jira/browse/YARN-3411
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Sangjin Lee
> Assignee: Vrushali C
> Priority: Critical
> Attachments: ATSv2BackendHBaseSchemaproposal.pdf,
> YARN-3411.poc.2.txt, YARN-3411.poc.txt
>
>
> There is work that's in progress to implement the storage based on a Phoenix
> schema (YARN-3134).
> In parallel, we would like to explore an implementation based on a native
> HBase schema for the write path. Such a schema does not exclude using
> Phoenix, especially for reads and offline queries.
> Once we have basic implementations of both options, we could evaluate them in
> terms of performance, scalability, usability, etc. and make a call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
