Analytics Server System Architecture for 8.2 to 8.4

The standalone ThingWorx Analytics Server architecture includes an adapter, a set of microservices, and one or more common workers. Each microservice includes a REST API component that accepts job requests and other queries from the ThingWorx Adapter for Analytics Server (previously called the Analytics Gateway) and submits them to separate worker components. The workers create a queued system for executing submitted jobs as specified by the requests. These common workers can handle any type of job request (training, scoring, profiles, etc.). If multiple common workers are deployed, multiple jobs of the same type can be processed simultaneously. This architecture allows the job orchestration and monitoring component (REST APIs) to be decoupled from the back-end, job-processing components (workers).

The standalone server deployment requires that ThingWorx Foundation is already installed and running.

A standalone deployment of ThingWorx Analytics includes a series of logical components. The components are shown in the following architecture diagram and described in the Components section below.

The following components correspond to the image above:

1. ThingWorx Server – A user or another client system submits job requests via an AnalyticsServer Thing that is part of the ThingWorx Foundation server installation.

2. ThingWorx Adapter for Analytics Server – The adapter acts as an integration point between the ThingWorx Foundation server and the ThingWorx Analytics Server. The adapter automatically registers with ThingWorx Foundation and instantiates the Things that represent the connected ThingWorx Analytics microservices. The adapter uses the connected microservices to handle job requests submitted through the ThingWorx Foundation server.

The adapter does not scale horizontally, so there can be only one per system. The number of resources (cores) assigned to the agent also controls the number of simultaneous requests the system can handle (about twice the number of cores the adapter is provided).

3. Microservices – The ThingWorx Analytics microservices each include a REST API component. The REST API accepts job requests and queries from the ThingWorx adapter and submits them to separate worker components. During installation, all of these microservices, or a subset of them, can be installed. At a minimum, the Results and Data microservices must be installed. The others are optional.

Most of the ThingWorx Analytics microservices are lightweight, and require few resources, because the Worker services do the actual work of the submitted job requests. The two exceptions are the scoring microservices: Prediction and Prescriptive. These microservices each include a real-time scoring service, so they need to be able to run in real time when a scoring request is received.

4. Common Workers – Common workers can process any type of submitted job requests. Workers pick up the jobs from the ZooKeeper system and do the work. Currently, three workers are provided during the installation process. However, the number of workers can be scaled up after the installation is complete. Each worker can handle one job at a time, so if there is only one worker in the system, only one job can be processed at a time for the system. Keep in mind, multiple workers will allow more job requests to be processed simultaneously, but will not increase the speed with which any given job is handled.

Since the workers do the heaviest processing in the system, they require allocation of the most system resources. Recommended: 4 GB of memory and at least one full core per worker.

5. ZooKeeper – A service that manages the job queues and provides configuration information. Other components in the system register with ZooKeeper and obtain the configuration information they need. ZooKeeper also provides coordination between the microservices and the common workers.

The ThingWorx Analytics system operates through the submission and tracking of user-supplied jobs. Job requests are submitted via the ThingWorx Foundation, where the AnalyticsServer Thing routes the jobs through the adapter to the appropriate microservices. These jobs include uploading and optimizing data, processing signals and clusters, training prediction models, and other actions.

All jobs are tasked in a distributed, fault-tolerant manner that is managed by ZooKeeper. When a microservice receives a job request, that job is submitted to ZooKeeper. The Workers are registered with ZooKeeper and receive updates for any changes in the status of a job. When a new job is added, or a previous job fails, the Workers request access to any present jobs. If the Worker receives the lock on a job, it is considered to own the job. Until the Worker either completes the job, or fails from an unrecoverable exception, ZooKeeper will preserve the job lock.

Each Worker process is designed to handle only a single job. When a job has completed (or failed), the Worker process exits and is replaced by a newly instantiated Worker process. The results of all jobs persist on the local file system.