Microsoft Technology Licensing, LLC

Honeywell International Inc.

Pankaj Sharma

Dharma Kiritkumar Shukla

Karthik Raman

Momin Mahmoud Al-Ghosien

Shireesh Kumar Thota

Madhan Gajendran

Ankur Savailal Shah

Atul Katiyar

Ji Huang

Bhalakumaaran Erode Ranganathan

Mikhail Mikhailovich Koltachev

Hari Sudan Sundar

Sujit Vattathil Kuruvilla

Shreshth Singhal

Liang Li

Ovidiu Constantin Platon

Samer Boshra

Rajeev Sudhakar Bhopi

Krishnan Sundaram

Subramanyam Pattipaka

Digvijaysinh Govindbhai Makwana

Ramachandran Ramjee

Muthian Sivathanu

Arsalan Ahmad

Rimma V Nehme

Nipun Kwatra

Adrian Ilcu Predescu

Aravind Ramachandran Krishna

Karan Vishwanath Popali

Padma Priya Aradhyula Bhavani

Brandon Chong

Larry James Miller

Yu Shrike Zhang

Rakesh Khanduja

Manish Kumar Shukla

Vaibhav Sharma

Hemant Kumar

Srinidhi Viswanatha

Jayanta Mondal

Oliver Drew Leonard Towers

Siddhesh Dilip Vethe

Jason Bialek

Vinod Sridharan

Kiran Kumar Kolli

Krishna Pradeep Reddy Tamma

Orestis Kostakis

Grigoriy A Orlov

Junyan Guo

Venkata Sivaramakrishna Ramadugu

Harini Chintapally

Bhavya Malik

Rama Krishnan Raghupathy

Lalitha Manjapara Viswanathan

Artavazd Ginosian

Swarnim Vyas

Denis Rystsov

Ailidani Ailijiang

Mohammad Derakhshani

Andrew Wise

Ashwini Singh

Vivek Ravindran

Balachandar Perumalswamy

Emily Lawton

Rimma Vladimirovna Nehme

The disclosure herein describes scheduling execution of artificial intelligence (AI) workloads in a cloud infrastructure platform. A global scheduler receives AI workloads associated with resource ticket values. The scheduler distributes the AI workloads to nodes based on balancing resource ticket values. Local schedulers of the nodes schedule AI workloads on resources based on the resource ticket values of the AI workloads. Based on scheduling the AI workloads, coordinator services of the local schedulers execute the distributed AI workloads on the infrastructure resources of the nodes. The disclosure further describes scheduling AI workloads based on priority tiers. A scheduler receives AI workloads, and each AI workload is associated with a priority tier indicative of a preemption priority while being executed. The AI workloads are scheduled for execution on a distributed set of nodes based on the priority tiers and then execute based on the scheduling.

Scheduler for planet-scale computing system

The disclosure herein describes platform-level checkpointing for deep learning (DL) jobs. The checkpointing is performed through capturing two kinds of state data: (i) GPU state (device state), and (ii) CPU state (host state). The GPU state includes GPU data (e.g., model parameters, optimizer state, etc.) that is located in the GPU and GPU context (e.g., the default stream in GPU, various handles created by the libraries such as DNN, Blas, etc.). Only a fraction of the GPU memory is copied because the checkpointing is done in a domain-aware manner. The 'active' memory contains useful data like model parameters. To be able to capture the useful data, memory management is controlled to identify which parts of the memory are active. Also, to restore the destination GPU to the same context/state, a mechanism is used to capture such state-changing events on an original GPU and replayed on a destination GPU.

Transparent pre-emption and migration for planet-scale computer

Data is collected from a network graph, wherein the collected data is useful for training a machine learning model on a query domain. A domain-specific template corresponding to the query domain is received, the domain-specific template defining one or more classifiers to guide collection of content relevant to the query domain from the network graph. A collection starting point is analyzed based on the one or more classifiers of the domain-specific template to identify one or more relevant instances of the content. The one or more identified relevant instances of the content are added to a contextual protocol package. Each identified relevant instance of the content is analyzed based on the one or more classifiers of the domain-specific template to identify one or more additional relevant instances of the content. The one or more identified additional relevant instances of the content are added to the contextual protocol package.

Guided source collection for a machine learning model

A server set for a data set may designate a subset of 'master' servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Merging conflict resolution for multi-master distributed databases

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Multi-master architectures for distributed databases

Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Conflict resolution for multi-master distributed databases

Methods, systems, apparatuses, and computer program products are provided for controlling access to a database. A data processing application may receive, from a user, a request that includes a procedural language code block to access data elements stored in a distributed database. A procedural language code block analyzer may obtain an access control policy that indicates permissions to access the data elements. A control system may determine, based on the access control policy, that access to a restricted portion of the data elements is denied. A reconstruction system may generate a reconstructed code block that allows the user to access data elements that are not restricted, such as by modifying the request to remove the portion that seeks access to the restricted data elements. The reconstruction system may then provide the modified request to the distributed database to receive the data elements to which the user is permitted to access.

Fine grained access control on procedural language for databases based on accessed resources

Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result. The transaction may also be applied over collections of replica sets using a second-level quorum to achieve nested consensus.

Resource-governed protocol and runtime for distributed databases with consistency models

Partitions are enabled to be merged in storage device of distributed database systems. A request to merge a plurality of source partitions into a merged partition is received. Each source partition stores a plurality of data items having corresponding source global identifiers and corresponding source local identifiers. The data items, with corresponding metadata, are appended from the source partitions to an intermediate storage structure in an order defined by the source local identifiers. Target global identifiers and target local identifiers are generated for each of the data items in the intermediate storage structure. The copied data items are flushed from the intermediate storage structure to the merged partition in an order defined by the target global identifiers. The source partitions and intermediate storage structure may then be purged of data, removed, and/or reused for further storage needs.

Distributed database systems partition merge

Systems and methods for displaying and controlling a remotely executed application on a display of a vehicle are disclosed. A method may include: receiving, by one or more processors, one or more video signals from one or more video sources onboard the vehicle; receiving, by the one or more processors, at a client module, a video signal including an image or display of the application executing on a remote server through a network; combining, by the one or more processors, via a video router, the received one or more video signals from the one or more video sources onboard the vehicle and the video signal including the image or display of the application executing on the remote server; and selectively displaying, by the one or more processors, on a display of the vehicle, the video signal including the image or display of the application executing on the remote server.

Systems and methods for displaying and controlling a remotely executed application on a display of a vehicle

Data sets such as databases are often distributed over a number of servers, where each server stores a subset of records and an index that enables the server to locate the records in response to queries. However, tight coupling of indexing and storage may limit load-balancing, fault recovery, and distribution. Instead, the set of servers may be partitioned into a set of storage servers that store the records and a set of index servers of the index over the records. In a set that is decoupled in this manner, load-balancing may involve provisioning and locating index servers independently of the provisioning and locating of the storage servers in view of the particular sensitivities and tolerances of various applications. Additionally, the index servers may also utilize a data layout that is selected and adapted independent of the data layout of the storage servers and/or the schema of the data stored thereby.

Schema-agnostic indexing of distributed databases

Data services are often provided with consistency guarantees of either strong consistency models, comprising uniform wall-clock consistency, or eventual consistency models, where temporary logical inconsistency is guaranteed to be resolved only after full data propagation. However, the performance characteristics of contemporary services often require an intermediate consistency model, where some aspects of the service have specific consistency expectations and other aspects of the service are flexible, such as bounded staleness (e.g., a maximum delay in reaching consistency); session consistency (e.g., individual sessions remain logically consistent, but ordering may vary across sessions); and prefix consistency (e.g., each view during a session is logically consistent, but ordering may vary between session views). Service guarantees may involve a selection within a range of consistency models that includes one or more intermediate consistency levels, and server configurations may be selected and applied to fulfill the intermediate consistency level selected in the service level agreement.

Intermediate consistency levels for database configuration

Databases are often provided according to various organizational models (e.g., document-oriented storage, key/value stores, and relational database), and are accessed through various access models (e.g., SQL, XPath, and schemaless queries). As data is shared across sources and applications, the dependency of a data service upon a particular organizational and/or access models may become confining. Instead, data services may store data in a base representation format, such as an atom-record-sequence model. New data received in a native item format may be converted into the base representation format for storage, and converted into a requested format to fulfill data requests. Queries may be translated from a native query format into a base query format that is applicable to the base representation format of the data set, e.g., via translation into an query intermediate language (such as JavaScript) and compilation into opcodes that are executed by a virtual machine within the database engine.

Unified data organization for multi-model distributed databases

A data service may be distributed over a set of servers in order to provide a database with properties such as low latency, high availability, and support for various consistency levels. Presented herein is a particular architecture that promotes rapid provisioning to promote scalability and failover; adaptive load-balancing to accommodate fluctuations in demand; and resiliency in the event of various types of failure, such as network partitions or regional outages. For a service comprising a resource set, a container is provided that hosts a set of replicas of a partition, and that is assigned an allocation of computing capabilities of one or more servers. The resource set of the service may be distributed over the replicas of the container. Scalability is achieved by adding replicas to the container, and load-balancing may be provided by splitting, merging, or otherwise refactoring the partition to accommodate anticipated and unanticipated fluctuations in service demand.

Containerization for elastic and scalable databases

Workloads are often performed by a server set according to a service level agreement, and are often provisioned and load-balanced by dedicating selected computational resources (e.g., servers and bandwidth) for application to the workload. However, resource-based provisioning may not accurately reflect the computational resource expenditure of the workload, leading to overprovisioning or underprovisioning of servers for the workload. Instead, the workload may be evaluated according to a service unit as a measurement of a volume of computational resources consumed by a workload unit, including performance dimensions specified in the service level agreement. The service level agreement may indicate a service unit rate for the workload. The workload may therefore be allocated to a subset of servers in portions according to a service unit rate, where the sum of the service unit rates for the portions allocated to the servers satisfies the service unit rate specified in the service level agreement.

Data service provisioning, metering, and load-balancing via service units

Growing community of inventors

Kirkland, WA, United States of America

Pankaj Sharma