# Overview

Composable Audience Studio (CAS) is a deployment mode of Treasure Data's CDP that enables you to build and manage audience segments directly on your Databricks data warehouse without copying data into Treasure Data. Using Zero-Copy / Federated Query architecture, CAS queries your Databricks tables in place, keeping data under your existing governance and access controls.

This guide walks through the end-to-end process of setting up a Composable Parent Segment on Databricks, from connection configuration to segment creation.

## What You Will Set Up

1. Service principal and PAT authentication for secure Databricks access
2. Databricks authentication configuration to connect Treasure Data to your Databricks workspace
3. Parent Segment configuration file defining your customer and behavior tables
4. API upload of the configuration to create the Parent Segment in CAS


## Prerequisites

Before you begin, ensure you have:

- A Treasure account with admin-level permissions
- A Databricks workspace with:
  - Unity Catalog enabled with a catalog, schema, and tables containing your customer and event data
  - A SQL warehouse or compute cluster available for query execution
  - A service principal with appropriate permissions on the target catalog/schema/tables
- A Treasure API key (Master API key recommended)


## Architecture

Data never leaves your Databricks environment. Treasure Data sends federated queries and receives results at query time.


```mermaid
graph LR
  subgraph TD["Treasure Data"]
    CAS["Composable Audience Studio<br/>- Segment Builder<br/>- Activation<br/>- Insights"]
  end

  subgraph DB["Your Databricks Workspace"]
    CT["Your Table (profiles + attributes)"]
    BT1["Behaviors Table 1"]
    BT2["Behaviors Table 2"]
    BTN["Behaviors Table N ..."]
  end

  CAS <-->|"Zero Copy / Query"| CT
  CAS <-->|"Zero Copy / Query"| BT1
  CAS <-->|"Zero Copy / Query"| BT2
  CAS <-->|"Zero Copy / Query"| BTN
```

## Parent Segment Data Model

A Composable Parent Segment is composed of a single Customers table and multiple Behaviors tables.

### Customers Table

The Customers table stores unified profile data and attributes, with each record representing a single profile. A unique identifier column is required for each profile.

- Contains all customer attributes (e.g., email, name, city, membership tier, LTV)
- Each row = one unique customer profile
- Unique identifier column serves as the primary key


### Behaviors Tables

Behaviors tables contain activity records for specific actions taken by profiles (e.g., website visits, orders). Each Behaviors table must include a unique ID column that links the activity record to the corresponding customer profile via the Unique identifier.

- Each table represents a distinct type of activity (page views, purchases, etc.)
- Multiple behavior records can exist per customer
- Must include a time column for temporal queries


### Composable Parent Segment Data Model


```mermaid
erDiagram
  Customers ||--o{ "Behaviors Table 1" : "1 to many"
  Customers ||--o{ "Behaviors Table 2" : "1 to many"
  Customers ||--o{ "Behaviors Table 3" : "1 to many"

  Customers {
    string unique_id PK
    string email
    string name
    string city
    string membership_tier
    float ltv
  }

  "Behaviors Table 1" {
    string unique_id FK
    timestamp time
    string action
  }

  "Behaviors Table 2" {
    string unique_id FK
    timestamp time
    string action
  }

  "Behaviors Table 3" {
    string unique_id FK
    timestamp time
    string action
  }
```

The relationship between Customers and each Behaviors table is 1-to-many: one customer profile can have many behavior records.