Zhijie Shen commented on YARN-3908:

Okay, it's fair point. It seems that the key design significantly depends on 
how we want to operate on the events. The current key design is most friendly 
to check if there exists the events who match the given event ID to match some 
given info key (and its value). But if you want to fetch everything that 
belongs to this event (our query needs to do this, as it's implicitly an atomic 
unit for now), it seems to be inevitable to scan through all these columns that 
have the given event ID (correct me if I'm wrong :-). If so, there seems to to 
have little gain from this key design, while complicating the event 
encapsulation logic.

And after rethinking of the current query to support (YARN-3051), I want to 
amend my suggestion. It seems to be more reasonable to use 
{{e!eventTimestamp?eventId?eventInfoKey}}, such that we can natively scan 
through the events of one entity one-by-one return them in a chronological 

> Bugs in HBaseTimelineWriterImpl
> -------------------------------
>                 Key: YARN-3908
>                 URL: https://issues.apache.org/jira/browse/YARN-3908
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Vrushali C
>         Attachments: YARN-3908-YARN-2928.001.patch, 
> YARN-3908-YARN-2928.002.patch, YARN-3908-YARN-2928.003.patch, 
> YARN-3908-YARN-2928.004.patch, YARN-3908-YARN-2928.004.patch, 
> YARN-3908-YARN-2928.005.patch
> 1. In HBaseTimelineWriterImpl, the info column family contains the basic 
> fields of a timeline entity plus events. However, entity#info map is not 
> stored at all.
> 2 event#timestamp is also not persisted.

This message was sent by Atlassian JIRA

Reply via email to