# CMS: A Continuous Machine-Learning and Serving Platform for Industrial Big Data
## 3 Platform Architecture
### System Architecture  
As shown from Figure 1, the computing architecture for CMS is divided into three different layers: the infrastructure layer, the scheduling layer and the model management layer. In the infrastructure layer, the Docker technology is used for resource allocation and application isolation. Underline resources are divided into dynamic allocable units to be used by various applications. The resource isolation feature of the Linux container enables multiple containers to be executed on a single host without the starving the others. The container orchestration layer focuses on scheduling different types of resources across multiple computers or domains. It can be implemented by reusing an existing Docker manage engine, e.g., Apache(r) Mesos, Google Kubernetes(r), Docker(r) Swarm, Rancher(r) Cattle. These two layers are implemented mainly by reusing platforms with industrial big-data-related enhancements, e.g., data accession, data conversion. On top of the container orchestration layer is the model management layer: this layer consists of four core sets of components:  
_Data accessors_ provide the data access, translation and mapping service from industrial cyber-physical systems. It is also responsible for receiving real-time data from the gateway, translating network protocol, issuing instructions and forwarding data, forwarding processed data to an historical database and real-time database, respectively. Its role also includes the isolation of the traffic between Distributed Control System (DCS) and the big data platform. It can be implemented with an existing data stream processing framework, e.g., Kafka, RabbitMQ, RocketMQ, together with an existing industrial network gateway. _Trainers_ generate models from historical data. Due to the fact of the model evolution, _trainers_ have to be executed periodically or triggered by certain events. By taking historical data together with recently updated data as inputs, it emits a newly learned model. Trainers generally need supports from existing machine-learning platforms. A _trainer_ normally demands a huge amount of computing resources. Thus, it is of crucial importance to effectively orchestrate _trainers_' executions. _Modelets_ provide the model serving service in production environments. Each time online-time data are received, it queries the models to make prediction or deduce adaptation actions based on its enclosed model. In addition to the model invocation task, one _Modelet_ is also responsible for loading, starting, stopping and unloading the model. One major design concern for _modelet_ is the strict response time and the supports for scalability. _Orchestrator_ manages the execution of different _trainers_ to update their generated models. As can be seen from Figure 1, the _orchestrator_ plays a core role in bridging the gap between _trainers_ and _modelets_. It triggers the execution of _trainers_ to generate up-to-dated models. Another major function of the _orchestrator_ is to determine the quality of generated models and to select an appropriated version to switch to. The _orchestrator_ needs to seamlessly deploy the selected model to its corresponding _modelet_ without interrupting the normal operation. As one platform might support a dynamic set of _modelets_ and _trainers_, it is important to support the dynamicity and scalability of those components. The micro-service pattern is adopted for this architecture implementation. Microservice is a software architecture that decomposes large application systems into a set of independent services; services can be independently developed and deployed,  
Figure 1: System architecture for the industrial application of continuous services. and realize loosely coupled application development through modular combination [33]. The other important feature is the support for the multitenancy, which is by Google [12], to indicate the scene that multiple model servers and _trainers_ deployed in a single instance of the server, due to regulation and cost limitations.