Let's begin with MLflow Tracking. Several art contexts are associated with a centralized training metadata tracking repository that MLflow enables collection of. We need to collect asset of important hyper parameters, or configuration nodes, that effect model performance. This can all be saved using MLflow APIs and centralized tracking service. Additionally, users can log performance metrics that provide insights into the effectiveness of the Machine Learning models. For reproducibility, MLflow enables users to log the particular source code that was used to produce a model along with its version, by integrating tightly with it to map every model to a particular commit hash. Perhaps most importantly for reproducibility, MLflow can also be used to log artifacts which are any arbitrary files including training, there's data and models themselves. This means that if I am a developer who just trained a model, I can persist this model to centralize tracking service. Then one of my colleagues can load that models sometimes later and either continue to train an experiment or productionize that model to satisfy a particular need. Finally, for any concept that is not supported as a first-class entity in the tracking ecosystem, MLflow provides support for flexible tags and nodes associated with the training session. For example, nodes might be a good place to drop some information about the business use case that our model is being developed for. Now that we're familiar with the set of contexts that MLflow Tracking is designed to manage, let us look at how that MLflow Tracking service integrates with the existing training ecosystem. We observe that developers at machine learning practitioners train their model in a variety of locations. Some prefer to use cloud hosted services like Jupyterlab or Databricks, all this, run more than 20 jobs on-premise or of the local machines. At their group uses remote task execution services in the cloud and there are many other choices. Regardless of environment, the goal for MLflow Tracking is to allow users to capture all of these important metadata. Users can do this with MLflow Tracking APIs written in Python, Java, and R. Also available gracefully that allows users to easily instrument the code and retrieve all of that content regardless of where the code is being executed. After all these information is collected, it's aggravated by a centralized tracking service that is plugable and designed to run on a variety of popular things. Further, the tracking server expose a view of all this training information, both through a high-performance illuminating user interface and asset of programmatic APIs so that developers can interact directly with the data and performs analytics about the models that are being trained. Let's look at an example of the MLflow Tracking API in Python. In this case, we are going to walk through a very simple example where a user trains a machine learning model and logs the associate metadata that I talked about on the previous slide. It all starts with the creation of a new run using the MLflow start run directives. A run is a parent for a training session. After a training session has been initialized MLflows log by our directive can be used to log hyperparameter information such as the number of layers in the neural network or the alpha parameters associated with the logistic regression algorithm. After this point, users can simply inject any training goal that they may already be executing. MLflow is not at all prescriptive or restrictive about the type of code that can run within a model training session. After the model has been fit, performance metrics are obtained and then logged using the MLflow log metric directive. Research groups and business often use sophisticated plotting tools to produce visualizations of models performance and these visualizations can be directly logged using the MLflow log artifact directive. It is also worth noting that MLflow UI also provides its own visualizations. Finally, the most important part for reproducibility comes from an MLflow model specific integration for persisting the model artifact itself. For example, this slide solves the MLflow TensorFlow log model directive, which will persist your TensorFlow graph in an MLflow model format, which you will learn more about that later and upload it to the centralized repository so that colleagues can download and begin using that model. Let's talk a little bit about how you can get started with MLflow Tracking within your organization. The MLflow Tracking service back end is divided into two components. The first is an entity or metadata store that is designed to collect and aggregate all of the lightweight metadata associated with a training sessions. This is for geometrics, your parameters and show some samples. For example, the metadata store is designed to work with any Unix or Windows file system. Is also compatible with a wide variety of SQL databases via SQLAlchemy. This includes PostgreSQL, MySQL, and SQLite. Finally, for organizations that want to bring their own infra, the metadata store provides a restful abstraction. This allows general organization to plug in any particular infrastructure restfully and implement the metadata startup traps. The second aspect of the MLflow backend is for heavier weight artifacts, such as those training data files and models. They artifacts store is also designed to run on top of variety of existing production infra, such as Amazon S3, Azure Blob storage, HDFS, Google Cloud Storage, the Databricks File Systems, et cetera. There are many options that lightly fit to your organizations use case for getting started with MLflow Tracking.