Data Lakes Com Google Cloud Platform

Modernizando Data Lakes e Data Warehouses com GCP
Semana 1
Introdução a Data Engineering
Olá! Este é o curso "Engenharia de dados no Google Cloud Platform". Sou Lak, líder da equipe
de Soluções de análise de dados e IA. No programa de aprendizado de Engenharia de dados
deste curso vamos discutir as diferenças entre data lakes e armazenamentos de dados. Depois
falaremos sobre a função principal dos engenheiros de dados, que é a criação de pipelines. No
terceiro curso da especialização falaremos sobre sistemas de streaming e desempenho e, no
curso final falaremos sobre análise e inteligência artificial na engenharia de dados. Neste
curso, que é o primeiro da especialização o curso sobre a modernização de data lakes e
armazenamentos de dados com o GCP começaremos com a descrição da função dos
engenheiros de dados. Falaremos sobre os clientes dos engenheiros e as vantagens que um
pipeline de dados correto traz para sua empresa. Também explicaremos por que você deve
fazer engenharia de dados na nuvem. O tema deste curso são os data lakes e os
armazenamentos de dados porque eles são os principais componentes dos pipelines.
Explicaremos as diferenças entre eles e os casos de uso de cada um. Também mostraremos as
soluções de data lakes e armazenamentos de dados disponíveis no Google Cloud Platform
além dos detalhes delas. Por último, você fará atividades práticas com data lakes,
armazenamentos de dados e o GCP no Qwiklabs.
Principal função do engenheiro de dados é a criação de pipelines
Conheça o papel do engenheiro de dados
Olá! Este é nosso curso de Engenharia de dados. Sou Lak, líder de Soluções de análise e IA do
Google Cloud. O tema deste módulo é o papel dos engenheiros de dados. Quem são os
engenheiros de dados? São pessoas que criam pipelines de dados. Vamos ver o que isso
significa, qual tipo de pipelines eles criam e qual é o propósito desses pipelines. Depois disso,
vamos explicar por que nós recomendamos fazer a engenharia de dados na nuvem
especificamente no Google Cloud Platform. Veremos os desafios da engenharia de dados e
como é mais fácil superá-los quando você cria pipelines de dados na nuvem. Depois veremos
qual é o objetivo dos pipelines de dados criados. Quais vantagens você traz para sua
organização quando cria pipelines de dados corretamente? Por último, veremos algumas
arquiteturas de referência que são arquiteturas para você adaptar.
Para fazer isso, você precisa saber o propósito de cada elemento delas. Por isso veremos mais
detalhes dos componentes na especialização. Começaremos com uma visão geral do propósito
dos produtos. O que os engenheiros de dados fazem? Como já dissemos, eles criam pipelines
de dados.
Mas por quê? Por que os engenheiros de dados criam pipelines?
Porque eles querem levar os dados a um componente como um painel, relatório ou modelo de
machine learning que a empresa usará para tomar decisões baseadas em dados. O propósito
do pipeline é usar os dados para tomar decisões.
Para isso, os dados precisam estar nas condições certas para que possam ser usados para
tomar decisões. Os dados brutos não são muito úteis sozinhos.
Um termo que você ouve com frequência na engenharia de dados é "data lake". O data lake
reúne dados de toda a empresa em um só lugar. É possível extrair os dados de um banco de
dados relacional ou de uma planilha e armazenar no data lake.
Uma opção de local único para armazenar dados brutos são os buckets do Cloud Storage.
O que você deve considerar na hora de escolher entre as opções de data lake? O que você
acha?
O que você deve considerar quando criar um data lake? Primeiro, o data lake é compatível
com os tipos de dados presentes? Eles cabem em um bucket do Cloud Storage? Se você tiver
um banco de dados relacional ou RDBMS, talvez precisará colocar os dados não em um bucket
mas no Cloud SQL, um banco de dados gerenciado. Segundo, ele é escalonável de acordo com
a demanda?
Você ficará sem espaço se o volume dos dados coletados aumentar? Esse problema é mais
frequente nos sistemas locais do que na nuvem.
Terceiro, ele faz ingestão de alta capacidade? Qual é a largura de banda da rede? Existem
pontos de presença de borda?
Quarto, há controle de acesso granular aos objetos? Os usuários precisam pesquisar dentro de
arquivos? Ou precisam apenas do arquivo inteiro? O Cloud Storage usa o armazenamento de
blob. Você precisa considerar a granularidade dos itens armazenados. Quinto, outras
ferramentas podem se conectar facilmente? Como elas acessam o armazenamento? Não se
esqueça de que o data lake serve para disponibilizar os dados para análises.
Falamos de um produto do Google Cloud, os buckets do Cloud Storage que são uma boa opção
para preparar os dados brutos antes de criar pipelines de transformação no armazenamento
de dados. Por que escolher o Google Cloud Storage? Geralmente, muitas empresas usam o
Cloud Storage como utilitário de backup e arquivamento. Com os vários data centers e a alta
disponibilidade de rede do Google o armazenamento em buckets do GCS é durável e de alto
desempenho.
Os engenheiros de dados usam buckets do Cloud Storage como parte de um data lake para
guardar vários arquivos de dados brutos CSV, JSON, Avro, parquet etc.
Depois, é possível carregá-los ou consultá-los no BigQuery que é um armazenamento de

dados. Neste curso, você criará buckets do Cloud Storage usando o Console e a linha de
comando, como neste slide. Depois que você configura e carrega os dados no bucket outros
produtos do Google Cloud Platform podem consultá-los.
Por falar em carregamento de dados e se for necessário processar os dados brutos? Talvez seja
necessário extrair os dados do local original, transformá-los e carregá-los. Uma opção é fazer o
processamento em uma ferramenta como o Cloud Dataproc ou o Cloud Dataflow. Vamos
explicar como usar esses produtos para pipelines de dados neste curso.
E se os pipelines em lote não forem suficientes? E se você precisar de análise em tempo real de
dados que chegam continuamente?
Nesse caso, você pode receber os dados no Cloud Pub/Sub transformá-los no Cloud Dataflow e
fazer o streaming deles no BigQuery. Também vamos falar sobre pipelines de streaming neste
curso.
Quickly create buckets with cloud shell

gsutil mb gs://your-project-name
Analise os desafios da engenharia de dados
Vamos ver alguns desafios que os engenheiros de dados enfrentam. Na engenharia de dados
você geralmente vai enfrentar alguns problemas quando criar pipelines. Talvez você tenha
dificuldade para acessar os dados necessários. Talvez você descubra que mesmo depois do
acesso os dados não têm a qualidade necessária para a análise ou o modelo de machine
learning. Você planeja criar um modelo e mesmo com dados de qualidade talvez as
transformações exijam recursos computacionais que você não tem. E você pode enfrentar
desafios relacionados ao desempenho das consultas e à capacidade de executar consultas e
transformações com os recursos computacionais à sua disposição. Vamos analisar o primeiro
desafio. O desafio de consolidar conjuntos de dados diferentes e formatos diferentes, além de
gerenciar os dados na escala certa. Por exemplo, você quer calcular o custo de aquisição de
clientes. Quanto custa adquirir um cliente em termos de marketing, promoções e descontos?
Talvez esses dados estejam espalhados por vários produtos de marketing e softwares de
relacionamento com o cliente. Talvez seja difícil encontrar uma ferramenta para analisar todos
os dados porque eles vêm de organizações diferentes de ferramentas diferentes com
esquemas diferentes. Talvez parte dos dados não esteja estruturada. Para descobrir algo
essencial para a sua empresa como o custo de adquirir um novo cliente e saber quais
descontos você deve oferecer para mantê-lo os dados não podem estar nesses tipos de silos.
O que dificulta o acesso aos dados?
A causa principal é este problema. O fato de que os dados, em muitas empresas estão
divididos entre departamentos e cada departamento cria sistemas transacionais próprios para
dar suporte aos processos comerciais deles. Por exemplo, pode haver sistemas operacionais
que correspondem a sistemas de lojas diferentes que são mantidos por armazéns que
gerenciam o inventário. Talvez a empresa tenha um departamento de marketing que gerencia
todas as promoções. Imagine que você precisa fazer uma consulta de análise para identificar
todas as promoções em loja em pedidos recentes e também o número de itens no inventário.
A consulta é: mostre todas as promoções na loja de pedidos recentes e o nível de inventário
deles. Nessa consulta você precisa combinar dados das lojas dados das promoções dados dos
níveis de inventário. Esses dados são armazenados em sistemas separados e geralmente com
acesso restrito então criar um sistema de análise que use os três conjuntos de dados para
responder uma consulta ad hoc pode ser algo difícil.
O segundo desafio é que a limpeza, a formatação e a preparação dos dados para insights exige
a criação de pipelines "extrair, transformar, carregar", ou ETL.
Os pipelines de ETL são geralmente necessários para garantir a exatidão e a qualidade dos
dados.
Os dados limpos e transformados não costumam ser armazenados no data lake mas em um
armazenamento de dados. Um armazenamento de dados é um local consolidado, como o data
lake é um local consolidado. Mas desta vez, os dados armazenados são compatíveis com
mesclagens e consultas.
Ao contrário do data lake, em que os dados estão em estado bruto, no armazenamento eles
são organizados de maneira a agilizar as consultas.
Como os dados só são úteis após a limpeza você deve considerar que os dados brutos
coletados em sistemas de origem precisam ser limpos e transformados.
Já que você vai transformá-los é melhor usar um formato que torna as consultas mais
eficientes. Ou seja, faça o ETL dos dados e guarde-os em um armazenamento de dados.
Imagine que você trabalha em um varejista e precisa consolidar dados de vários sistemas.
Pense no caso de uso. Se o caso de uso for identificar as promoções em loja mais eficientes na
França será necessário extrair os dados das lojas e os relacionados às promoções e talvez você
descubra que faltam algumas informações nesses dados. Talvez algumas transações sejam em
espécie e não haja a identificação do cliente nessas transações em espécie. Ou talvez algumas
transações estejam divididas em vários recibos e você precise combinar essas transações,
porque elas são do mesmo cliente. Ou talvez os carimbos de data/hora dos produtos estejam
no horário local. As lojas estão espalhadas pelo mundo então você precisa converter tudo para
UTC antes de fazer qualquer coisa. Talvez as promoções não estejam armazenadas no banco
de dados de transações. Talvez elas estejam em um arquivo de texto que alguém carrega na
página da Web com uma lista dos códigos que são usados pelo aplicativo para aplicar
descontos.
Pode ser muito difícil fazer uma consulta para realizar as promoções em loja e identificar as
promoções em loja mais eficientes porque existem todos os problemas que mencionamos nos
dados.
Quando os dados estão dessa forma você precisa transformar os dados brutos em um formato
que permita realizar a análise necessária.
É melhor fazer a limpeza e consolidação só uma vez e armazenar os dados limpos para facilitar
as próximas análises. Esse é um objetivo do armazenamento de dados.
Quando você precisa fazer muitas consolidações e limpezas um problema que surge com
frequência é onde realizar a computação.
A própria disponibilidade dos recursos computacionais pode ser um desafio.
Por quê? Em um sistema local os engenheiros de dados precisam gerenciar a capacidade de

servidores e clusters para que eles possam fazer o job de ETL dentro do prazo para a conclusão
dele. O problema é que os jobs de ETL não exigem os mesmos recursos ao longo do tempo.
Isso costuma variar entre as semanas e depende de fatores como feriados e promoções.
Isso significa que quando o tráfego está baixo você desperdiça dinheiro porque os
computadores não fazem nada. E quando o tráfego está alto, os computadores ficam tão
ocupados que os jobs demoram demais.
Quando os dados estão no armazenamento você precisa otimizar as consultas feitas pelos
usuários para racionalizar o uso dos recursos computacionais.
Isso é difícil se você gerencia um cluster de análise de dados local porque você é responsável
por escolher um mecanismo de consultas e instalar o software correspondente e mantê-lo
atualizado, além de provisionar mais servidores para aumentar a capacidade.
Não há uma maneira melhor de administrar o gasto com servidores para que a empresa se
concentre nos insights?
Introdução ao BigQuery
É claro que existe uma maneira melhor de administrar os custos de servidor para se concentrar
em insights.
Trata-se de um armazenamento de dados sem servidor. O BigQuery é o armazenamento de

dados sem servidor do Google Cloud com escala de petabytes. Você não precisa gerenciar
clusters. Basta se concentrar nos insights. O serviço BigQuery substitui o hardware comum de
um armazenamento de dados tradicional. Ou seja, ele é uma central coletiva para todos os
dados de análise na organização. Os conjuntos são coleções de tabelas que podem ser
divididos por linhas de negócios ou por domínios de análise. Cada conjunto está ligado a um
projeto do GCP. Um data lake pode conter arquivos no Cloud Storage no Google Drive ou
dados transacionais no Cloud Bigtable ou no Cloud SQL.
O BigQuery pode definir um esquema externo e fazer consultas nesses dados externos como
uma fonte de dados federada. As tabelas e as visualizações do banco de dados funcionam no
BigQuery da mesma maneira que em um armazenamento de dados tradicionais. Por isso, o
BigQuery aceita consultas escritas em dialeto SQL padrão, compatível com NC 2011. O Cloud
Identity and Access Management ou Cloud IAM, é usado para dar permissões para ações
específicas no BigQuery. Ele substitui as instruções de concessão e revogação de SQL que são
usadas para gerenciar permissões em bancos de dados SQL tradicionais. Um fator importante
da agilidade é poder fazer mais com menos além de não fazer coisas que não agreguem valor.
Se você realiza um trabalho que é igual em vários setores provavelmente não é algo que sua
empresa queira pagar. É algo que você quer comprar. Com a nuvem, os engenheiros de dados
passam menos tempo gerenciando hardware e mais tempo fazendo coisas mais personalizadas
e específicas para sua empresa. Você não precisa se preocupar com provisionamento,
confiabilidade melhorias de desempenho ou ajustes na nuvem. Como você não precisa se
preocupar com todas essas coisas pode dedicar seu tempo a imaginar maneiras de gerar
insights dos dados. Dissemos que não é preciso provisionar recursos para usar o BigQuery, ao
contrário de outros RDBMSs. Como isso funciona? O BigQuery aloca armazenamento e recurso
de consulta de forma dinâmica com base nos padrões de uso. Os recursos de armazenamento
são alocados quando você os usa e desalocados quando você remove dados ou apaga tabelas.
Os recursos das consultas são alocados de acordo com o tipo e a complexidade. Cada consulta
usa algumas unidades de um recurso chamado slot. Os slots são unidades de computação
formadas por recursos de CPU e RAM.
Data lakes e armazenamentos de dados
Nós mostramos a definição de data lakes e de armazenamentos de dados. Vamos ver mais
detalhes sobre eles.
Enfatizamos que os dados precisam estar em condições utilizáveis para serem usados para
tomar decisões. Muitas vezes, os dados brutos não são úteis por si só. Dissemos que os dados
brutos são replicados e armazenados em data lakes.
Para preparar os dados para o uso você usa pipelines "extrair, transformar e carregar", ou ETL
para processar os dados e guardá-los em um armazenamento de dados.
Vamos ver o que você deve considerar na hora de escolher as opções de armazenamento.
Precisamos responder a estas perguntas.
O armazenamento de dados serve como um coletor.
Você armazena dados nele. Mas os dados serão colocados nele por um pipeline de lotes ou de
streaming?
O armazenamento precisa ser atualizado constantemente ou basta carregar os dados nele

uma vez por dia ou por semana?
O armazenamento se escalona de acordo com minhas necessidades?
Muitos armazenamentos de dados baseados em cluster têm um limite de consultas

simultâneas por cluster. Esses limites vão causar problemas? O tamanho do cluster é suficiente
para armazenar e processar os dados?
Como os dados estão organizados? Como eles são catalogados? Como o acesso é controlado?
Você pode conceder acesso aos dados a todas as partes interessadas? E se elas quiserem
consultar os dados? Quem vai pagar pela consulta?
O armazenamento foi projetado para garantir desempenho? Considere o desempenho das
consultas simultâneas e se esse desempenho já pode ser usado ou se você precisa criar índices
e ajustar o armazenamento.
Por último, qual o nível de manutenção que a equipe de engenharia exige?
Os armazenamentos de dados tradicionais são difíceis de gerenciar e operar. Eles foram

criados para o paradigma da análise de dados por lote e para relatórios operacionais. A ideia
era que só alguns gerentes usariam os dados do armazenamento para geração de relatórios. O
BigQuery é uma solução moderna que altera o modo convencional de armazenamento. Veja
algumas diferenças importantes entre um armazenamento de dados tradicional e o BigQuery.
O BigQuery tem mecanismos para transferência de dados automatizada e implementa

aplicativos comerciais usando tecnologias como SQL, que as equipes já conhecem. Assim,
todos têm acesso aos insights de dados.
Você pode criar fontes de dados somente leitura que os usuários internos ou externos podem
consultar além de disponibilizar os resultados de consultas a qualquer pessoa com ferramentas
já conhecidas, como o Planilhas Google o Looker, o Tableau, o Qlik ou o Google Data Studio.
O BigQuery monta a base para a inteligência artificial. É possível treinar modelos do

TensorFlow e do Google AI com conjuntos de dados armazenados no BigQuery e usar o
BigQueryML para criar e treinar modelos de machine learning com SQL.
Outro recurso é o BigQuery GIS que as organizações usam para analisar dados geográficos. Isso
é essencial para muitas decisões comerciais relacionadas a dados de localização.
Com o BigQuery, as organizações analisam eventos comerciais em tempo real com a ingestão
automática de dados e a disponibilização imediata para consultas no armazenamento. Isso
porque o BigQuery pode ingerir centenas de milhares de linhas de dados por segundo, além de
consultar petabytes de dados num piscar de olhos.4:38 e siga a transcrição4:38
Com a infraestrutura sem servidor gerenciada e a rede global do Google o BigQuery elimina o
trabalho de provisionar e manter uma infraestrutura tradicional de armazenamento.
Ele também simplifica as operações com o uso do IAM para controlar o acesso aos recursos,
por meio de papéis, grupos e permissões para execução de jobs e consultas em um projeto. Ele
também faz backup e replicação automáticos.
Falamos sobre colocar os dados no BigQuery por meio de pipelines de ETL mas existe outra
opção. Você pode tratar o BigQuery como um mecanismo de consultas e consultar os dados no
data lake sem movimentação. Por exemplo, use o BigQuery para consultar dados diretamente
no Cloud SQL que é um banco de dados relacional gerenciado, como o PostreSQL o MySQL e o
SQL Server. Você também pode usar o BigQuery para consultar arquivos no Cloud Storage que
estejam em formatos como CSV ou Parquet. A principal vantagem é poder deixar os dados no
lugar e mesclá-los com outros dados no armazenamento. Vamos dar uma olhada.
Demonstração: Consultas federadas com o BigQuery
Nesta demonstração você verá como consultar dados de planilhas no Google Drive usando o
BigQuery. Todas as demonstrações estão no repositório público do curso em "data-
engineering/demos". Vamos fazer adições e provavelmente mudar os nomes deles então
basta consultar esta página para ver todos. Onde encontrar a consulta de dados externos
simples. Veja aqui onde você pode fazer consultas. O BigQuery tem o armazenamento nativo
e as consultas federadas, em que ele consulta dados que não estão nele. De todas estas
fontes. Nesta demonstração, usamos o Google Drive. A primeira coisa a fazer é criar a fonte de
dados. Vamos acessar sheets.new. Pronto, uma planilha nova. A próxima parte é copiar
alguns dados. Pode ser qualquer coisa, contanto que comece na célula A1. Um dos recursos
do Planilhas Google é poder chamar uma API de machine learning. Para isso, escreva em uma
célula =GOOGLETRANSLATE. O texto a ser traduzido. O idioma de partida. É inglês. O idioma de
chegada é o espanhol, este é o código dele. E pronto, você tem uma tradução. Vamos dizer
que o BigQuery é incrível. O tempo está péssimo. Qualquer coisa. Vamos ver os códigos de
outros idiomas. Vamos acessar os códigos. Código de duas letras. Indo-europeu. Vamos usar
caracteres especiais. Para alemão. Não funciona. E chinês? Chinês. Vou olhar na tabela. C-H,
esse é o código. Pronto, feito. Vamos ver como levar esses dados em tempo real para o
BigQuery. Vamos fazer mudanças aqui que vão aparecer lá em tempo real. Copie o URL da
página. Está na área de transferência. Vou voltar ao Google Cloud Platform. Dentro do
BigQuery. Vamos criar um conjunto de dados. Vamos usar o nome "e-commerce". O conjunto
de dados não existe. Vamos criar o conjunto de dados. É um projeto sobre traduções de
produtos ou algo assim. As configurações padrão estão ok. Temos o conjunto. Ele apenas
contém visualizações de tabelas e modelos de ML. Por isso ele está vazio e nada foi retornado.
Vamos criar uma tabela nova. Em vez de uma tabela vazia a fonte será o Drive onde estão os
arquivos do Planilhas Google. Vou colar o URL do meu Drive. Especificamos que é um arquivo
do Planilhas. Não vou usar o intervalo, mas poderia usar apenas alguns dos dados. É uma
tabela externa. É isso que vamos demonstrar. No nome da tabela, vamos usar "translation".
Aqui tem títulos, descrições. Só queremos chegar aos idiomas. Você precisa informar um
esquema. Neste campo do esquema. Sem detecção automática. Nós damos o esquema a você
na demonstração. Role para baixo e pronto. Basta colar aqui. Ou editar com a IU de texto. Em
"Opções avançadas", temos um cabeçalho. Então vamos escrever 1 para ignorá-lo. Crie a
tabela. Agora temos a tabela. Clique na tabela para ver algumas opções gratuitas. Sua tabela
tem um nome de graça. Você recebe a sintaxe de graça. O BigQuery cobra os bytes de dados
processados. Existe o nível gratuito com alguns terabytes por mês de dados processados. Isto
não vai chegar perto do limite. Selecione as colunas. E, para não usar o curinga que é uma
prática ruim acesse o esquema e clique nas colunas. Sempre pode haver mais para a consulta.
Como é uma consulta externa não sabemos quantos dados ela processará porque o
armazenamento não é nativo. Mas, de qualquer forma, vamos executá-la. As consultas
federadas demoram um pouco por causa da autenticação. Pronto. Aqui estão os dados do
Drive. Uma quantidade bem pequena, 477 bytes. Imagine que você queira adicionar vários
outros idiomas. Vamos ver. Coreano, francês. Vamos ver. Não sei os códigos dos idiomas.
Vamos ver o resultado. Você pode testar isto. Russo? RU? Alguns idiomas. O BigQuery
também é compatível com caracteres especiais. A conexão já está configurada. Se você
executar de novo a mesma consulta ela vai mostrar estes dados ou os dados novos? Se você
respondeu "dados novos", acertou. Pronto, aqui está. Uma vantagem. Se alguém mantiver
dados em planilhas… Poderia haver problemas com dados em planilhas devido ao acesso que o
autor concede a outras pessoas mas talvez isso faça parte do seu processo de ETL. Alguém
mantém parâmetros em uma planilha e você os coleta. Você pode fazer isso em tempo real e
criar ou substituir uma tabela aqui. Aspectos negativos das conexões de dados. Como elas não
usam o armazenamento nativo você não tem vantagens do BigQuery como o armazenamento
em cache. Mesmo que os dados sejam iguais, não há cache porque eles são externos. O cache
é um recurso de metadados do armazenamento nativo do BigQuery. Talvez sua consulta seja
um pouco lenta porque ela precisa autenticar a conexão com o Drive. Chegamos ao fim. Teste
com várias mensagens. O código da API Google Translate está disponível lá. Boa sorte e divirta-
se.
Comparação entre bancos de dados transacionais e

armazenamentos de dados
Os engenheiros de dados podem cuidar dos bancos de dados transacionais que os aplicativos
da empresa usam e dos armazenamentos de dados para as análises. Neste módulo, veremos
as diferenças entre bancos de dados e armazenamentos de dados e as soluções do Google
Cloud para cada um.
Quem usa o SQL Server, o MySQL ou o Postgres como banco de dados relacional pode migrar
para o Cloud SQL que é a solução totalmente gerenciada do Google Cloud. O Cloud SQL tem
alto desempenho e escalonabilidade com terabytes de armazenamento dezenas de milhares
de IOPS e 400 ou 500 GB de RAM por instância. Use o escalonamento automático do
armazenamento para lidar com aumentos na demanda sem inatividade.
Talvez as pessoas perguntem a você: por que não usar o Cloud SQL para criação de relatórios?
Você pode usar SQL diretamente no banco de dados, certo? Essa é uma ótima pergunta que
vamos responder no módulo sobre armazenamento de dados. Por enquanto, basta dizer que o
Cloud SQL é otimizado para transações e o BigQuery é otimizado para criação de relatórios,
que são geralmente leituras.
A arquitetura dessas opções é muito diferente. Os bancos de dados do Cloud SQL usam
registros e é preciso abrir o registro inteiro no disco. Mesmo que você selecione apenas uma
coluna. O BigQuery organiza por colunas o que permite esquemas de relatório muito amplos
porque é possível ler apenas algumas colunas no disco.
Isso não significa que os RDBMSs não são tão eficientes quanto armazenamentos de dados.
Eles apenas servem a propósitos diferentes.
Um banco de dados relacional serve para gerenciar transações.
Veja este terminal de venda em uma loja. Cada pedido e cada produto comprado é gravado
como um novo registro em algum banco de dados relacional. Talvez esse banco armazene
todos os pedidos que são feitos no site todos os produtos que estão no catálogo ou o número
de itens no inventário. Assim, quando um pedido é alterado é possível atualizá-lo rapidamente
no banco de dados. Em sistemas transacionais, é possível modificar uma única linha na tabela
de maneira consistente. Eles usam princípios relacionais como integridade referencial, para
evitar situações como um pedido de um produto que não existe na tabela.
Onde esses dados brutos se encaixam na discussão sobre data lakes e armazenamentos? Qual
é a visão geral?
Aqui está. Os sistemas operacionais, como bancos de dados relacionais que armazenam
pedidos on-line, inventários e promoções são as fontes de dados brutos à esquerda. Esta lista
não está completa. Poderia haver outros sistemas como manual, arquivos CSV ou planilhas.
Essas fontes são reunidas em um local consolidado, que chamamos de data lake. O data lake
foi criado para ter durabilidade e alta disponibilidade. Quando os dados chegam ao data lake, é
preciso processá-los por meio de transformações que os enviam a um armazenamento onde
eles ficam prontos para as equipes de análise downstream.
Esses são exemplos de equipes de análise que costumam criar pipelines para extrair dados de
armazenamentos.
Uma equipe de machine learning que quer criar um pipeline para extrair atributos para
modelos. Uma outra equipe de engenharia de dados que usa seus dados no armazenamento
deles.
Uma equipe de inteligência comercial que quer criar painéis com seus dados.
Quem trabalha nessas equipes e qual a relação deles com a equipe de engenharia de dados?
Crie parcerias eficientes com as outras equipes de dados
Já que o armazenamento de dados também atende outras equipes é essencial dar acesso ao
armazenamento sem deixar de cumprir as práticas recomendadas de governança. Quando os
dados estiverem no local de uso e prontos para o uso precisamos agregar valor a eles por
análise e machine learning. Geralmente são outras equipes que fazem isso. Então essas
equipes dependem dos nossos dados. Há muitas equipes que dependem dos seus
armazenamentos de dados e trabalham com as equipes de engenharia de dados para criar e
manter pipelines. Os três clientes mais comuns são engenheiros de machine learning analistas
de dados ou de negócios e outros engenheiros de dados. Vamos ver como esses papéis
interagem com seu armazenamento de dados e como os engenheiros de dados podem
trabalhar com eles. Como você verá no curso sobre machine learning as equipes de machine
learning precisam de muitos dados de alta qualidade para criar, treinar, testar, avaliar e exibir
modelos. Eles trabalham com equipes de engenharia de dados para criar pipelines e conjuntos
de dados para usar com os modelos deles. Aqui estão duas perguntas comuns que você talvez
receba. Quanto tempo demora para que uma transação vá dos dados brutos até o
armazenamento de dados?
O que a equipe de machine learning quer dizer é que eles querem que os dados para
treinamento dos modelos estejam disponíveis também no momento da previsão. Se houver
um grande atraso na coleta e agregação dos dados brutos a equipe de machine learning não
poderá criar modelos úteis.
Outra pergunta que você certamente vai receber é "seria difícil adicionar mais colunas ou mais
linhas de dados em alguns conjuntos de dados?" A equipe de machine learning precisa
identificar relações entre colunas de dados, além de ter muitos dados para treinar modelos.
Para conquistar a confiança dessas equipes faça os conjuntos de dados serem fáceis de
descobrir, documentados e disponíveis para elas fazerem experimentos rapidamente.
No BigQuery, você pode criar modelos de machine learning de alto desempenho diretamente
nele, usando apenas SQL, com o BigQuery ML. Este é o código para criar um modelo avaliá-lo e
fazer previsões. Você vai ver este código novamente nas aulas sobre machine learning.
Outro grupo importante com o qual você vai interagir são as equipes de business intelligence
ou análise de dados. Elas precisam consultar dados de boa qualidade para gerar insights e criar
painéis. Elas precisam de conjuntos de dados com esquemas bem definidos visualização rápida
de linhas e desempenho para escalonar para vários usuários de painéis simultâneos. Um dos
produtos do Google Cloud que gerencia o desempenho dos painéis é o BigQuery BI Engine que
está em beta no momento. O BI Engine é um serviço de análise na memória integrado ao
BigQuery para agilizar aplicativos de business intelligence.
Antes, as equipes de BI precisavam criar, gerenciar e otimizar servidores próprios além de algo
chamado cubos OLAP para usar aplicativos de relatórios. Agora, com o BI Engine, você consulta
conjuntos de dados do BigQuery em menos de um segundo sem criar cubos. O BI Engine usa a
mesma arquitetura de armazenamento e computação do BigQuery, e é um serviço inteligente
de armazenamento em cache na memória com manutenção de estado. Os últimos clientes da
sua equipe são outros engenheiros de dados que dependem da disponibilidade e desempenho
do seu armazenamento e seus pipelines para os data lakes e os armazenamentos deles. Eles
costumam perguntar o que você faz para garantir a disponibilidade dos pipelines de dados de
que eles precisam. Ou eles podem dizer que há demanda alta por alguns conjuntos de dados e
perguntar como você monitora e escalona seu ecossistema para que os dados fiquem
disponíveis quando precisarem.
Uma maneira comum de monitorar o funcionamento do ecossistema é usar o Stackdriver

Monitoring integrado em todos os recursos do Google Cloud Platform. Já que o Cloud Storage
e o BigQuery são recursos você pode configurar alertas e notificações para número de
consultas ou bytes de dados processados e assim acompanhar melhor o desempenho e o custo
do uso.
Outro motivo para usar o Stackdriver é acompanhar o gasto dos recursos usados e ver as
tendências da sua equipe ou organização. Você pode usar o Stackdriver para criar registros de
auditoria do Cloud e ver informações sobre jobs e detalhes granulares sobre as consultas e os
autores delas. Isso é útil principalmente para quem tem conjuntos de dados confidenciais que
precisam de vigilância. Vamos falar desse tópico mais tarde.
Gerencie o acesso e a governança de dados
Para trabalhar com outros grupos sua equipe de engenharia precisa criar políticas de acesso de
dados e regras para determinar como os usuários podem ou não podem usar os dados. Por
isso dizemos que os engenheiros de dados precisam gerenciar os dados. Isso inclui tópicos
essenciais, como privacidade e segurança. O que você deve considerar ao gerenciar alguns
conjuntos de dados? Divulgar claramente um modelo de governança que determina quem
pode e quem não pode acessar os dados.
Como lidar com informações de identificação pessoal Informações PII como números de
telefone e endereços de e-mail. Tarefas ainda mais básicas: como os usuários finais descobrem
os conjuntos de dados disponíveis para análise? Uma solução de governança é o Cloud Data
Catalog e a API Data Loss Prevention. O Data Catalog disponibiliza todos os metadados dos
seus conjuntos de dados para pesquisas dos usuários. Você agrupa os conjuntos de dados com
tags e marca algumas colunas como confidenciais etc. Por que isso é útil? Se você tiver vários
conjuntos de dados com várias tabelas com usuários que têm níveis de acesso diferentes o
Data Catalog tem uma interface unificada para descobrir os conjuntos de dados. Não é preciso
procurar os nomes das tabelas em SQL. A API Data Loss Prevention, ou DLP costuma ser usada
com o Data Catalog. Você a usa para entender e gerenciar dados sigilosos. Ela faz a
classificação e a redução escalonáveis de elementos sigilosos, como números de cartões de
crédito, nomes números do seguro social, algumas identificações internacionais números de
telefone, credenciais do GCP etc. Vamos dar uma olhada nessa API.
Demonstração: Como encontrar PIIs em conjuntos de

dados com a API DLP
Nesta demonstração vamos usar a API Cloud Data Loss Prevention para editar informações de
identificação pessoal (PII) como e-mails e números de telefone na escala adequada. Estas
demonstrações estão na pasta data-engineering/demos no nosso repositório. Esta é bem
curta. Vamos usar a ferramenta da Web. Você pode chamar a API e fazer experimentos nela.
Vamos abrir a demonstração da Web. Vou copiar o link.
Imagine no BigQuery.
Há endereços de e-mail ou algo assim nos dados. Como identificar esses dados proativamente?
A demonstração abre uma página que tem apenas um arquivo de código em texto. O arquivo
contém uma breve explicação sobre a API DLP.
Você pode ter isto. Ele identifica isto. Ele examina estes dados não estruturados. As instruções
dizem: "Estou lendo isto, parece estar em ordem. "Ei, alguém colocou um número de telefone
em um comentário. Não quero divulgar isto. Vou sinalizar que isto tem muita probabilidade de
ser um número de telefone". Aqui está a string e o tipo. Você pode informar ao modelo se o
resultado está correto ou não. Podemos ocultar a mensagem de boas-vindas e colar nossos
próprios exemplos de informações de identificação pessoal e ver se ele os detecta.
Imediatamente. Número de cartão de crédito, muito alto.
Habilitação dos EUA, muito alto. Parte de um endereço de e-mail e o domínio. Esta
demonstração é básica, apenas quatro linhas mas imagine que você recebeu um conjunto de
dados de terabytes. Como identificar, automaticamente e na escala adequada, e usar os
componentes da API para executar funções de hash ou de ofuscação para editar os dados e
evitar o vazamento de PII? Essa é a API DLP.
Crie pipelines prontos para a produção
Após configurar seus data lakes e armazenamentos de dados e elaborar a política de

governança é hora de implementar a produção de toda a operação e automatizar e monitorar
o máximo possível. É isso que queremos dizer com "implementar em produção o processo de
dados". Tem que ser um sistema de processamento completo e escalonável. Sua equipe de
engenharia de dados é responsável pelo funcionamento dos "canos" ou seja, os pipelines, e
por disponibilizar e atualizar os dados para análises e ML.
Veja alguns questionamentos que você deve fazer nesta fase. Como garantir o funcionamento
do pipeline e a limpeza dos dados? Como implementar estes pipelines para minimizar a
manutenção e maximizar o tempo de atividade? Como responder e se adaptar a mudanças em
esquemas e demandas comerciais? Estamos usando as ferramentas e práticas mais atuais de
engenharia de dados?
Uma ferramenta de orquestração de fluxos de trabalho usada por muitas empresas é o Apache
Airflow, e o Google Cloud tem uma versão gerenciada do Apache Airflow, chamada Cloud
Composer. Com o Cloud Composer, sua equipe orquestra todos os elementos de engenharia
de dados que discutimos até agora e mesmo outros que ainda não vimos. Por exemplo, é
possível configurar um evento acionado quando um arquivo CSP é transferido para o Cloud
Storage para iniciar um fluxo de trabalho de processamento e colocar os dados do arquivo
diretamente no armazenamento de dados. Essa ferramenta é útil porque os produtos e
serviços de Big Data do GCP têm endpoints de API para você chamar. Um job do Cloud
Composer pode ser executado a cada noite ou a cada hora e iniciar todo o seu pipeline dos
dados brutos ao data lake e ao armazenamento de dados. Falaremos mais sobre a
orquestração de fluxos de trabalho nos próximos módulos e você também fará um laboratório
sobre o Cloud Composer.
Veja o estudo de caso de um cliente do GCP

Revisão
Vamos resumir os tópicos que vimos até agora nesta introdução.
As fontes de dados à esquerda são os sistemas upstream como RDBMS e outros dados brutos
que chegam da sua empresa em diferentes formatos.
Falamos sobre alguns conceitos, como o data lake. O data lake é um local consolidado para os
dados brutos que é durável e altamente disponível.
Nosso data lake geralmente é o Google Cloud Storage. O segundo conceito é o

armazenamento de dados.
O armazenamento é o resultado final do pré-processamento e da preparação dos dados brutos

no data lake para análise e machine learning.
Há vários outros ícones de produtos do GCP aqui como dados em lote e em streaming no data
lake e a execução de machine learning nos dados. Vamos falar sobre esses tópicos mais
adiante no curso.
Adicione esta página aos favoritos para consulta: produtos do Google Cloud Platform em
quatro palavras ou menos. Nossa equipe de relações com desenvolvedores mantém essa
página no GitHub. É uma ótima maneira de acompanhar o lançamento de produtos e serviços.
Basta seguir as confirmações no GitHub.
Introdução a data lakes
Olá! Sou Evan Jones, desenvolvedor de currículo técnico do Google. Este é o capítulo sobre a
criação de data lakes. Vamos começar explicando o que são data lakes e por que eles são um
componente essencial do ecossistema de engenharia de dados.
O que são data lakes? É um termo muito amplo mas geralmente se trata de um local para
armazenar de forma segura vários tipos de dados de todas as escalas para processamento e
análise. Eles são usados para processar cargas de trabalho de análise de dados de ciência dos
dados e de ML ou pipelines de lote e de streaming. Eles aceitam qualquer tipo de dados.
Os data lakes são portáteis, no local ou na nuvem.

Este é o papel dos data lakes no ecossistema geral da sua equipe. Você começa com um
sistema de origem que é a fonte de todos os dados. Essas são as fontes de dados, e os
engenheiros precisam criar formas de recuperar e armazenar os dados. Esses são os coletores.
A primeira linha de defesa no ambiente de dados corporativo é o data lake. É uma central para
receber os dados em qualquer formato volume e velocidade. Ela aceita e processa tudo.
Vamos apresentar considerações e opções para a criação de data lakes neste módulo.
Depois que os dados saem da fonte e entram no seu ambiente é preciso muita limpeza e
processamento para deixá-los prontos para a empresa usar. Depois eles vão para o
armazenamento de dados que é o assunto do próximo módulo.
Quem faz a limpeza e o processamento dos dados? São os pipelines de dados. Eles são
responsáveis por transformar e processar os dados na escala adequada e disponibilizar novos
dados processados para análise.
Uma outra camada de abstração acima dos pipelines é algo que eu chamo de fluxo de trabalho
completo. Você precisa coordenar o trabalho entre vários componentes com um ritmo regular
ou conforme os eventos. O pipeline processa os dados do data lake para o armazenamento
mas o fluxo de trabalho de orquestração é responsável por iniciar o pipeline ao detectar um
novo arquivo de dados brutos na fonte.
Antes de mostrar os produtos da nuvem para esses papéis quero apresentar uma analogia
para entender esses componentes.
Em vez da engenharia de dados, vamos pensar em termos de engenharia civil. Você é

encarregado de construir um enorme arranha-céus em uma cidade. Antes de começar, você
precisa providenciar todo o material que será necessário para alcançar seu objetivo.
Alguns materiais podem chegar depois, mas vamos simplificar e imaginar que tudo precisa
estar no local para começar. O transporte de aço, concreto, água, madeira, areia, vidro,
qualquer material, de outros pontos da cidade até o canteiro de obras é semelhante aos dados
que chegam ao data lake proveniente das fontes. Agora você tem vários materiais mas ainda
não pode usá-los para construir. Você precisa cortar a madeira e o metal, medir e cortar o
vidro moldar tudo e preparar para a construção. O resultado, o vidro e o metal cortados são os
dados formatados, que depois são guardados no armazenamento de dados. Eles estão prontos
para agregar valor para a empresa que nesta analogia significa construir o prédio.
Como transformar os materiais em peças úteis? Continuando a analogia da construção, essa é

a função do operário. Como você verá depois quando falarmos sobre pipelines de dados. A
unidade do Cloud Dataflow se chama worker ("operário") em inglês que é na verdade uma
máquina virtual. Ele recebe uma pequena quantidade de dados e a transforma. Talvez você
pergunte: "e quanto ao prédio?" Ele representa o objetivo final do projeto de engenharia. Na
engenharia de dados, o novo prédio pode ser um insight de análise que não era possível antes
ou um modelo de machine learning. Ou que você quiser fazer agora que os dados limpos estão
disponíveis. A última parte da analogia é a camada de orquestração.
No canteiro de obras, há um mestre de obras ou supervisor para orientar o trabalho. Essa

pessoa pode dizer: "quando o metal chegar leve-o para tal área do canteiro para corte e
moldagem depois avise à outra equipe que o metal está pronto". Na engenharia de dados,
essa é a camada de orquestração ou o fluxo de trabalho geral. Você pode dizer: sempre que
um arquivo CSV ou algum dado chegar a este bucket do Cloud Storage transfira-o para o
pipeline de dados para processamento depois o pipeline deve fazer streaming dos dados para
o armazenamento. Ainda não terminou: quando os dados estiverem no armazenamento vou
informar ao modelo de machine learning que há novos dados disponíveis para treinamento e
retreinamento. Posso ordenar que ele treine uma nova versão do modelo. Você vê o gráfico de
ações que estamos criando? E se uma etapa falhar ou se você quiser executar isto todo dia a
cada hora ou ao ser acionado por um evento? Você vê a necessidade de um orquestrador, que
na nossa solução será o Apache Airflow em um ambiente do Cloud Composer.
Vamos voltar a um diagrama de arquitetura de solução que você já viu neste curso. O data lake
aqui são intervalos do Cloud Storage no centro do diagrama. É o local consolidado para dados
brutos com durabilidade e alta disponibilidade. Neste exemplo, o data lake é os intervalos do
Cloud Storage mas o Cloud Storage não é a única opção para os dados no GCP.
Ele é uma boa opção para usar como data lake mas não é a única. Em outros exemplos que
vamos ver, o BigQuery é o data lake e o armazenamento de dados, sem usar os intervalos do
Cloud Storage. Por isso, é importante entender o que você quer fazer e depois descobrir quais
são as soluções ideais. Seja qual for a ferramenta e a tecnologia que você usar o data lake
geralmente serve como um local único consolidado para todos os dados brutos. Eu o vejo
como uma área de preparação durável, para coletar dados e depois encaminhá-los. Os dados
podem ser enviados a locais como um pipeline de transformação que os limpa e os move para
o armazenamento. Depois eles são lidos por um modelo de ML. Mas tudo começa com os
dados no data lake.
Agora veremos alguns dos produtos de Big Data do Google Cloud que os engenheiros de dados
precisam conhecer. Você vai usar esses produtos nos laboratórios depois.
Esta é uma lista dos produtos de Big Data e ML, organizados pela posição que ocupam no
processamento de Big Data. Inclui o armazenamento à esquerda, a ingestão nas ferramentas
da nuvem para análise, treinamento de modelos de machine learning e, por último, a exibição
de insights. Neste módulo sobre data lakes, nosso foco será dois dos produtos que formam o
data lake: o Google Cloud Storage e o Cloud SQL, caso você use dados relacionais. Mais adiante
no curso, você usará o Cloud Bigtable também para fazer pipelines de streaming.
Quando eu conheci o Google Cloud Platform, fiquei surpreso ao ver que o BigQuery não está
na coluna de armazenamento. Ele é usado como um armazenamento de dados. Vamos
relembrar: qual é a principal diferença entre data lakes e armazenamentos de dados?
No data lake, você registra todos os aspectos brutos da operação da sua empresa.
Para registrar todos os aspectos, você armazena os dados no formato bruto natural que é
gerado pelos aplicativos. Todos os arquivos de registro e outros arquivos de dados brutos
ficam misturados dentro do data lake. Você pode armazenar qualquer coisa, em qualquer
formato com a flexibilidade que você quiser. Você armazena blobs de objeto ou arquivos. A
flexibilidade dos data lakes como ponto de coleta central é também o problema deles. No data
lake, o formato dos dados é determinado pelo aplicativo que os grava.
E a vantagem é que, quando há upgrade do aplicativo ele pode gravar dados novos
imediatamente porque se trata de uma captura dos dados brutos. Mas como fazer algo útil
para sua empresa com esta grande quantidade de dados brutos flexíveis?
Aí entra o armazenamento de dados.

O armazenamento exige mais atenção que o data lake. Você só poderá carregar os dados nele
quando tiver um esquema bem definido e identificar um caso de uso para que dados ruins não
cheguem a ele. Você pode pegar os dados brutos que estão no data lake transformar,
organizar, processar e limpar os dados e depois guardar o resultado útil no armazenamento.
Por que ter o armazenamento? Talvez porque os dados nele são usados para gerar gráficos
relatórios, painéis e como back-end de modelos de machine learning. Seja qual for o uso esses
dados estão disponíveis para uso no armazenamento.
Como o esquema é consistente e é igual em todos os aplicativos, um cientista ou analista de

dados poderia gerar insights mais rapidamente. O armazenamento contém dados estruturados
e semiestruturados que estão organizados e têm o formato ideal para consultas e análises
imediatas.
Armazenamento de dados e opções de ETL no GCP
Agora vamos discutir o armazenamento e as opções para extrair, transformar e carregar os

dados no Google Cloud Platform. As opções do GCP para criar data lakes são as soluções de
armazenamento que você já viu. O Cloud Storage é uma opção geral, o Cloud SQL e o Cloud
Spanner para dados relacionais, e o Cloud Firestore e o Cloud Bigtbable para NoSQL. Decidir
qual opção usar depende do seu caso de uso e do que você quer criar. O foco deste capítulo é
o Cloud Storage e o Cloud SQL mas você verá as opções NoSQL, como o Cloud Bigtable, mais
adiante quando falarmos de novo sobre o streaming de alta capacidade. Como escolher o
caminho para seu lake?
O destino final dos seus dados na nuvem e os caminhos que eles seguem dependem da
localização atual deles da quantidade (o componente "volume" dos 3 Vs") e do local em que
eles precisam chegar.
Em diagramas de arquitetura, o ponto final dos dados, como já dissemos, é o coletor. Um

coletor comum após um data lake é o armazenamento de dados.
Um aspecto crítico a considerar é a quantidade de processamento e transformação necessária

para que os dados sejam úteis.
É necessário fazer o processamento antes do carregamento no data lake ou depois disso, antes
da transferência para outro lugar? Vamos falar sobre esses padrões, porque há várias
respostas certas. O método que você usará para carregar os dados na nuvem depende da
quantidade de transformações necessárias para colocar os dados brutos no formato final.
Neste capítulo, veremos algumas considerações sobre o formato final dos dados.
O caso mais simples é quando os dados estão em um formato pronto para ingestão pelo
produto de nuvem que você quer usar. Por exemplo, você tem dados no formato Avro e quer
armazená-los no BigQuery porque ele é adequado ao caso de uso. Basta usar o "EL": extrair e
carregar. O BigQuery carrega arquivos Avro diretamente. "EL" é extrair e carregar quando é
possível importar os dados no sistema sem alteração. Por exemplo, importar dados de um
banco de dados que usa o mesmo esquema do destino.
Um dos recursos do BigQuery como você já viu no exemplo de consulta federada é que você
pode consultar dados mesmo sem carregá-los no BigQuery. Arquivos Avro, ORC, Parquet e CSV
são compatíveis com a consulta federada. Também é possível se conectar ao Cloud SQL e
consultar bancos de dados. Como uma conexão de dados externa.
O que é "ELT", ou extrair, carregar e transformar os dados?
É quando os dados carregados no produto de nuvem não estão no formato final que você
quer. Talvez seja preciso limpar transformar de alguma maneira ou até corrigir os dados. Ou
seja, você os extrai do sistema local, carrega no produto da nuvem e depois faz a
transformação. Isso é extrair, carregar e transformar, ou ELT, que você usa quando não precisa
de muitas transformações e elas não reduzirão muito a quantidade de dados.
Com o ELT, você carrega os dados direto no destino e depois os transforma. Um exemplo
comum no BigQuery é usar SQL para transformar dados brutos carregados nele e gravar em
uma tabela nova.
A terceira opção é extrair, transformar e depois carregar, ou ETL. Neste caso, você extrai os
dados aplica processamento neles e os carrega em um produto da nuvem à sua escolha.
Esta opção é indicada quando a transformação é essencial ou reduz muito o tamanho dos
dados. Você transforma os dados antes de carregar na nuvem para reduzir a largura de banda
necessária. Se você tiver dados em um formato binário exclusivo e precisar convertê-los antes
de carregar você usará ETL também. Para resumir: extrair, transformar e carregar, ou seja, ETL,
é um processo de integração de dados em que a transformação é feita em um serviço
intermediário antes do carregamento no destino. Por exemplo, é possível transformar os
dados em um pipeline usando o Cloud Dataflow, como você verá depois antes de carregá-los
no BigQuery.
Como criar um data lake usando o Cloud Storage

O Google Cloud Storage é um serviço essencial para trabalhar com dados especialmente não
estruturados como você verá em machine learning depois. Vamos ver por que o Google Cloud
Storage é tão usado como data lake.
Os dados no Cloud Storage são mantidos após a exclusão das máquinas virtuais ou clusters.
Eles são permanentes e baratos em comparação ao custo da computação. Pode ser mais
vantajoso armazenar os resultados dos processamentos anteriores em cache no Cloud Storage
para arquivamento. Ou, se o aplicativo não precisar ser executado o tempo todo salve o
estado dele no Cloud Storage e encerre a máquina que o está executando, ou quando você
não precisar dela.
O Cloud Storage apenas armazena objetos binários sem considerar os dados que estão neles.
Mas ele oferece compatibilidade de sistema de arquivos e faz com que os objetos funcionem
como arquivos por isso você pode copiar arquivos nele. Os dados armazenados no Cloud
Storage ficam lá para sempre ou seja, são duráveis, mas também instantâneos e com
consistência alta. Ele tem compartilhamento global, mas também é criptografado tem controle
completo e privacidade caso você queira. É um serviço global. Você acessa os dados em
qualquer lugar. Isso significa disponibilidade global. Mas também é possível manter os dados
em um determinado local. Os dados são exibidos com latência moderada e alta capacidade. Os
engenheiros de dados precisam entender como o Cloud Storage consegue esses recursos e
quando usá-los em soluções.
O Cloud Storage tem essas propriedades incríveis por ser um armazenamento de objetos. Os
demais recursos são baseados nisso. As duas principais entidades dele são os buckets e os
objetos.
Os buckets são contêineres para os objetos e os objetos existem nesses buckets, sem
independência. Para nossos fins, os buckets são contêineres de dados. Eles são identificados
por um namespace exclusivo. Quando você dá um nome a um bucket, ninguém mais pode usar
o mesmo nome até o bucket ser excluído. O namespace global ajuda na hora de encontrar
buckets. Quando é criado, o bucket é associado a uma ou várias regiões. Escolha uma região
próxima do processamento para reduzir a latência. Se você processar os dados com serviços de
nuvem daquela região poderá economizar as cobranças de saída de rede. Quando um objeto é
armazenado, o Cloud Storage o replica.
Ele monitora as réplicas e, se alguma for perdida ou corrompida, ele vai substituí-la por uma
cópia nova. É assim que o Cloud Storage consegue vários 9s de durabilidade. Em buckets de
várias regiões, os objetos são replicados entre elas. Em buckets de região única os objetos são
replicados nas zonas da região. Quando o objeto é recuperado, ele é atendido pela réplica
mais próxima do solicitante. É assim que ele consegue baixa latência. Vários solicitantes
podem recuperar objetos ao mesmo tempo em réplicas diferentes. É assim que ele consegue
alta capacidade. Os objetos são armazenados com metadados que são informações sobre eles.
Outros recursos do Cloud Storage usam os metadados para controle de acesso, compactação,
criptografia e gerenciamento do ciclo de vida de objetos e buckets. Por exemplo, o Cloud
Storage sabe quando um objeto foi guardado. Ele pode excluí-lo automaticamente após algum
tempo. Esse recurso usa os metadados para determinar quando excluir o objeto. Ao criar um
bucket, você deve tomar várias decisões. O primeiro é a localização do bucket. Ela é definida
na criação e não pode ser alterada. Se você precisar mover um bucket, deverá copiar o
conteúdo para a nova localização e pagar pela saída de rede. Por isso, escolha com atenção. A
localização pode ser uma única região como europe-north1 ou asia-south1. Pode ser várias
regiões, como UE ou Ásia. Nesse caso, o objeto é replicado em várias regiões na União
Europeia ou Ásia, respectivamente. A terceira opção é o bucket de região dupla. Por exemplo,
em north-america4 o objeto é replicado em us-central1 e em us-east1. Como escolher uma
região? Se todos os seus processamentos e usuários estiverem na Ásia escolha uma região
asiática para reduzir a latência de rede. Mas como escolher entre asia-south1 e a multirregião
da Ásia? Você pode escolher uma região e os dados serão replicados nas zonas dela. Se uma
zona ficar indisponível, você ainda terá acesso aos dados. As zonas diferentes em uma região
criam um isolamento contra falhas da infraestrutura física e de serviços de software. Mas se a
região ficar indisponível, devido a uma enchente, por exemplo você não poderá acessar os
dados regionais. Para ter acesso aos dados durante desastres naturais selecione multirregião
ou região dupla para que as réplicas sejam armazenadas em data centers separados
fisicamente. Leia mais sobre isso nos SLAs on-line. Vou colocar o link deles. Terceiro,
determine qual é a frequência de acesso ou de alteração dos dados. Você conseguirá
descontos no armazenamento se puder pagar mais quando acessar os dados. O desconto faz
sentido para quem acessa os dados uma vez por mês ou por trimestre. Quais são as situações?
Por exemplo, armazenamento de arquivos, backups ou recuperação de desastres. O desconto
realmente vale a pena para quem acessa uma vez por trimestre ou por ano. Essas são classes
de armazenamento. Veja no link os SLAs e os custos de cada classe de armazenamento. O
Cloud Storage usa os nomes dos buckets e os nomes de objetos para simular um sistema de
arquivos. O nome do bucket é o primeiro termo do URI, depois uma barra depois o nome do
objeto. A barra é um caractere válido no nome do objeto. O nome longo do objeto com as
barras parece um caminho de arquivo, embora seja um nome único.
Neste exemplo, o nome do bucket é declass. O nome do objeto é de/modules/O2/script.sh. As

barras são apenas caracteres no nome. Em um sistema de arquivos, esse caminho apareceria
como a estrutura de diretórios à esquerda, começando com declass. O Google Cloud Storage
funciona como um sistema de arquivos mas existem algumas diferenças. Por exemplo, você
quer mover todos os arquivos do diretório 02 para o diretório 03, dentro do diretório modules.
Em um sistema de arquivos com a estrutura de diretórios basta modificar os metadados, então
a movimentação é uma ação única. Mas em um armazenamento que simula um sistema de
arquivos é preciso procurar nomes com "02" na posição certa em todos os objetos contidos no
bucket. Depois é preciso editar cada nome e alterá-los para "03". O resultado é o mesmo da
movimentação dos arquivos entre diretórios. Mas em vez de trabalhar com alguns arquivos em
um diretório o sistema precisou pesquisar milhares de objetos no bucket para achar aqueles
com os nomes certos e alterar cada um deles. Portanto, o desempenho é diferente. Talvez
demore mais para mover alguns objetos do diretório 02 para o diretório 03 dependendo do
número dos demais objetos no bucket.
Durante a movimentação, haverá inconsistência com alguns arquivos no diretório antigo e

outros, no novo.
Recomendamos não colocar informações sigilosas em nomes de buckets, já que eles estão em
um namespace global. Os nomes, não os dados nos buckets. Você pode manter os dados em
sigilo, caso queira.
É possível acessar o Cloud Storage com o método de acesso de arquivos que possibilita, por
exemplo, comandos de cópia do diretório local para o Cloud Storage. Para isso, use a
ferramenta gsutil, o utilitário de armazenamento do Google. Também é possível acessá-lo pela
Web. O site é storage.cloud.google.com. Ele usa TLS ou HTTPS para transferir os dados
protegendo as credenciais e os dados em trânsito.
O Cloud Storage tem vários recursos de gerenciamento de objetos. Você pode definir uma
política para todos os objetos de um bucket que determina a exclusão deles após 30 dias.
Também pode usar o controle de versões para ter várias versões de um objeto, todas
controladas e disponíveis. Você pode configurar o gerenciamento de ciclo de vida. Por
exemplo, mover os objetos sem acesso há 30 dias para o Nearline Storage, ou há 90 dias para
o Coldline Storage, para otimizar custos.
Vamos ver maneiras programáticas de gerenciar os ciclos de vida para otimizar o uso dos
buckets do Cloud Storage e economizar custos.
Como otimizar custos com as classes do Google Cloud

Storage e o Cloud Functions
O GCP tem regras de ciclo de vida de objetos do Storage. Você pode usá-las para mover
objetos automaticamente para outras classes de armazenamento. As regras podem ser
baseadas em atributos como a data de criação ou o estado delas. Mas elas não consideram se
o objeto foi acessado ou não. Uma maneira de controlar os custos é mover os objetos mais
novos para o Nearline Storage caso eles não sejam acessados por algum tempo. Neste
laboratório, você vai criar dois buckets de armazenamento e gerar tráfego para apenas um
deles. Depois você vai criar um painel do Stackdriver Monitoring para ver a utilização do
bucket. Depois, como já fizemos antes você criará uma Função do Cloud para migrar o bucket
ocioso para uma classe menos cara. Para testar, usaremos uma notificação simulada do
Stackdriver que aciona a função. Vamos dar uma olhada.
Uma das estratégias de otimização que você verá aqui é: estou armazenando objetos em um
bucket do Google Cloud Storage, ou GCS. E se eles estiverem em uma classe de
armazenamento como Regional ou Nearline? Ou se houver uma maneira mais eficiente de
armazenar esses ativos dependendo do uso? Como migrá-los de uma classe para outra
automaticamente? Primeiro, quero mostrar a você quais são as classes de armazenamento.
Você vai testá-las no laboratório. Esta é a página do Google Cloud Storage com as classes
disponíveis. Ela mostra as classes de armazenamento disponíveis. Quando você cria um bucket
do GCS, ele usa Standard por padrão. Você não precisa especificar uma classe específica ao
criar, o padrão é Standard. Mas se você não usa os dados com frequência não é um bucket
público que recebe muito tráfego e você quer economizar custos para arquivar dados ou quer
automaticamente usar algo que custa um pouco menos e é acessado com menor frequência.
Aí você pode migrar os dados que estão armazenados em um bucket, do armazenamento
Standard reclassificá-lo para algo como Nearline. Ou talvez o Coldline Storage, caso o conteúdo
seja acessado uma vez por trimestre e não uma vez por dia, para Standard Storage. Agora você
já sabe que os buckets podem ter classes diferentes. Vamos voltar ao laboratório. Neste
laboratório...
...você conhecerá os vários tipos de armazenamento e depois criará buckets com

armazenamentos diferentes. Eu já tinha criado estes buckets. Você usará o mesmo repositório
para onde migrar o armazenamento. Você criará um bucket público. Fará o upload de um
arquivo contendo apenas "isto é um teste".
Depois você criará outro bucket que não contém dados. Esse será o bucket ocioso que não fará
nada. Você tem esses dois buckets. Você criará um espaço de trabalho e um painel do
Stackdriver Monitoring para mostrar o uso desses buckets. Assim como no laboratório anterior
quando monitoramos o uso da CPU neste você vai monitorar o uso do bucket. O Stackdriver é
muito flexível para localizar recursos no GCP e monitorar o uso deles. Algo que adoro fazer é
experimentar com bibliotecas do Apache. Esta é a Apache Bench, para enviar dados simulados
de trânsito àquele arquivo de texto. Vamos fazer isso. Isto é divertido. Vamos ver. Sem discos
permanentes. Quero usar o armazenamento de migração. Vamos acessar o armazenamento
de migração. Aqui está o código Python que gerencia o armazenamento. Vamos tentar gerar o
tráfego. Comando do Bench não encontrado. Você precisa instalar a biblioteca Apache Bench.
Vamos instalar.
Quando ela estiver disponível, enviaremos 10 mil solicitações a um dos buckets públicos. Esta
é a página do Google Cloud Storage. Para chegar aqui, no menu de navegação não em
"Compute", mas em "Storage" acesse "Browser". Já tenho alguns buckets. Os dois que você
criará neste laboratório são o bucket de exibição, que tem o arquivo de texto, está marcado
como público disponível a todos na Internet, e o bucket ocioso que não faz nada. Ele já foi
reclassificado para o Nearline Storage em vez do Standard original. Isso porque eu já executei a
Função do Cloud para testar a demonstração antes da gravação. Agora vamos enviar muito
tráfego. Usamos esse comando e pronto.
"Criando comparativo, tenha paciência." 1.000 solicitações, como 1.000 pessoas acessando
aquele arquivo de texto. 4.000, 5.000, você pode acompanhar a movimentação intensa no
painel do Stackdriver. Mais tarde, você veria que este arquivo específico ou este bucket está
recebendo muito tráfego. Regional Storage é adequado para ele. Mas este outro não tem
nada. Não há acessos nem nada para ser acessado. Vamos migrá-lo do Regional para o
Nearline. A função de Python faz exatamente isso. Você vai criar uma Função do Cloud e
colocá-la dentro do Cloud Scheduler. De volta ao laboratório depois da diversão com o tráfego
artificial uma espécie de autoataque DDoS. Este é o código que durante a migração, fará a
alteração para o Nearline Storage devido ao pouco tráfego. Como nos laboratórios anteriores,
você implementa a função e dá a ela um endpoint HTTP para o Cloud Scheduler chamar.
Depois você configura...
...um recurso de registro para ver o que está sendo implantado no arquivo JSON. Vejamos. Já
chamei a função. Vamos confirmar que ele está no Nearline Storage. Pronto. Ele foi transferido
de uma classe de uso frequente como Regional ou Standard e foi reclassificado para uma
opção mais barata porque você acessa os dados com menor frequência afinal ele não recebeu
10.000 unidades de tráfego. Então ele foi reclassificado para o Nearline. Chegamos ao fim do
laboratório. Boa sorte na sua tentativa e lembre-se de que você pode fazer o Qwiklabs mais de
uma vez. Não se preocupe se o timer terminar e se você não concluiu todos os objetivos. Basta
clicar em "Terminar o laboratório" e recomeçar o laboratório. Boa sorte!
Como proteger o armazenamento na nuvem
Proteger o data lake em execução no Cloud Storage é essencial. Vamos discutir os recursos de
segurança para os engenheiros de dados controlarem o acesso a objetos.
O Cloud Storage usa dois métodos separados porém sobrepostos, para controlar o acesso a
objetos.
O Cloud IAM, a política, e as listas de controle de acesso (ACL). O Cloud IAM é um item padrão
no Google Cloud Platform. Ele é aplicado a um bucket e implementa regras de acesso a todos
os objetos nele.
As listas de controle de acesso podem ser aplicadas a buckets ou a objetos individuais. Elas
oferecem controle mais granular. Os controles do Cloud IAM são intuitivos. Ele cria papéis de
projeto e papéis de bucket que incluem leitor, gravador e proprietário do bucket. Um papel de
bucket do IAM permite criar ou alterar ACLs e um papel de projeto permite criar e excluir
buckets e definir a política do IAM. Também estão disponíveis papéis personalizados. Os
usuários com os papéis de leitor, editor e proprietário de projeto são membros de grupos
internos especiais que lhes dão acesso aos papéis. Veja mais detalhes na documentação on-
line.
Quando cria um bucket você pode desativar as listas de acesso e usar apenas o Cloud IAM. As
listas de acesso são ativadas por padrão. Antes, essa opção era imutável. Mas agora você pode
desativar as listas que estavam em vigor antes.
Por exemplo, há um usuário, nome@email.com bob@exemplo.com, que dá a um leitor acesso

a um bucket pelo IAM. E você deu a essa pessoa acesso de gravação em um arquivo do bucket
por meio de uma lista de controle de acesso. Você pode dar essas permissões a contas de
serviço ou a aplicativos.
Todos os dados no Google Cloud são criptografados em repouso e em trânsito, sendo

impossível desativar isso.
O Google faz a criptografia com chaves que nós gerenciamos chaves de criptografia
gerenciadas pelo Google ou GMEK.
Usamos dois níveis de criptografia. Primeiro criptografamos os dados com uma chave, depois
criptografamos a chave com uma chave de criptografia de chave ou KEK.
As KEKs passam por rodízio regular e usamos a KEK atual armazenada no Cloud KMS serviço de
gerenciamento de chaves. Tudo é automático, sem que você faça nada.
Você pode gerenciar a KEK por conta própria. Em vez do Google, você pode controlar a criação
e a existência da KEK usada. São chaves de criptografia gerenciadas pelo cliente, ou CMEK.
Você pode ignorar o Cloud KMS e usar seu próprio mecanismo de criptografia e rodízio. Isso é
chamado de CSEK. A opção de criptografia usada depende dos seus negócios e de requisitos
legais e regulatórios. Converse com o setor jurídico da sua empresa.
A quarta opção é a criptografia do lado do cliente. Nela você criptografa os dados antes do
upload e precisa descriptografá-los por conta própria antes do uso. O Cloud Storage ainda faz a
criptografia GMEK, CMEK ou CSEK. Ele não detecta a criptografia extra que você adicionou.
O Cloud Storage grava o acesso aos dados em registros imutáveis. Além do Cloud Audit Logs
nos registros de acesso há várias retenções e bloqueios que você pode colocar nos dados. Para
auditoria, você pode aplicar uma retenção a um objeto para suspender operações de alteração
ou exclusão nele até a revogação. Você também pode bloquear um bucket contra alterações
ou exclusões. Também há uma política de retenção, que já mencionamos. Ela continua em
vigor e evita exclusão mesmo que não haja outros bloqueios ou retenções.
O bloqueio de dados é diferente da criptografia. A criptografia impede a compreensão dos

dados enquanto o bloqueio impede a modificação.
O Cloud Storage é compatível com vários outros casos especiais. Por exemplo, codificação de
descompactação. Por padrão os dados armazenados no Cloud Storage não são alterados. Isso
inclui arquivos gzip, que são devolvidos no mesmo formato. Mas por meio de tags de
metadados é possível solicitar a descompactação do arquivo quando ele é exibido. O arquivo
compactado tem upload mais rápido e menor custo de armazenamento.
Você pode fazer com que o solicitante pague por um bucket. Quando alguém de outra região
acessa os dados você precisa pagar pela saída do tráfego da rede. Mas você pode pagar só o
armazenamento e fazer o solicitante pagar o tráfego.
Você pode criar um URL para compartilhar anonimamente um objeto no Cloud Storage. O URL
pode expirar depois de algum tempo.
É possível fazer o upload de um objeto em várias partes e criar um objeto composto sem
concatená-las.
O Google Cloud Storage tem muitos outros recursos úteis, mas vamos seguir em frente.
Como armazenar todo tipo de dados
Como eu já disse o Google Cloud Storage não é a única opção para armazenar dados em um
data lake no Google Cloud. Não recomendamos usar o Cloud Storage para cargas de trabalho
transacionais. Embora a latência dele seja baixa não é baixa o suficiente para um grande
número de gravações. Para cargas de trabalho transacionais use o Cloud SQL se quiser SQL, ou
o Firestore se preferir NoSQL. Não use o Cloud Storage para dados não estruturados de
análise. Se você fizer isso gastará muitos recursos na análise dos dados. É melhor usar o Cloud
Bigtable ou o BigQuery para dados não estruturados de análise dependendo da latência
necessária. Falamos sobre cargas de trabalho transacionais e de análise. O que isso quer dizer?
As cargas de trabalho transacionais exigem inserções e atualizações rápidas de registros. O
objetivo é manter um snapshot com o estado atual do sistema. A desvantagem é que as
consultas são simples e afetam apenas alguns registros. Por exemplo, um sistema bancário.
Depositar seu salário da conta da empresa para sua conta, isso é uma transação. Ela atualiza o
campo de saldo, esperamos que seja para cima. O banco usa processamento de transação on-
line ou OLTP. Já as cargas de trabalho de análise costumam ler todo o conjunto de dados e são
usadas para planejamento e decisões. Talvez os dados venham de um sistema de
processamento de transações mas geralmente eles são originários de vários sistemas OLTPs.
Por exemplo, uma autoridade financeira pode exigir uma notificação sempre que um cliente
do banco transfere mais de US$ 10 mil a uma conta internacional. Ela pode solicitar que o
banco inclua os clientes que tentarem transferir o valor em frações no período de uma
semana.
Para esse relatório, é preciso verificar esse conjunto de dados grande e fazer uma consulta
complexa que agrega valores em janelas móveis em SQL. Esse é um exemplo de carga de
trabalho de processamento de análise on-line, ou OLAP. Nós tratamos esses casos de uso de
formas diferentes porque o foco dos sistemas transacionais é a gravação. Eles são sistemas
operacionais. Por exemplo, é necessário atualizar os dados do catálogo de uma loja sempre
que a loja adicionar um novo item ou mudar os preços. É preciso atualizar os dados de
inventário sempre que a loja vender um dos itens. Isso porque o catálogo nos sistemas de
inventário precisa manter um snapshot dos negócios atuais. Já os sistemas de análise podem
ser preenchidos periodicamente a partir de todo o sistema operacional. Podemos usar isso
uma vez por dia para gerar um relatório com todos os itens no catálogo que tiveram aumento
nas vendas e estão em baixa no estoque.
Esse relatório teria lido muitos dados mas não teria gravado muito. Ou seja, o foco dos
sistemas OLAP é a leitura de dados. Nós dissemos que é possível preencher os sistemas de
análise com os sistemas operacionais. Os engenheiros de dados criam pipelines para
preencher o sistema OLAP com dados do OLTP o sistema de processamento transacional. Uma
forma simples é exportar o banco de dados como um arquivo e carregá-lo no armazenamento
de dados o que chamamos de EL ou extrair e carregar. No Google Cloud, uma opção de
armazenamento de dados muito usada é o BigQuery. O carregamento direto de dados no
BigQuery é limitado. Isso porque a rede pode afetar esse gargalo. Em vez de carregar no
BigQuery talvez seja mais conveniente prepará-los e carregá-los no Cloud Storage, que é um
data lake e depois carregá-los no Google Cloud Storage por meio de um pipeline para o
BigQuery, que é o armazenamento de dados. Isso porque as cargas do Cloud Storage têm
várias linhas de execução e podem ser retomadas. Com o gsutil basta usar a opção "-m" aqui.
O carregamento de dados do Cloud Storage também será muito mais rápido devido à alta
capacidade. Graças a um recurso recente o BigQuery pode consultar arquivos que estão no
Google Cloud Storage diretamente sem precisar carregá-los para o armazenamento nativo.
Isso é uma consulta federada ou uma conexão com fonte de dados externa. Um caso muito
usado é quando você tem arquivos de dados em vários formatos, como CSV Avro (compatível
agora), Parquet ou Apache ORC e os consulta diretamente no BigQuery. Vamos ver uma
demonstração desse processo do GCS ao BigQuery usando uma consulta SQL federada.
Como armazenar dados relacionais na nuvem
Vamos voltar à discussão sobre cargas de trabalho transacionais. Existem algumas opções de
bancos de dados relacionais para armazenar as transações. A escolha padrão é o Cloud SQL
para quem tem dados em MySQL Postgres ou SQL Server. Mas se você precisa de um banco de
dados distribuído globalmente, use o Cloud Spanner. Você precisa disso quando há aplicativos
em várias regiões geográficas atualizando o banco de dados. Por operar em tempo real o
Spanner é ideal para esse caso de uso. Também escolha o Spanner se seu banco de dados for
grande demais para uma instância do Cloud SQL. Para bancos de dados com vários gigabytes
considere um banco de dados distribuído. O escalonamento do Spanner é ideal para esse caso
de uso. Para outros, use o Cloud SQL que tem um custo menor. Para cargas de trabalho de
análise, a escolha padrão no Google Cloud Platform é o BigQuery. Mas se você precisa de
inserções de alta capacidade na escala de milhões de linhas por segundo ou latência ultrabaixa
de alguns milissegundos, considere o Cloud Bigtable. Mais que isso, é melhor usar o BigQuery,
que tem um custo menor.
Cloud SQL como data lake relacional

O Cloud SQL é a escolha padrão para cargas de OLTP, ou processamento de transação on-line,
no Google Cloud. Vamos ver mais detalhes. O Cloud SQL é um banco de dados relacional
totalmente gerenciado e fácil de usar. Com ele, você transfere ao Google as tarefas demoradas
de administração, como aplicar patches e atualizações de software, gerenciar backups e
configurar replicações. Assim, você se dedica a criar ótimos aplicativos, e não a gerenciar. O
Cloud SQL é o serviço gerenciado do Google para RDBMS terceirizado ou sistemas de
gerenciamento de bancos de dados relacionais. Ele é compatível com MySQL, Postgres e
Microsoft SQL Server. Vamos adicionar outros sistemas com o tempo. Isso significa que nós
oferecemos uma instância do Compute Engine que já tem o banco de dados instalado, como
MySQL.
Nós gerenciamos a instância para você. Fazemos backups, atualizações de segurança versões
menores do software. Não se preocupe com isso. Em outras palavras o Google Cloud gerencia
o banco de dados para você tratá-lo como um serviço. Até fazemos tarefas de gerenciamento.
Você pode solicitar um failover de réplica e nós adicionaremos. E você terá um SLA de 99,95 de
disponibilidade.
Outra vantagem das instâncias do Cloud SQL é que outros serviços do GCP podem acessá-las,
como vimos na consulta federada do BigQuery. Eu adoro aquela demonstração. Você também
pode usar o Cloud SQL com o App Engine usando drivers padrão como Connector/J para Java e
MySQLdb para Python. Você pode autorizar instâncias do Compute Engine a acessar o Cloud
SQL colocar a instância do Cloud SQL na mesma zona da sua máquina virtual. O Cloud SQL
também é compatível com outros aplicativos e ferramentas que você já usa, como MySQL,
MySQL Workbench, Toad e outros aplicativos externos usando drivers padrão do MySQL.
Uma das vantagens de o Google gerenciar seu banco de dados é a segurança nível Google. Os
dados de clientes são criptografados nas redes internas do Google e quando armazenados em
arquivos temporários de tabela, nos backups que mencionamos. Toda instância do Cloud SQL
inclui um firewall de rede, para você conceder ou revogar o acesso a ela. O Cloud SQL é fácil de
usar, não exige instalação ou manutenção de software, e o Google gerencia os backups.
Ele guarda seus dados de backup em segurança e facilita a restauração de um backup de

determinado ponto no tempo e a recuperação para um estado da instância. O Cloud SQL
retém até 7 backups de cada instância incluídos automaticamente no custo dela. Para
escaloná-lo verticalmente, basta aumentar o tamanho da máquina. Você pode escalonar para
até 64 núcleos de processador e mais de 100 GB de RAM.
Horizontalmente, você pode escalonar rapidamente réplicas de leitura. O Cloud SQL funciona
com três situações de réplicas de leitura. Na primeira, a instância do Cloud SQL é replicada a
partir de uma instância-mestre. As réplicas são outras instâncias no mesmo projeto e local da
mestre.
Na segunda, a instância do Cloud SQL é replicada de uma mestre externa. Portanto, a

instância-mestre é externa ao Google Cloud SQL. Ela pode estar fora da rede do Google ou em
uma instância do Compute Engine. Use isso para backups de uma instância SQL local. Terceira,
instâncias externas replicadas de uma instância-mestre do Cloud SQL ou réplicas em um
ambiente de hospedagem fora do Cloud SQL.
Se você precisa de escalonamento horizontal de leitura e de gravação, considere usar o Cloud

Spanner. No caso especial de failover o Cloud SQL tem esses recursos. É possível configurar as
instâncias dele com réplica de failover em outra zona da mesma região. Os dados do Cloud SQL
são replicados em zonas da região.
Caso haja queda total de um data center uma instância do Cloud SQL em outra zona ficará
disponível.
Todas as alterações nos dados da mestre serão replicadas no failover. Se a zona das instâncias-
mestres cair o Cloud SQL fará failover para a réplica.
Se a mestre tiver problemas que não a queda, não haverá failover. Você pode iniciar o failover
manualmente para ter essas vantagens. Existem algumas ressalvas. A réplica de failover é
cobrada como uma instância separada.
Quando a zona cai e a mestre faz failover as conexões que estão abertas nessa instância são
fechadas. Mas aplicativos podem se reconectar com a mesma string de conexão ou endereço
IP. Você não precisa alterar seu aplicativo depois do failover.
Após o failover, a réplica se torna a mestre e o Cloud SQL cria outra réplica de failover em
outra zona.
Se sua instância do Cloud SQL estava próxima de outros recursos como uma instância do
Compute Engine, realoque a instância de volta à zona original quando ela ficar on-line. Caso
contrário, não é preciso realocar a instância.
Você pode usar a réplica de failover para transferir operações de leitura da mestre e evitar
gargalos. Veja mais detalhes sobre réplicas de failover na documentação sobre alta
disponibilidade que eu deixarei.
Dizemos que o Cloud SQL é totalmente gerenciado. Também usamos o termo "sem servidor"
em relação ao BigQuery. Qual é a diferença entre totalmente gerenciado e sem servidor?
Totalmente gerenciado significa que você controla o hardware do serviço. Você pode acessar
uma instância do Cloud SQL por SSH, por exemplo. Mas o Google ajuda na administração da
instância com backups automáticos e a criação de instâncias de failover, como mencionamos.
"Sem servidor" é um patamar acima. Você pode tratar esses produtos como uma API a ser
chamada. Você paga pelo uso deles mas não precisa gerenciar os servidores nem se preocupar
com qualquer aspecto dele, apenas receber a resposta. O BigQuery é sem servidor, assim
como o Cloud Pub/Sub para mensagens assíncronas e o Dataflow para processamento paralelo
de dados. Podemos considerar o Cloud Storage como sem servidor também. Apesar de ele
usar discos você não precisa interagir com o hardware.
Uma das vantagens do Google Cloud é que você pode criar um pipeline de processamento de
dados em componentes bem projetados tudo sem servidor. Já o Dataproc é totalmente
gerenciado. Você o usa para gerenciar cargas de trabalho do Spark e do Hadoop sem
configuração. Você ainda pode acessar os servidores caso queira. Entre fazer um novo projeto
no BigQuery ou no Dataflow que são sem servidor, ou no Dataproc, que é totalmente
gerenciado qual você deve escolher? Depende do caso de uso, mas se você pode colocar
facilmente seus dados em qualquer um deles, a melhor opção é o produto sem servidor.
Como carregar os dados de táxi no Cloud SQL
Neste laboratório, você criará um data lake e trará todos os seus dados relacionados de fora
do Cloud para um ambiente no Google Cloud SQL. Primeiro você criará a instância do Google
Cloud SQL que pode conter vários bancos de dados. Quando a instância estiver ativa, você
criará um banco de dados do Cloud SQL e importará alguns dados em texto. Ao final, você
verificará a integridade dos dados. Boa sorte.
Semana 2
O armazenamento de dados moderno
Olá! Este é o módulo sobre armazenamentos de dados. Sou Julie, especialista em análise de
dados do Google Cloud. Este é o terceiro módulo do curso de modernização de data lakes e
armazenamentos de dados com o GCP. Primeiro, vamos descrever o armazenamento de dados
moderno. Também vamos mostrar as diferenças entre data lakes e armazenamentos de dados
empresariais. O armazenamento empresarial deve consolidar dados de várias fontes. Como
você viu no módulo anterior o data lake faz algo semelhante. A diferença entre eles é a palavra
"consolidar". O armazenamento impõe um esquema enquanto o data lake é apenas dados
brutos. Mas o armazenamento empresarial coleta os dados e os disponibiliza para consultas e
processamento. Para usar o armazenamento, os analistas precisam conhecer o esquema. Mas,
ao contrário do data lake, não é preciso criar código para ler e analisar os dados.
Outro motivo para consolidar todos os dados além de padronizar e disponibilizar para
consultas é garantir que os resultados sejam relevantes. Os dados precisam estar limpos,
exatos e consistentes.
O propósito do armazenamento não é guardar dados. Esse é o propósito do data lake. Se você
quiser manter alguns dados, mas não fazer consultas neles deixe-os no data lake sem limpeza
ou simplificação. Todos os dados no armazenamento devem ser consultáveis. É importante
que as consultas sejam rápidas. Ninguém deve esperar horas ou dias pelos resultados.
Descrevemos o armazenamento empresarial e a diferença entre ele e o data lake. O que faz o
armazenamento ser moderno? As empresas precisam de cada vez mais dados. O
armazenamento lida com conjuntos de dados que não cabem na memória. Geralmente, são
gigabytes ou terabytes de dados mas o valor pode chegar à casa de petabytes. Não use um
armazenamento para cada conjunto de dados. Use um só armazenamento com
escalonamento de gigabytes até petabytes.
O armazenamento também precisa usar o modelo sem servidor e ser independente. Você não
deve se preocupar com manutenção de clusters ou criação de índices. Livres desses deveres,
os analistas de dados poderão realizar consultas improvisadas, o que é importante porque o
armazenamento de dados deve agilizar as decisões da empresa.
O armazenamento não será produtivo se ele permitir fazer consultas, mas não tiver
visualização e relatórios avançados. O ideal é que os armazenamentos possam se conectar à
ferramenta de visualização ou relatórios que sua empresa usa. Já que o armazenamento
precisa de dados limpos e consistentes você precisa criar pipelines para levar os dados até ele.
O armazenamento moderno precisa se integrar a um ecossistema de ferramentas para criação
de pipelines de ETL.
Os pipelines de dados precisam atualizar constantemente os dados no armazenamento. Você

precisa fazer o streaming de dados para o armazenamento, e não usar só lotes. A análise
preditiva é cada vez mais importante para a análise de dados. Por isso, o armazenamento
moderno precisa ser compatível com machine learning sem a retirada dos dados.
Por fim, o armazenamento moderno precisa ter recursos de segurança empresarial como
limite à exfiltração de dados. Também deve ter compartilhamento de dados e de consultas
com colaboradores.
Primeiros passos
Agora que você conhece os fundamentos do BigQuery vamos ver como ele organiza os dados.
O BigQuery organiza as tabelas em unidades chamadas de conjuntos de dados. O escopo deles
é o projeto do GCP. Para fazer referência a tabelas na linha de comando e em consultas SQL,
você usa a estrutura project.dataset.table.
Por que estruturar as informações em conjuntos, projetos e tabelas? Com esses escopos, você
estrutura as informações de maneira lógica. Use conjuntos de dados para separar tabelas de
domínios de análise diferentes e use o escopo de projeto para isolar conjuntos de acordo com
suas necessidades.
Como falaremos depois, você pode alinhar projetos ao faturamento e usar conjuntos de dados
para controle de acesso. Você armazena os dados em tabelas com base no esquema lógico. O
faturamento é associado ao projeto. Por exemplo, se você consultar uma tabela que pertence
a um projeto público do BigQuery o custo de armazenamento caberá ao projeto. Para fazer
consultas, você precisa fazer login no Console do GCP. Você faz a consulta no seu projeto do
GCP e as cobranças relacionadas vão para você em vez do projeto público.
Para fazer consultas em um projeto você precisa de permissões do Cloud IAM para enviar jobs.
Fazer uma consulta significa enviar um job de consulta ao serviço.
O controle de acesso é feito pelo Cloud IAM no nível do conjunto de dados, não das tabelas.
Para consultar dados em uma tabela você precisa ter permissão de leitura no conjunto de
dados dela.
Os conjuntos do BigQuery podem ser regionais ou multirregionais. Os conjuntos regionais são

replicados em zonas diferentes da região e multirregião tem replicação em regiões diferentes.
Cada tabela tem um esquema, que você digita no Console do GCP ou transfere na forma de um
arquivo JSON. O armazenamento do BigQuery criptografa os dados em repouso e durante
transmissões com chaves gerenciadas pelo Google. Você também pode usar suas próprias
chaves. A autenticação é feita pelo Cloud IAM, e você pode usar endereços do Gmail ou contas
do G Suite.
O controle de acesso é feito pelos papéis do Cloud IAM e envolve permissões. Discutimos duas
delas, o acesso de leitura e o envio de jobs de consulta. Mas há várias outras permissões. As
permissões funcionam no nível do conjunto de dados. Quando você dá acesso de leitura ou
gravação a um conjunto a pessoa tem acesso a todas as tabelas no conjunto. Os registros do
BigQuery são imutáveis e podem ser exportados no Stackdriver. Atividades de administrador e
eventos do sistema são registros. Um exemplo de evento do sistema é a expiração de tabela.
Se você configurar uma tabela para expirar em 30 dias um evento do sistema será gerado no
registro após 30 dias. Você receberá registros imutáveis quando acessarem um conjunto no
seu projeto.
O BigQuery tem papéis predefinidos para controlar o acesso aos recursos. Você também pode
criar papéis do Cloud IAM definindo um conjunto de permissões, e atribuí-los a usuários ou
grupos. Você pode atribuir um papel a um e-mail do Google ou grupo do G Suite. No
armazenamento de dados, é importante dar acesso controlado aos mesmos dados a diferentes
grupos de usuários. Por exemplo, o financeiro, o RH e o marketing acessam as mesmas tabelas,
mas com níveis diferentes. Para isso, as ferramentas tradicionais usam a segurança no nível da
linha. Para fazer o mesmo no BigQuery, defina visualizações autorizadas e permissões de nível
de linha.
É fácil dar acesso a conjuntos de dados. Era preciso muito tempo de preparação para receber
novos analistas. Para que eles fizessem consultas simples, você precisava mostrar as fontes
configurar conexões de ODBC, ferramentas e direitos de acesso. Com o GCP, os analistas
começam a produzir mais rapidamente. Para receber analistas no GCP, você dá acesso aos
projetos relevantes apresenta a eles o Console do GCP e a IU da Web do BigQuery e mostra
algumas consultas para que eles conheçam os dados. O Console do CGP mostra uma visão
centralizada de todos os ativos no ambiente. O mais importante para analistas de dados são os
buckets do Cloud Storage com os arquivos de trabalho. A IU da Web do BigQuery mostra os
conjuntos de dados que os analistas podem acessar. Os analistas podem fazer tarefas no
Console do GCP de acordo com o papel concedido, como ver metadados visualizar dados e
executar, salvar e compartilhar consultas. Você só controla o acesso a conjuntos. Quando você
dá acesso de leitura a um usuário, ele pode ler todas as tabelas do conjunto. E se você quiser
um controle mais granular? Para isso, use visualizações. Neste exemplo, criamos uma
visualização no conjunto B, e a visualização é um subconjunto dos dados do conjunto A.
Quando dá acesso ao conjunto B aos usuários você cria uma visualização autorizada que é um
subconjunto dos dados originais. Não é possível exportar dados de uma visualização. Os
conjuntos A e B precisam estar na mesma região ou multirregião.
A visualização é uma consulta SQL semelhante a uma tabela. Você pode consultar a
visualização igual a uma tabela. O BigQuery também tem visualizações materializadas. São
visualizações permanentes e você não precisa consultar a tabela sempre que as usar. O
BigQuery mantém a visualização materializada atualizada com o conteúdo da tabela de
origem. Escrevemos as consultas anteriores em SQL e as executamos na IU. Com isso,
enviamos um job ao serviço de consulta do BigQuery.
Os serviços de consulta e de armazenamento do BigQuery são separados mas eles trabalham

em conjunto. Neste caso, consultamos tabelas nativas no projeto de dados público do
BigQuery. A consulta de tabelas nativas é o uso mais comum do BigQuery e tem melhor
desempenho.
O BigQuery é mais eficiente quando usa os dados do próprio serviço de armazenamento. Os

serviços de armazenamento e de consulta trabalham juntos para organizar os dados e fazer
consultas eficientes em terabytes ou petabytes de dados.
O serviço de consulta também pode consultar dados em outros locais como tabelas em
arquivos CSV hospedados no Cloud Storage.
Você pode consultar dados em tabelas ou fontes externas sem carregá-los no BigQuery, algo
chamado de consultas federadas. O serviço de consulta coloca os resultados em uma tabela
temporária e a IU extrai e exibe os dados que estão nessa tabela. Essa tabela temporária é
guardada por 24 horas. Se você refizer uma consulta, e os resultados forem iguais o BigQuery
retornará um ponteiro para os resultados em cache. As consultas feitas com o cache não são
cobradas.
Você também pode pedir que o job grave em uma tabela de destino para você controlar
quando a tabela é excluída. Como a tabela de destino é permanente, haverá cobrança pelo
armazenamento dos resultados. Para calcular o preço, use o validador de consultas do
BigQuery e uma calculadora de preços para ver estimativas.
O validador mostra uma estimativa da quantidade de dados processados na consulta. Use esse
valor na calculadora para ver quanto a execução da consulta vai custar. Isso é válido nos planos
sob demanda, em que você paga por cada consulta pela quantidade de dados processados.
Talvez sua empresa tenha um plano com um preço fixo, então o custo depende da quantidade
de slots que a consulta usa. Você pode separar o custo do armazenamento e das consultas.
Separe os projetos A e B para compartilhar os dados sem dar acesso para execução de jobs.
Neste diagrama, os usuários 1 e 2 têm acesso para executar jobs e acessar os conjuntos de
dados nos projetos deles. Nas consultas deles, o job estará no respectivo projeto. E se o
usuário 2 precisar acessar os dados do projeto A? O proprietário do projeto A pode permitir
que o usuário 2 consulte o conjunto A e as cobranças serão feitas no projeto B. O proprietário
do conjunto público deu acesso a todos os usuários autenticados. A configuração especial
"todos os usuários autenticados" torna o conjunto público. Os usuários autenticados devem
usar o BigQuery nos próprios projetos e têm acesso para executar jobs e consultar o conjunto
de dados público. A fatura da consulta vai para o projeto deles apesar de usar dados públicos
ou compartilhados. O BigQuery oferece 1 TB de consultas gratuito por mês, então os conjuntos
públicos são uma boa maneira de testá-lo. Com o serviço de transferência de dados do
BigQuery, você copia rapidamente grandes conjuntos de dados de outros projetos para o seu.
Vamos falar mais sobre isso na seção sobre carregamento de dados.
Como carregar dados
Agora vamos mostrar como carregar dados no BigQuery. Como vimos em módulos anteriores,
o método de carregamento depende da quantidade de transformações. Use EL, ou extrair e
carregar, para importar os dados sem alteração quando a fonte e o destino têm o mesmo
esquema. Use ELT, ou extrair, carregar e transformar, para carregar dados brutos direto no
destino e transformá-los depois. Use ETL (extrair, transformar, carregar) para fazer a
transformação em um serviço intermediário antes de carregar no destino.
O caso mais simples é EL. Se for possível usar os dados no formato original, basta carregá-los
sem transformação. Você pode carregar dados em lote no BigQuery. Além de CSV, você pode
usar um sinalizador para especificar outros delimitadores além da vírgula. Também é possível
carregar arquivos compactados por gzip mas o carregamento deles é mais lento que o de
arquivos descompactados. Em casos de urgência ou quando há limitações de largura de banda
ou tempo faça testes de carregamento rápidos para ver qual alternativa é melhor. Os jobs de
carregamento são assíncronos, então não é preciso manter uma conexão com o cliente
durante a execução. Os jobs de carregamento não afetam seus outros recursos do BigQuery. O
job criará uma tabela de destino, se ainda não houver. O BigQuery determina o esquema de
dados desta forma. Com dados no formato Avro, o BigQuery determina o esquema
diretamente.
Com o formato JSON ou CSV, o BigQuery detecta o esquema automaticamente, mas

recomendamos a verificação manual.
É possível especificar um esquema como um argumento no job. Os jobs posteriores podem

anexar à mesma tabela com o mesmo procedimento do carregamento inicial, mas não é
preciso passar o esquema em cada job. Se seus arquivos CSV sempre contiverem uma linha
inicial que deve ser ignorada após o carregamento inicial e a criação da tabela use o sinalizador
de linhas de cabeçalho para isso. Veja mais detalhes na documentação dos sinalizadores de
carregamento. O BigQuery limita o número e o tamanho dos jobs de carregamento que você
pode executar por projeto e por tabela. Ele também limita o tamanho de arquivos e registros
carregados. Você pode iniciar jobs na IU da Web do BigQuery, além de automatizar o processo
com o Cloud Functions para detectar eventos do Cloud Storage que indica a chegada de novos
arquivos em um bucket e inicia um job de carregamento. O BigQuery pode importar dados em
formato JSON delimitados pelo caractere de nova linha. Ele também importa arquivos em
Avro, Parquet e ORC. O formato mais comum são arquivos CSV, que ligam o BigQuery a
planilhas. Ele também importa arquivos exportados do Firestore e do Datastore.
Outra maneira de importar dados é pela API. Em tese, em qualquer lugar em que é possível
executar código também é possível inserir dados em tabelas do BigQuery. Use a API em
instâncias do Compute Engine contêineres do Kubernetes, no App Engine ou no Cloud
Functions. Mas você precisa recriar a base de processamento de dados nesses casos. Na
prática, você usa a API no Cloud Dataproc ou no Cloud Dataflow.
O serviço de transferência de dados (DTS) tem conectores e jobs pré-criados que fazem as
transformações necessárias para carregar dados de relatórios de vários serviços no BigQuery.
Você pode transferir arquivos ao Cloud Storage no esquema nativo do armazenamento de
dados local carregá-los em tabelas de preparação no BigQuery e transformá-los no esquema
ideal do BigQuery usando comandos SQL.
É comum automatizar a execução de consultas de acordo com uma programação ou evento e

armazenar os resultados em cache. Você pode programar a execução das consultas
regularmente. É preciso escrever as consultas programadas em SQL padrão, que inclui
instruções na linguagem de definição de dados e na linguagem de manipulação de dados. É
possível parametrizar a string de consulta e a tabela de destino para organizar os resultados
por data e hora. Com um histórico de sete dias de alterações da sua tabela você pode
consultar um instantâneo dos dados em determinado momento. Você pode reverter as
alterações sem recuperar dos backups. Veja como fazer uma consulta SELECT nas tabelas de 24
horas atrás. Como é uma consulta SELECT, você pode fazer mais do que restaurar a tabela.
Você pode mesclar com outras tabelas ou corrigir alguns valores. Também é possível fazer isso
na ferramenta de linha de comando mostrada no segundo snippet. Aqui, restauramos os
dados de 120 segundos atrás.
Só será possível recuperar um arquivo excluído se não tiver sido criada outra tabela com o
mesmo ID no conjunto. Não é possível recuperar uma tabela excluída durante o streaming
nela. Provavelmente o pipeline de streaming já criou uma tabela vazia e começou a enviar
linhas a ela. Cuidado com a instrução CREATE OR REPLACE TABLE que torna a tabela
irrecuperável. O BigQuery é um serviço gerenciado, então você não se preocupa com a
operação a manutenção ou a proteção do sistema. Um armazenamento de dados exige código
para coordenação e interfaces. É possível usar o DTS do BigQuery sem programar. O núcleo do
DTS são transferências programadas de dados em qualquer lugar. No seu data center, em
outros serviços de nuvem você pode colocar todos esses dados no BigQuery.
A transferência é apenas uma etapa da criação de um armazenamento. Ao montar um sistema

próprio, você precisa preparar os dados para limpá-los e melhorar a qualidade. Além de
transformá-los usando ELT, como já falamos processá-los e colocá-los na forma estável final.
Um problema comum em sistemas de armazenamento é o atraso. Por exemplo, uma caixa
fecha mais tarde e não envia o recibo diário durante o período de transferência programado.
Para completar os dados, é preciso detectar a discrepância e solicitar os dados ausentes para
preencher as lacunas. Chamamos isso de preenchimento de dados e é um dos processos
automáticos do DTS do BigQuery.
O preenchimento significa adicionar dados atrasados para fechar lacunas no conjunto e

manter os processos de análise funcionando. Use o DTS para importações repetidas e
programadas de dados de sistemas de software como serviço para tabelas no BigQuery. O DTS
oferece conectores, modelos de transformação e a programação. Os conectores estabelecem
comunicação segura com o serviço de origem e coletam dados exportados em relatórios. Essas
informações são transformadas no BigQuery. As transformações podem ser complicadas,
resultando em 25 a 60 tabelas. A frequência mínima da programação é uma vez por dia.
O DTS do BigQuery automatiza o estado de movimento de aplicativos SAS para fazer consultas
regularmente. Você também pode usá-lo para mover dados entre regiões. Você não precisa de
buckets do Cloud Storage já que o DTS executa jobs que transformam relatórios de fontes SAS
em tabelas e visualizações do BigQuery. O Google oferece vários conectores, como Campaign
Manager, Cloud Storage Amazon S3, Google Ad Manager, Google Ads, Google Play Transfers
canal do YouTube, proprietário de conteúdo do YouTube, migração do Teradata e mais de cem
outros conectores por meio de parceiros.
Se as transformações de dados forem muito simples talvez seja possível fazê-las apenas com
SQL. O BigQuery aceita instruções DML como INSERT, UPDATE, DELETE e MERGE. Mas não o
trate como um sistema OLTP. Evite atualizações e inserções individuais porque há limites no
número de instruções update por dia.
O BigQuery também aceita instruções DDL como CREATE ou REPLACE TABLE. Neste exemplo,
usamos a instrução REPLACE para transformar uma string de gêneros em uma matriz. Vamos
falar sobre matrizes mais adiante.
No BigQuery, é possível consultar alguns dados sem importá-los primeiro para tabelas
internas. Por exemplo, procurar na primeira página de um arquivo do Planilhas Google ou
arquivo CSV ou JSON. Você pode usar uma consulta federada para importar dados de um CSV
no Cloud Storage e transformá-los usando SQL com uma só consulta. Mas a importação dos
dados no BigQuery aumenta o desempenho. Veja como consultar um banco de dados do Cloud
SQL, que é MySQL Postgres ou SQL Server hospedado, direto no BigQuery com sintaxe de
conexões externas e a cláusula FROM.
E se suas transformações fossem além das funções disponíveis no BigQuery? Crie suas próprias
funções. O BigQuery aceita funções definidas pelo usuário, ou UDF. Com uma UDF, você cria
uma função usando outra expressão SQL ou uma linguagem de programação externa. No
momento, é possível usar apenas JavaScript. Mas recomendamos usar SQL padrão, porque o
BigQuery otimiza a execução de SQL muito melhor do que JavaScript.
Com as UDFs, você estende as funções de SQL integradas. Elas recebem uma lista de valores
em matriz ou strut e retornam um único valor, também uma matriz ou um strut. As UDFs
escritas em JavaScript podem incluir recursos externos como bibliotecas de criptografia ou
outras. Antes, as UDFs eram apenas funções temporárias. Só era possível usá-las na mesma
consulta ou sessão de linha de comando. Agora há funções permanentes, scripts e
procedimentos armazenados em beta e talvez estejam disponíveis em geral quando você
estiver vendo este vídeo. Verifique a documentação. Quando você cria uma UDF, o BigQuery a
armazena como um objeto no seu banco de dados. Dessa forma, você pode compartilhar as
UDFs com colegas ou com o público em geral. A equipe do BigQuery tem um repositório de
funções de usuário frequentes neste link do GitHub.
Como otimizar com particionamento e clustering
Agora vamos falar sobre a otimização com particionamento e agrupamento.
Uma maneira de otimizar as tabelas do armazenamento de dados é particioná-las para reduzir

o custo e a quantidade dos dados lidos. Por exemplo, suponha que particionamos esta tabela
pela coluna eventDate. O BigQuery mudará o armazenamento interno para armazenar as
datas em fragmentos separados e particionar a tabela pela coluna de data ou carimbo de
data/hora. Cada partição contém um dia de dados. Ao armazenar, o BigQuery coloca todos os
dados de um bloco na mesma partição. Uma tabela de partição mantém essas propriedades
durante as operações que a modificam. Jobs de consulta, instruções de DML instruções de
DDL, jobs de carregamento ou de cópia. Para isso, o BigQuery precisa manter mais metadados
que uma tabela não particionada. Quando o número de partições aumenta, a quantidade de
metadados também aumenta. Quando você faz uma consulta com uma cláusula WHERE para
ver todas as datas entre 3 e 4 de janeiro o BigQuery precisa ler apenas dois quintos do
conjunto de dados. Isso gera uma enorme economia de tempo e dinheiro.
Você ativa o particionamento na criação da tabela. Este slide mostra como migrar uma tabela
para uma versão particionada no momento da ingestão. Usando uma tabela de destino, isso
custa uma verificação. Quando novos registros forem adicionados à tabela eles serão
colocados na partição certa. O BigQuery cria partições baseadas em data automaticamente,
sem manutenção adicional. Você também pode especificar o período de expiração dos dados
nas partições. É possível configurar o particionamento pela hora da ingestão em uma coluna
de data e hora ou com base em uma faixa de uma coluna de inteiros. Aqui nós particionamos o
ID do cliente e a faixa de 0 a 100 em intervalos de 10. Embora seja preciso manter mais
metadados para garantir o particionamento global dos dados o BigQuery pode estimar melhor
a quantidade de bytes processados pela consulta previamente. O cálculo do custo estabelece
um limite superior ao custo final da consulta. Recomendamos sempre incluir um filtro de
partição nas consultas. Isole o campo de partição no lado esquerdo porque só assim o
BigQuery descarta partições desnecessárias. O agrupamento pode melhorar o desempenho de
alguns tipos de consultas, como aquelas que usam cláusulas de filtro ou agregam dados.
Quando uma consulta ou job de carregamento grava os dados em uma tabela de grupo o
BigQuery classifica os dados pelos valores nas colunas de agrupamento. Esses valores são
usados para organizar os dados em vários blocos no armazenamento do BigQuery. Quando
você faz uma consulta que contém uma cláusula de filtro baseada nas colunas de agrupamento
o BigQuery usa blocos diversos para eliminar as verificações desnecessárias. Quando você faz
uma consulta que agrega dados com base nos valores nas colunas de agrupamento o
desempenho é melhor porque nos blocos classificados as linhas com valores semelhantes
coabitam. Neste exemplo, as tabelas foram particionadas por eventDate e agrupadas por
userID. Como a consulta examina partições em uma faixa específica apenas duas das cinco
partições são consideradas. Como a consulta procura o ID do usuário em um intervalo o
BigQuery pode saltar para a faixa de linhas e ler apenas as linhas das colunas necessárias.
Você configura o agrupamento ao criar a tabela. Aqui criamos o particionamento da tabela por
eventDate e o agrupamento por userID. Também dizemos ao BigQuery para excluir as
partições com mais de três dias. As colunas que você especifica no grupo são usadas para
juntar os dados relacionados. Quando você agrupa uma tabela por várias colunas a ordem
delas é importante. A ordem das colunas especificadas determina a ordem de classificação dos
dados.
Com o tempo, conforme mais operações modificam uma tabela o grau de organização dos
dados começa a enfraquecer, e os dados ficam parcialmente classificados. Com a classificação
parcial talvez as consultas que usam colunas de agrupamento precisem de mais blocos do que
uma tabela totalmente classificada. Para reagrupar os dados em toda a tabela, execute uma
consulta SELECT * que selecione e sobrescreva a tabela. Mas adivinhe? Não é mais preciso
fazer isso. A boa notícia é que o BigQuery agora faz o reagrupamento para você. Seus grupos
não ficarão desatualizados quando os dados aumentarem. O agrupamento automático é
totalmente gratuito e feito em segundo plano. Você não precisa fazer nada para ativá-lo.
Atualmente, o BigQuery permite o agrupamento de uma tabela particionada. É possível
agrupar tabelas particionadas pelo momento da ingestão e tabelas particionadas por coluna de
data ou hora. Atualmente, não é possível agrupar tabelas que não estão particionadas. Com o
agrupamento e o particionamento juntos é possível particionar os dados por uma coluna de
data ou hora e agrupá-los por outro conjunto de colunas. Nesse caso, os dados de cada
partição são agrupados com base nos valores das colunas de agrupamento. O particionamento
é uma maneira de ter melhores estimativas dos custos das consultas e garante melhor custo e
desempenho. O agrupamento traz mais benefícios de custo e desempenho além dos
benefícios do particionamento.
Como criar tabelas particionadas
Esta é uma demonstração do BigQuery. Vamos falar sobre tabelas de partição. Mais
especificamente, uma coluna que é uma tabela particionada por data e como isso resulta em
menos dados ao executar consultas em uma tabela particionada. Precisamos de uma consulta
e um conjunto de dados. Eu tenho uma que faz parte dos insights, dados de comércio
eletrônico dados transacionais para análise da Web. Vou copiar a consulta de demonstração
no repositório público. Todo este código é público. Vou colar no BigQuery.
Eu gosto de visualizar o conjunto de dados que vou consultar antes de fazer a consulta, para
ver como ele é. Esta tabela é o conjunto de dados, dados para insights, todas as sessões.
Vamos ver o tamanho nos detalhes. São 5,6 GB. 21 milhões de linhas. E os dados são
informações transacionais sobre visitas a uma página de comércio eletrônico. É a Google
Merchandise Store. São dados brutos de lá, mas isso não é importante. O que importa é,
rolando para baixo nos detalhes não há informações sobre o particionamento da tabela. Não
há coluna de partição. O que é o particionamento em uma tabela do BigQuery? Esta não é uma
partição de análise. É uma partição real na própria coluna. Você verá quando executarmos a
consulta. Vamos executá-la agora.
Ela está no cache porque eu a executei antes. Para demonstrar o desempenho é melhor
desativar o cache nas configurações. Achei que tinha sido bem rápido.
Veja que ela processou 205 MB apenas para retornar zero resultados. Você talvez ache que há
algo errado no código. Por que ele retorna zero com todos aqueles dados? A melhor resposta
é ver o que a consulta faz. Ela conta o número de IDs de transação e a data da transação da
tabela de comércio eletrônico em que há um ID de transação, ele não é nulo. A parte
importante é que a data é em 2018 ou após esse ano. É interessante. Por que você acha que
este filtro WHERE não retornou resultados? Vamos voltar e visualizar os dados para você ter
uma ideia. Role para baixo e observe alguns dos valores de data que estão armazenados como
inteiros aqui. Vemos 4 de outubro de 2016, 2017.
Na verdade, só há dados de 2016 e 2017. Este é um snapshot do passado não há nada de 2018,
mas normalmente, sem partições nas colunas o banco de dados não sabe que precisa abrir a
coluna e examinar os valores de campo diferentes. É uma quantidade pequena, 205 MB, para
essa consulta processar. Mas não seria melhor? Extrapolando o valor, em vez de 25 GB haveria
25 TB de dados. Não seria melhor executar a consulta mais rapidamente e saber,
automaticamente se há dados para 2018 ou não? É isso que fazemos com uma coluna
particionada por data. A próxima etapa é criar essa tabela, que são algumas linhas de SQL aqui.
A linguagem de definição de dados, DDL, para criar tabelas usando o código. Vou colar a
segunda consulta aqui. Antes da operação de criação, vou fazer uma operação de fundo que
serve para contar todas as transações na data formatada. É a mesma que vimos antes, mas
sem o filtro de cláusula WHERE.
O processo é o mesmo nos dados, 205 MB, e você vê o resultado exato. Há 365 linhas. O que
significa um ano de transações de comércio eletrônico. Pegamos a quantidade total de pessoas
que compram neste site e agregamos pelos dias. São 365 dias individuais. Parece que os dados
são de 2016 a 2017, cobrindo esse período. Normalmente, você salvaria os resultados da
consulta em uma tabela. Salvar os resultados aqui, em uma tabela do BigQuery. Mas vamos
fazer isso em DDL, a linguagem de definição de dados. Eu prefiro criar tabelas em SQL em vez
de pela IU. Se você salvar este controlador de inversão as pessoas saberão que a tabela não foi
criada com mágica de IU. Como armazenar os resultados em uma tabela em vez de exibi-los?
Basta usar CREATE OR REPLACE TABLE. A novidade para quem nunca viu as partições é que a
consulta determina que, quando a tabela for armazenada o usuário do BigQuery vai, em algum
lugar do disco particioná-la por uma coluna específica. No momento, ela precisa ser de um dos
tipos de dados especiais Uma data, como particionar por data um carimbo de data/hora ou
uma faixa de números inteiros. Isso ajuda a otimizar o armazenamento em disco. Esta consulta
cria uma tabela chamada ecommerce.partitions. Quando ela for criada, veremos essa tabela.
Vamos acessar a tabela. E você percebe imediatamente que é uma tabela de partição. Role
para baixo até os detalhes e você verá que há mais informações aqui do que havia antes na
tabela inteira. É uma tabela de partição, particionada por dia.
Informações de dia cada dia classificado como uma partição. Vamos executar a mesma
consulta de antes. Este é o campo formatado por data. Os usuários não precisam filtrar por
uma partição específica, mas se você tiver uma tabela muito grande talvez seja necessário usar
um filtro WHERE. Agora vamos executar a mesma consulta...
...mas desta vez no conjunto de dados particionado. Podemos ver que esta consulta vai
processar zero bytes, nada.
Em vez dos 205 MB, ela já conhece todas as partições antes da execução.
É como os metadados que o armazenamento nativo do BigQuery consegue acessar e nenhum

deles tem um valor após 2017 a 2018. Ela não encontrou nada. Ela diz que não precisou abrir
os dados. Eu sei que não há partições com a data de 2018. Se a data fosse 2017, o conjunto de
dados incluiria uma pequena quantidade. Ela retorna os resultados daquela tabela.
É assim que você cria uma tabela particionada por dados. Você pode usar dias individuais.
Quanto maior for a tabela quanto mais os usuários consultarem e filtrarem com base nos
parâmetros de data, como 10 dias, últimos 30 dias será mais necessário que eles não passem
por cada linha individual quando você pode usar uma partição para agilizar os dados. Em outra
demonstração, vamos ver como expandir as partições com outra opção de desempenho
chamada de agrupamento. Mas, sobre partições, é só isso.
Particionamento e clustering
Esta é uma demonstração do BigQuery sobre a configuração de agrupamentos para melhorar o

desempenho. Vamos encontrar uma boa consulta e um bom conjunto de dados. Esta é nossa
consulta, serão muitos dados. Vamos consultar a Wikipédia. A tabela já está particionada. Vou
colar a consulta no BigQuery para analisá-la. Pressiono a tecla Command no Mac. Veja no
botão de atalhos como acessar o esquema de cada tabela que aparece.
Aqui indica que é uma tabela de partição. O que é isso? Clique nos detalhes para ver a base do
particionamento. Role para baixo, aqui diz particionado por dia. No grande disco rígido da
nuvem, onde o BigQuery gerencia o armazenamento há diferentes dias de dados da Wikipédia
disponíveis. Na demonstração anterior, quando falamos de partições. Por exemplo, se houver
uma data que não existe de fato. Vou filtrar todos os registros da Wikipédia no futuro. Ele
processa zero bytes porque sabe imediatamente, sem abrir os dados e fazer a operação
WHERE para tentar fazer isso… Os dados são posteriores a 2099? Não. E neste campo?
Também não. Temos milhões de registros, ou bilhões neste caso 55 bilhões de registros. É uma
operação que exige muita computação. Com as partições, é possível saber imediatamente que
não há dados em 2099. Mas há dados para 2018. Há muitos dados. São 2,2 TB. Vamos executar
a consulta.
Antes disso, o processo tem 2,2 TB. A próxima parte da demonstração mostra as vantagens do
particionamento. Altere a data para sete meses no futuro e quando você executar isso ou
adicionar aqui ele vai ignorar várias partições e reduzir a quantidade processada pela metade.
Se a tabela não estiver particionada a consulta não saberá quais são os campos de dados. Ela
terá que analisar todos eles. Essa é vantagem das partições. Mas agora queremos mostrar o
agrupamento. Vamos ver quanto esta consulta demora para analisar 1,1 TB.
Este é o título da página da Wikipédia, o total de visualizações. Esta é a versão 2 da tabela

particionada apenas após 1 de julho de 2018 na Wikipédia móvel em inglês, e o título contém
"Google". O maior número de visualizações é Google, Chrome, Maps Google Tradutor e
também no meio disso tudo God of War, o videogame que tem "GOOG" no título. GOOG. Que
interessante o regex. A consulta processou 1,1 TB e demorou 12 segundos.
Existe uma terceira versão desta tabela que um dos gurus do Google criou para esta
demonstração. Lembre-se dos 12 ou 13 segundos, e 1,1 TB. Esta é uma tabela de partição. Mas
se você rolar para baixo até o fim, também verá clusters. Os dados compartilham o mesmo
local com base no título da Wikipédia e o título da página, o que é interessante. Vamos ver a
diferença entre consultar uma tabela particionada apenas particionada, e uma agrupada com
base no Wiki e no título. Por que isso mudaria? A hipótese é que as partições naturalmente
ajudam na filtragem dos dados. Para os clusters, você quer apenas inglês e inglês móvel que é
o "en.m", e jogar fora o resto. E você quer coisas com títulos semelhantes alfabeticamente. Os
clusters são como índices de RDBMSs, mas com algumas diferenças na prática. Vamos executar
a consulta e observar. Aqui diz 1,1 TB para processar. Queremos superar os 13 segundos. Mas,
na verdade, é muito interessante como isto funciona. O processador de consultas no momento
em que gravo não leva em conta os dados agrupados. Ele processou, na verdade...
414 GB. Ele ia processar 1,1 TB mas conseguiu uma economia enorme de 50% a 60% em bytes
graças ao particionamento dos dados. O tempo foi igual, mas com muito menos dados, pois
muitos estavam no mesmo local. Como os títulos e os bytes da Wikipédia em inglês e inglês
móvel. É importante observar que há muitas ressalvas no agrupamento. Uma vantagem é que
há reagrupamento automático dos dados. Se você quiser saber o que acontecerá se você
adicionar mais registros. Não é preciso recriar a tabela. Desde alguns meses atrás, em 2019 o
BigQuery tem um serviço que reagrupa automaticamente os dados quando novos dados
chegam. Mas, ao criar clusters, você precisa considerar que assim como no particionamento
criar e substituir uma tabela e especificar um cluster é que a ordem dos clusters é importante.
Fizemos esta demonstração para mostrar os clusters bem feitos. Mas isso é porque nós
filtramos primeiro por inglês e inglês móvel no Wiki. A ordem do agrupamento é importante e
eles estão agrupados primeiramente pela página da Wikipédia, inglês e inglês móvel E, dentro
desse cluster, se a página contém GOOG no título. Se você invertesse isso ou tivesse um e não
o outro seu desempenho mudaria drasticamente. Não seria pior do que sem o cluster.
Considere o que os usuários usam com mais frequência para decidir a configuração dos
clusters.
Como transformar dados em lote e em streaming
Na próxima seção, vamos falar sobre a transformação de dados. E se os dados que chegam não
forem úteis na forma bruta? Vamos ver o que fazer no curso sobre processamento de dados.
Há alguns anos, era fácil colocar o esquema em um diagrama. Com os avanços da tecnologia e
do mercado desde então é difícil colocar tudo em um só diagrama. Este esquema não é
consistente nem completo mas dá uma ideia do funcionamento geral. Aqui estão os sete
serviços, as árvores da floresta, que ajudam a encontrar os caminhos pela nuvem para a
engenharia de dados.
O Cloud Pub/Sub envia dados de streaming ao Cloud Dataflow. O Dataflow armazena e

transforma os dados no BigQuery ou no Bigtable.
O Cloud Storage armazena dados em lote e os envia ao Dataproc ou ao Dataflow.
Essas são as soluções de processamento de dados. Depois, você adiciona os serviços de

inteligência artificial e as interfaces de usuário e de negócios.
O Google Cloud tem ferramentas para processar dados em streaming infinitos. Elas são
Pub/Sub, Dataflow e Bigtable, que veremos no próximo curso. Você pode fazer streaming de
dados no BigQuery ou processá-los primeiro no Dataflow. Os streams são ilimitados, sem fim
definido. Isso representa um desafio para algoritmos que acionam uma ação ao final dos
dados. Continuamos a discussão no curso sobre processamento de dados de streaming. O
streaming não é um job de carregamento. É um método do BigQuery separado, chamado
inserções de streaming. O método insere um item por vez em uma tabela. É possível criar
tabelas com um modelo que identifica o esquema.
Os dados ficam disponíveis em segundos. Eles entram em um buffer de streaming até ser
possível inseri-los na tabela. No streaming, considere a disponibilidade e a consistência dos
dados. Candidatos ao streaming são análises ou aplicativos que toleram a ausência de dados,
ou dados fora da ordem ou duplicados. O stream talvez passe por outros serviços, o que
aumenta a latência e a possibilidade de erros. Como os dados de streaming são ilimitados, é
preciso considerar as cotas. Existe um limite diário e um limite de taxa simultânea. Veja mais
informações sobre eles na documentação on-line.
Quando você deve fazer a ingestão de dados em streaming em vez de usar lotes? Quando a
solução exige dados disponíveis imediatamente. No geral, não há cobrança pelo carregamento
de dados em lote mas há cobrança pelo streaming. Use lote ou lote repetido a menos que o
aplicativo exija o contrário.
Revisão
Vamos resumir o que aprendemos. Neste módulo, falamos sobre os requisitos de um

armazenamento de dados moderno.
Apresentamos o BigQuery a solução de armazenamento escalonável do Google Cloud

Platform. Não é preciso provisionar recursos para usar o BigQuery ao contrário de muitos
outros RDBMSs. Ele aloca o armazenamento e os recursos de consulta com base nos seus
padrões de uso.
Explicamos como carregar dados brutos em um data lake que você pode preparar em um
bucket do Cloud Storage antes de processá-los no armazenamento de dados para análise.
Falamos sobre o serviço de transferência de dados do BigQuery para criar e gerenciar

armazenamentos. Com o serviço, você pode programar consultas, transferências etc. Vimos
alguns conceitos do BigQuery como a organização dos dados no conjunto do projeto e na
tabela.
Toda tabela tem um esquema que você digita ou informa por meio de um arquivo JSON. Os
esquemas também podem ter tipos de dados de matriz que os torna repetidos, ou de struct,
que os torna aninhados. Essa desnormalização melhora o desempenho, porque evita
mesclagens intensas. Por último, mostramos como configurar particionamento e agrupamento
de tabelas para reduzir os dados verificados e agilizar as consultas. Chegamos ao fim do curso.
No próximo curso, vamos tratar de processamento em lote e em streaming e você criará
pipelines para seus novos conjuntos no BigQuery.
Resumo do curso
Vamos revisar os conceitos que vimos no curso sobre data lakes e armazenamentos de dados.
O papel principal dos engenheiros de dados é criar pipelines. O pipeline serve para que as
pessoas na empresa usem os dados para tomar decisões melhores e mais rápidas. O papel dos
engenheiros de dados não é novo mas poder criar pipelines inteiramente na nuvem é uma
novidade. Nós dizemos que fazer engenharia de dados na nuvem é vantajoso porque você
pode separar a computação do armazenamento e não precisa gerenciar a infraestrutura ou o
software. Assim você dedica mais tempo ao que importa: gerar insights usando dados.
Apresentamos os data lakes e os armazenamentos de dados e as diferenças entre eles. Em alto
nível, o data lake serve para armazenar dados não processados. O armazenamento serve para
armazenar os dados transformados que você usará depois para análise machine learning e
painéis. Depois mostramos os detalhes técnicos do Cloud Storage como a solução de data lake
do GCP. Também apresentamos outras soluções do GCP para baixa latência cargas de trabalho
transacionais e dados estruturados. Por último, apresentamos o BigQuery como a solução de
armazenamento de dados do Google Cloud. Falamos sobre o particionamento e a divisão em
clusters no BigQuery para melhorar o desempenho. Também falamos sobre EL, ELT e ETL, e a
relação deles com os data lakes e os armazenamentos de dados. E apresentamos uma
arquitetura de referência no GCP para pipelines de dados em streaming e em lote. Esperamos
que você use essas arquiteturas como ponto de partida para seus pipelines de dados.

Data Lakes Com Google Cloud Platform

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Data Lakes Com Google Cloud Platform

Enviado por

Direitos autorais:

Formatos disponíveis

Modernizando Data Lakes e Data Warehouses com GCP

Principal função do engenheiro de dados é a criação de pipelines

Conheça o papel do engenheiro de dados

Mas por quê? Por que os engenheiros de dados criam pipelines?

Depois, é possível carregá-los ou consultá-los no BigQuery que é um armazenamento de

Quickly create buckets with cloud shell

Analise os desafios da engenharia de dados

O que dificulta o acesso aos dados?

A própria disponibilidade dos recursos computacionais pode ser um desafio.

Por quê? Em um sistema local os engenheiros de dados precisam gerenciar a capacidade de

Trata-se de um armazenamento de dados sem servidor. O BigQuery é o armazenamento de

Data lakes e armazenamentos de dados

Precisamos responder a estas perguntas.

O armazenamento de dados serve como um coletor.

O armazenamento precisa ser atualizado constantemente ou basta carregar os dados nele

O armazenamento se escalona de acordo com minhas necessidades?

Muitos armazenamentos de dados baseados em cluster têm um limite de consultas

Por último, qual o nível de manutenção que a equipe de engenharia exige?

Os armazenamentos de dados tradicionais são difíceis de gerenciar e operar. Eles foram

O BigQuery tem mecanismos para transferência de dados automatizada e implementa

O BigQuery monta a base para a inteligência artificial. É possível treinar modelos do

Demonstração: Consultas federadas com o BigQuery

Comparação entre bancos de dados transacionais e

Eles apenas servem a propósitos diferentes.

Um banco de dados relacional serve para gerenciar transações.

Crie parcerias eficientes com as outras equipes de dados

Uma maneira comum de monitorar o funcionamento do ecossistema é usar o Stackdriver

Gerencie o acesso e a governança de dados

Demonstração: Como encontrar PIIs em conjuntos de

Imediatamente. Número de cartão de crédito, muito alto.

Crie pipelines prontos para a produção

Após configurar seus data lakes e armazenamentos de dados e elaborar a política de

Veja o estudo de caso de um cliente do GCP

Vamos resumir os tópicos que vimos até agora nesta introdução.

Nosso data lake geralmente é o Google Cloud Storage. O segundo conceito é o

O armazenamento é o resultado final do pré-processamento e da preparação dos dados brutos

Introdução a data lakes

Os data lakes são portáteis, no local ou na nuvem.

Em vez da engenharia de dados, vamos pensar em termos de engenharia civil. Você é

Como transformar os materiais em peças úteis? Continuando a analogia da construção, essa é

No canteiro de obras, há um mestre de obras ou supervisor para orientar o trabalho. Essa

Aí entra o armazenamento de dados.

Como o esquema é consistente e é igual em todos os aplicativos, um cientista ou analista de

Armazenamento de dados e opções de ETL no GCP

Agora vamos discutir o armazenamento e as opções para extrair, transformar e carregar os

Em diagramas de arquitetura, o ponto final dos dados, como já dissemos, é o coletor. Um

Um aspecto crítico a considerar é a quantidade de processamento e transformação necessária

O que é "ELT", ou extrair, carregar e transformar os dados?

Como criar um data lake usando o Cloud Storage

Neste exemplo, o nome do bucket é declass. O nome do objeto é de/modules/O2/script.sh. As

Durante a movimentação, haverá inconsistência com alguns arquivos no diretório antigo e

Como otimizar custos com as classes do Google Cloud

...você conhecerá os vários tipos de armazenamento e depois criará buckets com

Como proteger o armazenamento na nuvem

Por exemplo, há um usuário, nome@email.com bob@exemplo.com, que dá a um leitor acesso

Todos os dados no Google Cloud são criptografados em repouso e em trânsito, sendo

O bloqueio de dados é diferente da criptografia. A criptografia impede a compreensão dos

Como armazenar dados relacionais na nuvem

Cloud SQL como data lake relacional

Ele guarda seus dados de backup em segurança e facilita a restauração de um backup de

Na segunda, a instância do Cloud SQL é replicada de uma mestre externa. Portanto, a

Se você precisa de escalonamento horizontal de leitura e de gravação, considere usar o Cloud

Como carregar os dados de táxi no Cloud SQL

Os pipelines de dados precisam atualizar constantemente os dados no armazenamento. Você