[
https://issues.apache.org/jira/browse/YARN-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675728#comment-15675728
]
Varun Saxena commented on YARN-5739:
------------------------------------
Well, found a link of HBase book which recommends using both KeyOnlyFilter and
FirstKeyOnlyFilter. Not sure why. But anyways let's use both, as the book says.
Probably internal implementation of HBase warrants use of both for optimal
performance. Quoting from the book:
{code}
101.7. Optimal Loading of Row Keys
When performing a table scan where only the row keys are needed (no families,
qualifiers, values or timestamps), add a FilterList with a MUST_PASS_ALL
operator to the scanner using setFilter. The filter list should include both a
FirstKeyOnlyFilter and a KeyOnlyFilter. Using this filter combination will
result in a worst case scenario of a RegionServer reading a single value from
disk and minimal network traffic to the client for a single row.
{code}
> Provide timeline reader API to list available timeline entity types for one
> application
> ---------------------------------------------------------------------------------------
>
> Key: YARN-5739
> URL: https://issues.apache.org/jira/browse/YARN-5739
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelinereader
> Reporter: Li Lu
> Assignee: Li Lu
> Attachments: YARN-5739-YARN-5355.001.patch,
> YARN-5739-YARN-5355.002.patch
>
>
> Right now we only show a part of available timeline entity data in the new
> YARN UI. However, some data (especially library specific data) are not
> possible to be queried out by the web UI. It will be appealing for the UI to
> provide an "entity browser" for each YARN application. Actually, simply
> dumping out available timeline entities (with proper pagination, of course)
> would be pretty helpful for UI users.
> On timeline side, we're not far away from this goal. Right now I believe the
> only thing missing is to list all available entity types within one
> application. The challenge here is that we're not storing this data for each
> application, but given this kind of call is relatively rare (compare to
> writes and updates) we can perform some scanning during the read time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
