After you start an instance, you can view the basic information of the instance on the Basic Information page. For more information about how to start an instance, see Preparations. After you use a server SDK to push data, you can view the quota usage of existing user and item tables. If you use historical data to start an instance, you can view the related information immediately after the instance is started.
If the used quota is highlighted red, the total quota is exceeded. This situation has the following impacts:
If the queries per second (QPS) exceeds the total quota that you have purchased, AIRec performs throttling to prohibit access that consumes excess traffic. Solution: Define a strategy in advance. When the business volume increases, increase the QPS quota to meet business requirements.
If the numbers of users and items exceed the quotas that you have purchased, data addition and update operations performed by using server SDKs fail, and the behavioral data cannot be uploaded. Solution: Increase the quotas or use a DELETE command to delete invalid data.
We recommend that you configure alerts in the CloudMonitor console. This way, the alerts can be reported in a timely manner when your quota is exceeded. For more information about alert configurations, see View the metrics and configure alert rules.
Note: The QPS that you measured is an instantaneous value.
After an instance is started, you can view data source information of user, item, and behavioral tables on the Data Sources page.
Note: You can use a Umeng SDK or a server SDK to upload data sources from a behavioral table.
Note: If you fail to start the instance by using historical data, you can click Data Quality Report to view the failure cause.
If you enable offline storage, the offline data required for training the AIRec model is stored in MaxCompute that is within your enterprise account. In this case, make sure that the offline data is stable and you can manage the data.
Note: Do not perform high-risk operations on offline data, for example, add, delete, and rewrite the data. Otherwise, offline data computing performed by AIRec is affected.
For detailed operations on MaxCompute, see the MaxCompute documentation.
For more information about how to grant AIRec the permissions to read data from and write data to MaxCompute, see Grant permissions on offline storage to AIRec.
1. MaxCompute tables that store offline data are automatically created by AIRec. The tables are named in the following formats:
User table: airec_cn_xxx_user
Item table: airec_cn_xxx_item
Behavioral table: airec_cn_xxx_behavior
xxx specifies the ID of the AIRec instance. If the name of a MaxCompute table that is automatically created by AIRec conflicts with the name of an existing table, you can click Rename to rename the table. We recommend that you use a separate MaxCompute project to store offline data. Do not write data to the tables that store the offline data unless necessary.
2. The user, item, and behavioral tables that store offline data are partitioned tables. Each partition in these tables contains two partition fields:
hh. These fields are of the STRING type. AIRec generates a partition on an hourly basis. In the partition, the
ds partition field indicates the date that corresponds to the last hour and the
hh partition field indicates the last hour.
3. We recommend that you do not change the partition lifecycle. If you need to change the partition lifecycle due to storage issues of MaxCompute, follow the instructions in the MaxCompute documentation or contact AIRec technical support.
4. A shortened partition lifecycle may have the following impacts:
Each partition of the user table or item table stores full data. Therefore, a shortened table lifecycle has a minor impact but data rollback may fail.
Each partition stores only the hourly incremental data. Therefore, a shortened table lifecycle affects the training datasets of AIRec and may affect the recommendation results.
AIRec algorithm policies require that the partitions that are generated in the last 24 hours or a longer period of time must be retained in the user and item tables. The policies also require that the partitions that are generated in the last hour or a longer period of time must be retained in the behavioral table. If you delete these partitions, unknown errors may occur.
Note: We recommend that you do not change the partition lifecycle. If you need to change the partition lifecycle due to special reasons, submit a ticket or contact AIRec technical support in the DingTalk group.