This document describes the Feature Management page operations in the DataBuddy console, including searching and filtering feature tables, viewing feature table details, and publishing offline feature tables as online feature tables.
Tip
The Feature Management page is a pure index view and does not provide buttons for creating feature tables or batch import. Feature tables are created through the create_table method of the Feature Engineering SDK, or existing tables are brought under management through the automatic recognition method described below. Prerequisites
You have activated the DataBuddy service and completed workspace initialization.
The current account has the corresponding view or metadata maintenance permissions on the target Catalog / Schema.
Feature Management List Search and Filtering
In the left sidebar, choose Data Science > Feature Management to go to the Feature Management list page. The list displays all recognized feature tables in the current Workspace in a pure index view.
Top action bar
Search feature tables: Perform a fuzzy search by feature table name.
Scope filter: Filter feature tables by Owner, Catalog (multiple selection supported), and Tag.
Refresh: Reload the list to obtain the latest status.
Buddy: Open the Buddy entry to interact with the agent in real time.
Feature table list area
Field | Description |
Feature Table Name | catalog.schema.table format. Click to go to the feature table details page.
|
Owner | Owner registered for the table in Catalog |
Online Table | Name of the Catalog where the associated online feature table resides (hover over it to view the full name); empty if no online table is published. |
Last update time. | Last update time of table data or metadata |
Tags | Tag set maintained in Catalog |
Description information. | Table description maintained in Catalog |
Viewing Feature Table Details
A feature table is essentially a table in Catalog for which a primary key and a timestamp key have been declared using the Feature Engineering SDK. Therefore, its details page is the asset details page of the table in the data catalog. You can go to the details page in either of the following ways:
Go to from the feature management list: Click the feature table name in the feature management list.
Go to from the data catalog: In the left sidebar, choose Catalog, expand the target Catalog > Schema > table, and click the corresponding feature table.
Top Operation Column
The top of the page displays the name and path of the current feature table (Quick Access / <catalog> / <database> / <table>) and a set of action entries.
Operation | Description |
Search Field Name | Quickly filter by field name in the field list of the current table. |
Create from Table | Dropdown menu for quickly initiating downstream operations based on the current feature table (see the table below for details). |
Renaming a CVD Instance | Rename Feature Table |
Delete a Table | Delete the current feature table (equivalent to the SDK's drop_table, and the operation cannot be undone). |
Buddy | Enter Buddy with the current table context in one click for intelligent analysis. |
Create from Table dropdown option:
Entries | Description |
Online Table | |
NoteBook | Create a Notebook and automatically bring in the current table for direct reading and writing of feature data. |
SQL Explorer | Open SQL Explorer and prefill the current table for ad hoc queries. |
Dashboard | Create a visual dashboard based on the current table. |
Analysis Space | Enter Buddy to perform conversational analysis on the current table. |
Quality Task | Configure a data quality validation task for the current table. |
Power BI Connector | Obtain the configuration for connecting Power BI to the current table. |
Tag Page
The details page provides the following tabs: Overview, Data Preview, Lineage, Permissions, Details, Change History, and Quality.
Overview: The main entry for maintaining feature table metadata. You can click Add Description to add a business description for the table, edit the Owner, and click Add Tag to maintain table-level tags. In the field list, you can edit the Field Description, add Tags to fields (primary key fields are marked with PK, and timestamp key fields are marked accordingly), and add masking policies.
Data Preview: View sample data of the feature table.
Lineage: View the upstream and downstream lineage of the table.
Permission: View and manage access permissions for the table.
Details: View the Schema, field definitions, and storage information of the table.
Change History: View the change records of the table structure and data.
Quality: View data quality check results.
Tip
Metadata such as table-level descriptions, owners, field descriptions, and field tags is centrally maintained by Catalog. After modification, it is synchronized to the feature management list. We recommend that you complete this metadata before the feature table is officially used for training to help downstream users understand the business meaning of each feature.
Automatically Identifying Existing Tables as Feature Tables
Any table in Catalog that has both a primary key and a timestamp key is automatically identified as a feature table, without the need to call the SDK or perform any additional operations on the page. If a table has its primary key and timestamp key specified by the data engineering process or the Feature Engineering SDK at creation, the table immediately appears in the feature management list.
In the field list on the Overview Tab of the table details page, the primary key field is displayed with a PK indicator on the right, and the timestamp key field is displayed with a timestamp icon on the right. However, these two attributes are metadata determined at table creation and read by the backend, and the current UI does not provide an editable entry for marking primary keys or timestamp keys. To have an existing table identified as a feature table, you must ensure that the table has both a primary key and a timestamp key at its source (DML / SQL DDL / Feature Engineering SDK create_table).
Note:
The table is identified as a feature table only when both a primary key and a timestamp key exist simultaneously. Tables with only a primary key or only a timestamp key do not appear in the feature management list.
Verification Method
To check whether a table is identified as a feature table:
1. Choose Catalog in the left sidebar to go to the corresponding Catalog > Schema > Table details page.
2. Check whether any field in the field list is marked as PK (primary key) and whether any field has a timestamp icon.
3. When both conditions are met, go to Data Science > Feature Management to find the table in the list. You can click Refresh on the list page to reload.
Publishing an Online Feature Table
If a model needs to be deployed as an online inference service, the offline feature tables it depends on must first be published as online feature tables, and a synchronization task continuously syncs offline data to online storage (PostgreSQL).
1. Go to Data Catalog and open the details page of the target offline feature table.
2. Select Online Table in Create from Table, and the online table creation window appears.
3. Configure the parameters in the dialog box and submit. The system automatically creates an online feature table and a feature synchronization workflow at the same time.
Tip
Only offline feature tables in Catalog that have a primary key and a timestamp key display the Create Online Table entry. Tables that do not meet the conditions cannot be published as online tables.
Dialog Box Parameters:
Parameter | Description | Required |
Computing Resource | Computing resource for running synchronization tasks | Yes |
Storage Address | PostgreSQL data source for online tables | Yes |
Catalog / Schema / Table Name | Target Catalog, Schema, and table name of the online feature table | Yes |
Synchronization method | Snapshot / Scheduled trigger / Continuous run | Yes |
Select and Configure Sync Method:
Synchronization method | Scenario | Trigger Logic |
Snapshot | Synchronize the current snapshot of the offline feature table to the online table at one time, commonly used for initial publishing or temporary refresh. | Execute a single synchronization immediately after submission. |
Scheduled Triggering | Update from the offline feature table to the online table periodically, for example, synchronize the features generated on the current day in the early morning. | Trigger on a scheduled basis or by using a Cron expression. |
Continuous running | Continuously run synchronization tasks when real-time requirements are high. | Start the next execution immediately after the task completes once. |
The detailed rules for scheduling configuration items are consistent with Workflow scheduling. For more information, see Scheduling and Triggers. In this scenario, note the following differences:
1. In continuous run mode, queuing mode and maximum concurrency configuration are not supported.
2. Task Retry Mode (continuous run mode only):
Failed: A failed task is retried as long as other tasks are still in their first attempt. If all tasks enter the retry state, a new job run is created.
Never: No retry is performed after a failure.
Note:
The Notebook file of the feature synchronization workflow is created by the system and placed in a fixed directory. You are not allowed to modify the task file content, delete the workflow, or adjust the task structure. You can only modify its scheduling configuration and start the run.
FAQs
Q: Why can't I see the table I just created or tagged in the feature management list?
Confirm whether the target table has both a primary key and a timestamp key. Check the field markers on the Catalog table details page. Only tables that meet both conditions are identified as feature tables. You can click Refresh on the list page to reload.
Q: Why are field descriptions and field tags for feature tables maintained in Catalog instead of the feature management module?
In DataBuddy, a feature table is essentially a table in Catalog, and all metadata maintenance logic is handled centrally in Catalog. The Feature Management module reuses the same metadata through redirection, avoiding inconsistencies between two sets of descriptions.
Q: After the owner of a feature table is transferred, can the original owner still maintain tags?
Tag maintenance permissions follow the table permissions in Catalog. After the owner is transferred, if the original owner does not retain the corresponding permissions, they will no longer be able to maintain the table metadata. This mechanism is consistent with Catalog asset management.
References
Scheduling and Triggers