Snowplow

Instalação e configuração do Snowplow Open Source na Google Cloud

Snowplow é uma companhia com sede em Londres que oferece uma “Behavioral Data Platform” na nuvem e também uma versão open source. Segundo o site oficial, eles são a terceira ferramenta de web tracking mais usada, atrás do Google Analytics e Facebook.

Motivação para este post

O processo de instalação e configuração do Snowplow Open Source na Google Cloud é bastante complexo e, para piorar, a documentação está muito desatualizada.

A documentação também é open-source e eu cheguei a enviar pull requests corrigindo alguns dos erros que encontrei.
De qualquer forma, documentei tudo neste artigo para referência futura.
Espero que ajude alguém também.

Eu fiz o processo todo entre dezembro de 2022 e janeiro de 2023 usando um MacBook Pro M1. Para meu uso específico, ativei tanto BigQuery quando PostgreSQL, o que custa cerca de $240 por mês.

Normalmente usa-se apenas um Data Warehouse. Na GCP eu recomendo o BigQuery, pois:

  • Lida bem com grandes volumes de dados
  • Alguns pacotes do dbt, como o snowplow_ecommerce não são compatíveis com PostgreSQL ainda.
  • Pode custar menos, dependendo do uso (mesmo com Pub/Sub a mais)
    • O BigQuery é cobrado por uso e não por tempo online.
    • O primeiro terabyte de armazenagem é gratuito.

Visão geral

Explicando a imagem item-a-item:

  • Trackers: É de onde queremos coletar informações.
    É possível rastrear qualquer coisa capaz de fazer chamadas REST, como websites, aplicativos mobile e bancos de dados.
    As SDKs ajudam bastante nesse processo.
    Os dados são enviados seguindo um schema explícito que você mesmo define.

  • Iglu Server: Cloud Engine (com load balancer) e banco Cloud SQL.
    É um repositório de schemas.
    Eles são definidos em arquivos JSON Schema e podem ser versionados, por exemplo: YouTube JSON Schema e GA Ecommerce Schema.

  • Stream collector app: Compute Engine (com load balancer).
    Contém o endpoint HTTP que recebe eventos raw, os serializa e os envia para tópicos do Pub/Sub (sp-raw-topic ou sp-bad-1-topic).

    Se o evento for muito grande, por exemplo, ele é enviado para o tópico PubSub de bad data.

  • Enrich PubSub: Aplicação JVM no Compute Engine (uma ou mais VMs).
    Nesta etapa, eventos do Raw Stream (sp-raw-topic, escritos pelo collector) são lidos e validados.

    • Se o evento não corresponder a um schema definido no Iglu Server, esse evento é enviado para o Bad Stream.
      Isso previne dados falsos ou de má qualidade irem para produção e também permite analisar o schema recebido, o que ajuda a encontrar possíveis erros.
      No Google Analytics esses dados seriam simplesmente ignorados.
    • Se o evento corresponder a um schema, ele será “enriquecido” de acordo com o que você configurou.
      Por exemplo:
      • Separar o User Agent em partes:
        • Tipo de dispositivo
        • Sistema operacional
        • Versão do sistema
        • etc.
      • Anonimizar IPs
      • Filtrar dados pessoais (PII)
      • Extender informações de geolocalização

    Existem vários enrichments disponíveis.

    Após “enriquecido”, o evento é enviado ao tópico Good Enriched (sp-enriched-topic).

  • Loader: carrega nas tabelas
    Se o loader não estiver conseguindo inserir as linhas no BigQuery, elas são enviadas para um stream de failed inserts e a insersão é tentada novamente.

  • Mutator: É usado quando algum schema precisar ser alterado ou extendido. Todos os eventos vão para uma mesma tabela gigante. Alterar um schema pode causar um grande problema.

Terraform

Em vez de criar e configurar cada recurso manualmente pela interface do Google Cloud ou pela linha de comando, com Terraform você define, de forma declarativa, a infraestrutura como código em uma linguagem própria baseada na HCL (HashiCorp Configuration Language).

Como qualquer código, os arquivos do Terraform podem ser versionados, o que facilita realizar modificações e rollbacks.

Existe um Quick Start que realiza o deploy utilizando Terraform. Infelizmente os módulos atuais não cobrem todos os setups e alguns deles estão bem desatualizados. Ainda assim eu os usarei como base, pois o Terraform reduz o risco de erros e facilita manter a infraestrutura.

Pré-requisitos

  1. Criação de um projeto

    Crie um projeto na Google Cloud e ative billing.
    Usarei o nome projeto-snowplow neste artigo.

  2. Instalação do Terraform

    brew install terraform
    
  3. Instalação da Google Cloud CLI

    brew install google-cloud-sdk
    
    $ gcloud version
    Google Cloud SDK 412.0.0
    bq 2.0.83
    core 2022.12.09
    gcloud-crc32c 1.0.0
    gsutil 5.17
    
    gcloud auth login
    

    Adicione no ~/.zshrc:

    source "$(brew --prefix)/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc
    

    Esse comando irá adicionar o diretório /opt/homebrew/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin ao PATH.

  4. Service account

    1. Crie uma service account chamada spsetup
      Menu » IAM and admin » Service accounts » Create Service Account

    2. Crie uma chave
      KEYS » Add Key » Key type: JSON
      Salve o arquivo como ~/Snowplow/key.json

    3. Aponte a variável de ambiente para o caminho do arquivo

      export GOOGLE_APPLICATION_CREDENTIALS="/Users/julio/Snowplow/key.json"
      
  5. Ativação das APIs

    Entre em cada um dos links abaixo e ative as APIs.

  6. VPC e Subnets

    A configuração “segura” do Snowplow requer uma VPC. Ela pode ser criada pela interface web, linha de comando ou Terraform.

    • Pela linha de comando:

      gcloud compute networks create \
          vpc-snowplow \
          --project=projeto-snowplow \
          --description=Snowplow\ VPC \
          --subnet-mode=custom \
          --mtu=1460 \
          --bgp-routing-mode=regional
      
      gcloud compute networks subnets create \
          vpc-snowplow-europe-west3 \
          --project=projeto-snowplow \
          --range=10.0.0.0/24 \
          --stack-type=IPV4_ONLY \
          --network=vpc-snowplow \
          --region=europe-west3 \
          --enable-private-ip-google-access
      
    • Pelo Terraform:

      # VPC
      # https://www.terraform.io/docs/providers/google/r/compute_network.html
      # Keep the default route (0.0.0.0/0) to allow internet access
      resource "google_compute_network" "snowplow_vpc" {
        name                            = "snowplow-vpc"
        routing_mode                    = "REGIONAL"
        auto_create_subnetworks         = false
        delete_default_routes_on_create = false
      }
      
      # Private Subnet
      # https://www.terraform.io/docs/providers/google/r/compute_subnetwork.html
      resource "google_compute_subnetwork" "snowplow_private_subnet" {
        name                     = "snowplow-private-subnet-europe-west3"
        ip_cidr_range            = "10.0.0.0/24"
        region                   = var.region
        network                  = google_compute_network.snowplow_vpc.id
        private_ip_google_access = true
      }
      
  7. Cloud Router

    • Pela linha de comando:

      gcloud compute routers create router-snowplow \
      --project=projeto-snowplow \
      --description=To\ allow\ access\ to\ the\ internet \
      --region=europe-west3 \
      --network=vpc-snowplow \
      --set-advertisement-mode=custom
      
    • Pelo Terraform:

      # Cloud Router
      # https://www.terraform.io/docs/providers/google/r/compute_router.html
      resource "google_compute_router" "snowplow_router" {
        name    = "snowplow-router"
        region  = var.region
        network = google_compute_network.snowplow_vpc.id
        bgp {
          asn            = 64514
          advertise_mode = "CUSTOM"
        }
      }
      
  8. Cloud NAT

    Crie um NAT gateway. É por ele que as VMs terão acesso à internet.

    • Pelo Terraform:

      # NAT Gateway
      # https://www.terraform.io/docs/providers/google/r/compute_router_nat.html
      resource "google_compute_router_nat" "snowplow_nat" {
        name                               = "snowplow-nat"
        router                             = google_compute_router.snowplow_router.name
        region                             = google_compute_router.snowplow_router.region
        nat_ip_allocate_option             = "AUTO_ONLY"
        source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
      
        subnetwork {
          name                    = google_compute_subnetwork.snowplow_private_subnet.id
          source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
        }
      
        log_config {
          enable = true
          filter = "ERRORS_ONLY"
        }
      }
      
  9. Java

    brew install java
    brew install openjdk
    
    sudo ln -sfn \
      $(brew --prefix)/opt/openjdk@11/libexec/openjdk.jdk \
      /Library/Java/JavaVirtualMachines/openjdk-11.jdk
    
  10. Igluctl

    Copie o link da última versão disponível em https://github.com/snowplow/igluctl/releases/latest.

    wget https://github.com/snowplow/igluctl/releases/download/0.10.2/igluctl_0.10.2.zip
    unzip igluctl_0.10.2.zip
    rm igluctl_0.10.2.zip
    
    chmod +x igluctl
    mv igluctl ~/bin
    
    igluctl --version
    0.10.2
    

    Mova o executável para algum diretório no PATH. ~/bin no meu caso.

Quick Start

  1. Repositório

    Clone o repositório

    git clone https://github.com/snowplow/quickstart-examples
    
  2. Pasta do projeto

    Copie apenas o que será usado para uma nova pasta:

    cp -r quickstart-examples/terraform/gcp/iglu_server/secure ~/Snowplow/iglu_server
    cp -r quickstart-examples/terraform/gcp/pipeline/secure ~/Snowplow/pipeline
    

    Eu copiei apenas as pastas secure, pois é o recomendado para ambientes de produção. A diferença é que o Snowplow será configurado na VPC que criamos anteriormente.

Iglu Server

  1. Arquivo terraform.tfvars

    Edite o arquivo ~/Snowplow/iglu_server/terraform.tfvars:

    prefix = "sp"
    project_id = "projeto-snowplow"
    region = "europe-west3"
    network    = "snowplow-vpc"
    subnetwork = "snowplow-private-subnet-europe-west3"
    ssh_ip_allowlist = ["88.217.100.200/32", "35.235.240.0/20"]
    ssh_key_pairs = [
      {
        user_name  = "snowplow"
        public_key = "ssh-ed25519 AAAAC3NzC1lZDI…E5Gv8/gQzPr3H/9B+Nxc/GInziPJX"
      }
    ]
    
    # --- Snowplow Iglu Server
    iglu_db_name     = "iglu"
    iglu_db_username = "iglu"
    iglu_db_password = "SENHA_DO_IGLU_BD"
    iglu_super_api_key = "01234567-890a-bcde-f012-34567890abcd"
    
    user_provided_id  = ""
    telemetry_enabled = false
    
    # --- SSL Configuration (optional)
    ssl_information = {
      certificate_id = ""
      enabled        = false
    }
    
    # --- Extra Labels to append to created resources (optional)
    labels = {}
    

    Para gerar a chave SSH:

    ssh-keygen -t rsa -b 4096 -f snowplow -C "Snowplow"
    

    Para gerar um UUID aleatório: https://duckduckgo.com/?q=uuid

  2. Comandos do Terraform

    cd ~/Snowplow/iglu_server
    terraform init
    terraform plan -out plan
    terraform apply "plan"
    

    Anote a saída, que será o IP do Iglu Server.
    A saída também é salva no terraform.tfstate:

    $ grep -A1 iglu_server_ip_address terraform.tfstate
        "iglu_server_ip_address": {
          "value": "34.100.100.200",
    
  3. Adicionar schemas no Iglu server

    git clone https://github.com/snowplow/iglu-central
    cp -r iglu-central/schemas ~/Snowplow/
    rm -rf iglu-central
    
    cd ~/Snowplow
    rm -rf schemas/SCHEMAS_QUE_NAO_SERAO_USADOS
    igluctl static push --public schemas/ http://IP_DO_IGLU_SERVER 01234567-890a-bcde-f012-34567890abcd
    

    Deixe apenas os schemas que você irá utilizar na pasta schemas.
    O UUID no final do comando é a iglu_super_api_key que geramos anteriormente.

  4. Inspecionar status do Iglu Server

    O Iglu Server possui alguns endpoints para inspecionar seu próprio estado.

    $ curl http://34.100.100.200/api/meta/health/db
    OK
    
    $ curl -s http://34.100.100.200/api/meta/server \
        -H "apikey: 01234567-890a-bcde-f012-34567890abcd" | jq
    {
      "version": "0.8.7",
      "authInfo": {
        "vendor": "",
        "schema": "CREATE_VENDOR",
        "key": [
          "CREATE",
          "DELETE"
        ]
      },
      "database": "postgres",
      "schemaCount": 0,
      "debug": false,
      "patchesAllowed": true
    }
    

Pipeline

  1. Arquivo bigquery.terraform.tfvars

    Edite o arquivo ~/Snowplow/pipeline/bigquery.terraform.tfvars:

    prefix = "sp"
    project_id = "projeto-snowplow"
    region = "europe-west3"
    
    network    = "snowplow-vpc"
    subnetwork = "snowplow-private-subnet-europe-west3"
    
    ssh_ip_allowlist = ["88.217.100.200/32", "35.235.240.0/20"]
    
    ssh_key_pairs = [
      {
        user_name  = "snowplow"
        public_key = "ssh-ed25519 AAAAC3NzC1lZDI…E5Gv8/gQzPr3H/9B+Nxc/GInziPJX"
      }
    ]
    
    iglu_server_dns_name = "http://34.100.100.200"
    iglu_super_api_key = "01234567-890a-bcde-f012-34567890abcd"
    
    bigquery_db_enabled  = true
    bigquery_loader_dead_letter_bucket_deploy = true
    bigquery_loader_dead_letter_bucket_name = "sp-bq-loader-dead-letter_bucket"
    
    user_provided_id  = ""
    telemetry_enabled = false
    
    ssl_information = {
      certificate_id = ""
      enabled        = false
    }
    
    labels = {}
    
    ###########################################################################
    
    postgres_db_enabled  = true
    
    postgres_db_name     = "snowplow"
    postgres_db_username = "snowplow"
    postgres_db_password = "TYPE_PG_PASSWORD_HERE"
    
    postgres_db_authorized_networks = [
      {
        name  = "julio"
        value = "88.217.100.200/32"
      }
    ]
    
    postgres_db_tier = "db-g1-small"
    
  2. Execução do Terraform

    cd ~/Snowplow/pipeline
    terraform init
    terraform apply
    
  3. Eventos de teste

    Pegue o endereço do collector:

    $ grep -A1 collector_ip_address terraform.tfstate
        "collector_ip_address": {
          "value": "34.111.120.123",
    

    Envie os seguintes eventos de teste:

    curl 'http://34.111.120.123/com.snowplowanalytics.snowplow/tp2' \
       -H 'Content-Type: application/json; charset=UTF-8' \
       -H 'Cookie: _sp=305902ac-8d59-479c-ad4c-82d4a2e6bb9c' \
       --data-raw \
      '{
        "schema": "iglu:com.snowplowanalytics.snowplow/payload_data/jsonschema/1-0-4",
        "data": [
          {
            "e": "pv",
            "url": "/docs/open-source-quick-start/quick-start-installation-guide-on-aws/send-test-events-to-your-pipeline/",
            "page": "Send test events to your pipeline - Snowplow Docs",
            "refr": "https://docs.snowplow.io/",
            "tv": "js-2.17.2",
            "tna": "spExample",
            "aid": "docs-example",
            "p": "web",
            "tz": "Europe/London",
            "lang": "en-GB",
            "cs": "UTF-8",
            "res": "3440x1440",
            "cd": "24",
            "cookie": "1",
            "eid": "4e35e8c6-03c4-4c17-8202-80de5bd9d953",
            "dtm": "1626182778191",
            "cx": "eyJzY2hlbWEiOiJpZ2x1Om…YS03ZjRlNzk2OTM3ZmEifX1dfQ",
            "vp": "863x1299",
            "ds": "848x5315",
            "vid": "3",
            "sid": "87c18fc8-2055-4ec4-8ad6-fff64081c2f3",
            "duid": "5f06dbb0-a893-472b-b61a-7844032ab3d6",
            "stm": "1626182778194"
          },
          {
            "e": "ue",
            "ue_px": "eyJzY2hlbWEiOiJpZ2x1Om…IlB1cnBsZSBTbm93cGxvdyBIb29kaWUifX19",
            "tv": "js-2.17.2",
            "tna": "spExample",
            "aid": "docs-example",
            "p": "web",
            "tz": "Europe/London",
            "lang": "en-GB",
            "cs": "UTF-8",
            "res": "3440x1440",
            "cd": "24",
            "cookie": "1",
            "eid": "542a79d3-a3b8-421c-99d6-543ff140a56a",
            "dtm": "1626182778193",
            "cx": "eyJzY2hlbWEiOiJpZ2x1Om…lNzk2OTM3ZmEifX1dfQ",
            "vp": "863x1299",
            "ds": "848x5315",
            "vid": "3",
            "sid": "87c18fc8-2055-4ec4-8ad6-fff64081c2f3",
            "duid": "5f06dbb0-a893-472b-b61a-7844032ab3d6",
            "refr": "https://docs.snowplow.io/",
            "url": "/docs/open-source-quick-start/quick-start-installation-guide-on-aws/send-test-events-to-your-pipeline/",
            "stm": "1626182778194"
          }
        ]
      }'
    

    O comando acima envia um evento que bom e um que não corresponde a nenhum schema.

  4. Verificação no BigQuery

    Entre em https://console.cloud.google.com/bigquery?project=projeto-snowplow e encontre a tabela events no dataset sp_snowplow_db. Verifique se há algum dado na aba PREVIEW.

    Essa é a tabela de “good data”.

    O pipeline para “bad data” não está incluso no Quick Start e deve ser criado manualmente.

  5. Verificação no PostgreSQL

    Pegue o IP do banco:

    $ grep -A1 postgres_db_ip_address terraform.tfstate
      "postgres_db_ip_address": {
        "value": "34.89.100.100",
    

    Conecte-se usando algum programa como o DBeaver:

    • Host: 34.89.100.100
    • Database: snowplow
    • Port: 5432
    • Username: snowplow
    • Password: TYPE_PG_PASSWORD_HERE

    A tabela de “good data” é a atomic.events.
    Ela deverá estar vazia, pois a fila já foi consumida pelo BigQuery.
    É necessário duplicar a fila para que o PostgreSQL também receba os eventos.

    Existem várias tabelas de “bad data”, uma delas é a atomic_bad.com_snowplowanalytics_snowplow_badrows_schema_violations_1.

Próximos passos

  • Configurar domínio e ativar SSL
  • Criar schemas próprios
  • Bad data no BigQuery

Julio Batista Silva
Julio Batista Silva
Engenheiro de Dados

Eu sou um engenheiro de computação apaixonado por ciência, tecnologia, fotografia e idiomas. Atualmente trabalhando como Engenheiro de Dados na Alemanha.

comments powered by Disqus