BACKGROUND

[0001] Large data collection by data providers (e.g., telecom resource providers), such as call record data collection, is generally accomplished by storing compiled records (e.g. call records) large datasets. Individual records and their representative datasets are generally stored with little regard for their downstream use and the various schemas that would be useful in processing such data by the data providers and the downstream accessors of that data. To convert and store such datasets into useful information it is helpful to perform various data reformatting operations on the originally stored data. The process of reformatting, transferring and storing datasets often leads to errors that result in incomplete transfer of records or complete data transfer failure altogether.

[0002] It is with respect to this general technical environment that aspects of the present technology disclosed herein have been contemplated. Furthermore, although a general environment has been discussed, it should be understood that the examples described herein should not be limited to the general environment identified in the background.

SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Additional aspects, features, and/or advantages of examples will be set forth in part in the description which follows and, in part, will be apparent from the description or may be learned by practice of the disclosure.

[0004] Non-limiting examples of the present disclosure describe systems, methods and devices for transmitting data from a source data store, comprising: receiving a plurality of data chunks, the plurality of data chunks received in a first format; performing at least one upsert operation on each of the plurality of data chunks, the at least one upsert operation comprising converting the first format to a schema compatible with a destination data store; executing a transfer of the upserted data chunks to the destination data store; determining that at least one of the upserted data chunks has failed to transfer to the destination data store; storing the at least one failed data chunk in a failed chunk retry data store; re-performing the at least one upsert operation on the at least one failed data chunk; and re-executing a transfer of the at least one failed data chunk to the destination data store.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive examples are described with reference to the following figures:

[0006] FIG. 1 is a schematic diagram illustrating an example distributed computing environment for providing advanced retry mechanisms for transfer of large datasets.

[0007] FIG. 2 is a schematic diagram illustrating an exemplary failed data transfer retry mechanism utilizing a back-off retry scheme.

[0008] FIG. 3A and 3B illustrate an exemplary method 300A and 300B for implementing an advanced retry mechanism for transfer of large datasets from a source data store to a destination data store.

[0009] FIG. 4 illustrates a computing device for executing one or more aspects of the present disclosure.

[0010] FIG. 5 is a simplified block diagram of a computing device with which aspects of the present disclosure may be practiced.

[0011] FIG. 6 is a block diagram illustrating physical components (e.g., hardware) of a computing device 1000 with which aspects of the present disclosure may be practiced.

[0012] FIG. 7 is a schematic diagram illustrating an example distributed computing environment for providing an advanced retry mechanism for transfer of large datasets.

DETAILED DESCRIPTION

[0013] Various embodiments will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the appended claims.

[0014] The various embodiments and examples described above are provided by way of illustration only and should not be construed to limit the claims attached hereto. Those skilled in the art will readily recognize various modifications and changes that may be made without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the claims.

[0015] Generally, the present disclosure is directed to systems, methods and devices for transferring datasets stored in a first format in a source data store to a destination data store requiring a different format. The systems, methods and devices described herein may be utilized in the transfer of data, from a source data store, that is stored in non- structured, semi-structured and/or structured formats to a destination data store that requires the storage of data in a specified schema. According to a specific example, call records received from a telecommunication company, which are typically stored in a semi- structured format (i.e., data that does not conform with the formal structure of data models associated with relational databases or other forms of data tables, but nonetheless contains tags or other markers to separate semantic elements and enforce hierarchies of records and fields within the data), may be stored in a source data store and transferred to a destination data store after performing one or more format-modifying operations on the semi- structured data such that it meets a specified schema of the destination data store.

[0016] As used herein, the term "dataset" describes a finite collection of data records, "data record" describes a single line within a dataset, and "data chunk" describes a memory fragment of a dataset whose size is determined via one or more mechanisms as more fully described below. Aspects provide mechanisms for periodically determining whether datasets in a source data store should be extracted for transfer to a destination data store, splitting datasets stored in a source data store into data chunks, extracting the data chunks from the source data store, performing one or more upsert operations on each data chunk and transferring the upserted data chunks to a destination data source.

[0017] According to examples a dataset may comprise a large number of records. Such datasets may typically be gigabytes if not terabytes in size. According to an example, such datasets may be split into individual data chunks of a configurable finite set size. These individual chunks that are created are of fixed size and may comprise incomplete records. According to additional examples the size of a data chunk may be determined based on the computing resources available for a dataset transfer. For example, if computing resources are abundant, a higher number of resources for executing mapping operations may be capable of being run simultaneously than would otherwise be the case for a system that has strained or otherwise limited computing resources available for a dataset transfer.

[0018] A data chunk may fail to be successfully transferred to a destination data store for various reasons. As an example, one or more records included in a data chunk may fail to be properly upserted by a mapper or mapping engine during the transfer process to a destination data store due to network weather. As used herein, an upsert operation describes any operation involved in modifying the format of data stored in a source data store such that it may be successfully be transferred to a destination data store requiring a second data format. For example, an upsert operation as used herein may comprise insertion of a row, or on the basis of a row already existing, updating the existing row. According to the systems and methods described herein, an upsert is only applicable to the complete records present in a dataset. All incomplete records are ignored and flushed as a residue by one or more residue flushing engines. When individual mappers or mapping engines process these separate data chunks, the incomplete records are reconciled by a reducer task during processing/cooking. All data chunks that are identified as having an error while uperting are marked as "failed chunk." In performing the reducer task (e.g., when one or more records are incomplete), all residues are marked as failed and those failed records are treated as another failed data chunk in a failed chunk container.

[0019] Additional aspects of the present disclosure provide advanced retry mechanisms for data chunks that have failed to successfully transfer to a destination data store requiring a specific schema. Specifically, a parallel process is provided whereby successfully transferred data chunks are immediately accessible in the destination data store upon their successful transfer while the advanced retry mechanisms described herein operate simultaneously on failed data chunks. The advanced retry mechanisms include transferring failed data chunks to a failed chunk retry data store, periodically extracting failed data chunks from the failed chunk retry data store according to a back-off retry attempt threshold, re-performing one or more upsert operations on the extracted data chunks, and reattempting a transfer of the upserted data chunks to the destination data store. As such, lossless data transfer from a source data store to a destination data store may be accomplished even in the case of one or more data chunks failing to successfully transfer to the destination data store, while access is simultaneously provided during failed data chunk retry, to data chunks that were initially or subsequently successfully transferred to the destination data store.

[0020] Mechanisms for executing the chunking of datasets from a source data store, processing of those data chunks for transfer to a destination data store and retry of data chunks that fail to transfer to a destination data store may be implemented according to the following examples.

[0021] Example - Segment Creation and Instant Processing:

[0022] 1. Dataset XI is segmented into data chunks of xl 1, xl2, xl3 ... xN. These data chunks are segmented by memory-strictness (e.g., 1 MB even if the segmentation occurs in the middle of a record) as opposed to data strictness. [0023] 2. Create a notification for the creation of a batch job with n tasks.

[0024] 3. For each data chunk: (a) tag each data chunk with Task Id. xl 1 ... txN; (b) upload tagged data chunks to a persistent storage and create a notification once upload completes.

[0025] 4. Repeat step 3 above for 1... N data chunks.

[0026] 5. Repeat steps 1-4 for datasets X2 ... Xn.

[0027] Example - Master Batch Job :

[0028] 1. Receive job creation notification and initiate batch job -> X1J.

[0029] 2. Create empty task for txl 1 data chunk: (a) txl 1 wait for notification that xl 1 data chunk upload is completed; (b) once notification is received, start processing the data chunk; (c) residue records (not completed due to chunking) are moved to XI J-rxl 1 file in residue container; (d) all failed records are moved to XI J-fxl 1 file in failed container with metadata (e.g., metadata indicating RetryCount number, FileName,

FailedRecordsCount, etc.); (e) delete xl l data chunk.

[0030] 3. Repeat step 2 until xN data chunk has been successfully transferred.

[0031] 4. Create task txN+1 : (a) stitch all residues (XI J-rxl 1, XI J-rxl2, XI J-rxl3 ...

XI J-rxN from residue container; (b) process the data chunk; (c) move all failed records to

XlJ-fxN+1 file in failed container; (d) delete XI J-rxl 1, XlJ-rxl2, XlJ-rxl3 ... XlJ-rxN;

(e) if there are no failed records, mark XI as "SUCCESS" or as "PARTIAL SUCCESS" if there are one or more failed records.

[0032] Example - Retry Batch (Scheduled Independently):

[0033] Assuming: (a) XI produces failed data chunks XI J-fxl 1, XI J-fxl3, XI J-fxl5;

(b) X2 produces failed data chunks X2J-fx21, X2J-fx23; (c) Xn produces failed data chunks XnJ-fxnl :

[0034] 1. Scan failed container.

[0035] 2. Create task for XI J-fxl 1 (a) process the data chunk; (b)

FailedRecordsCount is saved as metadata of XI J-fxl 1 file; (c) retrieve retry count from metdata and update with RetiyCount+1.

[0036] 3. Repeat step 2 for XlJ-fxl3 ... XnJ-fxnl .

[0037] 4. Create task for post processing: (a) get all failed data chunks for XI; (b) If

Sum(FailedRecordsCount) = 0, delete all failed data chunks and mark XI file as

"SUCCESS"; (c) if RetryCount = Configurable MaxRetry, delete the data chunk; (d) repeat substep (a) for X2 ... Xn.

[0038] According to some aspects a data chunk that has failed to successfully transfer to a destination data store may be transferred back to the failed chunk retry data store and the process of retrying transfer of such repeatedly failed data chunks to the destination data store as described above may be repeated one or more times based on a linearly scaled, exponentially scaled, or non-scaled back-off attempt threshold.

[0039] If a linearly scaled back-off attempt threshold is utilized, retry of failed data chunks would occur at regular temporal intervals. That is, according to a linearly scaled back-off attempt threshold, a first retry would occur after X seconds, minutes, hours or days, and if the failed data chunk fails to transfer a second time a second retry would occur after X seconds, minutes, hours or days, and so on until either the failed data chunk is successfully transferred to a destination data store or a threshold number of retry transfer attempts has occurred. Upon reaching the threshold number of transfer attempts and still unsuccessfully being transferred to the destination data store the repeatedly failed data chunk may be sent to a permanently failed container such that no additional attempts to transfer the data chunk are be made. According to a more specific example, a first retry may occur five seconds after a data chunk fails to initially transfer successfully to a destination data store, if the failed data chunk fails to transfer during a first retry a second retry may occur five seconds after the data chunk fails to transfer successfully to the destination data store during the first retry, if the failed data chunk fails to transfer during the second retry a third retry may occur five seconds after the data chunk fails to transfer during the second retry, and so on until either the failed data chunk is successfully transferred to a destination data store or a threshold number of retry transfer attempts has occurred.

[0040] In the case of an exponentially scaled back-off attempt threshold being utilized, retry of failed data chunks would occur at exponentially scaled temporal intervals. That is, a first retry would occur after X seconds, minutes, hours or days and if the failed data chunk fails to transfer a second time a second retry would occur after Y seconds (Y being an exponential function of X), minutes, hours or days, and so on until either a failed data chunk is successfully transferred to a destination data store or a threshold number of retry transfer attempts has occurred. According to a more specific example, a first retry may occur 5 seconds after a data chunk fails to initially transfer successfully to a destination data store, if the failed data chunk fails to transfer during a first retry a second retry may occur 25 seconds after the data chunk fails to transfer successfully to the destination data store during the first retry, if the failed data chunk fails to transfer during a second retry a third retry may occur several minutes after the data chunk fails to transfer during the second retry, and so on until either the failed data chunk is successfully transferred to a destination data store or a threshold number of retry transfer attempts has occurred.

[0041] In the case of a non-scaled back-off attempt threshold being utilized, retry of failed data chunks would occur at various determined temporal intervals. That is, rather than retrying failed data chunks on linear or exponential temporal scales, transfer retries may be executed at non-scaled intervals as determined by one or more non-scaled interval engines. Such engines may provide non-scaled intervals for retrying failed data chunks based on computer learning to determine timespans between successive retries that are likely to be successful, determining that received data associated with a destination data store indicates that the destination data store is in one or more states which are indicative of the destination data store being able to accommodate transfer data or transfer data of a specific format, determining that received data associated with a destination data store indicates that a destination data store is in one or more states which are indicative of the destination data store being unable to accommodate transfer of data or transfer data of a specific format, etc. Furthermore non-scaled interval engines may determine random temporal criteria for retrying one or more data chunk for transfer to a destination data store.

[0042] According to examples a separate engine or set of engines (e.g., extraction engines, mapping engines, upsert engines, encryption and decryption engines) is assigned to each data chunk of a dataset that is to be transferred from a source data store to a destination data store. Thus, metadata may be associated with each data chunk indicating which specific engines were assigned to it during transfer. This metadata may indicate to an administrator of a dataset transfer that one or more of the engines in a data transfer system is likely responsible for transfer errors if metadata from multiple failed data chunks from multiple dataset transfer cycles indicate that they were handled by one or more of the same engines. Additionally, metadata may be associated with failed data chunks indicating a number of times that a transfer to a destination data store has been tried for a data chunk. Such metadata may be utilized in determining whether to perform a subsequent retry transfer attempt of a data chunk based on a back-off retry attempt threshold, and if the data chunk has not exceeded the back-off retry attempt threshold, the metadata may provide a mechanism for determining how long to wait to retry a transfer of the data chunk to the destination data store based on a linear or exponential temporal scale defined by the back-off retry attempt threshold. [0043] Data chunks and/or individual records included in a data chunk may be encrypted and decrypted in one or more cycles during the transfer of a data chunk from a source data store to a destination data store. For example, a data chunk may be encrypted or decrypted upon being extracted from a source data store, upon transfer of a data chunk to a destination data store, upon transfer of a failed data chunk to a failed chunk retry data store, upon extraction of a failed data chunk from a failed chunk retry data store, and upon transfer of a failed data chunk to a permanently failed container. According to other examples a data chunk and/or individual records included in a data chunk may be encrypted when at rest and in transit and the data chunk and/or individual records included in the data chunk may only be decrypted at a transfer boundary (e.g., at the boundary of the source data store, the boundary of the destination data store, the boundary of a failed chunk retry data store).

[0044] According to examples, during the transfer of a dataset to a destination data store, separate engines for performing encryption and decryption operations may be assigned to each of the data chunks comprising the dataset. Thus, unlike typical large data transfer methods that employ a single service for encrypting and decrypting a dataset, which can sometimes take days for large datasets and often leads to dropped records, assigning separate engines to each data chunk for encryption and decryption operations significantly increases the efficiency of a data transfer and decreases the amount of time needed to transfer datasets. Further, because a data chunk transfer failure due to one or more miswrite by an engine assigned to a data chunk only affects that data chunk, successfully transferred data chunks are immediately accessible at a destination data store while the failed data chunks can simultaneously be retried according to the aspects described herein.

[0045] FIG. 1 is a schematic diagram illustrating an example distributed computing environment 100 for providing advanced retry mechanisms for transfer of large datasets. Computing environment 100 includes source dataset context 102, destination dataset context 114, data chunk retry context 108 and network 120. Original dataset context 102 includes source data store 104 and one or more computing devices such as server computing device 106. Large datasets, such as audio and video call log files, may be stored in source data store 104. According to examples such large datasets may comprise multiple files stored in various formats. Server computing device 106 may perform various operations related to datasets stored in source data store 104 utilizing one or more modules and/or engines such as a trigger engine for periodically analyzing datasets 104 and splitting datasets (such as dataset S 1 and dataset S2) into data chunks, such as data chunks SlCl, S1C2, S1C3 and S2CN, S2C2, S2C3 and S2CN shown in source data store 104. Additional operations that may be performed by server computing device 106 include extracting data chunks from source data store 104 for transfer, encrypting and decrypting data chunks and/or individual files included in data chunks, determining format requirements of a destination data store such as destination data store 116, as well as performing one or more upsert operation on data chunks and their corresponding data records.

[0046] Upon extraction of one or more data chunks comprising a split dataset (e.g., data chunks S 1 C 1 , S 1 C2, S 1 C3 , S 1 CN, S2C 1 , S2C2, S2C3 and S2CN), server computing device 106 may assign a separate mapping engine to each of the extracted data chunks for performing one or more upsert operations for modifying the format of each of the extracted data chunks to a specific schema format supported by a destination data store such as destination data store 116. Upon performance of the upsert operations on each of the data chunks, a first attempt may be made to transfer each of data chunks, via network 120, to destination data store 116. According to this example one or more operations may be performed by one or more computing devices, such as server computing device 118, prior to and/or during transfer of data chunks to the destination data store 116. For example, server computing device 118 may encrypt or decrypt one or more data chunks being transferred to destination data store 116. Server computing device 118 may also inspect each data chunk being transferred to ensure that the format of files contained therein complies with a structured format supported by destination data store 116.

[0047] As shown in FIG. 1, a first attempt has been made to transfer each data chunk from dataset 1 (i.e., SlCl, S1C2, S1C3 and S1CN) and dataset 2 (i.e., S2C1, S2C2, S2C3 and S2CN) from source data store 104 to destination data store 116. Upon the first transfer attempt only data chunks SlCl, S1C2, S1C3, S1CN*, S2C1, S2C2, S2C3 and S2CN* were successfully transferred to destination data store 116. According to the systems and methods described herein the data chunks that failed to successfully transfer to destination data store 116 are transferred, via network 120, to a failed chunk retry data store such as failed chunk retry data store 110. Thus, in this example failed data S1C7, S2C33, S3C15 and SNCN** have been transferred and stored in failed chunk retry data store 110. According to an additional aspects, rather than transferring data chunks that failed to transfer to a failed chunk retry data store such as failed chunk retry data store 110, those data failed chunks may be marked as failed within a the source data store 104 and subsequent transfer retries of those failed data chunks to the destination data store 116 may be executed directly from source data store 104. One or more computing devices such as server computing device 112 may encrypt or decrypt one or more failed data chunks and/or individual files included in one or more failed data chunks.

[0048] According to examples, after failed data chunks from a split transfer dataset have been stored in failed chunk retry data store 110 (or alternatively failed data chunks have been marked as failed in source data store 104) one or more additional periodic attempts may be made to transfer the failed data chunks to destination data store 116. For example, one or more operations may be performed by server computing device on failed chunks S1C7, S2C33, S3C15 and SNCN** for a second transfer attempt. Such operations may include encrypting and/or decrypting failed data chunks, extracting failed data chunks from failed data chunk storage 110 (or alternatively failed data chunks in source data store 104 that have been marked as failed), and re-performing one or more upsert operations on failed data chunks for a second attempt at transferring failed data chunks to destination data store 116. According to examples, server computing device may assign separate engines to each failed data chunk for the operations described above. Server computing device 112 may also make a determination as to how many times a failed data chunk has failed to transfer to destination data store 116, and based on that determination and a backoff retry attempt threshold, how long to wait between retry attempts and/or whether to transfer a failed data chunk to a permanently failed container based on a determination that a failed data chunk has exceeded a back-off retry attempt threshold number (e.g., 1 attempt, 2 attempts, 3 attempts, 4 attempts, 5 attempts).

[0049] FIG. 2 is a schematic diagram 200 illustrating an exemplary failed data transfer retry mechanism utilizing a back-off retry scheme. Although the depicted data transfer retry mechanism shown in FIG. 2 depicts completion of a dataset transfer after three retry attempts, completion of a dataset transfer may be accomplished according to the aspects described herein by retrying one or more failed data chunks of a dataset, one, two, three, or N number of times. Further, a successful data transfer of a dataset may not require use of a data transfer retry mechanism as illustrated by FIG. 2 should a successful transfer of each data chunk of a dataset be accomplished successfully upon an initial data chunk transfer attempt of all data chunks from a source data store to a destination data store.

[0050] Schematic diagram 200 includes first data chunk retry context 202 having failed chunk retry data store 204 in which data chunks that failed to transfer to a destination data store, such as destination data store 208, during a first transfer attempt are stored. According to this example each of failed data chunks C3, C4, C5, D3, D4, E5 and E7 failed to transfer to destination data store 208 during an initial transfer attempt, while data chunks E6 and D5 (shown in destination data store 208 in bold) were successfully transferred during an initial data chunk transfer attempt from a source data store to destination data store 208. As such, in accordance with the systems and methods described herein, a first retry attempt to transfer each of failed data chunks C3, C4, C5, D3, D4, E5 and E7 to destination data store 208 is made. As illustrated in FIG. 2, data chunks having a "CN" designation such as data chunks C3, C4 and C5 have been divided from a first dataset, data chunks having a "DN" designation such as data chunks D3, D4 and D5 have been divided from a second dataset, and data chunks having an "EN" designation such as data chunks E5, E6 and E7 have been divided from a third dataset.

[0051] Prior to the first retry attempt one or more computing devices such as server computing device 206 may perform one or more operations on each of data chunks C3, C4, C5, D3, D4, E5 and E7 such as encryption and decryption operations, extraction operations and upsert operations. Server computing device 206 may assign a separate engine or module to each of failed data chunks C5, D3, D4, E5 and E7 in performing such operations. As shown in FIG. 2, only initially failed data chunks C4, D4 and E7 are successfully transferred to destination data store 208 during a first transfer retry attempt. Once successfully transferred to destination data store 208, those data chunks and the records included therein are immediately made accessible, while simultaneous retry attempts can be made on the remaining failed data chunks. Accordingly, each of failed data chunks C3, C5, D3 and E5 are transferred back to failed chunk retry data store 204 (referred to as failed chunk retry data store 212 during a second transfer retry attempt and failed chunk retry data store 220 during a third transfer retry attempt). Although reference is made to "failed chunk retry data store" with regard to FIG. 2, according to aspects of the disclosure failed data chunks may simply be marked as failed within the source data store and transfer of those failed data chunks to a destination data store may be retried therefrom.

[0052] Schematic diagram 200 includes second data chunk retry context 210 having failed chunk retry data store 212 in which data chunks that failed to transfer to a destination data store ,such as destination data stores 208, 216 and 216, during a first transfer attempt and a subsequent first retry transfer attempt, are stored. Thus, according to this example, each of failed data chunks C3, C5, D3 and E5 failed to transfer to destination data store 216 during an initial transfer attempt and a subsequent first retry attempt. As such, in accordance with the systems and methods described herein, a second retry attempt to transfer each of failed data chunks C3, C5, D3 and E5 to destination data store 216 is made.

[0053] Prior to the second retry attempt one or more computing devices such as server computing device 214 may perform one or more operations on each of data chunks C3, C5, D3 and E5 such as encryption and decryption operations, extraction operations and upsert operations. Server computing device 214 may assign a separate engine or module to each of failed data chunks C3, C5, D3 and E5 in performing such operations. As shown in FIG. 2, only failed data chunks C3, C5 and E5 are successfully transferred to destination data store 216 during a second transfer retry attempt. Once successfully transferred to destination data store 216, those data chunks and the records included therein are immediately made accessible, while simultaneous retry attempts can be made on the remaining failed data chunks. Accordingly, remaining failed data chunk D3 is transferred back to failed chunk retry data store 212 (referred to as failed chunk retry data store 220 during a third transfer retry attempt).

[0054] Schematic diagram 200 includes third data chunk retry context 218 having failed chunk retry data store 224 in which data chunks that failed to transfer to a destination data store, such as destination data store 208, 216 and 216, during a first transfer attempt and subsequent first and second retry transfer attempts, are stored. Thus, according to this example, failed data chunk D3 failed to transfer to destination data store 224 during an initial transfer attempt and subsequent first and second retry attempts. As such, in accordance with the systems and methods described herein, a third retry attempt to transfer failed data chunk D3 to destination data store 224 is made.

[0055] Prior to the third retry attempt one or more computing devices such as server computing device 222 may perform one or more operations on failed data chunk D3 such as encryption and decryption operations, extraction operations and upsert operations. As shown in FIG. 2, failed data chunk D3 is successfully transferred to destination data store 224 during a third transfer retry attempt. Once successfully transferred to elastic job store 224 successful transfer of each of data chunks C3, C4, C5, D3, D4, D5, E5, E6 and E7 has been accomplished.

[0056] FIG. 3A and FIG. 3B illustrate an exemplary method 300A and 300B for implementing an advanced retry mechanism for transfer of large datasets from a source data store that stores files in a first format to a destination data store that requires the storage of data in a specified schema. The method begins at a start operation and flow moves to operation 302 A where one or more datasets in a source data store are split into a plurality data chunks for transfer. From operation 302 A flow continues to operation 304 A where an individual extraction engine is assigned to each of the split data chunks (e.g., a different extraction engine is assigned to each of the data chunks split from the one or more datasets at operation 302 A) and the data chunks are extracted from the source data store for transfer.

[0057] From operation 304 A flow continues to operation 306 A where an individual encryption engine is assigned to each of the extracted data chunks and each of the data chunks are optionally encrypted for transfer by their respective assigned encryption engines. From operation 306A flow moves to operation 308A where a determination is made as to the structured schema requirements of a destination data store to which the extracted data chunks are to be transferred. Moving to operation 31 OA an individual mapping engine is assigned to each of the extracted data chunks and one or more upsert operations are performed on each data chunk by their respective assigned mapping engines for conforming their format to a schema supported by a destination data store to which they are to be transferred.

[0058] From operation 310A flow continues to operation 312A where a first attempt to transfer each of the upserted data chunks to a destination data store is made. Continuing from operation 312A to operation 314A a determination is made that at least one data chunk failed to transfer successfully to the destination data store. From operation 314A flow continues to FIG. 3B and operation 302B where each of the data chunks that initially failed to transfer successfully to the destination data store (which may be derived from separate datasets) are transferred to a failed chunk retry data store. Alternatively, the failed data chunks may be marked as failed within the source data store and retry of those failed chunks may be executed from the source data store rather than the retry execution being accomplished through a separate failed chunk retry data store. According to examples, each of the initially failed data chunks may be encrypted or decrypted by an individually assigned encryption or decryption engine prior to being transferred to a failed chunk retry data store.

[0059] From operation 302B flow continues to operation 304B where one or more retry modules may be implemented and each of the initially failed data chunks are extracted from a failed chunk retry data store. According to examples, each of the initially failed data chunks may be encrypted or decrypted by an individually assigned encryption or decryption engine prior to a retry transfer attempt.

[0060] Moving to operation 304B flow continues to operation 306B where an individual mapping engine is assigned to each of the initially failed data chunks and one or more upsert operations are performed on each initially failed data chunk by their respective assigned mapping engines for conforming their format to a schema supported by a destination data store to which they are to be transferred. Continuing to operation 308B a first retry attempt to transfer each of the initially failed data chunks to the destination data store is made.

[0061] From operation 308B flow continues to operation 310B where data chunks that are successfully transferred to the destination data store during the first retry attempt are integrated with any data chunks that were successfully transferred to the destination data store during the initial transfer attempt. Flow then continues to operation 312B where operations 302B-310B are repeated until either all of the data chunks have been successfully transferred to the transfer data store or a back-off retry threshold number of retry attempts is exceeded based on a designated retry strategy.

[0062] FIG. 4 and FIG. 5 illustrate computing device 400, for example, a mobile telephone, a smart phone, a tablet personal computer, a laptop computer, and the like, with which embodiments of the disclosure may be practiced. With reference to FIG. 4, an exemplary mobile computing device 400 for implementing the embodiments is illustrated. In a basic configuration, the mobile computing device 400 is a handheld computer having both input elements and output elements. The mobile computing device 400 typically includes a display 405 and one or more input buttons 410 that allow the user to enter information into the computing device 400. The display 405 of the mobile computing device 400 may also function as an input device (e.g., a touch screen display). If included, an optional side input element 415 allows further user input. The side input element 415 may be a rotary switch, a button, or any other type of manual input element.

[0063] In alternative embodiments, mobile computing device 400 may incorporate more or less input elements. For example, the display 405 may not be a touch screen in some embodiments. In yet another alternative embodiment, the mobile computing device 400 is a portable phone system, such as a cellular phone. The mobile computing device 400 may also include an optional keypad 435. Optional keypad 435 may be a physical keypad or a "soft" keypad generated on the touch screen display.

[0064] In various embodiments, the output elements include the display 405 for showing a graphical user interface (GUI), a visual indicator 420 (e.g., a light emitting diode) and/or an audio transducer 425 (e.g., a speaker). In some embodiments, the mobile computing device 400 incorporates a vibration transducer for providing the user with tactile feedback. In yet another embodiments, the mobile computing device 400 incorporates input and/or output ports, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., a HDMI port) for sending signals to or receiving signals from an external device. In embodiments, the word processing application may be displayed on the display 405.

[0065] FIG. 5 is a block diagram illustrating the architecture of one embodiment of a mobile computing device. That is, the mobile computing device 500 can incorporate a system (i.e., an architecture) 502 to implement some aspects of the disclosure. In one aspect the system 502 is implemented as a "smart phone" capable of running one or more applications (e.g., browser, e-mail, calendaring, contact managers, messaging clients, games, and media clients/players). In some aspects, the system 502 is integrated as a computing device, such as an integrated personal digital assistant (PDA) and a wireless phone.

[0066] One or more application programs 566 may be loaded into the memory 562 and run on or in association with the operating system 564. Examples of the application programs include phone dialer programs, e-mail programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, messaging programs, diagramming applications, and so forth. The system 502 also includes a non-volatile storage area 568 within the memory 562. The nonvolatile storage area 568 may be used to store persistent information that should not be lost if the system 502 is powered down. The application programs 566 may use and store information in the non-volatile storage area 568, such as e-mail or other messages used by an e-mail application, and the like.

[0067] A synchronization application (not shown) also resides on the system 502 and is programmed to interact with a corresponding synchronization application resident on a host computer to keep the information stored in the non-volatile storage area 568 synchronized with corresponding information stored in the host computer. As should be appreciated, other applications may be loaded into the memory 562 and run on the mobile computing device 500, including steps and methods for transmitting a semi -structured dataset to a destination data store having requiring a structured format.

[0068] The system 502 has a power supply 570, which may be implemented as one or more batteries. The power supply 570 might further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.

[0069] The system 502 may also include a radio 572 that performs the functions of transmitting and receiving radio frequency communications. The radio 572 facilitates wireless connectivity between the system 502 and the "outside world," via a

communications carrier or service provider. Transmissions to and from the radio 572 are conducted under control of the operating system 564. In other words, communications received by the radio 572 may be disseminated to the application programs 566 via the operating system 564, and vice versa. The radio 572 allows the system 502 to

communicate with other computing devices such as over a network. The radio 572 is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information deliver media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF infrared and other wireless media. The term computer readable media is used herein includes both storage media and communication media.

[0070] This embodiment of the system 502 provides notifications using the visual indicator 520 that can be used to provide visual notifications and/or an audio interface 574 producing audible notifications via the audio transducer 525. In the illustrated

embodiment, the visual indicator 520 is a light emitting diode (LED) and the audio transducer 525 is a speaker. These devices may be directly coupled to the power supply 570 so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor 560 and other components might shut down for conserving battery power. The LED may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. The audio interface 574 is used to provide audible signals to and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 525, the audio interface 574 may also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. In accordance with embodiments of the present invention, the microphone may also serve as an audio sensor to facilitate control of notifications, as will be described below. The system 502 may further include a video interface 576 that enables an operation of an on-board camera 530 to record still images, video stream, and the like.

[0071] A mobile computing device 500 implementing the system 502 may have additional features or functionality. For example, the mobile computing device 500 may also include additional data storage devices (removable and/or non-removable) such as, magnetic disks, optical disks, or tape. Such additional storage is illustrated in FIG. 5 by the non-volatile storage area 568. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.

[0072] Data/information generated or captured by the mobile computing device 500 and stored via the system 502 may be stored locally on the mobile computing device 500, as described above, or the data may be stored on any number of storage media that may be accessed by the device via the radio 572 or via a wired connection between the mobile computing device 500 and a separate computing device associated with the mobile computing device 500, for example, a server computer in a distributed computing network, such as the Internet. As should be appreciated such data/information may be accessed via the mobile computing device 500 via the radio 572 or via a distributed computing network. Similarly, such data/information may be readily transferred between computing devices for storage and use according to well-known data/information transfer and storage means, including electronic mail and collaborative data/information sharing systems.

[0073] One of skill in the art will appreciate that the scale of systems such as system 502 may vary and may include more or fewer components than those described in FIG. 5. In some examples, interfacing between components of the system 502 may occur remotely, for example where components of system 502 may be spread across one or more devices of a distributed network. In examples, one or more data stores/storages or other memory are associated with system 502. For example, a component of system 502 may have one or more data storages/mem ories/stores associated therewith. Data associated with a component of system 502 may be stored thereon as well as processing

operations/instructions executed by a component of system 502.

[0074] FIG. 6 is a block diagram illustrating physical components (e.g., hardware) of a computing device 600 with which aspects of the disclosure may be practiced. The computing device components described below may have computer executable

instructions for transmitting a dataset, including: receiving a plurality of data chunks, the plurality of data chunks received in a first format; performing at least one upsert operation on each of the plurality of data chunks, the at least one upsert operation comprising converting the first format to a schema compatible with a destination data store; executing a transfer of the upserted data chunks to the destination data store; determining that at least one of the upserted data chunks has failed to transfer to the destination data store; storing the at least one failed data chunk in a failed chunk retry data store; re-performing the at least one upsert operation on the at least one failed data chunk; and re-executing a transfer of the at least one failed data chunk to the destination data store, including computer executable instructions for data transfer application 620 that can be executed to employ the methods disclosed herein.

[0075] In a basic configuration, the computing device 600 may include at least one processing unit 602 and a system memory 604. Depending on the configuration and type of computing device, the system memory 604 may comprise, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories. The system memory 604 may include an operating system 605 and one or more program modules 606 suitable for data transfer application 620, such as one or more components in regards to FIG. 6 and, in particular, data chunk retry module 618 data extraction engine 611, data chunk encryption module 613, mapping module 615 and data chunk upsert engine 617.

[0076] The operating system 605, for example, may be suitable for controlling the operation of the computing device 600. Furthermore, aspects of the disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in FIG. 6 by those components within a dashed line 608. The computing device 600 may have additional features or functionality. For example, the computing device 600 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in FIG. 6 by a removable storage device 609 and a nonremovable storage device 610.

[0077] As stated above, a number of program modules and data files may be stored in the system memory 604. While executing on the processing unit 602, the program modules 606 (e.g., data transfer application 620) may perform processes including, but not limited to, the aspects, as described herein. Other program modules that may be used in accordance with aspects of the present disclosure. [0078] Furthermore, aspects of the disclosure may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. For example, aspects of the disclosure may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in FIG. 6 may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units and various application functionality all of which are integrated (or "burned") onto the chip substrate as a single integrated circuit. When operating via an SOC, the functionality, described herein, with respect to the capability of client to switch protocols may be operated via application-specific logic integrated with other components of the computing device 500 on the single integrated circuit (chip). Embodiments of the disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the disclosure may be practiced within a general purpose computer or in any other circuits or systems.

[0079] The computing device 600 may also have one or more input device(s) 612 such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or swipe input device, etc. The output device(s) 614 such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The computing device 600 may include one or more communication connections 616 allowing communications with other computing devices 650. Examples of suitable communication connections 616 include, but are not limited to, radio frequency (RF) transmitter, receiver, and/or transceiver circuitry; universal serial bus (USB), parallel, and/or serial ports.

[0080] The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, or program modules. The system memory 604, the removable storage device 609, and the non-removable storage device 610 are all computer storage media examples (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture which can be used to store information and which can be accessed by the computing device 600. Any such computer storage media may be part of the computing device 600. Computer storage media does not include a carrier wave or other propagated or modulated data signal.

[0081] Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more

characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0082] The different aspects described herein may be employed using software, hardware, or a combination of software and hardware to implement and perform the systems and methods disclosed herein. Although specific devices have been recited throughout the disclosure as performing specific functions, one of skill in the art will appreciate that these devices are provided for illustrative purposes, and other devices may be employed to perform the functionality disclosed herein without departing from the scope of the disclosure.

[0083] As stated above, a number of program modules and data files may be stored in the system memory 604. While executing on processing unit 602, program modules (e.g., applications, Input/Output (I/O) management, and other utilities) may perform processes including, but not limited to, one or more of the operational stages of the methods described herein.

[0084] FIG. 7 illustrates one example of the architecture of a system for transmitting one or more datasets from a source data store to a destination data store as described above. Data from a semi-structured dataset may be accessed, interacted with, or edited in association with programming modules 606 and storage/memory which may be stored in different communication channels or other storage types. For example, various documents may be stored using a directory service 722, a web portal 724, a mailbox service 726, an instant messaging store 728, or a social networking site 730, application 706, an IO manager, other utilities and storage systems may use any of these types of systems or the like for enabling data utilization, as described herein. A server 702 may provide a storage system for use by a client operating on a general computing device 704 and mobile computing devices 706 through network 715. By way of example, network 715 may comprise the Internet or any other type of local or wide area network, and client nodes may be implemented as a computing device embodied in a personal computer, a tablet computing device 706, and/or by a mobile computing device 708 (e.g., mobile processing device). Any of these examples of the computing devices described herein may obtain content from the store 716.

[0085] Reference has been made throughout this specification to "one example" or "an example," meaning that a particular described feature, structure, or characteristic is included in at least one example. Thus, usage of such phrases may refer to more than just one example. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples.

[0086] One skilled in the relevant art may recognize, however, that the examples may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to observe obscuring aspects of the examples.

[0087] While examples and applications have been illustrated and described, it is to be understood that the examples are not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems disclosed herein without departing from the scope of the claimed examples.