7 Production Deployment of Oracle Real-Time Decisions

This chapter explains the various components of an Oracle Real-Time Decisions configuration and introduces the concept of production deployment of Oracle RTD, for a proof of concept/pilot-type implementation or a full production environment.

After an Inline Service is tested and ready for production deployment, you will deploy it to one or more servers for production. The hardware requirements for your system depend on whether you choose a proof of concept/pilot-type configuration or a full production configuration. System configuration may need to be adjusted based upon specific customer requirements and application characteristics.

This chapter contains the following topics:

• Section 7.1, "Oracle Real-Time Decisions Components"

• Section 7.2, "Proof of Concept Configuration"

• Section 7.3, "Full Production Configuration"

7.1 Oracle Real-Time Decisions Components

Oracle Real-Time Decisions is a real-time decision engine software platform that consists of the following components:

• Real-Time Decision Server

• Decision Studio

• Decision Center

• Load Generator

• Administration (JMX)

Figure 7-1 shows the main service and database components of Oracle Real-Time Decisions and the main runtime interactions between the components. To introduce and illustrate the basic Oracle Real-Time Decisions architecture concepts, the diagram shows a basic Oracle Real-Time Decisions topology, with one occurrence of each of the main services within a single Oracle Real-Time Decisions instance.

Figure 7-1 Single-Instance Oracle Real-Time Decisions Components and Interactions

Description of "Figure 7-1 Single-Instance Oracle Real-Time Decisions Components and Interactions"

The main Oracle Real-Time Decisions services are:

• Decision Service

  Decision Service is responsible for tracking customers through Inline Service (ILS) sessions and responding to requests for decisions. It implements the decision logic, computes predictions and scores, and returns sorted results to the calling operational systems. It also creates learning records for model update.

  A learning record contains session data and information about events that occurred during the session, for example, the fact that three offers were presented and one was accepted.

• Learning Service

  Learning Service is responsible for updating the models. It reads the learning records created by Decision Service, updates the models and periodically generates new optimized prediction models to be consumed by Decision Service.

• Query Service

  Query Service uses the models produced by Learning Service to provide the data behind Decision Center reports.

• Decision Center

  Decision Center is the web-based application that is responsible for producing the Decision Center reports.

The Oracle RTD database is used to store model data and ILS metadata, in addition to the control and configuration data required for the Oracle Real-Time Decisions environment. An ILS is typically deployed to the database through Decision Studio (not shown in Figure 7-1).

The following provides an overview of the main runtime interactions between Oracle Real-Time Decisions components and Inline Services, and includes references to the processes annotated in Figure 7-1.

• At runtime, ILS metadata is loaded into Decision Service memory - (A). Enterprise data and results of decision requests are stored in ILS session data (only entity data is highlighted in the diagram, but choice event data is also significant for model updates) - (B), (C).

• Either during or at the end of ILS sessions, learning records are written out to the database by Decision Service - (D).

• Learning Service reads the learning records, and produces learning models - (E) - which are periodically written out ("persisted") to the database - (F). Learning Service also periodically creates the prediction models - (G) - that are the basis for many Oracle Real-Time Decisions decisions.

  In more detail:

  1. By default, Learning Service wakes up every 15 seconds, and checks to see if there are any new learning records in the database. If so, it retrieves the new records in batches and creates or updates the learning models in Learning Service memory.

  2. Each model has a persistence interval, which controls how often learning models are written to the database. If the persistence interval is reached or exceeded since the last write-out to the database, Learning Service writes out the learning models and deletes the old learning records.

  3. Learning records and learning models contain all the attributes (and their values) defined for the session. The key part of the learning process is selecting those attributes and values that are predictive, that is, which correlate to the output that you want to predict, and generating prediction models from them. In general, prediction models are much smaller than learning models, as only a small proportion of attributes are predictive.

  4. You can select whether or not to generate a prediction model for an Oracle RTD model. If predictive modeling is selected, then another model parameter controls when to generate the prediction model. This parameter specifies what percentage of new learning records added to the model will prompt the creation of a new prediction model. The new prediction model replaces the old prediction model.

• Prediction models are used by Decision Service as required for Oracle RTD decisions. Decision Service periodically checks if there are any new prediction models, and if so, loads them into its memory - (H). They are retained in Decision Service memory to service subsequent decisions.

• Decision Center loads ILS metadata into Decision Service memory when users log in and select an ILS - (I). As required, Decision Center users may edit the ILS and redeploy it to the database. Decision Center as a reporting tool interacts with Query Service to query the contents of learning models - (J). Query Service itself reads the learning models from the database - (K)..

Note:

Another Oracle RTD component, Batch Service, does not appear in Figure 7-1. For more information on Batch Service, which is currently co-located with Decision Service, see "Batch Framework Architecture" in  Oracle Real-Time Decisions Platform Developer's Guide.

7.1.1 Clustering

In many production systems, Oracle RTD is installed and deployed in an Oracle RTD cluster. The following considerations apply to Oracle RTD clusters:

• Learning Service is a cluster singleton, meaning that only one Learning Service instance is active at a time, although it can be deployed to multiple Oracle RTD instances for availability, as in the following possible configuration (Figure 7-2):

  Figure 7-2 Learning Service as a Cluster Singleton

  
  Description of "Figure 7-2 Learning Service as a Cluster Singleton"
  
  

• In a cluster, Decision Center and Query Service are typically deployed to one or more dedicated Oracle RTD instances. Decision Center uses Query Service to populate its reports. It is possible to dedicate individual Query Service instances to processing the queries for particular Studies (the collection of models associated with a given Inline Service).

• In a cluster, Decision Service is typically deployed to different Oracle RTD instances than either Learning Service, Query Service or Decision Center, in order to minimize the performance and memory impact of these other components on Decision Service.

7.1.2 Time Windows

The Time Window parameter influences how models are processed and used. Time Window defines a time period, such as Week, Month, Quarter, Year, which is defined (and can be altered) at the model level.

In addition to the standard modeling processing described in this section, which is independent of time windows, learning models are archived at the end of each Time Window period. These model archives are the basis for Decision Center analytic reports, which show data within and across time periods.

Predictions are always made from the most recent data. In general, they derive from the learning records received so far in the current time window together with all the learning records in the previous time window. During the first time window, predictions are made from what is currently available.

Figure 7-3 shows the model processes as they occur in the initial time windows of a model, and shows how Oracle RTD creates new, overlapping instances of models as time passes.

Figure 7-3 Model Processes in Initial Time Windows

Description of "Figure 7-3 Model Processes in Initial Time Windows"

Each model instance starts at the beginning of a time window, exists for two time windows, and, apart from the first model instance, overlaps with the previous model instance.

For each model instance, learning information accumulates during its first time window, at the end of which time a copy is saved as archive for reporting. At that point in time:

1. The model instance becomes the "primary model instance", and during its second time window it is used for predictions, while also continuing to learn

2. The next model instance is created, which serves as the "secondary model instance" and is only used for learning purposes until it becomes the primary model itself at the next time window boundary

To summarize:

• Predictions derive from the learning records received so far in the current time window together with all the learning records in the previous time window.

• Apart from the first time window, predictions only derive from a primary model instance, during the second time window of its existence.

Apart from the first time window, the Learning Service holds in memory, for each model, both the primary and secondary model instances, which span the current and previous time windows.

The Query Service loads into memory instances of the models belonging to the studies it has been assigned, for the time windows involved in the queries it receives. This will included archived models if Decision Center users make queries for time windows preceding the current one.

Decision Center reports have a setting to ”show incomplete time window”. When checked, reports for the current time window use the secondary model instance and reports for the previous time window use the archived model. When unchecked, reports for the combined current and previous time windows use the primary model instance.

7.2 Proof of Concept Configuration

The intent of a proof of concept/pilot-type configuration is not to support a system in production for an unspecified length of time, but to allow the customer to better understand the benefits of deploying an Inline Intelligence solution. All the Oracle RTD services are deployed on a single server

Table 7-1 lists the hardware requirements for an proof of concept configuration.

Table 7-1 Hardware Requirements for All-In-One Configuration

Hardware	Minimum Configuration
Number of Cores	4
RAM	16 GB

7.3 Full Production Configuration

The Full Production configuration supports a large scale deployment of Oracle RTD. There are a number of factors that determine the system configuration. They include the peak number of requests per second, the number of choices, the number and size of models for the current time window and previous time windows and the number of data sources, among other things.

This configuration involves:

• Multiple Decision Service instance for the processing of integration points

• A Learning Service instance for the processing of the models

• A Backup Service instance for failover shall the primary learning server fail

• One or multiple instances running both Query Service and Decision Center for reporting purpose

The number of Decision Service instances depends on the peak number of requests per second, the number of choices and desired response time. The memory requirements for the Decision Service instances depends on the number of concurrent sessions, size of each session, and the number and size of the prediction models.

The number of cores for the Learning Service instance and backup Learning Service instance depends on how much parallel processing the Learning Service needs to do to keep up with the load generated by the Decision Service instances. The memory requirement of the Learning Service instance and backup Learning Service instance depends on the number and size of models for the current and previous time windows.

The number of Query Service and Decision Center instances depends on either the number of Decision Center concurrent users or the number and size of current, previous and archived models. The more archived models you want to be able to report on, the more memory you will need on your Query Service instance, or have multiple Query Service instances. The number of cores of your Query Service instance(s) depends on the number of Decision Center concurrent users.

Please refer to our published benchmarks for further information on the configuration most appropriate for your business and technical requirements. The Oracle Corporation Professional Services Group can also assist in determining the most appropriate configuration for your needs.

Table 7-2 lists the hardware requirements for a Full Production Configuration.

Table 7-2 Hardware Requirements for Full Deployment Configuration

Server	Component	Minimum Configuration
Decision Service (each instance)	Number of Cores	2
	RAM	4 GB
Learning Service (each, primary or backup instance)	Number of Cores	4
	RAM	16 GB
Query Service and Decision Center(each instance)	Number of Cores	4
	RAM	16 GB
Database Server	Number of Cores	4
	RAM	16 GB