hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joep Rottinghuis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5109) timestamps are stored unencoded causing parse errors
Date Sat, 21 May 2016 00:47:15 GMT

    [ https://issues.apache.org/jira/browse/YARN-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15294595#comment-15294595
] 

Joep Rottinghuis commented on YARN-5109:
----------------------------------------

bq. The main motivation for reversing the user and the cluster in the entity table is to accommodate
the fact that the table can get real large and we wanted to provide good partitioning by using
the user dimension rather than the cluster dimension. We preserved the original order (cluster
and then user) for the application table.

Indeed. Aside from sheer size, which would be roughly equal in both cases, we especially want
to avoid hotspotting during writes with a very high update volume. Even if we can keep the
total size under control with an expiration policy, fact remains that if there is a specifically
large cluster (and/or just one cluster) the cluster prefix doesn't really help spread the
load. If the user is first, we at least "salt" the key with the user, so the load gets spread
across the various users.
Of course the same issue could happen the other way around, if somebody runs many clusters
and all of them they run jobs emitting entities (with metric time series data) as one single
user (let's say "hadoop"), we'd still hotspot.

The volume for the application table _should_ be smaller. In a multi-cluster setup, the load
would also spread there. Range scans per cluster would be more efficient over the application
table, at the cost of reduced parallelism during writes.

bq. The bottom line is that since this was the intended design and nothing is broken, we should
not revisit it as part of this JIRA. Let me know if that is OK with you guys.
+1 agreed.

> timestamps are stored unencoded causing parse errors
> ----------------------------------------------------
>
>                 Key: YARN-5109
>                 URL: https://issues.apache.org/jira/browse/YARN-5109
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Sangjin Lee
>            Assignee: Varun Saxena
>            Priority: Blocker
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-5109-YARN-2928.01.patch, YARN-5109-YARN-2928.02.patch
>
>
> When we store timestamps (for example as part of the row key or part of the column name
for an event), the bytes are used as is without any encoding. If the byte value happens to
contain a separator character we use (e.g. "!" or "="), it causes a parse failure when we
read it.
> I came across this while looking into this error in the timeline reader:
> {noformat}
> 2016-05-17 21:28:38,643 WARN org.apache.hadoop.yarn.server.timelineservice.storage.common.TimelineStorageUtils:
incorrectly formatted column name: it will be discarded
> {noformat}
> I traced the data that was causing this, and the column name (for the event) was the
following:
> {noformat}
> i:e!YARN_RM_CONTAINER_CREATED=\x7F\xFF\xFE\xABDY=\x99=YARN_CONTAINER_ALLOCATED_HOST
> {noformat}
> Note that the column name is supposed to be of the format (event id)=(timestamp)=(event
info key). However, observe the timestamp portion:
> {noformat}
> \x7F\xFF\xFE\xABDY=\x99
> {noformat}
> The presence of the separator ("=") causes the parse error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message