Connecting to Bigquery Depot¶
Step 1: Create the Bigquery Depot¶
If the Depot is not active, create one using the provided template.
name: ${{bigquerydepot}}
version: v2alpha
type: depot
tags:
- ${{dropzone}}
- ${{bigquery}}
owner: ${{owner-name}}
layer: user
depot:
type: BIGQUERY
description: ${{description}} # optional
external: ${{true}}
secrets:
- name: ${{bq-instance-secret-name}}-r
allkeys: true
- name: ${{bq-instance-secret-name}}-rw
allkeys: true
bigquery: # optional
project: ${{project-name}} # optional
params: # optional
${{"key1": "value1"}}
${{"key2": "value2"}}
Step 2: Prepare the Lens model folder¶
In the model
folder, the semantic model will be defined, encompassing SQL mappings, logical tables, logical views, and user groups. Each subfolder contains specific files related to the Lens model. You can download the Lens template to quickly get started.
Load data from the data source¶
In the sqls
folder, create .sql
files for each logical table, where each file is responsible for loading or selecting the relevant data from the source. Ensure, only the necessary columns are extracted, and the SQL dialect is specific to the bigquery. For instance,
-
Format table names as:
project_id.dataset.table
. -
Use
STRING
for text data types instead ofVARCHAR
. -
Replace generic functions with BigQuery’s
EXTRACT
function.
For instance, a simple data load might look as follows:
Alternatively, you can write more advanced queries that include transformations, such as:
SELECT
CAST(customer_id AS VARCHAR) AS customer_id,
first_name,
CAST(DATE_PARSE(birth_date, '%d-%m-%Y') AS TIMESTAMP) AS birth_date,
age,
CAST(register_date AS TIMESTAMP) AS register_date,
occupation,
annual_income,
city,
state,
country,
zip_code
FROM
"onelakehouse"."retail".customer;
Define the table in the model¶
Create a tables
folder to store logical table definitions, with each table defined in a separate YAML file outlining its dimensions, measures, and segments. For instance, to define a table for sales
data:
table:
- name: customers
sql: {{ load_sql('customers') }}
description: Table containing information about sales transactions.
Add dimensions and measures¶
After defining the base table, add the necessary dimensions and measures. For instance, to create a table for sales data with measures and dimensions, the YAML definition could look as follows:
tables:
- name: sales
sql: {{ load_sql('sales') }}
description: Table containing sales records with order details.
dimensions:
- name: order_id
type: number
description: Unique identifier for each order.
sql: order_id
primary_key: true
public: true
measures:
- name: total_orders_count
type: count
sql: id
description: Total number of orders.
Add segments to filter¶
Segments are filters that allow for the application of specific conditions to refine the data analysis. By defining segments, you can focus on particular subsets of data, ensuring that only the relevant records are included in your analysis. For example, to filter for records where the state is either Illinois or Ohio, you can define a segment as follows:
To know more about segments click here.
Create views¶
Create a views folder to store all logical views, with each view defined in a separate YAML file (e.g., sample_view.yml
). Each view references dimensions, measures, and segments from multiple logical tables. For instance the followingcustomer_churn
view is created.
views:
- name: customer_churn_prediction
description: Contains customer churn information.
tables:
- join_path: marketing_campaign
includes:
- engagement_score
- customer_id
- join_path: customer
includes:
- country
- customer_segments
To know more about the views click here.
Create User groups¶
This YAML manifest file is used to manage access levels for the semantic model. It defines user groups that organize users based on their access privileges. In this file, you can create multiple groups and assign different users to each group, allowing you to control access to the model.By default, there is a 'default' user group in the YAML file that includes all users.
To know more about the User groups click here.
Step 3: Deployment manifest file¶
After setting up the Lens model folder, the next step is to configure the deployment manifest. Below is the YAML template for configuring a Lens deployment.
# RESOURCE META SECTION
version: v1alpha # Lens manifest version (mandatory)
name: "bigquery-lens" # Lens Resource name (mandatory)
layer: user # DataOS Layer (optional)
type: lens # Type of Resource (mandatory)
tags: # Tags (optional)
- lens
description: bigquery depot lens deployment on lens2 # Lens Resource description (optional)
# LENS-SPECIFIC SECTION
lens:
compute: runnable-default # Compute Resource that Lens should utilize (mandatory)
secrets: # Referred Instance-secret configuration (**mandatory for private code repository, not required for public repository)
- name: bitbucket-cred # Referred Instance Secret name (mandatory)
allKeys: true # All keys within the secret are required or not (optional)
source: # Data Source configuration
type: depot # Source type is depot here
name: bigquerydepot # Name of the bigquery depot
repo: # Lens model code repository configuration (mandatory)
url: https://bitbucket.org/tmdc/sample # URL of repository containing the Lens model (mandatory)
lensBaseDir: sample/lens/source/depot/bigquery/model # Relative path of the Lens 'model' directory in the repository (mandatory)
syncFlags: # Additional flags used during synchronization, such as specific branch.
- --ref=lens # Repository Branch
Each section of the YAML template defines key aspects of the Lens deployment. Below is a detailed explanation of its components:
-
Defining the Source:
-
Source type: The
type
attribute in thesource
section must be explicitly set todepot
. -
Source name: The
name
attribute in thesource
section should specify the name of the Bigquery Depot created.
-
-
Setting Up Compute and Secrets:
-
Define the compute settings, such as which engine (e.g.,
runnable-default
) will process the data. -
Include any necessary secrets (e.g., credentials for Bitbucket or AWS CodeCommit) for secure access to data and repositories.
-
-
Defining Repository:
-
url
Theurl
attribute in the repo section specifies the Git repository where the Lens model files are stored. For instance, if your repo name is lensTutorial then the repourl
will be https://bitbucket.org/tmdc/lensTutorial -
lensBaseDir
: ThelensBaseDir
attribute refers to the directory in the repository containing the Lens model. Example:sample/lens/source/depot/bigquery/model
. -
secretId
: ThesecretId
attribute is used to access private repositories (e.g., Bitbucket, GitHub). It specifies the secret needed to securely authenticate and access the repository. -
syncFlags
: Specifies additional flags to control repository synchronization. Example:--ref=dev
specifies that the Lens model resides in thedev
branch.
-
-
Configuring API, Worker and Metric Settings (Optional): Set up replicas, logging levels, and resource allocations for APIs, workers, routers, and other components.
Step 4: Apply the Lens manifest file¶
After configuring the deployment file with the necessary settings and specifications, apply the manifest using the following command: