# US 12,762,020 B1 · Universal format for multiple storage layer compatibility > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,762,020 B1 - Document ID: US12762020B1 - Status: Granted - Kind: B1 - Application number: 19/185,127 - Filed: 2025-04-21 - Granted: 2026-10-13 - Earliest claimed: 2024-04-26 - Assignees: Databricks, Inc. - Applicants: Databricks, Inc. - Inventors: Zhaolei Liu; Frederick Ryan Johnson; Terry Kim; Hao Jiang; Mitchell Scott Sandre; Lukas Lanzelot Rupprecht - Web page: https://patentgrep.com/patent/US12762020B1 ## CPC - G06F 11/1448: {Management of the data involved in backup or backup restore} - G06F 16/27: Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) ## Abstract One of the key challenges that entities face when adopting data lakehouse for data storage is selecting a storage format for their data. However, choosing a single storage format to standardize is a difficult task, and entities often end up using different storage formats and different data processing services that may provide support for a particular storage format but not for the other. The disclosure addresses these challenges by recognizing the fact that different data storage formats are built on data files of the same type. The main differences are the metadata layer that stores metadata files describing the properties of these data files. The metadata for a second data storage format is automatically generated against a single copy of data files. As a result, entities can use the most suitable tool for each data workload and operate on a single data source, with interoperability across different storage ecosystems. ## Claims ### Claim 1 A computer-implemented method, comprising: identifying an opportunity to convert a first snapshot of a data table in a first data storage format to a second snapshot of the data table in a second data storage format, wherein the first snapshot of the data table is represented by a set of data files and is associated with one or more transactions written to one or more first metadata files; identifying a previous snapshot of the data table in the first data storage format that was converted to a respective snapshot in the second data storage format; retrieving, from a storage system, a subset of the one or more first metadata files that correspond to a subset of transactions for conversion to the second data storage format, wherein the subset of transactions includes transactions occurring from the previous snapshot of the data table to the first snapshot of the data table; generating the second snapshot of the data table in the second data storage format, comprising: using one or more library modules associated with the second data storage format to convert a sequence of actions representing the subset of transactions in the first data storage format to a sequence of equivalent actions in the second data storage format, and writing the sequence of equivalent actions to one or more second metadata files according to the second data storage format; and storing the one or more second metadata files to a file path of the storage system in conjunction with the data table. ### Claim 2 (depends on 1) The computer-implemented method of claim 1, wherein the sequence of actions include one or more actions to add new data files to the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the new data files were added to the data table and describing properties of the new data files. ### Claim 3 (depends on 1) The computer-implemented method of claim 1, wherein the sequence of actions include one or more actions to remove data files from the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the data files were removed from the data table. ### Claim 4 (depends on 1) The computer-implemented method of claim 1, further comprising: receiving, from a client, a request to perform a read operation on the data table based on the second data storage format; reading the one or more second metadata files to identify at least a subset of data files to read to satisfy the request from a second client device; and returning results of the read operation as a response to the request. ### Claim 5 (depends on 4) The computer-implemented method of claim 4, further comprising: configuring a catalogue interface and linking, in a database, the data table and the file path to the one or more second metadata files; and responsive to receiving the request for the data table, accessing the file path to read the one or more second metadata files. ### Claim 6 (depends on 1) The computer-implemented method of claim 1, wherein the one or more first metadata files include one or more checkpoint parquet files. ### Claim 7 A non-transitory computer readable storage medium comprising stored program code, the stored program code comprising instructions, the instructions when executed cause a processor system to: identify an opportunity to convert a first snapshot of a data table in a first data storage format to a second snapshot of the data table in a second data storage format, wherein the first snapshot of the data table is represented by a set of data files and is associated with one or more transactions written to one or more first metadata files; identify a previous snapshot of the data table in the first data storage format that was converted to a respective snapshot in the second data storage format; retrieve, from a storage system, a subset of the one or more first metadata files that correspond to a subset of transactions for conversion to the second data storage format, wherein the subset of transactions includes transactions occurring from the previous snapshot of the data table to the first snapshot of the data table; generate the second snapshot of the data table in the second data storage format, the instructions further causing the processor system to: use one or more library modules associated with the second data storage format to convert a sequence of actions representing the subset of transactions in the first data storage format to a sequence of equivalent actions in the second data storage format, and write the sequence of equivalent actions to one or more second metadata files according to the second data storage format; and store the one or more second metadata files to a file path of the storage system in conjunction with the data table. ### Claim 8 (depends on 7) The non-transitory computer readable storage medium of claim 7, wherein the sequence of actions include one or more actions to add new data files to the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the new data files were added to the data table and describing properties of the new data files. ### Claim 9 (depends on 7) The non-transitory computer readable storage medium of claim 7, wherein the sequence of actions include one or more actions to remove data files from the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the data files were removed from the data table. ### Claim 10 (depends on 7) The non-transitory computer readable storage medium of claim 7, the instructions further causing the processor system to: receive, from a client, a request to perform a read operation on the data table based on the second data storage format; read the one or more second metadata files to identify at least a subset of data files to read to satisfy the request from a second client device; and return results of the read operation as a response to the request. ### Claim 11 (depends on 10) The non-transitory computer readable storage medium of claim 10, the instructions further causing the processor system to: configure a catalogue interface and linking, in a database, the data table and the file path to the one or more second metadata files; and responsive to receiving the request for the data table, access the file path to read the one or more second metadata files. ### Claim 12 (depends on 7) The non-transitory computer readable storage medium of claim 7, wherein the one or more first metadata files include one or more checkpoint parquet files or one or e SON files. ### Claim 13 A computer system comprising: a processor system; and non-transitory computer readable storage medium comprising stored program code, the stored program code comprising instructions, the instructions when executed cause a processor system to: identify an opportunity to convert a first snapshot of a data table in a first data storage format to a second snapshot of the data table in a second data storage format, wherein the first snapshot of the data table is represented by a set of data files and is associated with one or more transactions written to one or more first metadata files; identify a previous snapshot of the data table in the first data storage format that was converted to a respective snapshot in the second data storage format; retrieve, from a storage system, a subset of the one or more first metadata files that correspond to a subset of transactions for conversion to the second data storage format, wherein the subset of transactions includes transactions occurring from the previous snapshot of the data table to the first snapshot of the data table; generate the second snapshot of the data table in the second data storage format, the instructions further causing the processor system to: use one or more library modules associated with the second data storage format to convert a sequence of actions representing the subset of transactions in the first data storage format to a sequence of equivalent actions in the second data storage format, and write the sequence of equivalent actions to one or more second metadata files according to the second data storage format; and store the one or more second metadata files to a file path of the storage system in conjunction with the data table. ### Claim 14 (depends on 13) The computer system of claim 13, wherein the sequence of actions include one or more actions to add new data files to the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the new data files were added to the data table and describing properties of the new data files. ### Claim 15 (depends on 13) The computer system of claim 13, wherein the sequence of actions include one or more actions to remove data files from the data table, and wherein the one or more second metadata files include one or more manifest files indicating that the data files were removed from the data table. ### Claim 16 (depends on 13) The computer system of claim 13, the instructions further causing the processor system to: receive, from a client, a request to perform a read operation on the data table based on the second data storage format; read the one or more second metadata files to identify at least a subset of data files to read to satisfy the request from a second client device; and return results of the read operation as a response to the request. ### Claim 17 (depends on 16) The computer system of claim 16, the instructions further causing the processor system to: configure a catalogue interface and linking, in a database, the data table and the file path to the one or more second metadata files; and responsive to receiving the request for the data table, access the file path to read the one or more second metadata files. ### Claim 18 (depends on 13) The computer system of claim 13, wherein the one or more first metadata files include one or more checkpoint parquet files.