Criando uma plataforma de dados, Parte 1: A Fundação
Muitas organizações já passaram por pelo menos uma dessas questões: Como criar uma plataforma de dados? Por onde começar?
Bom, esse artigo visa responder essas perguntas com uma solução: E se pudéssemos experimentar criando uma plataforma a partir do “zero” com as melhores práticas para que as organizações pudessem explorar e criar suas próprias “data pipelines” a partir de uma fundação sólida?
Dessa forma, a proposta dessa série é criar uma plataforma completa usando uma arquitetura de referência.
Então, vamos com a parte 1 de uma série a seguir:
- Parte 1: A fundação
- Parte 2: Deploy de uma pipelines de dados integrado com Gitlab
- Parte 3: Gerenciando seu catálogo de dados
- Parte 4: Anonimizado seus dados usando Data Loss Prevention
- Parte 5: Gerenciando chaves de criptografia com chaves customizadas pelo cliente
- Parte 6: Gerenciando diversos níveis de permissões com Bigquery
Vamos então criar nossa fundação. A abordagem dessa plataforma sugerida é basicamente:
- criar limites para cada passo: (a) para carregar; (b) orquestrar; (c) transformar; e (d) e expor os dados;
- definir atores com responsabilidades e papéis: Engenheiras de dados, Analistas de dados e Analistas de segurança de dados (Data security Team);
- seguir o princípio do privilégio mínimo: um(a) usuário(a) deve ter acesso apenas ao que é absolutamente necessário para desempenhar suas responsabilidades e nada mais;
- confiar na representação da conta de serviço: demonstraremos como aproveitar a representação para evitar a necessidade de criar chaves de conta de serviços.
A plataforma de dados
Como acelerador, vamos partir de uma plataforma de referência que é demonstrada a seguir:
Assim vamos demonstrar como criar vários projetos, um projeto para cada etapa do fluxo dos dados, seguindo o princípio de segmentar e isolar cada etapa.
As etapas identificadas são:
- Zona de entrega ou zona efêmera (drop-off)
- Zona de carregamento (load)
- Zona de armazenamento de dados (data warehouse)
- Zona de orquestração
- Zona de transformação
- Zona de exposição
Aderindo assim ao princípio de privilégio mínimo usando funções em nível de projeto. Como já dito, e reforçando, para separar as responsabilidades cada zona ficará em um projeto distinto, conforme a seguir:
Zona de entrega ou zona efêmera (drop off area):
- Usada para armazenar dados temporários. Os dados são enviados para o Cloud Storage, BigQuery ou Cloud PubSub. Os recursos são configurados com uma política de ciclo de vida personalizável.
Zona de carregamento (load area):
- Usada para carregar dados da zona de efêmera para o data warehouse. A carga é feita com lógica de transformação mínima ou nenhuma transformação (basicamente conversões de tipos). A anonimização ou tokenização de Informações de Identificação Pessoal (PII) pode ser implementada aqui ou na fase de transformação, dependendo dos seus requisitos.
Zona de armazenamento de dados (Data Warehouse):
Vários projetos distribuídos em 3 camadas separadas, para hospedar dados progressivamente processados e refinados:
- Zona de aterrissagem (Landing zone): área onde ficam os dados brutos e dados estruturados, armazenados em formatos relevantes: (a) dados estruturados armazenados no BigQuery; (b) dados não estruturados armazenados no Cloud Storage com metadados adicionais armazenados no BigQuery (por exemplo, imagens armazenadas no Cloud Storage e análise das imagens para a API Cloud Vision armazenadas no BigQuery).
- Zona de dados curados (Curated zone): dados limpos, agregados e curados
- Zona confidencial (Confidencial zone): camada com curadoria e não criptografada
- Zona de recreação (Playground): tabelas temporárias que os analistas de dados usarão para realizar P&D (Pesquisa & desenvolvimento) em dados disponíveis em outras camadas de data warehouse.
Zona de orquestração (Orchestration):
Usada para hospedar o Cloud Composer (Airflow), que orquestra todas as tarefas que movem dados entre camadas.
Zona de transformação (Transformation):
Usada para mover dados entre camadas do Data Warehouse. É altamente recomendável confiar no BigQuery Engine para realizar as transformações. Se o BigQuery não tiver os recursos necessários para realizar suas transformações, você poderá usar o Cloud Dataflow com modelos previamente definido. Este estágio também pode opcionalmente anonimizar ou tokenizar PII.
Zona de exposição (Exposure):
Usada para hospedar recursos que compartilham dados processados com sistemas externos. Dependendo do padrão de acesso, os dados podem ser apresentados por meio do Cloud SQL, BigQuery ou Bigtable. Para dados do BigQuery, sugerimos que você confie nas visualizações autorizadas.
Funções e contas de serviço
Vamos atribuir funções aos recursos no nível do projeto, concedendo as funções apropriadas por meio de grupos (pessoas humanas) e contas de serviço (serviços e aplicativos) de acordo com as melhores práticas.
Por exemplo, para o projeto da área de entrega ou efêmera (drop off), será conforme essa tabela:
Assim, apenas pessoas com grupo gcp-data-engineers terão acesso a essa zona, assim como as demais contas de serviço (ao todo 5 contas).
Uma referência completa das funções do IAM gerenciadas por essa sugestão de plataforma de dados, pode ser vista neste link.
Grupos de usuários
Os grupos de usuárias fornecem um quadro de referência estável que permite dissociar o conjunto final de permissões do estágio em que as entidades e os recursos são criados e suas associações do IAM definidos.
Usamos três grupos para controlar o acesso aos recursos:
Pessoas engenheiras de dados (Data Engineer):
- Elas gerenciam e executam o Data Hub, com acesso de leitura a todos os recursos para solucionar possíveis problemas com pipelines. Essa equipe também pode representar qualquer conta de serviço.
Pessoas analistas de dados (Data Analyst):
- Eles realizam análises em conjuntos de dados, com acesso de leitura ao projeto Data Warehouse Confidential e acesso de LEITURA/GRAVAÇÃO do BigQuery ao projeto Playground.
Pessoas de segurança de dados (Data Security):
- Elas lidam com configurações de segurança relacionadas ao Data Hub. Essa equipe tem acesso de administrador ao projeto comum para configurar modelos do Cloud DLP ou tags de política do Data Catalog.
A tabela abaixo mostra uma visão geral de alto nível das funções de cada grupo em cada projeto, usando padrões de acesso READ, WRITE e ADMIN para simplificar.
Criando a plataforma
Uma vez definido a estrutura dos projetos, as contas de serviços, grupos de usuários, agora vamos finalmente criar a nossa plataforma.
Como acelerador, vamos usar um script em terraform para criar essa plataforma de referência, siga os passos abaixo:
1. Verifique os requisitos:
- Vamos precisar de uma organização GCP e de uma conta de serviço com permissão de folder Admin e projector Creator.
- Definir uma billing account. Veja aqui como fazer.
- Instalar o Git no terminal (nesse exemplo, no cloud shell). Detalhes aqui.
- Instalar Terraform cli (também no cloud shell). Detalhes aqui.
2. Na sua organização, crie um folder à sua escolha. Aqui definimos como DATA-PLAT usando o cloud shell.
3. Usando o cloud shell você já terá instalado o git + terraform, então primeiramente faça o clone do repositório, com esse comando:
Veja aqui como usar Cloud Shell.
4. Navegue para a pasta onde está o script que vamos rodar.
5. Faça uma cópia do terraform.tfvars.sample com o nome terraform.tfvars e altere as seguintes variáveis conforme sua organização:
Altere as seguintes variáveis:
6. Na sua organização crie três grupos conforme a seguir:
7. Finalmente agora bastará aplicar* para criar os recursos:
Agora é só esperar, pois em cerca de 25 minutos você terá uma plataforma pronta para usar no Google Cloud!
Ao terminar salve a saída da sua execução do script terraform pois vamos usar no próximo passo. Ao todo serão criados 10 projetos, e ficará conforme a seguir:
Executando um teste “drive” na plataforma recém criada.
Agora com os projetos criados, vamos testar a plataforma executando uma DAG no Composer (Airflow). No passo anterior, pedimos para você salvar a saída da execução do “terraform apply”, pois vamos usar alguns comandos sugeridos nessa saída.
No caso dessa demo apresentada nesse artigo, a saída foi (visão parcial da saída):
Para testar siga os passos:
- Copie os dados de exemplo para zona de entrega ou zona efêmera (drop off) utilizando os comandos sugeridos. E copie também o schema dos dados para a área de orquestração.
2. Agora, vamos subir uma DAG de exemplo para fazer a ingestão e transformar esses dados.
3. Agora vamos abrir o Composer. Você pode ir no projeto dat-plat-orc >> Composer e abrir a UI do Airflow, conforme demonstrada na imagem abaixo:
Execute manualmente a DAG com o nome data_pipeline_dag
4. PRONTO!!! Agora é só ir no projeto dat-plt-dwh-cur e visualizar os dados importados no Bigquery.
Parabéns! Você aprendeu aqui como criar uma plataforma de dados usando uma arquitetura de referência a partir de um script de terraform.
Mais detalhes sobre essa plataforma de referência podem ser encontrados aqui.
Agora, tente você mesmo criar a sua plataforma usando sua conta GCP e sua organização. E ao final você pode destruir todos recursos com o comando: terraform destroy.
Agradecimentos e créditos
Agradeço a Lorenzo Caggioni por compartilhar e colegas do Google por construir esses módulos com IaC como aceleradores para nossos clientes.
* Você pode rodar o comando terraform plan para verificar quais recursos serão criados, caso deseje verificar a lista de recursos e projetos.
