Data Team Platform

1. You are here:
2. Business Technology
3. Data Team
4. Data Team Platform

Maintained by:

G

On this page

• Quick Links
• Our Data Stack
• Extract and Load
  • Data Sources
    • Source contacts
    • Tier definition
  • Data Team Access to Data Sources
  • Data Source Overviews
  • DataSiren
  • Snowplow Infrastructure
• Orchestration
• Data Warehouse
  • Snowflake support portal access
  • Warehouse Access
  • Snowflake Permissions Paradigm
    • User Roles
    • Functional Roles
    • Object Roles
    • Masking Roles
    • Examples
    • Logging in and using the correct role
  • Compute Resources
  • Data Storage
    • Raw
    • Prep
    • Prod
    • Folder Structure in Analytics Project
    • Static
  • Data Masking
    • Static Masking
    • Dynamic Masking
  • Timezones
  • Snapshots
    • dbt
    • Other uses
    • Language
  • Backups
    • Unforeseen circumstances
      • Incorrect events happening inside the data platform
      • Unavailability of the Snowflake environment
  • Admin
    • Create Storage location
• Transformation
• Trusted Data Framework
  • Key Terms
  • Trusted Data Components
    • Virtuous Test Cycle
    • Test Cases Expressed As SQL and YAML
    • Trusted Data Schema
    • Schema To Golden Record Coverage
    • Trusted Data Dashboard
    • Test Run
    • Row Count Test
      • Row Count Tests PGP
• Data Pump
  • Adding a Data Pump
  • Operational Data Pumps
    • Marketing Data Mart to Marketo
    • Trusted Data Model to Gainsight
    • Qualtrics Mailing List Data Pump / Qualtrics SheetLoad
      • Debugging to Qualtrics Processes
• Data Spigot
  • Current Data Spigots
• Visualization
  • Meta Analyses for the Data Team
• Security
  • Passwords
  • Software User Provisioning
    • Stitch provisioning
• Google Data Studio
• Sales Analytics Notebooks
  • The process, explained
  • Example:
  • Planned (near) future work:
• Sales Systems Use-Case: Using the Snowflake API

Quick Links

• Data Infrastructure
• Data Pipelines
• Data CI Jobs
• Data Quality
• dbt Guide
• Enterprise Data Warehouse
• Data Pump
• Jupyter Guide
• Permifrost
• Python Guide
• Sisense (Periscope)
• Sisense Style Guide
• Snowplow
• SQL Style Guide
• Meltano
• R/RStudio
• Tableau

Our Data Stack

We use GitLab to operate and manage the analytics function. Everything starts with an issue. Changes are implemented via merge requests, including changes to our pipelines, extraction, loading, transformations, and parts of our analytics.

Extract and Load

We currently use Stitch and Fivetran for some of our data sources. These are off-the-shelf ELT tools that remove the responsibility of building, maintaining, or orchestrating the movement of data from some data sources into our Snowflake data warehouse. We run a full-refresh of all of our Stitch/Fivetran data sources at the same time that we rotate our security credentials (approx every 90 days). Prior to running a full refresh we will drop all of the tables.

Stitch and Fivetran handle the start of the data pipeline themselves. This means that Airflow does not play a role in the orchestration of the Stitch- and Fivetran schedules.

Other solutions we use to extract data are:

1. Meltano
2. Custom pipelines built in Python and orchestrated via Airflow
3. Snowflake data share

For source ownership please see the Tech Stack Applications data file.

Data Sources

The following table indexes all of the RAW data sources we are loading into the data warehouse from external locations. We manage the development backlog and priorities in the New Data Source/Pipeline Project Management sheet, with links to GitLab issues for up-to-date status and progress management. The new data source handbook page describes how the Data Team handles any request for new data sources.

Key

• Pipeline: The technology we use to replicate data.
• RF (Replication Frequency): How often we load new and updated data.
• Raw Schema: The schema in the RAW database where data is stored.
• Prep Schema: The schema in the PREP database where source models are materialized.
• Audience: The primary users of the data.
• SLO: Service Level Objective. Our SLO is the time between real-time and the analysis displayed in the data visualization tool
• x indicates undefined or not run

Source contacts

See the source contact spreadsheet for who to contact if there are any external errors.

Tier definition

Data Team Access to Data Sources

In order to integrate new data sources into the data warehouse, specific members of the Data team will need admin-level access to data sources, both in the UI and through the API. We need this admin-level access through the API in order to pull all the data needed to build the appropriately analyses and through the UI to compare the results of prepared analyses to the UI.

Sensitive data sources can be limited to no less than 1 data engineer and 1 data analyst having access to build the require reporting. In some cases, it may only be 2 data engineers. We will likely request an additional account for the automated extraction process.

Sensitive data is locked down through the security paradigms listed below; Sisense will never have access to sensitive data, as Sisense does not have access to any data by default. Sisense's access is always explicitly granted.

Data Source Overviews

• Customer Success Dashboards
• Netsuite
  • Netsuite and Campaign Data
• Version (pings)
  • Note that up until October 2019, the data team referred to the entire version data source as "pings". However, usage ping is only one subset of the version data source which is why we now use "version" or "version app" to refer to the version.gitlab.com data source and "usage data" or "usage pings" or "pings" to refer to the specific usage data feature of the version data source. In the context of Data extraction, when it comes to Service ping data ingestion, specific details should be found in the Service ping page or in the Readme.md page for Service ping
• Salesforce
• Zendesk

DataSiren

To ensure that the data team has a complete picture of where sensitive data is in the data warehouse, as well as make sure Sisense does not have access to sensitive data, a periodic scan of the data warehouse is made using dbt along with the internally-developed library of tools created as datasiren. This scan is currently executed weekly. The fine-grained results are stored in Snowflake in the PREP.DATASIREN schema and are not available in Periscope because of sensitivity reasons. High-level results have been made available in Periscope, including the simple dashboard found here.

Snowplow Infrastructure

Refer to the Snowplow Infrastructure page for more information on our setup.

Orchestration

We use Airflow on Kubernetes for our orchestration. Our specific setup/implementation can be found here. Also see the Data Infrastructure page for more information.

Data Warehouse

We currently use Snowflake as our data warehouse. The Enterprise Data Warehouse (EDW) is the single source of truth for GitLab's corporate data, performance analytics, and enterprise-wide data such as Key Performance Indicators. The EDW supports GitLab’s data-driven initiatives by providing all teams a common platform and framework for reporting, dashboarding, and analytics. With the exception of point-to-point application integrations all current and future data projects will be driven from the EDW. As a recipient of data from a variety of GitLab source systems, the EDW will also help inform and drive Data Quality best-practices, measures, and remediation to help ensure all decisions are made using the best data possible.

Snowflake support portal access

To get access to snowflake support portal, please follow the below steps.

• Register using gitlab email id to community portal
• This registration will send a welcome email to gitlab mail with the subject Welcome to the Snowflake Community. In the mail it will ask you to finish the registration as part of that you will be asked to set your password for the community portal.
• Once done login again to your snowflake community account and on the home page, click submit case. For the first time, the user who do not have access to submit a case with snowflake. It will ask you to fill in the form for access.
• In the form select the access for already snowflake customer. On the next page, it will ask for information Account Name , Cloud Name, and Region Name. Below is one way to pull this information from the snowflake console.
  • Account Name - select CURRENT_ACCOUNT();
  • Region Name- select CURRENT_REGION();
  • Cloud Name - Based on the region name value we can identify the cloud name.
• Once done you should receive the acknowledgment mail with the subject [Request received] Case# instantly. In case you don't receive the mail resubmit the form.
• Post that you will receive confirmation mail within 24 hours on your request with the subject line Case# -Self Register - Enable Case access

Warehouse Access

To gain access to the data warehouse:

• Create an issue in the access requests project documenting the level of access required.
• Do not request a shared account - each account must be tied to a user.
• We loosely follow the paradigm explained in this blog post around permissioning users.
• When asking to mirror an existing account, please note that access to restricted SAFE data will not be provisioned/mirrored (currently provided via restricted_safe role).

Snowflake Permissions Paradigm

We use Permifrost to help manage permissions for Snowflake. Our configuration file for our Snowflake instance is stored in this roles.yml file. Also available is our handbook page on Permifrost.

We follow this general strategy for role management:

• Every user has an associated user role
• Functional roles exist to represent common privilege sets (analyst_finance, data_manager, product_manager)
• Logical groups of data have their own object roles
• Object roles are assigned primarily to functional roles
• Higher privilege roles (accountadmin, securityadmin, useradmin, sysadmin) are assigned directly to users
• Service accounts have an identically named role
• Additional roles can be assigned either to the service account role or the service account itself, depending on usage and needs
• Individual privileges can be granted at the granularity of the table & view
• Warehouse usage can be granted to any role as needed, but granting to functional roles is recommended

User Roles

Every user will have their own user role that should match their user name. Object level permissions (database, schemas, tables) in Snowflake can only be granted to roles. Roles can be granted to users or to other roles. We strive to have all privileges flow through the user role so that a user only has to use one role to interact with the database. Exceptions are privileged roles such as accountadmin, securityadmin, useradmin, and sysadmin. These roles grant higher access and should be intentionally selected when using.

Functional Roles

Functional roles represent a group of privileges and role grants that typically map to a job family. The major exception is the analyst roles. There are several variants of the analyst role which map to different areas of the organization. These include analyst_core, analyst_finance, analyst_people, and more. Analysts are assigned to relevant roles and are explicitly granted access to the schemas they need.

Functional roles can be created at any time. It makes the most sense when there are multiple people who have very similar job families and permissions.

Object Roles

Object roles are for managing access to a set of data. Typically these represent all of the data for a given source. The zuora object role is an example. This role grants access to the raw Zuora data coming from Stitch, and also to the source models in the prep.zuora schema. When a user needs access to Zuora data, granting the zuora role to that user's user role is the easiest solution. If for some reason access to the object role doesn't make sense, individual privileges can be granted at the granularity of a table.

Masking Roles

Masking Roles manage how users interact with masked data. Masking is applied at the column level and which columns are masked is the decision of the source system owner. Masking is applied to a column in a schema.yml file within the dbt code base when a data object is created via dbt. As some users will need access to unmasked data the masking role allows for permissions to the unmasked data to be granted on a functional or object role level. For example if the masking role of people_data_masking is applied to the column locality then the functional role of analyst_people can be set as a member of the people_masking role to allow the analysts to see unmasked people data.

When a masking policy is created, it is created based on the masking roles and only one masking policy can be applied to a column.

Examples

This is an example role hierarchy for an Data Analyst, Core:

This is an example role hierarchy for an Data Engineer and Account Administrator:

This is an example role hierarchy for a Security Operations Engineer:

For more information, watch this recorded pairing session (must be viewed as GitLab Unfiltered).

Logging in and using the correct role

When you apply for a Snowflake account via an AR and get access provisioned it takes until 3.00AM UTC for the change to take effect. This is because we have a script running daily to provision the access in Snowflake. When you can login, you can do this via Okta. After you logged in via Okta, you need to select the right role that is attached to your account. This is by default the same as your account and it follows the convention of your email adres minus @gitlab.com.

When you don’t select the right role in Snowflake, you only see the following Snowflake objects:

Selecting the right role can be done via the GUI in the up right corner.

1. Click on the arrow
2. Select Switch Role
3. Select your role.

You can set this to your default by running the following:

ALTER USER <YOUR_USER_NAME> SET DEFAULT_ROLE = '<YOUR_ROLE>'

Compute Resources

Compute resources in Snowflake are known as "warehouses". To use our credit consumption effectively, we try to minimize the amount of warehouses. For development purposes (executing dbt jobs locally, running MR pipelines and querying in Snowflake) we use the dev_x warehouse. The names of the warehouse are appended with their size (dev_xs for extra small).

If you're running into query time limits please check your query for optimisation. A bad performing query in development will result in a bad performing query in production, having impact on a daily basis. Please always use the right (size) warehouse. Ground rules of using/selecting a warehouse:

• Warehouses are set as t-shirt sizes. Larger warehouses are more costly for GitLab
• Consider using a running warehouse
  • If you resume a paused warehouse, there is a initial start cost
  • Every warehouse suspends after a set period, but when idle (time between query result and the suspend time), we still consume snowflake credits
  • In general we don't spend more money if we run concurrent queries.
• The query timeout in Snowflake is set to 30 minutes for the REPORTING warehouse. Sisense has a threshold that has been set to 10 minutes to time-out in order to prevent queuing on the Sisense platform.

Data Storage

We use three primary databases: raw, prep, and prod. The raw database is where data is first loaded into Snowflake; the other databases are for data that is ready for analysis (or getting there).

All tables and views in prep and prod are controlled (created, updated) via dbt. Every Quarter the Data Platform Team runs a check for tables and views that are not related to a dbt model and will be removed.

The following list of schema are exceptions and not checked:

• SNOWPLOW_%
• DOTCOM_USAGE_EVENTS_%
• INFORMATION_SCHEMA
• BONEYARD
• TDF
• CONTAINER_REGISTRY
• FULL_TABLE_CLONES
• QUALTRICS_MAILING_LIST
• NETSUITE_FIVETRAN

There is a snowflake database, which contains information about the entire GitLab instance. This includes all tables, views, queries, users, etc.

There is a covid19 database, which is a shared database managed through the Snowflake Data Exchange.

There is a testing_db database, which is used for testing Permifrost.

There is a bi_tool_eval database, which is used for testing bi tooling. Users are able create own testing sets manually.

All databases not defined in our roles.yml Permifrost file are removed on a weekly basis.

Raw

This database is not available to query in Sisense. No dbt models exist for this data and so it may be the case that the data needs review or transformation in order to be useful or accurate. This review, documentation, and transformation all happens downstream in dbt for PREP and PROD

• Raw may contain sensitive data, so permissions need to be carefully controlled
• RAW will contain data that isn't ready for business use.
• Data is stored in different schemas based on the source
• User access can be controlled by schema and tables

Prep

This database is not available to query in Sisense, and is the first layer of verification and transformation in the warehouse, but is not yet ready for general business use.

• Source models are built in logical schemas corresponding to the data source (i.e. sfdc, zuora)
• PREPARATION - this is the default schema where dbt models are built
• SENSITIVE

Prod

This database and all schemas and tables in it are queryable by Sisense. This data has been transformed and modeled for business use.

With the exception of public, and boneyard, all schemas are controlled by dbt. See the dbt guide for more information.

Folder Structure in Analytics Project

The table below shows a mapping of how models stored within folders in the models/ directory in the analytics project will be materialized in the data warehouse.

The source of truth for this is in the dbt_project.yml configuration file.

Static

For data warehouse use cases that require us to store data for our users without updating it automatically with dbt we use the STATIC database. This also allows for analysts and other users to create their own data resources (tables, views, temporary tables). There is a sensitive schema for sensitive data within the static database. If your use case for static requires the use or storage of sensitive data please create an issue for the data engineers.

Scenario's we have been using the STATIC database:

A request comes in to upload a set of data into one of our data sources. This set of data is going to be uploaded once and never updated again.

In this case we have created a new table in the STATIC database and loaded the data there via BULK UPLOAD / COPY command. Then this model has been exposed to the PREP layer. The final model reads from this table via a UNION statement.

This way we have the data in the STATIC database and even if we perform a full-refresh of the data source, we will be able to include this manually uploaded set of records.

Examples of this implementation can be found below:

• Qualtrics, Link to the MR
• Clari, Link to the MR

Data Masking

We use data masking obfuscate private or sensitive information with our data warehouse. Masking can be applied in a dynamic or static manner depending on the particular data needs. Masking can be applied at the request of the data source system owner or at discretion of the Data Team. As our current data masking methods are applied procedurally using dbt they can only be applied in the PREP and PROD database. If masking is required in the RAW database alternant methods of masking should be investigated.

Static Masking

Static data masking is applied during the transformation of the data and the masked result is materialized into the table or view. This will mask the data for all users regardless of role or access permission. This is accomplished in the code with tools such as the hash_sensitive_columns macro within dbt.

Dynamic Masking

Dynamic masking is currently applied on tables or views in the prep and prod layer at query run time based on assigned policies and user roles using the Dynamic Data Masking capabilities of Snowflake. Dynamic masking allows for data to be unmasked for selected users wile masked for all other users. This is accomplished by creating masking policies that are then applied to the column at the time of table or view creation. Masking policies are maintained within the data warehouse source code repository. Please see the dbt guide to setup dynamic masking.

Note: Dynamic masking is not applied on raw database yet.

Timezones

All timestamp data in the warehouse should be stored in UTC. The default timezone for a Snowflake sessions is PT, but we have overridden this so that UTC is the default. This means that when current_timestamp() is queried, the result is returned in UTC.

Stitch explicitly converts timestamps to UTC. Fivetran does this as well (confirmed via support chat).

The only exception to this rule is the use of pacific time to create date_id in fact tables, which should always be created by the get_date_pt_id dbt macro and labeled with the _pt_id suffix.

Snapshots

We use the term snapshots in multiple places throughout the data team handbook and the term can be confusing depending on the context. Snapshots as defined by the dictionary is "a record of the contents of a storage location or data file at a given time". We strive to use this definition whenever we use the word.

dbt

The most common usage is in reference to dbt snapshots. When dbt snapshots is run, it takes the current state of the source data and updates the corresponding snapshot table, which is a table that contains the full history of the source table. It has valid_to and valid_from fields indicating the time period for which that particular snapshot is valid. See the dbt snapshots section in our dbt guide for more technical information.

The tables generated and maintained by dbt snapshots are the raw historical snapshot tables. We will build downstream models on top of these raw historical snapshots for further querying. The snapshots folder is where we store the dbt models. One common model we may build is one that generate a single entry (i.e. a single snapshot) for a given day; this is useful when there are multiple snapshots taken in a 24 hour period. We also will build models to return the most current snapshot from the raw historical table.

Other uses

Our Greenhouse data can be thought of as a snapshot. We get a daily database dump provided by Greenhouse that we load into Snowflake. If we start taking dbt snapshots of these tables then we would be creating historical snapshots of the Greenhouse data.

The extracts we do for some yaml files and for BambooHR can also be thought of as snapshots. This extraction works by taking the full file/table and storing it in its own, timestamped row in the warehouse. This means we have historical snapshots for these files/tables but these are not the same kind of snapshot as dbt. We'd have to do additional transformations to get the same valid_to and valid_from behavior.

Language

• Snapshot - The state of data at a specific point in time
• Take a snapshot - Run the job that takes the state of the data currently and stores it. Can be used in the dbt context. Not recommended to reference our yaml extract jobs - these would be "run the extract".
• Historical snapshots - A table that contains data for a given source table at multiple points in time. Most commonly used to reference dbt-generated snapshot tables. Can also be used to reference the yaml extract tables.
• Latest snapshot - The most current state of the data we have stored. For dbt snapshots these are the records that have null for the valid_to. For BambooHR and yaml extracts these correspond to the last time the extraction job was run. For Greenhouse raw, this represents the data as it is in the warehouse. Were we to start taking snapshots of the Greenhouse data the speaker would have to clarify if they mean the raw table or the latest record in the historical snapshots table.

Backups

The scope of data backups at Data Platform level is to ensure data continuity and availability for reporting and analytics purposes. In case of an unforeseen circumstance happening with our data in Snowflake or with our Snowflake platform, the GitLab data team is able to recover and restore data to the desired state. In our backup policy we tried to find a balance between the risk of an unforeseen event and the impact of the mitigated solution.

Note: the (Snowflake) Data Platform doesn't act as a data archival solution for upstream source systems i.e. for compliance reasons. The Data Platform relies on data that was and is made available in upstream source systems.

Unforeseen circumstances

We've identified currently 2 types of unforeseen circumstances:

• Incorrect events happening inside the data platform.
• Unavailability of the Snowflake environment.

Incorrect events happening inside the data platform

This can be data manipulation action done by a GitLab Team member or by services with access to the data in Snowflake. Some examples are accidentally dropping/truncating a table or running incorrect logic in a transformation.

The vast majority of data in snowflake is copied or derived from copies of our data sources, which is all managed idempotently with dbt and so the most common procedure for data restoration or recovery is through recreating or refreshing objects using dbt Full Refresh. For data in the RAW database, which comes from our extraction pipelines we follow the appropriate Data refresh procedure.

However, there are some exceptions to this. Any data in snowflake which is not a result of idempotent processes or that cannot be refreshed in a practical amount of time should be backed up. For this we use Snowflake Time travel. Which includes:

1. Storage in permanent (not transient) tables.
2. A data retention period of 30 days.

The data retention period is set via dbt This should be implemented in code via a dbt post-hook example.

The following set of rules and guidelines applies to backing up data/using time travel:

• It is the responsibility of the CODEOWNER to ensure that the the backup processes has been correctly implemented for the data that their code builds or maintains.
• Backups (via Time Travel) need not be applied on dbt models by default since these are idempotent and this would result in a huge increase of the storage costs in Snowflake.
• The retention period is set to 30 days.

At the moment the following snowflake objects are considered in scope for Time Travel recovery:

• RAW.SNAPSHOTS.*

Once a table is permanent with a retention period we are able to use Time Travel (internal runbook) in the event we need to recover one of these tables.

Unavailability of the Snowflake environment

For the unlikely event that Snowflake becomes unavailable for an undetermined amount of time, we additionally backup the any business critical data, where Snowflake is the primary source, to Google Cloud Storage (GCS). We execute these backup jobs using dbt's run-operation capabilities. Currently, we backup all of our snapshots daily and retain them for a period of 60 days (per GCS retention policy). If a table should be added to this GCS backup procedure it should be added via the backup manifest.

Admin

In order to keep Snowflake up and running, we perform administrative work.

Create Storage location

In order to load data into the data warehouse, data is usually read out of a storage bucket. To load from a bucket, that bucket must be added as part of an allow list in Snowflake and a stage must be created.

First select all current storage locations. Copy the value under property_value where property=STORAGE_ALLOWED_LOCATIONS

DESC INTEGRATION GCS_INTEGRATION;

Paste the value in the query below, over <<<<_paste_here_>>>> + the value of the new bucket location. Values needs to be separated by a ,.

ALTER INTEGRATION GCS_INTEGRATION 
SET STORAGE_ALLOWED_LOCATIONS = ('<<<<_paste_here_>>>>')

A new stage can then be created with the added storage location.

CREATE STAGE "RAW"."PTO".pto_load
STORAGE_INTEGRATION = GCS_INTEGRATION URL = 'bucket location';

Transformation

We use dbt for all of our transformations. See our dbt guide for more details on why and how we use this tool.

Trusted Data Framework

Data Customers expect Data Teams to provide data they can trust to make their important decisions. And Data Teams need to be confident in the quality of data they deliver. But this is a hard problem to solve: the Enterprise Data Platform is complex and involves multiple stages of data processing and transformation, with tens to hundreds of developers and end-users actively changing and querying data 24 hours a day. The Trusted Data Framework (TDF) supports these quality and trust needs by defining a standard framework for data testing and monitoring across data processing stages, accessible by technical teams and business teams. Implemented as a stand-alone module separate from existing data processing technology, the TDF fulfills the need for an independent data monitoring solution.

• Enable everyone to contribute to trusted data, not just analysts and engineers
• Enable data validations from top to bottom and across all stages of data processing
• Validate data from source system data pipelines
• Validate data transforms into dimensional models
• Validate critical company data
• Deployable independently from central data processing technology

Key Terms

• Assertion or Test Case - An individual test and the smallest unit of a test that can be performed. In TDF the test case is expressed either as a SQL statement or via a YAML configuration within SQL-compilation tool, dbt.
• Data Schema - The tables, columns, views, and other structural elements that make up a data subject area, create using SQL Data Definition Language (DDL).
• Golden Data - Golden data is a data constant from a single field or a group of fields important to the business.
• Monitoring - Tracking the results of tests cases to help ensure data is ready for use.

Trusted Data Components

The primary elements of the TDF include:

1. A Virtuous Test Cycle that embeds quality as a normal part of daily data development, ranging from new data solutions to break-fix issue resolution.
2. Test Cases Expressed As SQL and YAML which can be developed by anyone.
3. The Trusted Data Schema saves test results for monitoring and alerting, and long-term analysis towards the path of developing wisdom around business processes and data platform performance.
4. Schema-to-Golden Record Coverage to provide broad coverage of the data warehouse domain, ranging from schema to critical "Golden" data.
5. The Trusted Data Dashboard, a business-friendly dashboard to visualize overall test coverage, successes, and failures.
6. The Test Run is when a Test Cases are executed.
7. Row Count test to reconsile the amount of rows between source system and Snowflake

Virtuous Test Cycle

The TDF embraces business users as the most important participant in establishing trusted data and uses a simple and accessible testing model. With SQL and YAML as a test agent, a broad group of people can contribute test cases. The test format is straightforward with simple PASS/FAIL results and just four test case types. Adoption grows quickly as TDF demonstrates value:

• Data Customers and Business Users learn the testing framework and create tests themselves
• Teams embrace testing as a valuable activity to include at all times, not as a last-minute activity
• The Data Team learns to add new tests as part of production-down retrospectives to more rapidly identify issues before they become large problems
• Teams develop operational rythms to continually develop new tests and expand test coverage

Over time, it is not uncommon to develop hundreds of tests cases which are run on a daily basis, continually validating data quality.

Test Cases Expressed As SQL and YAML

SQL is the universal language in databases and nearly everyone who works with data has some level of SQL competency. However, not everyone may be familiar with SQL and we don't want that to limit who can contribute. We use dbt to support the TDF which enables the defining of tests via SQL and YAML.

Trusted Data Schema

With all tests being run via dbt, storing tests results is simple. We store the results of every test run in the data warehouse. Storing test results enables a variety of valuable features, including:

• data visualization and pattern analysis test results (total tests run by date, PASS/FAIL rate by subject area, and so on)
• measurement of test coverage over a data subject or schema (number of tests by area)
• measurement of system quality improvements over time (an increase in the PASS rate)
• development of an alerting system based on test result

These test results are parsed and are available for querying in Sisense.

The schema we store all test results is: WORKSPACE_DATA.
Note: This schema only containts views.

Schema To Golden Record Coverage

The Data Warehouse environment can change quickly and the TDF supports predictability, stability, and quality with test coverage of the areas in the Data Warehouse that are most likely to change:

1. Schema tests to validate the integrity of a schema
2. Column Value tests to determine if the data value in a column matches pre-defined thresholds or literals
3. Rowcount tests to determine if the number of rows in a table over a pre-defined period of time match pre-defined thresholds or literals
4. Golden Data tests to determine if pre-defined high-value data exists in a table

The implementation details of these tests are documented in our dbt guide.

Trusted Data Dashboard

The Trusted Data Dashboard as available in Sisense.

Test Run

More to come.

Row Count Test

The row count tests reconciles the amount of rows between source database and target database by extracting data from source DB tables and load into Snowflake table and extract similar stats from Snowflake and perform comparison between source and target. Their is a challenge to have an exact match between source and target, because;

• There is timing difference.
• Data warehouse might keep history.
• Deletions takes place on source database.

Depending on the scenario, its advisable to check the row count not on the highest (table) level, but check the row counts on a lower granular level. This could be one or more fields with a logical distribution, but still on a aggregated level. An example could be an insert or update date in a table.

Based on the row counts from source and row counts on the target (Snowflake data warehouse), a reconciliation can take place to determine if all rows are loaded into the data warehouse.

Row Count Tests PGP

The framework is designed to handle execution of any kind of query to perform the test. As per the current architecture every query will create one Kubernetes pod, so grouping into one query reduces creation of the number of Kubernetes pods. For record count and data actual test between postgres DB and snowflake the approach followed is grouping low volume source tables together and large volume source tables run as an individual task.

A new yaml file is created which is supposed to do all types of reconciliation (so its not incorporated in the existing yaml extraction manifest). Manifest file combines a group of low volume tables together and a large volume table as individual tasks. Row count test comparisons from Postgres and snowflake are stored in a snowflake table named "PROD"."WORKSPACE_DATA"."PGP_SNOWFLAKE_COUNTS".

Data Pump

In order to make it easy for anyone to send data from Snowflake to other applications in the GitLab tech stack we have partnered with the Enterprise Applications Integration Engineering team to create this data integration framework, which we are calling Data Pump.

This is all orchestrated in the Data Pump Airflow DAG, which runs the pump, and is set to run once daily at 05:00 UTC.

Adding a Data Pump

Step 1: Create a data model using dbt in /marts/pumps (or /marts/pumps_sensitive if the model contains RED or ORANGE Data), following our SQL and dbt style and documentation standards. Create an MR using dbt model changes template. Once this is merged and appears in Snowflake in PROD.PUMPS or PROD.PUMPS_SENSITIVE you are ready for steps two and three.

Step 2: Add Model to pumps.yml using the 'Pump Changes' MR template with the following attributes:

• model - the name of the model in dbt and snowflake
• timestamp_column - the name of the column that should be used to batch the data (or null if there is none and the table is small)
• sensitive - True if this model contains sensitive data and is in the pumps_sensitive directory and schema
• single - True if you want to create a single file in the target location. False if multiple files can be written
• stage - The name of the snowflake stage you'd like to use for the target location
• owner - your (or the business DRI's) gitlab handle

Step 3: Create an issue in the platypus project using the 'change' issue template so that the Integration team can map and integrate the data into the target application.

Operational Data Pumps

Marketing Data Mart to Marketo

The Email Data Mart is designed to automatically power updates to Marketo to enable creation of structured and targeted communications.

Trusted Data Model to Gainsight

The Data Model to Gainsight Pump is designed to automatically power updates to Gainsight to enable creation of visualizations, action plans, and strategies for Customer Success to help our customers succeed in their use of GitLab.

Qualtrics Mailing List Data Pump / Qualtrics SheetLoad

The Qualtrics mailing list data pump process, also known in code as Qualtrics SheetLoad, enables emails to be uploaded to Qualtrics from the data warehouse without having to be downloaded onto a team member's machine first. This process shares its name with SheetLoad because it looks through Google Sheets for files with names starting with qualtrics_mailing_list. For each of the files it finds with an id column as the first column, it uploads that file to Snowflake. The resulting table is then joined with the GitLab user table to retrieve email addresses. The result is then uploaded to Qualtrics as a new mailing list.

During the process, the Google Sheet is updated to reflect the process' status. The first column's name is set to processing when the process begins, and then is set to processed when the mailing list and contacts have been uploaded to Qualtrics. Changing the column name informs the requester of the process' status, assists in debugging, and ensures that a mailing list is only created once for each spreadsheet.

The end user experience is described on the UX Qualtrics page.

Debugging to Qualtrics Processes

Attempting to reprocess a spreadsheet should usually be the first course of action when a spreadsheet has an error and there is no apparent issue with the request file itself. Reprocessing has been necessary in the past when new GitLab plan names have been added to the gitlab_api_formatted_contacts dbt model, as well as when the Airflow task hangs when processing a file. This process should only be performed with coordination or under request from the owner of the spreadsheet, to ensure that they are not using any partial mailing list created by the process, as well as not making any additional changes to the spreadsheet.

To reprocess a Qualtrics Mailing List request file:
1. Disable the Qualtrics Sheetload DAG in Airflow.
2. Delete any mailing lists in Qualtrics that have been created from the erroring spreadsheet. You should be able to log into Qualtrics using the Qualtrics - API user credentials and delete the mailing list. The mailing list's name corresponds to the name of the spreadsheet file after qualtrics_mailing_list., which should also be the same as the name of the tab in the spreadsheet file.
3. Edit cell A1 of the erroring file to be id.
4. Enable the Qualtrics Sheetload DAG in Airflow again and let it run, closely monitoring the Airflow task log.

Data Spigot

A Data Spigot is a concept/methodology to give external systems, access to Snowflake data in a controlled manner. To give external systems access to Snowflake, the following controls are in place:

• A dedicated service account.
• A dedicated view (or views) only exposing the minimum required data. No Personally Identifiable Information (PII) may be disclosed.
• A dedicated role (or equivalent) with access to only the specified tables/views.
• A dedicated XS warehouse to limit and monitor costs.

The process for setting up a new Data Spigot is as follows:

1. Comply to the controls that are in place, as described above.
2. Add new Data Spigots to the table below:

Current Data Spigots

Sales Systems Use-Case: Using the Snowflake API

Visualization

We use Sisense as our Data Visualization and Business Intelligence tool. To request access, please follow submit an access request.

Meta Analyses for the Data Team

• Sisense Usage! 📈
• Sisense Account Optimization 💪
• Sisense Account Maintenance 🗑️
• dbt Event Logging
• Snowflake Spend ️❄

Security

Passwords

Per GitLab's password policy, we rotate service accounts that authenticate only via passwords every 90 days. A record of systems changed and where those passwords were updated is kept in this Google Sheet.

We also rotate Snowflake user passwords the first Sunday of every 3rd month of the year (January, April, July, October) via the Snowflake Password Reset DAG.

Software User Provisioning

The data team is responsible for provisioning users within the tools managed by the Data Team. This includes tools like Sisense, MonteCarlo, Fivetran, Stitch, and Snowflake.

For Snowflake, we have a robust process documented in the Snowflake Permissions Paradigm section of this page.

For other tools, add users via the UI and in the appropriate Google Group if one exists.

Stitch provisioning

A new user in Stitch should by default be added to the General role. This role gives sufficient access to Stitch to create new, change existing and troubleshoot running extractions.

Google Data Studio

Much like Google Drive all GitLab team members have access to Google's Data Studio which can be used to build dashboards with data from Google Sheets or other Google data sources. Hence there is no access request needed to get access provisioned to Google Data Studio. Google Data Studio is especially popular with Marketing with their use of Google Analytics. Though this resides outside of the platform described above, any data managed within Google's Data Studio must adhere to the same Data Categorization and Management Policies as we do in the rest of our platform.

There are 3 types of objects available in Google Data Studio:

• Data Sources
  • This is a connection to data sources. Currently there is no connection available/supported towards our Snowflake data warehouse.
• Reports
  • This is for creating reports based on any connected data set.
• Explorer
  • This is a tool to quickly explore data sets and find detailed insights.

The sharing and access process in Data Studio is comparable to sharing in Google Drive / Google Docs. Google Studio Objects can be shared with individuals in our GitLab organization account or with the Organization as a whole. There are no group or role level permissions available. Given the decentralized quality of managing dashboards and data sources in Data studio it is advised that business critical data and reporting be eventually migrated to Snowflake and Sisense. This is made easy with the use of sheetload or FiveTran, which has a BigQuery connector.

A GitLab Team Member that creates any artifacts in Google Studio owns the owner permissions of that particular object. With the ownership the GitLab Team Member holds responsibility to keep data SAFE within GitLab and outside the organization. Google Data Studio currently doesn't provide an admin interface that can take over the ownership. Upon off-boarding any ownership of existing objects should be carried over to ensure business continuity by the respective object owner. Note that Red Data should never be stored or transmitted within Google Data Studio.

Sales Analytics Notebooks

The Sales Analytics have a couple (but expanding) list of regular update processes that will benefit from being able to be run automatically without human intervention.

Some of those are:

1. X-Ray fitted curves calculation: Quarterly process that create a table with fitted curves to historical coverage ratios. This data is used within the X-Ray dashboard.
2. QTD Pre-Aggregated data for X-Ray and SAE Heatmap: Daily process to precalculate data aggregations at different levels. This process is much easier to run in Python than with SQL and we will be able to upload the data directly into Snowflake.

For future iterations, the Jupyter notebooks will be able to access to gSheets documents, opening the door to automating some of our regular data extracts.

For this, we have implemented a solution consisting of multiple Airflow dags, per schedule.

The process, explained

As of right now (subject to further iterations and changes), the steps are the following:

1. A Sales Analyst works on a Python Notebook (example notebook) and makes it ready for production (making sure the cell execution results are cleared, no local variables/secrets are laying around etc.)

2. The Sales Analyst uploads the notebook and its respective query in the corresponding folder, depending on what schedule the notebook should run on. The available schedules (and therefore folders) under https://gitlab.com/gitlab-data/analytics/-/tree/master/sales_analytics_notebooks are:

   • daily - daily at 6AM
   • weekly - every Monday at 6AM
   • monthly - every 7th day of the month, at 6AM
   • quarterly - every 7th day of the quarter, at 6AM

This has been implemented by creating 4 main DAGs (one per schedule) consisting of as many tasks as there are notebooks for that schedule. New tasks are dynamically added to the DAG as notebooks are committed to the repository.

The code for the dags can be found in the Sales Analytics Dags in the gitlab-data/analytics project.

Example:

Currently, under the /daily/ notebooks we have one sample notebook and its corresponding query.

This notebook runs daily and the scores produced during execution are loaded into Snowflake in the RAW.SALES_ANALYTICS schema.

For this data to be available on Sisense, dbt models will have to be written to expose them as views in the production database, under the PROD.WORKSPACE_SALES schema.

For that the Sales Analyst can either open an MR directly into the gitlab-data/analytics project, or create an issue on this project and a data platform engineer will implement the necessary dbt models.

In order to change the desired day of the week/time of these schedules, the Sales Analyst can open an issue on the gitlab-data/analytics project.

Planned (near) future work:

• Change the folder where the notebooks reside (Noel will provide a new repo for that)

• Send dag failure alerts towards the #sales-analytics-pipelines (analytics#14861), so the Sales Analysts can monitor errors with the notebooks

• If the errors seem to be platform-related, the Sales Analyst can reach out to the data platform engineers either via Slack (via the #data-engineering channel), or by opening an issue on the gitlab-data/analytics project

Sales Systems Use-Case: Using the Snowflake API

The Sales Systems team needs to run the same query several times per day against Snowflake and load that data into Salesforce.

The data team provided an API user so the Sales Analytics team can automate this process, instead of manually downloading the data and uploading it into Salesforce. More detail on this use-case can be found in the original issue #15456.

The data pulled from the database is encapsulated in a view that strictly exposes only the requested data and the sales systems team will be querying this view directly via the Snowflake API. A new role was created specifically, called SALES_SYSTEMS_SNOWFLAKE_API_ROLE for this use-case on Snowflake and it has been configured to only have read access on the underlying view.

The Snowflake API user has been created following the steps in the official Snowflake documentation on Using Key Pair Authentication and the credential is stored in our Data Team Secure vault and is to be shared with the Sales Systems team.

We created a runbook with a step-by-step guide on how to create the user and role for this purpose - link to the Snowflake API User runbook.