<div dir="ltr"><div class="gmail_default" style="font-size:small">This is not entirely unexpected when using the Dataset API. The method by which the "sample=.01" parameter is applied is in terms of files stored on S3. As pings come in, the ingestion pipeline batches them up by several dimensions (including channel, build, fx version, etc) and saves them to S3 when they reach a certain size or after a certain timeout.<br><br></div><div class="gmail_default" style="font-size:small">This generally results in a large number of small files (for uncommon long-tail combinations of dimensions such as nightly builds) and a smaller number of large files (such as release on the current version).<br><br></div><div class="gmail_default" style="font-size:small">When loading the data back out of S3, the Dataset code batches these S3 objects into approximately-equal sets based on size, but if there are only a few large files to read, they will unbalance some of the partitions. At a 1% sample, it's possible there were only a handful of large files which become the bottleneck to the task completing.<br><br></div><div class="gmail_default" style="font-size:small">Ideally the S3 objects would be better balanced size-wise, but since we need to ensure a maximum upper bound on latency until data becomes available for processing, we need to eventually flush accumulated data to long term storage even if we've only seen one record for a set of dimensions.<br><br></div><div class="gmail_default" style="font-size:small">This definitely impacts on cluster efficiency, and should be improved as we move towards more "direct to parquet" outputs[2]. This will let us partition by fewer dimensions on S3 and instead take advantage of the ability to efficiently scan and filter the parquet data directly. The good news is that the more data you read from S3, the more balanced the reading becomes, so at least this particular problem is worst on the small case, not the large case.<br><br></div><div class="gmail_default" style="font-size:small">Thanks for the report!<br><br></div><div class="gmail_default" style="font-size:small">Mark<br></div><div class="gmail_default" style="font-size:small"><br>[1] <a href="https://github.com/mozilla/python_moztelemetry/blob/master/moztelemetry/dataset.py#L185">https://github.com/mozilla/python_moztelemetry/blob/master/moztelemetry/dataset.py#L185</a><br>[2] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1304412">https://bugzilla.mozilla.org/show_bug.cgi?id=1304412</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 3:23 PM, Eric Rescorla <span dir="ltr"><<a href="mailto:ekr@mozilla.com" target="_blank">ekr@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>You might be interested in the following notebook:</div><div><a href="https://gist.github.com/ekr/5dbd14316554c87ebecf49dec3c2b543" target="_blank">https://gist.github.com/ekr/<wbr>5dbd14316554c87ebecf49dec3c2b5<wbr>43</a><br></div><div><br></div><div>The behavior I see in the last cell (un-named) is that it takes 2 minutes</div><div>(there are about 750k records) but the progress indicator jumps up to</div><div>636 processes done and then grinds away until it hits 640. I don't know</div><div>if this is too slow or not (it seems a bit slow) but this seems indicative</div><div>that maybe we're not making good us of the cluster, so I thought I</div><div>would mention it.</div><div><br></div><div>-Ekr</div><div><br></div><div><br></div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
fhr-dev mailing list<br>
<a href="mailto:fhr-dev@mozilla.org">fhr-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/fhr-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/fhr-dev</a><br>
<br></blockquote></div><br></div>