Using Textual with Snowpark Container Services directly

Snowpark Container Services (SPCS) allow developers to run containerized workloads directly within Snowflake. Because Tonic Textual is distributed using a private Docker repository, you can use these images in SPCS to run Textual workloads.

It is quicker to use the Snowflake Native App, but SPCS allows for more customization.

Add images to the repository

To use the Textual images, you must add them to Snowflake. The Snowflake documentation and tutorial walks through the process in great detail, but the basic steps are as follows:

1. Set up an image repository in Snowflake.
2. To pull down the required images, you must have access to our private Docker image repository on Quay.io. You should have been provided credentials during onboarding. If you require new credentials, or you experience issues accessing the repository, contact [e-mail]. Once you have access, pull down the following images:

   • textual-snowflake
   • textual-roberta-gpu
3. Use the Docker CLI to upload the images to the image repository.

The images are now available in Snowflake.

Create the Textual service

The Textual service exposes the functions that are used to redact sensitive values in Snowflake.

You create the Textual service in textual_api_pool.

DROP SERVICE IF EXISTS textual;
CREATE SERVICE textual
  IN COMPUTE POOL textual_api_pool
  FROM SPECIFICATION $$
    spec:
      containers:
      - name: textual
        image: your_image_repository_url/textual-snowflake:latest
        env:
          SOLAR_SECRET: your_encryption_string
          SOLAR_ROBERTA_URL: https://textual-roberta-service:8801
          ENVIRONMENT_NAME: your_environment_name
      endpoints:
        - name: textual
          port: 9002
      $$
   QUERY_WAREHOUSE='TEXTUAL'
   MIN_INSTANCES=1
   MAX_INSTANCES=1;

Create the Roberta service

Next, you create the Roberta service, which recognizes personally identifiable information (PII) and other sensitive values in text.

You create the Roberta service in textual_ml_pool.

Without model-based custom entity types

If you do not plan to use the service to detect model-based custom entity types, then:

DROP SERVICE IF EXISTS textual_roberta_service;
CREATE SERVICE textual_roberta_service
  IN COMPUTE POOL textual_ml_pool
  FROM SPECIFICATION $$
    spec:
      containers:
      - name: textualml
        image: your_image_repository_url/textual-roberta-gpu:latest
        env:
            ENVIRONMENT_NAME: your_environment_name
     $$
   MIN_INSTANCES=1
   MAX_INSTANCES=1;

With model-based custom entity types

If you do plan to detect model-based custom entity types, then when you create the service, you must create a volume mount to store the models.

Obtain the volume UID and GID

The configuration includes the volume UID and GID.

First, create the version of the service without the custom entity types, with an added command in the containers section:

DROP SERVICE IF EXISTS textual_roberta_service;
CREATE SERVICE textual_roberta_service
  IN COMPUTE POOL textual_ml_pool
  FROM SPECIFICATION $$
    spec:
      containers:
      - name: textualml
        image: your_image_repository_url/textual-roberta-gpu:latest
        resources:
          requests:
            nvidia.com/gpu: 1
          limits:
            nvidia.com/gpu: 1
        env:
          ENVIRONMENT_NAME: your_environment_name
          command:
          - /bin/sh
          - -c
          - "id && sleep 600"
     $$
   MIN_INSTANCES=1
   MAX_INSTANCES=1;

When the service starts, it returns the values of the UID and GID.

Creating the service with the volume mount

After you obtain the UID and GID, to create the service with the volume mount.

DROP SERVICE IF EXISTS textual_roberta_service;
CREATE SERVICE textual_roberta_service
  IN COMPUTE POOL textual_ml_pool
  FROM SPECIFICATION $$
    spec:
      containers:
      - name: textualml
        image: your_image_repository_url/textual-roberta-gpu:latest
        env:
            ENVIRONMENT_NAME: your_environment_name
        volumeMounts:
          - name: stage-volume  # Must match the volume name below
            mountPath: /usr/bin/textual/custom_models  # Path in the container file system            
      endpoints:
        - name: textualmlendpoint
          port: 8801
          protocol: TCP          
      volumes:
        - name: stage-volume
          source: "@textual_db.public.textual_models"
          uid: <uid_value>
          gid: <gid_value>
      $$
   MIN_INSTANCES=1
   MAX_INSTANCES=1;

Create functions

You can create custom SQL functions that use your API and ML services. These functions are accessible from directly within Snowflake.

CREATE OR REPLACE FUNCTION public.textual_redact(TEXT VARCHAR, REDACT_OPTIONS VARIANT)
  RETURNS varchar
  SERVICE = <api_service_name>
  CONTEXT_HEADERS = (current_user, current_account)
  ENDPOINT = textual
  AS '/api/redact';

CREATE OR REPLACE FUNCTION public.textual_redact(TEXT VARCHAR)
  RETURNS varchar
  SERVICE = <api_service_name>
  CONTEXT_HEADERS = (current_user)
  ENDPOINT = textual
  AS '/api/redact';
  
CREATE OR REPLACE FUNCTION public.textual_parse(PATH VARCHAR, STAGE_NAME VARCHAR, md5sum VARCHAR)
  returns varchar
  SERVICE=core.textual_service
  CONTEXT_HEADERS = (current_user)
  endpoint=textual
  MAX_BATCH_ROWS=10
  as '/api/parse/start';

Example usage

It can take a couple of minutes for the containers to start. After the containers are started, you can use the functions that you created in Snowflake.

To test the functions, use an existing table. You can also create this simple test table:

CREATE TABLE Messages (
    Message TEXT
);

INSERT INTO Messages (Message) VALUES ('Hi my name is John Smith and I drive a Honda');
INSERT INTO Messages (Message) VALUES ('Hi John, mine is Jane Doe');

You use the function in the same way as any other user-defined function. You can pass in additional configuration to determine how to process specific built-in and model-based custom entity types.

For example:

SELECT public.textual_redact('Hi, my name is John Smith and I drive a Honda.', PARSE_JSON('{"generatorConfig":{"CUSTOM_CAR_MAKE":"Redaction","NAME_GIVEN":"Synthesis"},"customPiiEntityIds":["CUSTOM_CAR_MAKE|org1|entity1|model2"]}'));

Note that to specify custom entity types:

• You must first mount the entity types to a Snowflake stage.
• You provide the identifier in both generatorConfig and customPiiEntityIds.
• In customPiiEntityIds, the model path must match the mounted folder structure.

By default, the function redacts the entity values. In other words, it replaces the values with a placeholder that includes the type. Synthesis indicates to replace the value with a realistic replacement value. Off indicates to leave the value as is.

The textual_redact function works identically to the textual_redact function in the Snowflake Native App.

Here are response for the text examples above, showing redacted and synthesized values for the entity types:

Message	Redacted	Synthesized
Hi my name is John Smith and I drive a Honda	Hi my name is [NAME_GIVEN_Kx0Y7] [NAME_FAMILY_s9TTP0] and I drive a [CUSTOM_CAR_MAKE_pY3MN]	Hi my name is Lamar Jones and I drive a Subaru.
Hi John, mine is Jane Doe	Hi [NAME_GIVEN_Kx0Y7], mine is [NAME_GIVEN_veAy9] [NAME_FAMILY_6eC2]	Hi Lamar, mine is Doris Perez.

The textual_parse function works identically to the textual_parse function in the Snowflake Native App.