Note

This documentation is for a prior release of Kinetica. For the latest documentation, click here.

Active Analytics Workbench (AAW) Overview

Kinetica provides the Active Analytics Workbench (AAW) with the goal of simplifying and accelerating data science and machine learning in a scalable fashion. With AAW, users can ingest data, train models, make inferences (answers/output from models), and even audit models with a few endpoints (or clicks via the UI). The AAW package can be automatically installed via KAgent and coexists with the database--meaning easy access to one's data and GPUs. AAW leverages Kubernetes to deploy, train, and test models.

Note

To work with models in SQL, see Machine Learning (ML). For statistical analysis functions that don't require a model, see ML Functions.

Concepts

The AAW workflow is defined by five key concepts:

Registries

Docker container registries house the ML models themselves and abstract their implementation details. Any model used by Kinetica must exist in a Docker container registry.

Data

Data comprises ingests, datasets, and feature sets.

  • Ingests represent an ingest tool (e.g., KIO, Kafka, etc.) that pulls data from a given source (Kinetica, PostgreSQL, S3, etc.) and puts it in a new table inside Kinetica. Data can be pulled in batches or via continuous streaming.
  • Datasets represent a set (or sub-set) of column data from a source table in Kinetica. One or more columns can be filtered to create a dataset.
  • Feature sets represent a group of features, which are datasets transformed inline with functions or relationally using Materialized Views

Models

A model can be a function, statistical model, regression, data model, and more that is deployed to enable inferencing capabilities. AAW can deploy any number of replicas of the model, allowing for scalability and better resource management. AAW currently only supports Blackbox models, which are models where implementation details are abstracted and housed in Docker containers. Input and output are the only available interface; they also don't require a training dataset.

Important

Blackbox models rely on the Kinetica Blackbox SDK to fetch AAW-compatible output from a custom Blackbox. Kinetica can assist in Blackbox model container creation if necessary. Consult New Blackbox Model for more information.

Deployments

A deployment represents a model that has been deployed. A deployed model can have inference tests run manually, automatically, or in batches, depending on the type of deployment. Currently there are three types of deployments:

  • On-Demand -- inference tests are run as necessary using user-provided input with results being returned based on the given input
  • Continuous -- inference tests are run automatically against records being streamed into an input table; inference results are inserted into an output table
  • Batch -- inference tests are run against a batch of data in an existing table all at once

Audits

An audit represents the ability to audit a model deployment to ensure its training, testing, and inferencing are untampered. An audit enables drilling into specific inferences from a deployment and filtering the inference by input parameter, process status, and more.

Installation

Kinetica recommends installing AAW using KAgent, as KAgent can install everything AAW requires and can preconfigure everything for the best out-of-the-box experience. Consult Cluster for AAW package install instructions using KAgent. Since AAW relies on Kubernetes, there are two official methods of setting up Kubernetes with KAgent:

  • Using an embedded version of Kubernetes -- KAgent will install and set-up Kubernetes for you on the same infrastructure as Kinetica
  • Using an external Kubernetes cluster -- KAgent will configure AAW to communicate with the external Kubernetes cluster

After the installation is finished, a kml service is available to manage the AAW user interface and API.

Important

AAW will inherit existing login information from the cluster, so logging into the AAW user interface will use the same credentials as GAdmin

Kubernetes Considerations

Kinetica recommends users opt for an external Kubernetes cluster for the following reasons:

  • External Kubernetes clusters are fully managed, monitored, and updated
  • External Kubernetes clusters won't contend with the database for resources and as such, can achieve greater performance on the database and AAW sides
  • External Kubernetes clusters can be scaled independently of the database

Amazon Web Services (AWS) has an Elastic Kubernetes Service (EKS) and Microsoft Azure has an Azure Kubernetes Service that are fully managed services that can be used with AAW.

If users still wish to opt for the embedded Kubernetes setup, please consider the following limitations:

  • The embedded Kubernetes cluster is a stock Kubernetes installation that is statically sized upon cluster initialization
  • The embedded Kubernetes cluster cannot be updated independently of the database, i.e. Kubernetes is only updated when the database is updated, assuming the database version to be installed includes Kubernetes updates as well
  • Kinetica does not provide direct management tools for the embedded Kubernetes cluster, but other tools can be used to connect to and manage the embedded Kubernetes cluster. Additionally, there are utility scripts located in /opt/gpudb/kml/utils that can assist with some of the cluster management

Logging

All the main logs for the AAW service and API are located in /opt/gpudb/kml/logs. All logs for the AAW user interface are located in /opt/gpudb/kml/ui/logs.