Patent Publication Number: US-10318882-B2

Title: Optimized training of linear machine learning models

Description:
BACKGROUND 
     Machine learning combines techniques from statistics and artificial intelligence to create algorithms that can learn from empirical data and generalize to solve problems in various domains such as natural language processing, financial fraud detection, terrorism threat level detection, human health diagnosis and the like. In recent years, more and more raw data that can potentially be utilized for machine learning models is being collected from a large variety of sources, such as sensors of various kinds, web server logs, social media services, financial transaction records, security cameras, and the like. 
     Traditionally, expertise in statistics and in artificial intelligence has been a prerequisite for developing and using machine learning models. For many business analysts and even for highly qualified subject matter experts, the difficulty of acquiring such expertise is sometimes too high a barrier to be able to take full advantage of the large amounts of data potentially available to make improved business predictions and decisions. Furthermore, many machine learning techniques can be computationally intensive, and in at least some cases it can be hard to predict exactly how much computing power may be required for various phases of the techniques. Given such unpredictability, it may not always be advisable or viable for business organizations to build out their own machine learning computational facilities. 
     The quality of the results obtained from machine learning algorithms may depend on how well the empirical data used for training the models captures key relationships among different variables represented in the data, and on how effectively and efficiently these relationships can be identified. Depending on the nature of the problem that is to be solved using machine learning, very large data sets may have to be analyzed in order to be able to make accurate predictions, especially predictions of relatively infrequent but significant events. For example, in financial fraud detection applications, where the number of fraudulent transactions is typically a very small fraction of the total number of transactions, identifying factors that can be used to label a transaction as fraudulent may potentially require analysis of millions of transaction records, each representing dozens or even hundreds of variables. Constraints on raw input data set size, cleansing or normalizing large numbers of potentially incomplete or error-containing records, and/or on the ability to extract representative subsets of the raw data also represent barriers that are not easy to overcome for many potential beneficiaries of machine learning techniques. For many machine learning problems, transformations may have to be applied on various input data variables before the data can be used effectively to train models. In some traditional machine learning environments, the mechanisms available to apply such transformations may be less than optimal—e.g., similar transformations may sometimes have to be applied one by one to many different variables of a data set, potentially requiring a lot of tedious and error-prone work. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  illustrates an example system environment in which various components of a machine learning service may be implemented, according to at least some embodiments. 
         FIG. 2  illustrates an example of a machine learning service implemented using a plurality of network-accessible services of a provider network, according to at least some embodiments. 
         FIG. 3  illustrates an example of the use of a plurality of availability containers and security containers of a provider network for a machine learning service, according to at least some embodiments. 
         FIG. 4  illustrates examples of a plurality of processing plans and corresponding resource sets that may be generated at a machine learning service, according to at least some embodiments. 
         FIG. 5  illustrates an example of asynchronous scheduling of jobs at a machine learning service, according to at least some embodiments. 
         FIG. 6  illustrates example artifacts that may be generated and stored using a machine learning service, according to at least some embodiments. 
         FIG. 7  illustrates an example of automated generation of statistics in response to a client request to instantiate a data source, according to at least some embodiments. 
         FIG. 8  illustrates several model usage modes that may be supported at a machine learning service, according to at least some embodiments. 
         FIGS. 9 a  and 9 b    are flow diagrams illustrating aspects of operations that may be performed at a machine learning service that supports asynchronous scheduling of machine learning jobs, according to at least some embodiments. 
         FIG. 10 a    is a flow diagram illustrating aspects of operations that may be performed at a machine learning service at which a set of idempotent programmatic interfaces are supported, according to at least some embodiments. 
         FIG. 10 b    is a flow diagram illustrating aspects of operations that may be performed at a machine learning service to collect and disseminate information about best practices related to different problem domains, according to at least some embodiments. 
         FIG. 11  illustrates examples interactions associated with the use of recipes for data transformations at a machine learning service, according to at least some embodiments. 
         FIG. 12  illustrates example sections of a recipe, according to at least some embodiments. 
         FIG. 13  illustrates an example grammar that may be used to define recipe syntax, according to at least some embodiments. 
         FIG. 14  illustrates an example of an abstract syntax tree that may be generated for a portion of a recipe, according to at least some embodiments. 
         FIG. 15  illustrates an example of a programmatic interface that may be used to search for domain-specific recipes available from a machine learning service, according to at least some embodiments. 
         FIG. 16  illustrates an example of a machine learning service that automatically explores a range of parameter settings for recipe transformations on behalf of a client, and selects acceptable or recommended parameter settings based on results of such explorations, according to at least some embodiments. 
         FIG. 17  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service that supports re-usable recipes for data set transformations, according to at least some embodiments. 
         FIG. 18  illustrates an example procedure for performing efficient in-memory filtering operations on a large input data set by a machine learning service, according to at least some embodiments. 
         FIG. 19  illustrates tradeoffs associated with varying the chunk size used for filtering operation sequences on machine learning data sets, according to at least some embodiments. 
         FIG. 20 a    illustrates an example sequence of chunk-level filtering operations, including a shuffle followed by a split, according to at least some embodiments. 
         FIG. 20 b    illustrates an example sequence of in-memory filtering operations that includes chunk-level filtering as well as intra-chunk filtering, according to at least some embodiments. 
         FIG. 21  illustrates examples of alternative approaches to in-memory sampling of a data set, according to at least some embodiments. 
         FIG. 22  illustrates examples of determining chunk boundaries based on the location of observation record boundaries, according to at least some embodiments. 
         FIG. 23  illustrates examples of jobs that may be scheduled at a machine learning service in response to a request for extraction of data records from any of a variety of data source types, according to at least some embodiments. 
         FIG. 24  illustrates examples constituent elements of a record retrieval request that may be submitted by a client using a programmatic interface of an I/O (input-output) library implemented by a machine learning service, according to at least some embodiments. 
         FIG. 25  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service that implements an I/O library for in-memory filtering operation sequences on large input data sets, according to at least some embodiments. 
         FIG. 26  illustrates an example of an iterative procedure that may be used to improve the quality of predictions made by a machine learning model, according to at least some embodiments. 
         FIG. 27  illustrates an example of data set splits that may be used for cross-validation of a machine learning model, according to at least some embodiments. 
         FIG. 28  illustrates examples of consistent chunk-level splits of input data sets for cross validation that may be performed using a sequence of pseudo-random numbers, according to at least some embodiments. 
         FIG. 29  illustrates an example of an inconsistent chunk-level split of an input data set that may occur as a result of inappropriately resetting a pseudo-random number generator, according to at least some embodiments. 
         FIG. 30  illustrates an example timeline of scheduling related pairs of training and evaluation jobs, according to at least some embodiments. 
         FIG. 31  illustrates an example of a system in which consistency metadata is generated at a machine learning service in response to a client request, according to at least some embodiments. 
         FIG. 32  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service in response to a request for training and evaluation iterations of a machine learning model, according to at least some embodiments. 
         FIG. 33  illustrates an example of a decision tree that may be generated for predictions at a machine learning service, according to at least some embodiments. 
         FIG. 34  illustrates an example of storing representations of decision tree nodes in a depth-first order at persistent storage devices during a tree-construction pass of a training phase for a machine learning model, according to at least some embodiments. 
         FIG. 35  illustrates an example of predictive utility distribution information that may be generated for the nodes of a decision tree, according to at least some embodiments. 
         FIG. 36  illustrates an example of pruning a decision tree based at least in part on a combination of a run-time memory footprint goal and cumulative predictive utility, according to at least some embodiments. 
         FIG. 37  illustrates an example of pruning a decision tree based at least in part on a prediction time variation goal, according to at least some embodiments. 
         FIG. 38  illustrates examples of a plurality of jobs that may be generated for training a model that uses an ensemble of decision trees at a machine learning service, according to at least some embodiments. 
         FIG. 39  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service to generate and prune decision trees stored to persistent storage in depth-first order, according to at least some embodiments. 
         FIG. 40  illustrates an example procedure for generating and using linear prediction models, according to at least some embodiments. 
         FIG. 41  illustrates an example scenario in which the memory capacity of a machine learning server that is used for training a model may become a constraint on parameter vector size, according to at least some embodiments. 
         FIG. 42  illustrates a technique in which a subset of features for which respective parameter values are stored in a parameter vector during training may be selected as pruning victims, according to at least some embodiments. 
         FIG. 43  illustrates a system in which observation records to be used for learning iterations of a linear model&#39;s training phase may be streamed to a machine learning service, according to at least some embodiments. 
         FIG. 44  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service at which, in response to a detection of a triggering condition, parameters corresponding to one or more features may be pruned from a parameter vector to reduce memory consumption during training, according to at least some embodiments. 
         FIG. 45  illustrates a single-pass technique that may be used to obtain quantile boundary estimates of absolute values of weights assigned to features, according to at least some embodiments. 
         FIG. 46  is a block diagram illustrating an example computing device that may be used in at least some embodiments. 
     
    
    
     While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to. 
     DETAILED DESCRIPTION 
     Various embodiments of methods and apparatus for a customizable, easy-to-use machine learning service (MLS) designed to support large numbers of users and a wide variety of algorithms and problem sizes are described. In one embodiment, a number of MLS programmatic interfaces (such as application programming interfaces (APIs)) may be defined by the service, which guide non-expert users to start using machine learning best practices relatively quickly, without the users having to expend a lot of time and effort on tuning models, or on learning advanced statistics or artificial intelligence techniques. The interfaces may, for example, allow non-experts to rely on default settings or parameters for various aspects of the procedures used for building, training and using machine learning models, where the defaults are derived from the accumulated experience of other practitioners addressing similar types of machine learning problems. At the same time, expert users may customize the parameters or settings they wish to use for various types of machine learning tasks, such as input record handling, feature processing, model building, execution and evaluation. In at least some embodiments, in addition to or instead of using pre-defined libraries implementing various types of machine learning tasks, MLS clients may be able to extend the built-in capabilities of the service, e.g., by registering their own customized functions with the service. Depending on the business needs or goals of the clients that implement such customized modules or functions, the modules may in some cases be shared with other users of the service, while in other cases the use of the customized modules may be restricted to their implementers/owners. 
     In some embodiments, a relatively straightforward recipe language may be supported, allowing MLS users to indicate various feature processing steps that they wish to have applied on data sets. Such recipes may be specified in text format, and then compiled into executable formats that can be re-used with different data sets on different resource sets as needed. In at least some embodiments, the MLS may be implemented at a provider network that comprises numerous data centers with hundreds of thousands of computing and storage devices distributed around the world, allowing machine learning problems with terabyte-scale or petabyte-scale data sets and correspondingly large compute requirements to be addressed in a relatively transparent fashion while still ensuring high levels of isolation and security for sensitive data. Pre-existing services of the provider network, such as storage services that support arbitrarily large data objects accessible via web service interfaces, database services, virtual computing services, parallel-computing services, high-performance computing services, load-balancing services, and the like may be used for various machine learning tasks in at least some embodiments. For MLS clients that have high availability and data durability requirements, machine learning data (e.g., raw input data, transformed/manipulated input data, intermediate results, or final results) and/or models may be replicated across different geographical locations or availability containers as described below. To meet an MLS client&#39;s data security needs, selected data sets, models or code implementing user-defined functions or third-party functions may be restricted to security containers defined by the provider network in some embodiments, in which for example the client&#39;s machine learning tasks are executed in an isolated, single-tenant fashion instead of the multi-tenant approach that may typically be used for some of the provider network&#39;s services. The term “MLS control plane” may be used herein to refer to a collection of hardware and/or software entities that are responsible for implementing various types of machine learning functionality on behalf of clients of the MLS, and for administrative tasks not necessarily visible to external MLS clients, such as ensuring that an adequate set of resources is provisioned to meet client demands, detecting and recovering from failures, generating bills, and so on. The term “MLS data plane” may refer to the pathways and resources used for the processing, transfer, and storage of the input data used for client-requested operations, as well as the processing, transfer and storage of output data produced as a result of client-requested operations. 
     According to some embodiments, a number of different types of entities related to machine learning tasks may be generated, modified, read, executed, and/or queried/searched via MLS programmatic interfaces. Supported entity types in one embodiment may include, among others, data sources (e.g., descriptors of locations or objects from which input records for machine learning can be obtained), sets of statistics generated by analyzing the input data, recipes (e.g., descriptors of feature processing transformations to be applied to input data for training models), processing plans (e.g., templates for executing various machine learning tasks), models (which may also be referred to as predictors), parameter sets to be used for recipes and/or models, model execution results such as predictions or evaluations, online access points for models that are to be used on streaming or real-time data, and/or aliases (e.g., pointers to model versions that have been “published” for use as described below). Instances of these entity types may be referred to as machine learning artifacts herein—for example, a specific recipe or a specific model may each be considered an artifact. Each of the entity types is discussed in further detail below. 
     The MLS programmatic interfaces may enable users to submit respective requests for several related tasks of a given machine learning workflow, such as tasks for extracting records from data sources, generating statistics on the records, feature processing, model training, prediction, and so on. A given invocation of a programmatic interface (such as an API) may correspond to a request for one or more operations or tasks on one or more instances of a supported type of entity. Some tasks (and the corresponding APIs) may involve multiple different entity types—e.g., an API requesting a creation of a data source may result in the generation of a data source entity instance as well as a statistics entity instance. Some of the tasks of a given workflow may be dependent on the results of other tasks. Depending on the amount of data, and/or on the nature of the processing to be performed, some tasks may take hours or even days to complete. In at least some embodiments, an asynchronous approach may be taken to scheduling the tasks, in which MLS clients can submit additional tasks that depend on the output of earlier-submitted tasks without waiting for the earlier-submitted tasks to complete. For example, a client may submit respective requests for tasks T 2  and T 3  before an earlier-submitted task T 1  completes, even though the execution of T 2  depends at least partly on the results of T 1 , and the execution of T 3  depends at least partly on the results of T 2 . In such embodiments, the MLS may take care of ensuring that a given task is scheduled for execution only when its dependencies (if any dependencies exist) have been met. 
     A queue or collection of job objects may be used for storing internal representations of requested tasks in some implementations. The term “task”, as used herein, refers to a set of logical operations corresponding to a given request from a client, while the term “job” refers to the internal representation of a task within the MLS. In some embodiments, a given job object may represent the operations to be performed as a result of a client&#39;s invocation of a particular programmatic interface, as well as dependencies on other jobs. The MLS may be responsible for ensuring that the dependencies of a given job have been met before the corresponding operations are initiated. The MLS may also be responsible in such embodiments for generating a processing plan for each job, identifying the appropriate set of resources (e.g., CPUs/cores, storage or memory) for the plan, scheduling the execution of the plan, gathering results, providing/saving the results in an appropriate destination, and at least in some cases for providing status updates or responses to the requesting clients. The MLS may also be responsible in some embodiments for ensuring that the execution of one client&#39;s jobs do not affect or interfere with the execution of other clients&#39; jobs. In some embodiments, partial dependencies among tasks may be supported—e.g., in a sequence of tasks (T 1 , T 2 , T 3 ), T 2  may depend on partial completion of T 1 , and T 2  may therefore be scheduled before T 1  completes. For example, T 1  may comprise two phases or passes P 1  and P 2  of statistics calculations, and T 2  may be able to proceed as soon as phase P 1  is completed, without waiting for phase P 2  to complete. Partial results of T 1  (e.g., at least some statistics computed during phase P 1 ) may be provided to the requesting client as soon as they become available in some cases, instead of waiting for the entire task to be completed. A single shared queue that includes jobs corresponding to requests from a plurality of clients of the MLS may be used in some implementations, while in other implementations respective queues may be used for different clients. In some implementations, lists or other data structures that can be used to model object collections may be used as containers of to-be-scheduled jobs instead of or in addition to queues. In some embodiments, a single API request from a client may lead to the generation of several different job objects by the MLS. In at least one embodiment, not all client API requests may be implemented using jobs—e.g., a relatively short or lightweight task may be performed synchronously with respect to the corresponding request, without incurring the overhead of job creation and asynchronous job scheduling. 
     The APIs implemented by the MLS may in some embodiments allow clients to submit requests to create, query the attributes of, read, update/modify, search, or delete an instance of at least some of the various entity types supported. For example, for the entity type “DataSource”, respective APIs similar to “createDataSource”, “describeDataSource” (to obtain the values of attributes of the data source), “updateDataSource”, “searchForDataSource”, and “deleteDataSource” may be supported by the MLS. A similar set of APIs may be supported for recipes, models, and so on. Some entity types may also have APIs for executing or running the entities, such as “executeModel” or “executeRecipe” in various embodiments. The APIs may be designed to be largely easy to learn and self-documenting (e.g., such that the correct way to use a given API is obvious to non-experts), with an emphasis on making it simple to perform the most common tasks without making it too hard to perform more complex tasks. In at least some embodiments multiple versions of the APIs may be supported: e.g., one version for a wire protocol (at the application level of a networking stack), another version as a Java™ library or SDK (software development kit), another version as a Python library, and so on. API requests may be submitted by clients using HTTP (Hypertext Transfer Protocol), HTTPS (secure HTTP), Javascript, XML, or the like in various implementations. 
     In some embodiments, some machine learning models may be created and trained, e.g., by a group of model developers or data scientists using the MLS APIs, and then published for use by another community of users. In order to facilitate publishing of models for use by a wider audience than just the creators of the model, while preventing potentially unsuitable modifications to the models by unskilled members of the wider audience, the “alias” entity type may be supported in such embodiments. In one embodiment, an alias may comprise an immutable name (e.g., “SentimentAnalysisModell”) and a pointer to a model that has already been created and stored in an MLS artifact repository (e.g., “samModel-23adf-2013-12-13-08-06-01”, an internal identifier generated for the model by the MLS). Different sets of permissions on aliases may be granted to model developers than are granted to the users to whom the aliases are being made available for execution. For example, in one implementation, members of a business analyst group may be allowed to run the model using its alias name, but may not be allowed to change the pointer, while model developers may be allowed to modify the pointer and/or modify the underlying model. For the business analysts, the machine learning model exposed via the alias may represent a “black box” tool, already validated by experts, which is expected to provide useful predictions for various input data sets. The business analysts may not be particularly concerned about the internal working of such a model. The model developers may continue to experiment with various algorithms, parameters and/or input data sets to obtain improved versions of the underlying model, and may be able to change the pointer to point to an enhanced version to improve the quality of predictions obtained by the business analysts. In at least some embodiments, to isolate alias users from changes to the underlying models, the MLS may guarantee that (a) an alias can only point to a model that has been successfully trained and (b) when an alias pointer is changed, both the original model and the new model (i.e., the respective models being pointed to by the old pointer and the new pointer) consume the same type of input and provide the same type of prediction (e.g., binary classification, multi-class classification or regression). In some implementations, a given model may itself be designated as un-modifiable if an alias is created for it—e.g., the model referred to by the pointer “samModel-23adf-2013-12-13-08-06-01” may no longer be modified even by its developers after the alias is created in such an implementation. Such clean separation of roles and capabilities with respect to model development and use may allow larger audiences within a business organization to benefit from machine learning models than simply those skilled enough to develop the models. 
     A number of choices may be available with respect to the manner in which the operations corresponding to a given job are mapped to MLS servers. For example, it may be possible to partition the work required for a given job among many different servers to achieve better performance. As part of developing the processing plan for a job, the MLS may select a workload distribution strategy for the job in some embodiments. The parameters determined for workload distribution in various embodiments may differ based on the nature of the job. Such factors may include, for example, (a) determining a number of passes of processing, (b) determining a parallelization level (e.g., the number of “mappers” and “reducers” in the case of a job that is to be implemented using the Map-Reduce technique), (c) determining a convergence criterion to be used to terminate the job, (d) determining a target durability level for intermediate data produced during the job, or (e) determining a resource capacity limit for the job (e.g., a maximum number of servers that can be assigned to the job based on the number of servers available in MLS server pools, or on the client&#39;s budget limit). After the workload strategy is selected, the actual set of resources to be used may be identified in accordance with the strategy, and the job&#39;s operations may be scheduled on the identified resources. In some embodiments, a pool of compute servers and/or storage servers may be pre-configured for the MLS, and the resources for a given job may be selected from such a pool. In other embodiments, the resources may be selected from a pool assigned to the client on whose behalf the job is to be executed—e.g., the client may acquire resources from a computing service of the provider network prior to submitting API requests, and may provide an indication of the acquired resources to the MLS for job scheduling. If client-provided code (e.g., code that has not necessarily been thoroughly tested by the MLS, and/or is not included in the MLS&#39;s libraries) is being used for a given job, in some embodiments the client may be required to acquire the resources to be used for the job, so that any side effects of running the client-provided code may be restricted to the client&#39;s own resources instead of potentially affecting other clients. 
     Example System Environments 
       FIG. 1  illustrates an example system environment in which various components of a machine learning service (MLS) may be implemented, according to at least some embodiments. In system  100 , the MLS may implement a set of programmatic interfaces  161  (e.g., APIs, command-line tools, web pages, or standalone GUIs) that can be used by clients  164  (e.g., hardware or software entities owned by or assigned to customers of the MLS) to submit requests  111  for a variety of machine learning tasks or operations. The administrative or control plane portion of the MLS may include MLS request handler  180 , which accepts the client requests  111  and inserts corresponding job objects into MLS job queue  142 , as indicated by arrow  112 . In general, the control plane of the MLS may comprise a plurality of components (including the request handler, workload distribution strategy selectors, one or more job schedulers, metrics collectors, and modules that act as interfaces with other services) which may also be referred to collectively as the MLS manager. The data plane of the MLS may include, for example, at least a subset of the servers of pool(s)  185 , storage devices that are used to store input data sets, intermediate results or final results (some of which may be part of the MLS artifact repository), and the network pathways used for transferring client input data and results. 
     As mentioned earlier, each job object may indicate one or more operations that are to be performed as a result of the invocation of a programmatic interface  161 , and the scheduling of a given job may in some cases depend upon the successful completion of at least a subset of the operations of an earlier-generated job. In at least some implementations, job queue  142  may be managed as a first-in-first-out (FIFO) queue, with the further constraint that the dependency requirements of a given job must have been met in order for that job to be removed from the queue. In some embodiments, jobs created on behalf of several different clients may be placed in a single queue, while in other embodiments multiple queues may be maintained (e.g., one queue in each data center of the provider network being used, or one queue per MLS customer). Asynchronously with respect to the submission of the requests  111 , the next job whose dependency requirements have been met may be removed from job queue  142  in the depicted embodiment, as indicated by arrow  113 , and a processing plan comprising a workload distribution strategy may be identified for it. The workload distribution strategy layer  175 , which may also be a component of the MLS control plane as mentioned earlier, may determine the manner in which the lower level operations of the job are to be distributed among one or more compute servers (e.g., servers selected from pool  185 ), and/or the manner in which the data analyzed or manipulated for the job is to be distributed among one or more storage devices or servers. After the processing plan has been generated and the appropriate set of resources to be utilized for the job has been identified, the job&#39;s operations may be scheduled on the resources. Results of some jobs may be stored as MLS artifacts within repository  120  in some embodiments, as indicated by arrow  142 . 
     In at least one embodiment, some relatively simple types of client requests  111  may result in the immediate generation, retrieval, storage, or modification of corresponding artifacts within MLS artifact repository  120  by the MLS request handler  180  (as indicated by arrow  141 ). Thus, the insertion of a job object in job queue  142  may not be required for all types of client requests. For example, a creation or removal of an alias for an existing model may not require the creation of a new job in such embodiments. In the embodiment shown in  FIG. 1 , clients  164  may be able to view at least a subset of the artifacts stored in repository  120 , e.g., by issuing read requests  118  via programmatic interfaces  161 . 
     A client request  111  may indicate one or more parameters that may be used by the MLS to perform the operations, such as a data source definition  150 , a feature processing transformation recipe  152 , or parameters  154  to be used for a particular machine learning algorithm. In some embodiments, artifacts respectively representing the parameters may also be stored in repository  120 . Some machine learning workflows, which may correspond to a sequence of API requests from a client  164 , may include the extraction and cleansing of input data records from raw data repositories  130  (e.g., repositories indicated in data source definitions  150 ) by input record handlers  160  of the MLS, as indicated by arrow  114 . This first portion of the workflow may be initiated in response to a particular API invocation from a client  164 , and may be executed using a first set of resources from pool  185 . The input record handlers may, for example, perform such tasks as splitting the data records, sampling the data records, and so on, in accordance with a set of functions defined in an I/O (input/output) library of the MLS. The input data may comprise data records that include variables of any of a variety of data types, such as, for example text, a numeric data type (e.g., real or integer), Boolean, a binary data type, a categorical data type, an image processing data type, an audio processing data type, a video processing data type, a bioinformatics data type, a structured data type such as a data type compliant with the Unstructured Information Management Architecture (UIMA), and so on. In at least some embodiments, the input data reaching the MLS may be encrypted or compressed, and the MLS input data handling machinery may have to perform decryption or decompression before the input data records can be used for machine learning tasks. In some embodiments in which encryption is used, MLS clients may have to provide decryption metadata (e.g., keys, passwords, or other credentials) to the MLS to allow the MLS to decrypt data records. Similarly, an indication of the compression technique used may be provided by the clients in some implementations to enable the MLS to decompress the input data records appropriately. The output produced by the input record handlers may be fed to feature processors  162  (as indicated by arrow  115 ), where a set of transformation operations may be performed  162  in accordance with recipes  152  using another set of resources from pool  185 . Any of a variety of feature processing approaches may be used depending on the problem domain: e.g., the recipes typically used for computer vision problems may differ from those used for voice recognition problems, natural language processing, and so on. The output  116  of the feature processing transformations may in turn be used as input for a selected machine learning algorithm  166 , which may be executed in accordance with algorithm parameters  154  using yet another set of resources from pool  185 . A wide variety of machine learning algorithms may be supported natively by the MLS libraries, including for example random forest algorithms, neural network algorithms, stochastic gradient descent algorithms, and the like. In at least one embodiment, the MLS may be designed to be extensible—e.g., clients may provide or register their own modules (which may be defined as user-defined functions) for input record handling, feature processing, or for implementing additional machine learning algorithms than are supported natively by the MLS. In some embodiments, some of the intermediate results (e.g., summarized statistics produced by the input record handlers) of a machine learning workflow may be stored in MLS artifact repository  120 . 
     In the embodiment depicted in  FIG. 1 , the MLS may maintain knowledge base  122  containing information on best practices for various machine learning tasks. Entries may be added into the best practices KB  122  by various control-plane components of the MLS, e.g., based on metrics collected from server pools  185 , feedback provided by clients  164 , and so on. Clients  164  may be able to search for and retrieve KB entries via programmatic interfaces  161 , as indicated by arrow  117 , and may use the information contained in the entries to select parameters (such as specific recipes or algorithms to be used) for their request submissions. In at least some embodiments, new APIs may be implemented (or default values for API parameters may be selected) by the MLS on the basis of best practices identified over time for various types of machine learning practices. 
       FIG. 2  illustrates an example of a machine learning service implemented using a plurality of network-accessible services of a provider network, according to at least some embodiments. Networks set up by an entity such as a company or a public sector organization to provide one or more services (such as various types of multi-tenant and/or single-tenant cloud-based computing or storage services) accessible via the Internet and/or other networks to a distributed set of clients may be termed provider networks herein. A given provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment and the like, needed to implement, configure and distribute the infrastructure and services offered by the provider. At least some provider networks and the corresponding network-accessible services may be referred to as “public clouds” and “public cloud services” respectively. Within large provider networks, some data centers may be located in different cities, states or countries than others, and in some embodiments the resources allocated to a given service such as the MLS may be distributed among several such locations to achieve desired levels of availability, fault-resilience and performance, as described below in greater detail with reference to  FIG. 3 . 
     In the embodiment shown in  FIG. 2 , the MLS utilizes storage service  202 , computing service  258 , and database service  255  of provider network  202 . At least some of these services may also be used concurrently by other customers (e.g., other services implemented at the provider network, and/or external customers outside the provider network) in the depicted embodiment, i.e., the services may not be restricted to MLS use. MLS gateway  222  may be established to receive client requests  210  submitted over external network  206  (such as portions of the Internet) by clients  164 . MLS gateway  222  may, for example, be configured with a set of publicly accessible IP (Internet Protocol) addresses that can be used to access the MLS. The client requests may be formatted in accordance with a representational state transfer (REST) API implemented by the MLS in some embodiments. In one embodiment, MLS customers may be provided an SDK (software development kit)  204  for local installation at client computing devices, and the requests  210  may be submitted from within programs written in conformance with the SDK. A client may also or instead access MLS functions from a compute server  262  of computing service  262  that has been allocated to the client in various embodiments. 
     Storage service  252  may, for example, implement a web services interface that can be used to create and manipulate unstructured data objects of arbitrary size. Database service  255  may implement either relational or non-relational databases. The storage service  252  and/or the database service  255  may play a variety of roles with respect to the MLS in the depicted embodiment. The MLS may require clients  164  to define data sources within the provider network boundary for their machine learning tasks in some embodiments. In such a scenario, clients may first transfer data from external data sources  229  into internal data sources within the provider network, such as internal data source  230 A managed by storage service  252 , or internal data source  230 B managed by database service  255 . In some cases, the clients of the MLS may already be using the provider network services for other applications, and some of the output of those applications (e.g., web server logs or video files), saved at the storage service  252  or the database service  255 , may serve as the data sources for MLS workflows. 
     In response to at least some client requests  210 , the MLS request handler  180  may generate and store corresponding job objects within a job queue  142 , as discussed above. In the embodiment depicted in  FIG. 2 , the job queue  142  may itself be represented by a database object (e.g., a table) stored at database service  255 . A job scheduler  272  may retrieve a job from queue  142 , e.g., after checking that the job&#39;s dependency requirements have been met, and identify one or more servers  262  from computing service  258  to execute the job&#39;s computational operations. Input data for the computations may be read from the internal or external data sources by the servers  262 . The MLS artifact repository  220  may be implemented within the database service  255  (and/or within the storage service  252 ) in various embodiments. In some embodiments, intermediate or final results of various machine learning tasks may also be stored within the storage service  252  and/or the database service  255 . 
     Other services of the provider network, e.g., including load balancing services, parallel computing services, automated scaling services, and/or identity management services, may also be used by the MLS in some embodiments. A load balancing service may, for example, be used to automatically distribute computational load among a set of servers  262 . A parallel computing service that implements the Map-reduce programming model may be used for some types of machine learning tasks. Automated scaling services may be used to add or remove servers assigned to a particular long-lasting machine learning task. Authorization and authentication of client requests may be performed with the help of an identity management service of the provider network in some embodiments. 
     In some embodiments a provider network may be organized into a plurality of geographical regions, and each region may include one or more availability containers, which may also be termed “availability zones”. An availability container in turn may comprise portions or all of one or more distinct physical premises or data centers, engineered in such a way (e.g., with independent infrastructure components such as power-related equipment, cooling equipment, and/or physical security components) that the resources in a given availability container are insulated from failures in other availability containers. A failure in one availability container may not be expected to result in a failure in any other availability container; thus, the availability profile of a given physical host or server is intended to be independent of the availability profile of other hosts or servers in a different availability container. 
     In addition to their distribution among different availability containers, provider network resources may also be partitioned into distinct security containers in some embodiments. For example, while in general various types of servers of the provider network may be shared among different customers&#39; applications, some resources may be restricted for use by a single customer. A security policy may be defined to ensure that specified group of resources (which may include resources managed by several different provider network services, such as a computing service, a storage service, or a database service, for example) are only used by a specified customer or a specified set of clients. Such a group of resources may be referred to as “security containers” or “security groups” herein. 
       FIG. 3  illustrates an example of the use of a plurality of availability containers and security containers of a provider network for a machine learning service, according to at least some embodiments. In the depicted embodiment, provider network  302  comprises availability containers  366 A,  366 B and  366 C, each of which may comprise portions or all of one or more data centers. Each availability container  366  has its own set of MLS control-plane components  344 : e.g., control plane components  344 A- 344 C in availability containers  366 A- 366 C respectively. The control plane components in a given availability container may include, for example, an instance of an MLS request handler, one or more MLS job queues, a job scheduler, workload distribution components, and so on. The control plane components in different availability containers may communicate with each other as needed, e.g., to coordinate tasks that utilize resources at more than one data center. Each availability container  366  has a respective pool  322  (e.g.,  322 A- 322 C) of MLS servers to be used in a multi-tenant fashion. The servers of the pools  322  may each be used to perform a variety of MLS operations, potentially for different MLS clients concurrently. In contrast, for executing MLS tasks that require a higher level of security or isolation, single-tenant server pools that are designated for only a single client&#39;s workload may be used, such as single tenant server pools  330 A,  330 B and  330 C. Pools  330 A and  330 B belong to security container  390 A, while pool  330 C is part of security container  390 B. Security container  390 A may be used exclusively for a customer C 1  (e.g., to run customer-provided machine learning modules, or third-party modules specified by the customer), while security container  390 B may be used exclusively for a different customer C 2  in the depicted example. 
     In some embodiments, at least some of the resources used by the MLS may be arranged in redundancy groups that cross availability container boundaries, such that MLS tasks can continue despite a failure that affects MLS resources of a given availability container. For example, in one embodiment, a redundancy group RG 1  comprising at least one server S 1  in availability container  366 A, and at least one server S 2  in availability container  366 B may be established, such that S 1 &#39;s MLS-related workload may be failed over to S 2  (or vice versa). For long-lasting MLS tasks (such as tasks that involve terabyte or petabyte-scale data sets), the state of a given MLS job may be check-pointed to persistent storage (e.g., at a storage service or a database service of the provider network that is also designed to withstand single-availability-container failures) periodically, so that a failover server can resume a partially-completed task from the most recent checkpoint instead of having to start over from the beginning. The storage service and/or the database service of the provider network may inherently provide very high levels of data durability, e.g., using erasure coding or other replication techniques, so the data sets may not necessarily have to be copied in the event of a failure. In some embodiments, clients of the MLS may be able to specify the levels of data durability desired for their input data sets, intermediate data sets, artifacts, and the like, as well as the level of compute server availability desired. The MLS control plane may determine, based on the client requirements, whether resources in multiple availability containers should be used for a given task or a given client. The billing amounts that the clients have to pay for various MLS tasks may be based at least in part on their durability and availability requirements. In some embodiments, some clients may indicate to the MLS control-plane that they only wish to use resources within a given availability container or a given security container. For certain types of tasks, the costs of transmitting data sets and/or results over long distances may be so high, or the time required for the transmissions may so long, that the MLS may restrict the tasks to within a single geographical region of the provider network (or even within a single data center). 
     Processing Plans 
     As mentioned earlier, the MLS control plane may be responsible for generating processing plans corresponding to each of the job objects generated in response to client requests in at least some embodiments. For each processing plan, a corresponding set of resources may then have to be identified to execute the plan, e.g., based on the workload distribution strategy selected for the plan, the available resources, and so on.  FIG. 4  illustrates examples of various types of processing plans and corresponding resource sets that may be generated at a machine learning service, according to at least some embodiments. 
     In the illustrated scenario, MLS job queue  142  comprises five jobs, each corresponding to the invocation of a respective API by a client. Job J 1  (shown at the head of the queue) was created in response to an invocation of API 1 . Jobs J 2  through J 5  were created respectively in response to invocations of API 2  through API 5 . Corresponding to job J 1 , an input data cleansing plan  422  may be generated, and the plan may be executed using resource set RS 1 . The input data cleansing plan may include operations to read and validate the contents of a specified data source, fill in missing values, identify and discard (or otherwise respond to) input records containing errors, and so on. In some cases the input data may also have to be decompressed, decrypted, or otherwise manipulated before it can be read for cleansing purposes. Corresponding to job J 2 , a statistics generation plan  424  may be generated, and subsequently executed on resource set RS 2 . The types of statistics to be generated for each data attribute (e.g., mean, minimum, maximum, standard deviation, quantile binning, and so on for numeric attributes) and the manner in which the statistics are to be generated (e.g., whether all the records generated by the data cleansing plan  422  are to be used for the statistics, or a sub-sample is to be used) may be indicated in the statistics generation plan. The execution of job J 2  may be dependent on the completion of job J 1  in the depicted embodiment, although the client request that led to the generation of job J 2  may have been submitted well before J 1  is completed. 
     A recipe-based feature processing plan  426  corresponding to job J 3  (and API 3 ) may be generated, and executed on resource set RS 3 . Further details regarding the syntax and management of recipes are provided below. Job J 4  may result in the generation of a model training plan  428  (which may in turn involve several iterations of training, e.g., with different sets of parameters). The model training may be performed using resource set RS 4 . Model execution plan  430  may correspond to job J 5  (resulting from the client&#39;s invocation of APIS), and the model may eventually be executed using resource set RS 5 . In some embodiments, the same set of resources (or an overlapping set of resources) may be used for performing several or all of a client&#39;s jobs—e.g., the resource sets RS 1 -RS 5  may not necessarily differ from one another. In at least one embodiment, a client may indicate, e.g., via parameters included in an API call, various elements or properties of a desired processing plan, and the MLS may take such client preferences into account. For example, for a particular statistics generation job, a client may indicate that a randomly-selected sample of 25% of the cleansed input records may be used, and the MLS may generate a statistics generation plan that includes a step of generating a random sample of 25% of the data accordingly. In other cases, the MLS control plane may be given more freedom to decide exactly how a particular job is to be implemented, and it may consult its knowledge base of best practices to select the parameters to be used. 
     Job Scheduling 
       FIG. 5  illustrates an example of asynchronous scheduling of jobs at a machine learning service, according to at least some embodiments. In the depicted example, a client has invoked four MLS APIs, API 1  through API 4 , and four corresponding job objects J 1  through J 4  are created and placed in job queue  142 . Timelines TL 1 , TL 2 , and TL 3  show the sequence of events from the perspective of the client that invokes the APIs, the request handler that creates and inserts the jobs in queue  142 , and a job scheduler that removes the jobs from the queue and schedules the jobs at selected resources. 
     In the depicted embodiment, in addition to the base case of no dependency on other jobs, two types of inter job dependencies may be supported. In one case, termed “completion dependency”, the execution of one job Jp cannot be started until another job Jq is completed successfully (e.g., because the final output of Jq is required as input for Jp). Full dependency is indicated in  FIG. 5  by the parameter “dependsOnComplete” shown in the job objects—e.g., J 2  is dependent on J 1  completing execution, and J 4  depends on J 2  completing successfully. In the other type of dependency, the execution of one job Jp may be started as soon as some specified phase of another job Jq is completed. This latter type of dependency may be termed a “partial dependency”, and is indicated in  FIG. 5  by the “dependsOnPartial” parameter. For example, J 3  depends on the partial completion of J 2 , and J 4  depends on the partial completion of J 3 . It is noted that in some embodiments, to simplify the scheduling, such phase-based dependencies may be handled by splitting a job with N phases into N smaller jobs, thereby converting partial dependencies into full dependencies. J 1  has no dependencies of either type in the depicted example. 
     As indicated on client timeline TL 1 , API 1  through API 4  may be invoked within the time period t 0  to t 1 . Even though some of the operations requested by the client depend on the completion of operations corresponding to earlier-invoked APIs, the MLS may allow the client to submit the dependent operation requests much earlier than the processing of the earlier-invoked APIs&#39; jobs in the depicted embodiment. In at least some embodiments, parameters specified by the client in the API calls may indicate the inter job dependencies. For example, in one implementation, in response to API 1 , the client may be provided with a job identifier for J 1 , and that job identifier may be included as a parameter in API 2  to indicate that the results of API 1  are required to perform the operations corresponding to API 2 . As indicated by the request handler&#39;s timeline TL 2 , the jobs corresponding to each API call may be created and queued shortly after the API is invoked. Thus, all four jobs have been generated and placed within the job queue  142  by a short time after t 1 . 
     As shown in the job scheduler timeline TL 3 , job J 1  may be scheduled for execution at time t 2 . The delay between the insertion of J 1  in queue  142  (shortly after t 0 ) and the scheduling of J 1  may occur for a number of reasons in the depicted embodiment—e.g., because there may have been other jobs ahead of J 1  in the queue  142 , or because it takes some time to generate a processing plan for J 1  and identify the resources to be used for J 1 , or because enough resources were not available until t 2 . J 1 &#39;s execution lasts until t 3 . In the depicted embodiment, when J 1  completes, (a) the client is notified and (b) J 2  is scheduled for execution. As indicated by J 2 &#39;s dependsOnComplete parameter value, J 2  depends on J 1 &#39;s completion, and J 2 &#39;s execution could therefore not have been begun until t 3 , even if J 2 &#39;s processing plan were ready and J 2 &#39;s resource set had been available prior to t 3 . 
     As indicated by J 3 &#39;s “dependsOnPartial” parameter value, J 3  can be started when a specified phase or subset of J 2 &#39;s work is complete in the depicted example. The portion of J 2  upon which J 3  depends completes at time t 4  in the illustrated example, and the execution of J 3  therefore begins (in parallel with the execution of the remaining portion of J 2 ) at t 4 . In the depicted example, the client may be notified at time t 4  regarding the partial completion of J 2  (e.g., the results of the completed phase of J 2  may be provided to the client). 
     At t 5 , the portion of J 3  on which J 4  depends may be complete, and the client may be notified accordingly. However, J 4  also depends on the completion of J 2 , so J 4  cannot be started until J 2  completes at t 6 . J 3  continues execution until t 8 . J 4  completes at t 7 , earlier than t 8 . The client is notified regarding the completion of each of the jobs corresponding to the respective API invocations API 1 -API 4  in the depicted example scenario. In some embodiments, partial dependencies between jobs may not be supported—instead, as mentioned earlier, in some cases such dependencies may be converted into full dependencies by splitting multi-phase jobs into smaller jobs. In at least one implementation, instead of or in addition to being notified when the jobs corresponding to the API invocations are complete (or when phases of the jobs are complete), clients may be able to submit queries to the MLS to determine the status (or the extent of completion) of the operations corresponding to various API calls. For example, an MLS job monitoring web page may be implemented, enabling clients to view the progress of their requests (e.g., via a “percent complete” indicator for each job), expected completion times, and so on. In some embodiments, a polling mechanism may be used by clients to determine the progress or completion of the jobs. 
     MLS Artifacts 
       FIG. 6  illustrates example artifacts that may be generated and stored using a machine learning service, according to at least some embodiments. In general, MLS artifacts may comprise any of the objects that may be stored in a persistent manner as a result of an invocation of an MLS programmatic interface. In some implementations, some API parameters (e.g., text versions of recipes) that are passed to the MLS may be stored as artifacts. As shown, in the depicted embodiment, MLS artifacts  601  may include, among others, data sources  602 , statistics  603 , feature processing recipes  606 , model predictions  608 , evaluations  610 , modifiable or in-development models  630 , and published models or aliases  640 . In some implementations the MLS may generate a respective unique identifier for each instance of at least some of the types of artifacts shown and provide the identifiers to the clients. The identifiers may subsequently be used by clients to refer to the artifact (e.g., in subsequent API calls, in status queries, and so on). 
     A client request to create a data source artifact  602  may include, for example, an indication of an address or location from which data records can be read, and some indication of the format or schema of the data records. For example, an indication of a source URI (universal resource identifier) to which HTTP GET requests can be directed to retrieve the data records, an address of a storage object at a provider network storage service, or a database table identifier may be provided. The format (e.g., the sequence and types of the fields or columns of the data records) may be indicated in some implementations via a separate comma separated variable (csv) file. In some embodiments, the MLS may be able to deduce at least part of the address and/or format information needed to create the data source artifact—e.g., based on the client&#39;s identifier, it may be possible to infer the root directory or root URI of the client&#39;s data source, and based on an analysis of the first few records, it may be possible to deduce at least the data types of the columns of the schema. In some embodiments, the client request to create a data source may also include a request to re-arrange the raw input data, e.g., by sampling or splitting the data records using an I/O library of the MLS. When requesting a creation of a data source, in some implementations clients may also be required to provide security credentials that can be used by the MLS to access the data records. 
     In some embodiments, as described in further detail below with respect to  FIG. 7 , at least some statistics  603  may be generated automatically for the data records of a data source. In other embodiments, the MLS may also or instead enable clients to explicitly request the generation of various types of statistics, e.g., via the equivalent of a createStatistics(dataSourceID, statisticsDescriptor) request in which the client indicates the types of statistics to be generated for a specified data source. The types of statistics artifacts that are generated may vary based on the data types of the input record variables—e.g., for numeric variables, the mean, median, minimum, maximum, standard deviation, quantile bins, number of nulls or “not-applicable” values and the like may be generated. Cross-variable statistics such as correlations may also be generated, either automatically or on demand, in at least some embodiments. 
     Recipes  606  comprising feature processing transformation instructions may be provided by a client (or selected from among a set of available recipes accessible from an MLS recipe collection) in some embodiments. A recipe language allowing clients to define groups of variables, assignments, dependencies upon other artifacts such as models, and transformation outputs may be supported by the MLS in such embodiments, as described below in greater detail. Recipes submitted in text form may be compiled into executable versions and re-used on a variety of data sets in some implementations. 
     At least two types of artifacts representing machine learning models or predictors may be generated and stored in the depicted embodiment. Often, the process of developing and refining a model may take a long time, as the developer may try to improve the accuracy of the predictions using a variety of data sets and a variety of parameters. Some models may be improved over a number of weeks or months, for example. In such scenarios it may be worthwhile to enable other users (e.g., business analysts) to utilize one version of a model, while model developers continue to generate other, improved versions. Accordingly, the artifacts representing models may belong to one of two categories in some embodiments: modifiable models  630 , and published models or aliases  640 . An alias may comprise an alias name or identifier, and a pointer to a model (e.g., alias  640 A points to model  630 B, and alias  640 B points to model  630 D in the depicted embodiment). As used herein, the phrase “publishing a model” refers to making a particular version of a model executable by a set of users by reference to an alias name or identifier. In some cases, at least some of the users of the set may not be permitted to modify the model or the alias. Non-expert users  678  may be granted read and execute permissions to the aliases, while model developers  676  may also be allowed to modify models  630  (and/or the pointers of the aliases  640 ) in some embodiments. In some embodiments, a set of guarantees may be provided to alias users: e.g., that the format of the input and output of an alias (and the underlying model referred to by the alias) will not change once the alias is published, and that the model developers have thoroughly tested and validated the underlying model pointed to by the alias. In addition, a number of other logical constraints may be enforced with respect to aliases in such embodiments. For example, if the alias is created for a model used in online mode (model usage modes are described in further detail below with respect to  FIG. 8 ), the MLS may guarantee that the model pointed to remains online (i.e., the model cannot be un-mounted). In some implementations a distinction may be drawn between aliases that are currently in production mode and those that are in internal-use or test mode, and the MLS may ensure that the underlying model is not deleted or un-mounted for an alias in production mode. When creating aliases to online-mode models, a minimum throughput rate of predictions/evaluations may be determined for the alias, and the MLS may ensure that the resources assigned to the model can meet the minimum throughput rate in some embodiments. After model developers  676  improve the accuracy and/or performance characteristics of a newer version of a model  630  relative to an older version for which an alias  640  has been created, they may switch the pointer of the alias so that it now points to the improved version. Thus, non-expert users may not have to change anything in the way that they have been using the aliases, while benefiting from the improvements. In some embodiments, alias users may be able to submit a query to learn when the underlying model was last changed, or may be notified when they request an execution of an alias that the underlying model has been changes since the last execution. 
     Results of model executions, such as predictions  608  (values predicted by a model for a dependent variable in a scenario in which the actual values of the independent variable are not known) and model evaluations  610  (measures of the accuracy of a model, computed when the predictions of the model can be compared to known values of dependent variables) may also be stored as artifacts by the MLS in some embodiments. In addition to the artifact types illustrated in  FIG. 6 , other artifact types may also be supported in some embodiments—e.g., objects representing network endpoints that can be used for real-time model execution on streaming data (as opposed to batch-mode execution on a static set of data) may be stored as artifacts in some embodiments, and client session logs (e.g., recordings of all the interactions between a client and the MLS during a given session) may be stored as artifacts in other embodiments. 
     In some embodiments, the MLS may support recurring scheduling of related jobs. For example, a client may create an artifact such as a model, and may want that same model to be re-trained and/or re-executed for different input data sets (e.g., using the same configuration of resources for each of the training or prediction iterations) at specified points in time. In some cases the points in time may be specified explicitly (e.g., by the client requesting the equivalent of “re-run model M 1  on the currently available data set at data source DS 1  at 11:00, 15:00 and 19:00 every day”). In other cases the client may indicate the conditions under which the iterations are to be scheduled (e.g., by the client requesting the equivalent of “re-run model M 1  whenever the next set of 1000000 new records becomes available from data source DS 1 ”). A respective job may be placed in the MLS job queue for each recurring training or execution iteration. The MLS may implement a set of programmatic interface enabling such scheduled recurring operations in some embodiments. Using such an interface, a client may specify a set of model/alias/recipe artifacts (or respective versions of the same underling artifact) to be used for each of the iterations, and/or the resource configurations to be used. Such programmatic interfaces may be referred to as “pipelining APIs” in some embodiments. In addition to the artifact types shown in  FIG. 6 , pipeline artifacts may be stored in the MLS artifact repository in some embodiments, with each instance of a pipeline artifact representing a named set of recurring operations requested via such APIs. In one embodiment, a separately-managed data pipelining service implemented at the provider network may be used in conjunction with the MLS for supporting such recurrent operations. 
     As mentioned above, in some embodiments, the MLS may automatically generate statistics when a data source is created.  FIG. 7  illustrates an example of automated generation of statistics in response to a client request to instantiate a data source, according to at least some embodiments. As shown, a client  764  submits a data source creation request  712  to the MLS control plane  780  via an MLS API  761 . The creation request may specify an address or location from which data records can be retrieved, and optionally a schema or format document indicating the columns or fields of the data records. 
     In response to receiving request  712 , the MLS control plane  780  may generate and store a data source artifact  702  in the MLS artifact repository. In addition, and depending in some cases on the current availability of resources at the MLS, the MLS may also initiate the generation of one or more statistics objects  730  in the depicted embodiment, even if the client request did not explicitly request such statistics. Any combination of a number of different types of statistics may be generated automatically in one of two modes in various embodiments. For example, for very large data sets, an initial set of statistics  763  based on a sub-sample (e.g., a randomly-selected subset of the large data set) may be obtained in a first phase, while the generation of full-sample statistics  764  derived from the entire data set may be deferred to a second phase. Such a multi-phase approach towards statistics generation may be implemented, for example, to allow the client to get a rough or approximate summary of the data set values fairly rapidly in the first phase, so that the client may begin planning subsequent machine learning workflow steps without waiting for a statistical analysis of the complete data set. 
     As shown, a variety of different statistics may be obtained in either phase. For numeric variables, basic statistics  765  may include the mean, median, minimum, maximum, and standard deviation. Numeric variables may also be binned (categorized into a set of ranges such as quartiles or quintiles); such bins  767  may be used for the construction of histograms that may be displayed to the client. Depending on the nature of the distribution of the variable, either linear or logarithmic bin boundaries may be selected. In some embodiments, correlations  768  between different variables may be computed as well. In at least one embodiment, the MLS may utilize the automatically generated statistics (such as the correlation values) to identify candidate groups  769  of variables that may have greater predictive power than others. For example, to avoid over-fitting for certain classes of models, only one variable among a set of variables that correlate very strongly with one another may be recommended as a candidate for input to a model. In such scenarios, the client may be able to avoid the time and effort required to explore the significance of other variables. In many problem domains in which a given data record may have hundreds or even thousands of variables, such an automated selection of candidate variables expected to have greater predictive effectiveness may be very valuable to clients of the MLS. 
       FIG. 8  illustrates several model usage modes that may be supported at a machine learning service, according to at least some embodiments. Model usage modes may be broadly classified into three categories: batch mode, online or real-time mode, and local mode. In batch mode, a given model may be run on a static set of data records. In real-time mode, a network endpoint (e.g., an IP address) may be assigned as a destination to which input data records for a specified model are to be submitted, and model predictions may be generated on groups of streaming data records as the records are received. In local mode, clients may receive executable representations of a specified model that has been trained and validated at the MLS, and the clients may run the models on computing devices of their choice (e.g., at devices located in client networks rather than in the provider network where the MLS is implemented). 
     In the depicted embodiment, a client  164  of the MLS may submit a model execution request  812  to the MLS control plane  180  via a programmatic interface  861 . The model execution request may specify the execution mode (batch, online or local), the input data to be used for the model run (which may be produced using a specified data source or recipe in some cases), the type of output (e.g., a prediction or an evaluation) that is desired, and/or optional parameters (such as desired model quality targets, minimum input record group sizes to be used for online predictions, and so on). In response the MLS may generate a plan for model execution and select the appropriate resources to implement the plan. In at least some embodiments, a job object may be generated upon receiving the execution request  812  as described earlier, indicating any dependencies on other jobs (such as the execution of a recipe for feature processing), and the job may be placed in a queue. For batch mode  865 , for example, one or more servers may be identified to run the model. For online mode  867 , the model may be mounted (e.g., configured with a network address) to which data records may be streamed, and from which results including predictions  868  and/or evaluations  869  can be retrieved. In at least one embodiment, clients may optionally specify expected workload levels for a model that is to be instantiated in online mode, and the set of provider network resources to be deployed for the model may be selected in accordance with the expected workload level. For example, a client may indicate via a parameter of the model execution/creation request that up to 100 prediction requests per day are expected on data sets of 1 million records each, and the servers selected for the model may be chosen to handle the specified request rate. For local mode, the MLS may package up an executable local version  843  of the model (where the details of the type of executable that is to be provided, such as the type of byte code or the hardware architecture on which the model is to be run, may have been specified in the execution request  812 ) and transmit the local model to the client. In some embodiments, only a subset of the execution modes illustrated may be supported. In some implementations, not all of the combinations of execution modes and output types may be supported—for example, while predictions may be supported for online mode in one implementation, evaluations may not be supported for online mode. 
     Methods for Implementing MLS Operations 
       FIGS. 9 a  and 9 b    are flow diagrams illustrating aspects of operations that may be performed at a machine learning service that supports asynchronous scheduling of machine learning jobs, according to at least some embodiments. As shown in element  901  of  FIG. 9 a   , the MLS may receive a request from a client via a programmatic interface (such as an API, a command-line tool, a web page, or a custom GUI) to perform a particular operation on an entity belonging to a set of supported entity types of the MLS. The entity types may include, for example, data sources, statistics, feature processing recipes, models, aliases, predictions, and/or evaluations in the depicted embodiment. The operations requested may include, for example, create, read (or describe the attributes of), modify/update attributes, execute, search, or delete operations. Not all the operation types may apply to all the entity types in some embodiments—e.g., it may not be possible to “execute” a data source. In at least some implementations, the request may be encrypted or encapsulated by the client, and the MLS may have to extract the contents of the request using the appropriate keys and/or certificates. 
     The request may next be validated in accordance with various rules or policies of the MLS (element  904 ). For example, in accordance with a security policy, the permissions, roles or capabilities granted to the requesting client may be checked to ensure that the client is authorized to have the requested operations performed. The syntax of the request itself, and/or objects such as recipes passed as request parameters may be checked for some types of requests. In some cases, the types of one or more data variables indicated in the request may have to be checked as well. 
     If the request passes the validation checks, a decision may be made as to whether a job object is to be created for the request. As mentioned earlier, in some cases, the amount of work required may be small enough that the MLS may simply be able to perform the requested operation synchronously or “in-line”, instead of creating and inserting a job object into a queue for asynchronous execution (at least in scenarios in which the prerequisites or dependencies of the request have already been met, and sufficient resources are available for the MLS to complete the requested work). If an analysis of the request indicates that a job is required (as detected in element  907 ), a job object may be generated, indicating the nature of the lower-level operations to be performed at the MLS as well as any dependencies on other jobs, and the job object may be placed in a queue (element  913 ). In some implementations, the requesting client may be notified that the request has been accepted for execution (e.g., by indicating to the client that a job has been queued for later execution). The client may submit another programmatic request without waiting for the queued job to be completed (or even begun) in some cases. If the job does not have any dependencies that have yet to be met, and meets other criteria for immediate or in-line execution (as also determined in element  907 ), the requested operation may be performed without creating a job object (element  910 ) and the results may optionally be provided to the requesting client. Operations corresponding to elements  901 - 913  may be performed for each request that is received via the MLS programmatic interface. At some point after a particular job Jk is placed in the queue, Jk may be identified (e.g., by a job scheduler component of the MLS control plane) as the next job to be implemented (element  951  of  FIG. 9 b   ). To identify the next job to be implemented, the scheduler may, for example, start from the head of the queue (the earliest-inserted job that has not yet been executed) and search for jobs whose dependencies (if any are specified) have been met. 
     In addition to the kinds of validation indicated in element  904  of  FIG. 9 a   , the MLS may perform validations at various other stages in some embodiments, e.g., with the general goals of (a) informing clients as soon as possible when a particular request is found to be invalid, and (b) avoiding wastage of MLS resources on requests that are unlikely to succeed. As shown in element  952  of  FIG. 9 b   , one or more types of validation checks may be performed on the job Jk identified in element  951 . For example, in one embodiment each client may have a quota or limit on the resources that can be applied to their jobs (such as a maximum number of servers that can be used concurrently for all of a given customer&#39;s jobs, or for any given job of the customer). In some implementations respective quotas may be set for each of several different resource types—e.g., CPUs/cores, memory, disk, network bandwidth and the like. In such scenarios, the job scheduler may be responsible for verifying that the quota or quotas of the client on whose behalf the job Jk is to be run have not been exhausted. If a quota has been exhausted, the job&#39;s execution may be deferred until at least some of the client&#39;s resources are released (e.g., as a result of a completion of other jobs performed on the same client&#39;s behalf). Such constraint limits may be helpful in limiting the ability of any given client to monopolize shared MLS resources, and also in minimizing the negative consequences of inadvertent errors or malicious code. In addition to quota checks, other types of run-time validations may be required for at least some jobs—e.g., data type checking may have to be performed on the input data set for jobs that involve feature processing, or the MLS may have to verify that the input data set size is within acceptable bounds. Thus, client requests may be validated synchronously (at the time the request is received, as indicated in element  904  of  FIG. 9 a   ) as well as asynchronously (as indicated in element  952  of  FIG. 9 b   ) in at least some embodiments. A workload distribution strategy and processing plan may be identified for Jk—e.g., the number of processing passes or phases to be used, the degree of parallelism to be used, an iterative convergence criterion to be used for completing Jk (element  954 ). A number of additional factors may be taken into account when generating the processing plan in some embodiments, such as client budget constraints (if any), the data durability needs of the client, the performance goals of the client, security needs (such as the need to run third-party code or client-provided code in isolation instead of in multi-tenant mode). 
     In accordance with the selected distribution strategy and processing plan, a set of resources may be identified for Jk (element  957 ). The resources (which may include compute servers or clusters, storage devices, and the like) may be selected from the MLS-managed shared pools, for example, and/or from customer-assigned or customer-owned pools. JK&#39;s operations may then be performed on the identified resources (element  960 ), and the client on whose behalf Jk was created may optionally be notified when the operations complete (or in the event of a failure that prevents completion of the operations). 
     Idempotent Programmatic Interfaces 
     Some of the types of operations requested by MLS clients may be resource-intensive. For example, ingesting a terabyte-scale data set (e.g., in response to a client request to create a data store) or generating statistics on such a data set may take hours or days, depending on the set of resources deployed and the extent of parallelism used. Given the asynchronous manner in which client requests are handled in at least some embodiments, clients may sometimes end up submitting the same request multiple times. In some cases, such multiple submissions may occur because the client is unaware whether the previous submission was accepted or not (e.g., because the client failed to notice an indication that the previous submission was accepted, or because such an indication was lost). In other cases, a duplicate request may be received because the client has assumed that since the expected results of completing the requested task have not been provided for a long time, the previous request must have failed. If, in response to such a duplicate submission, the MLS actually schedules another potentially large job, resources may be deployed unnecessarily and the client may in some cases be billed twice for a request that was only intended to be serviced once. Accordingly, in order to avoid such problematic scenarios, in at least one embodiment one or more of the programmatic interfaces supported by the MLS may be designed to be idempotent, such that the re-submission of a duplicate request by the same client does not have negative consequences. 
       FIG. 10 a    is a flow diagram illustrating aspects of operations that may be performed at a machine learning service at which a set of idempotent programmatic interfaces are supported, according to at least some embodiments. In  FIG. 10 a   , a creation interface (e.g., an API similar to “createDataSource” or “createModel”) is used as an example of an idempotent programmatic interface. Although idempotency may be especially useful for programmatic interfaces that involve creation of artifacts such as data sources and models, idempotent interfaces may also be supported for other types of operations (e.g., deletes or executes) in various embodiments. As shown in element  1001 , a request to create a new instance of an entity type ET 1  may be received from a client C 1  at the MLS via a programmatic interface such as a particular API. The request may indicate an identifier ID 1 , selected by the client, which is to be used for the new instance. In some implementations, the client may be required to specify the instance identifier, and the identifier may be used as described below to detect duplicate requests. (Allowing the client to select the identifier may have the additional advantage that a client may be able to assign a more meaningful name to entity instances than a name assigned by the MLS.) The MLS may generate a representation IPR 1  of the input parameters included in the client&#39;s invocation of the programmatic interface (element  1004 ). For example, the set of input parameters may be supplied as input to a selected hash function, and the output of the hash function may be saved as IPR 1 . 
     In the embodiment depicted in  FIG. 10 a   , for at least some of the artifacts generated, the MLS repository may store the corresponding instance identifier, input parameter representation, and client identifier (i.e., the identifier of the client that requested the creation of the artifact). The MLS may check, e.g., via a lookup in the artifact repository, whether an instance of entity type ET 1 , with instance identifier ID 1  and client identifier C 1  already exists in the repository. If no such instance is found (as detected in element  1007 ), a new instance of type ET 1  with the identifier ID 1 , input parameter representation IPR 1  and client identifier C 1  may be inserted into the repository (element  1007 ). In addition, depending on the type of the instance, a job object may be added to a job queue to perform additional operations corresponding to the client request, such as reading/ingesting a data set, generating a set of statistics, performing feature processing, executing a model, etc. A success response to the client&#39;s request (element  1016 ) may be generated in the depicted embodiment. (It is noted that the success response may be implicit in some implementations—e.g., the absence of an error message may serve as an implicit indicator of success.) 
     If, in operations corresponding to element  1007 , a pre-existing instance with the same instance identifier ID 1  and client identifier C 1  is found in the repository, the MLS may check whether the input parameter representation of the pre-existing instance also matches IPR 1  (element  1013 ). If the input parameter representations also match, the MLS may assume that the client&#39;s request is a (harmless) duplicate, and no new work needs to be performed. Accordingly, the MLS may also indicate success to the client (either explicitly or implicitly) if such a duplicate request is found (element  1016 ). Thus, if the client had inadvertently resubmitted the same request, the creation of a new job object and the associated resource usage may be avoided. In some implementations, if the client request is found to be an exact duplicate of an earlier request using the methodology described, an indication may be provided to the client that the request, while not being designated as an error, was in fact identified as a duplicate. If the input parameter representation of the pre-existing instance does not match that of the client&#39;s request, an error message may be returned to the client (element  1019 ), e.g., indicating that there is a pre-existing instance of the same entity type ET 1  with the same identifier. In some implementations, instead of requiring the client to submit an identifier, a different approach to duplicate detection may be used, such as the use of a persistent log of client requests, or the use of a signature representing the (request, client) combination. 
     Best Practices 
     One of the advantages of building a machine learning service that may be used by large numbers of customers for a variety of use cases is that it may become possible over time to identify best practices, e.g., with respect to which techniques work best for data cleansing, sampling or sub-set extraction, feature processing, predicting, and so on.  FIG. 10 b    is a flow diagram illustrating aspects of operations that may be performed at a machine learning service to collect and disseminate information about best practices related to different problem domains, according to at least some embodiments. As shown in element  1051 , at least some of the artifacts (such as recipes and models) generated at the MLS as a result of client requests may be classified into groups based on problem domains—e.g., some artifacts may be used for financial analysis, others for computer vision applications, others for bioinformatics, and so on. Such classification may be performed based on various factors in different embodiments—e.g. based on the types of algorithms used, the names of input and output variables, customer-provided information, the identities of the customers, and so on. 
     In some embodiments, the MLS control plane may comprise a set of monitoring agents that collect performance and other metrics from the resources used for the various phases of machine learning operations (element  1054 ). For example, the amount of processing time it takes to build N trees of a random forest using a server with a CPU rating of C 1  and a memory size of M 1  may be collected as a metric, or the amount of time it takes to compute a set of statistics as a function of the number of data attributes examined from a data source at a database service may be collected as a metric. The MLS may also collect ratings/rankings or other types of feedback from MLS clients regarding the effectiveness or quality of various approaches or models for the different problem domains. In some embodiments, quantitative measures of model predictive effectiveness such as the area under receiver operating characteristic (ROC) curves for various classifiers may also be collected. In one embodiment, some of the information regarding quality may be deduced or observed implicitly by the MLS instead of being obtained via explicit client feedback, e.g., by keeping track of the set of parameters that are changed during training iterations before a model is finally used for a test data set. In some embodiments, clients may be able to decide whether their interactions with the MLS can be used for best practice knowledge base enhancement or not—e.g., some clients may not wish their customized techniques to become widely used by others, and may therefore opt out of sharing metrics associated with such techniques with the MLS or with other users. 
     Based on the collected metrics and/or feedback, respective sets of best practices for various phases of machine learning workflows may be identified (element  1057 ). Some of the best practices may be specific to particular problem domains, while others may be more generally applicable, and may therefore be used across problem domains. Representations or summaries of the best practices identified may be stored in a knowledge base of the MLS. Access (e.g., via a browser or a search tool) to the knowledge base may be provided to MLS users (element  1060 ). The MLS may also incorporate the best practices into the programmatic interfaces exposed to users—e.g., by introducing new APIs that are more likely to lead users to utilize best practices, by selecting default parameters based on best practices, by changing the order in which parameter choices in a drop-down menu are presented so that the choices associated with best practices become more likely to be selected, and so on. In some embodiments the MLS may provide a variety of tools and/or templates that can help clients to achieve their machine learning goals. For example, a web-based rich text editor or installable integrated development environment (IDE) may be provided by the MLS, which provides templates and development guidance such as automated syntax error correction for recipes, models and the like. In at least one embodiment, the MLS may provide users with candidate models or examples that have proved useful in the past (e.g., for other clients solving similar problems). The MLS may also maintain a history of the operations performed by a client (or by a set of users associated with the same customer account) across multiple interaction sessions in some implementations, enabling a client to easily experiment with or employ artifacts that the same client generated earlier. 
     Feature Processing Recipes 
       FIG. 11  illustrates examples interactions associated with the use of recipes for data transformations at a machine learning service, according to at least some embodiments. In the depicted embodiment, a recipe language defined by the MLS enables users to easily and concisely specify transformations to be performed on specified sets of data records to prepare the records for use for model training and prediction. The recipe language may enable users to create customized groups of variables to which one or more transformations are to be applied, define intermediate variables and dependencies upon other artifacts, and so on, as described below in further detail. In one example usage flow, raw data records may first be extracted from a data source (e.g., by input record handlers such as those shown in  FIG. 1  with the help of an MLS I/O library), processed in accordance with one or more recipes, and then used as input for training or prediction. In another usage flow, the recipe may itself incorporate the training and/or prediction steps (e.g., a destination model or models may be specified within the recipe). Recipes may be applied either to data records that have already split into training and test subsets, or to the entire data set prior to splitting into training and test subsets. A given recipe may be re-used on several different data sets, potentially for a variety of different machine learning problem domains, in at least some embodiments. The recipe management components of the MLS may enable the generation of easy-to-understand compound models (in which the output of one model may be used as the input for another, or in which iterative predictions can be performed) as well as the sharing and re-use of best practices for data transformations. In at least one embodiment, a pipeline of successive transformations to be performed starting with a given input data set may be indicated within a single recipe. In one embodiment, the MLS may perform parameter optimization for one or more recipes—e.g., the MLS may automatically vary such transformation properties as the sizes of quantile bins or the number of root words to be included in an n-gram in an attempt to identify a more useful set of independent variables to be used for a particular machine learning algorithm. 
     In some embodiments, a text version  1101  of a transformation recipe may be passed as a parameter in a “createRecipe” MLS API call by a client. As shown, a recipe validator  1104  may check the text version  1101  of the recipe for lexical correctness, e.g., to ensure that it complies with a grammar  1151  defined by the MLS in the depicted embodiment, and that the recipe comprises one or more sections arranged in a predefined order (an example of the expected structure of a recipe is illustrated in  FIG. 12  and described below). In at least some embodiments, the version of the recipe received by the MLS need not necessarily be a text version; instead, for example, a pre-processed or partially-combined version (which may in some cases be in a binary format rather than in plain text) may be provided by the client. In one embodiment, the MLS may provide a tool that can be used to prepare recipes—e.g., in the form of a web-based recipe editing tool or a downloadable integrated development environment (IDE). Such a recipe preparation tool may, for example, provide syntax and/or parameter selection guidance, correct syntax errors automatically, and/or perform at least some level of pre-processing on the recipe text on the client side before the recipe (either in text form or binary form) is sent to the MLS service. The recipe may use a number of different transformation functions or methods defined in one or more libraries  1152 , such as functions to form Cartesian products of variables, n-grams (for text data), quantile bins (for numeric data variables), and the like. The libraries used for recipe validation may include third-party or client-provided functions or libraries in at least some embodiments, representing custom feature processing extensions that have been incorporated into the MLS to enhance the service&#39;s core or natively-supported feature processing capabilities. The recipe validator  1104  may also be responsible for verifying that the functions invoked in the text version  1101  are (a) among the supported functions of the library  1152  and (b) used with the appropriate signatures (e.g., that the input parameters of the functions match the types and sequences of the parameters specified in the library). In some embodiments, MLS customers may register additional functions as part of the library, e.g., so that custom “user-defined functions” (UDFs) can also be included in the recipes. Customers that wish to utilize UDFs may be required to provide an indication of a module that can be used to implement the UDFs (e.g., in the form of source code, executable code, or a reference to a third-party entity from which the source or executable versions of the module can be obtained by the MLS) in some embodiments. A number of different programming languages and/or execution environments may be supported for UDFs in some implementations, e.g., including Java™, Python, and the like. The text version of the recipe may be converted into an executable version  1107  in the depicted embodiment. The recipe validator  1104  may be considered analogous to a compiler for the recipe language, with the text version of the recipe analogous to source code and the executable version analogous to the compiled binary or byte code derived from the source code. The executable version may also be referred to as a feature processing plan in some embodiments. In the depicted embodiment, both the text version  1101  and the executable version  1107  of a recipe may be stored within the MLS artifact repository  120 . 
     A run-time recipe manager  1110  of the MLS may be responsible for the scheduling of recipe executions in some embodiments, e.g., in response to the equivalent of an “executeRecipe” API specifying an input data set. In the depicted embodiment, two execution requests  1171 A and  1171 B for the same recipe R 1  are shown, with respective input data sets IDS 1  and IDS 2 . The input data sets may comprise data records whose variables may include instances of any of a variety of data types, such as, for example text, a numeric data type (e.g., real or integer), Boolean, a binary data type, a categorical data type, an image processing data type, an audio processing data type, a video processing data type, a bioinformatics data type, a structured data type such as a particular data type compliant with the Unstructured Information Management Architecture (UIMA), and so on. In each case, the run-time recipe manager  1110  may retrieve (or generate) the executable version of R 1 , perform a set of run-time validations (e.g., to ensure that the requester is permitted to execute the recipe, that the input data appears to be in the correct or expected format, and so on), and eventually schedule the execution of the transformation operations of R 1  at respective resource sets  1175 A and  1175 B. In at least some cases, the specific libraries or functions to be used for the transformation may be selected based on the data types of the input records—e.g., instances of a particular structured data type may have to be handled using functions or methods of a corresponding library defined for that data type. Respective outputs  1185 A and  1185 B may be produced by the application of the recipe R 1  on IDS 1  and IDS 2  in the depicted embodiment. Depending on the details of the recipe R 1 , the outputs  1185 A may represent either data that is to be used as input for a model, or a result of a model (such as a prediction or evaluation). In at least some embodiments, a recipe may be applied asynchronously with respect to the execution request—e.g., as described earlier, a job object may be inserted into a job queue in response to the execution request, and the execution may be scheduled later. The execution of a recipe may be dependent on other jobs in some cases—e.g., upon the completion of jobs associated with input record handling (decryption, decompression, splitting of the data set into training and test sets, etc.). In some embodiments, the validation and/or compilation of a text recipe may also or instead be managed using asynchronously-scheduled jobs. 
     In some embodiments, a client request that specifies a recipe in text format and also includes a request to execute the recipe on a specified data set may be received—that is, the static analysis steps and the execution steps shown in  FIG. 11  may not necessarily require separate client requests. In at least some embodiments, a client may simply indicate an existing recipe to be executed on a data set, selected for example from a recipe collection exposed programmatically by the MLS, and may not even have to generate a text version of a recipe. In one embodiment, the recipe management components of the MLS may examine the set of input data variables, and/or the outputs of the transformations indicated in a recipe, automatically identify groups of variables or outputs that may have a higher predictive capability than others, and provide an indication of such groups to the client. 
       FIG. 12  illustrates example sections of a recipe, according to at least some embodiments. In the depicted embodiment, the text of a recipe  1200  may comprise four separate sections—a group definitions section  1201 , an assignments section  1204 , a dependencies section  1207 , and an output/destination section  1210 . In some implementations, only the output/destination section may be mandatory; in other implementations, other combinations of the sections may also or instead be mandatory. In at least one embodiment, if more than one of the four section types shown in  FIG. 12  is included in a recipe, the sections may have to be arranged in a specified order. In at least one embodiment, a destination model (i.e., a machine learning model to which the output of the recipe transformations is to be provided) may be indicated in a separate section than the output section. 
     In the group definitions section  1201 , as implied by the name, clients may define groups of input data variables, e.g., to make it easier to indicate further on in the recipe that the same transformation operation is to be applied to all the member variables of a group. In at least some embodiments, the recipe language may define a set of baseline groups, such as ALL_INPUT (comprising all the variables in the input data set), ALL_TEXT (all the text variables in the data set), ALL_NUMERIC (all integer and real valued variables in the data set), ALL_CATEGORICAL (all the categorical variables in the data set) and ALL_BOOLEAN (all the Boolean variables in the data set, e.g., variables that can only have the values “true” or “false” (which may be represented as “1” and “0” respectively in some implementations)). In some embodiments, the recipe language may allow users to change or “cast” the types of some variables when defining groups—e.g., variables that appear to comprise arbitrary text but are only expected to have only a discrete set of values, such as the names of the months of the year, the days of the week, or the states of a country, may be converted to categorical variables instead of being treated as generic text variables. Within the group definitions section, the methods/functions “group” and “group_remove” (or other similar functions representing set operations) may be used to combine or exclude variables when defining new groups. A given group definition may refer to another group definition in at least some embodiments. In the example section contents  1250  shown in  FIG. 12 , three groups are defined: LONGTEXT, SPECIAL_TEXT and BOOLCAT. LONGTEXT comprises all the text variables in the input data, except for variables called “title” and “subject”. SPECIAL_TEXT includes the text variables “subject” and “title”. BOOLCAT includes all the Boolean and categorical variables in the input data. It is noted that at least in some embodiments, the example group definitions shown may be applied to any data set, even if the data set does not contain a “subject” variable, a “title” variable, any Boolean variables, any categorical variables, or even any text variables. If there are no text variables in an input data set, for example, both LONGTEXT and SPECIAL_TEXT would be empty groups with no members with respect to that particular input data set in such an embodiment. 
     Intermediate variables that may be referenced in other sections of the recipe  1200  may be defined in the assignments section  1204 . In the example assignments section, a variable called “binage” is defined in terms of a “quantile_bin” function (which is assumed to be included among the pre-defined library functions of the recipe language in the depicted embodiment) applied to an “age” variable in the input data, with a bin count of “30”. A variable called “countrygender” is defined as a Cartesian product of two other variables “country” and “gender” of the input data set, with the “cartesian” function assumed to be part of the pre-defined library. In the dependencies section  1207 , a user may indicate other artifacts (such as the model referenced as “clustermodel” in the illustrated example, with the MLS artifact identifier “pr-23872-28347-alksdjf”) upon which the recipe depends. For example, in some cases, the output of a model that is referenced in the dependencies section of the recipe may be ingested as the input of the recipe, or a portion of the output of the referenced model may be included in the output of the recipe. The dependencies section may, for example, be used by the MLS job scheduler when scheduling recipe-based jobs in the depicted embodiment. Dependencies on any of a variety of artifacts may be indicated in a given recipe in different embodiments, including other recipes, aliases, statistics sets, and so on. 
     In the example output section  1210 , a number of transformations are applied to input data variables, groups of variables, intermediate variables defined in earlier sections of the recipe, or the output of an artifact identified in the dependencies section. The transformed data is provided as input to a different model identified as “model1”. A term-frequency-inverse document frequency (tfidf) statistic is obtained for the variables included in the LONGTEXT group, after punctuation is removed (via the “nopunct” function) and the text of the variables is converted to lowercase (by the “lowercase” function). The tfidf measure may be intended to reflect the relative importance of words within a document in a collection or corpus; the tfidf value for a given word typically is proportional to the number of occurrences of the word in a document, offset by the frequency of the word in the collection as a whole. The tfidf, nopunct and lowercase functions are all assumed to be defined in the recipe language&#39;s library. Similarly, other transformations indicated in the output section use the osb (orthogonal sparse bigrams) library function, the quantile_bin library function for binning or grouping numeric values, and the Cartesian product function. Some of the outputs indicated in section  1210  may not necessarily involve transformations per se: e.g., the BOOLCAT group&#39;s variables in the input data set may simply be included in the output, and the “clusterNum” output variable of “clustermodel” may be included without any change in the output of the recipe as well. 
     In at least some embodiments, the entries listed in the output section may be used to implicitly discard those input data variables that are not listed. Thus, for example, if the input data set includes a “taxable-income” numeric variable, it may simply be discarded in the illustrated example since it is not directly or indirectly referred to in the output section. The recipe syntax and section-by-section organization shown in  FIG. 12  may differ from those of other embodiments. A wide variety of functions and transformation types (at least some of which may differ from the specific examples shown in  FIG. 12 ) may be supported in different embodiments. For example, date/time related functions “dayofweek”, “hourofday” “month”, etc. may be supported in the recipe language in some embodiments. Mathematical functions such as “sqrt” (square root), “log” (logarithm) and the like may be supported in at least one embodiment. Functions to normalize numeric values (e.g., map values from a range {−N 1  to +N 2 } into a range {0 to 1}), or to fill in missing values (e.g., “replace_missing_with_mean(ALL_NUMERIC)”) may be supported in some embodiments. Multiple references within a single expression to one or more previously-defined group variables, intermediate variables, or dependencies may be allowed in one embodiment: e.g., the recipe fragment “replace_missing(ALL_NUMERIC, mean(ALL_NUMERIC))” may be considered valid. Mathematical expressions involving combinations of variables such as “‘income’+10*‘capital_gains’” may also be permitted within recipes in at least some embodiments. Comments may be indicated by delimiters such as “//” in some recipes. 
     Recipe Validation 
       FIG. 13  illustrates an example grammar that may be used to define acceptable recipe syntax, according to at least some embodiments. The grammar shown may be formatted in accordance with the requirements of a parser generator such as a version of ANTLR (ANother Tool for Language Recognition). As shown, the grammar  1320  defines rules for the syntax of expressions used within a recipe. Given a grammar similar to that shown in  FIG. 13 , a tools such as ANTLR may generate a parser than can build an abstract syntax tree from a text version of a recipe, and the abstract syntax tree may then be converted into a processing plan by the MLS control plane. An example tree generated using the grammar  1320  is shown in  FIG. 14 . 
     In the example grammar “MLS-Recipe” shown in  FIG. 13 , an expression “expr” can be one of a “BAREID”, a “QUOTEDID”, a “NUMBER” or a “functioncall”, with each of the latter four entities defined further down in the grammar. A BAREID starts with an upper case or lower case letter and can include numerals. A QUOTEDID can comprise any text within single quotes. NUMBERs comprise real numeric values with or without exponents, as well as integers. A functioncall must include a function name (a BAREID) followed by zero or more parameters within round brackets. Whitespace and comments are ignored when generating an abstract syntax tree in accordance with the grammar  1320 , as indicated by the lines ending in “-&gt;skip”. 
       FIG. 14  illustrates an example of an abstract syntax tree that may be generated for a portion of a recipe, according to at least some embodiments. The example recipe fragment  1410  comprising the text “cartesian(binage, quantile_bin(‘hours-per-week’, 10))” may be translated into abstract syntax tree  1420  in accordance with grammar  1320  (or some other similar grammar) in the depicted embodiment. As shown, “cartesian” and “quantile_bin” are recognized as function calls, each with two parameters. During the syntax analysis of the illustrated recipe fragment, recipe validator  1104  may ensure that the number and order of the parameters passed to “cartesian” and “quantile_bin” match the definitions of those functions, and that the variables “binage” and “hours_per_week” are defined within the recipe. If any of these conditions are not met, an error message indicating the line number within the recipe at which the “cartesian” fragment is located may be provided to the client that submitted the recipe. Assuming that no validation errors are found in the recipe as a whole, an executable version of the recipe may be generated, of which a portion  1430  may represent the fragment  1410 . 
     Domain-Specific Recipe Collections 
     In at least some embodiments, some users of the MLS may not be experts at feature processing, at least during a period when they start using the MLS. Accordingly, the MLS may provide users with access to a collection of recipes that have previously been found to be useful in various problem domains.  FIG. 15  illustrates an example of a programmatic interface that may be used to search for domain-specific recipes available from a machine learning service, according to at least some embodiments. As shown, a web page  1501  may be implemented for a recipe search, which includes a message area  1504  providing high-level guidance to MLS users, and a number of problem domains for which recipes are available. In the depicted example, a MLS customer can use a check-box to select from among the problem domains fraud detection  1507 , sentiment analysis  1509 , image analysis  1511 , genome analysis  1513 , or voice recognition  1515 . A user may also search for recipes associated with other problem domains using search term text block  1517  in the depicted web page. 
     For the selected problem domain (image analysis), links to five example recipes are shown on web page  1501 : recipes FR 1  and FR 2  for facial recognition, BTR 1  for brain tumor recognition, ODA 1  for ocean debris recognition, and AED 1  for astronomical event detection. Additional details regarding a given recipe may be obtained by the user by clicking on the recipe&#39;s name: for example, in some embodiments, a description of what the recipe does may be provided, ratings/rankings of the recipe submitted by other users may be provided, comments submitted by other users on the recipes, and so on. If a user finds a recipe that they wish to use (either unchanged or after modifying the recipe), they may be able to download the text version of the recipe, e.g., for inclusion in a subsequent MLS API invocation. As indicated in the message area  1504 , users may also be able to submit their own recipes for inclusion in the collection exposed by the MLS in the depicted embodiment. In at least some implementations, the MLS may perform some set of validation steps on a submitted recipe (e.g., by checking that the recipe produces meaningful output for various input data sets) before allowing other users access. 
     Automated Parameter Tuning for Recipe Transformations 
     For many types of feature processing transformation operations, such as creating quantile bins for numeric data attributes, generating ngrams, or removing sparse or infrequent words from documents being analyzed, parameters may typically have to be selected, such as the sizes/boundaries of the bins, the lengths of the ngrams, the removal criteria for sparse words, and so on. The values of such parameters (which may also be referred to as hyper-parameters in some environments) may have a significant impact on the predictions that are made using the recipe outputs. Instead of requiring MLS users to manually submit requests for each parameter setting or each combination of parameter settings, in some embodiments the MLS may support automated parameter exploration.  FIG. 16  illustrates an example of a machine learning service that automatically explores a range of parameter settings for recipe transformations on behalf of a client, and selects acceptable or recommended parameter settings based on results of such explorations, according to at least some embodiments. 
     In the depicted embodiment, an MLS client  164  may submit a recipe execution request  1601  that includes parameter auto-tune settings  1606 . For example, the client  164  may indicate that the bin sizes/boundaries for quantile binning of one or more variables in the input data should be chosen by the service, or that the number of words in an n-gram should be chosen by the service. Parameter exploration and/or auto-tuning may be requested for various clustering-related parameters in some embodiments, such as the number of clusters into which a given data set should be classified, the cluster boundary thresholds (e.g., how far apart two geographical locations can be to be considered part of a set of “nearby” locations), and so on. Various types of image processing parameter settings may be candidates for automated tuning in some embodiments, such as the extent to which a given image should be cropped, rotated, or scaled during feature processing. Automated parameter exploration may also be used for selection dimensionality values for a vector representation of a text document (e.g., in accordance with the Latent Dirichlet Allocation (LDA) technique) or other natural language processing techniques. In some cases, the client may also indicate the criteria to be used to terminate exploration of the parameter value space, e.g., to arrive at acceptable parameter values. In at least some embodiments, the client may be given the option of letting the MLS decide the acceptance criteria to be used—such an option may be particularly useful for non-expert users. In one implementation, the client may indicate limits on resources or execution time for parameter exploration. In at least one implementation, the default setting for an auto-tune setting for at least some output transformations may be “true”, e.g., a client may have to explicitly indicate that auto-tuning is not to be performed in order to prevent the MLS from exploring the parameter space for the transformations. 
     In response to a determination that auto-tuning is to be performed for a given transformation operation, the MLS (e.g., a parameter explorer  1642  of the recipe run-time manager  1640 ) may select a parameter tuning range  1654  for the transformation (e.g., whether the quantile bin counts of 10, 20, 30 and 40 should be explored for a particular numeric variable). The parameter ranges may be selected based on a variety of factors in different embodiments, including best practices known to the MLS for similar transformations, resource constraints, the size of the input data set, and so on. In scenarios in which respective parameters for combinations of several transformation operations are to be tuned (e.g., if quantile binning is being auto-tuned for more than one variable), the parameter explorer  1642  may select a respective set of values for each parameter so as to keep the number of combinations that are to be tried below a threshold. Having determined the range of parameter values, the parameter explorer may execute iterations of transformations for each parameter value or combination, storing the iteration results  1656  in at least some implementations in temporary storage. Based on the result sets generated for the different parameter values and the optimization criteria being used, at least one parameter value may be identified as acceptable for each parameter. In the depicted embodiment, a results notification  1667  may be provided to the client, indicating the accepted or recommended parameter value or values  1668  for the different parameters being auto-tuned. For some parameters, it may not always be straightforward to identify a particular parameter value as being the single best value, e.g., because several different values may lead to similar results. In some embodiments, instead of identifying a single optimal value for such a parameter, the MLS may instead identify a set of candidate values {V 1 , V 2 , V 3 , . . . , Vn} for a given parameter P, such that all the values of the set provide results of similar quality. The set of candidate values may be provided to the client, enabling the client to choose the specific parameter value to be used, and the client may notify the MLS regarding the selected parameter value. In one embodiment, the client may only be provided with an indication of the results of the recipe transformations obtained using the accepted/optimized parameter values, without necessarily being informed about the parameter value settings used. 
     Methods of Supporting Feature Processing Via Re-Usable Recipes 
       FIG. 17  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service that supports re-usable recipes for data set transformations, according to at least some embodiments. As shown in element  1701 , an indication of a text version of a recipe for transformation operations to be performed on input data sets may be received at a network-accessible MLS implemented at a provider network. In one embodiment, the recipe text may include one or more of four sections in accordance with a recipe language defined by the MLS: a group definitions section, an assignment section, a dependency section, and an output/destination section (which may also be referred to simply as the output section). In some embodiments, one or more sections (such as the output section) may be mandatory. In general, the output/destination section may indicate various feature processing transformation operations that are to be performed on entities defined in other sections of the recipe, or directly on input variables of a data set. The group definitions section may be used to define custom groups of input variables (or input data variables combined with other groups, or groups derived from other groups). Such group definitions may make it easier to specify in the output section that a common transformation is to be applied to several variables. A number of built-in or predefined groups may be supported by the recipe language in some embodiments, such as ALL_NUMERIC or ALL_CATEGORICAL, along with functions such as “group_remove” and “group” to allow recipe creators to easily indicate variable exclusions and combinations to be used when defining new groups. The assignment section may be used to define one or more intermediate variables that can be used elsewhere in the recipe. The dependency section may indicate that the recipe depends on another machine learning artifact (such as a model, or another recipe) or on multiple other artifacts stored in an MLS&#39;s repository. In some embodiments, the output section may indicate not just the specific transformations to be applied to specified input variables, defined groups, intermediate variables or output of the artifacts indicated in the dependency section, but also the destination models to which the transformation results are to be provided as input. 
     The machine learning service may natively support libraries comprising a variety of different transformation operations that can be used in the recipe&#39;s output section, such as the types of functions illustrated in  FIG. 12 . In some embodiments, several different libraries, each corresponding to a given problem domain or to a respective class of machine learning algorithm, may be supported by the MLS. In addition, in one embodiment MLS customers may be able to register their own custom functions (called “user-defined functions” or UDFs), third-party functions, or libraries comprising multiple UDFs or third-party functions with the MLS to extend the core feature processing capabilities of the MLS. UDFs may be provided to the MLS by clients in a variety of different formats (e.g., including one or more text formats and/or one or more binary formats) in some embodiments. A number of different programming or scripting languages may be supported for UDFs in such embodiments. An API for registering externally-produced transformation functions or libraries with the MLS may be supported in some embodiments, e.g., enabling a client to indicate whether the newly-registered functions are to be made accessible to other clients or restricted for use by the submitting client. In one implementation, a recipe may comprise an import section in which one or more libraries (e.g., libraries other than a core or standard library of the MLS) whose functions are used in the recipe may be listed. In some implementations, the MLS may impose resource usage restrictions on at least some UDFs—e.g., to prevent runaway consumption of CPU time, memory, disk space and the like, a maximum limit may be set on the time that a given UDF can run. In this way, the negative consequences of executing potentially error-prone UDFs (e.g., a UDF whose logic comprises an infinite loop under certain conditions) may be limited. In at least some embodiments, the recipe text (or a file or URL from which the recipe text can be read) may be passed as a parameter in an API (such as a “createRecipe” API) invoked by an MLS client. 
     The recipe text may be validated at the MLS, e.g., in accordance with a set of syntax rules of a grammar and a set of libraries that define supported transformation methods or functions (element  1704 ). If syntax errors or unresolvable tokens are identified during the text validation checks, in at least some embodiments error messages that indicate the portion of the text that needs to be corrected (e.g., by indicating the line number and/or the error-inducing tokens) may be provided to the recipe submitter. If no errors are found, or after the errors found are corrected and the recipe is re-submitted, an executable version of the recipe text may be generated (element  1707 ). One or both versions of the recipe (the text version and the executable version) may be stored in an artifact repository of the MLS in the depicted embodiment, e.g., with a unique recipe identifier generated by the MLS being provided to the recipe submitter. 
     The MLS may determine, e.g., in response to a different API invocation or because the initial submission of the recipe included an execution request, that the recipe is to be applied to a particular data set (element  1710 ). The data set may be checked to ensure that it meets run-time acceptance criteria, e.g., that the input variable names and data types match those indicated in the recipe, and that the data set is of an acceptable size (element  1713 ). A set of provider network resources (e.g., one or more compute servers, configured with appropriate amounts of storage and/or network capacity as determined by the MLS) may be identified for the recipe execution (element  1716 ). The transformations indicated in the recipe may then be applied to the input data set (element  1719 ). In some embodiments, as described above with respect to  FIG. 16 , the MLS may perform parameter explorations in an effort to identify acceptable parameter values for one or more of the transformations. After the recipe transformations are completed (and/or the results of the transformations are provided to the appropriate destinations, such as a model specified in the recipe itself), a notification that the recipe&#39;s execution is complete may be provided to the client that requested the execution (element  1722 ) in the depicted embodiment. 
     I/O-Efficient Input Data Filtering Sequences 
     As mentioned earlier, some machine learning input data sets can be much larger (e.g., on the order of terabytes) than the amount of memory that may be available at any given server of a machine learning service. In order to train and evaluate a model, a number of filtering or input record rearrangement operations may sometimes have to be performed in a sequence on an input data set. For example, for cross-validating a classification model, the same input data set may have to be split into training and test data sets multiple times, and such split operations may be considered one example of input filtering. Other input filtering operation types may include sampling (obtaining a subset of the data set), shuffling (rearranging the order of the input data objects), or partitioning for parallelism (e.g., dividing a data set into N subsets for a computation implemented using map-reduce or a similar parallel computing paradigm, or for performing multiple parallel training operations for a model). If a data set that takes up several terabytes of space were to be read from and/or written to persistent storage for each filtering operation (such as successive shuffles or splits), the time taken for just the I/O operations alone may become prohibitive, especially if a large fraction of the I/O comprised random reads of individual observation records of the input data set from rotating disk-based storage devices. Accordingly, in some embodiments, a technique of mapping large data sets into smaller contiguous chunks that are read once into some number of servers&#39; memories, and then performing sequences of chunk-level filtering operations in place without copying the data set to persistent storage between successive filtering operations may be implemented at a machine learning service. In at least one such embodiment, an I/O library may be implemented by the machine learning service, enabling a client to specify, via a single invocation of a data-source-agnostic API, a variety of input filtering operations to be performed on a specified data set. Such a library may be especially useful in scenarios in which the input data sets comprise varying-length observation records stored in files within file system directories rather than in structured database objects such as tables, although the chunking and in-memory filtering technique described below may in general be performed for any of a variety of data source types (including databases) as described below. The I/O library may allow clients to indicate data sources of various types (e.g., single-host file systems, distributed file systems, storage services of implemented at a provider network, non-relational databases, relational databases, and so on), and may be considered data-source-agnostic in that the same types of filtering operations may be supported regardless of the type of data source being used. In some cases, respective subsets of a given input data set may be stored in different types of data sources. 
       FIG. 18  illustrates an example procedure for performing efficient in-memory filtering operations on a large input data set by a machine learning service (MLS), according to at least some embodiments. As shown, a data source  1802  from which a client of the machine learning service wishes to extract observation records may comprise a plurality of data objects such as files F 1 , F 2 , F 3  and F 4  in the depicted embodiment. The sizes of the files may differ, and/or the number of observation records in any given file may differ from the number of observation records in other files. As used herein, the term “observation record” may be used synonymously with the term “data record” when referring to input data for machine learning operations. A data record extraction request submitted by the client may indicate the data source  1802 , e.g., by referring to locations (e.g., a directory name or a set of URLs) of files F 1 , F 2 , F 3  and F 4 . In response to the extraction request, the MLS may ascertain or estimate the size of the data set as a whole (e.g., the combined size of the files) in the depicted embodiment, and determine an order in which the files should be logically concatenated to form a unified address space. In the example shown, data set  1804  may be generated, for example, by logically concatenating the files in the order F 1 , F 2 , F 3  and F 4 . In some embodiments, the client&#39;s data record extraction request may specify the order in which the files of a multi-file data set are to be combined (at least initially), and/or the sizes of the files. In other embodiments, the MLS may determine the concatenation order (e.g., based on any combination of various factors such as lexical ordering of the file names, the sizes of the files, and so on). It is noted that although files are used as an example of the data objects in which observation records are stored in  FIG. 18  and some subsequent figures, similar techniques for input filtering may be used regardless of the type of the data objects used (e.g., volumes providing a block-level interface, database records, etc.) in various embodiments. 
     The concatenated address space of data set  1804  may then be sub-divided into a plurality of contiguous chunks, as indicated in chunk mapping  1806 . The size of a chunk (Cs) may be determined based on any of several factors in different embodiments. For example, in one embodiment, the chunk size may be set such that each chunk can fit into the memory of an MLS server (e.g., a server of pools  185  of  FIG. 1 ) at which at least a portion of the response to the client&#39;s data record extraction request is to be generated. Consider a simple scenario in which the memory portions available for the data records at each of several MLS servers is Sm. In such a scenario, a chunk size Cs such that Cs is less than or equal to Sm may be selected, as shown in  FIG. 18 . In other embodiments, the client request may indicate a chunk sizing preference, or the MLS may define a default chunk size to be used even if different servers have different amounts of memory available for the data records. In some embodiments, the chunk size to be used for responding to one record extraction request may differ from that used for another record extraction request; in other embodiments, the same chunk size may be used for a plurality of requests, or for all requests. The sub-division of the concatenated data set  1804  into contiguous chunks (rather than, for example, randomly selected sub-portions) may increase the fraction of the data set that can be read in via more efficient sequential reads than the fraction that has to be read via random reads, as illustrated below with respect to  FIG. 19 . In some embodiments, different chunks of a given chunk mapping may have different sizes—e.g., chunk sizes need not necessarily be identical for all the chunks of a given data set. It is noted that the initial sub-division of the data set into chunks represents a logical operation that may be performed prior to physical I/O operations on the data set. 
     In the depicted embodiment, an initial set of candidate chunk boundaries  1808  may be determined, e.g., based on the chunk sizes being used. As shown, candidate chunk boundaries need not be aligned with file boundaries in at least some embodiments. The candidate chunk boundaries may have to be modified somewhat to align chunk boundaries with observation record boundaries in at least some embodiments when the chunks are eventually read, as described below in greater detail with reference to  FIG. 22 . A chunk-level filtering plan  1850  may be generated for the chunked data set  1810  in some embodiments, e.g., based on contents of a filtering descriptor (which may also be referred to as a retrieval descriptor) included in the client&#39;s request. The chunk-level filtering plan may indicate, for example, the sequence in which a plurality of in-memory filtering operations  1870  (e.g.,  1870 A,  1870 B and  1870 N) such as shuffles, splits, samples, or partitioning for parallel computations such as map reduce are to be performed on the chunks of the input data. In some embodiments the machine learning model may support parallelized training of models, in which for example respective (and potentially partially overlapping) subsets of an input data set may be used to train a given model in parallel. The duration of one training operation may overlap at least partly with the duration of another in such a scenario, and the input data set may be partitioned for the parallel training sessions using a chunk-level filtering operation. A chunk-level shuffle, for example, may involve rearranging the relative order of the chunks, without necessarily rearranging the relative order of observation records within a given chunk. Examples of various types of chunk-level filtering operations are described below. 
     In at least some embodiments, the client may not necessarily be aware that at least some of the filtering operations will be performed on chunks of the data set rather than at the granularity of individual data records. In the depicted embodiment, data transfers  1814  of the contents of the chunks (e.g., the observation records respectively included within C 1 , C 2 , C 3  and C 4 ) may be performed to load the data set into the memories of one or more MLS servers in accordance with the first filtering operation of the sequence. To implement the first in-memory filtering operation of the sequence, for example, a set of reads directed to one or more persistent storage devices at which least some of the chunks are stored may be executed. De-compression and/or decryption may also be required in some embodiments, e.g., prior to one or more operations of the sequence of filtering operations  1870 . For example, if the data is stored in compressed form at the persistent storage devices, it may be de-compressed in accordance with de-compression instructions/metadata provided by the client or determined by the MLS. Similarly, if the source data is encrypted, the MLS may decrypt the data (e.g., using keys or credentials provided or indicated by the client). 
     After the set of reads (and/or the set of associated de-compression/decryption operations) is completed, at least a subset of the chunks C 1 -C 4  may be present in MLS server memories. (If the first filtering operation of the sequence involves generating a sample, for example, not all the chunks may even have to be read in.) The remaining filtering operations of plan  1850  may be performed in place in the MLS server memories, e.g., without copying the contents of any of the chunks to persistent storage in the depicted embodiment, and/or without re-reading the content of any of the chunks from the source data location. For example, the in-memory results of the first filtering operation may serve as the input data set for the second filtering operation, the in-memory results of the second filtering operation may serve as the input data set for the third filtering operation, and so on. In the depicted embodiment, the final output of the sequence of filtering operations may be used as input for record parsing  1818  (i.e., determining the content of various variables of the observation records). The observation records  1880  generated as a result of parsing may then be provided as input to one or more destinations, e.g., to model(s)  1884  and/or feature processing recipe(s)  1882 . Thus, in the depicted embodiment, only a single pass of physical read operations may be required to implement numerous different filtering operations, which may result in a substantial input processing speedup compared to scenarios in which the data set is copied to persistent storage (or re-read) for each successive filtering operation. Of course, although multiple chunk-level and/or observation-record-level operations may be performed in memory without accessing persistent storage, the results of any such operation may be stored to persistent storage if necessary, e.g., so that the results may be re-used later for another job. Thus, although avoiding frequent and potentially time-consuming I/O operations to disk-based or other persistent storage devices is made easier by the technique described above, I/O to persistent storage may still be performed at any stage as and when necessary based on an application&#39;s requirements. 
     By performing filtering operations such as shuffling or sampling at the chunk level as described above, random physical read operations directed to individual data records may be avoided. Consider a scenario in which the input data set is to be shuffled (e.g., to cross-validate a classification model), the shuffling is performed at the chunk level with a chunk size of one megabyte, the data records of the data set have an average size of one kilobyte, and neither de-compression nor decryption is required. If the original data set was 1000 megabytes in size, in any given iteration of random shuffling, the order in which 1000 chunks are logically arranged may be changed. However, the order of the data records within any given chunk would not change in a chunk-level shuffle operation. As a result, all the data records that lie within a particular chunk (e.g., Chunk654 out of the 1000 chunks) would be provided as a group to train a model using the results of the shuffling. If the records within Chunk654 are not randomly distributed with respect to an independent variable V 1  of interest, the chunk-level shuffle may not end up being as good with respect to randomizing the values of V 1  for training purposes as, for example, a record-level shuffle would have been. Thus, at least in some scenarios there may be some loss of statistical quality or predictive accuracy as a result of performing filtering at the chunk level rather than the data record level. However, in general the loss of quality/accuracy may be kept within reasonable bounds by choosing chunk sizes appropriately.  FIG. 19  illustrates tradeoffs associated with varying the chunk size used for filtering operation sequences on machine learning data sets, according to at least some embodiments. 
     Read operations corresponding to two example chunk mappings are shown for a given data set DS 1  in  FIG. 19 . To simplify the presentation, data set DS 1  is assumed to be stored on a single disk, such that a disk read head has to be positioned at a specified offset in order to start a read operation (either a random read or a set of sequential reads) on DS 1 . In chunk mapping  1904 A, a chunk size of S 1  is used, and DS 1  is consequently subdivided into four contiguous chunks starting at offsets O 1 , O 2 , O 3  and O 4  within the data set address space. (It is noted that the number of chunks in the example mappings shown in  FIG. 19  and in subsequent figures has been kept trivially small to illustrate the concepts being described; in practice, a data set may comprise hundreds or thousands of chunks.) In order to read the four chunks, a total of (at least) four read head positioning operations (RHPs) would have to be performed. After positioning a disk read head at offset O 1 , for example, the first chunk comprising the contents of DS 1  with offsets between O 1  and O 2  may be read in sequentially. This sequential read (SR 1 ) or set of sequential reads may typically be fast relative to random reads, because the disk read head may not have to be repositioned during the sequential reads, and disk read head positioning (also known as “seeking”) may often take several milliseconds, which may be of the same order of magnitude as the time taken to sequentially read several megabytes of data. Thus, with the chunk size of S 1 , reading the entire data set DS 1  as mapped to four chunks may involve a read operations mix  1910 A that includes four slow RHPs (RHP 1 -RHP 4 ) and four fast sequential reads (SR 1 -SR 4 ). 
     Instead of using a chunk size of S, if a chunk size of 2S (twice the size used for mapping  1904 A) were used, as in mapping  1904 B, only two RHPs would be required (one to offset O 1  and one to offset O 3 ) as indicated in read operations mix  1910 B, and the data set could be read in via two sequential read sequences SR 1  and SR 2 . Thus, the number of slow operations required to read DS 1  would be reduced in inverse proportion to the chunk size used. On the X-axis of tradeoff graph  1990 , chunk size increases from left to right, and on the Y-axis, the change in various metrics that results from the chunk size change is illustrated. In general, increasing the chunk size would tend to decrease the total read time (TRT) for transferring large data sets into memory. Even if the reads of different chunks could be performed in parallel, increasing the fraction of the data that is read sequentially would in general tend to decrease total read time. Increasing the chunk size may in general require more memory at the MLS servers to hold the chunk contents, as indicated by the per-server memory requirement (MR) curve shown in graph  1990 . Finally, as discussed above, for at least some types of machine learning problems, increased chunk sizes may lead to a slightly worse quality of statistics (QS) or slightly worse predictive accuracy of machine learning models. This may occur because the records within a given chunk may not be filtered with respect to records in the entire data set (or with respect to each other) in the same way that the chunks are filtered with respect to each other. In scenarios in which the MLS is able to select a chunk size, therefore, the tradeoffs illustrated in graph  1990  between total read time, memory requirements and statistical quality may have to be considered. In practice, depending on the size of the chunks relative to the entire data set, the loss of statistical quality resulting from using larger chunks may be fairly small. In at least some embodiments, there need not be a 1:1 relationship between chunks and MLS servers—e.g., a given MLS server may be configurable to store multiple chunks of a data set. In some embodiments, partial chunks or subsets of chunks may also be stored at an MLS server—e.g., the number of chunks stored in a given server&#39;s memory need not be an integer. In various embodiments, in addition to chunk-level filtering operations, intra-chunk and/or cross-chunk filtering operations (e.g., at the observation record level) may be performed as described below in further detail, which may help to further reduce the loss of statistical quality. It is noted that the curves shown in graph  1990  are intended to illustrate broad qualitative relationships, not exact mathematical relationships. The rate at which the different metrics change with respect to chunk size may differ from that shown in the graph, and the actual relationships may not necessarily be representable by smooth curves or lines as shown. 
       FIG. 20 a    illustrates an example sequence of chunk-level filtering operations, including a shuffle followed by a split, according to at least some embodiments. As shown, a chunked data set  2010  comprises ten chunks C 1 -C 10 . A detailed view of chunk C 1  at the top of  FIG. 20 a    shows its constituent observation records OR 1 - 1  through OR 1 - n , with successive observation records being separated by delimiters  2004 . As shown, the observation records of a data set or a chunk need not be of the same size. In a chunk-level shuffle operation  2015 , which may be one of the in-memory chunk-level filtering operations of a plan  1850 , the chunks are re-ordered. After the shuffle, the chunk order may be C 5 -C 2 -C 7 -C 9 -C 10 -C 6 -C 8 -C 3 -C 1 -C 4 . In a subsequent chunk-level split operation  2020 , 70% of the chunks (e.g., C 5 -C 2 -C 7 -C 9 -C 10 -C 6 -C 8 ) may be placed in training set  2022 , while 30% of the chunks (C 3 -C 1 -C 4 ) may be placed in a test set  2024  in the depicted example. As the shuffle was performed at the chunk level, the internal ordering of the observation records within a given chunk remains unchanged in the depicted example. Thus, the observation records of chunk C 1  are in the same relative order (OR 1 - 1 , OR 1 - 2 , . . . , OR 1 - n ) after the shuffle and split as they were before the shuffle and split filtering operations were performed. It is noted that for at least some types of filtering operations, in addition to avoiding copies to persistent storage, the chunk contents may not even have to be moved from one memory location to another in the depicted embodiment. For example, instead of physically re-ordering the chunks from C 1 -C 2 -C 3 -C 4 -C 5 -C 6 -C 7 -C 8 -C 9 -C 10  to C 5 -C 2 -C 7 -C 9 -C 10 -C 6 -C 8 -C 3 -C 1 -C 4  during the shuffle, pointers to the chunks may be modified, such that the pointer that indicates the first chunk points to C 5  instead of C 1  after the shuffle, and so on. 
     In some embodiments, as mentioned earlier, filtering at the observation record level may also be supported by the MLS. For example, a client&#39;s record extraction request may comprise descriptors for both chunk-level filtering and record-level filtering.  FIG. 20 b    illustrates an example sequence of in-memory filtering operations that includes chunk-level filtering as well as intra-chunk filtering, according to at least some embodiments. In the depicted example, the same set of chunk-level filtering operations are performed as those illustrated in  FIG. 20 a   —i.e., a chunk-level shuffle  2015  is performed on data set  2004 , followed by a 70-30 split  2020  into training set  2022  and test set  2024 . However, after the chunk-level split, an intra-chunk shuffle  2040  is also performed, resulting in the re-arrangement of the observation records within some or all of the chunks. As a result of the intra-chunk shuffle, the observation records of chunk C 1  may be provided as input in the order OR 1 - 5 , OR 1 - n , OR 1 - 4 , OR 1 - 1 , OR 1 - 2 , . . . , to a model or feature processing recipe (or to a subsequent filtering operation), for example, which differs from the original order of the observation records prior to the chunk-level shuffle. Observation records of the other chunks (e.g., C 2 -C 10 ), which are not shown in  FIG. 20 a    or  FIG. 20 b   , may also be shuffled in a similar manner in accordance with the client&#39;s filtering descriptor. In at least one embodiment, cross-chunk record-level filtering operations may also be supported. For example, consider a scenario in which at least two chunks Cj and Ck are read into the memory of a given MLS server S 1 . In a cross-chunk shuffle, at least some of the observation records of Cj may be shuffled or re-ordered with some of the observation records of Ck in S 1 &#39;s memory. Other types of record-level filtering operations (e.g., sampling, splitting, or partitioning) may also be performed across chunks that are co-located in a given server&#39;s memory in such embodiments. In one implementation, multiple servers may cooperate with one another to perform cross-chunk operations. For some applications, only a single chunk-level filtering operation may be performed before the result set of the chunk-level operation is fed to a recipe for feature processing or to a model for training—that is, a sequence of multiple chunk-level operations may not be required. Other types of operations (such as aggregation/collection of observation records or applying aggregation functions to values of selected variables of observation records) may also be performed subsequent to one or more chunk-level operations in at least some embodiments. 
     The ability to perform filtering operations at either the chunk level or the observation record level may enable several different alternatives to achieving the same input filtering goal.  FIG. 21  illustrates examples of alternative approaches to in-memory sampling of a data set, according to at least some embodiments. A 60% sample of a chunked data set  2110  comprising ten chunks C 1 -C 10  is to be obtained—that is, approximately 60% of the observation records of the data set are to be retained, while approximately 40% of the observation records are to be excluded from the output of the sampling operation. 
     In a first approach, indicated by the arrow labeled “1”, straightforward chunk-level sampling  2112  of the chunks may be implemented, e.g., resulting in the selection of chunks C 1 , C 2 , C 4 , C 6 , C 8  and C 10  as the desired sample. In a second approach, a combination of chunk-level and intra-chunk sampling may be used. For example, as indicated by the arrow labeled “2”, in a first step, 80% of the chunks may be selected (resulting in the retention of chunks C 1 , C 2 , C 3 , C 5 , C 6 , C 7 , C 8  and C 9 ) using chunk-level sampling  2114 . Next, in an intra-chunk sampling step  2116 , 75% of the observation records of each of the retained chunks may be selected, resulting in a final output of approximately 60% of the observation records (since 75% of 80% is 60%). In a third alternative approach indicated by the arrow labeled “3”, 60% of each chunk&#39;s observation records may be sampled in a single intra-chunk sampling step  2118 . Similar alternatives and combinations for achieving a given input filtering goal may also be supported for other types of filtering operations in at least some embodiments. 
     In at least some embodiments, candidate chunk boundaries may have to be adjusted in order to ensure that individual observation records are not split, and to ensure consistency in the manner that observation records are assigned to chunks  FIG. 22  illustrates examples of determining chunk boundaries based on the location of observation record boundaries, according to at least some embodiments. Data set  2202 A comprises observation records OR 1 -OR 7  (which may vary in size) separated by record delimiters such as delimiter  2265 . For example, in one implementation in which the data source includes alphanumeric or text files, newline characters (“\n”) or other special characters may be used as record delimiters. Based on a selected chunk size, the candidate chunk boundaries happen to fall within the bodies of the observation records in data set  2202 A. Candidate chunk boundary (CCB)  2204 A falls within observation record OR 2  in the depicted example, CCB  2204 B falls within OR 4 , and CCB  2204 C falls within OR 6 . In the depicted embodiment, the following approach may be used to identify the actual chunk boundaries (ACBs). Starting at the offset immediately after the CCB for a given chunk&#39;s ending boundary, and examining the data set in increasing offset order (e.g., in a sequential scan or read), the first observation record delimiter found is selected as the ending ACB for the chunk. Thus, in the example of data set  2202 A, the position of the delimiter between OR 2  and OR 3  is identified as the actual chunk boundary  2214 A corresponding to CCB  2204 A. Similarly, ACB  2214 B corresponds to the delimiter between OR 4  and ORS, and ACB  2214 C corresponds to the delimiter between OR 6  and OR 7 . As a result of the selection of the actual chunk boundaries, as shown in chunk table  2252 A, chunk C 1  comprises OR 1  and OR 2 , chunk C 2  comprises OR 3  and OR 4 , and chunk C 3  comprises ORS and OR 6 , while chunk C 4  comprises OR 7 . Using the technique described, each observation record is mapped to one and only one chunk. 
     The same rules regarding the determination of chunk boundaries may be applied even if a CCB happens to coincide with an OR delimiter in some embodiments. For example, in data set  2202 B, CCB  2204 K happens to be aligned with the delimiter separating OR 2  and OR 3 , CCB  2204 L coincides with the delimiter separating OR 4  and ORS, while CCB  2204 M coincides with the delimiter separating OR 6  and OR 7 . Using the rule mentioned above, in each case the search for the next delimiter starts at the offset immediately following the CCB, and the next delimiter found is selected as the ACB. Accordingly, ACB  2214 K is positioned at the delimiter between OR 3  and OR 4 , ACB  2214 L is positioned at the delimiter between OR 5  and OR 6 , and ACB  2214 M is positioned at the delimiter between OR 7  and OR 8 . As indicated in chunk table  2252 B, chunk C 1  of data set  2202 B eventually includes OR 1 , OR 2  and OR 3 , chunk C 2  includes OR 4  and ORS, chunk C 3  includes OR 6  and OR 7 , and chunk C 4  includes OR 8 . 
       FIG. 23  illustrates examples of jobs that may be scheduled at a machine learning service in response to a request for extraction of data records from any of a variety of data source types, according to at least some embodiments. As shown, a set of programming interfaces  2361  enabling clients  164  to submit observation record extraction/retrieval requests  2310  in a data-source-agnostic manner may be implemented by the machine learning service. Several different types  2310  of data sources may be supported by the MLS, such as an object storage service  2302  that may present a web-services interface to data objects, a block storage service  2304  that implements volumes presenting a block-device interface, any of a variety of distributed file systems  2306  (such as the Hadoop Distributed File System or HDFS), as well as single-host file systems  2308  (such as variants of Ext3 that may be supported by Linux-based operating systems). In at least some embodiments, databases (e.g., relational databases or non-relational databases) may also be supported data sources. Data objects (e.g., files) that are implemented using any of the supported types of data sources may be referred to in the retrieval requests, as indicated by the arrows labeled  2352 A and  2352 B. In some implementations, a single client request may refer to input data objects such as files that are located in several different types of data sources, and/or in several different instances of one or more data source types. For example, different subsets of a given input data set may comprise files located at two different single-host file systems  2308 , while respective subsets of another input data set may be located at an object storage service and the block-storage service. 
     An MLS request handler  180  may receive a record extraction request  2310  indicating a sequence of filtering operations that are to be performed on a specified data set located at one or more data sources, such as some combination of shuffling, splitting, sampling, partitioning (e.g., for parallel computations such as map-reduce computations, or for model training operations/sessions that overlap with each other in time and may overlap with each other in the training sets used), and the like. A filtering plan generator  2380  may generate a chunk mapping of the specified data set, and a plurality of jobs to accomplish the requested sequence of filtering operations (either at the chunk level, the record level, or both levels) in the depicted embodiment, and insert the jobs in one or more MLS job queues  142 . For example, one or more chunk read jobs  2311  may be generated to read in the data from the data source. If needed, separate jobs may be created to de-compress the chunks (such as jobs  2312 ) and/or decrypt the data (jobs  2313 ). In the depicted embodiment, jobs  2314  may be generated for chunk-level filtering operations, while jobs  2315  may be generated for observation record-level filtering operations. Filtering operations at the observation record level may comprise intra-chunk operations (e.g., shuffles of records within a given chunk) and/or cross-chunk operations (e.g., shuffles of records of two or more different chunks that may be co-located in the memory of a given MLS server) in the depicted embodiment. In at least some embodiments, respective jobs may be created for each type of operation for each chunk—thus, for example, if the chunk mapping results in 100 chunks, 100 jobs may be created for reading in one chunk respectively, 100 jobs may be created for the first chunk-level filtering operation, and so on. In other embodiments, a given job may be created for an operation involving multiple chunks, e.g., a separate job may not be required for each chunk. In some embodiments, as described below in further detail, the splitting of a data set into a training set and a test set may be implemented as separate jobs—one for the training set and one for the test set. As discussed earlier, a given job may indicate dependencies on other jobs, and such dependencies may be used to ensure that the filtering tasks requested by the client are performed in the correct order. 
       FIG. 24  illustrates examples constituent elements of a record extraction request that may be submitted by a client using a programmatic interface of an I/O (input-output) library implemented by a machine learning service, according to at least some embodiments. As shown, observation record (OR) extraction request  2401  may include a source data set indicator  2402  specifying the location(s) or address(es) from which the input data set is to be retrieved. For a data set stored in an object storage service presenting a web-service interface, for example, one or more URLs (uniform resource locators) or URIs (uniform resource identifiers) may be specified; for files, some combination of one or more file server host names, one or more directory names, and/or one or more file names may be provided as the indicator  2402 . In one implementation, if a data set includes multiple objects such as more than one file, a client may include instructions for logical concatenation of the objects of the data set to form a unified address space (e.g., the logical equivalent of “combine files of directory d 1  in alphabetical order by file name, then files of directory d 2  in alphabetical order”). In some embodiments, an expected format  2404  or schema for the observation records may be included in the OR extraction request, e.g., indicating the names of the variables or fields of the ORs, the inter-variable delimiters (e.g., commas, colons, semicolons, tabs, or other characters) and the OR delimiters, the data types of the variables, and so on. In at least one implementation, the MLS may assign default data types (e.g., “string” or “character”) to variables for which data types are not indicated by the client. 
     In one embodiment, the OR extraction request  2401  may include compression metadata  2406 , indicating for example the compression algorithm used for the data set, the sizes of the units or blocks in which the compressed data is stored (which may differ from the sizes of the chunks on which chunk-level in-memory filtering operations are to be performed), and other information that may be necessary to correctly de-compress the data set. Decryption metadata  2408  such as keys, credentials, and/or an indication of the encryption algorithm used on the data set may be included in a request  2401  in some embodiments. Authorization/authentication metadata  2410  to be used to be able to obtain read access to the data set may be provided by the client in request  2401  in some implementations and for certain types of data sources. Such metadata may include, for example, an account name or user name and a corresponding set of credentials, or an identifier and password for a security container (similar to the security containers  390  shown in  FIG. 3 ). 
     OR extraction request  2401  may include one or more filtering descriptors  2412  in the depicted embodiment, indicating for example the types of filtering operations (shuffle, split, sample, etc.) that are to be performed at the chunk level and/or at the OR level, and the order in which the filtering operations are to be implemented. In some implementations, one or more descriptors  2452  may be included for chunk-level filtering operations, and one or more descriptors  2454  may be included for record-level (e.g., intra-chunk and/or cross-chunk) filtering operations. Each such descriptor may indicate parameters for the corresponding filtering operation—e.g., the split ratio for split operations, the sampling ratio for sampling operations, the number of partitions into which the data set is to be subdivided for parallel computations or parallel training sessions, the actions to be taken if a record&#39;s schema is found invalid, and so on. 
     In at least one embodiment, the OR extraction request  2401  may include chunking preferences  2414  indicating, for example, a particular acceptable chunk size or a range of acceptable chunk sizes. The destination(s) to which the output of the filtering operation sequence is to be directed (e.g., a feature processing recipe or a model) may be indicated in field  2416 . In some embodiments, a client may indicate performance goals  2418  for the filtering operations, such as a “complete-by” time, which may be used by the MLS to select the types of servers to be used, or to generate a filtering sequence plan that is intended to achieve the desired goals. It is noted that in at least some embodiments, not all of the constituent elements shown in  FIG. 25  may be included within a record extraction request—for example, the compression and/or decryption related fields may only be included for data sets that are stored in a compressed and/or encrypted form. 
       FIG. 25  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service that implements an I/O library for in-memory filtering operation sequences on large input data sets, according to at least some embodiments. An I/O library that enables clients to submit observation record extraction requests similar to those illustrated in  FIG. 24  may be implemented. The I/O library may be agnostic with respect to the type of data store at which the input data set is stored—e.g., a common set of programmatic interfaces may be provided for record extraction requests stored at any combination of several different data store types. Such an OR extraction request may be received (element  2501 ), indicating a source data set that may be too large to fit into the available memory of an MLS server. The OR extraction request may include one or more descriptors indicating a sequence of filtering operations that are to be performed on the input data set. 
     A chunk size to be used for transferring contiguous subsets of the input data set into the memories of one or more MLS servers may be determined (element  2504 ), e.g., based on any of various factors such as the memory capacity constraints of the MLS servers, a preference indicated by the requesting client via parameters of the request, a default setting of the MLS, the estimated or actual size of the input data set, and so on. In some implementations several different chunk sizes may be selected—e.g., some MLS servers may have a higher memory capacity than others, so the chunks for the servers with more memory may be larger. If the input data set includes multiple objects (such as files), the objects may be logically concatenated to form a single unified address space (element  2507 ) in some embodiments. The sequence in which the objects are concatenated may be determined, for example, based on instructions or guidance provided in the request, based on alphanumeric ordering of the object names, in order of file size, in random order, or in some other order selected by the MLS. 
     A chunk mapping may be generated for the data set (element  2510 ), indicating a set of candidate chunk boundaries based on the selected chunk size(s) and the unified address space. The positions or offsets of the candidate chunk boundaries within the data object or object of the input data set may be computed as part of the mapping generation process. A plan for a sequence of chunk-level filtering operations corresponding to the filtering descriptor(s) in the OR extraction request may be created (element  2513 ). The plan may include record-level filtering operations (e.g., intra-chunk or cross-chunk operations), in addition to or instead of chunk-level filtering operations, in some embodiments. Cross-chunk operations may, for example, be performed on observation records of several chunks that are co-located in the memory of a given MLS server in some embodiments. In other embodiments, cross-chunk operations may also or instead be performed on chunks that have been read into the memories of different MLS servers. The types of filtering operations supported may include sampling, splitting, shuffling, and/or partitioning. Based at least in part on the first filtering operation of the plan, a data transfer of at least a subset of the chunks of the data set from persistent storage to MLS server memories may be performed (element  2516 ). Depending on the manner in which the data is stored at the source locations indicated in the OR extraction request, the data transfer process may include decryption and/or decompression in addition to read operations in some embodiments. In some embodiments, the client may request the MLS to encrypt and/or compress the data prior to transferring the chunks from the source locations to the MLS servers, and then to perform the reverse operation (decryption and/or decompression) once the encrypted/compressed data reaches the MLS servers. 
     After the first filtering operation of the sequence is performed in memory at the MLS servers, the remaining filtering operations (if any) may be performed in place in the depicted embodiment, e.g., without copying the chunks to persistent storage or re-reading the chunks for their original source locations (element  2519 ). In one embodiment, respective jobs may be generated and placed in an MLS job queue for one or more of the filtering operations. In at least some embodiments, a record parser may be used to obtain the observation records from the output of the sequence of filtering operations performed (element  2522 ). The ORs may be provided programmatically to the requesting client (e.g., as an array or collection returned in response to the API call representing the OR extraction request), and/or to a specified destination such as a model or a feature processing recipe (element  2525 ). 
     Consistent Filtering of Input Data Sets 
       FIG. 26  illustrates an example of an iterative procedure that may be used to improve the quality of predictions made by a machine learning model, according to at least some embodiments. The procedure may include re-splitting or re-shuffling the input data set for each of several cross-validation iterations, for example, as described below. An input data set comprising labeled observation records (i.e., observation records for which the values or “labels” of dependent variables are known) may be mapped to a set of contiguous chunks  2602 , e.g., using the techniques described above to increase the fraction of physical I/O that can be performed sequentially. An in-memory chunk-level split operation  2604  may be performed to obtain a training set  2610  and a test set  2615 . For example, 80% of the chunks may be included in the training set  2610  in one scenario, and the remaining 20% of the chunks may be included in the test set  2615 . A candidate model  2620  may be trained in a training run  2618  (e.g., for a linear regression model, candidate coefficients to be assigned to the various independent variables of the data set may be determined). The candidate model  2620  may then be used to make predictions on the test set, and the evaluation results  2625  of the model may be obtained (e.g., indicating how accurately the model was able to generate predictions for the dependent variables of the records of the test set using the candidate coefficients). A variety of measures  2630  of the accuracy or quality may be obtained in different embodiments, depending on the type of model being used—e.g., the root mean square error (RMSE) or root mean square deviation (RMSD) may be computed for linear regression models, the ratio of the sum of true positives and true negatives to the size of the test set may be computed for binary classification problems, and so on. 
     If the accuracy/quality measures  2630  are satisfactory, the candidate model  2620  may be designated as an approved model  2640  in the depicted embodiment. Otherwise, any of several techniques may be employed in an attempt to improve the quality or accuracy of the model&#39;s predictions. Model tuning  2672  may comprise modifying the set of independent variables being used for the predictions, changing model execution parameters (such as a minimum bucket size or a maximum tree depth for tree-based classification models), and so on, and executing additional training runs  2618 . Model tuning may be performed iteratively using the same training and test sets, varying some combination of independent variables and parameters in each iteration in an attempt to enhance the accuracy or quality of the results. In another approach to model improvement, changes  2674  may be made to the training and test data sets for successive training-and-evaluation iterations. For example, the input data set may be shuffled (e.g., at the chunk level and/or at the observation record level), and a new pair of training/test sets may be obtained for the next round of training. In another approach, the quality of the data may be improved by, for example, identifying observation records whose independent variable values appear to be invalid or outliers, and deleting such observation records from the data set. One common approach for model improvement may involve cross-validating a candidate model using a specified number of distinct training and test sets extracted from the same underlying data, as described below with reference to  FIG. 27 . Just as multiple iterations of model tuning  2672  may be performed, data set changes  2674  may also be performed iteratively in some embodiments, e.g., until either a desired level of quality/accuracy is obtained, until resources or time available for model improvement are exhausted, or until the changes being tried no longer lead to much improvement in the quality or accuracy of the model. 
       FIG. 27  illustrates an example of data set splits that may be used for cross-validation of a machine learning model, according to at least some embodiments. In the depicted embodiment, a data set comprising labeled observation records  2702  is split five different ways to obtain respective training sets  2720  (e.g.,  2720 A- 2720 E) each comprising 80% of the data, and corresponding test sets  2710  (e.g.,  2710 A- 2710 E) comprising the remaining 20% of the data. Each of the training sets  2720  may be used to train a model, and the corresponding test set  2710  may then be used to evaluate the model. For example, in cross-validation iteration  2740 A, the model may be trained using training set  2720 A and then evaluated using test set  2710 A. Similarly, in cross-validation iteration  2740 B, a different training set  2720 B (shown in two parts, part  1  and part  2  in  FIG. 27 ) comprising 80% of the input data may be used, and a different test set  2710 B may be used for evaluating the model. The cross-validation example illustrated in  FIG. 27  may be referred to as “5-fold cross validation” (because of the number of different training/test set pairs generated and the corresponding number of training-and-evaluation iterations.) The MLS may implement an API allowing a client to request k-fold cross validation in some embodiments, where k is an API parameter indicating the number of distinct training sets (and corresponding test sets) to be generated for training a specified model using the same underlying input data set. 
     The labeled observation records are distributed among eight chunks C 1 -C 8  in the example shown in  FIG. 27 . As mentioned earlier, the chunk sizes and boundaries may be determined based on any of various factors, including memory size limits at MLS servers, client preferences, and so on. In some scenarios, the split ratio desired (such as the 80-20 split illustrated in  FIG. 27 ) may result in the observation records of a given chunk having to be distributed across a training set and the corresponding test set. That is, partial chunks may have to be included in training and test sets in some cases. Some observation records of chunk C 2  may be included in test set  2710 A, while other observation records of chunk C 2  may be included in training set  2720 A, for example. 
     It is noted that although the training sets may appear to comprise contiguous portions of the input data set in  FIG. 27 , in practice the training and test data sets may be obtained using random selection (e.g., either at the chunk level, at the observation record level, or at both levels) in at least some embodiments. By changing the set of observation records included in the training and test sets of the different cross-validation iterations  2740 A- 2740 E, the quality of the predictions made may in general improve, as the effect of localized non-uniformity of the independent variable values in different subsets of the input data set may be reduced. For example, if the value of an independent numerical variable within the subset of data records that are in test set  2710 A is unusually high compared to the mean of that variable over the entire data set, the effects of that anomaly on model accuracy/quality would be expected to be dissipated by the use of different test data sets for the other cross-validation iterations. 
       FIG. 28  illustrates examples of consistent chunk-level splits of input data sets for cross validation that may be performed using a sequence of pseudo-random numbers, according to at least some embodiments. A random number based split algorithm  2804  is used to divide data set chunks C 1 -C 10  into training and test sets for successive training-evaluation iterations (TEIs). Each TEI may, for example, represent a particular cross-validation iteration such as those illustrated in  FIG. 27 , although such training and evaluation iterations may also be performed independently of whether cross-validation is being attempted. A pseudo-random number generator (PRNG)  2850  may be used to obtain a sequence  2872  of pseudo-random numbers. The PRNG  2850  may be implemented, for example, as a utility function or method of an MLS library or a programming language library accessible from a component of the MLS. The state of PRNG  2850  may be deterministically initialized or reset using a seed value S (e.g., a real number or string) in the depicted embodiment, such that the sequence of pseudo-random numbers that is produced after resetting the state with a given seed S is repeatable (e.g., if the PRNG is reset using the same seed multiple times, the same sequence of PRNs would be provided after each such state reset). 
     In the depicted example, to simplify the presentation, the number of chunks of the input data set (10) and the split ratio (80-20) has been chosen such that an integer number of chunks is placed into the training set and the test set—i.e., observation records of a given chunk do not have to be distributed between both a training set and a test set. The pseudo-random numbers (PRNs) of the sequence  2872  produced by the PRNG may be used to select members of the training and test sets. For example, using the first PRN  2874  (produced after resetting the state of the PRNG), which has a value of 84621356, chunk C 7  may be selected for inclusion in the training set  2854 A to be used for TEI  2890 A. Using the second PRN 56383672, chunk C 2  may be selected for the training set  2854 A, and so on. The random-number based split algorithm  2804  may rely on certain statistical characteristics of the PRN sequence to correctly designate each chunk of the input data set into either the training set or the test set in the depicted example scenario. The statistical characteristics may include the property that a very large number of distinct pseudo-random numbers (or distinct sub-sequences of some length N) are expected to be produced in any given sequence (e.g., before a given PRN is repeated in the sequence, or before a sub-sequence of length N is repeated). If the state of the PRNG is not reset between the time that a given training set  2854  is generated and the time that the corresponding test set  2856  is generated in the depicted embodiment, the sequence of PRNs  2872  generated may ensure that each chunk of the input data is mapped to either the training set or the test set, and no chunk is mapped to both the training set and the test set. Such a split operation, in which each object (e.g., chunk or observation record) of the source data set is placed in exactly one split result set (e.g., a training set or the corresponding test set), may be referred to as a “consistent” or “valid” split. A split operation in which one or more objects of the input data set are either (a) not placed in any of the split result sets, or (b) placed in more than one of the split result sets may be termed an “inconsistent” or “invalid” split. The sequence of the PRNs used for each of the two split mappings (the mapping to the training set and the mapping to the test set), and hence the state of the PRN source, may influence the probability of producing inconsistent splits in at least some embodiments. In turn, the use of inconsistent splits for training and evaluation may result in poorer prediction quality and/or poorer accuracy than if consistent splits are used. 
     In at least some embodiments, intra-chunk shuffles may be implemented within the training set and/or the test set, e.g., based on contents of a client request in response to which the TEIs are being implemented. Thus, for example, the observation records within a given chunk (e.g., C 7 ) of training set  2854 A may be re-ordered in memory (without copying the records to persistent storage) relative to one another before they are provided as input to the model being trained. Similarly, the observation records of a given chunk (e.g., C 3 ) of test set  2856 A may be shuffled in memory before the model is evaluated using the test set. 
     As a result of using the PRN sequence  2872 , the first TEI  2890 A may be implemented with a training set  2854 A of chunks (C 7 ,C 2 ,C 4 ,C 5 ,C 9 ,C 1 ,C 10 ,C 8 ) and a test set  2856 A of chunks (C 3 ,C 6 ). In some embodiments, the same PRNG  2850  may also be used (e.g., without re-initialization or resetting), to split the input data set for the next TEI  2890 B. It is noted that for some models and/or applications, only one TEI may be implemented in various embodiments. In the depicted example, training set  2854 B of TEI  2890 B comprises chunks (C 8 ,C 3 ,C 5 ,C 6 ,C 10 ,C 2 ,C 1 ,C 9 ) and the corresponding test set  2856 B comprises chunks (C 4 ,C 7 ). Both the splits illustrated in  FIG. 28  are consistent/valid according to the definitions provided above. It is noted that although the splitting of the data is illustrated at the chunk level in  FIG. 28 , the same type of relationship between the PRNG state and the consistency of the split may apply to splits at the observation record level (or splits involving partial chunks) in at least some embodiments. That is, to perform a consistent split at the observation record level using a PRNG, the state of the PRNG should ideally not be re-initialized between the determination of the training set and the determination of the test set. A split involving partial chunks may be implemented in some embodiments as a chunk-level split in which a non-integer number of chunks is placed in each split result set, followed by an intra-chunk split for those chunks whose records are distributed across multiple split result sets. In addition to two-way splits, the PRN-based approach to splitting a data set may also be used for N-way splits (where N&gt;2). 
       FIG. 29  illustrates an example of an inconsistent chunk-level split of an input data set that may occur as a result of inappropriately resetting a pseudo-random number generator, according to at least some embodiments. In the depicted example, a PRNG  1850  is initialized using a seed S. The PRN sequence  2972 A is used by the split algorithm  2804  to produce the training set  2954 A comprising the same set of chunks of data set  2844 A that were included in test set  2854 A of  FIG. 28  (C 7 ,C 2 ,C 4 ,C 5 ,C 9 ,C 1 ,C 10 ,C 8 ). After the training set  2954 A is generated, the PRNG is re-initialized. As a result, the sequence of pseudo-random numbers generated is repeated—e.g., the first PRN generated after the reset is once again 84621356, the second PRN is once again 56383672, and so on. The split algorithm chooses chunks C 7  and C 2  for inclusion in test set  2956 A as a result of the repetition of PRNs in the depicted example. Such a split may be deemed invalid or inconsistent because C 2  and C 7  are in both the training set and the test set (and because chunks C 3  and C 6  are in neither the training set nor the test set). 
     In some embodiments, a PRNG may not be invoked in real time for each placement of a given chunk or record into a training set or a test set. Instead, a list of pseudo-random numbers or random numbers may be generated beforehand (e.g., using a PRNG), and the numbers in the pre-generated list may be used one by one for the split placements. In such a scenario, as long as a pointer is maintained to the last number in the list that was used for the training set, and the test set placement decisions are made using the remainder of the numbers (i.e., numbers that were not used for the training set), split consistency may be achieved in at least some embodiments. 
     In another approach to attaining consistent splits, respective mechanisms (e.g., APIs) may be implemented to (a) save a current state of a PRNG and (b) to re-set a PRNG to a saved state in one embodiment. Consider a scenario in which an API “save_state(PRNG)” can be invoked to save the internal state of a PRNG to an object “state_AfterTraining” after the training set of a TEI has been generated, and a different API “set_state(PRNG, state_AfterTraining)” can be invoked to reset the state of the PRNG (or a different PRNG) to the saved state just before starting the selection of the test set of the TEI. Using such a pair of state save and restore operations, the same sequence of PRNs may be obtained as would be obtained if all the PRNs were obtained without saving/re-setting the PRNG state. In some embodiments, different PRN sources may be used for the training set selection than of a given TEI are used for the test set selection, as described below with respect to  FIG. 30 , and the state of such PRN sources may be synchronized to help achieve consistent splits. 
     In at least some embodiments, the selection of a test set from a given input data set may occur asynchronously with respect to (and in some cases much later than) the selection of the corresponding training set. For example, separate jobs may be inserted in the MLS job queue for the selection of a training set and the selection of the corresponding test set, and the jobs may be scheduled independently of each other in a manner similar to that described earlier. In such scenarios, in order to ensure that the training/test split is valid and consistent despite the delay between the two operations, the MLS may maintain state information pertaining to the selection of the training set in some embodiments, which can then be used to help generate the test set.  FIG. 30  illustrates an example timeline of scheduling related pairs of training and evaluation jobs, according to at least some embodiments. Four events that occur during a period of approximately four hours (from 11:00 to 15:00 on a particular day) of a job scheduler&#39;s timeline are shown. 
     At time t 1 , a training job J 1  of a training-and-evaluation iteration TEI 1  for a model M 1  is begun. Job J 1  is scheduled at a set of servers SS 1  of the MLS, and may include the selection of a training set, e.g., either at the chunk-level, at the observation record level, or at both levels. A pseudo-random number source PRNS  3002  (such as a function or method that returns a sequence of PRNs, or a list of pre-generated PRNs) may be used to generate the training set for Job J 1 . At time t 2 , a training job J 2  may be scheduled at a server set SS 2 , for a training-and-evaluation iteration TEI 2  for a different model M 2 . The training set for job J 2  may be obtained using pseudo-random numbers obtained from a different PRNS  3002 B. 
     At time t 3 , a test job J 3  for the evaluation phase of TEI 1  is scheduled, more than two hours later than job J 1 . The scheduling of J 3  may be delayed until J 1  completes, for example, and the size of the data set being used for J 1 /J 3  may be so large that it takes more than two hours to complete the training phase in the depicted example. J 3  may be scheduled at a different set of servers SS 3  than were used for J 1 . In at least some implementations, a different PRNS  9002 C may be available at server set SS 3  than was available at server set SS 1 . In order to ensure consistency of the training/test split, PRNS  3002 C may be synchronized with PRNS  3002 A in the depicted embodiment. Thus for example, if a seed value Seed 1  was used to initialize PRNS  3002 A, and  1000  pseudo-random numbers were obtained from PRNS  3002 A during job J 1 , the same seed value Seed 1  may be used to initialize a logically equivalent PRNS  3002 C, and  1000  pseudo-random numbers may be acquired from PRNS  3002 C before the pseudo-random numbers to be used for test set selection are acquired. Equivalents of the “save_state( )” and “set_state( )” calls discussed above may be used in some embodiments to synchronize PRNS  3002 C with PRNS  3002 A. If lists of pre-generated PRNS are being used as the PRN sources, in one embodiment the MLS may ensure that (a) the same list is used for J 1  and J 3  and (b) the first PRN in the list that is used for J 3  is in a position immediately after the position of the last PRN used for J 1 . Other synchronization techniques may be used in various embodiments to ensure that the sequence of pseudo-random numbers used for test set determination is such that a valid and consistent split is achieved for jobs J 1  and J 3 . Similarly, for test job J 4  (scheduled at t 4 ) corresponding to training job J 2 , PRNS  3002 D may be synchronized with PRNS  3002 B. In at least the depicted embodiment, to ensure split consistency, it may be necessary to enforce a logical relationship or some degree of coordination between the sets of pseudo-random numbers used for generating a training set and the corresponding test set (e.g., the numbers used in J 3  may have to be coordinated with respect to the numbers used in J 1 , and the numbers used in J 4  may have to be coordinated with respect to the numbers used in J 2 ). 
       FIG. 31  illustrates an example of a system in which consistency metadata is generated at a machine learning service in response to a client request, according to at least some embodiments. The consistency metadata may be retained or shared across related jobs (e.g., a training job and a corresponding evaluation job) to achieve the kinds of coordination/synchronization discussed with respect to  FIG. 30 . In system  3100  of  FIG. 31 , a client  164  of an MLS may submit a split request  3110  via a data-source-agnostic programmatic interface  3161  of an MLS I/O library. In some implementations, the split request may be part of a cross-validation request, or part of a request to perform a specified number of training-and-evaluation iterations. In at least one embodiment, the split request may represent a variant of the type of observation record extraction request  2401  shown in  FIG. 24 . The split request may include, for example, one or more client-specified seed values  3120  that may be used for obtaining the pseudo-random numbers for the requested split operations, although such seed values may not have to be provided by the client in at least one embodiment. In addition, in the depicted embodiment, the split request  3110  may include an indication (e.g., file names, paths or identifiers) of the input data set  3122 . Split parameters  3124  may indicate one or more training-to-test ratios (e.g., the 80-20 split ratio illustrated in  FIG. 29 ). In some embodiments in which the split request is part of a request for training-and-evaluation iterations or cross-validation iterations, the desired iteration count  3126  may be included in the client request. 
     A request handler component  180  of the MLS may pass on the request  3110  to a plan generator  3180  in the depicted embodiment. The plan generator may determine a set of consistency metadata  3152 , e.g., metadata that may be shared among related jobs that are inserted in the MLS job queue for the requested split iterations. The metadata  3152  may comprise the client-provided seed values  3120 , for example. In one embodiment, if a client-provided seed value is not available (e.g., because the API  3161  used for the client request does not require a seed to be provided, or because the client failed to provide a valid seed value), the plan generator  3180  may determine a set of one or more seed values. Such MLS-selected seed values may be based, for example, on some combination of input data set IDs  3122  (e.g., a hash value corresponding to a file name or directory name of the input data set may be used as a seed), client identifier, the time at which the request  3110  was received, the IP address from which the request  3110  was received, and so on. In one implementation, the MLS may have several sources of pseudo-random numbers available, such as PRNGs or lists of pre-generated PRNs, and an identifier of one or more PRN sources may be included in the consistency metadata  3152 . In an embodiment in which pre-generated PRN lists are to be used, a pointer to the last-used PRN within a specified list may be used, such that each entity that uses the list (e.g., an MLS job executor) updates the pointer after it has used some number of the list&#39;s PRNs. In one embodiment in which equivalents of the “save_state( )” and “set_state( )” operations described above are supported for PRNGs, a state record of a PRNG may be included in the metadata. The state record may be updated by each entity (e.g., an MLS job executor) that used the PRNG, e.g., so that the next entity that uses the PRNG can set its state appropriately to obtain PRNs that can be used to perform a consistent split. 
     The plan generator  3180  may generate respective jobs  3155  for selecting the split result sets. For example, for a given training-and-evaluation iteration, one job may be created for selecting the training set and another job may be generated for selecting the test set. In some implementations, a job object created by the plan generator  3180  may include a reference or pointer to the consistency metadata to be used for that job. In another implementation, at least a portion of the consistency metadata  3152  may be included within a job object. When a job is executed, the metadata  3152  may be used to ensure that the input data set is split consistently. In some embodiments, a single job may be created that includes both training and test set selection. 
     It is noted that a similar approach towards consistency or repeatability may be taken for other types of input filtering operations, such as sampling or shuffling, in at least some embodiments. For example, in one embodiment, a client may wish to ensure shuffle repeatability (i.e., that the results of one shuffle request can be re-obtained if a second shuffle request with the same input data and same request parameters is made later) or sample repeatability (i.e., that the same observation records or chunks are retrievable from a data set as a result of repeated sample requests). If the filtering operation involves a use of pseudo-random numbers, saving seed values and/or the other types of consistency metadata shown in  FIG. 31  may enable support for shuffle repeatability and/or sample repeatability as well. For example, a repeated shuffle may be obtained starting with the same input data set and re-initializing a PRNG with the same seed value as was used for an initial shuffle. Similarly, re-using the same seed may also result in a repeatable sample. In various embodiments, consistent splits may be performed at the chunk level, at the observation record level, or at some combination of chunk and record levels, using consistency metadata of the kind described above. In at least one embodiment, after a chunk-level split is performed, the records of the individual chunks in the training set or the test set may be shuffled prior to use for training/evaluating a model. 
       FIG. 32  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service in response to a request for training and evaluation iterations of a machine learning model, according to at least some embodiments. As shown in element  3201 , a request to perform one or more TEIs (training-and-evaluation iterations, such as cross-validation iterations) may be received via a programmatic interface such as an MLS I/O library API. A set of consistency metadata may be generated for the iteration(s), e.g., comprising one or more initialization parameter values (such as a value V 1 ) for pseudo-random number sources (PRNSs). The metadata may comprise a seed value to be used to initialize or reset a state of a PRNG, for example, or a pointer to a particular offset within a list of pre-generated pseudo-random number. In some embodiments, the client may include at least a portion of the metadata in the TEI request. In addition to or instead of seed value(s), the consistency metadata may include, for example, an identifier of a PRNS, a representation of a state of a PRNS, and/or a pointer into a list of pseudo-random numbers. 
     If the input data set indicated in the request is spread over multiple files or multiple data objects, the files/objects may be logically concatenated to form a unified address space for the input data. The address space of the input data set may be sub-divided into contiguous chunks (element  3207 ), e.g., with the chunk sizes/boundaries being selected based on client preferences, memory constraints at MLS servers, and/or other factors. One or more chunks of the input data set may be read in from persistent storage to respective memories at one or more MLS servers, e.g., such that at least a portion of chunk C 1  is stored in memory at server S 1  and at least a portion of chunk C 2  is stored in memory at server S 2  (element  3210 ). 
     Using the consistency metadata, a first training set Trn 1  of the input data may be selected (element  3213 ), e.g., including at least some observation records of chunk C 1 . The training set may be selected at the chunk level, the observation record level, or some combination of chunk level and observation record level. Partial chunks may be included in the training set Trn 1  in at least some embodiments (that is, some observation records of a given chunk may be included in the training set while others may eventually be included in the corresponding test set). In one embodiment, an initialization parameter value V 1  may be used to obtain a first set of pseud-random numbers from a source that provided deterministic sequences of such numbers based on the source&#39;s initial state, and the first set of pseudo-random numbers may in turn be used to select the training set Trn 1  used to train a targeted machine learning model M 1 . 
     To evaluate the model after it has been trained, a test set Tst 1  may be determined using the consistency metadata (element  3216 ) (e.g., using a set of pseudo-random numbers obtained from the same source, or from a source whose state has been synchronized with that of the source used for selecting Trn 1 ). In one implementation, for example, the consistency metadata may indicate a seed Seed 1  and a count N 1  of pseudo-random numbers that are obtained from a PRNG for generating Trn 1 . If the original PRNG is not available to provide pseudo-random numbers for selecting Tst 1  (e.g., if the test set is being identified at a different server than the server used for identifying Trn 1 , and local PRNGs have to be used at each server), an equivalent PRNG may be initialized with Seed 1 , and the first N 1  pseudo-random numbers generated from the equivalent PRNG may be discarded before using the succeeding pseudo-random numbers (starting from the (N 1 +1)th number) for selecting Tst 1 . In another implementation, the algorithm used for selecting Trn 1  and Tst 1  (or any pair of training and test sets) may be designed in such a way that the same sequence of pseudo-random numbers can be used to select Trn 1  and Tst 1  while still meeting the consistency criteria described earlier. In such an implementation, same seed value may be used to initialize a PRNG for Tst 1 , and no pseudo-random numbers may have to be skipped to select Tst 1 . Model M 1  may be tested/evaluated (e.g., the accuracy/quality of the model&#39;s predictions may be determined) using test set Tst 1 . 
     As long as more TEIs remain to be performed (as determined in element  3219 ), the training and test sets for the next iteration may be identified in place, without copying any of the chunk contents to other locations in the depicted embodiment (element  3222 ). In the depicted embodiment, the consistency metadata that was used to generate Trn 1  and Tst 1  may be used for selecting the training set and the test set for subsequent TEIs as well. In other embodiments, respective sets of consistency metadata may be used for respective TEIs. In at least some embodiments in which a training set is initially identified at the chunk level, the observation records within individual chunks of the training set may be shuffled in memory (i.e., an intra-chunk shuffle may be performed without any additional I/O to persistent storage) prior to using the observation records to train the model. Similarly, intra-chunk shuffles may be performed on test sets in some embodiments before the test sets are used for evaluation. After all the requested iterations of training and evaluation are completed, the processing of the request received in operations corresponding to element  3201  may be considered complete, and the final results of the iterations may be provided to a destination indicated in the request (element  3225 ). 
     Optimizations for Decision Tree Based Models 
     A number of machine learning methodologies, for example techniques used for classification and regression problems, may involve the use of decision trees.  FIG. 33  illustrates an example of a decision tree that may be generated for predictions at a machine learning service, according to at least some embodiments. A training set  3302  comprising a plurality of observation records (ORs) such as OR  3304 A, OR  3304 B and OR  3304 C is to be used for training a model to predict the value of a dependent variable DV. Each OR in the training set  3302  contains values for some number of independent variables (IVs), such as IV 1 , IV 2 , IV 3 , IVn (for example, in OR  3304 A, IV 1 &#39;s value is x, IV 2 &#39;s value is y, IV 3 &#39;s value is k, IV 4 &#39;s value is m, and IVn&#39;s value is q) as well as a value of the dependent variable DV (whose value is X in the case of OR  3304 A). In general, not all the ORs  3304  need have values for all of the independent variables in at least some embodiments; for example, some values may not be available from the source from which the observation records are obtained. In the depicted example, assume that the dependent variable, which may also be referred to as the “label” or the “target variable” (since it is the variable whose value the model is to predict) takes on one of two values, X or Y. Any given independent variable as well as the dependent variable may take on any number of different values, and may be of any desired data type such as numerical, categorical, Boolean, character, and so on. 
     Based on an analysis of the observation records  3304  of a subset or all of the training set, one or more decision trees  3320  may be constructed, e.g., by a model generator component or model manager component of the machine learning service described above, to make predictions for the value of DV based on the values of at least some of the IVs of an observation record. Each non-leaf node of a decision tree  3320 , such as root node  3322 , may indicate one or more conditions or predicates to be evaluated on one or more independent variables, and the results of evaluating the predicate may determine the path to be taken next towards a leaf node of the tree at which a prediction for the DV is made for the OR. For example, in the decision tree illustrated, the root node indicates that the value of independent variable IV 2  is to be compared with k. If IV 2  is less than k for a given observation record for which a prediction is to be made, the path to intermediate node  3323  should be taken, as indicated by the edge labeled “y” (for “yes” in answer to the evaluation of “IV 2 &lt;k”). If IV 2  is greater than or equal to k in the observation record being analyzed, the path labeled “n” (for “no”) would be taken. Similar decisions would be taken at various non-leaf nodes until a leaf node is reached, at which point a value for DV would be predicted based on the combination of predicates checked along the path. Thus, in the depicted tree  3320 , if the following conditions are found to be true, a DV value of X may be predicted at leaf node  3324 : (IV 2 &lt;k) and (IV 1 &gt;=p) and (IV 6 &gt;=p) and (IV 7 ==q) and (IV 4  !=z). A similar traversal would be performed for all the records of a test data set  3330  by a decision tree based model  3335 , resulting in a set of predictions  3340  of DV values. For many training data sets, one or more of the independent variables may not necessarily be represented in a decision tree—for example, if independent variable IVn is not significant with respect to predicting DV, none of the nodes included in the tree  3320  may include a condition that refers to IVn. In general, the model generator component of the machine learning service may be responsible for identifying efficient ways of predicting DV values accurately using some subset of the independent variables, and encoding such efficient ways in the form of one or more decision trees. A number of factors which may contribute to prediction quality and efficiency are discussed below. 
     A simple binary classification example is illustrated in  FIG. 33  to simplify the presentation. Decision trees may also be used for multi-way classification and/or regression in various embodiments. A given node of a decision tree may have more than two child nodes (i.e., more than two outgoing paths towards the leafs) in some embodiments—that is, more complex multi-result conditions may be evaluated at each node than the simple binary tests shown in  FIG. 33 . As described below in further detail, each node may be represented by a corresponding descriptor indicating the predicates/conditions to be checked, the number and identity of its child nodes, etc., so that the tree as whole may be represented as a collection of node descriptors. The size and shape of a decision tree  3320  that is generated may depend on various factors such as the number of independent variables that are found to be significant for predictions, the order in which the tree-generation algorithm analyzes the observation records of the training set, and so on. Some models (such as Random Forest models and adaptive boosting models) may require or rely on ensembles or collections of many different trees, e.g., respective trees obtained using respective subsets of the training data set. 
     The costs (e.g., in terms of resources used or time required) for making decision-tree based predictions may be broadly categorized into two categories: training costs and execution/prediction costs. Execution/prediction costs may also be called run-time costs herein. Training costs refer to the resources used to construct the trees and train the model using the training data set, while the execution costs refer to the resources used when the models make predictions on new data (or test data) that was not used for the training phase. In at least some embodiments, as described below, tradeoffs may be possible between the training costs and the quality of the predictions made on new data. By expending more resources and/or time during training, better (e.g., more accurate and/or faster) predictions may be made possible for at least some types of problems. For example, unlike in some conventional tree-construction approaches, in some embodiments decision trees may be constructed in depth-first order, with the descriptors for the nodes being streamed immediately to disk or some other form of persistent storage as they are being created, instead of requiring the tree-construction procedure to be limited to the amount of main memory available at a given server. Such a depth-first and persistent-storage-based tree construction pass may result in a number of benefits relative to breadth-first memory-constrained approaches, such as better prediction accuracies for observation record classes with small populations, better processor cache utilization (e.g., at level 2 or level 1 hardware caches associated with the CPUs or cores being used at MLS servers), and so on. Although fairly large trees may be produced as a result of such an approach (since the tree sizes are not memory-constrained during the tree construction pass), the trees may be pruned intelligently during a second pass of the training phase, e.g., to remove a subset of the nodes based on one or more run-time optimization goals. The term “run-time optimization goals” may be used herein to refer to objectives associated with executing a trained model to make predictions, such as reducing the time it takes to generate predictions for a test data set or a production data set, reducing the amount of CPU or other resources consumed for such predictions, and so on. (In some embodiments, in addition to or instead of such run-time or prediction-time goals, clients of the MLS may also or instead have training time goals pertaining to the resources or time used for training the model.) Pruned trees that can fit within memory constraints may then be used to make high-quality predictions on non-training data sets. Details regarding the manner in which the decision trees may be generated and pruned in different embodiments are provided below. 
       FIG. 34  illustrates an example of storing representations of decision tree nodes in a depth-first order at persistent storage devices during a tree-construction pass of a training phase for a machine learning model, according to at least some embodiments. In the depicted example, training data  3432  may be read into training set memory buffers  3340  (e.g., at one or more MLS servers) prior to construction of one or more decision tree trees  3433 . In other embodiments, the entire training set need not be read into memory—for example, in one implementation, pointers to the observation records may be retained in memory instead of the entire records. As each node of tree  3433  is created, the training set (e.g., the observation records themselves, or pointers to the observation records) may be sorted or rearranged in memory in accordance with the predicate evaluated for that node. For example, if node N 1  of tree  3433  includes an evaluation of a predicate “IV 1 &lt;=x” for an independent variable IV 1 , the training set records may be rearranged such that all the records with IV 1  values less than equal to x are in one contiguous portion P 1  of the memory, and the tree generator component of the MLS may then analyze the contents of that portion P 1  for constructing the left sub-tree (node N 2  and its children) in the depicted embodiment. The rearrangement of the training set records may be performed in memory (i.e., without I/O to disk or other persistent storage devices) in at least some embodiments. As lower levels of the tree are reached, smaller subsets of the training set may have to be rearranged, thereby potentially improving hardware cache utilization levels in at least some embodiments. 
     Tree  3433  may be constructed in depth-first order in the depicted embodiment. Although the pre-order version of depth first traversal/construction is illustrated in  FIG. 34 , in-order or post-order depth-first traversals/construction may be employed in some embodiments. The labels “N&lt;#&gt;” for the nodes indicate the sequence in which they are generated, and the order in which corresponding descriptors  3430  are written from memory to persistent storage device(s) such as various disk-based devices accessible at the MLS servers at which the model generator or model manager runs. Thus, node N 1  is created first, and written to persistent storage first, followed by N 2 , N 3 , . . . , as indicated by arrows  3435 . The first leaf node created in the depth-first sequence is N 6 , followed by N 7 , N 8 , N 9 , N 10  and N 12 . The descriptors  3430  (e.g.,  3430 A- 3430 L for nodes N 1 -N 12  respectively) may indicate, for example, the predicates or conditions to be evaluated at the corresponding nodes, the number and/or identities of the child nodes, and so on. 
     In addition to the predicates to be evaluated at each node, a respective predictive utility metric (PUM)  3434  may also be generated for some or all of the nodes of tree  3433  in the depicted embodiment and stored in persistent storage—e.g., PUM  3434 A may be computed and stored for node N 1 , PUM  3434 B for node N 2 , and so on. Generally speaking, the PUM of a given node may be indicative of the relative contribution or usefulness of that node with respect to the predictions that can be made using all the nodes. Different measures may be used as predictive utility metrics in different embodiments, e.g., based on the type of machine learning problem being solved, the specific algorithm being used for the tree&#39;s construction, and so on. In one implementation, for example, a Gini impurity value may be used as the PUM or as part of the PUM, or an entropy-based measure of information gain, or some other measure of information gain may be used. In some implementations, a combination of several different measures may be used. In at least some embodiments, some measure of predictive utility or benefit of a predicate may have to be computed in any case during tree construction for at least some of the nodes to be added to the tree, and the PUM assigned to the node may simply represent such a benefit. In some implementations, PUM values may not be identified for one or more nodes of a tree—that is, having PUM values available for a subset of the nodes may suffice for tree pruning purposes. 
     In at least some implementations, it may be possible to create a partial (or total) order of the nodes of a decision tree based on the PUMs of the nodes, and such an ordering may be used in a tree pruning pass of the training phase as described below. In one embodiment, instead of or in addition to generating an ordered list of all the nodes, a histogram or similar distribution indicator of the PUM values with respect to the tree nodes may be created and/or written to persistent storage, e.g., together with the node descriptors and PUM values. A histogram may, for example, take much less memory than an exhaustive list of the tree&#39;s nodes and corresponding PUM values. 
       FIG. 35  illustrates an example of predictive utility distribution information that may be generated for the nodes of a decision tree, according to at least some embodiments. PUM values increase from left to right on the X-axis of the PUM histogram  3510 , and the number of decision tree nodes that fall within each PUM value bucket is indicated by the height of the corresponding bar of the histogram. As a result of generating the distribution information, bucket  3520 A representing relatively low-value nodes may be identified, indicating how many nodes have low PUM values, and bucket  3520 B indicating the number of high-value nodes may be identified, for example. The low value nodes may be deemed better candidates for removal from the tree during pruning than the high value nodes. In some implementations, identifiers of at least some of the nodes belonging to one or more of the buckets of the histogram  3510  may be stored in persistent storage to assist in the pruning phase. For example, the identifiers of nodes within two levels from a leaf node may be stored for one or more low-value buckets in one implementation, and such a list may be used to identify pruning candidate nodes. 
     The tree-construction pass of a training phase may be followed by a pruning pass in at least some embodiments, in which the tree representations are reduced in size by eliminating selected nodes in view of one or more run-time optimization goals or criteria. In some embodiments, several separate periods of tree-construction interspersed with periods of tree-pruning may be implemented, so that the entire tree need not necessarily be generated before some its nodes are pruned (which might help reduce the total number of nodes generated). A number of different goals may be taken into consideration in different embodiments for pruning  FIG. 36  illustrates an example of pruning a decision tree based at least in part on a combination of a run-time memory footprint goal and cumulative predictive utility, according to at least some embodiments. The term “run-time memory footprint” may be used herein to indicate the amount of main memory required for an execution of the model at a given server or a combination of servers, e.g., after the model&#39;s training phase is completed. Tradeoffs between two conflicting run-time goals may be considered in the depicted embodiment: the amount of memory it takes to store the tree during model execution, and the accuracy or quality of the prediction. In at least some implementations, both the memory footprint or usage (for which lower values are better) and the accuracy/quality (for which higher values are better) may increase with the number of retained nodes (i.e., the nodes that are not removed/pruned from the initial decision tree generated using the depth-first stream-to-persistent-storage technique described above). A run-time memory footprint goal may be translated into a “max-nodes” value  3610 , indicating the maximum number of nodes that can be retained. The quality or accuracy of the pruned tree may be expressed in terms of the cumulative retained predictive utility  3620 , for example, which may be computed by summing the PUM values of the retained nodes, or by some other function that takes the PUM values of retained nodes as inputs. 
     Nodes may be identified for removal using a variety of approaches in different embodiments. For example, in a greedy pruning technique  3650 , the unpruned tree  3604  may be analyzed in a top-down fashion, selecting the path that leads to the node with the highest PUM value at each split in the tree. The cumulative PUM values of the nodes encountered during the greedy top-down traversal may be tracked, as well as the total number of nodes encountered. When the total number of nodes encountered equals the max-nodes value, the nodes that have been encountered thus far may be retained and the other nodes may be discarded or removed. In at least some embodiments, a modified or pruned version  3608  of the tree  3604  may be stored (e.g., in persistent storage) separately from the un-pruned version, so that, for example, re-pruning may be attempted using a different pruning approach if necessary. In other embodiments, only the pruned version  3608  may be retained. In some embodiments, instead of using a greedy top-down approach, a bottom-up approach may be used as indicated by arrow  3660 , in which leaf nodes are analyzed first, and nodes are removed if their contribution to the quality/accuracy of the model is below a threshold until the max-nodes constraint  3610  is met. In some embodiments, the PUM distribution information (such as a histogram similar to that illustrated in  FIG. 35 ) may be consulted when selecting nodes to be pruned. In embodiments in which multiple run-time goals (some of which may conflict with each other) guide the pruning procedure, the MLS may have to prioritize the conflicting goals relative to each other. For example, the max-nodes goal shown in  FIG. 36  may be considered a higher priority than the goal of accumulating predictive utility. In at least some implementations, at least some nodes may be selected for pruning using a random selection procedure, e.g., without using a strictly top-down or bottom-up approach while still adhering to the run-time goals and quality objectives. 
     In some embodiments, other types of run-time goals may be taken into account during the tree pruning pass of a model&#39;s training phase.  FIG. 37  illustrates an example of pruning a decision tree based at least in part on a prediction time variation goal, according to at least some embodiments. In some cases, depending on the distributions of the values of the independent variables of the training data set and the relationships between the independent variables and the dependent variable, a decision tree such as un-pruned decision tree  3704  may be very unbalanced. That is, some paths between the root node and leaf nodes may be much longer than others. For example, leaf node N 8  of tree  3704  may be reached from root node N 1  via a decision path  3704 A that traverses eight nodes (including N 1  and N 8 ), while leaf node N 17  may be reached via a decision path  3704 B that includes only three nodes. 
     In the depicted embodiment, the time taken (and the CPU resources consumed) to make a prediction for a given observation record&#39;s dependent variable may be at least approximately proportional to the length of the decision path, as indicated in graph  3786 . For some latency-sensitive applications, the variation in the time taken to make predictions for different observation records or test sets may be considered an important indicator of the quality of the model, with less variation typically being preferred to more variation. Accordingly, the maximum variation in prediction time  3710  may be an important run-time optimization goal in such embodiments, and some number of nodes may be removed from the tree  3704  so as to reduce the maximum variation in possible decision paths. As shown, for example, nodes N 6 , N 7 , N 8 , N 9 , N 10  and N 11  may be removed from tree  3704 , so that the maximum decision path length in the modified/pruned tree  3608  is reduced from eight to five. In at least some embodiments, a primary goal of minimizing variation in prediction time may be combined with a secondary goal of maximizing cumulative retained predictive utility. For example, when choices for pruning are to be made that affect the lengths of decision paths equally, the PUM values of the alternative pruning target nodes may be compared and the node with the greater PUM value may be retained. 
     In at least some embodiments, business goals may also be considered when pruning decision trees. For example, consider a scenario in which a group of potential customers of a service is being classified into segments S 1 , S 2 , . . . , Sn, such that the customers that are classified as belonging to segment S 6  are expected to spend substantially higher amounts on the service that customers belonging to other segments. In such a scenario, nodes along the decision paths that lead to classification of S 6  customers may be retained during pruning in preference to nodes along decision paths that lead to other segments. In various embodiments, a combination of memory footprints/constraints, quality/accuracy goals, absolute execution-time (prediction-time) goals, prediction-time variation goals, business/revenue goals, and/or other goals may be used, with application-specific prioritization of the different goals. In at least some embodiments, a programmatic interface of the MLS may allow clients to indicate one or more run-time optimization goals of the kinds described above, e.g., by ranking the relative importance to a client of the different types of goals for a given model or problem. In some embodiments, information regarding best practices for decision tree pruning (e.g., which pruning methodologies are most useful) for different problem domains may be collected by the MLS in knowledge base  122  (shown in  FIG. 1 ) and applied as needed. 
       FIG. 38  illustrates examples of a plurality of jobs that may be generated for training a model that uses an ensemble of decision trees at a machine learning service, according to at least some embodiments. In the depicted embodiment, respective training samples  3805 A,  3805 B and  3805 C may be obtained from a larger training set  3802  (e.g., using any of a variety of sampling methodologies such as random sampling with replacement), and each such sample may be used to create a respective decision tree using the depth-first approach described above. Thus, training sample  3805 A may be used to generate and store an un-pruned decision tree (UDT)  3810 A in depth-first order at persistent storage during tree-creation pass  3812  of training phase  3820 , training sample  3805 B may be used for UDT  3810 B, and UDT  3810 C may be generated using training sample  3805 C. Respective jobs J 1 , J 2  and J 3  may be inserted into an MLS job queue or collection for the construction of UDTs  3810 A,  3810 B and  3810 C in some embodiments. The jobs of the tree-creation pass may be performed in parallel in at least some embodiments, e.g., using respective servers of an MLS server pool, or using multiple threads of execution (or processes) at the same MLS server. 
     Each UDT may be pruned in accordance with applicable run-time optimization goals to produce a corresponding pruned decision tree (PDT)  3818  in the pruning pass  3814  of the training phase in the depicted embodiment. Jobs J 4 , J 5  and J 6  may be implemented for pruning UDTs  3810 A- 3810 C respectively, producing PDT  3818 A- 3818 C. Finally, jobs J 7 , J 8  and J 9  respectively may be scheduled to execute the model using the three PDTs  3818 A- 3818 C using some specified test set (or production data set) in the depicted embodiment, resulting in prediction results  3850 A- 3850 C. The results  3850  obtained from the different PDTs may be combined in any desired fashion (e.g., by identifying an average or median value for the predictions for each test set observation record) to produce aggregated prediction results  3860  during a prediction or test phase of the machine learning algorithm being used. A prediction phase may differ from a test phase, for example, in that the values of the dependent variables may not be known for the data set in the prediction phase, while values for the dependent variables may be known for the data set used for testing the model. In some embodiments, an additional job J 10  may be scheduled for the aggregation of the results. It is noted that any of the jobs J 1 -J 10  may be performed in parallel with other jobs, as long as the applicable job dependencies are met—e.g., job J 4  may have to be initiated after J 1  completes, and J 7  may be initiate after J 4  completes. Note, however, that J 7  may be begun even before J 2  completes, as J 7  does not depend on J 2 —thus, in at least some embodiments, the prediction/test phase  3830  may overlap with the training phase if sufficient resources are available. For some tree ensemble-based algorithms such as Random Forest, hundreds of UDTs and PDTs may be generated for a given training set, and the use of parallelism may reduce both the training time and the execution time substantially relative to sequential approaches. In some embodiments, different run-time optimization goals may be applied to pruning different UDTs, while in other embodiments, the same set of run-time optimization goals may be applied to all the trees of an ensemble. Jobs for any of the different tasks illustrated (e.g., tree generation, tree pruning or model execution) that have met their dependencies may be executed in parallel at the thread level (e.g., different threads of execution may be used for the jobs on the same server), the process level (e.g., respective processes may be launched for multiple jobs to be run concurrently on the same server or different servers), or the server level (e.g., each job of a set of concurrently-schedulable jobs may be executed at a different thread/process at a respective MLS server) in various embodiments. Combinations of thread-level, process-level and server-level parallelism may be used in some embodiments—e.g., of four jobs to be run in parallel, two may be run at respective threads/processes at one MLS server, while two may be run at another MLS server. 
       FIG. 39  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service to generate and prune decision trees stored to persistent storage in depth-first order, according to at least some embodiments. As shown in element  3901 , a set of run-time optimization goals may be identified for a prediction-tree based model M 1  to be trained using a training data set TDS and executed at a machine learning service. A variety of goals may be determined and/or prioritized in different embodiments, including for example memory usage or footprint goals, utilization goals for other resources such as CPUs, prediction-time goals (e.g., the elapsed time for a prediction run of the model), prediction-time variation goals (e.g., reducing the differences between model prediction times for different observation records), prediction accuracy/quality goals, budget goals (e.g., the total amount that a client wishes to spend on model execution, which may be proportional to the CPU utilization of the model execution or to utilization levels of other resources), revenue/profit goals of the kind described above, and so on. In some embodiments, the training data set and/or indications of some or all of the optimization goals (or the relative priorities of the different goals) may be provided by an MLS client programmatically, e.g., via one or more MLS APIs. For example, in one embodiment an API to create a decision tree based model may be invoked by a client, with respective request parameters indicating the data set and one or more run-time goals. At least some of the goals may be qualitative instead of being expressed in exact quantities in some embodiments—e.g., it may not always be possible to indicate a precise target value for cumulative predictive utility, but a goal of maximizing cumulative predictive utility to the extent possible may still be used to guide pruning in some scenarios. 
     A tree-construction pass of M 1 &#39;s training phase may be initiated using some selected subset of all of the training data set. In some implementations, the training data (or at least pointers to the observation records of the training data) may be loaded into memory prior to the construction of the tree, and rearranged in memory based on the predicates evaluated at the nodes of the tree as the nodes are generated. During the tree-construction pass, the nodes of a decision tree may be generated in depth-first order in the depicted embodiment (element  3904 ), and node information such as the predicates being tested and the child node count or pointers to the child nodes may be streamed to persistent storage (e.g., rotating-disk based storage) in depth-first order. In the depicted embodiment, a predictive utility metric (PUM) value may be stored for at least some of the nodes, indicative of the contribution or utility of the nodes towards the predictions made by the model. Any of several types of statistical measures may be used as PUM values in different implementations, such as Gini impurity values, entropy measures, information gain measures, and so on. The PUM values may be used, for example in a subsequent tree-pruning pass of the training phase, to determine an order in which nodes can be pruned or removed from the tree without affecting the quality of the model predictions significantly. In some embodiments a histogram or a similar representation of the distribution of PUM among the tree&#39;s nodes may be generated during the tree construction pass. In other embodiments, the distribution information may be collected in a separate traversal of the tree. The terms “tree construction” and “tree creation” may be used as synonyms herein. 
     The constructed tree may be analyzed, e.g., in either a top-down greedy approach or a bottom-up approach, to identify some number of nodes that should be removed in view of the run-time optimization goals and/or the nodes&#39; PUM values in the depicted embodiment (element  3907 ). In some embodiments, the tree-pruning phase need not be performed, e.g., if the un-pruned tree already meets desired optimization goals. In at least one embodiment, it may be the case that none of the nodes of a given tree is pruned, e.g., because a cost-benefit analysis indicates that the removal is not worthwhile. The modified or pruned version of the decision tree may be stored (element  3910 ), e.g., in a separate location than the un-pruned tree, for use later during a test phase and/or production-level prediction runs of the model. 
     Depending on whether the model is ensemble-based or not, multiple trees may have to be constructed in some cases. If more trees are required (as determined in element  3913 ), a different sample of the training data set may be generated and the construction and pruning operations of elements  3904  onwards may be repeated. Although parallelism is not explicitly illustrated in  FIG. 39 , in some embodiments, as mentioned earlier, multiple trees may be constructed and/or pruned in parallel. In the depicted embodiment, after all the trees have been constructed and pruned, the model may be executed using the pruned tree(s) to obtain one or more sets of predictions (element  3916 ). Prediction runs corresponding to multiple pruned trees may be performed in parallel in some implementations. Metrics that can be used to determine whether the optimization goals were achieved during the prediction run(s) may be obtained in some embodiments. If all the goals were met to an adequate extent, as detected in element  3919 , the training and execution phases of the model may be considered complete (element  3928 ). If some goals (such as a desired level of accuracy) were not met, and if additional resources such as more memory are available (as detected in element  3922 ), in some embodiments the training and/or execution phases may be retried using additional resources (element  3925 ). Such retries may be repeated in some embodiments until the goals are met or no additional resources are available. The techniques described herein for generating and pruning trees based on training-time versus run-time tradeoffs may be used for various types of tree-based models in different embodiments, including for example CART (classification and regression tree) models, Random Forest models, and adaptive boosting models. In some embodiments, tree generation and tree pruning may be performed iteratively, e.g., with several different periods of tree generation and several different periods of tree pruning interspersed with each other during the training phase of the model. In such a scenario, some number of nodes may be generated and stored in depth first order in a first tree-generation period. Then, tree generation may be paused, the created nodes may be examined for pruning (e.g., based on their PUM values and on the optimization goals) in a first tree-pruning period, and some nodes may be removed based on the analysis. More nodes may be generated for the resulting tree in the next tree-generation period, followed by removal of zero or more nodes during the next tree-pruning period, and so on. Such iterative generation and pruning may help eliminate nodes with low utility from the tree earlier than in an approach in which the entire tree is generated before any nodes are pruned. 
     In at least one embodiment, a number of different components of the machine learning service may collectively perform the operations associated with decision tree optimizations. A client request for the training or creation of a tree-based model (e.g., either a model based on a single tree, or a model using an ensemble of trees), submitted via one or more APIs may be received at a request/response handler, which may determine the nature of the request and pass on the client request (or an internal representation of the client request) to a model generator or model manager. In some embodiments, each pass of the training phase may be performed by a respective MLS component—e.g., one or more tree generator components may create the trees in depth-first order and stream the node descriptors to persistent storage at one or more MLS servers, while one or more tree reducers may be responsible for pruning trees. In at least one embodiment, one or more training servers of the MLS may be used for training tree-based models, while one or more prediction servers may be used for the actual predictions. In embodiments in which respective jobs are created for different tasks, a job manager may be responsible for maintaining a collection or queue of outstanding jobs and for scheduling jobs as resources become available and job dependencies are met. Responses (e.g., an identifier of a tree-based model, or results of a prediction run) may be provided to the client by the front-end request/response handler in some embodiments. In at least some embodiments, some or all of these components may comprise specialized, tuned, or task-optimized hardware and/or software. 
     Optimizations for Training Linear Models 
     It is noted that in the context of the following discussion of optimizations for training linear models, the term “feature identifier” may refer to a unique identifier for a property derived from observation records of a data set to be used to train a model. The term “feature set” may refer to a set of feature identifiers for which (a) feature values are observable while training the model and (b) feature parameters are known or inferred from the training data. The term “feature” may refer to a value (e.g., either a single numerical, categorical, or binary value, or an array of such values) of a property of an observation record indexed by a feature identifier. The term “feature vector” may refer to a set of pairs or tuples of (feature identifiers, feature values), which may, for example, be stored in a key-value structure (such as a hash map) or a compressed vector. The term “feature parameter” or “parameter” may refer to a value of a parameter corresponding to a property indexed by the feature identifier. A real number representing a weight is one example of a parameter that may be used in some embodiments, although for some types of machine learning techniques more complex parameters (e.g., parameters that comprise multiple numerical values or probability distributions) may be used. The term “parameter vector” may refer to a set of pairs or tuples (feature identifier, parameter), which may also be stored in a key-value structure such as a hash map or a compressed vector. In at least some embodiments, a feature vector may be considered a transient structure (created for example for a given observation record that is examined during a learning iteration) that is used primarily to update the parameter vector and then discarded. In contrast, in some embodiments, the parameter vector may be retained for the duration of the training phase of the model, although as described below the parameter vector may grow and shrink during the training phase. Although key-value structures may be used for parameter vectors and/or feature vectors in some embodiments, other types of representations of parameter vectors and/or feature vectors may be employed in various embodiments. 
     Linear prediction models, such as various examples of generalized linear models, are among the most popular (and often most effective) approaches for dealing with many types of machine learning problems.  FIG. 40  illustrates an example procedure for generating and using linear prediction models, according to at least some embodiments. As shown, an unprocessed or raw training data set  5002  to be used to train a linear model may comprise some number of observation records (ORs)  5004 , such as ORs  5004 A,  5004 B, and  5004 B. Each OR  5004  may in turn comprise values of some number of input variables (IVs), such as IV 1 , IV 2 , IV 3 , IVn, and a value of at least one dependent variable DV. Dependent variables may also be referred to as “output” variables. In at least some embodiments, not all the observation records may be available before model training has to be begun—e.g., as described below in further detail, in some cases observation records may be streamed to a machine learning service as they become available from one or more online data sources. In such scenarios, the MLS may be responsible for training a model iteratively, e.g., with each iteration representing an attempt to improve the quality of the model&#39;s predictions based on the ORs analyzed up to that point. Such training iterations that are based on analysis of respective sets of observation records may also be termed “learning iterations” herein. 
     In at least some embodiments, a model generator component of the MLS may require that input variables to be used for generating features (that can then be used for training a linear model) meet certain data-type constraints. For example, in the depicted embodiment, the model generator may require that the raw values of categorical IVs of the training data be converted into numerical values and/or normalized (e.g., by mapping the numerical values to real numbers between −1 and 1). Such type transformations may be performed during an initial data preparation phase  5010 , producing a set of modified or prepared observation records  5015 . 
     The linear model may then be trained iteratively in the depicted embodiment, e.g., using a plurality of learning iterations  5020 . Initially, in at least some implementations, an empty parameter vector  5025  may be created. The parameter vector  5025  may be used to store parameters (e.g., real numbers that represent respective weights) assigned to a collection of features or processed variable values, where the features are derived from the observation record contents using one or more feature processing transformations (FPTs) of the types described earlier. When making a prediction of a dependent variable value for a give observation record, a linear model may compute the weighted sum of the features whose weights are included in the parameter vector in some implementations. In at least some embodiments, a key-value structure such as a hash map may be used for the parameter vector  5025 , with feature identifiers (assigned by the model generator) as keys, and the parameters as respective values stored for each key. For example, parameters W 1 , W 2 , and Wm shown in  FIG. 40  are assigned respectively to features with feature identifiers F 1 , F 2 , and Fm. 
     During each learning iteration  5020 , one or more prepared ORs  5015  may be examined by the model generator (which may also be referred to as a model trainer). Based on the examination of the input variables in the prepared OR, and/or the accuracy of a prediction for the dependent variables of the prepared OR by the model in its current state, respective parameters or weights may be identified for a new set of one or more processed variables. In at least some implementations, the previously-stored parameters or weights may be updated if needed in one or more learning iterations, e.g., using a stochastic gradient descent technique or some similar optimization approach. As more and more observation records are examined, more and more (feature identifier, parameter) key-value pairs may be added into the parameter vector. As described below with reference to  FIG. 41 , this growth of the parameter vector, if left unchecked, may eventually lead to a scenario in which the memory available at an MLS server being used for the model generator is exhausted and an out-of-memory error may end the training phase of the model prematurely. 
     To avoid such undesirable scenarios, a technique for pruning selected parameters (i.e., removing entries for selected features from the parameter vector) may be employed in some embodiments. According to such a technique, when certain triggering conditions are met (e.g., when the number of features for which parameters are stored in the parameter vector exceeds a threshold), a fraction of the features that contribute least to the models&#39; predictions may be identified as pruning victims (i.e., features whose entries are removed or “pruned” from the parameter vector). An efficient in-memory technique to estimate quantile boundary values (e.g., the 20% of the features that contribute the least to the model&#39;s predictions) for parameters may be used in some embodiments, without requiring copying of the parameters or an explicit sort operation. More generally, the importance or contribution of a given feature to the predictive performance of the model (e.g., the accuracy or quality of the model&#39;s predictions) may be determined by the deviation of the corresponding parameter value from an “a-priori parameter value” in at least some embodiments. The efficient in-memory technique described below for estimating quantile boundary values may represent one specific example of using such deviations to select pruning victims, relevant in scenarios in which a scalar weight value is used as a parameter value, the a priori parameter value is zero, and the relative contributions correspond to the absolute values of the weights (the respective “distances” of the weights from zero). For models in which the parameters are vectors of values, and the a priori value is a vector of zeros, a similar approach involving the computation of the distance of a particular vector parameter from the vector of zeros may be used. For some types of models, the parameters may comprise probability distributions rather than scalars. In one embodiment in which parameters comprise probability distributions, the relative contributions of different features represented in a parameter vector may be obtained by estimating Kullback-Leibler (KL) divergence from the a-priori values, and such divergence estimates may be used to identify features whose parameters should be pruned. 
     Entries (e.g., parameter values) for the pruning victims identified may be removed from the parameter vector  5025 , thus reducing the memory consumed. However, additional learning iterations may be performed even after pruning some parameters. Thus, the parameter vector size may grow and shrink repeatedly as more observation records are considered, more parameters are added, and more parameters are pruned. It is noted that the terms “pruning a parameter” or “pruning a feature” may be used synonymously herein to refer to the removal of a particular entry comprising a (feature identifier, parameter) pair from a parameter vector. In at least some implementations, a parameter for a particular feature that was pruned in one learning iteration may even be re-added to the parameter vector later, e.g., in response to a determination by the model generator (based on additional observation records) that the feature is more useful for predictions than at the time when it was pruned. The value of the re-added parameter may differ from the value that was removed earlier in some cases. 
     After some number of learning iterations during which the parameter vector may have grown and shrunk a number of times, the linear model may be executed using the current parameter vector. In some embodiments, the parameter vector  5025  may be “frozen” (e.g., an immutable representation of the parameter vector as of a particular point in time may be stored in an MLS artifact repository) prior to model execution  5040  for predictions  5072  on a production or test data set  5050 . In other embodiments, even after the model is used to make production or test runs, additional learning iterations  5020  may be performed using new observation records. In scenarios in which a parameter vector is frozen for production use or testing, additional learning iterations may continue on a non-frozen or modifiable version of the parameter vector. In various embodiments, operations on either side of the boundary indicated by the dashed line in  FIG. 40  may be interspersed with one another—e.g., one or more learning iterations during which the parameter vector is modified based on new observation data may be followed by a production run of the model, and the production run may be followed by more learning iterations, and so on. 
       FIG. 41  illustrates an example scenario in which the memory capacity of a machine learning server that is used for training a model may become a constraint on parameter vector size, according to at least some embodiments. As discussed earlier, a wide variety of feature processing transformations (FPTs) may be supported at a machine learning service for input variables in various embodiments, and at least some FPTs may be chained in a sequence—i.e., applied to features that have been generated using other FPTs. Supported feature processing transformation functions may include, for example, quantile bin functions  5154  for numerical variables, Cartesian product functions  5150  for various types of variables, n-gram functions  5152  for text, calendar functions, domain-specific transformation functions  5156  such as image processing functions, audio processing functions, video processing functions, bio-informatics processing functions, natural language processing functions other than n-grams, and so on. Depending on the data type of an input variable, one or more FPTs may be applied to it, and additional FPTs may be applied to the results. For example, new features comprising Cartesian products of n-grams, quantile bins, and/or domain-specific transformations may be created in the depicted embodiment. The number  5133  of possible feature processing transformations and combinations may be very large, which could lead to a parameter vector  5144  that is unbounded in size. In some implementations, the various features identified may be mapped to a vector of real numbers, where the dimension of the vector may be arbitrarily large at least in principle. 
     At least in some implementations, a significant portion or all of the learning iterations of a particular model may be intended to be performed on a single MLS server such as server  5160  (e.g., using one or more threads of execution at such a server). In some such implementations, the parameter vector for the model may be required to fit in the main memory  5170  of the MLS server  5160 . If the in-memory parameter vector representation  5180  grows too large, the process or thread used for learning may exit prematurely with an out-of-memory error, and at least some of the learning iterations may have to be re-implemented. As shown in memory requirement graph  5175 , the MLS server memory requirement may grow in a non-linear fashion with the number of input variables and/or observation records examined. It is noted that the requirement graph  5175  is not intended to illustrate an exact relationship between the number of observations and the possible parameter vector size for any given machine learning problem; instead, it is intended to convey general trends that may be observed in such relationships. 
     In some conventional machine learning systems, the training of a model may simply be terminated when the number of features whose parameters are stored in the parameter vector reaches a selected maximum. This means that in such approaches, features that may otherwise have been identified later as significant contributors to prediction quality may never be considered for representation in the parameter vector. In another common technique, different features may be combined disjunctively using hash functions (e.g., to save space, only N bits of K bits of a hash value that would otherwise represent a particular feature may be used, with the N bits being selected using a modulo function), which may also result in reduction in the quality of the predictions. In some machine learning systems, one or more regularization techniques may be used, in which the weights or parameters assigned to different features may be reduced by some factor in various learning iterations, and as a result, some features may gradually be eliminated from the parameter vector (with their weights approaching zero). However, when used by itself for constraining parameter vector size, regularization may result in relatively poor quality of model prediction. Regularization may also require a selection of one or more hyper-parameters (such as the reduction factors to use), which may not be straightforward. It is noted that even in embodiments in which the parameter pruning techniques described below are implemented, regularization may still be used for various reasons (such as to prevent over-fitting, or to at least contribute to parameter vector size reduction). 
     A technique that imposes limits on the size of the parameter vector used for a linear model, without sacrificing the quality of the predictions made and without restricting the set of features based on how early during the training phase the features are identified may be utilized in some embodiments. According to this technique, when a triggering condition is met, parameters corresponding to a subset of the features identified thus far may be pruned from the parameter vector (effectively replacing the removed parameter values with a default or a priori value). As indicated earlier, such features may be referred to herein as “pruning victim features” or more simply as “pruning victims”. An efficient estimation technique to identify a selected fraction or quantile of the features that contribute the least to the predictions of the model may be used to identify the pruning victims in some implementations as described below. At least in some implementations, such a technique may not require explicitly sorting the parameters or copying the parameters. After parameters corresponding to the pruning victim features have been pruned, parameters for additional features may be added, e.g., in subsequent learning iterations. In some cases, a parameter for a given feature that was selected as a pruning victim earlier may be re-introduced into the parameter vector if later observations indicate that the given feature may be more useful for prediction than it was expected to be when it was pruned. 
       FIG. 42  illustrates such a technique in which a subset of features for which respective parameter values are stored in a parameter vector during training may be selected as pruning victims, according to at least some embodiments. Four learning iterations  5210 A,  5210 B,  5210 K and  5210 L are shown. In each learning iteration, a respective observation record set (ORS)  5202  (e.g., ORS  5202 A in learning iteration  5210 A, ORS  5202 B in learning iteration  5210 B, and so on) comprising one or more observation records may be examined by the model generator to determine whether any new parameters should be added to the parameter vector. In addition, earlier-generated parameter values may be updated or adjusted in at least some embodiments, e.g., using a stochastic gradient technique. After learning iteration  5210 , the parameter vector comprises parameters  5222 A corresponding to feature identifiers  5212 A. After the next learning iteration  5210 B, the parameter vector has grown and now comprises parameters  5222 B for feature identifiers  5212 B (and some or all of the parameters set in learning iteration  5210 A may have been adjusted or changed). 
     As additional learning iterations are performed, more parameters may be added to the parameter vector. Eventually, during or after some learning iteration  5210 K, the model generator may determine that a threshold parameter vector size PVS has been exceeded, and may perform a pruning analysis. It is noted that at least in some embodiments, operations to detect whether the triggering condition for pruning has been met may not be performed in or after every learning iteration, as such frequent pruning may be unnecessary. Instead, such checks may be performed periodically, e.g., based on the number of learning iterations that have been performed since such a check was last completed, or based on the time that has elapsed since such a check was last performed, or based on the number of observation records that have been examined since a check was last performed. In at least some embodiments, the PVS may be based at least in part on (e.g., set to some fraction of) the memory capacity of an MLS server, or the triggering condition may be based on some other server resource capacity constraint such as CPU utilization limits. In one embodiment, a client on whose behalf the linear model is being trained may indicate one or more goals for training (e.g., that a server with no more than X gigabytes of memory is to be used for training) and/or for post-training execution, and such goals may influence the value of PVS. In various embodiments, PVS may be expressed in terms of the number of parameters included in the parameter vector, or simply in terms of the amount of memory consumed by the parameter vector. 
     In the pruning analysis, the model generator may identify some selected number (or some selected fraction) of the features whose parameters are to be removed. In one embodiment, for example, the 10% least significant features may be identified, e.g., based on the absolute values of weights assigned to the features represented in the parameter vector. In some embodiments, as mentioned above, the relative contribution of the features to a prediction (which is computed at least in part using the weighted sums of the feature values) may be assumed to be proportional to the absolute value of their weights. The task of identifying the 10% least important features may thus be equivalent to identifying the 10% of the weights that have the smallest absolute value. An exact identification of such a fraction of the features may require sorting the absolute values of the weights of the entire parameter vector, which may pose resource consumption problems of its own for large parameter vectors—e.g., a substantial amount of memory, CPU cycles and/or persistent storage may be required for such sort operations. Accordingly, an optimization may be used in some implementations to find an approximate boundary weight for the selected fraction (i.e., the weight Wk such that approximately 10% of the features have smaller absolute weights and the remaining approximately 90% have higher absolute weights), without sorting the weights or copying the weights. An example of such an optimization technique is described below in conjunction with the discussion of  FIG. 45 . After the boundary for the selected quantile (e.g., 10% in the above example) is estimated, weights whose absolute values are below the boundary may be easily identified, and the entries for such weights may be removed from the parameter vector. It is noted that although weights are discussed herein as a simple example of the kinds of parameters that may be stored, similar techniques may be used to determine pruning candidates when more complex parameters (e.g., parameter structures that include more than just a single real number) are used. That is, the pruning technique described is not restricted to embodiments in which a single numerical quantity (such as a weight with a real number value) is used as a parameter. More complex parameters may be transformed, for example, into numerical values that approximate the relative contributions of the corresponding features to the predictions made by the model. As mentioned earlier, different measures of deviations of specific parameter values from a priori values may be used in various embodiments to estimate the relative contributions of the parameters, depending on the types of parameters being used for the model. 
     After some subset of the features have been identified as pruning candidates and their parameters are removed, as indicated by the arrow labeled  5255  in  FIG. 42 , the pruned parameter vector (comprising adjusted parameters  5222 K* for feature identifiers  5212 K*) may no longer violate the PVS constraint. In at least some embodiments, a sufficiently large fraction of the parameter vector may be pruned that additional parameters may again be added in one or more subsequent learning iterations, such as learning iteration  5210 L shown in  FIG. 42 . Thus, the parameter vector size may grow again after being reduced via pruning. Additional pruning may be required if the parameter vector size again exceeds PVS eventually, and more parameters may be added after the additional pruning is completed. A parameter corresponding to any feature may be added to the parameter vector in a given learning iteration, including for example parameters corresponding to features that were selected as pruning victims earlier. By not restricting the set of features that can be considered for representation in the parameter vector during any learning iteration, and eliminating only those parameters at each pruning stage that are currently identified as contributing the least to the model&#39;s predictions, the technique illustrated in  FIG. 42  may converge on a parameter vector that provides highly accurate predictions while limiting memory use during training. In addition, the reduction in the parameter vector size may also reduce the time it takes to load and execute the model during prediction runs—thus, the benefits of the technique may be obtained both during the training phase and in post-training-phase prediction runs. 
     The approach of iterative learning described above, in which the parameter vector membership may decrease and increase over time, may be especially useful in embodiments in which observation records may be streamed to the MLS from a variety of data sources. In such scenarios, compared to environments in which the entire training data set is collected prior to any of the learning iterations, it may be even more helpful to be able to reconsider features whose parameters have been pruned earlier, and in general to keep modifying the parameter vector as more observation records arrive. The characteristics of the observation records (e.g., the distributions of the values of various input variables) may change over time, for example, making it more likely that the parameter vector that can make the best predictions will also change over time. 
       FIG. 43  illustrates a system in which observation records to be used for learning iterations of a linear model&#39;s training phase may be streamed to a machine learning service, according to at least some embodiments. As shown, a data receiver endpoint  5308  (e.g., a network address or a uniform resource identifier) may be established at the MLS for receiving observation records from one or more streaming data sources (SDSs)  5302 , such as SDS  5302 A, SDS  5302 B and SDS  5302 C. Such data sources may, for example, include web server logs of a geographically distributed application, sensor-based data collectors, and the like. The observation records (ORs) from such data sources may arrive in arbitrary order—e.g., OR 1  from SDS  5302 A may be received first, followed by OR 2  from SDS  5302 C, OR 3  and OR 4  from SDS  5302 B, and so on. 
     At the model generator the records may be used for learning iterations in the order in which they arrive in the depicted embodiment. For example, OR 1 , OR 2  and OR 3  may be examined during a first set of learning iterations  5333 A, resulting in the generation of a particular parameter vector. The learning iteration set  5333 A may be followed by a pruning iteration  5334  in which some selected parameters are removed from the parameter vector based on their relative contributions to the predictions of the model being trained. Pruning iteration  5334  may be followed by another learning iteration set  5333 B, in which OR 4 , OR 5  and OR 6  are examined and parameters for one or more new features (and/or features whose parameters were previously pruned) are added to the parameter vector. Over time, the parameter vector may evolve to provide accurate predictions for data from all the streaming data sources  5302 . In some embodiments, pruning iterations  5334  may be scheduled at regular intervals, e.g., once every X seconds, regardless of the rate at which observation records are received or examined. Such schedule-based pruning may help the MLS to respond to wide fluctuations in observation record arrival rates—e.g. to prevent out-of-memory errors resulting from a sudden burst of observation records that arrive at a time at which the parameter vector size is already close to its maximum threshold. 
       FIG. 44  is a flow diagram illustrating aspects of operations that may be performed at a machine learning service at which, in response to a detection of a triggering condition, parameters corresponding to one or more features may be pruned from a parameter vector to reduce memory consumption during training, according to at least some embodiments. As shown in element  5401 , an indication of a data source from which unprocessed or raw observation records of a training data set that is to be used to develop a linear predictive model may be received at a machine learning service. In at least some embodiments, the data source may be indicated by a client via an MLS programmatic interface such as an API, a web-based console, a standalone GUI or a command line tool. The linear predictive model may, for example, be expected to make predictions based at least in part on weighted sums of feature values derived from the training data via one or more feature processing transformations (FPTs) of the types described earlier. In some implementations, a job object for generating/training the model may be created in response to the invocation of the API by the client and placed in a job queue such as queue  142  of  FIG. 1 . The job may be scheduled, e.g., asynchronously, on a selected training server (or a set of training servers) of the MLS server pool(s)  185 . 
     The process of training the model may be initiated (e.g., when the queued job is scheduled). An empty parameter vector may be initialized (element  5404 ) and one or more settings to be used during the training phase of the model may be determined—e.g., the threshold condition that is to be used to trigger pruning may be identified, the fraction of parameters that is to be pruned each time such a threshold condition is detected may be identified, and so on. The threshold may be based on a variety of factors in different implementations, such as the maximum number of parameters that can be included in the parameter vector, the memory capacity of the MLS server(s) used for training the model, and/or goals indicated by the client. Client-provided goals from which the threshold may be derived may include, for example, limits on various types of resources that can be consumed during training and/or during post-training runs of the model, including memory, CPU, network bandwidth, disk space and the like. In some embodiments, a client may specify a budget goal for the training and/or for prediction runs, and the budget may be translated into corresponding resource limits at a component of the MLS. 
     A model generator or trainer may then begin implementing one or more learning iterations in the depicted embodiment. A set of one or more observation records may be identified for the next learning iteration (element  5407 ). Depending on the nature of the observation records, some preliminary data type transformations and/or normalization operations may have to be performed (element  5410 ). For example, some model generators may require that categorical input variables be converted into numerical or Boolean variables, and/or that numerical variable values be mapped to real numbers in the range −1 to 1. One or more new features for which parameters such as weights are to be added to the parameter vector may be identified (element  5413 ). In some cases, a new entry for a feature was selected as a pruning victim earlier may be re-inserted into the parameter vector. The parameter value for such a re-added entry may differ from the parameter value of the previously pruned entry in some cases, while the parameter values of the original and re-introduced entries may be the same in other cases. A key-value structure such as a hash map or hash table may be used to store (feature identifier, parameter) pairs of the parameter vector in some implementations, e.g., with feature identifiers as the keys. In some embodiments, one or more previously-generated parameter values may also be updated at this stage, e.g., using a stochastic gradient descent technique. 
     If the model generator determines that the threshold condition (identified in operations corresponding to element  5404 ) for triggering a round of pruning has been met (element  5416 ), one or more features may be identified as pruning victims (element  5419 ). In the depicted embodiment, the features that contribute the least to the models&#39; predictions, e.g. by virtue of having the smallest absolute weights, may be selected as pruning victims. The manner in which the relative contributions of different features are determined or estimated, and the manner in which the features expected to provide the smallest contributions are identified, may differ in various embodiments. In some embodiments in which each feature is assigned a respective real number as a weight, an efficient estimation technique that does not require sorting or copying of the weights and can estimate a quantile boundary value among the weights in a single in-memory pass over the parameter vector may be used. After the quantile boundary (e.g., the weight representing the estimated 10 th  percentile or the estimated 20 th  percentile among the range of absolute values of the weights represented in the parameter vector) is identified, entries for features with lower weights may be removed from the parameter vector. The memory consumed by the parameter vector may be reduced by the removal of the entries corresponding to the pruning victims (element  5422 ). 
     If the learning iterations have been completed (as detected in element  5425 ), the trained model may be used for generating predictions on production data, test data, and/or on other post-training-phase data sets (element  5428 ). Learning iterations may be deemed to be complete if, for example, all the observation records expected to be available have been examined, or if the accuracy of the predictions that can be made by the model on the basis of the learning iterations performed thus far meets an acceptance criteria. If additional learning iterations are to be performed (as also detected in element  5425 ), operations corresponding to elements  5407  onwards may be repeated—e.g., a new set of one or more observation records may be identified, the raw data may be transformed as needed, parameters for new features may be added to the parameter vector, and so on. In some cases, at least some additional learning iterations may be performed on observation records that have already been examined. 
     As mentioned earlier, pruning victims may be selected from the features represented in a parameter vector based on an analysis of the relative contribution or relative significance of the individual features with respect to model predictions.  FIG. 45  illustrates a single-pass technique that may be used to determine quantile boundary estimates of the absolute values of weights assigned to features, according to at least some embodiments. A set of weights W 1 , W 2 , . . . Wm corresponding to respective features F 1 , F 2 , . . . , Fm may be examined in memory, e.g., without copying the weights and without explicitly sorting the weights. In the depicted embodiment, the quantile for which a boundary value is to be obtained is referred to as “tau”. Thus, for example, if the boundary between the lowest 20% of the absolute values of weights and the remaining 80% of the weights is to be identified, tau may be set to 0.2. The boundary itself is referred to as “phi-tau”. Initially, as shown in element  5502 , tau and another parameter “eta” (representing a learning rate to be used to determine phi-tau) may be determined and phi-tau may be set to zero. Then, the next weight Wj may be examined and its absolute value abs(Wj) may be obtained (element  5505 ). If abs(Wj) is greater than phi-tau, as determined in element  5508 , phi-tau may be increased by adding (tau*eta), the product of tau and eta. If abs(Wj) is not greater than phi-tau, phi-tau may be reduced by subtracting (1−tau)*eta (element  5511 ). If more weights remain to be examined (as detected in element  5517 ), the operations corresponding to elements  5505  onwards may be repeated. Otherwise, after all the weights have been examined, the estimation of the quantile boundary phi-tau may be complete (element  5520 ). The value of phi-tau at the end of the procedure illustrated in  FIG. 45  may then be used to select the pruning victims—e.g., features with weights whose absolute values are less than phi-tau may be chosen as victims, while features with weights whose absolute values are no less than phi-tau may be retained. In at least some implementations, the learning rate (eta) may be modified or adjusted during the quantile boundary estimation procedure; that is, eta need not remain constant. 
     It is noted that in various embodiments, operations other than those illustrated in the flow diagrams of  FIGS. 9 a , 9 b , 10 a , 10 b   ,  17 ,  25 ,  32 ,  39 ,  44  and  45  may be used to implement at least some of the techniques of a machine learning service described above. Some of the operations shown may not be implemented in some embodiments, may be implemented in a different order, or in parallel rather than sequentially. For example, with respect to  FIG. 9 b   , a check as to whether the client&#39;s resource quota has been exhausted may be performed subsequent to determining the workload strategy in some embodiments, instead of being performed before the strategy is determined. 
     Use Cases 
     The techniques described above, of providing a network-accessible, scalable machine learning service that is geared towards users with a wide range of expertise levels in machine learning tools and methodologies may be beneficial for a wide variety of applications. Almost every business organization or government entity is capable of collecting data on various aspects its operations today, and the discovery of meaningful statistical and/or causal relationships between different components of the collected data and the organization&#39;s objectives may be facilitated by such a service. Users of the MLS may not have to concern themselves with the details of provisioning the specific resources needed for various tasks of machine learning workflows, such as data cleansing, input filtering, transformations of cleansed data into a format that can be fed into models, or model execution. Best practices developed over years of experience with different data cleansing approaches, transformation types, parameter settings for transformations as well as models may be incorporated into the programmatic interfaces (such as easy-to learn and easy-to-use APIs) of the MLS, e.g., in the form of default settings that users need not even specify. Users of the MLS may submit requests for various machine learning tasks or operations, some of which may depend on the completion of other tasks, without having to manually manage the scheduling or monitor the progress of the tasks (some of which may take hours or days, depending on the nature of the task or the size of the data set involved). 
     A logically centralized repository of machine learning objects corresponding to numerous types of entities (such as models, data sources, or recipes) may enable multiple users or collaborators to share and re-use feature-processing recipes on a variety of data sets. Expert users or model developers may add to the core functionality of the MLS by registering third-party or custom libraries and functions. The MLS may support isolated execution of certain types of operations for which enhanced security is required. The MLS may be used for, and may incorporate techniques optimized for, a variety of problem domains covering both supervised and unsupervised learning, such as, fraud detection, financial asset price predictions, insurance analysis, weather prediction, geophysical analysis, image/video processing, audio processing, natural language processing, medicine and bioinformatics and so on. Specific optimization techniques such as pruning of depth-first decision trees or limiting the size of linear models by efficiently pruning feature weights may be implemented by default in some cases without the MLS clients even being aware of the use of the techniques. For other types of optimizations, such as optimizations between training-time resource usage and prediction-time resource usage, clients may interact with the machine learning service to decide upon a mutually acceptable feature processing proposal. 
     Illustrative Computer System 
     In at least some embodiments, a server that implements one or more of the components of a machine learning service (including control-plane components such as API request handlers, input record handlers, recipe validators and recipe run-time managers, feature processing managers, plan generators, job schedulers, artifact repositories, and the like, as well as data plane components such as MLS servers implementing decision tree optimizations and/or category-based sampling) may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media.  FIG. 46  illustrates such a general-purpose computing device  9000 . In the illustrated embodiment, computing device  9000  includes one or more processors  9010  coupled to a system memory  9020  (which may comprise both non-volatile and volatile memory modules) via an input/output (I/O) interface  9030 . Computing device  9000  further includes a network interface  9040  coupled to I/O interface  9030 . 
     In various embodiments, computing device  9000  may be a uniprocessor system including one processor  9010 , or a multiprocessor system including several processors  9010  (e.g., two, four, eight, or another suitable number). Processors  9010  may be any suitable processors capable of executing instructions. For example, in various embodiments, processors  9010  may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors  9010  may commonly, but not necessarily, implement the same ISA. In some implementations, graphics processing units (GPUs) may be used instead of, or in addition to, conventional processors. 
     System memory  9020  may be configured to store instructions and data accessible by processor(s)  9010 . In at least some embodiments, the system memory  9020  may comprise both volatile and non-volatile portions; in other embodiments, only volatile memory may be used. In various embodiments, the volatile portion of system memory  9020  may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM or any other type of memory. For the non-volatile portion of system memory (which may comprise one or more NVDIMMs, for example), in some embodiments flash-based memory devices, including NAND-flash devices, may be used. In at least some embodiments, the non-volatile portion of the system memory may include a power source, such as a supercapacitor or other power storage device (e.g., a battery). In various embodiments, memristor based resistive random access memory (ReRAM), three-dimensional NAND technologies, Ferroelectric RAM, magnetoresistive RAM (MRAM), or any of various types of phase change memory (PCM) may be used at least for the non-volatile portion of system memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory  9020  as code  9025  and data  9026 . 
     In one embodiment, I/O interface  9030  may be configured to coordinate I/O traffic between processor  9010 , system memory  9020 , and any peripheral devices in the device, including network interface  9040  or other peripheral interfaces such as various types of persistent and/or volatile storage devices. In some embodiments, I/O interface  9030  may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory  9020 ) into a format suitable for use by another component (e.g., processor  9010 ). In some embodiments, I/O interface  9030  may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface  9030  may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface  9030 , such as an interface to system memory  9020 , may be incorporated directly into processor  9010 . 
     Network interface  9040  may be configured to allow data to be exchanged between computing device  9000  and other devices  9060  attached to a network or networks  9050 , such as other computer systems or devices as illustrated in  FIG. 1  through  FIG. 45 , for example. In various embodiments, network interface  9040  may support communication via any suitable wired or wireless general data networks, such as types of Ethernet network, for example. Additionally, network interface  9040  may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol. 
     In some embodiments, system memory  9020  may be one embodiment of a computer-accessible medium configured to store program instructions and data as described above for  FIG. 1  through  FIG. 45  for implementing embodiments of the corresponding methods and apparatus. However, in other embodiments, program instructions and/or data may be received, sent or stored upon different types of computer-accessible media. Generally speaking, a computer-accessible medium may include non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to computing device  9000  via I/O interface  9030 . A non-transitory computer-accessible storage medium may also include any volatile or non-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of computing device  9000  as system memory  9020  or another type of memory. Further, a computer-accessible medium may include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link, such as may be implemented via network interface  9040 . Portions or all of multiple computing devices such as that illustrated in  FIG. 46  may be used to implement the described functionality in various embodiments; for example, software components running on a variety of different devices and servers may collaborate to provide the functionality. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or special-purpose computer systems, in addition to or instead of being implemented using general-purpose computer systems. The term “computing device”, as used herein, refers to at least all these types of devices, and is not limited to these types of devices. 
     Embodiments of the disclosure can be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         receive, via a particular programmatic interface of a set of programmatic interfaces implemented at a network-accessible machine learning service of a provider network, a first request from a client to perform a particular operation associated with an instance of an entity type, wherein the entity type comprises one or more of: (a) a data source to be used for a machine learning model, (b) a set of statistics to be computed from a particular data source, (c) a set of feature processing transformation operations to be performed on a specified data set, (d) a machine learning model employing a selected algorithm, (e) an alias associated with a machine learning model, or (f) a result of a particular machine learning model;   insert a job object corresponding to the first request in a job queue of the machine learning service;   provide an indication to the client that the first request has been accepted for execution;   determine, in accordance with a first workload distribution strategy identified for the first request, a first set of provider network resources to be used to perform the particular operation;   receive, prior to a completion of the particular operation indicated in the first request, a second request from the client to perform a second operation dependent on a result of the particular operation;   insert a second job object corresponding to the second request in the job queue, wherein the second job object includes an indication of a dependency of the second operation on a result of the particular operation;   prior to initiating execution of the second operation, provide a second indication to the client that the second request has been accepted for execution; and   in response to a determination that the particular operation has been completed successfully, schedule the second operation on a second set of provider network resources.       

     2. The system as recited in clause 1, wherein the particular operation comprises one or more of: (a) a creation of the instance, (b) a read operation to obtain respective values of one or more attributes of the instance, (c) a modification of an attribute of the instance, (d) a deletion of the instance, (e) a search operation, or (f) an execute operation. 
     3. The system as recited in any of clauses 1-2, wherein the particular operation comprises assignment of an alias usable by a designated group of users of the machine learning service to execute a particular machine learning model, wherein the alias comprises a pointer to the particular machine learning model, wherein at least some users of the designated group of users are not permitted to modify the pointer. 
     4. The system as recited in any of clauses 1-3, wherein the set of programmatic interfaces comprises a representational state transfer application programming interface. 
     5. The system as recited in any of clauses 1-4, wherein the particular operation comprises a creation of a particular data source, wherein the one or more computing devices are further configured to:
         generate a particular set of statistics on one or more variables of data records of the particular data source, without receiving a request from the client for the particular set of statistics; and   provide, to the client, an indication of the particular set of statistics.       

     6. A method, comprising: 
     performing, by one or more computing devices:
         receiving, via a particular programmatic interface of a set of programmatic interfaces implemented at a machine learning service, a first request from a client to perform a particular operation associated with an instance of an entity type, wherein the entity type comprises one or more of: (a) a data source to be used for generating a machine learning model, (b) a set of feature processing transformation operations to be performed on a specified data set, (c) a machine learning model employing a selected algorithm, or (d) an alias associated with a machine learning model;   inserting a job corresponding to the first request in a job queue of the machine learning service;   receiving, prior to a completion of the particular operation indicated in the first request, a second request from the client to perform a second operation dependent on a result of the particular operation;   inserting a second job object corresponding to the second request in the job queue, wherein the second job object includes an indication of a dependency of the second operation on a result of the particular operation; and   in response to determining that the particular operation has been completed successfully, scheduling the second operation.       

     7. The method as recited in clause 6, wherein the particular operation comprises one or more of: (a) a creation of the instance, (b) a read operation to obtain respective values of one or more attributes of the instance, (c) a modification of an attribute of the instance, (d) a deletion of the instance, (e) a search operation, or (f) an execute operation. 
     8. The method as recited in any of clauses 6-7, wherein the particular operation comprises assignment of an alias usable by a designated group of users of the machine learning service to execute a particular machine learning model, wherein the alias comprises a pointer to the particular machine learning model, wherein at least some users of the designated group of users are not permitted to modify the pointer. 
     9. The method as recited in any of clauses 6-8, wherein the particular operation comprises a creation of a particular data source, further comprising performing, by the one or more computing devices:
         generating a particular set of statistics on one or more variables of data records of the particular data source, without receiving a request from the client for the particular set of statistics; and   providing, to the client, an indication of the particular set of statistics.       

     10. The method as recited in clause 9, further comprising performing, by the one or more computing devices:
         selecting a subset of the data records of the particular data source to be used to generate the particular set of statistics.       

     11. The method as recited in any of clauses 6-9, further comprising performing, by the one or more computing devices:
         identifying a workload distribution strategy for the first request, wherein said identifying comprises one or more of: (a) determining a number of passes of processing a data set of the particular operation (b) determining a parallelization level for processing a data set of the particular operation, (c) determining a convergence criterion to be used to terminate the particular operation, (d) determining a target durability level for intermediate data produced during the particular operation, or (e) determining a resource capacity limit for implementing the particular operation.       

     12. The method as recited in clause 11, further comprising performing, by the one or more computing devices:
         selecting a particular set of provider network resources to implement the first workload strategy.       

     13. The method as recited in any of clauses 6-9 or 11, further comprising performing, by the one or more computing devices:
         in response to determining that performing the particular operation includes an execution of a module developed by an entity external to the provider network, identifying a particular security container from which to select at least one resource to be used for the particular operation.       

     14. The method as recited in any of clauses 6-9, 11 or 13, further comprising performing, by the one or more computing devices:
         providing, to the client, an executable version of a particular machine learning model for execution at a platform outside the provider network.       

     15. The method as recited in any of clauses 6-9, 11, or 13-14, further comprising performing, by the one or more computing devices:
         verifying, prior to scheduling the particular operation, that a resource quota of the client has not been exhausted.       

     16. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors:
         receive, via a particular programmatic interface of a set of programmatic interfaces implemented at a network-accessible machine learning service of a provider network, a first request from a client to perform a particular operation associated with an instance of an entity type, wherein the entity type comprises one or more of: (a) a data source to be used for generating a machine learning model, (b) a set of statistics to be computed from a particular data source, (c) a machine learning model employing a selected algorithm, or (d) an alias associated with a machine learning model;   insert a job corresponding to the first request in a job queue of the machine learning service;   receive, prior to a completion of the particular operation indicated in the first request, a second request from the client to perform a second operation dependent on a result of the particular operation; and   insert a second job object corresponding to the second request in the job queue, wherein the second job object includes an indication of a dependency of the second operation on a result of the particular operation.       

     17. The non-transitory computer-accessible storage medium as recited in clause 16, wherein the particular operation comprises assignment of an alias usable by a designated group of users of the machine learning service to execute a particular machine learning model, wherein the alias comprises a pointer to the particular machine learning model, wherein at least some users of the designated group of users are not permitted to modify the pointer. 
     18. The non-transitory computer-accessible storage medium as recited in any of clauses 16-17, wherein the particular operation comprises a creation of a particular data source, wherein the instructions when executed at the one or more processors:
         generate a particular set of statistics on one or more variables of data records of the particular data source, without receiving a request from the client for the particular set of statistics; and   provide, to the client, an indication of the particular set of statistics.       

     19. The non-transitory computer-accessible storage medium as recited in clause 18, wherein one or more variables comprise a plurality of variables, and wherein the instructions when executed on the one or more processors:
         identify, based at least in part on a correlation analysis of the plurality of variables, a first set of candidate variables to be used in preference to a second set of variables as inputs to a machine learning model; and   provide an indication of the first set of variables to the client.       

     20. The non-transitory computer-accessible storage medium as recited in any of clauses 16-18, wherein the particular operation comprises an instantiated of a particular machine learning model in online mode, wherein the instructions when executed on the one or more processors:
         select a set of provider network resources to be used for the particular machine learning model in online mode based at least in part on an expected workload level indicated by the client.       

     21. The non-transitory computer-accessible storage medium as recited in any of clauses 16-18 or 20, wherein the instructions when executed on the one or more processors:
         receive, from the client of the service, credentials to be used to decrypt one or more data records of a particular data source to perform the particular operation.       

     22. The non-transitory computer-accessible storage medium as recited in any of clauses 16-18 or 20-21, wherein the instructions when executed on the one or more processors:
         receive a third request from the client via an idempotent programmatic interface of the set of programmatic interfaces to perform a third operation;   determine, based on one or more of: (a) an instance identifier indicated in the third request, (b) an identifier of the client, or (c) a representation of input parameters of the third request, whether the third request is a duplicate of an earlier-submitted request; and   in response to a determination that the third request is a duplicate of an earlier-submitted request, provide an indication of success of the third request to the client, without inserting an additional job object corresponding to the third request in the job queue.       

     Embodiments of the disclosure can also be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         receive, at a network-accessible machine learning service of a provider network, a text representation of a recipe comprising one or more of: (a) a group definitions section indicating one or more groups of variables, wherein individual ones of the one or more groups comprise a plurality of variables on which at least one common transformation operation is to be applied, (b) an assignment section defining one or more intermediate variables, (c) a dependency section indicating respective references to one or more machine learning artifacts stored in a repository, or (d) an output section indicating one or more transformation operations to be applied to at least one entity indicated in the group definitions section, the assignment section, or the dependency section;   validate, in accordance with (a) a set of syntax rules defined by the machine learning service and (b) a set of library function definitions for transformation operation types supported by the machine learning service, the text representation of the recipe;   generate an executable representation of the recipe;   store the executable representation in the repository;   determine that the recipe is to be applied to a particular data set;   verify that the particular data set meets a run-time acceptance criterion of the recipe; and   apply, using one or more selected provider network resources, a particular transformation operation of the one or more transformation operations to the particular data set.       

     2. The system as recited in clause 1, wherein the one or more computing devices are further configured to:
         receive a request to apply the recipe to a different data set;   verify that the different data set meets the run-time acceptance criterion of the recipe; and   apply the particular transformation operation to the different data set.       

     3. The system as recited in any of clauses 1-2, wherein the one or more computing devices are further configured to:
         provide, to a client via a programmatic interface, an indication of a respective set of one or more recipes applicable to individual ones of a plurality of machine learning problem domains.       

     4. The system as recited in any of clauses 1-3, wherein the text representation comprises an indication of a particular machine learning model to be executed using a result of the particular transformation operation. 
     5. The system as recited in any of clauses 1-4, wherein the one or more computing devices are further configured to:
         determine, in response to an indication that automated parameter tuning is to be performed for the recipe, a plurality of parameter value options applicable to a different transformation operation of the one or more transformation operations;   generate, by the machine learning service, respective results of the different transformation operation using individual ones of the plurality of parameter value options; and   provide, by the machine learning service based on an analysis of the respective results, an indication of at least one candidate parameter value of the plurality of parameter value options that meets a parameter acceptance criterion.       

     6. A method, comprising: 
     performing, by one or more computing devices:
         receiving, at a network-accessible machine learning service, a first representation of a recipe comprising one or more of: (a) a group definitions section indicating one or more groups of variables, wherein individual ones of the one or more groups comprise a plurality of data set variables on which at least one common transformation operation is to be applied and (b) an output section indicating one or more transformation operations to be applied to at least one entity indicated in one or more of: (i) the group definitions section or (ii) an input data set;   validating, in accordance with at least a set of library function definitions for transformation operation types supported by the machine learning service, the first representation of the recipe;   generating an executable representation of the recipe;   determining that the recipe is to be applied to a particular data set;   verifying that the particular data set meets a run-time acceptance criterion; and   applying, using one or more selected provider network resources, a particular transformation operation of the one or more transformation operations to the particular data set.       

     7. The method as recited in clause 6, wherein the first representation is a text representation or a binary representation. 
     8. The method as recited in any of clauses 6-7, wherein the first representation is generated by a client of the machine learning service using a tool obtained from the machine learning service. 
     9. The method as recited in any of clauses 6-8, wherein a data type of at least one variable of an input data record of the particular data set comprises one or more of: (a) text, (b) a numeric data type, (c) Boolean, (d) a binary data type, (d) a categorical data type, (e) an image processing data type, (f) an audio processing data type, (g) a bioinformatics data type, or (h) a structured data type. 
     10. The method as recited in clause 9, wherein the data type comprises a particular structured data type, further comprising performing, by the one or more computing devices:
         selecting, based at least in part on the particular structured data type, a particular library function to be used for the particular transformation operation.       

     11. The method as recited in any of clauses 6-9, wherein the first representation comprises an assignment section defining an intermediate variable in terms of one or more of: (a) an input data set variable or (b) an entity defined in the group definitions section, wherein the intermediate variable is referenced in the output section. 
     12. The method as recited in any of clauses 6-9 or 11, wherein the first representation comprises a dependency section indicating a reference to a particular artifact stored in a repository of the machine learning service, wherein the particular transformation operation consumes an output of the particular artifact as an input. 
     13. The method as recited in clause 12, wherein the particular artifact comprises one or more of: (a) a machine learning model, (b) a different recipe, (c) a statistics set or (d) an alias that includes a reference to a machine learning model. 
     14. The method as recited in any of clauses 6-9 or 11-12, wherein the particular transformation operation utilizes a user-defined function, further comprising performing, by the one or more computing devices:
         receiving, at the machine learning service from a client prior to said receiving the first representation, an indication of a module implementing the user-defined function, wherein the module is in a text format or a binary format.       

     15. The method as recited in any of clauses 6-9, 11-12 or 14, further comprising performing, by the one or more computing devices:
         validating the first representation in accordance with a set of syntax rules defined by the machine learning service.       

     16. The method as recited in any of clauses 6-9, 11-12, or 14-15, further comprising performing, by the one or more computing devices:
         receiving a request to apply the recipe to a different data set;   verifying that the different data set meets the run-time acceptance criterion of the recipe; and   applying the particular transformation operation to the different data set.       

     17. The method as recited in any of clauses 6-9, 11-12, or 14-16, further comprising performing, by the one or more computing devices:
         providing, to a client via a programmatic interface, an indication of a respective set of one or more recipes applicable to individual ones of a plurality of machine learning problem domains.       

     18. The method as recited in any of clauses 6-9, 11-12, or 14-17, wherein the first representation comprises an indication of a particular machine learning model to be executed using a result of the particular transformation operation. 
     19. The method as recited in any of clauses 6-9, 11-12, or 14-18, further comprising performing, by the one or more computing devices:
         determining, by the machine learning service in response to an indication that automated parameter tuning is to be performed for the recipe, a plurality of parameter value options applicable to a different transformation operation of the one or more transformation operations;   generating, by the machine learning service, respective results of the different transformation operation using individual ones of the plurality of parameter value options.       

     20. The method as recited in clause 19, further comprising performing, by the one or more computing devices:
         selecting, by the machine learning service, a particular parameter value of the plurality of parameter value options as an acceptable value based at least in part on a particular result set corresponding to the particular parameter value.       

     21. The method as recited in any of clauses 19-20, further comprising performing, by the one or more computing devices:
         indicating, by the machine learning service to a client, at least a subset of the plurality of parameter value options as candidate values based on an analysis of the respective results; and   receiving, at the machine learning service from the client, an indication of a particular parameter value of the subset to be used for the different transformation operation.       

     22. The method as recited in any of clauses 19-21, wherein the plurality of parameter value options comprise one or more of: (a) respective lengths of n-grams to be derived from a language processing data set, (b) respective quantile bin boundaries for a particular variable, (c) image processing parameter values, (d) a number of clusters into which a data set is to be classified, (e) values for a cluster boundary threshold, or (f) dimensionality values for a vector representation of a text document. 
     23. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors:
         determine, at a machine learning service, a first representation of a recipe comprising one or more of: (a) a group definitions section indicating one or more groups of variables, wherein individual ones of the one or more groups comprise a plurality of data set variables on which at least one common transformation operation is to be applied, or (b) an output section indicating one or more transformation operations to be applied to at least one entity indicated in one or more of (i) the group definitions section or (ii) an input data set of the recipe;   validate, in accordance with at least a set of library function definitions for transformation operation types supported by the machine learning service, the first representation of the recipe;   generate an executable representation of the recipe; and   in response to a determination that the recipe is to be applied to a particular data set, use one or more selected provider network resources to implement a particular transformation operation of the one or more transformation operations to the particular data set.       

     24. The non-transitory computer-accessible storage medium as recited in clause 23, wherein the first representation comprises an assignment section defining an intermediate variable in terms of one or more of: (a) an input data set variable or (b) an entity defined in the group definitions section, wherein the intermediate variable is referenced in the output section. 
     25. The non-transitory computer-accessible storage medium as recited in any of clauses 23-24, wherein the first representation comprises a dependency section indicating a reference to a particular artifact stored in a repository of the machine learning service, wherein the particular transformation operation consumes an output of the particular artifact as an input. 
     26. The non-transitory computer-accessible storage medium as recited in any of clauses 23-25, wherein the particular artifact comprises one or more of: (a) a machine learning model, (b) a different recipe, (c) an alias or (d) a set of statistics. 
     27. The non-transitory computer-accessible storage medium as recited in any of clauses 23-26, wherein the set of library function definitions comprise one or more of: (a) a quantile bin function, (b) a Cartesian product function, (c) a bi-gram function, (d) an n-gram function, (e) an orthogonal sparse bigram function, (f) a calendar function, (g) an image processing function, (h) an audio processing function, (i) a bio-informatics processing function, or (j) a natural language processing function. 
     Embodiments of the disclosure can also be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         receive, via a programmatic interface of a machine learning service of a provider network, a request to extract observation records of a particular data set from one or more file sources, wherein a size of the particular data set exceeds a size of a first memory portion available for the particular data set at a first server of the machine learning service;   map the particular data set to a plurality of contiguous chunks, including a particular contiguous chunk whose size does not exceed the first memory portion;   generate, based at least in part on a filtering descriptor indicated in the request, a filtering plan to perform a sequence of chunk-level filtering operations on the plurality of contiguous chunks, wherein an operation type of individual ones of the sequence of filtering operations comprises one or more of: (a) sampling, (b) shuffling, (c) splitting, or (d) partitioning for parallel computation, and wherein the filtering plan includes a first chunk-level filtering operation followed by a second chunk-level filtering operation;   execute, to implement the first chunk-level filtering operation, at least a set of reads directed to one or more persistent storage devices at which at least a subset of the plurality of contiguous chunks are stored, wherein, subsequent to the set of reads, the first memory portion comprises at least the particular contiguous chunk;   implement the second chunk-level filtering operation on an in-memory result set of the first chunk-level filtering operation, without re-reading from the one or more persistent storage devices, and without copying the particular contiguous chunk; and   extract a plurality of observation records from an output of the sequence of chunk-level filtering operations.       

     2. The system as recited in clause 1, wherein the one or more computing devices are further configured to:
         implement an intra-chunk filtering operation on a set of observation records identified within the particular contiguous chunk.       

     3. The system as recited in any of clauses 1-2, wherein the one or more computing devices are further configured to:
         de-compress contents of the particular contiguous chunk in accordance with one or more de-compression parameters indicated in the request.       

     4. The system as recited in any of clauses 1-3, wherein the one or more computing devices are further configured to:
         decrypt contents of the particular contiguous chunk in accordance with one or more decryption parameters indicated in the request.       

     5. The system as recited in any of clauses 1-4, wherein the one or more computing devices are further configured to:
         provide a plurality of observation records obtained from the sequence as input for an execution of one or more of: (a) a feature processing recipe or (b) a machine learning model.       

     6. A method, comprising: 
     performing, on one or more computing devices:
         receiving, at a machine learning service, a request to extract observation records of a particular data set from one or more data sources;   mapping the particular data set to a plurality of chunks including a particular chunk;   generating a filtering plan to perform a sequence of chunk-level filtering operations on the plurality of chunks, wherein an operation type of individual ones of the sequence of filtering operations comprises one or more of: (a) sampling, (b) shuffling, (c) splitting, or (d) partitioning for parallel computation, and wherein the filtering plan includes a first chunk-level filtering operation followed by a second chunk-level filtering operation;   initiating, to implement the first chunk-level filtering operation, a set of data transfers directed to one or more persistent storage devices at which at least a subset of the plurality of chunks is stored, wherein, subsequent to the set of data transfers, the first memory portion comprises at least the particular chunk;   implementing the second chunk-level filtering operation on an in-memory result set of the first chunk-level filtering operation; and   extracting a plurality of observation records from an output of the sequence of chunk-level filtering operations.       

     7. The method as recited in clause 6, wherein the one or more data sources comprise one or more storage objects including a particular storage object, wherein said mapping the particular data set into the plurality of chunks comprises determining, based at least in part on a chunk size parameter, a candidate offset within the particular storage object as a candidate ending boundary of the particular chunk, further comprising performing, by the one or more computing devices:
         selecting, as an ending boundary of the particular chunk, a particular delimiter representing an ending boundary of a particular observation record within the particular storage object, wherein the particular delimiter is located at a different offset than the candidate offset.       

     8. The method as recited in clause 7, wherein said selecting, as the ending boundary, the particular delimiter comprises:
         identifying, in a sequential read of the particular storage object in order of increasing offsets, the first delimiter with an offset higher than the candidate offset as the ending boundary of the particular chunk.       

     9. The method as recited in any of clauses 6-7, wherein the one or more data sources comprise one or more of: (a) a single-host file system, (b) a distributed file system, (c) a storage object accessible via a web service interface from a network-accessible storage service, (d) a storage volume presenting a block-level device interface, or (e) a database. 
     10. The method as recited in any of clauses 6-7 or 9, wherein the request is formatted in accordance with an application programming interface of the machine learning service. 
     11. The method as recited in any of clauses 6-7 or 9-10, further comprising performing, by the one or more computing devices:
         de-compressing contents of the particular chunk in accordance with one or more de-compression parameters indicated in the request.       

     12. The method as recited in any of clauses 6-7 or 9-11, further comprising performing, by the one or more computing devices:
         decrypting contents of the particular chunk in accordance with one or more decryption parameters indicated in the request.       

     13. The method as recited in any of clauses 6-7 or 9-12, wherein the plurality of observation records comprises a first observation record of a first record length, and a second observation record of a different record length. 
     14. The method as recited in any of clauses 6-7 or 9-13, further comprising performing, by the one or more computing devices:
         implementing an intra-chunk filtering operation on a set of observation records identified within the particular chunk.       

     15. The method as recited in any of clauses 6-7 or 9-14, further comprising performing, by the one or more computing devices:
         inserting a first job object representing the first chunk-level filtering operation in a collection of jobs to be scheduled at the machine learning service; and   inserting a second job object representing the second chunk-level filtering operation in the collection, prior to a completion of the first chunk-level filtering operation.       

     16. The method as recited in any of clauses 6-7 or 9-15, further comprising performing, by the one or more computing devices:
         providing the plurality of observation records extracted from the output of the sequence as input for an execution of one or more of: (a) a feature processing recipe or (b) a machine learning model.       

     17. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors:
         generate in response to receiving a request to extract observation records of a particular data set from one or more data sources at a machine learning service, a plan to perform one or more chunk-level operations including a first chunk-level operation on a plurality of chunks of the particular data set, wherein an operation type of the first chunk-level operation comprises one or more of: (a) sampling, (b) shuffling, (c) splitting, or (d) partitioning for parallel computation;   initiate, to implement the first chunk-level operation, a set of data transfers directed to one or more persistent storage devices at which at least a subset of the plurality of chunks is stored, wherein, subsequent to the set of data transfers, a first memory portion of a particular server of the machine learning service comprises at least a particular chunk of the plurality of chunks; and   implement a second operation on a result set of the first chunk-level operation, wherein the second operation comprises one or more of: (a) another filtering operation, (b) a feature processing operation or (c) an aggregation operation.       

     18. The non-transitory computer-accessible storage medium as recited in clause 17, wherein the particular data set comprises contents of one or more of: (a) a single-host file system, (b) a distributed file system, (c) a storage object accessible via a web service interface from a network-accessible storage service, (d) a storage volume presenting a block-level device interface, or (e) a database. 
     19. The non-transitory computer-accessible storage medium as recited in any of clauses 17-18, wherein the second operation comprises an intra-chunk filtering operation. 
     20. The non-transitory computer-accessible storage medium as recited in any of clauses 17-19, wherein the second operation comprises a cross-chunk filtering operation performed on a plurality of observation records including a first observation record identified within the particular chunk and a second observation record identified within a different chunk of the plurality of chunks. 
     21. The non-transitory computer-accessible storage medium as recited in any of clauses 17-20, wherein the second operation is an in-memory operation performed without copying the particular chunk to a different persistent storage device and without re-reading contents of the particular chunk from the one or more persistent storage devices. 
     22. The non-transitory computer-accessible storage medium as recited in any of clauses 17-21, wherein the operation type of the first chunk-level operation is partitioning for a parallel computation, wherein the first chunk-level operation includes a plurality of model training operations including a first training operation and a second training operation, wherein an execution duration of the first training operation overlaps at least in part with an execution duration of the second training operation. 
     Embodiments of the disclosure can also be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         generate consistency metadata to be used for one or more training-and-evaluation iterations of a machine learning model, wherein the consistency metadata comprises at least a particular initialization parameter value for a pseudo-random number source;   sub-divide an address space of a particular data set of the machine learning model into a plurality of chunks, including a first chunk comprising a first plurality of observation records, and a second chunk comprising a second plurality of observation records;   retrieve, from one or more persistent storage devices, observation records of the first chunk into a memory of a first server, and observation records of the second chunk into a memory of a second server,   select, using a first set of pseudo-random numbers, a first training set from the plurality of chunks, wherein the first training set includes at least a portion of the first chunk, wherein observation records of the first training set are used to train the machine learning model during a first training-and-evaluation iteration of the one or more training-and-evaluation iterations, and wherein the first set of pseudo-random numbers is obtained using the consistency metadata; and   select, using a second set of pseudo-random numbers, a first test set from the plurality of chunks, wherein the first test set includes at least a portion of the second chunk, wherein observation records of the first test set are used to evaluate the machine learning model during the first training-and-evaluation iteration, and wherein the second set of pseudo-random numbers is obtained using the consistency metadata.       

     2. The system as recited in clause 1, wherein the one or more computing devices are further configured to:
         insert a first job corresponding to the selection of the first training set in a collection of jobs to be scheduled at of a machine learning service, and a second job corresponding to the selection of the first test set in the collection; and   schedule the second job for execution asynchronously with respect to the first job.       

     3. The system as recited in any of clauses 1-2, wherein the one or more computing devices are configured to:
         receive, from a client of a machine learning service, a request for the one or more training-and-evaluation iterations, wherein the request indicates at least a portion of the consistency metadata.       

     4. The system as recited in any of clauses 1-3, wherein the consistency metadata is based at least in part on an identifier of a data object in which one or more observation records of the particular data set are stored. 
     5. The system as recited in any of clauses 1-4, wherein the one or more computing devices are further configured to:
         reorder observation records of the first chunk prior to presenting the observation records of the first training set as input to the machine learning model.       

     6. A method, comprising: 
     one or more computing devices configured to:
         determining consistency metadata to be used for one or more training-and-evaluation iterations of a machine learning model, wherein the consistency metadata comprises at least a particular parameter value for a pseudo-random number source;   sub-dividing an address space of a particular data set of the machine learning model into a plurality of chunks, including a first chunk comprising a first plurality of observation records, and a second chunk comprising a second plurality of observation records;   selecting, using the consistency metadata, a first training set from the plurality of chunks, wherein the first training set includes at least a portion of the first chunk, and wherein observation records of the first training set are used to train the machine learning model during a first training-and-evaluation iteration of the one or more training-and-evaluation iterations; and   selecting, using the consistency metadata, a first test set from the plurality of chunks, wherein the first test set includes at least a portion of the second chunk, and wherein observation records of the first test set are used to evaluate the machine learning model during the first training-and-evaluation iteration.       

     7. The method as recited in clause 6, further comprising performing, by the one or more computing devices:
         retrieving, from a persistent storage device into a memory of a first server, at least the first chunk prior to training the machine learning model during the first training-and-evaluation iteration; and   selecting, for a different training-and-evaluation iteration of the one or more training-and-evaluation iterations, (a) a different training set and (b) a different test set, without copying the first chunk from the memory of the first server to a different location.       

     8. The method as recited in any of clauses 6-7, further comprising performing, by the one or more computing devices:
         receiving, from a client of a machine learning service, a request for the one or more training-and-evaluation iterations, wherein the request indicates at least a portion of the consistency metadata.       

     9. The method as recited in clause 8, wherein the request is formatted in accordance with a particular programmatic interface implemented by a machine learning service of a provider network. 
     10. The method as recited in any of clauses 6-8, wherein the consistency metadata is based at least in part on an identifier of a data object in which one or more observation records of the particular data set are stored. 
     11. The method as recited in any of clauses 6-8 or 10, wherein the first training set comprises at least one observation record of a third chunk of the plurality of chunks, and wherein the first test set comprises at least one observation record of the third chunk. 
     12. The method as recited in any of clauses 6-8 or 10-11, further comprising performing, by the one or more computing devices:
         shuffling observation records of the first chunk prior to presenting the observation records of the first training set as input to the machine learning model.       

     13. The method as recited in any of clauses 6-8 or 10-12, further comprising performing, by the one or more computing devices:
         determining a number of chunks into which the address space is to be sub-divided based at least in part on one or more of: (a) a size of available memory at a particular server or (b) a client request.       

     14. The method as recited in any of clauses 6-8 or 10-13, wherein the particular data set is stored in a plurality of data objects, further comprising:
         determining an order in which the plurality of data objects are to be combined prior to sub-dividing the address space.       

     15. The method as recited in any of clauses 6-8 or 10-14, wherein the one or more training-and-evaluation iterations are cross-validation iterations of the machine learning model. 
     16. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors:
         determine consistency metadata to be used for one or more training-and-evaluation iterations of a machine learning model, wherein the consistency metadata comprises at least a particular parameter value for a pseudo-random number source;   select, using the consistency metadata, a first training set from a plurality of chunks of a particular data set, wherein individual ones of the plurality of chunks comprise one or more observation records, wherein the first training set includes at least a portion of a first chunk of the plurality of chunks, and wherein observation records of the first training set are used to train the machine learning model during a first training-and-evaluation iteration of the one or more training-and-evaluation iterations; and   select, using the consistency metadata, a first test set from the plurality of chunks, wherein the first test set includes at least a portion of a second chunk of the plurality of chunks, and wherein observation records of the first test set are used to evaluate the machine learning model during the first training-and-evaluation iteration.       

     17. The non-transitory computer-accessible storage medium as recited in clause 16, wherein the instructions when executed on the one or more processors:
         initiate a retrieval, from a persistent storage device into a memory of a first server, of at least the first chunk prior to training the machine learning model during the first training-and-evaluation iteration; and   select, for a different training-and-evaluation iteration of the one or more training-and-evaluation iterations, (a) a different training set and (b) a different test set, without copying the first chunk from the memory of the first server to a different location.       

     18. The non-transitory computer-accessible storage medium as recited in any of clauses 16-17, wherein the instructions when executed on the one or more processors:
         receive, from a client of a machine learning service, a request for the one or more training-and-evaluation iterations, wherein the request indicates at least a portion of the consistency metadata.       

     19. The non-transitory computer-accessible storage medium as recited in any of clauses 16-18, wherein the consistency metadata is based at least in part on an identifier of a data object in which one or more observation records of the particular data set are stored. 
     20. The non-transitory computer-accessible storage medium as recited in in any of clauses 16-19, wherein the instructions when executed on the one or more processors:
         shuffle observation records of the first chunk prior to presenting the observation records of the first training set as input to the machine learning model.       

     Embodiments of the disclosure can also be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         identify one or more run-time optimization goals for a decision-tree based machine learning model to be trained using a data set, including at least a goal for a memory footprint of an execution of the machine learning model subsequent to a training phase of the machine learning model;   store, in a depth-first order at one or more persistent storage devices during a tree-construction pass of the training phase, respective representations of a plurality of nodes generated for a particular decision tree using at least a portion of the data set;   determine, for one or more nodes of the particular decision tree during the tree-construction pass, a respective value of a predictive utility metric (PUM), wherein a particular PUM value associated with a particular node of the one or more nodes is a measure of an expected contribution of the particular node to a prediction generated using the machine learning model;   generate, during a tree-pruning pass of the training phase, a modified version of the particular decision tree, wherein to generate the modified version, at least the particular node is removed from the particular decision tree, wherein the particular node is selected for removal based at least in part on the one or more run-time optimization goals and based at least in part on the particular PUM value;   store a representation of the modified version of the particular decision tree; and   subsequent to the training phase, execute the machine learning model using at least the modified version of the particular decision tree to obtain a particular prediction.       

     2. The system as recited in clause 1, wherein the PUM comprises one or more of: (a) an indication of a Gini impurity, (b) an information gain metric, or (c) an entropy metric. 
     3. The system as recited in any of clauses 1-2, wherein the one or more run-time optimization goals include one or more of: (a) a prediction time goal, (b) a processor utilization goal, or (c) a budget goal. 
     4. The system as recited in any of clauses 1-3, wherein the one or more computing devices are further configured to:
         generate a representation of a distribution of values of the PUM among the one or more nodes; and   select the particular node for removal based at least in part on the distribution.       

     5. The system as recited in any of clauses 1-4, wherein the machine learning model comprises one or more of: (a) a Random Forest model, (b) a classification and regression tree (CART) model, or (c) an adaptive boosting model. 
     6. A method, comprising: 
     performing, by one or more computing devices:
         storing, in a depth-first order at one or more persistent storage devices during a tree-construction pass of a training phase of a machine learning model, respective representations of a plurality of nodes generated for a particular decision tree;   determining, for one or more nodes of the particular decision tree, a respective value of a predictive utility metric (PUM), wherein a particular PUM value associated with a particular node of the one or more nodes is a measure of an expected contribution of the particular node to a prediction generated using the machine learning model;   generating, during a tree-pruning pass of the training phase, a modified version of the particular decision tree, wherein said generating comprises removing at least the particular node from the particular decision tree, wherein the particular node is selected for removal based at least in part on the particular PUM value; and   executing the machine learning model using at least the modified version of the particular decision tree to obtain a particular prediction.       

     7. The method as recited in clause 6, wherein the particular node is selected for removal based at least in part on one or more run-time optimization goals for an execution of the model, including one or more of: (a) a memory-footprint goal (b) a prediction time goal, (c) a processor utilization goal, or (d) a budget goal. 
     8. The method as recited in any of clauses 6-7, wherein the PUM comprises one or more of: (a) an indication of a Gini impurity, (b) an information gain metric, or (c) an entropy metric. 
     9. The method as recited in any of clauses 6-8, further comprising performing, by the one or more computing devices:
         determining a distribution of values of the PUM among the one or more nodes; and   selecting the particular node for removal based at least in part on the distribution.       

     10. The method as recited in any of clauses 6-9, further comprising performing, by the one or more computing devices:
         accumulating, during the tree-pruning pass, values of the PUM for a plurality of nodes of the particular decision tree in a top-down traversal of the particular decision tree; and   selecting the particular node for removal based at least in part on a result of said accumulating.       

     11. The method as recited in any of clauses 6-10, further comprising performing, by the one or more computing devices:
         examining, during the tree-pruning pass, values of the PUM for a plurality of nodes of the particular decision tree in a bottom-up traversal of the particular decision tree; and   selecting the particular node for removal based at least in part on a result of said examining.       

     12. The method as recited in any of clauses 6-11, wherein the machine learning model comprises one or more of: (a) a Random Forest model, (b) a classification and regression tree (CART) model, or (c) an adaptive boosting model. 
     13. The method as recited in any of clauses 6-12, wherein the machine learning model is configured to utilize a plurality of decision trees including the particular decision tree, wherein the particular decision tree is generated at a particular thread of execution of a plurality of threads of execution of a machine learning service, further comprising performing, by the one or more computing devices:
         generating a second decision tree of the plurality of decision trees at a different thread of execution of the plurality of threads of execution.       

     14 The method as recited in any of clauses 6-13, wherein the machine learning model is configured to utilize a plurality of decision trees including the particular decision tree, wherein the modified version of the particular decision tree is generated at a particular thread of execution of a plurality of threads of execution of a machine learning service, further comprising performing, by the one or more computing devices:
         generating a modified version of a second decision tree of the plurality of decision trees at a different thread of execution of the plurality of threads of execution.       

     15. The method as recited in any of clauses 6-14, wherein the machine learning model is configured to utilize a plurality of decision trees including the particular decision tree, wherein the particular prediction is obtained at a particular thread of execution of a plurality of threads of execution of a machine learning service, further comprising:
         obtaining a second prediction using a modified version of a second decision tree of the plurality of decision trees at a different thread of execution of the plurality of threads of execution.       

     16. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors:
         store, in a depth-first order at one or more persistent storage devices during a first tree-construction period of one or more tree-construction periods of a training phase of a machine learning model, respective representations of a plurality of nodes generated for a particular decision tree;   determine, for one or more nodes of the particular decision tree, a respective value of a predictive utility metric (PUM), wherein a particular PUM value associated with a particular node of the one or more nodes is a measure of an expected contribution of the particular node to a prediction generated using the machine learning model;   select, during a first tree-pruning period of one or more tree-pruning periods of the training phase, the particular node for removal from the particular decision tree based at least in part on the particular PUM value; and   store a modified version of the particular decision tree, wherein the modified version excludes the particular node.       

     17. The non-transitory computer-accessible storage medium as recited in clause 16, wherein the particular node is selected for removal based at least in part on one or more run-time optimization goals for an execution of the machine learning model, including one or more of: (a) a memory-footprint goal (b) a prediction time goal, (c) a processor utilization goal, or (d) a budget goal. 
     18. The non-transitory computer-accessible storage medium as recited in any of clauses 16-17, wherein the particular node is selected for removal based at least in part on one or more goals specified by a client on whose behalf the machine learning model is created. 
     19. The non-transitory computer-accessible storage medium as recited in any of clauses 16-18, wherein the instructions when executed at the one or more processors:
         store a representation of a distribution of values of the PUM among the one or more nodes; and   select the particular node for removal based at least in part on the distribution.       

     20. The non-transitory computer-accessible storage medium as recited in any of clauses 16-19, wherein the plurality of nodes of the particular decision tree is generated in response to an invocation of a programmatic interface of a machine learning service implemented at a provider network. 
     21. The non-transitory computer-accessible storage medium as recited in any of clauses 16-20, wherein the one or more tree-construction periods comprise a second tree-construction period performed after the first tree-pruning period, wherein the one or more tree-pruning periods comprise a second tree-pruning period performed after the second tree-construction period, and wherein the instructions when executed on the one or more processors:
         store, during the second tree-construction period, a second node of the particular decision tree; and   determine, during the second tree-pruning period, whether to remove the second node from the particular decision tree based at least in part on a PUM value associated with the second node.       

     Embodiments of the disclosure can be described in view of the following clauses: 
     1. A system, comprising: 
     one or more computing devices configured to:
         receive, at a machine learning service of a provider network, an indication of a data source to be used for generating a linear prediction model, wherein, to generate a prediction, the linear prediction model is to utilize respective weights assigned to individual ones of a plurality of features derived from observation records of the data source, wherein the respective weights are stored in a parameter vector of the linear prediction model;   determine, based at least in part on examination of a particular set of observation records of the data source, respective weights for one or more features to be added to the parameter vector during a particular learning iteration of a plurality of learning iterations of a training phase of the linear prediction model;   in response to a determination that a triggering condition has been met during the training phase,
           identify one or more pruning victims from a set of features whose weights are included in the parameter vector, based at least in part on a quantile analysis of the weights, wherein the quantile analysis is performed without a sort operation; and   remove at least a particular weight corresponding to a particular pruning victim of the one or more pruning victims from the parameter vector; and   
           generate, during a post-training-phase prediction run of the linear prediction model, a prediction using at least one feature for which a weight is determined after the particular weight of the particular pruning victim is removed from the parameter vector.       

     2. The system as recited in clause 1, wherein the triggering condition is based at least in part on a population of the parameter vector. 
     3. The system as recited in any of clauses 1-2, wherein the triggering condition is based at least in part on a goal indicated by a client. 
     4. The system as recited in any of clauses 1-3, wherein the one or more computing devices are further configured to:
         during a subsequent learning iteration of the plurality of learning iterations, performed after the particular learning iteration,
           determine that a weight for the particular pruning victim is to be re-added to the parameter vector; and   add the weight corresponding to the particular pruning victim to the parameter vector.   
               

     5. The system as recited in any of clauses 1-4, wherein a first feature of the one or more features whose weights are to be added to the parameter vector during the particular learning iteration is derived from one or more variables of the observation records of the data source via a transformation that comprises a use of one or more of: (a) a quantile bin function, (b) a Cartesian product function, (c) a bi-gram function, (d) an n-gram function, (e) an orthogonal sparse bigram function, (f) a calendar function, (g) an image processing function, (h) an audio processing function, (i) a bio-informatics processing function, (j) a natural language processing function or (k) a video processing function. 
     6. A method, comprising: 
     performing, by one or more computing devices:
         receiving an indication of a data source to be used for training a machine learning model, wherein, to generate a prediction, the machine learning model is to utilize respective parameters assigned to individual ones of a plurality of features derived from observation records of the data source, wherein the respective parameters are stored in a parameter vector of the machine learning model;   identifying one or more features for which respective parameters are to be added to the parameter vector during a particular learning iteration of a plurality of learning iterations of a training phase of the machine learning model;   in response to determining that a triggering condition has been met in the training phase, removing respective parameters of one or more pruning victim features from the parameter vector, wherein the one or more pruning victim features are selected based at least in part on an analysis of relative contributions of features whose parameters are included in the parameter vector to predictions made using the machine learning model; and   generating, during a post-training-phase prediction run of the machine learning model, a particular prediction using at least one feature for which a parameter is determined after the one or more pruning victim features are selected.       

     7. The method as recited in clause 6, wherein the analysis of relative contributions comprises a quantile analysis of weights included in the parameter vector. 
     8. The method as recited in any of clauses 6-7, wherein the analysis of relative contributions (a) does not comprise a sort operation and (b) does not comprise copying values of the parameters included in the parameter vector. 
     9. The method as recited in any of clauses 6-8, wherein said determining that the triggering condition has been met comprises determining that a population of the parameter vector exceeds a threshold. 
     10. The method as recited in any of clauses 6-9, wherein the triggering condition is based at least in part on a resource capacity constraint of a server of a machine learning service. 
     11. The method as recited in any of clauses 6-10, wherein the triggering condition is based at least in part on a goal indicated by a client. 
     12. The method as recited in any of clauses 6-11, further comprising performing, by the one or more computing devices:
         during a subsequent learning iteration of the plurality of learning iterations, performed after the particular learning iteration,
           determining that a parameter for a particular feature which was previously selected as a pruning victim feature is to be re-added to the parameter vector; and   adding the parameter for the particular feature to the parameter vector.   
               

     13. The method as recited in any of clauses 6-12, wherein a first feature of the one or more features for which respective parameters are to be added to the parameter vector during the particular learning iteration is determined from one or more variables of observation records of the data source via a transformation that comprises a use of one or more of: (a) a quantile bin function, (b) a Cartesian product function, (c) a bi-gram function, (d) an n-gram function, (e) an orthogonal sparse bigram function, (f) a calendar function, (g) an image processing function, (h) an audio processing function, (i) a bio-informatics processing function, (j) a natural language processing function, or (k) a video processing function. 
     14. The method as recited in any of clauses 6-13, further comprising performing, by the one or more computing devices:
         implementing a stochastic gradient descent technique to update, during the particular learning iteration, one or more previously-generated parameters included in the parameter vector.       

     15. The method as recited in any of clauses 6-14, wherein the machine learning model comprises a generalized linear model. 
     16. The method as recited in any of clauses 6-15, further comprising performing, by the one or more computing devices:
         receiving, via a programmatic interface of a machine learning service implemented at a provider network, wherein the machine learning service comprises a plurality of training servers at one or more data centers, a client request indicating the data source; and   assigning, to a particular training server of the plurality of training servers by a job scheduler of the machine learning service, asynchronously with respect to said receiving the client request, a job comprising the plurality of learning iterations.       

     17. A non-transitory computer-accessible storage medium storing program instructions that when executed on one or more processors implements a model generator of a machine learning service, wherein the model generator is configured to:
         determine a data source to be used for generating a model, wherein, to generate a prediction, the model is to utilize respective parameters assigned to individual ones of a plurality of features derived from observation records of the data source, wherein the respective parameters are stored in a parameter vector of the model;   identify one or more features for which parameters are to be added to the parameter vector during a particular learning iteration of a plurality of learning iterations of a training phase of the model;   in response to a determination that a triggering condition has been met, remove respective parameters assigned to one or more pruning victim features from the parameter vector, wherein the one or more pruning victim features are selected based at least in part on an analysis of relative contributions of features whose parameters are included in the parameter vector to predictions made using the model; and   add, subsequent to a removal from the parameter vector of at least one parameter assigned to a pruning victim feature, at least one parameter to the parameter vector.       

     18. The non-transitory computer-accessible storage medium as recited in clause 17, wherein the analysis of relative contributions comprises a determination of a deviation of a particular parameter value included in the parameter vector from an a priori parameter value. 
     19. The non-transitory computer-accessible storage medium as recited in any of clauses 17-18, wherein the particular parameter value comprises a probability distribution, and wherein the determination of the deviation comprises an estimation of a Kullback-Leibler (KL) divergence. 
     20. The non-transitory computer-accessible storage medium as recited in any of clauses 17-19, wherein to determine whether the triggering condition has been met, the model generator is configured to determine whether a population of the parameter vector exceeds a threshold. 
     21. The non-transitory computer-accessible storage medium as recited in any of clauses 17-20, wherein the data source comprises a source of a stream of observation records transmitted to a network endpoint of a machine learning service. 
     CONCLUSION 
     Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible medium. Generally speaking, a computer-accessible medium may include storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., as well as transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network and/or a wireless link. 
     The various methods as illustrated in the Figures and described herein represent exemplary embodiments of methods. The methods may be implemented in software, hardware, or a combination thereof. The order of method may be changed, and various elements may be added, reordered, combined, omitted, modified, etc. 
     Various modifications and changes may be made as would be obvious to a person skilled in the art having the benefit of this disclosure. It is intended to embrace all such modifications and changes and, accordingly, the above description to be regarded in an illustrative rather than a restrictive sense.