Create and log a table
Follow these steps to log a table to a run. The resulting table is stored as an artifact in W&B and rendered in your project’s workspace.- Initialize a new run with
wandb.init(). - Create a table with the
wandb.TableClass. Use thecolumnsanddataparameters to define the table columns and rows. To control how the table behaves when logged, set the optionallog_modeparameter to:IMMUTABLE(the default),MUTABLE, orINCREMENTAL. See Table Logging Modes in the next section for more information. - Log the table to W&B with
run.log().
a and b, and two rows of data, ["a1", "b1"] and ["a2", "b2"]:
Logging modes
Thewandb.Table log_mode parameter controls how a table is logged, updated, and displayed in the W&B App. Choose one of the following values based on your workflow: IMMUTABLE for a single end-of-run snapshot, MUTABLE for a table that you update after logging, or INCREMENTAL for long-running jobs that log table data in batches.
The following describes the three logging modes, the high-level differences, and common use cases for each mode:
The following sections show example code snippets for each mode along with considerations for when to use each mode.
MUTABLE mode
MUTABLE mode updates an existing table by replacing it with a new one. MUTABLE mode is useful when you want to add new columns and rows to an existing table in a non-iterative process. Within the UI, the table is rendered with all rows and columns, including the new ones added after the initial log.
In
MUTABLE mode, the table object is replaced each time you log the table. Overwriting a table with a new one is computationally expensive and can be slow for large tables.MUTABLE mode, log it, and then add new columns to it. The table object is logged three times: once with the initial data, once with the confidence scores, and once with the final predictions.
The following example uses a placeholder function
load_eval_data() to load data and a placeholder function model.predict() to make predictions. Replace these with your own data loading and prediction functions.INCREMENTAL mode instead.
INCREMENTAL mode
In INCREMENTAL mode, you log batches of rows to a table during the machine learning experiment. This is ideal for monitoring long-running jobs or when working with large tables that would be inefficient to log during the run for updates. Within the UI, the table is updated with new rows as they are logged, so you can view the latest data without waiting for the entire run to finish. You can also step through the increments to view the table at different points in time.
Run workspaces in W&B have a limit of 100 increments. If you log more than 100 increments, only the most recent 100 are shown in the run workspace.
INCREMENTAL mode, logs it, and then adds new rows to it. The table is logged once per training step (step). The example uses placeholder functions (get_training_batch(), train_model_on_batch(), and predict_on_batch()). Replace these with your own data loading, training, and prediction functions.
log_mode="MUTABLE"). However, W&B may not render all rows in the table if you log a large number of increments. To update and view your table data while your run is ongoing and to have all the data available for analysis, consider using two tables: one with INCREMENTAL log mode and one with IMMUTABLE log mode.
The following example shows how to combine INCREMENTAL and IMMUTABLE logging modes to achieve this.
incr_table is logged incrementally (with log_mode="INCREMENTAL") during training. This lets you log and view updates to the table as new data is processed. At the end of training, an immutable table (final_table) is created with all data from the incremental table. The immutable table is logged to preserve the complete dataset for further analysis and to let you view all rows in W&B.
Examples
The following examples show end-to-end logging patterns for common workflows: enriching evaluation results, resuming runs that log incremental tables, and incrementally logging batches during training.Enrich evaluation results with MUTABLE
Resume runs with INCREMENTAL tables
You can continue logging to an incremental table when resuming a run:
Increments are logged to a new table if you turn off summaries on a key used for the incremental table using
wandb.Run.define_metric("<table_key>", summary="none") or wandb.Run.define_metric("*", summary="none").