TensorFlow has become an ecosystem consisting of many valuable assets. At the core of its popularity and versatility is a comprehensive machine learning library and model templates that evolve quickly with new features and capabilities. This popularity comes at a cost, and that cost is expressed as complexity, intricate dependencies, and API updates or deprecation timelines that can easily break the models and workflow that were laboriously built not too long ago. It is one thing to learn and use the latest improvement in your code as you build a model to experiment with your ideas and hypotheses, but it is quite another if your job is to build a model for long-term production use, maintenance, and support.

Another problem associated with early TensorFlow in general concerned its code debugging process. In TensorFlow 1, lazy execution makes it rather tricky to test or debug your code because the code is not executed unless it is wrapped in a session, AKA a graph. Starting with TensorFlow 2, eager execution finally becomes a first-class citizen. Also, another welcome addition to TensorFlow 2 is the adoption of the Keras high-level API. This makes it much easier to code, experiment with, and maintain your model. It also improves the readability of your code and its training flow.

For enterprise adoption, there are typically these three major challenges that are of concern for stakeholders:

• The first challenge is scale. A production-grade model has to be trained with large amounts of data, and often it is not practical or possible to fit into a single-node computer's memory. This also can be thought of as another problem: how do you pass training data to the model? It seems the natural and instinctive way is to declare and involve the entire dataset as a Pythonic structure such as a NumPy array or a pandas DataFrame, as we have seen in so many open source examples. But if the data is too large, then it seems reasonable to use another way of passing data into a model instance, similar to the Python iterator. In fact, TensorFlow.io and TensorFlow dataset libraries are specifically provided to address this issue. We will see how they ingest data in batches to a model training process in the subsequent chapters.
• The second challenge that typically arises in consideration of enterprise adoption of TensorFlow is the manageability of the development environment. Backward compatibility is not a strength of TensorFlow, because there are historically very quick updates to and new releases of APIs that replace or deprecate old ones. This includes but is not limited to library version, API signature, and usage style deprecation. As you can imagine by now, this is a deal-breaker for development, debugging, and maintenance of the codebase; it also doesn't help with managing the stability and reproducibility of a production environment and its scoring results. It can easily become a nightmare for someone who manages and controls a machine learning development infrastructure and the standard practices in an enterprise project.
• The third challenge is the efforts for API improvements, patch releases, and bug fixes. To address this, TensorFlow rolls these efforts into long-term support. Typically, for any TensorFlow release, Google's TensorFlow team is committed to providing these fixes for up to a year only. However, for an enterprise, this is too short for them to get a proper return on investment from the development cycle. Therefore, for enterprises' mission-critical performance, a longer commitment to TensorFlow releases is essential.

TensorFlow Enterprise was created to address these challenges. TensorFlow Enterprise is a special distribution of TensorFlow that is exclusively available through Google Cloud's various services. TensorFlow Enterprise is available through the following:

• Google Cloud AI Notebooks
• Google Cloud AI Deep Learning VMs
• Google Cloud AI Deep Learning Containers
• Partially available on Google Cloud AI Training

The dependencies such as drivers and library version compatibility are managed by Google Cloud. It also provides optimized connectivity with other Google Cloud services, such as Cloud Storage and the data warehouse (BigQuery). Currently, TensorFlow Enterprise supports versions 1.15, 2.1, and 2.3 of Google Cloud, and the GCP and TensorFlow teams will provide long-term support for up to three years, including bug fixes and updates.

In addition to these exclusive services and managed features, the TensorFlow team also takes enterprise support to another level by offering a white-glove service. This is a separate service from Google Cloud Support. In this case, TensorFlow engineers in Google will work with qualified enterprise customers to solve problems or provide bug fixes in cutting edge AI applications.

TensorFlow Enterprise packages

At the time of writing this book, TensorFlow Enterprise includes the following packages:

Figure 1.1 – TensorFlow packages

We will have more to say about how to launch JupyterLab in Google AI Platform in Chapter 2, Running TensorFlow Enterprise in Google AI Platform, but for now, as a demonstration, the following command can be executed as a CLI command in a JupyterLab cell. It will provide the version for each package in your instance so that you can be sure of version consistency:

!pip list | grep tensorflow

Here's the output:

Figure 1.2 – Google Cloud AI Platform JupyterLab environment

We confirmed the environment is running a TensorFlow Enterprise distribution and all the library versions. Knowing this would help in future debugging and collaboration efforts.

Assuming you have a Google Cloud account already set up with a billing method, before you can start using TensorFlow Enterprise, there are some one-time setup steps that you must complete in Google Cloud. This setup consists of the following steps:

1. Create a cloud project and enable billing.
2. Create a Google Cloud Storage bucket.
3. Enable the necessary APIs.

The following are some quick instructions for these steps.

Setting up a cloud environment

Now we are going to take a look at what we need to set up in Google Cloud before we can start using TensorFlow Enterprise. These setups are needed so that essential Google Cloud services can integrate seamlessly into the user tenant. For example, the project ID is used to enable resource creation credentials and access for different services when working with data in the TensorFlow workflow. And by virtue of the project ID, you can read and write data into your Cloud Storage and data warehouse.

Creating a project

This is the first step. It is needed in order to enable billing so you can use nearly all Google Cloud resources. Most resources will ask for a project ID. It also helps you organize and track your spending by knowing which services contribute to each workload. Let's get started:

1. The URL for the page to create a project ID is https://console.cloud.google.com/cloud-resource-manager.

   After you have signed into the GCP portal, you will see a panel similar to this:

   

   Figure 1.3 – Google Cloud's project creation panel

2. Click on CREATE PROJECT:
   

   Figure 1.4 – Creating a new project

3. Then provide a project name, and the platform will instantly generate a project ID for you. You can either accept it or edit it. It may give you a warning regarding how many projects you can create if you already have a few active projects:
   

   Figure 1.5 – Project name and project ID assignment

4. Make a note of the project name and project ID. Keep these handy for future use. Hit CREATE and soon you will see the platform dashboard for this project:

Figure 1.6 – The main project management panel

The project ID will frequently be used when accessing data storage. It is also used to keep track of resource consumption and allocation in a cloud tenant.

Creating a Google Cloud Storage bucket

A Google Cloud Storage bucket is a common way to store models and model assets from a model training job. Creating a storage bucket is very easy. Just look for Storage in the left panel and select Browser:

Figure 1.7 – Google Cloud's Storage options

Click CREATE BUCKET, and follow the instructions as indicated in the panel. In all cases, there are default options selected for you:

1. Choose where to store your data. This is a trade-off between cost and availability as measured by performance. The default is multi-region to ensure the highest availability.
2. Choose a default storage class for your data. This choice lets you decide on costs related to retrieval operations. The default is the standard level for frequently accessed data.
3. Choose how to control access to objects. This offers two different access levels for the bucket. The default is object-level permissions (ACLs) in addition to bucket level permission (IAM).
4. Advanced settings (optional). Here, you can choose the encryption type, bucket retention policy, and any bucket labels. The default is a Google-managed key and no retention policy nor labels:

Figure 1.8 – Storage bucket creation process and choices

Enabling APIs

Now we have a project, but before we start consuming Google Cloud services, we need to enable some APIs. This process needs to be done only once, usually as the project ID is created:

1. For now, let's enable the Compute Engine API for the project of your choice:
   

   Figure 1.9 – Google Cloud APIs and Services for the project

   Optional: Then select ENABLE APIS AND SERVICES.

   You may do it here now, or as you go through the exercises in this book. If you need to use a particular cloud service for the first time, you can enable the API as you go along:

   

   Figure 1.10 – Enabling APIs and Services

2. In the search box, type Compute Engine API:
   

   Figure 1.11 – Enabling the Compute Engine API

3. You will see the status of the Compute Engine API in your project as shown in the following screenshot. Enable it if it's not already enabled:

Figure 1.12 – Google Cloud Compute Engine API

For now, this is good enough. There are more APIs that you'll need as you go through the examples in this book; GCP will ask you to enable the API when relevant. You can do so at that time.

If you wish, you may repeat the preceding procedure to enable several other APIs as well: specifically, the BigQuery API, BigQuery Data Transfer API, BigQuery Connection API, Service Usage API, Cloud Storage, and the Storage Transfer API.

Next, let's take a look at how to move data in a storage bucket into a table inside a BigQuery data warehouse.

We will use a simple example of putting data stored in a Google Cloud bucket into a table that can be queried by BigQuery. The easiest way to do so is to use the BigQuery UI. Make sure it is in the right project. We will use this example to create a dataset that contains one table.

You can navigate to BigQuery by searching for it in the search bar of the GCP portal, as in the following screenshot:

Figure 1.13 – Searching for BigQuery

You will see BigQuery being suggested. Click on it and it will take you to the BigQuery portal:

Figure 1.14 – BigQuery and the data warehouse query portal

Here are the steps to create a persistent table in the BigQuery data warehouse:

1. Select Create dataset:
   

   Figure 1.15 – Creating a dataset for the project

2. Make sure you are in the dataset that you just created. Now click CREATE TABLE:
   

   Figure 1.16 – Creating a table for the dataset

   In the Source section, under Source, in the Create table from section, select Google Cloud Storage:

   

   Figure 1.17 – Populating the table by specifying a data source

3. Then it will transition to another dialog box. You may enter the name of the file or use the Browse option to find the file stored in the bucket. In this case, a CSV file has already been put in my Google Cloud Storage bucket. You may either put your own CSV file into the storage bucket, or download the one I used from https://data.mendeley.com/datasets/7xwsksdpy3/1. Also, enter the column names and datatypes as the schema:
   

   Figure 1.18 – An example of populating a table using an existing CSV file stored in the bucket

4. In the Schema section, use Auto-detect, and in the Advanced options, since the first row is an array of column names, we need to tell it to skip the first row:
   

   Figure 1.19 – Handling column names for the table

5. Once the table is created, you can click QUERY TABLE to update the SQL query syntax, or just enter this query:

   SELECT * FROM `project1-190517.myworkdataset.iris` LIMIT 1000

6. Execute the preceding query and now click on Run:

Figure 1.20 – Running a query to examine the table

There are many different data source types, as well as many different ways to create a data warehouse from raw data. This is just a simple example for structured data. For more information on other data sources and types, please refer to the BigQuery documentation at https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-csv#console.

Now you have learned how to create a persistent table in your BigQuery data warehouse using the raw data in your storage bucket.

We used a CSV file as an example and added it to BigQuery as a table. In the next section, we are going to see how to connect TensorFlow to our data stored in BigQuery and the Cloud Storage bucket. Now we are ready to launch an instance of TensorFlow Enterprise running on AI Platform.

In this section, we are going to see firsthand how easy it is to access data stored in one of the Google Cloud Storage options, such as a storage bucket or BigQuery. To do so, we need to configure an environment to execute some example TensorFlow API code and command-line tools in this section. The easiest way to use TensorFlow Enterprise is through the AI Platform Notebook in Google Cloud:

1. In the GCP portal, search for AI Platform.
2. Then select NEW INSTANCE, with TensorFlow Enterprise 2.3 and Without GPUs. Then click OPEN JUPYTERLAB:
   

   Figure 1.21 – The Google Cloud AI Platform and instance creation

3. Click on Python 3, and it will provide a new notebook to execute the remainder of this chapter's examples:

Figure 1.22 – A JupyterLab environment hosted by AI Platform

An instance of TensorFlow Enterprise running on AI Platform is now ready for use. Next, we are going to use this platform to perform some data I/O.

TensorFlow Enterprise can easily access data sources in Google Cloud Storage as well as BigQuery. Either of these data sources can easily host gigabytes to terabytes of data. Reading training data into the JupyterLab runtime at this magnitude of size is definitely out of question, however. Therefore, streaming data as batches through training is the way to handle data ingestion. The tf.data API is the way to build a data ingestion pipeline that aggregates data from files in a distributed system. After this step, the data object can go through transformation steps and evolve into a new data object for training.

In this section, we are going to learn basic coding patterns for the following tasks:

• Reading data from a Cloud Storage bucket
• Reading data from a BigQuery table
• Writing data into a Cloud Storage bucket
• Writing data into BigQuery table

After this, you will have a good grasp of reading and writing data to a Google Cloud Storage option and persisting your data or objects produced as a result of your TensorFlow runtime.

Cloud Storage Reader

Cloud Storage Reader is integrated with tf.data, so a tf.data object can easily access data in Google Cloud Storage. For example, the following code snippet demonstrates how to read a tfrecord dataset:

my_train_dataset = tf.data.TFRecordDataset('gs://<BUCKET_NAME>/<FILE_NAME>*.tfrecord')
my_train_dataset = my_train_dataset.repeat()
my_train_dataset = my_train_dataset.batch()
…
model.fit(my_train_dataset, …)

In the example preceding pattern, the file stored in the bucket is serialized into tfrecord, which is a binary format of your original data. This is a very common way of storing and serializing large amounts of data or files in the cloud for TensorFlow consumption. This format enables a more efficient read for data being streamed over a network. We will discuss tfrecord in more detail in a future chapter.

BigQuery Reader

Likewise, BigQuery Reader is also integrated into the TensorFlow Enterprise environment, so training data or derived datasets stored in BigQuery can be consumed by TensorFlow Enterprise.

There are three commonly used methods to read a table stored in a BigQuery data warehouse. The first way is the %%bigquery magic command. The second way is using the BigQuery API in a general Python runtime, and the third way is to use TensorFlow I/O. Each has its advantages.

The BigQuery magic command

This method is perfect for running SQL statements directly in a JupyterLab cell. This is equivalent to switching the cell's command interpreter. The %%bigquery interpreter executes a standard SQL query and the results are returned as a pandas DataFrame.

The following code snippet shows how to use the %%bigquery interpreter and assign a pandas DataFrame name to the result. Each step is a JupyterLab cell:

1. Specify a project ID. This JupyterLab cell uses a default interpreter. Therefore, this is a Python variable. If the BigQuery table is in the same project, then you don't need to specify the project ID:

   project_id = '<PROJECT-XXXXX>'

2. Invoke the %%bigquery magic command, and assign the project ID and a DataFrame name to hold the result:

   %%bigquery --project $project_id mydataframe
   SELECT * from `bigquery-public-data.covid19_jhu_csse.summary` limit 5

   If the table is in the same project as you currently running from, you don't need --project argument.

3. Verify the result is a pandas DataFrame:

   type(mydataframe)

4. Show the DataFrame:

   mydataframe

The complete code snippet for this example is as follows:

Figure 1.23 – Code snippet for BigQuery and Python runtime integration

Here are the key takeaways:

• It is required to have a project ID in order to use the BigQuery API.
• You may pass a Python variable such as the project ID as a value into the cell that runs the %%bigquery interpreter using the $ prefix.
• In order for the result to be reusable further by the Python preprocessing functionality or for TensorFlow consumption, you need to specify a name for the DataFrame that will hold the query result.

The Python BigQuery API

The second method by which we can invoke the BigQuery API is through Google Cloud's BigQuery client. This will give us direct access to the data, execute the query, and allow us to receive the results right away. This method does not require the user to know about the table schema. In fact, it simply wraps a SQL statement inside the BigQuery client instantiated through a library call.

This code snippet demonstrates how to invoke the BigQuery API and use it to return the results in a pandas DataFrame:

from google.cloud import bigquery
project_id ='project-xxxxx'
client = bigquery.Client(project=project_id)
sample_count = 1000
row_count = client.query('''
  SELECT 
    COUNT(*) as total
  FROM `bigquery-public-data.covid19_jhu_csse.summary`''').to_dataframe().total[0]
df = client.query('''
  SELECT
    *
  FROM
    `bigquery-public-data.covid19_jhu_csse.summary`
  WHERE RAND() < %d/%d
''' % (sample_count, row_count)).to_dataframe()
print('Full dataset has %d rows' % row_count)

The output of the preceding code is as follows:

Figure 1.24 – Code output

Let's take a closer look at the preceding code:

• An import of the BigQuery library is required to create a BigQuery client.
• The project ID is required for using this API to create a BigQuery client.
• This client wraps a SQL statement and executes it.
• The returned data can be easily converted to a pandas DataFrame right away.

The pandas DataFrame rendition of the BigQuery table has the following columns:

Figure 1.25 – The pandas DataFrame rendition of the BigQuery table

This is ready for further consumption. It is now a pandas DataFrame that occupies memory space in your Python runtime.

This method is very straightforward, as it can help you explore the data schema and do simple aggregation and filtering, and since it is basically a SQL statement wrapper, it is very easy to just get the data out of the warehouse and start using it. You didn't have to know much about the table schema to do this.

However, the problem with this approach is when the table is big enough to overflow your memory. TensorFlow I/O can help solve this problem.

TensorFlow I/O

For TensorFlow consumption of BigQuery data, it is better if we use TensorFlow I/O to invoke the BigQuery API. This is because TensorFlow I/O will provide us with a dataset object that represents the query results, rather than the entire results, as in the previous method. A dataset object is the means to stream training data for a model during training. Therefore not all training data has to be in memory at once. This complements mini-batch training, which is arguably the most common implementation of gradient descent optimization used in deep learning. However, this is a bit more complicated than the previous method. It requires you to know the schema of the table. This example uses a public dataset hosted by Google Cloud.

We need to start with the columns of our interest from the table. We can use the previous method to examine the column names and datatypes, and create a session definition:

1. Load the required libraries and set up the variables as follows:

   import tensorflow as tf
   from tensorflow_io.bigquery import BigQueryClient
   PROJECT_ID = 'project-xxxxx' # This is from what you created in your Google Cloud Account. 
   DATASET_GCP_PROJECT_ID = 'bigquery-public-data'
   DATASET_ID = 'covid19_jhu_csse'
   TABLE_ID = 'summary'

2. Instantiate a BigQuery client and specify the batch size:

   batch_size = 2048
   client = BigQueryClient()

3. Use the client to create a read session and specify the columns and datatypes of interest. Notice that when using the BigQuery client, you need to know the correct column names and their respective datatypes:

   read_session = client.read_session(
       'projects/' + PROJECT_ID,
       DATASET_GCP_PROJECT_ID, TABLE_ID, DATASET_ID,
       ['province_state',
          'country_region',
          'confirmed',
          'deaths',
          'date',
          'recovered'
          ],
       [tf.string,
          tf.string,
          tf.int64,
          tf.int64,
          tf.int32,
          tf.int64],
         requested_streams=10
   )

4. Now we can use the session object created to execute a read operation:

   dataset = read_session.parallel_read_rows(sloppy=True).batch(batch_size)

5. Let's take a look at the dataset with type():

   type(dataset)

   Here's the output:

   

   Figure 1.26 – Output

6. In order to actually see the data, we need to convert the dataset ops to a Python iterator and use next() to see the content of the first batch:

   itr = tf.compat.v1.data.make_one_shot_iterator(
       dataset
   )
    next(itr)

The output of the preceding command shows it is organized as an ordered dictionary, where the keys are column names and the values are Tensors:

Figure 1.27 – Raw data as an iterator

Here are the key takeaways:

• TensorFlow I/O's BigQuery Client requires setting up a read session, which consists of column names from your table of interest.
• This client then executes a read operation that also includes data batching.
• The output of the read operation is a TensorFlow ops.
• This ops may be converted to a Python iterator, so it can output the actual data read by the ops.
• This improves the efficiency of memory use during training, as data is sent for training in batches.

Persisting data in BigQuery

We have looked at how to read data stored in Google Storage solutions, such as Cloud Storage buckets or a BigQuery data warehouse, and how to enable the data for consumption by AI Platform's TensorFlow Enterprise instance running in JupyterLab. Now let's take a look at some ways to write data back, or persist our working data, into our cloud Storage.

Our first example concerns writing a file stored in JupyterLab runtime's directory (in some TensorFlow Enterprise documentations, this is also referred to as a local file). The process in general is as follows:

1. For convenience, execute a BigQuery SQL read command on a table from a public dataset.
2. Store the result locally as a comma-separated file (CSV).
3. Write the CSV file to a table in our BigQuery dataset.

Each step is a code cell. The following step-by-step code snippet applies to JupyterLab in any of the three AI platforms (AI Notebook, AI Deep Learning VM, and Deep Learning Container):

1. Designate a project ID:

   project_id = 'project1-190517'

2. Execute the BigQuery SQL command and assign the result to a pandas DataFrame:

   %%bigquery --project $project_id mydataframe
   SELECT * from `bigquery-public-data.covid19_jhu_csse.summary`

   The BigQuery results come back as a pandas DataFrame by default. In this case, we designate the DataFrame name to be mydataframe.

3. Write the pandas DataFrame to a CSV file in a local directory. In this case, we used the /home directory of this JupyterLab runtime:

   import pandas as pd
   mydataframe.to_csv('my_new_data.csv')

4. Designate a dataset name:

   dataset_id = 'my_new_dataset'

5. Use the BigQuery command-line tool to create an empty table in this project's dataset. This command starts with !bq:

   !bq --location=US mk --dataset $dataset_id

   This command creates a new dataset. This dataset doesn't have any tables yet. We are going to write a new table into this dataset in the next step.

6. Write the local CSV file to a new table:

   !bq \
       --location=US \
       load \
       --autodetect \
       --skip_leading_rows=1 \
       --source_format=CSV \
       {dataset_id}.my_new_data_table \
       'my_new_data.csv'

   In this command, since the CSV file is stored in the current directory, its filename of 'my_new_data.csv' will suffice. Otherwise, a full path is required. Also, {dataset_id}.my_new_data_table indicates that we want to write the CSV file into this particular dataset and the table name.

7. Now you can navigate to the BigQuery portal, and you will find the dataset and the table:
   

   Figure 1.28 – The BigQuery portal and navigation to the dataset

   In this case, we have one dataset, which contains one table.

8. Then, execute a simple query, as follows:

Figure 1.29 – A query for examining the table

This is a very simple query where we just want to show 1,000 randomly selected rows. You can now execute this query and the output will be as shown in the following screenshot.

The following query output shows the data from the BigQuery table we just created:

Figure 1.30 – Example table output

Here are the key takeaways:

• Data generated during the TensorFlow workflow in the AI Platform's JupyterLab runtime can be seamlessly persisted as a table in BigQuery.
• Persisting data in a structured format, such as a pandas DataFrame or a CSV file, in BigQuery can easily be done using the BigQuery command-line tool.
• When you need to move a data object (such as a table) between the JupyterLab runtime and BigQuery, use the BigQuery command-line tool with !bq to save time and effort.

Persisting data in a storage bucket

In the previous Persisting data in BigQuery section, we saw how a structured data source such as a CSV file or a pandas DataFrame can be persisted in a BigQuery dataset as a table. In this section, we are going to see how to persist working data such as a NumPy array. In this case, the suitable target storage is a Google Cloud Storage bucket.

The workflow for this demonstration is as follows:

1. For convenience, read a NumPy array from tf.keras.dataset.
2. Save the NumPy array as a pickle (pkl) file. (FYI: The pickle file format, while convenient and easy to use for serializing Python objects, also has its downsides. For one, it may be slow and creates a larger object than the original. Second, a pickle file may contain bugs or security risks for any process that opens it. It is used only for convenience here.)
3. Use the !gsutil storage command-line tool to transfer files from JupyterLab's /home directory (in some documentation, this is referred to as the local directory) to the storage bucket.
4. Use !gsutil to transfer the content in the bucket back to the JupyterLab runtime. Since we will use Python with !gsutil, we need to keep the content in separate cells.

Follow these steps to complete the workflow:

1. Let's use the IMDB dataset because it is already provided in NumPy format:

   import tensorflow as tf
   import pickle as pkl
   (x_train, y_train), (x_test, y_test) = tf.keras.datasets.imdb.load_data(
       path='imdb.npz',
       num_words=None,
       skip_top=0,
       maxlen=None,
       seed=113,
       start_char=1,
       oov_char=2,
       index_from=3
   )
   with open('/home/jupyter/x_train.pkl','wb') as f:
       pkl.dump(x_train, f)

   x_train, y_train, x_test, and y_test are returned as NumPy arrays. Let's use x_train for the purposes of this demonstration. The x_train array is going to be saved as a pkl file in the JupyterLab runtime.

   The preceding code opens the IMDB movie review dataset that is distributed as a part of TensorFlow. This dataset is formatted as tuples of NumPy arrays and separated as training and test partitions. Then we proceed to save the x_train array as a pickle file in the runtime's /home directory. This pickle file will then be persisted in a storage bucket in the next step.

2. Designate a name for the new storage bucket:

   bucket_name = 'ai-platform-bucket'

3. Create a new bucket with the designated name:

   !gsutil mb gs://{bucket_name}/

   Use !gsutil to move the pkl file from the runtime to the storage bucket:

   !gsutil cp /home/jupyter/x_train.pkl gs://{bucket_name}/

4. Read the pkl file back:

   !gsutil cp gs://{bucket_name}/x_train.pkl /home/jupyter/x_train_readback.pkl

5. Now let's inspect the Cloud Storage bucket:

Figure 1.31 – Serializing an object in a bucket from the workflow in AI Platform

Here are the key takeaways:

• Working data generated during the TensorFlow workflow can be persisted as a serialized object in the storage bucket.
• Google AI Platform's JupyterLab environment provides seamless integration between the TensorFlow runtime and the Cloud Storage command-line tool, gsutil.
• When you need to transfer content between Google Cloud Storage and AI Platform, use the !gsutil command-line tool.

This chapter provided a broad overview of the TensorFlow Enterprise environment hosted by Google Cloud AI Platform. We also saw how this platform seamlessly integrates specific tools such as command-line APIs to facilitate the easy transfer of data or objects between the JupyterLab environment and our storage solutions. These tools make it easy to access data stored in BigQuery or in storage buckets, which are the two most commonly used data sources in TensorFlow.

In the next chapter, we will take a closer look at the three ways available in AI Platform to use TensorFlow Enterprise: the Notebook, Deep Learning VM, and Deep Learning Containers.