Li Lu commented on YARN-3862:

bq.  it would be useful to maintain separation between limiting the contents 
that are returned (akin to contents of SELECT in SQL) and limiting the rows 
that are selected (akin to the WHERE clause in SQL).
I agree we should distinguish those two use cases. Restricting our filters to 
be predicates on rows will work perfectly for relational databases (and launch 
SQL queries), but if we storage data in our current fashion, we may also need 
to dynamically "filter" some columns I assume? For example, we may have a 
column filter that selects all configs that starts with 
"yarn.timelineservice.". I think most of these column filters will work on 
column qualifiers but not the values. 

> Decide which contents to retrieve and send back in response in TimelineReader
> -----------------------------------------------------------------------------
>                 Key: YARN-3862
>                 URL: https://issues.apache.org/jira/browse/YARN-3862
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Varun Saxena
>            Assignee: Varun Saxena
>         Attachments: YARN-3862-YARN-2928.wip.01.patch
> Currently, we will retrieve all the contents of the field if that field is 
> specified in the query API. In case of configs and metrics, this can become a 
> lot of data even though the user doesn't need it. So we need to provide a way 
> to query only a set of configs or metrics.
> As a comma spearated list of configs/metrics to be returned will be quite 
> cumbersome to specify, we have to support either of the following options :
> # Prefix match
> # Regex
> # Group the configs/metrics and query that group.
> We also need a facility to specify a metric time window to return metrics in 
> a that window. This may be useful in plotting graphs 

This message was sent by Atlassian JIRA

Reply via email to