In ESP 4.3, there are five analytics windows. They are:
- Model Reader
- Model Supervisor
As the name suggests, the Score window applies scoring and clustering algorithms to incoming events generating output score and clustering events in real time. For example, the window can apply an Enterprise Miner-generated Random Forest scoring algorithm to incoming trade data to predict real-time asset prices.
In the 4.3 release, the ESP Score window can perform DBSCAN and KMEANS clustering as well as utilize ASTORE scoring algorithms.
The Train window utilizes incoming events to develop/adjust scoring and clustering algorithms in real time. The Train window works together with the Score window. Once the Train window has trained or adjusted an algorithm, it outputs that algorithm to a Score window for real-time scoring/clustering. The frequency of model output and adjustments is subject to the Train window's parameters.
In the 4.3 release, the ESP Train window can train DBSCAN and KMEANS clustering algorithms (matching the Score window). When paired with the Score window, Train ESP models are referred to as "Online Training" models because the Train window is constantly adjusting the clustering algorithm and sending updates to the Score window "online."
The Model Reader window receives external ASTORE scoring algorithm information in the form of "request" events and passes the ASTORE scoring algorithm information to Score windows in the form of "model" events.
When paired with the Score window, Model-Reader ESP models are referred to as "Offline Training" models because the ASTORE models are developed and updated offline. When a new/updated ASTORE model is ready, it is sent into the Score node via a Model Reader node. This is done as the ESP model is running ("on the fly").
The Model Supervisor window stores multiple ASTORE algorithms and passes those algorithms to Score windows on demand. This way, scoring rules can be changed on the fly.
For example, a particular ESP scoring model might have numerous candidate scoring algorithms (say 10). As conditions change throughout the day, one algorithm might fit the situation better than the others, so a Send request would be sent to the Model Supervisor window to send that algorithm to the Score window. Later in the day, a different algorithm might fit better so a Send request would be sent for that one....
The Calculate window creates real-time, running statistics based on a number of statistical/analytical techniques.
In the 4.3 release, the ESP Calculate window supports the following analytic algorithms:
- Distribution Fitting
- Segmented Correlation
- Summary - Min, Max, Mean, Sum, Std, USS, ...
- Tokenization - String parsing
While I'd like to provide examples for each of the above, I need to keep this post to a manageable size. So I think a model supervisor example with offline ASTORE files probably hits most of the points people need to get any of this working. So here we go...
The astoreScoreRepository model looks identical to the "Model Supervisor Window" picture above except that the window names are more descriptive.
The model xml is below. It contains all of the Source window schema definitions you'll need to send requests into the Model Reader and Model Supervisor windows.
The model reads the trades1M.csv file from the ESP Examples directory. On my system, this located at /opt/sas/viya/home/SASEventStreamProcessingEngine/4.3.0/examples/xml/vwap_xml. It will be somewhere similar in yours.
Beyond the input trades event stream, two requests are sent into the model. A "Load Model" request is sent via the modeRequestSource window to the ModelReader1 window. It registers 2 different ASTORE scoring algorithms. Additionally a "Send Model" request is sent via the modelSupRequestSource window to the ModelSupervisor1 window. It sends one of the two scoring algorithms to the Score window.
The "Load Model" request is below. It loads two different ASTORE models into the Model Reader node -- score.sasast and score2.sasast. As the model XML shows, the message published into the ESP model via a connector. In the model, it is located at, /opt/sas/espcoursefiles/modelRequest2.csv.
(Note: You need the blank line at the end or the source window will not read the final message row.)
The "Send Model" request is below. It directs the Model Repository window to send the score.sasast ASTORE scoring algorithm to the Score node.
(Note: As before, you need the blank line at the end or the source window will not read the final message row.)
Unlike, the load request, the send request is not delivered to its Source window via a Connector. Instead the ESP XML client is used. This allows time for Model Supervisor window to register the two ASTORE algorithms. It also makes for a more realistic scenario. Requests to change the scoring algorithm will come-in after the model is up and running via the REST API (e.g. the ESP XML Client). The command used is shown below.
The ASTORE file used in this model was generated in Enterprise Miner. It uses the other variables in the trades1M.csv file to predict the price variable. The file uses a random forest methodology.
Since the example ESP model uses 2 ASTORE files, score.sasast and score2.sasast, simply copy and rename the ASTORE file linked above to make both files.
In addition to the overview and the example, here are some other information you'll need to make this all work.
When integrating AStore files into ESP, you need to know two sets of values:
- The ASTORE Input Map - The list of input variables
- The ASTORE Output Map - The list of output variables
You can get these lists by registering the ASTORE file in ESP Studio (Score node). You can also get them using the ESP XML Analytics client. The following command reveals the input and output maps of the ASTORE used in the example above.
You'll get an output that looks like this:
When using an ASTORE, the Score node expects the input event stream to contain each field required by the ASTORE. It maps the input event stream to the ASTORE input map by field name.
The ASTORE output fields are mapped to the Score node's output event stream using the output-map XML tag. You can see this in the example XML above. ESP Studio populates this map for you using drop-down boxes.
In addition to all of the functionality above, users can also issue requests to reconfigure ESP Analytics window parameters while models are running. Both the Train and Calculate windows accept reconfig requests. As an example, a user might wish to adjust the WindowLength parameter of a Correlation analysis. That user would send a reconfig request into that window (via a Source window).
A reconfig request has the same schema as any other request. An example looks like this:
To facilitate both "data" events and "request" events (as well as "model" events), ESP 4.3 is enhanced with a new Edge parameter, Role. The role identifies the incoming event stream as either "data," "request," or "model." ESP Studio takes care of adding the correct role for you but when you're building your own XML or when you're debugging your ESP Studio models, be sure to check that the role assigned matching the event stream. An example is shown below.
SAS ESP Analytics is a separate package that must be licensed in addition to the base ESP engine. In order to run the analytics package, the ESP server needs access to the SAS TK shared objects. This is done using the plugindir command line option. See below for an example.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.