[
https://issues.apache.org/jira/browse/YARN-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513989#comment-14513989
]
Junping Du commented on YARN-3411:
----------------------------------
Just 2 cents on comments above:
bq. By timelineservice depending on HBase, we now have a circular dependency
between hadoop and HBase. Evidently it builds (which is bit surprising), but it
creates an interesting situation. I'm wondering how we should handle this. I
suppose the same issue exists with Phoenix.
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? In prospective of upstream/downstream project
relationship, I do agree it bring extra complexity between Hadoop project and
HBase project in syncing project releases. However, I think we should expect
this and already decided to take the pain before we are moving to HBase. Don't
we? Though, I didn't remember to see public discussions on this concern before.
bq. For metrics, shall we be more generalized to support all kinds of numeric
value, boolean and so on?
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.
> [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)
