Data access method applied to data lake, data lake and related device

Abstract

This application provides a data access method, a data lake, and related devices for use in a data lake. For a data lake comprising a client, a metadata management node, and an object storage system, the client can request the metadata management node to locate the object path of a data block in a file and generate and encrypt corresponding access tokens at the data block level. Access control for each data block can be achieved through these access tokens. After the client sends an object access request, including the object path of the data block and the encrypted access token, to the object storage system, the object storage system performs strict security authentication on the object access request using the information in the decrypted access token before performing read / write operations based on the object path of the data block. This significantly reduces the risk of data leakage, effectively prevents unauthorized access, enhances data security, and ensures secure data access between the object storage system and the metadata management node in the data lake.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data access method, a data lake, and related equipment applied to a data lake. Background Technology

[0002] Currently, mainstream data lakes typically use object storage systems as the underlying data storage layer and employ metadata management nodes similar to the NameNode in HDFS (Hadoop Distributed File System) to provide metadata management functionality. This allows data lakes to offer highly scalable and cost-effective storage solutions, particularly well-suited for handling the massive file storage demands of big data scenarios. For this architecture, ensuring secure data access between the object storage system and the metadata management node is crucial; therefore, it is essential to research secure data access mechanisms between these two systems. Summary of the Invention

[0003] This application provides a data access method, a data lake, and related devices for use in a data lake, to ensure secure data access between the object storage system and the metadata management node in the data lake.

[0004] This application provides a data access method for a data lake, which includes a client, a metadata management node, and an object storage system. The method is applied to the metadata management node and includes: receiving a file access request sent by the client, the file access request requesting read / write operations on a target data block in a target file, the file access request indicating the filename of the target file and the location information of the target data block in the target file; obtaining the object path of the target data block in the object storage system based on the filename of the target file and the location information of the target data block; generating an access token corresponding to the target data block, and encrypting the access token using an access key to obtain an encrypted access token; returning the object path corresponding to the target data block and the encrypted access token to the client, so that the client sends an object access request for the target data block to the object storage system, the object access request including the encrypted access token and a URI address determined based on the object path corresponding to the target data block.

[0005] This application also provides a data access method for a data lake, which includes a metadata management node and an object storage system. The method is applied to the object storage system and includes: receiving an object access request for a target data block sent by a client, the object access request including an encrypted access token and a URI address determined based on the object path corresponding to the target data block; decrypting the encrypted access token using a decryption key to obtain an access token; performing security authentication on the object access request based on the URI address and the access token in the object access request; and if the security authentication is successful, performing read and write operations on the target data block in the object storage system according to the object path corresponding to the target data block.

[0006] This application embodiment also provides a data lake, including: a client, a metadata management node, and an object storage system; the client is used to send a file access request to the metadata management node, the file access request being used to request read and write operations on a target data block in a target file, and the file access request being used to indicate the filename of the target file and the location information of the target data block in the target file; the metadata management node is used to respond to the received file access request, obtain the object path of the target data block in the object storage system according to the filename of the target file and the location information of the target data block in the file access request; generate an access token corresponding to the target data block, and encrypt the access token using an access key to obtain... The encrypted access token is returned to the client along with the object path corresponding to the target data block. The client also sends an object access request for the target data block to the object storage system. The object access request includes the encrypted access token and a URI address determined based on the object path corresponding to the target data block. In response to the received object access request, the object storage system decrypts the encrypted access token using a decryption key to obtain the access token. It then performs security authentication on the object access request based on the URI address and access token. If the security authentication is successful, it performs read and write operations on the target data block in the object storage system based on the object path corresponding to the target data block.

[0007] This application also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor coupled to the memory for executing the computer program to perform steps in a data access method applied to a data lake.

[0008] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in a data access method applied to a data lake.

[0009] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to implement the steps in a data access method applied to a data lake.

[0010] The technical solution provided in this application addresses a data lake comprising a client, a metadata management node, and an object storage system. The client can request the metadata management node to locate the object path of a data block in a file and generate and encrypt corresponding access tokens at the data block level. These access tokens enable access control for each data block. After the client sends an object access request, including the object path of the data block and the encrypted access token, to the object storage system, the system performs rigorous security authentication on the request using the information in the decrypted access token before performing read / write operations based on the object path of the data block. This ensures that every access is legitimate and secure, significantly reducing the risk of data leakage, effectively preventing unauthorized access, enhancing data security, and guaranteeing secure data access between the object storage system and the metadata management node in the data lake. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0012] Figure 1 Here is a system architecture diagram of an exemplary data lake;

[0013] Figure 2 A signaling interaction diagram for a data access method applied to a data lake, provided in an embodiment of this application;

[0014] Figure 3 This is an example application scenario diagram for hot file statistics;

[0015] Figure 4 Signaling interaction diagram for another data access method applied to a data lake provided in the embodiments of this application;

[0016] Figure 5 A flowchart illustrating a data access method applied to a data lake, as provided in this application embodiment;

[0017] Figure 6 A flowchart illustrating another data access method applied to a data lake, provided as an embodiment of this application;

[0018] Figure 7 A flowchart illustrating another data access method applied to a data lake, provided as an embodiment of this application;

[0019] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship. Furthermore, in the embodiments of this application, "first," "second," "third," etc., are only used to distinguish the content of different objects and have no other special meaning.

[0022] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0023] First, let me explain the terms used in this application:

[0024] A data lake is a system or repository that stores data in its raw format, typically in blocks of objects or files. A data lake is usually a single store for all of an enterprise's data, including raw copies of data from the original systems and transformed data generated for various tasks, such as reporting, visualization, advanced analytics, and machine learning. Essentially, it's a large warehouse storing a wide variety of raw data from an enterprise, accessible, processed, analyzed, and transferable. Data lakes include structured data (rows and columns), semi-structured data, unstructured data, and binary data (such as images, audio, and video) from relational databases. Semi-structured data includes, but is not limited to, CSV (Comma-Separated Values), log data, XML (eXtensible Markup Language), and JSON (JavaScript Object Notation); unstructured data includes, for example, email data, plain text documents, or PDF (Portable Document Format) files. It is a centralized repository that can store structured and unstructured data of any size and supports big data and AI computing. The construction of a data lake provides unified management of metadata on the lake, enterprise-level access control, and seamless integration with multiple computing engines, breaking down data silos and revealing service value.

[0025] HDFS (Hadoop Distributed File System) typically consists of clients, a Name Node, and multiple Data Nodes. During file uploads, the client splits the file into blocks. The client interacts with the Name Node to obtain the file's metadata, including the storage location information of the data blocks on the Data Nodes. Based on this location information, the client interacts with the Data Nodes to write the data blocks. During file reads, the client obtains the storage location information of the data block to be read from the Name Node. The client then interacts with the Data Nodes to read the corresponding data block.

[0026] Object storage systems are object-centric storage systems that store data as objects rather than files, offering advantages such as high reliability, high scalability, and high performance. An object can include data, metadata, and a unique identifier. Data is the actual content to be stored and can be any form of unstructured data, such as text files, images, videos, and backup files. Metadata is descriptive information about the data, containing various attributes such as creation time, content type, and size. Each object has a globally unique identifier, also called a key, used to locate and access the object. In various embodiments of this application, the data within an object can be a data block, and the object's unique identifier can be the storage location information of the data block in the object storage system (also known as the object path of the data block). An object storage system can be, for example, an OSS (Object Storage System).

[0027] Currently, mainstream data lakes typically use object storage systems as the underlying data storage layer and employ metadata management nodes similar to the NameNode in HDFS (Hadoop Distributed File System) to provide metadata management functionality. This allows data lakes to offer highly scalable and cost-effective storage solutions, particularly well-suited for handling the massive file storage demands of big data scenarios. For this architecture, ensuring secure data access between the object storage system and the metadata management node is crucial; therefore, it is essential to research secure data access mechanisms between these two systems.

[0028] Therefore, this application provides a data access method, a data lake, and related devices for use in a data lake. The technical solution provided in this application, targeting a data lake comprising a client, a metadata management node, and an object storage system, allows the client to request the metadata management node to locate the object path of a data block in a file and generate and encrypt corresponding access tokens at the data block level. These access tokens enable access control for each data block. After the client sends an object access request, including the object path of the data block and the encrypted access token, to the object storage system, the object storage system performs strict security authentication on the object access request using the information in the decrypted access token before performing read / write operations based on the object path of the data block. This ensures that every access is legitimate and secure, significantly reducing the risk of data leakage, effectively preventing unauthorized access, enhancing data security, and guaranteeing secure data access between the object storage system and the metadata management node in the data lake.

[0029] The technical solutions of this application and how they solve the aforementioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0030] Figure 1 This is a system architecture diagram of an exemplary data lake. See also... Figure 1 The data lake can include: clients, metadata management nodes, and object storage systems.

[0031] The client is responsible for initiating requests to read or write data in the data lake. The client can communicate with the metadata management node or object storage system through API (Application Programming Interface) or SDK (Software Development Kit).

[0032] The metadata management node is primarily responsible for maintaining and managing metadata information. It can act as the name node in HDFS and provide metadata services compatible with the HDFS interface. Metadata information includes, but is not limited to: filename (FileName), file path (FilePath), file size, location information of data blocks within the file, and object path of data blocks (blockPath).

[0033] Here, filename refers to the name of the file; file path can refer to the complete path of the file in the data lake, which helps to locate the file's location; file size refers to the amount of storage space occupied by the file, in bytes.

[0034] When a file is split into multiple data blocks, in order to correctly reassemble these data blocks to restore the original file, the following key information can be maintained: data block ID, data block offset, and data block length.

[0035] Each data block has a unique data block number, identifying its sequential position within the entire file. For example, the first data block might be marked as 0, the second as 1, and so on. The data block offset can refer to the starting byte position of the data block within the file. For consecutive data blocks, the end position of the previous data block is usually the start position of the next data block. The data block length can represent the actual size of each data block. Except for the last data block, in most cases all data blocks are of the same size (e.g., equal to the set data block size). Depending on the file size, the last data block may be smaller than the set data block size.

[0036] In this embodiment, the location information of a data block in the file can be represented by a data block number or a data block offset, but is not limited to these.

[0037] In this embodiment, the object path of a data block can be understood as the storage location information of the data block in the object storage system. The object path typically follows a structured format and may include the bucket name, file name, and object key. For example, the object path could be my-bucket / data-files / block-001.dat. Here, my-bucket is the bucket name, data-files is the file name, and block-001.dat is the object key.

[0038] In this embodiment, the object storage system is primarily responsible for the persistent storage of data blocks. The client initiates a request and interacts with the metadata management node via API or SDK to obtain necessary metadata information. Based on the metadata information, the client directly communicates with the object storage system to perform specific read or write operations on data blocks.

[0039] Figure 1 The data lake shown is merely an exemplary data lake, and the embodiments of this application do not limit the number of components or the specific composition structure of the data lake. For ease of understanding, it is used as... Figure 1For example, an object storage system may include an object storage system server (e.g., OSS Server) and a storage layer; a metadata management node includes a metadata management node server (e.g., Ns Server) and a database (e.g., DB). The OSS Server handles requests from clients, including upload, download, and delete operations, and interacts with the storage layer to execute these operations. The storage layer is the backend storage service; for example, it stores multiple data blocks and can be a physical disk, a distributed file system, or a cloud storage service. The Ns Server, as the core component of the metadata management node, handles metadata operation requests from clients and interacts with the database to obtain or update metadata information. The database stores metadata, including the mapping between file paths and object paths of at least one data block; that is, the file paths of files and the object paths of data blocks have a one-to-N relationship, where N is a positive integer greater than or equal to 1.

[0040] For specific examples, see Figure 1 As shown in ①, the client sends file write requests or file read requests to the metadata management node via the SDK; see also Figure 1 As shown in ②, the client forwards the file write request or file read request to NsServer; see also Figure 1 As shown in ③, if the client sends a file read request, the Ns Server retrieves the metadata of the file requested to be read from the underlying database and returns it to the client. The file metadata includes at least the mapping relationship between the file path and the object path of the data block. If the client sends a file write request, the Ns Server generates the file metadata and writes the file metadata to the underlying database. The Ns Server can also return the metadata of the file requested to be written to the client.

[0041] The client receives the file's metadata, retrieves the object path of the data block from the metadata, and generates an object access request for the data block based on the object path. The object access request is a standard object access method, and the request method can be either `get()` or `rangeGet()`. The `get()` method allows the client to request the entire content of the object. `rangeGet()` allows the client to request a portion of the object's content instead of the entire object. Object access requests can include object write requests corresponding to file write requests, or object read requests corresponding to file read requests. Object write requests are used to request that a data block be written to the object storage system, and object read requests are used to request that a data block be read from the object storage system. See also... Figure 1 As shown in ④, the client sends an object access request to the OSS Server; see also Figure 1 As shown in Figure ⑤, if the client sends an object write request, the OSS Server writes the data block to the storage layer; if the client sends an object read request, the OSS Server reads the data block from the storage layer and returns it to the client; thus, the data access process of the data lake is completed.

[0042] To better understand the technical solution of this application, the following is combined with... Figure 2 The signaling interaction diagram shown is used for explanation. Figure 2 This is a signaling interaction diagram for a data access method applied to a data lake, provided as an embodiment of this application. See also... Figure 2 Data access methods applied to data lakes may include the following steps:

[0043] 201. The client sends a file access request to the metadata management node.

[0044] Specifically, a file access request is used to request read or write operations on a target data block in a target file. A file access request can be a file write request or a file read request.

[0045] Among them, a file write request is used to request the writing of a new file in the data lake (which can also be understood as creating a new file), or a file write request can be used to request the appending of an already written file.

[0046] For example, regarding a write request to create a new file: the client sends a file write request to the metadata management node, inquiring whether a new file named newfile.txt can be created and retrieving necessary metadata information. The metadata management node returns confirmation information and the necessary metadata information, which includes, but is not limited to: filename, file path, and object paths of the data blocks obtained from splitting the file. Based on the metadata information, the client writes the data blocks to the specified location in the object storage system.

[0047] For example, consider an append-only write operation on an already written file: The client sends a file write request to the metadata management node, inquiring whether an append operation can be performed on the specified file and retrieving necessary metadata information. If the specified file supports append-only writes, the metadata management node returns confirmation information and necessary metadata information, including but not limited to: filename, file path, and the object path of the data block to be appended. The client then writes the data to be appended into a new data block, which is then written to the specified location in the object storage system.

[0048] A file read request can be used to request the reading of a complete written file from the data lake, or it can be used to request the reading of one or more data blocks from a written file.

[0049] For example, for a read request to read an entire file: the client sends a file read request to the metadata management node to query the relevant metadata information of the file to be read. The metadata management node returns the metadata information of the file to be read, which includes, but is not limited to: filename, file path, file size, and object paths of each data block. Based on the metadata information, the client communicates directly with the object storage system and reads all relevant data blocks sequentially. The client then merges the read data blocks in order to restore the original file.

[0050] For example, for a read request to read one or more data blocks from a file (i.e., read a portion of the file's data): the client sends a file read request to the metadata management node, queries the relevant metadata information of the file to be read, and the relevant metadata information includes the object paths of the required data blocks. Based on the metadata information, the client communicates directly with the object storage system and reads only the required data blocks.

[0051] In practical applications, for file writing scenarios, the client can divide the new file to be written into several data blocks and record the position information of each data block in the file. Similarly, for append-only scenarios, the file data to be appended can be written into a new data block, and the position information of the new data block in the file can be recorded.

[0052] In this embodiment, the target file can be of various types, including but not limited to: log files, image files, text files, video files, or database backup files, etc. The file access request for the target file can indicate the filename of the target file and the location information of the target data block within the target file. For cases where the client wants to write the entire file, append to, or read a portion of the file's data, the file access request can carry the filename of the target file and the location information of the target data block within the target file. When the client wants to read the entire file, the file access request can contain only the filename. In this case, although the location information of the target data block within the target file is not explicitly specified, it can be considered that this file access request implicitly includes the location information of all data blocks from the beginning to the end of the file.

[0053] 202. In response to a received file access request, the metadata management node obtains the object path of the target data block in the object storage system based on the file name of the target file and the location information of the target data block in the file access request.

[0054] Specifically, the metadata management node performs the corresponding operation of obtaining the object path of the target data block in the object storage system according to the type of file access request. In this way, the metadata management node can effectively support file write and read operations, ensuring data consistency and efficient access.

[0055] Optionally, the implementation of obtaining the object path of the target data block in the object storage system based on the file name of the target file and the location information of the target data block is as follows: if the file access request is a file write request, then the file path of the target file is determined based on the file name of the target file, and the object path of the target data block in the object storage system is determined, and a mapping relationship between the file path of the target file and the object path of the target data block is established, and the metadata of the target file is generated. The metadata of the target file includes the file name of the target file, the file path of the target file, the location information of the target data block, and the mapping relationship between the file path of the target file and the object path of the target data block.

[0056] Optionally, the implementation of obtaining the object path of the target data block in the object storage system based on the file name of the target file and the location information of the target data block is as follows: if the file access request is a file read request, the metadata of the target file is searched based on the file name of the target file and the location information of the target data block to obtain the object path of the target data block in the object storage system.

[0057] In practical applications, if the file access request is a file read request, the mapping relationship between the file path of the target file and the object path of the target data block can be found in the metadata of the target file based on the filename of the target file and the location information of the target data block. The object path of the target data block can then be obtained from this mapping relationship. It can be understood that the metadata of the target file can include the filename of the target file, the file path of the target file, the location information of each data block, and the mapping relationship between the file path of the target file and the object path of each data block. For each data block included in the target file, the location information of each data block and its corresponding object path are related. Of course, the metadata of the target file can also include the location information of each data block and its corresponding object path. By querying the metadata of the target file based on the filename of the target file and the location information of the target data block, the mapping relationship between the file path of the target file and the object path of the target data block can be found, and the object path of the target data block can be obtained from this mapping relationship. For example, if the location information of the target data block can be represented by a data block number, and the object name in the object path of the target data block is the data block number, then the mapping relationship between the file path of the target file and the object path of the target data block can be found in the metadata of the target file based on the filename of the target file and the location information of the target data block.

[0058] 203. The metadata management node generates an access token corresponding to the target data block, and encrypts the access token using the access key to obtain the encrypted access token.

[0059] In this embodiment, the number of target data blocks is not limited and can be one or more. For multiple target data blocks, a separate access token can be generated for each target data block, with different access tokens corresponding to different target data blocks, thus improving data access security.

[0060] In practical applications, access tokens are generated at the individual data block level, and these tokens enable access control for each data block. There are no restrictions on how access tokens are generated in practice.

[0061] Further, alternatively, fine-grained access control for each data block can be achieved by using multi-dimensional information in the access token (such as object path, access key, access token expiration time, or allowed access mode, at least two of these).

[0062] In practical applications, the access token's expiration time (which can be denoted as expireTime) is the time after which the requested access expires. If the expiration time is exceeded, the access request becomes invalid and access is denied. This prevents clients from continuously accessing a specific data block (or object) in the object storage system, achieving time-sensitive control over secure access.

[0063] Access key (can be denoted as encodeKeyID): This is the encryption key between the metadata management node and the object storage system. It can be updated regularly to prevent leakage and thus prevent security risks, thereby improving the security of data access.

[0064] The object path (which can be denoted as blockPath) corresponding to the target data block in the access token: Access is only granted if the object path corresponding to the data block in the object access request initiated by the client matches the object path corresponding to the target data block in the access token; otherwise, access is denied. This secure access mechanism effectively controls the scope of requests, ensures the security of client-side SDK access to data, and can effectively cope with complex and diverse client-side environments.

[0065] The allowed access modes (referred to as accessModes) in the access token control the type of object access requests initiated by the client. Access is allowed only when the request type matches the allowed access mode; otherwise, access is denied. Allowed access modes include, but are not limited to: create mode (i.e., writing to a new file), delete mode (i.e., deleting a file or data block), read mode (i.e., reading from a file), and so on.

[0066] Assuming the access token is denoted as blockToken, then blockToken = {expireTime, encodeKeyID, blockPath, accessMode}, meaning that blockToken can include information such as expireTime, encodeKeyID, blockPath, and accessMode.

[0067] Alternatively, the method for generating the access token corresponding to the target data block may include generating the access token based on the object path, access key, expiration time of the access token, and allowed access mode corresponding to the target data block.

[0068] In some optional embodiments, the method of generating an access token based on the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode includes: obtaining the file path of the target file; and generating an access token based on the file path of the target file, the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode.

[0069] Specifically, adding the target file's path to the access token facilitates subsequent file-level data analysis. For example, it allows for hotspot file statistical analysis at the file level.

[0070] For example, assuming the file path of the target file is denoted as FilePath, then blockToken = {expireTime, encodeKeyID, blockPath, accessMode, FilePath}.

[0071] In this embodiment, the metadata management node generates an access token, encrypts the access token to obtain an encrypted access token, and returns the encrypted access token to the client.

[0072] It is worth noting that access tokens can be used to control access permissions to objects (i.e., data blocks) in an object storage system, thereby enhancing data access security. The metadata management node encrypts the access tokens, ensuring their security during data transmission.

[0073] 204. The metadata management node returns the object path and encrypted access token corresponding to the target data block to the client.

[0074] 205. The client sends an object access request for the target data block to the object storage system.

[0075] In this embodiment, the metadata management node returns the object path and encrypted access token corresponding to the target data block to the client. The client determines the URI (Uniform Resource Identifier) ​​address corresponding to the target data block based on the object path. Optionally, the object path corresponding to the target data block can be used as the URI of the target data block. For example, if the object path corresponding to the target data block is prefix / 1127646872980113064, the URI of the target data block is also prefix / 1127646872980113064.

[0076] In practical applications, clients can combine the URL of the object storage system (Uniform Resource Locator) with the URI corresponding to the target data block to construct a complete URL for accessing the target data block. For example, combining the object storage system URL https: / / object-storage.example.com with the object path yields the complete URL https: / / object-storage.example.com / prefix / 1127646872980113064. The target data block's URL is added to the request line, and the encrypted access token is added to the request headers to construct an HTTP (Hypertext Transfer Protocol) request to access the target data block. This HTTP request is essentially an object access request for the target data block. Thus, the object access request includes the encrypted access token and the URI address determined based on the object path corresponding to the target data block.

[0077] 206. In response to a received object access request, the object storage system uses a decryption key to decrypt the encrypted access token to obtain the access token.

[0078] 207. Perform security authentication on the object access request based on the URI address and access token in the object access request.

[0079] Specifically, after receiving an object access request from a client, the object storage system decrypts the encrypted access token using a decryption key to obtain the access token. Then, it performs security authentication on the object access request based on the URI address in the object access request and the access token.

[0080] In practical applications, security authentication of object access requests is performed based on the URI address in the object access request and partial token information in the access token. For example, it checks whether the URI address in the object access request matches the object path corresponding to the target data block in the access token; it checks whether the current time is less than the expiration time in the access token; if all the checks result in yes, the security authentication passes; if at least one check result in no, the security authentication fails. Another example is checking whether the URI address in the object access request matches the object path corresponding to the target data block in the access token; it checks whether the current time is less than the expiration time in the access token; it checks whether the decryption key matches the access key in the access token; if all the checks result in yes, the security authentication passes; if at least one check result in no, the security authentication fails.

[0081] Optionally, the object access request can be further authenticated in multiple dimensions based on the URI address in the object access request and all token information in the access token, thereby improving the reliability of the security authentication.

[0082] Based on this, the access token includes: the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode. Accordingly, the implementation method for security authentication of the object access request based on the URI address in the object access request and the access token is as follows: determine whether the URI address in the object access request is consistent with the object path corresponding to the target data block in the access token; determine whether the current time is less than the expiration time in the access token; determine whether the decryption key is consistent with the access key in the access token; determine whether the access mode of the object access request belongs to the allowed access mode in the access token; if the result of all the judgment operations is yes, the security authentication is successful; if the result of at least one of the judgment operations is no, the security authentication fails.

[0083] 208. If the security authentication is successful, read and write operations will be performed on the target data block in the object storage system according to the object path corresponding to the target data block.

[0084] Specifically, if the security authentication is successful, and the object access request is a read request, the object storage system reads the target data block from the object storage system according to the object path corresponding to the target data block and returns it to the client. If the object access request is a write request, the object storage system writes the target data block to the object storage system according to the object path corresponding to the target data block, and can also return a write success message to the client.

[0085] Of course, if security authentication fails, the object storage system will refuse to perform read or write operations, meaning it will refuse to read the target data block from the object storage system or write the target data block to the object storage system. If security authentication fails, the object storage system can also return a security authentication failure message or access failure information to the client, etc.

[0086] The technical solution provided in this application addresses a data lake comprising a client, a metadata management node, and an object storage system. The client can request the metadata management node to locate the object path of a data block in a file and generate and encrypt corresponding access tokens at the data block level. These access tokens enable access control for each data block. After the client sends an object access request, including the object path of the data block and the encrypted access token, to the object storage system, the system performs rigorous security authentication on the request using the information in the decrypted access token before performing read / write operations based on the object path of the data block. This ensures that every access is legitimate and secure, significantly reducing the risk of data leakage, effectively preventing unauthorized access, enhancing data security, and guaranteeing secure data access between the object storage system and the metadata management node in the data lake.

[0087] Data lakes, because their data storage foundation is an object storage system, inherently possess unlimited scalability, thus capable of handling the massive file storage requirements of big data scenarios. In native HDFS, raw file data is split into multiple data blocks, and each data block, acting as an object, is sequentially written to a data node for storage according to the block model. Data lakes still use the block model, but the split data blocks are sequentially written to the object storage system. When subsequently reading file content, the mapping relationship between files and objects needs to be used to read the data sequentially from the object storage system, thus transforming the data access method into a standard object access method. After the data access method changes to object access, the corresponding file information cannot be perceived when accessing objects in the object storage system, making it impossible to perform data analysis from a file-level perspective, and also hindering system stress analysis and operation and maintenance management of the data lake. For example, it is impossible to perform hot file statistics from a file-level perspective, failing to adequately meet users' demands for hot file statistics. Especially in big data analysis scenarios, read requests account for a very large proportion of all requests, for example, 80%. When data access is changed to object access, the original file access information is lost, making it impossible to perform statistics at the file level. Users need to be aware of hot files in their own usage scenarios in order to optimize their service performance.

[0088] Based on the above, in some optional embodiments, a hot file statistics mechanism is proposed, aiming to perform statistical analysis at the file level to help users better identify hot files in big data analysis scenarios, thereby optimizing service performance. Based on the above, after performing read and write operations on the target data block in the object storage system according to the object path corresponding to the target data block, the above method may further include: obtaining the file path of the target file from the access token, and adding the file path of the target file to the response result of the object access request; determining the number of accesses for a single file based on the file path in at least one response result.

[0089] In practical applications, for each object access request, the file path of the currently accessed file can be added to the response result. Over time, the number of object accesses increases. Statistical analysis can be performed on the file paths in the generated responses to determine the access count of each file. It's understandable that the file path, as a form of file identification information, can be used to determine the file's access count by counting the occurrences of the file path.

[0090] To better perform hot file statistics, optionally, determining the access count of a single file based on the file path in at least one response result includes: using a reverse proxy server to generate and save access logs for the target file based on the file path in the response result; using a log collection agent to periodically collect the saved access logs of each file and save them to the log service system; using a real-time computing engine to obtain the access logs of each file from the log service system, and parsing and aggregating them to obtain log statistics data at the granularity of a single file within a set time period. The log statistics data includes at least the access count of a single file. The log statistics data is then extracted, transformed, loaded into ETL processing, and the ETL processing results are stored in a table.

[0091] Specifically, when a reverse proxy server detects that the response to an object access request includes the file path of the target file, it confirms that the target file has been accessed. At this point, the reverse proxy server can generate an access log that includes the file path of the target file. Of course, the access log can also include more information related to the target file, such as file access time, file size, filename, etc., but it is not limited to these. See also Figure 3A log collection agent, used for log data acquisition, can periodically collect access logs from various saved files and save them to the log service system providing the log service. For example, the log collection agent may collect logs every 10 seconds, 1 minute, or 5 minutes. A real-time computing engine with real-time data processing capabilities directly consumes the log data from the log service system. For example, the real-time computing engine can directly read log data from the log service system by creating a log service source table. The read log data may include access logs for various files. The real-time computing engine parses (e.g., streaming parsing) and aggregates the access logs for each file to obtain log statistics at the individual file level within a set time period. The log statistics include at least the number of accesses for each individual file. The set time period may be, for example, 10 seconds, 1 minute, or 5 minutes. Optionally, the log statistics may also include hot file markers for individual files. These markers indicate whether an individual file is a hot file; for example, if a file's access count exceeds a set number of accesses, the file is a hot file; otherwise, it is not. The real-time computing engine performs ETL (Extract, Transform, Load) processing on log statistics and stores the ETL results in tables. Storing log statistics in a standardized tabular format facilitates subsequent retrieval and sorting of the log statistics.

[0092] It is worth noting that the hot file statistics mechanism can also help to create a clearer profile of user data access, make it easier for users to conduct data analysis, and help to analyze system pressure and manage the operation and maintenance of the user's own service system.

[0093] Hot file statistics mechanisms enable user-owned service systems to perceive system load and identify which files or data blocks are access hotspots, facilitating better load balancing. For example, hot files can be distributed across more nodes to alleviate read request pressure. Hot file statistics mechanisms also help user-owned service systems analyze performance load models, promoting better operation and maintenance. Performance load models are mathematical or statistical models that describe and predict the behavior of service systems under different load conditions. They help understand and optimize service system performance, ensuring efficient and stable operation.

[0094] To better understand the technical solution of this application, the following is combined with... Figure 4 This section introduces a specific scenario and implementation example. See [link / reference] Figure 4In a data lake, the object storage system can include an OSS Server and a storage layer, while the metadata management node can include an Ns Server and a database. Clients in a data lake interact with either the object storage system or the metadata management node via an SDK. For example, in a data retrieval scenario, see [link to relevant documentation]. Figure 4 The client sends a file read request via the SDK, see [link / reference]. Figure 4 As shown in ①, the client forwards the file read request to the Ns Server, which in turn requests to query the metadata of the file to be read. See also... Figure 4 As shown in ② and ③, the Ns Server retrieves the metadata of the file to be read from the underlying database. From the metadata returned by the database, the mapping relationship between the file path of the file to be read and the object path of the data block can be found. See also... Figure 4 As shown in section ④, the Ns Server generates a corresponding access token for each data block to be read and encrypts the access token. The access token can include multi-dimensional information such as the file path of the file to be read, the object path corresponding to the data block to be read, the access key, the expiration time of the access token, and the allowed access mode. See also Figure 4 As shown in Figure ⑤, NsServer returns an encrypted access token to the client via the SDK. See also... Figure 4 As shown in Figure 6, the client sends an object read request to the OSSServer via the SDK. The object read request includes the object path corresponding to the data block to be read and the encrypted access token; see also Figure 1 As shown in section ⑦, the OSS Server decrypts the encrypted access token to obtain the access token. See also... Figure 1 As shown in Figure ⑧, the OSS Server uses access tokens for security authentication. See also... Figure 1 As shown in diagrams ⑨ and ⑩, if security authentication passes, the OSSServer reads the data block to be read from the storage layer. See also... Figure 1 middle As shown, the OSS Server generates access logs including the file paths of the files to be read, which will be helpful for subsequent hot file statistics. See also... Figure 1 middle As shown, the OSS Server returns the read data blocks to the client through the SDK, thus completing the data reading process of the data lake.

[0095] Figure 5 This is a flowchart illustrating a data access method applied to a data lake, as provided in an embodiment of this application. The data lake includes a client, a metadata management node, and an object storage system. This method is applied to the metadata management node. (See also...) Figure 5 The method may include the following steps:

[0096] 501. Receive a file access request sent by the client. The file access request is used to request read and write operations on the target data block in the target file. The file access request is used to indicate the file name of the target file and the location information of the target data block in the target file.

[0097] 502. Based on the filename of the target file and the location information of the target data block, obtain the object path of the target data block in the object storage system.

[0098] 503. Generate an access token corresponding to the target data block, and encrypt the access token using the access key to obtain the encrypted access token.

[0099] 504. Return the object path and encrypted access token corresponding to the target data block to the client so that the client can send an object access request for the target data block to the object storage system. The object access request includes the encrypted access token and the URI address determined based on the object path corresponding to the target data block.

[0100] Optionally, the implementation method for obtaining the object path of the target data block in the object storage system based on the filename of the target file and the location information of the target data block is as follows: If the file access request is a file write request, the file path of the target file is determined based on the filename of the target file, and the object path of the target data block in the object storage system is determined. A mapping relationship is established between the file path of the target file and the object path of the target data block, and metadata of the target file is generated. The metadata of the target file includes the filename of the target file, the file path of the target file, the location information of the target data block, and the mapping relationship between the file path of the target file and the object path of the target data block. If the file access request is a file read request, the metadata of the target file is searched based on the filename of the target file and the location information of the target data block to obtain the object path of the target data block in the object storage system.

[0101] Optionally, an access token is generated based on the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode, including: obtaining the file path of the target file; and generating an access token based on the file path of the target file, the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode.

[0102] The detailed implementation methods and technical effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0103] Figure 6This is a flowchart illustrating a data access method applied to a data lake, as provided in an embodiment of this application. The data lake includes a client, a metadata management node, and an object storage system. The method is applied to the object storage system; see [link to relevant documentation]. Figure 6 The method may include the following steps:

[0104] 601. Receive an object access request for a target data block sent by the client. The object access request includes an encrypted access token and a URI address determined based on the object path corresponding to the target data block.

[0105] 602. Use the decryption key to decrypt the encrypted access token to obtain the access token.

[0106] 603. Perform security authentication on the object access request based on the URI address and access token in the object access request.

[0107] 604. If the security authentication is successful, then read and write operations will be performed on the target data block in the object storage system according to the object path corresponding to the target data block.

[0108] Optionally, the access token includes: the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode. Correspondingly, the implementation method for security authentication of the object access request based on the URI address in the object access request and the access token is as follows: Determine whether the URI address in the object access request is consistent with the object path corresponding to the target data block in the access token; determine whether the current time is less than the expiration time in the access token; determine whether the decryption key is consistent with the access key in the access token; determine whether the access mode of the object access request belongs to the allowed access mode in the access token; if the result of all the determination operations is yes, then the security authentication is successful; if the result of at least one determination operation is no, then the security authentication fails.

[0109] Optionally, after performing read and write operations on the target data block in the object storage system based on the object path corresponding to the target data block, the above method further includes: obtaining the file path of the target file from the access token, and adding the file path of the target file to the response result of the object access request; determining the number of accesses for a single file based on the file path in at least one response result.

[0110] Optionally, determining the access count of a single file based on the file path in at least one response result includes: using a reverse proxy server to generate and save access logs of the target file based on the file path of the target file in the response result; using a log collection agent to periodically collect the access logs of each saved file and save them to the log service system; using a real-time computing engine to obtain the access logs of each file from the log service system and perform parsing and aggregation to obtain log statistics data of a single file within a set time period, wherein the log statistics data includes at least the access count of a single file; extracting, transforming, and loading the log statistics data into ETL processing; and storing the ETL processing results in a table.

[0111] The detailed implementation methods and technical effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0112] Figure 7 This is a flowchart illustrating a data access method applied to a data lake, as provided in an embodiment of this application. The data lake includes a client, a metadata management node, and an object storage system. This method is applied to the client; see [link to relevant documentation]. Figure 7 The method may include the following steps:

[0113] 701. Send a file access request to the metadata management node. The file access request is used to request read and write operations on the target data block in the target file. The file access request is used to indicate the file name of the target file and the location information of the target data block in the target file.

[0114] 702. Receive the object path and encrypted access token corresponding to the target data block returned by the metadata management node.

[0115] 703. Send an object access request to the object storage system for the target data block. The object access request includes an encrypted access token and a URI address determined based on the object path corresponding to the target data block.

[0116] The detailed implementation methods and technical effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0117] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 701 to 703 can be device A; or the execution subject of steps 701 and 702 can be device A, and the execution subject of step 703 can be device B; and so on.

[0118] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 701, 702, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0119] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device includes: a memory 81 and a processor 82;

[0120] Memory 81 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0121] Processor 82, coupled to memory 81, is used to execute computer programs in memory 81 for: performing steps in a data access method applied to the data lake.

[0122] Optional, such as Figure 8 As shown, the electronic device also includes other components such as a communication component 83, a display 84, a power supply component 85, and an audio component 86. Figure 8 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 8 The components shown. Additionally... Figure 8 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a desktop computer, laptop computer, or smartphone, it may include... Figure 8 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 8 The component within the dashed box.

[0123] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0124] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G (2nd Generation), 3G (3rd Generation), 4G (4th Generation) / LTE (long Term Evolution), 5G (5th Generation), or combinations thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0125] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0126] The aforementioned power supply component provides power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides. The aforementioned audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device in which the audio component resides is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0127] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium may be volatile, non-volatile, or a combination thereof, and may be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium.

[0128] Accordingly, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor is able to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0129] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. The above are merely embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A data access method applied to a data lake, characterized in that, The data lake includes clients, metadata management nodes, and an object storage system. The method is applied to the metadata management node, and the method includes: Receive a file access request sent by the client. The file access request is used to request read and write operations on a target data block in a target file. The file access request is used to indicate the file name of the target file and the location information of the target data block in the target file. Based on the filename of the target file and the location information of the target data block, obtain the object path of the target data block in the object storage system; Generate an access token corresponding to the target data block, and encrypt the access token using the access key to obtain an encrypted access token; The object path corresponding to the target data block and the encrypted access token are returned to the client, so that the client sends an object access request for the target data block to the object storage system. The object access request includes the encrypted access token and a URI address determined based on the object path corresponding to the target data block.

2. The method according to claim 1, characterized in that, Based on the filename of the target file and the location information of the target data block, obtain the object path of the target data block in the object storage system, including: If the file access request is a file write request, then the file path of the target file is determined based on the file name of the target file, and the object path of the target data block in the object storage system is determined. A mapping relationship between the file path of the target file and the object path of the target data block is established, and the metadata of the target file is generated. The metadata of the target file includes the file name of the target file, the file path of the target file, the location information of the target data block, and the mapping relationship between the file path of the target file and the object path of the target data block. If the file access request is a file read request, the metadata of the target file is searched based on the filename of the target file and the location information of the target data block to obtain the object path of the target data block in the object storage system.

3. The method according to any one of claims 1 or 2, characterized in that, Generating the access token corresponding to the target data block includes: The access token is generated based on the object path, access key, expiration time of the access token, and allowed access mode corresponding to the target data block.

4. The method according to claim 3, characterized in that, The access token is generated based on the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode, including: Obtain the file path of the target file; The access token is generated based on the file path of the target file, the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode.

5. A data access method applied to a data lake, characterized in that, The data lake includes clients, metadata management nodes, and an object storage system. The method is applied to the object storage system and includes: Receive an object access request for a target data block sent by a client, the object access request including an encrypted access token and a URI address determined based on the object path corresponding to the target data block; The encrypted access token is decrypted using the decryption key to obtain the access token. The object access request is securely authenticated based on the URI address in the object access request and the access token. If the security authentication is successful, then read and write operations are performed on the target data block in the object storage system according to the object path corresponding to the target data block.

6. The method according to claim 5, characterized in that, The access token includes: the object path corresponding to the target data block, the access key, the expiration time of the access token, and the allowed access mode; Accordingly, the object access request is securely authenticated based on the URI address in the object access request and the access token, including: Determine whether the URI address in the object access request matches the object path corresponding to the target data block in the access token; Determine whether the current time is less than the expiration time in the access token; Determine whether the decryption key matches the access key in the access token; Determine whether the access mode of the object access request belongs to the allowed access mode in the access token; If all judgment operations result in "yes", the security authentication passes; if at least one judgment operation results in "no", the security authentication fails.

7. The method according to claim 5, characterized in that, After performing read and write operations on the target data block in the object storage system based on the object path corresponding to the target data block, the method further includes: Obtain the file path of the target file from the access token, and add the file path of the target file to the response result for the object access request; The number of times a single file is accessed is determined based on the file path in at least one response result.

8. The method according to claim 7, characterized in that, Determining the number of accesses to a single file based on the file path in at least one response result includes: The reverse proxy server generates and saves access logs for the target file based on the file path of the target file in the response result; and the log collection agent periodically collects the access logs of each saved file and saves them to the log service system. The real-time computing engine is used to obtain access logs of each file from the log service system, and then parses and aggregates them to obtain log statistics of a single file within a set time period. The log statistics include at least the number of accesses of a single file. The log statistics are then extracted, transformed, loaded into ETL processing, and the ETL processing results are stored in a table.

9. A data access method applied to a data lake, characterized in that, The data lake includes a client, a metadata management node, and an object storage system. The method is applied to the client and includes: Send a file access request to the metadata management node. The file access request is used to request read and write operations on the target data block in the target file. The file access request is used to indicate the file name of the target file and the location information of the target data block in the target file. Receive the object path and encrypted access token corresponding to the target data block returned by the metadata management node; Send an object access request for the target data block to the object storage system. The object access request includes the encrypted access token and a URI address determined based on the object path corresponding to the target data block.

10. A data lake, characterized in that, include: Client, metadata management node, and object storage system; The client is used to send a file access request to the metadata management node. The file access request is used to request read and write operations on a target data block in a target file. The file access request is used to indicate the file name of the target file and the location information of the target data block in the target file. The metadata management node is used to respond to a received file access request and obtain the object path of the target data block in the object storage system based on the file name of the target file and the location information of the target data block in the file access request. Generate an access token corresponding to the target data block, and encrypt the access token using the access key to obtain an encrypted access token; The object path corresponding to the target data block and the encrypted access token are returned to the client. The client is also configured to send an object access request for the target data block to the object storage system, the object access request including the encrypted access token and a URI address determined based on the object path corresponding to the target data block; The object storage system is configured to respond to a received object access request by decrypting the encrypted access token using a decryption key to obtain an access token. The object access request is securely authenticated based on the URI address in the object access request and the access token. If the security authentication is successful, then read and write operations are performed on the target data block in the object storage system according to the object path corresponding to the target data block.

11. An electronic device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program to perform the steps of the method according to any one of claims 1-4, 5-8, or 9.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-4, 5-8, or 9.

13. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method described in any one of claims 1-4, 5-8, or 9.

Images