Li Lu commented on YARN-3134:

Hi [~vrushalic], thanks for the note! Yes events and metrics are missing in the 
previous POC patch (actually I should have called them Work-In-Progress). I'm 
currently working on it and mostly done. 

About appending metrics and events, it would be very nice if we can distinguish 
the "creation" calls, the "append" and the "update" calls. For the last two we 
can have some fast path to not touch many fields, and only work on the "delta" 
part of the entity. We can pretty much simulate that with our current writer 
API, by setting unchanged TimelineEntity fields to be null or empty (like 
events/info/metrics). However, if this is the case, we need to provide some 
wrapper methods in our client to allow users to easily generate the "patch", 
hopefully in some user-friendly ways (such as appendMetric(myEntity, myContext, 
newMetric) or updateInfo(myEntity, myContext, infoKey, infoValue), just some 
quick examples...). 

> [Storage implementation] Exploiting the option of using Phoenix to access 
> HBase backend
> ---------------------------------------------------------------------------------------
>                 Key: YARN-3134
>                 URL: https://issues.apache.org/jira/browse/YARN-3134
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Li Lu
>         Attachments: YARN-3134-040915_poc.patch, YARN-3134-041015_poc.patch, 
> YARN-3134DataSchema.pdf
> Quote the introduction on Phoenix web page:
> {code}
> Apache Phoenix is a relational database layer over HBase delivered as a 
> client-embedded JDBC driver targeting low latency queries over HBase data. 
> Apache Phoenix takes your SQL query, compiles it into a series of HBase 
> scans, and orchestrates the running of those scans to produce regular JDBC 
> result sets. The table metadata is stored in an HBase table and versioned, 
> such that snapshot queries over prior versions will automatically use the 
> correct schema. Direct use of the HBase API, along with coprocessors and 
> custom filters, results in performance on the order of milliseconds for small 
> queries, or seconds for tens of millions of rows.
> {code}
> It may simply our implementation read/write data from/to HBase, and can 
> easily build index and compose complex query.

This message was sent by Atlassian JIRA

Reply via email to