A look back on 2019A look back on 2019

TensorFlow has emerged as one of the most popular deep learning frameworks in use today. It has by far more users and contributors than any other project, and appears to be continuing on its upward trajectory with the release of the TensorFlow 2.0 API. There are many new features of the TensorFlow 2.0 API to look through, and we will discuss many of them, including eager execution, notebook accessible tensorboards, and tighter integration with Keras. In addition, we will show how edge calculations can be accelerated with tensorflow.js which runs completely in the browser and provides much faster model serving. TensorFlow Lite is a framework for running on smaller remote devices. We will also discuss the parallel execution framework, as TensorFlow is well on the way to becoming the standard for all things deep learning.

Jerome NilmeierData Scientist & Developer Advocate, IBM

Since model selection methods choose the "best" model in some sense, significance tests for variables in that model will tend to be anti-conservative, and goodness of fit tests will tend to be conservative. This is troubling, as it implies these tests in practice do not actually provide evidence in favor of the chosen variables or model. We demonstrate methods of post-selection inference to obtain conditionally valid significance tests and conditionally unbiased goodness of fit tests and show how these outperform unadjusted tests.

Joshua LoftusAssistant Professor, NYU

Service organizations often measure themselves on keeping customer downtime to a minimum. In the complex distributed architectures inherent to many modern tech companies, however, blips are bound to occur, rendering the effectiveness of incident response critical to the customer experience. KPIs such as MTTD and MTTR (Mean Time to Detection/Resolution, respectively) are used to better understand the efficiency of said incident response, and maturing organizations would be wise to leverage tooling to improve these metrics. In a maturing global company such as DigitalOcean, distributed systems reign supreme, and with them the myriad microservices that generate metrics and data (and duly need to be observed effectively). Accordingly, we’ve built a platform named The Observatorium, whose primary goal is to reduce MTTD/MTTR across our cloud; we do so by curating and shepherding information in creative-yet-efficient ways, which I’ll discuss in more depth in this talk.

Alex KassEngineering Manager, Observability Applications & Infra Analytics, DigitalOcean

At Materialize, Inc. we are building a high-throughput, low-latency SQL view maintenance engine. You write SQL queries against continually evolving relations, we give you back the answers fast. You ask the queries again and you get updated answers in milliseconds. This system design departs fundamentally from both Spark-like and relational database systems, and is based instead on timely dataflow and differential dataflow. In this talk, we will go through the architectural highlights distinguish Materialize from prior systems, call out how they enable interactive queries over continually evolving data, and demonstrate the stack used for real-time data warehousing.

Frank McSherryChief Scientist, Materialize

Data teams everywhere struggle with pipeline debt: untested, undocumented assumptions that drain productivity, erode trust in data and kill team morale. Unfortunately, rolling your own data validation tooling usually takes weeks or months. In addition, most teams suffer from “documentation rot,” where data documentation is hard to maintain, and therefore chronically outdated, incomplete, and only semi-trusted. Great Expectations, the leading open source project for fighting pipeline debt, can solve these problems for you. We're excited to share new features and under-the-hood architecture with the data community.

Abe GongCo-Founder & CEO, Great Expectations

This talk is about a service that replaced our previous real-time service that produces all historical metrics data which powers a lot of things at Datadog. This new service is based on Kafka-Connect and Spark (vs. Go previously) and handles 100s TBs/10s T records a day while running on spot instances in a pretty violent environment. We're going to talk about decisions we made, architecture, engineering considerations, various optimizations we had to do, we'll show that it's possible to process trillions of records using Spark, we'll talk about certain savings we got in the result, operational challenges and benefits, and various migrations we had to implement as part of rolling out a new service. Albeit, not everything can be directly used by others but we believe that the general approaches and considerations for building and migrating a system of such scale can be used as a general guidance for building systems of different levels.

Vadim SemenovData Engineer, Datadog

The idea of distributed tracing is to stitch together the execution path traversed by a request: operations are timed, and the execution context is propagated as different services perform work to handle the request. As storing all trace data is prohibitively expensive, it is necessary to select certain traces to be retained and discard others. Anomalous traces are invaluable to debugging and optimization workflows, but traces do not announce up front whether they will take an abnormally long time to complete, or whether an operation 35 links away will result in an error. A tail-based approach, in which the decision whether to retain a trace is deferred until the trace is complete, at which point its characteristics determine the likelihood that it is retained, is therefore required. This talk will describe the product and engineering requirements for a robust and scalable tail-based distributed tracing system, and the statistical techniques that arise in meeting these requirements. For example, we will discuss how to prefer abnormally long and/or erroneous traces while maintaining the ability to calculate accurate summary statistics. We will introduce the necessary concepts from distributed tracing. Some comfort with statistical arguments would be helpful.

Joe RossPrincipal Data Scientist, Splunk

Schiphol Group is a group of airports, best known for Amsterdam Schiphol Airport. Schiphol is the third busiest airport in Europe. Due to its location, Schiphol is unable to build substantial new infrastructure to increase capacity. In an effort to increase on-time performance, a broad initiative was started to gain insight into the cause of delays. One of these possible causes is the 'turnaround' process. During a turnaround, an arriving aircraft is 'turned-around' to become a departing one. This process includes events such as re-fuelling. The turnaround is fully arranged and coordinated by the airline - resulting in a variety of handlers and differences in (order of) procedures. Schiphol is not involved in organising this, and therefore doesn't have detailed information about the events. Most importantly, whether the aircraft will be able to leave on time. In this talk, we'll discuss how Schiphol approached this problem with an innovative Deep Learning initiative. Our solution generates events as they happen by analyzing a real-time feed of camera images of the aircraft at the gate. We'll focus on how we set up the streaming pipeline and the challenges we faced, such as running GPU-backed infrastructure in production. Our main components are Apache Kafka and Tensorflow, backed by Azure Kubernetes Service. We'll explain how we went from a manual, batch-based Tensorflow process to a fully-automated, near real-time streaming solution.

Daniel van der EndeData Engineer, GoDataDrivenTim van CannData Engineer, GoDataDriven

The abundance of data, coupled with cheap and widely-available computing and storage, has revolutionized science, industry and government alike. Now, to a large extent, the bottleneck to extracting actionable insights lies with people. Complex computational pipelines are required to ingest, clean, analyze, visualize and create models from data. But the process to assemble these is inherently iterative and time consuming.  In addition,  after a series of steps, there are many ways in which the computations,  the data, and the analyst could have been wrong. Thus, when results are derived, an important question is whether you can trust them. In this talk, I will discuss the importance of computational provenance for data science and how it enables reproducibility, transparency, and helps build trust in results obtained from data-driven exploration. I will also present techniques and tools that support automatic provenance capture and simplify the reproducibility of computations.

Juliana FreireProfessor of Computer Science and Engineering and Data Science, NYU

If you’ve ever thought you needed to be a programmer to do stream processing and build stream processing data pipelines, think again. Apache Kafka is a distributed, scalable, and fault-tolerant streaming platform, providing low-latency pub/sub messaging coupled with native storage and stream processing capabilities. Integrating Kafka with a relational database management system (RDBMS), NoSQL, and object stores is simple with Kafka Connect, which is part of Apache Kafka. KSQL is the open-source SQL streaming engine for Apache Kafka and makes it possible to build stream processing applications at scale, written using a familiar SQL interface. Viktor Gamov walks you through the architectural reasoning for Apache Kafka and the benefits of real-time integration. You’ll build a streaming data pipeline using nothing but your bare hands, Kafka Connect, and KSQL.

Viktor GamovDeveloper Advocate, Confluent