Introdução ao BigQuery — Parte 1

https://www.cmarix.com/blog/key-benefits-of-google-bigquery-to-manage-serverless-data-warehousing/

Bem vindo a mais um post da Kompa Data & AI :) Hoje falaremos de uma tecnologia muito famosa e referência em data warehousing: o BigQuery! Não somente hoje na verdade, mas como essa é uma ferramenta muito fácil de usar mas muito complexa para dominar, faremos uma série de 8 posts sobre o tema. Eles serão:

1. O que é o um Data Warehouse e por que utilizar o BigQuery
2. Usabilidade do BigQuery (UI, projetos, datasets, tabelas, views, queries etc)
3. Pricing e Execution Plan: como ler e entender
4. Data Sources e Conexões
5. Segurança e governança no BigQuery
6. Melhores práticas para organização, performance, custo e storage
7. Como estruturar seu DW: arquitetura e primeiros passos
8. Machine Learning no BigQuery (regressão, classificação, clusterização, recomendação e TensorFlow)

A ideia dessa série é apresentar, de forma completa, essa ferramenta tão importante para estoque, manipulação e análise de dados para pessoas que estão iniciando na sua jornada de análise de dados na nuvem. Hoje vamos introduzir a ferramenta e contextualiza-lo(a) sobre seu uso. Sem mais delongas, bora pro post!

Contextualização

Você já deve ter ouvido algum jargão do tipo "data is the new oil" (dados são o novo petróleo), numa alusão da importância estratégica que os dados representam para uma organização atualmente. Ou ainda, deve ter visto alguma palestra de que para manter um diferencial competitivo, uma empresa precisa passar por uma transformação "data-driven". Bom, por trás desse "hype", é inegável que saber extrair inteligência de seus dados é fundamental para otimizar sua tomada de decisões.

Com isso em mente, considere o mar de fontes de dados que uma organização pode ter simultaneamente: dados transacionais, financeiros, CRM, Google Analytics, Ads, logs de sistemas, dados de usabilidade dos usuários, fontes externas etc! Fica bem claro que precisamos de uma arquitetura que ofereça uma ótima governança de dados, performance para grandes consultas analíticas e possibilidade de integração com diversas fontes de dados, inclusive real-time, para tomada de decisões baseados em dados. Temos, então, o Data Warehouse.

O que é um Data Warehouse?

O conceito de um Data Warehouse (DW) é simples: é basicamente um local de armazenamento (banco de dados, não necessariamente relacional) de dados cujo objetivo principal é oferecer a infraestrutura necessária para reports, análises, BI e machine learning.

Como o próprio nome sugere, é um Armazém de Dados, então podemos imaginar que seus aspectos são: um lugar para armazenar (storage), processos para transformar os dados e fazer o delivery no formato desejado com cadência geralmente regular (processamento), e uma série de políticas de governança para gestão e administração de todos esses dados. Sendo assim, centraliza e consolida grandes quantidades de dados de várias fontes e uma solução de extração, carregamento e transformação (ELT) para preparar os dados para análise, tudo num só lugar com formato padronizado (lembrando que padronizado não é a mesma coisa que estruturado).

Porém, fica o questionamento: por que usar um Data Warehouse e não um Data Lake ou um banco de dados relacional tradicional para minhas análises?

Qual a diferença entre um Data Lake e um Data Warehouse?

De uma maneira resumida e muito superficial:

• Data Lake armazena e trata dados de todas as naturezas e qualidades: não estruturados(imagens, textos, audios etc), semiestruturados(JSON, XML etc) e estruturados (dados relacionais).O DW preferencialmente lida com dados estruturados (dados relacionais), representando uma versão "definitiva" da verdade.
• o esquema (schema) de um Data Lake, pelo menos em suas camadas mais quentes/perto da entrada, são definidas em momento de leitura. Os esquemas de uma DW são menos dinâmicos, geralmente planejados no momento de construção do mesmo, muito semelhante a um schema tradicional de banco de dados relacional. Porém, há casos no DW com schemas definidos em momento de leitura.

Poderíamos apresentar N outras diferenças comparativas entre as 2 soluções, mas de uma forma geral, Data Lakes existem para o processamento e gestão de Big Data (lembra dos 5 Vs?) focando no custo benefício operacional de todos esses dados. Então se você precisa processar milhões de eventos de diversas fontes, em formas e velocidades diferentes para sua aplicação, use um Data Lake. Já se você precisa extrair inteligência de seus dados estruturados para tomar decisões impactantes no negócio (lembrando que pode ser um humano ou máquina fazendo isso), use um DW. Ademais, precisamos sempre lembrar que essas tecnologias não são excludentes, mas complementares.

Qual a diferença entre um DW (OLAP) e um banco de dados relacional (OLTP)?

Começando um pouco sobre o significado das sílabas, OnLine Transactional Processing (OLTP) permite execuções em real-time de grande números de transações pouco complexas por um grande número de agentes pensando em alterações, adições e exclusões (UPDATE, INSERT, DELETE). Enquanto isso, OnLine Analytical Processing (OLAP) é um sistema para trabalhar com análises multi-dimensionais numa alta velocidade em altos volumes de dados. Uma outra forma de pensar na diferença dessas 2 arquiteturas, é que o OLTP foca em performance para alterações em rows (linhas), enquanto o OLAP foca em performance para leitura e manipulação de columns (colunas), muitas vezes agregados advindos de sistemas OLTP. A conexão entre OLTP e OLAP (geralmente nessa ordem), se dá por meio de um processo de ETL (Extract, Load and Transform).

OLAP é otimizado para conduzir análises complexas de dados para tomadas de decisão mais inteligentes. Os sistemas OLAP são projetados para uso por cientistas de dados, analistas de negócios e profissionais do conhecimento, e oferecem suporte a business intelligence (BI) e ferramentas para tomadas de decisões. Seu tempo de resposta geralmente se dá na casa de segundos ou minutos. O OLTP, por outro lado, é otimizado para processar um grande número de transações. Os sistemas OLTP são projetados para uso por funcionários de linha de frente (por exemplo, sistemas financeiros, hotelaria, banco de dados de senhas e etc…). Seu tempo de resposta geralmente se dá na casa de milisegundos.

Juntando DW, banco de dados e Data Lake

A partir das definições acima, podemos entender que para cada caso, há uma solução de storage otimizada às suas necessidades. O mais comum numa empresa é usarmos vários tipos de soluções de storage para cada etapa de processamento de dados, inclusive até soluções não mencionadas aqui. Num modelo genérico, geralmente temos:

Fonte: https://aws.amazon.com/pt/data-warehouse/

• Dados chegando num banco de dados relacional e/ou data lake, a depender da natureza desses dados. Repare que o foco nessa etapa é facilidade e performance de processamento de dados.
• Dados sendo preparados para consumo, num processo de ETL servindo de ponte entre zona crua e DW.
• Dados já prontos para análise/consumo analítico num data warehouse, que geralmente também vai apresentar uma ferramenta/política de data discovery e governança.
• Reports e análises sendo gerados.

O que é o BigQuery (BQ)?

Agora que você já sabe o que é um DW e por que usar um, vamos falar da tecnologia que escolhemos na Kompa para abrigar nosso warehouse: o Big Query! De acordo com a própria Google:

BigQuery is a fully-managed enterprise data warehouse that helps you manage and analyze your data with built-in features like machine learning, geospatial analysis, and business intelligence. BigQuery’s serverless architecture lets you use SQL queries to answer your organization’s biggest questions with zero infrastructure management. BigQuery’s scalable, distributed analysis engine lets you query terabytes in seconds and petabytes in minutes.

Ok, bastante informação. Vamos por partes:

• fully-managed enterprise data warehouse quer dizer que o BQ é pensado para ser usado em escala empresarial sem que seus usuários se preocupem em gerenciar sua infraestrutura. Isso é muito prático pois só temos que nos preocupar com a governança de dados, e não do sistema em si. Isso traz muito mais agilidade para o time de engenheiros, cientistas e analistas de dados.
• helps you manage and analyze your data descreve justamente o que falamos até agora sobre DWs
• built-in features like machine learning, geospatial analysis, and business intelligence mostra que o BQ, além de permitir uma comunicação via Standard SQL, traz funcionalidades analíticas extras para o usuário como a possibilidade de construção, importação, avaliação e deploy de modelos de Machine Learning (ML), bem como tipos de dados específicos do BQ como dados geo-espaciais e conexões a engines de Business Intelligence (BI), como o Google Data Studio.
• BigQuery’s scalable, distributed analysis engine lets you query terabytes in seconds and petabytes in minutes…basicamente, o BQ foi construído pensado em computação paralelizada em larga escala. Se você tem curiosidade sobre como o BQ funciona "under the hood", recomendo fortemente a leitura desse post e esse podcast, no qual os autores explicam os sistemas Dremel (engine de execução), Colossus (storage distribuído), Borg (processamento) e Jupiter (rede). Abaixo, você pode ver a arquitetura do BQ:

Fonte: https://cloud.google.com/blog/products/bigquery/bigquery-under-the-hood

Funcionalidades

Sendo um DW serverless baseado em SQL, o BQ apresenta as seguintes principais funcionalidades:

• Storage para grandes volumes de dados, baseado em projetos, datasets e tabelas, com a possibilidade de escolha de regiões e zonas pelo globo de forma granular. A alimentação desses dados pode ser realizada de diversas formas, como batch-loading, streaming, BQ Data Transfer
• Capacidade de querying baseado em ANSI-standard SQL, tanto de dados localizados no BQ como em outras soluções de storage (Cloud Storage, Cloud SQL, Spanner e Google Sheets) por meio de queries federadas.
• Conexão nativa com engines de BI como Data Studio, Looker e Google Sheets, bem como soluções terceiras como Tableau e Power BI.
• Governança de dados granular, apoiando-se no GCP IAM. É possível realizar a gestão de acesso a níveis desde projetos até linhas ou colunas.
• Suporte nativo a alguns algoritmos de Machine Learning e importação de modelos baseados em TensorFlow

Próximos passos

Nesse post nós fomos introduzidos aos conceitos de Data Warehouse e funcionalidades do BigQuery. No próximo post, apresentaremos a UI e a API do BigQuery, bem como faremos um tour pela sua usabilidade e uma demonstração do querying dentro da ferramenta!