Before you enable OSS-HDFS, you must be familiar with the relationships between OSS-HDFS and the features of Object Storage Service (OSS). This way, you can properly use OSS-HDFS and prevent data loss.
After OSS-HDFS is enabled for a bucket, data that is written by using OSS-HDFS is stored in the .dlsdata/
directory of the bucket. To ensure the availability of OSS-HDFS or prevent data loss, do not perform write operations on the .dlsdata/
directory or objects in the directory by using methods that are not supported by OSS-HDFS. For example, do not perform the following write operations: rename the directory, delete the directory, and delete objects in the directory.
The following table describes the risks or considerations when you use OSS features that may perform write operations on the .dlsdata/
directory.
Feature | Risk | Description | References |
Retention policy | Data deletion failures | We recommend that you do not enable OSS-HDFS and configure retention policies for a bucket at the same time. For example, OSS-HDFS is enabled for a bucket for which a retention policy is configured. When you use methods supported by OSS-HDFS to delete an object from the | |
Lifecycle rule | Data loss | To configure or modify a lifecycle rule to match all objects in a bucket for which OSS-HDFS is enabled, use the NOT element to exclude the objects that are stored in the If you want to manage the lifecycle of data stored in OSS-HDFS, use the automatic storage tiering feature of OSS-HDFS. | |
Versioning | Automatic data deletion failures and service exceptions | Do not enable OSS-HDFS and versioning for a bucket at the same time. If OSS-HDFS and versioning are enabled for a bucket, OSS-HDFS may not work as expected. To ensure the stability of OSS-HDFS, you need to suspend versioning at the earliest opportunity and configure lifecycle rules to remove delete markers. | |
Delete a directory | Data loss | To maintain OSS-HDFS stability and prevent data loss, do not delete the | |
Delete objects | Data loss | To maintain OSS-HDFS stability and prevent data loss, do not delete objects from the | |
Rename directories | Data loss | To maintain OSS-HDFS stability and prevent data loss, do not rename the | |
Rename objects | Data loss | To maintain OSS-HDFS stability and prevent data loss, do not rename objects in the | |
Upload objects | Data loss | To maintain OSS-HDFS stability and prevent data loss, do not upload objects to the | |
Change the storage classes of objects | Data access failures and billing rule changes | We recommend that you do not change the storage classes of objects in the If you change the storage class of an object in the When you change the storage class of an object to IA, Archive, Cold Archive, or Deep Cold Archive, take note of consequential factors such as the minimum billable size (64 KB), minimum storage duration, and data retrieval fees. | |
Bucket policy | Data access failures, automatic data deletion failures, and unexpected billing | To maintain access to the | |
RAM | Data access failures, automatic data deletion failures, and unexpected billing | When you enable OSS-HDFS for a bucket, the | |
Bucket inventory | Data contamination | To maintain OSS-HDFS availability and prevent data contamination, do not set Inventory Path to | |
Logging | Data contamination | To maintain OSS-HDFS availability and prevent data contamination, do not set Log Prefix to | |
ZIP package decompression | Data contamination and data loss | To maintain OSS-HDFS availability and prevent data contamination, do not set Destination Directory to |
OSS-HDFS stores HDFS data and auxiliary data in the .dlsdata/
directory of OSS buckets. The data consumes OSS storage capacity, and you are charged storage fees. For more information, see Storage capacity usage of OSS-HDFS.