<div dir="ltr">The old infrastructure has (finally) been fully decommissioned. This means that "DATASET-oldinfra" will not be available for data generated after 2017-03-08. <br><br>If you need to perform exploratory analysis on data that is older than 
2016-10-12 that spans to dates later than 2017-03-08, you will need you to perform a union between the 
old and new infra data sets, using "DATASET-oldinfra" to 
access data with submissionDate preceding 2016-10-12 and "DATASET" 
otherwise.<br><br>-whd<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 4:56 PM, Wesley Dawson <span dir="ltr"><<a href="mailto:whd@mozilla.com" target="_blank">whd@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">TL;DR If you notice any issues when running analyses on telemetry data over the next few weeks, contact me via email or IRC. You probably won't.<br><br>Over the course of this week I'm going to cut over the metadata prefixes for telemetry data sets to point at data sets generated by our newer server infrastructure. The newer server infrastructure has been running in parallel to the current infrastructure since October 2016. Once the cut-over is completed, accessing data sets from our canonical store (e.g. telemetry, telemetry-sample) will retrieve the newer data sets instead of the legacy data sets.<br><br>WHO THIS AFFECTS AND WHAT IT MEANS TO YOU<br><br>If you perform your analysis via s.t.m.o. (Presto) or by using parquet data sets with Spark (this should be most of you), then this change should *not* affect you! There may be slight variations in query results due to enforcing basic schema validation (see below), but those differences should be minimal.<br><br>If you are using the Scala Dataset API via telemetry-batch-view or the Python Dataset/get_pings API via PySpark to access records, this change *may* affect you (but probably not). The most noticeable difference is that the new data only goes back to pings submitted after 2016-10-12.<br><br>If you need to perform exploratory analysis on data that is older than 2016-10-12, you will need to access the data using a different data set name: "DATASET-oldinfra".  You may need to perform a union between the old and new infra data sets, in which case, use "DATASET-oldinfra" to access data with submissionDate preceding 2016-10-12 and "DATASET" otherwise.<br><br>Of the scheduled jobs we run, I've only found one that potentially requires history greater than what is provided by the new infra data sets. I'll reach out to the owner of that job specially, but the general procedure for accessing old data is outlined above.<br><br>FURTHER DIFFERENCES BETWEEN THE NEW AND OLD INFRA DATASETS<br><br>The gist is that you probably won't notice any difference, but continue reading if you like gory details.<br><br>Basic schema validation: with the new infrastructure we do basic schema validation server-side that discards ~.5% of the pings we receive from clients. See <a href="https://github.com/mozilla-services/mozilla-pipeline-schemas/" target="_blank">https://github.com/mozilla-<wbr>services/mozilla-pipeline-<wbr>schemas/</a> for the schemas. We plan to increase the schema stringency over time to decrease the amount of validation/cleaning work that you need to perform in your analyses.<br><br>Data format: data is now stored in per-file gzip-encoded protobuf files, which contrasts with our previous approach of per-record snappy compression. This comes with a ~50% size decrease in our store (good) but a 10-15% performance penalty (bad) for parsing during analysis. This change paves the way for moving to zstd compression later this year, which will provide both greater performance and smaller object sizes. I don't except any jobs to time out due to this change, but if yours does, bump the timeout and try re-running the analysis.<br><br>Changes in representations in some JSON edge cases: in the current infra some values that were submitted by the client as empty arrays were set to NULL or empty dicts by our json parser (cjson). The new json parser (rjson) stores them correctly as empty arrays. This probably doesn't affect many analyses but might allow you to do less error checking. Additionally, the client occasionally submits very large numbers for which json parsing library behavior varies (e.g. 64 bit unsigned integers). These large numbers were previously truncated in lua, but are now left as-is. Depending on which json parser you use to access the data, the specific value you see may differ, but once again this is unlikely to affect most analyses.<br><br>That wraps it up for changes.<br><br>IN CONCLUSION<br><br>I'll send a followup email after the migration has completed, and another one after the old infra has been turned off. Any questions should go to this thread or #datapipeline on IRC.<br><br>-whd<br></div>
</blockquote></div><br></div>