Nesse post quero trazer uma visão geral do Kubernetes, sua história, e como sua arquitetura é composta. Mas o que é o Kubernetes?

Ele é uma plataforma opensource portável, extensível focado em gerenciar serviços containerizados, desenvolvida pela Google em 2014 e lançada publicamente em 2015. Essa plataforma atua de forma que ele ajuda a preparar e gerenciar clusters, e também nos contâiners Docker e portanto atua na sua orquestração e isso é possível através da automação por meio de configurações declarativas via arquivos YAML. Com isso ela oferece uma alta disponibilidade, escalabilidade e resiliência em ambientes de produção.

Como ela surgiu?

O surgiu a partir de uma tecnologia de orquestração de contêineres interna chamada Borg. A Google começou a trabalhar nessa ferramenta em 2003 para gerenciar seus próprios serviços internos em contêineres. Ele foi projetado para lidar com a escalabilidade e a alta disponibilidade de serviços, além de oferecer um ambiente de desenvolvimento mais fácil e ágil.

Em 2014, a Google decidiu disponibilizar o que conhecemos como Kubernetes hoje, mas como um projeto de código aberto, o que permitiu que outras empresas e desenvolvedores utilizassem a tecnologia. O projeto rapidamente se tornou popular, atraindo uma comunidade de desenvolvedores e contribuidores em todo o mundo. Em 2015, a Kubernetes foi doada para a Cloud Native Computing Foundation (CNCF), uma organização de código aberto que ajuda a gerenciar e promover tecnologias nativas de nuvem.

Desde então, ela tornou-se uma das tecnologias mais populares no espaço de contêineres, sendo amplamente adotada por empresas de todos os tamanhos em todo o mundo.

Como era antes?

Antes do Kubernetes, os deploys eram geralmente feitos de forma manual, o que exigia muito esforço. Os desenvolvedores precisavam configurar manualmente cada servidor e instalar todas as dependências e bibliotecas necessárias. Isso exigia muitos scripts de automação personalizados e era um processo propenso a erros humanos.

Olhando em uma perspectiva maior, a imagem mostra como tem sido a evolução da infraestrutura em que as nossas aplicações eram implantados:

• Deploy tradicional: Nesse momento era feito o deploy em máquinas físicas, e com isso um ou mais aplicações utilizam o mesmo recurso. O problema disso é que uma determinada aplicação poderia utilizar recursos o suficiente para deixar quaisquer outras subutilizadas a nível de performance. Então para resolver isso era separando sua implantação em máquinas físicas diferentes, tornando seu gerenciamento e manutenção custosos e caros.

• Deploy virtualizado: Como solução, a virtualização foi introduzido, em que temos um ou mais servidores que atuam como hypervisor e assim eles hospedam ou mais máquinas virtuais. Dessa forma as aplicações estão isoladas a nível desta virtualização, cada um com seus recursos delimitados desde o início. Outra vantagem é que a escalabilidade vertical aqui nesse ambiente é instântanea porque não é acoplada com o físico totalmente, mas claro ainda é limitado.

• Deploy via contâiner: Contâiners são similares aos VMs, mas eles possuem um isolamento menos estrito, de forma que compartilham do mesmo Sistema Operacional. Dessa forma, além de serem leves por isso como VMs eles possuem o seu próprio filesystem, compartilhamento de CPU, memória, process space, e muito mais. Como eles são mais desacoplados da infraestrutura, eles são muito mais portáveis entre clouds e outros sistemas operacionais.

O gerenciamento de aplicativos também era um desafio. À medida que o número de servidores aumentava, era difícil garantir que cada servidor estivesse executando as mesmas versões de software e bibliotecas. Também era difícil escalar aplicativos para atender às necessidades de tráfego crescente. Para lidar com esses problemas, surgiram ferramentas como Ansible, Chef e Puppet, que automatizavam a configuração do servidor e gerenciavam as dependências do aplicativo.

No entanto, essas ferramentas não eram específicas para contêineres, o que significava que os desenvolvedores ainda precisavam gerenciar manualmente as implantações e escalas dos contêineres. Isso levou ao desenvolvimento de ferramentas de orquestração de contêineres, como o Rancher, Docker Swarm e o Apache Mesos. No entanto, essas ferramentas tinham suas próprias limitações. Por exemplo, o Docker Swarm não tinha recursos avançados de escalabilidade e gerenciamento de aplicativos, enquanto o Apache Mesos era mais complexo de configurar e gerenciar.

Foi nesse contexto que o Kubernetes foi desenvolvido, para preencher essa lacuna e oferecer uma plataforma de orquestração de contêineres de ponta a ponta.

Como é sua arquitetura?

Ele tem uma arquitetura altamente modular e escalável, que consiste em vários componentes que trabalham juntos para fornecer recursos de orquestração de contêineres. Esses componentes incluem o seguinte:

Cluster

O cluster é a estrutura básica do Kubernetes, que consiste em um ou mais nós (ou servidores) em um grupo. Cada nó executa um agente de Kubernetes (kubelet) para gerenciar os contêineres e outros recursos. O cluster é gerenciado pelo componente de controle do Kubernetes.

Componente de controle

O componente de controle do Kubernetes é responsável por gerenciar o estado do cluster. Ele é composto por vários componentes, incluindo:

• kube-apiserver: é um componente que expõem um API Kubernetes e que serve de frontend para o control pane, ou seja, é aqui que vai receber os comandos do “mundo externo” através do programa kubectl de maneira declarativa ou imperativa

• etcd: atua como storage de chave e valor para o Kubernetes, armazenando dados relativos aos clusters

• kube-scheduler: componente que observa por novas criações de pods que não possuem atribuição e nenhum node e seleciona um mais adequado para ser hospedado e executado

• kube-controller-manager: é um componente que execute processos controladores, o que basicamente são processos que rodam em loop para regular o estado do sistema. No control pane temos alguns tipos como Node Controller, Job Controller, entre outros.

• cloud-controller-manager: esse componente incorpora a lógica de controle do seu cluster com as APIs dos provedores da nuvem, separando as partes do cluster as particularidades dos fornecedores. Aqui ele executa controladores específicos do fornecedor que implantou seu ambiente. Dessa forma, caso esteja utilizando um cluster em sua própria infraestrutura ou está utilizando para fins de estudo, você não utiliza esse componente.

Nós

Componentes dos nós executam em cada uma delas, mantendo a execução dos contêineres e provendo o ambiente de execução para o Kubernetes.

Cada um desses componentes abaixo rodam em cada nó do cluster, fazendo parte do conceito de Kubernetes Service.

• kubelet: ele tem o objetivo de manter o conjunto de pods; registrar o nó ao cluster, enviando eventos e status relacionados além de reportar utilização de recursos. Também ele recebe um conjunto de PodSpecs por meio do API Kubernetes para garantir que os pods estarão executando conforme esperado e com estabilidade.

• kube-proxy: ele gerencia e mantêm as regras de rede do nó do cluster. É com essas regras que que autoriza a comunicação dos pods dentro ou fora do seu cluster.

Pods

Os pods são a unidade básica de implantação no Kubernetes, que consiste em um ou mais contêineres que compartilham o mesmo espaço de rede e armazenamento. Os pods são agendados em nós pelos componentes de controle e são gerenciados pelo kubelet em cada nó.

Serviços

Os serviços fornecem uma maneira de expor um conjunto de pods como um serviço de rede. Eles são responsáveis por encaminhar o tráfego para os pods correspondentes, permitindo que os aplicativos sejam escalonados e mantidos sem interrupções.

Volumes

Os volumes fornecem uma maneira de armazenar dados persistentes em contêineres. Os volumes podem ser compartilhados entre vários contêineres em um pod e podem ser gerenciados pelo Kubernetes para garantir que os dados persistam durante as atualizações e falhas.

Uma ferramenta cada vez mais essencial nas soluções

O Kubernetes é uma ferramenta poderosa e flexível gerenciarmos e mantermos nossas aplicações rodando. Com sua arquitetura altamente modular e escalável, ele permite que os desenvolvedores gerenciem e orquestrem facilmente suas aplicações em contêineres, independentemente da infraestrutura subjacente. Hoje faz parte da rotina de todo desenvolvedor trabalhar com essa infraestrutura, de forma direta ou não, seja onpremise ou no cloud. Caso não conheça, acesse a documentação para saber mais.

Até mais!

Cláusula SELECT

Ele é usada para selecionar dados de uma tabela. É possível selecionar colunas específicas, filtrar dados com base em condições e aplicar funções de agregação a valores numéricos.

Exemplo de consulta SQL utilizando a cláusula SELECT:

SELECT customer_id, SUM(price) as total_price
FROM orders
WHERE order_date >= '2022-01-01'
GROUP BY customer_id;

Nessa consulta, a cláusula SELECT seleciona o ID do cliente e o total de gastos em pedidos de cada cliente desde o início de 2022. A cláusula GROUP BY é usada para agrupar os dados por ID do cliente, permitindo calcular o total de gastos de cada cliente.

Cláusula INSERT

A cláusula INSERT é usada para inserir novas linhas em uma tabela. É possível inserir dados em uma única linha ou em várias linhas em uma única consulta.

Exemplo simples de uma consulta SQL utilizando a cláusula INSERT:

INSERT INTO customers (id, name, email)
VALUES (123, 'João Silva', 'joao.silva@email.com');

Além disso, podemos utilizar o INSERT com outras cláusulas.

Usando valores explícitos

INSERT dataset.Inventory (product, quantity)
VALUES  ('top load washer', 10),
                ('front load washer', 20),
                ('dryer', 30),
                ('refrigerator', 10),
                ('microwave', 20),
                ('dishwasher', 30),
                ('oven', 5)

INSERT dataset.NewArrivals (product, quantity, warehouse)
VALUES ('top load washer', 100, 'warehouse #1'),
             ('dryer', 200, 'warehouse #2'),
             ('oven', 300, 'warehouse #3')

Utilizando instrução INSERT SELECT

INSERT dataset.Warehouse (warehouse, state)
SELECT *
FROM UNNEST([('warehouse #1', 'WA'),
                         ('warehouse #2', 'CA'),
                         ('warehouse #3', 'WA')])

Utilizando instrução WITH como alternativa ao INSERT SELECT

INSERT dataset.Warehouse (warehouse, state)
WITH w AS (
    SELECT ARRAY<STRUCT<warehouse string, state string>>
    [('warehouse #1', 'WA'),
     ('warehouse #2', 'CA'),
     ('warehouse #3', 'WA')] col
)
SELECT warehouse, state FROM w, UNNEST(w.col)

Copiando conteúdo de uma tabela para outra

INSERT dataset.DetailedInventory (product, quantity, supply_constrained)
SELECT product, quantity, false
FROM dataset.Inventory

INSERT VALUES utilizando uma subconsulta

INSERT dataset.DetailedInventory (product, quantity)
VALUES ('countertop microwave',
        (SELECT quantity FROM dataset.DetailedInventory WHERE product = 'microwave'))

INSERT sem utilizar os nomes das colunas

INSERT dataset.Warehouse VALUES('warehouse #4', 'WA'), ('warehouse #5', 'NY')

Utilização do INSERT com tipos STRUCT

INSERT dataset.DetailedInventory
VALUES
    ('top load washer', 10, FALSE, [(CURRENT_DATE, "comment1")],("white","1 year",(30,40,28))),
    ('front load washer', 20, FALSE, [(CURRENT_DATE, "comment1")], ("beige","1 year",(35,45,30)))

Dado que a tabela tenha as colunas comments e specifications como um tipo STRUCT, com os valores seguindo a ordem dos campos, ela será incluída. Veja uma saída de uma consulta de exemplo:

INSERT com tipos ARRAY

CREATE TABLE IF NOT EXISTS dataset.table1 (names ARRAY<STRING>);

INSERT INTO dataset.table1 (names) VALUES (["name1","name2"])

Cláusula UPDATE

A cláusula UPDATE é usada para atualizar os valores existentes em uma ou mais colunas em uma tabela. Ao criar consultas com ele, pode vir com outras cláusulas:

• WHERE: as instruções UPDATE precisam incluir a cláusula WHERE com uma condição pelo menos. Caso precise atualizar todas as linhas de uma tabela, use WHERE true.

• FROM: o UPDATE pode utilizar opcionalmente a cláusula FROM, quando precisa especificar quais as linhas serão atualizadas na tabela de destino.

Sobre o FROM, algumas advertências:

1. A cláusula SET ela pode referir a colunas de uma tabela de destino e colunas de qualquer item FROM. Se tiver conflitos de nomes, as referências não qualificadas são tratadas como ambíguas.

2. Se a tabela de destino na cláusula FROM estiver presente, ela vai precisar ter um alias se quiser executar mesclagem automaticamente

3. Se uma linha de tabela estiver mesclada com zero linhas da cláusula FROM, ela não seria atualizada

4. Se uma linha de tabela estiver mesclada exatamente com uma linha da cláusula FROM, ela será atualizada

5. Se uma linha de tabela estiver mesclada com mais de uma linha da cláusula FROM, a consulta gerará o seguinte erro: UPDATE/MERGE must match at most one source row for each target row.

Segue alguns exemplos de consultas SQL utilizando a cláusula UPDATE:

UPDATE com a cláusula WHERE

UPDATE dataset.Inventory SET quantity = quantity - 10 WHERE product like '%washer%'

UPDATE usando mesclagens

UPDATE dataset.Inventory
SET quantity = quantity + (SELECT quantity FROM dataset.NewArrivals 
                     WHERE Inventory.product = NewArrivals.product),
    supply_constrained = false
WHERE product IN (SELECT product FROM dataset.NewArrivals)

Uma alternativa é associar as tabelas:

UPDATE dataset.Inventory i
SET quantity = i.quantity + n.quantity, supply_constrained = false
FROM dataset.NewArrivals n
WHERE i.product = n.product

UPDATE de campos aninhados

UPDATE dataset.DetailedInventory
SET specifications.color = 'white',specifications.warranty = '1 year'
WHERE product like '%washer%'

Como alternativa, atualize todo o registro:

UPDATE dataset.DetailedInventory
SET specifications = STRUCT<color STRING, warranty STRING, dimensions STRUCT<depth FLOAT64, height FLOAT64, width FLOAT64>>('white', '1 year', NULL)
WHERE product like '%washer%'

UPDATE de registros repetidos

UPDATE dataset.DetailedInventory
SET comments = ARRAY(
    SELECT comment FROM UNNEST(comments) AS comment  
    UNION ALL  
    SELECT (CAST('2016-01-01' AS DATE), 'comment1')
)
WHERE product like '%washer%'

Dica
Se a coluna for do tipo STRUCT, o column_name pode referenciar um campo usando a notação de ponto, como por exemplo: struct1.field1.

Cláusula DELETE

A cláusula DELETE é usada para remover linhas específicas de uma tabela. É importante explicar que a cláusula WHERE é obrigatória para esse tipo de instrução. Caso precise excluir todas as linhas de uma tabela, defina o WHERE como true, como no exemplo abaixo:

DELETE FROM dataset.DetailedInventory WHERE true

Segue mais alguns exemplos:

DELETE com cláusula WHERE

DELETE dataset.Inventory WHERE quantity = 0

DELETE com uma subconsulta

DELETE dataset.Inventory i
WHERE i.product NOT IN (SELECT product from dataset.NewArrivals)

DELETE com subconsulta, utilizando a cláusula EXISTS

DELETE dataset.Inventory
WHERE NOT EXISTS  
    (SELECT * from dataset.NewArrivals WHERE Inventory.product = NewArrivals.product)

Cláusula TRUNCATE TABLE

A cláusula TRUNCATE TABLE é uma operação que permite remover todos os dados de uma tabela de uma só vez. Ao contrário da cláusula DELETE, que remove linhas específicas de uma tabela, a cláusula TRUNCATE TABLE remove todos os dados da tabela, sem levar em consideração nenhuma condição específica. Portanto, é importante ter cuidado ao utilizar essa cláusula para evitar a perda acidental de dados importantes.

A seguir, um exemplo de como usar a cláusula TRUNCATE TABLE no BigQuery:

TRUNCATE TABLE dataset.Inventory

Cláusula MERGE

A cláusula MERGE é uma operação suportada pelo BigQuery que combina as operações de INSERT, UPDATE e DELETE em uma única consulta SQL. Essa operação é usada para combinar dados de várias tabelas em uma única tabela, ou para atualizar ou inserir novas linhas em uma tabela existente com base em uma condição de correspondência.

Ela é útil quando se trabalha com grandes volumes de dados em diferentes fontes, pois permite combinar dados de forma mais eficiente e precisa. O BigQuery permite que você execute consultas MERGE usando instruções SQL padrão, o que torna a integração de dados mais fácil e eficiente.

Suponha que você tenha duas tabelas, "customers_old" e "customers_new", que contêm informações sobre clientes. A tabela "customers_old" contém informações desatualizadas, enquanto a tabela "customers_new" contém informações atualizadas. Você pode usar a cláusula MERGE para combinar as duas tabelas e atualizar as informações desatualizadas na tabela "customers_old".

MERGE customers_old AS target
USING customers_new AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN
  UPDATE SET target.name = source.name, target.email = source.email
WHEN NOT MATCHED THEN
  INSERT (customer_id, name, email)
  VALUES (source.customer_id, source.name, source.email);

Nessa consulta, a cláusula MERGE combina as tabelas "customers_old" e "customers_new" com base no campo "customer_id". A cláusula WHEN MATCHED é usada para atualizar as informações desatualizadas na tabela "customers_old" com as informações atualizadas da tabela "customers_new". A cláusula WHEN NOT MATCHED é usada para inserir novas linhas na tabela "customers_old" com informações da tabela "customers_new" que não existiam anteriormente.

Vamos a um outro exemplo. Suponha que você tenha uma tabela chamada "orders", que contém informações sobre pedidos de clientes, incluindo o ID do cliente, a data do pedido e o valor total. Você pode usar a cláusula MERGE para inserir novos pedidos na tabela "orders" ou atualizar os valores dos pedidos existentes com base no ID do cliente e na data do pedido.

MERGE orders AS target
USING (
  SELECT customer_id, order_date, SUM(price) as total_price
  FROM new_orders
  GROUP BY customer_id, order_date
) AS source
ON target.customer_id = source.customer_id AND target.order_date = source.order_date
WHEN MATCHED THEN
  UPDATE SET target.total_price = source.total_price
WHEN NOT MATCHED THEN
  INSERT (customer_id, order_date, total_price)
  VALUES (source.customer_id, source.order_date, source.total_price);

Nessa consulta, a cláusula MERGE combina a tabela "orders" com uma subconsulta "new_orders", que contém informações sobre novos pedidos de clientes. A cláusula ON é usada para comparar o ID do cliente e a data do pedido em ambas as tabelas. A cláusula WHEN MATCHED é usada para atualizar os valores de pedidos existentes na tabela "orders" com os valores da subconsulta "new_orders". A cláusula WHEN NOT MATCHED é usada para inserir novos pedidos na tabela "orders" que não existiam anteriormente.

Para quem já tem familiaridade com bancos relacionais e SQL, vai se identificar com a maioria dos comandos aqui, e isso é bom, porque a curva de aprendizado é bem menor.

Tipos de Dados Numéricos

Os tipos de dados numéricos são usados para armazenar valores numéricos. Os principais tipos de dados numéricos são:

• INT64: um número inteiro de 64 bits, que pode ser positivo ou negativo.

• FLOAT64: um número de ponto flutuante de 64 bits, que pode representar valores com decimais.

• NUMERIC: um número decimal preciso, que pode ser usado para cálculos que requerem precisão.

Exemplo de consulta SQL utilizando o tipo de dados numéricos:

SELECT SUM(price) as total_price
FROM orders
WHERE customer_id = 12345;

Tipos de Dados de Data e Hora

Os tipos de dados de data e hora são usados para armazenar datas e horários. Os principais tipos de dados de data e hora são:

• DATE: uma data no formato YYYY-MM-DD.

• TIMESTAMP: um horário UTC com precisão de segundos.

• DATETIME: um horário com precisão de microssegundos.

Exemplo de consulta SQL utilizando o tipo de dados de data e hora:

SELECT COUNT(*) as num_orders
FROM orders
WHERE DATE(order_date) = '2022-01-01';

Tipos de Dados Textuais

Os tipos de dados textuais são usados para armazenar texto. Os principais tipos de dados textuais são:

• STRING: um texto com tamanho máximo de 2 GB.

• BYTES: um valor de byte com tamanho máximo de 2 GB.

Exemplo de consulta SQL utilizando o tipo de dados textual:

SELECT COUNT(*) as num_customers
FROM customers
WHERE name LIKE '%John%';

Tipos de Dados Geográficos

Os tipos de dados geográficos são usados para armazenar informações de localização. Os principais tipos de dados geográficos são:

• GEOGRAPHY: um ponto, linha ou polígono no formato WKT ou GeoJSON.

• ST_GEOGPOINT: um ponto geográfico com coordenadas de latitude e longitude.

• ST_GEOGPOLYGON: um polígono geográfico definido por uma lista de pontos.

Exemplo de consulta SQL utilizando o tipo de dados geográficos:

SELECT COUNT(*) as num_locations
FROM locations
WHERE ST_CONTAINS(region, ST_GEOGPOINT(-122.4194, 37.7749));

Tipos de Dados Estruturados: STRUCT

Os tipos de dados estruturados são usados para armazenar dados em uma estrutura hierárquica. Os principais tipos de dados estruturados são:

• STRUCT: uma estrutura aninhada que pode conter campos com diferentes tipos de dados.

Suponha que você tem uma tabela no BigQuery que contém informações de clientes, incluindo nome, endereço e informações de contato. A tabela pode ser estruturada como uma lista de structs, com cada struct contendo informações sobre um único cliente:

CREATE TABLE customers (
  id INT64,
  name STRING,
  address STRUCT<street STRING, city STRING, state STRING, zip INT64>,
  contact STRUCT<phone STRING, email STRING>
);

Agora, para recuperar o endereço completo de um cliente específico, você pode usar o tipo de dados STRUCT em uma consulta SQL:

SELECT address.street, address.city, address.state, address.zip
FROM customers
WHERE id = 12345;

Nessa consulta, a estrutura "address" é um struct que contém informações sobre o endereço do cliente. A consulta seleciona o endereço completo do cliente com ID 12345, mostrando a rua, a cidade, o estado e o código postal.

Note que, para selecionar campos dentro de uma estrutura, é necessário especificar o nome da estrutura seguido do nome do campo, separados por um ponto. Isso permite selecionar campos específicos de um struct e criar consultas mais precisas e eficientes.

Tipo ARRAY

O tipo de dado ARRAY é usado para armazenar uma lista de valores do mesmo tipo em uma única coluna em uma tabela do BigQuery. Esses valores podem ser de qualquer tipo de dado suportado pela ferramenta , como números, strings, data/hora, geográficos, etc.

Ao armazenar dados em um array, é possível organizar as informações em uma única coluna e simplificar a estrutura da tabela, tornando mais fácil a consulta e análise dos dados. Com o tipo de dado ARRAY, é possível, por exemplo, armazenar todos os produtos comprados por um cliente em uma única linha da tabela.

Suponha que você tenha uma tabela no BigQuery que contém informações de pedidos de clientes, incluindo o ID do cliente e uma lista de produtos comprados. A tabela pode ser estruturada da seguinte maneira:

CREATE TABLE orders (
  id INT64,
  customer_id INT64,
  products ARRAY<STRUCT<product_name STRING, quantity INT64>>
);

Nessa estrutura, a coluna "products" é um array que contém informações sobre os produtos comprados pelo cliente em cada pedido. Para recuperar o número total de produtos comprados por um cliente específico, você pode usar o tipo de dados ARRAY em uma consulta SQL:

SELECT SUM(product.quantity) as total_quantity
FROM orders, UNNEST(products) as product
WHERE customer_id = 12345;

Nessa consulta, a função UNNEST é usada para desaninhar a estrutura de produtos, permitindo que cada linha da tabela corresponda a um único produto comprado pelo cliente. O resultado da consulta é o número total de produtos comprados pelo cliente com ID 12345.

O BigQuery é uma ferramenta poderosa para armazenar e consultar dados em nuvem, permitindo a análise de grandes volumes de dados em tempo real. Com uma variedade de tipos de dados disponíveis, é possível armazenar e classificar diferentes tipos de dados em uma estrutura hierárquica, o que pode facilitar o processo de consulta e análise de dados. Ao conhecer os tipos de dados disponíveis e como utilizá-los em suas consultas SQL, você poderá extrair informações valiosas de seus dados em menos tempo e com maior eficiência.

O que é o BigQuery?

Ele é um Modern Data Warehouse da Google, em que possui uma estrutura de armazenamento com a capacidade e infraestrutura do Cloud da Google, em que as consultas são feitas via SQL. Você pode fazer as chamadas na plataforma, mas também pode ser feito através da linha de comando, em chamadas REST ou usando as bibliotecas como .NET, Java ou Python. Ele foi feito para lidar com grande volume de dados, na casa dos Petabytes. Ele não tem servidor, portanto não tem necessidade de uma infraestrutura para gerenciar o ambiente.

Além disso ele é rápido por conta da forma com que os dados são armazenados, utilizando a forma colunar. Essa estrutura visa diminuir o processo de I/O de disco ao mínimo, lendo a menor quantidade de dados durante a consulta. Além disso, diferente do relacional, em que é usado em aplicativos transacionais, no colunar ele é otimizado para uma recuperação rápida de dados, normalmente usados em aplicações analíticas.

Por conta da otimização na leitura dos dados em disco, e na forma em que a estrutura foi pensada, ela é ideal para soluções como Data Warehouse e Processamento de Big Data.

Por essas características, ela é uma excelente opção para empresas que precisam armazenar e analisar grandes volumes de dados em tempo real. A plataforma oferece um ambiente seguro e escalável para armazenamento de dados, além de permitir o acesso a dados em tempo real e a execução de consultas complexas em segundos. O BigQuery também é altamente integrado com outras soluções do Google Cloud Platform, como o Google Analytics e o Google Data Studio.

Quais são suas vantagens?

• Análise em tempo real: Com a performance dela podemos fazer inclusões de streaming, além de permitir capturar e analisar os dados praticamente online para gerar insights rápidos. Os dados novos ficam disponíveis imediatamente.

• Acessível a grandes e pequenas companhias: Por conta da forma de cobrança, ela é flexível no orçamento para qualquer tamanho de empresa. Para pequenas empresas por exemplo, temos as cotas mensais gratuitas (até 1Tb/mês de dados analisados e 10Gb de dados armazenados), e para as grandes é costume optar pela escala, com contrato focado na disponibilidade e suporte.

• Dispensa servidor: Como ela se beneficia da infraestrutura da Google, ele pode focar somente nos insights gerados através das consultas.

• SQL padrão: Ele utiliza o padrão ANSI:2011, o que reduz a necessidade de reescritas e novos aprendizados. Além disso disponibiliza drivers (ex.: ODBC e JDBC) sem custo.

• Separação de armazenamento e computação: Ele possui uma estrutura escalonada, facilitando a capacidade de armazenar os dados, e que por consequência resulta em custos menores. Além disso, o armazenamento pode ser cobrado separadamente das consultas. De acordo com o Google, o BigQuery viabiliza a redução de custos em 56% a 88%.

• Modelo de preços flexíveis: Você escolhe a opção de pagar somente armazenamento e recursos utilizados. Em outros modelos, como fixo, pode escolher um custo mensavel escalável, de acordo com seu volume de dados.

• Compartilhamento otimizado: Você pode compartilhar o acesso a sua base para usuários internos ou externos, tendo segurança de autenticação e papéis, além de saber o custo gerados nas consultas a partir de cada usuário.

• Descontos automáticos: Se você tem utilizado e armazenado os dados com grande frequência, nos primeiros 90 dias o Google automaticamente aplica descontos.

• Importação de dados: é possível fazer a importação dos dados a partir de arquivos como CSV, JSON, Avro ou Parquet.

• Machine Learning: Com o BigQuery ML você pode criar, testar e utilizar modelos de Machine Learning nos dados em escala global, usando SQL simples.

Criando sua conta no GCP

Para criar uma assinatura no Google Cloud, você pode utilizar alguma conta Google que utiliza os recursos do Workspace por exemplo (Gmail, Google Docs, etc). Nos primeiros 90 dias você ganha um crédito de $300 para gastar nos serviços. Clique em "Comece agora gratuitamente"

Feito isso ele vai fazer algumas perguntas em 3 etapas.

Etapa 1

Etapa 2
Nesse caso esse usuário já preencheu algumas informações, que caso seja acessado pela primeira vez, pode ser solicitado como:

• Tipo de Conta

• CPF ou CNPJ

• Endereço

• Data de Nascimento (em PF)

• Dados de pagamento

Sobre os dados de pagamento o Google solicita, mas não quer dizer que será cobrado, isso é feito para fins de evitar criação de contas por robôs. Você só será cobrado se alterar isso manualmente na sua conta. Lembrando que se passar dos 90 dias, você precisa atualizar para uma conta paga.

Etapa 3
Com tudo isso feito, você será redirecionado para um dashboard principal do Google Cloud.

Na primeira vez é provavel que o conteúdo dele esteja em branco, mas no caso da imagem acima eu criei um novo projeto para trabalhar em cima. Ele traz algumas informações relacionados a ela.

Criando um novo projeto

Para o GCP um projeto é um escopo que você aloca um conjunto de recursos a ela, então pode no Cloud vários projetos. Para isso você vai na barra superior (ao lado do "Google Cloud Platform") e selecione o campo. Vai aparecer uma modal com a lista de projetos cadastrado, e opção de incluir um novo.

Ao solicitar a criação de um novo projeto você vai preencher os seguintes dados:

• Nome do projeto

• ID do projeto (opcional porque ele é gerado automaticamente)

• Qual organização deseja que esse projeto esteja vinculado

• Local (pode ser uma pasta ou organização pai)

Depois de criado você pode selecionar e vincular os recursos do GCP que deseja nele.

Criando sua primeira consulta

Vamos fazer a nossa primeira consulta, e para precisa ter uma conta criada e logada, além de ter criado um projeto. Para acessar a ferramenta, vamos no menu lateral e ir na seção Big Data.

Clicando na opção, vamos ser redirecionados ao Espaço de trabalho SQL em que teremos acesso ao editor de texto, em que iremos executar as nossas consultas.

Um detalhe importante é que no topo do editor, é exibido um alerta sobre o Sandbox. Ele é preparado para você experimentar a ferramenta e fazer as consultas e armazenamentos, mas com determinados limites. Acesse a documentação para entender mais. Agora vamos fazer a primeira consulta, usando uma base de dados pública que o BigQuery disponibiliza.

SELECT gender, tripduration FROM `bigquery-public-data.new_york_citibike.citibike_trips` LIMIT 5

Aqui estamos trazendo duas colunas, de um dataset público, que são os dados sobre o uso de bicicletas na cidade de Nova York. A consulta é simples, mas existe uma peculiaridade. Podemos ler a query da seguinte forma:

Busque as colunas gender e tripduration que está na tabela citibike_trips, do dataset new_york_citibike, do projeto bigquery-public-data.

Atenção!

Como estamos acessando algo fora do nosso dataset e projeto, essa sintaxe é necessária. Mas no caso da nossa própria base, podemos definir o nome da tabela somente. Além disso, é importante explicar que:

• No nosso projeto podemos ter vários datasets

• No nosso dataset podemos ter várias tabelas

Nesse exemplo vemos o quão semelhante uma query no BigQuery é semelhante ao que conhecemos do SQL em bancos relacionais.

• Melhor produtividade
• Coerência no código, sem usar e abusar de queries SQL, usando o paradigma de programação da aplicação.
• Facilita na mudança de banco de dados (às vezes, não vem ao caso)

Mesmo com seus prós e contras ele ajuda muito, só tem um problema.

Com toda essa dependência, você fica “mais ignorante” com o SQL.

Claro que alguns podem discordar, e fiquem a vontade para falarmos nos comentários, mas conversando com alguns colegas, creio que o sentimento é parecido: você perde a “memória muscular” do SQL ou peculiaridades do banco e suas boas práticas. Por isso, achei legal dar uma revisada sobre banco de dados e principalmente sobre essa linguagem de consulta, para justamente não confiar cegamente nessas bibliotecas, porque elas não são perfeitas, e um dia vai ser necessário customizar o comportamento delas para se tornar mais performática.

Irei criar posts voltado a esses estudos, e hoje vamos falar um pouco da história do banco de dados e como surgiu o SQL como conhecemos hoje.

Começando do início

Antes de mais nada, o que é um banco de dados? Basicamente é um conjunto de informações relacionadas. Na wikipédia diz:

Bancos de dados ou bases de dados são um conjunto de arquivos relacionados entre si com registros sobre pessoas, lugares ou coisas. São coleções organizadas de dados que se relacionam de forma a criar algum sentido (Informação) e dar mais eficiência durante uma pesquisa ou estudo.

O caso de uma lista telefônica pode ser considerado um banco de dados. Quando tinhamos um caderninho com os nomes das pessoas e seus telefones eles eram organizados de forma estruturada e os dados eram relacionados e que tinham a informação para entrarmos em contato, quando necessário. Em banco de dados físico, tinham suas desvantagens:

• Pesquisar os dados necessários poderia levar a algum tempo, em caso de muitos registros
• A mudança de dados, de forma frequente, tornava mais desgastante e custava mais, quando era impresso.

Depois veio os bancos de dados que eram armazenados em fitas magnéticas, e veio tornar mais fácil, mas claro ainda estava aquém do ideal, como limitações de hardware na época.

Ao longo dos anos, surgiram outras soluções de banco de dados, algumas com modelos de dados específicos.

Tipos de Modelo de dados

Em Sistemas de Banco de Dados, temos uma variedade de tipos de base de dados, ou seja, em como esses dados estão organizados:

Hierárquico

Trabalha com conceito de árvore, usando ligações entre os registros.

Redes

Possuem registros e ligações que definem os relacionamentos entre os registros.

Relacional

Representação dos dados em conjunto de tabelas. Esse modelo foi idealizado por Edgar Frank Codd em 1970, sendo descrito no artigo “Relational Model of Data for Large Shared Data Banks”. Esse tipo que usamos até hoje e iremos focar.

SQL e sua história

Além do modelo relacional, o Codd propôs uma linguagem para manipular os dados em tabelas, e que foi chamado de DSL/Alpha. Com a publicação de um artigo com essa proposta, a IBM auxiliou para que fosse possível criar o protótipo, e assim foi criado uma versão inicial, chamado de SQUARE. Após o seu lançamento, ele sofreu melhorias e que levou a mudança do nome para SEQUEL que foi finalmente renomeada para SQL. Um dos principais desenvolvedores foram Donald D. Chamberlin e Raymond F. Boyce.

No SQL temos partes distintas na linguagem:

• Instruções de esquema SQL: Usados para definir os objetos do banco de dados em que os dados serão armazenados (tabela, chave primária, etc);
• Instruções de dados SQL: Usados para manipular as estrutura de dados definidas previamente;
• Instruções de transação SQL: Usado para iniciar, encerrar e desfazer transações

Alguns exemplos:

CREATE TABLE contatos(  
id SMALLINT,  
nome VARCHAR(50) NOT NULL,  
telefone VARCHAR(30) NOT NULL,  
CONSTRAINT pk_contatos PRIMARY KEY (id)  
);

Foi usado acima a instrução de esquema para criar a tabela contatos no banco de dados. No caso de inserir e consultar um novo registro, respectivamente, usamos a instrução de dados:

INSERT INTO contatos (id, nome, telefone) VALUES (1, 'Carlos Silva', '(61) 99999-1111');SELECT * FROM contatos;

Essa linguagem é intrinsecamente ligado a modelo relacional porque o resultado de uma consulta gera uma tabela, ou o conhecido result set. Com isso podemos usar tanto as tabelas permanentes, criados via instrução de esquema, como as tabelas do tipo result set, como entradas para futuras consultas.

Conclusão

Dessa forma, espero que tenha sido interessante essa breve introdução e história do banco de dados e como surgiu o SQL.

Até mais.

Antes de começar: Esse post eu criei em 2017 no Medium, mas ele continua atual, ainda mais em relação com o meu recente diagnóstico de que tenho TDAH e sinais leves de TEA (Transtorno do Expectro Autista). Eu ainda estou assimilando tudo isso, mas no futuro quero escrever mais sobre. Até lá, espero que esse post traga uma boa reflexão desse mundo que exige de nós uma alta performance a todo momento.

Na vida, sempre temos algo que nos angustia, nos chateia, e que queremos superar ou melhorar, e o que me deixa mais chateado é a minha atitude em procrastinar as coisas, o clássico “empurrando com a barriga”. Mas hoje não fico tão triste com isso porque vejo que isso é algo que vem de mim. Isso prejudica com certeza, mas como tudo na vida, temos que pegar o lado bom de tudo.

Se a vida te der um limão, faça uma limonada!

Quem me conhece, sabe que uso qualquer tipo de ideia ou ferramenta que me ajude a ser mais produtivo. Um tempo usei o pomodoro, que é um ótimo timebox para estudos, e qualquer tipo de tarefa que precise de foco, e hoje uso o GTD para armazenar e controlar todas as tarefas do meu cotidiano. Para quem consegue finalizar todas as suas tarefas que aparecem, pode achar isso loucura, mas eles me salvam tem 4 anos. Mas como nada é uma bala de prata, tenho recaídas, e elas geram desânimo e até breves momentos de depressão. E para quem tem um certo nível de TDAH, sabem que essas coisas intensificam, por mais banais que sejam.

Fazendo minhas leituras entre livros de História, Programação e Política, esses dias acabei lendo um livro chamado A Arte da Procrastinação — Como Realizar Tarefas Deixando-as Para Depois porque sempre gosto de encontrar algo que possa melhorar meu desempenho. Achei o título interessante e fiquei meio desconfiado, mas comecei a ler. O interessante é que tive uma surpresa meio óbvia mas que não nos tocamos: não sou o único. É idiota pensar nisso, mas por favor, todo mundo tem esse questionamento com qualquer defeito que encontra em você mesmo.

Ele trouxe alguns pontos que todo procrastinador vai se identificar. Quero descrever alguns deles.

Muitas tarefas sendo feitas, mas suas prioridades são questionáveis

Tarefas sempre vão aparecer e serão várias, mas conseguimos fazer muitas delas. Mas será que realmente era necessário finalizá-las agora?

Meu fracasso mais sério, em termos desse ideal, é a procrastinação. Em 1995, por não trabalhar em algum projeto ao qual deveria estar me dedicando, comecei a me sentir mal. Mas aí notei algo. No geral, eu tinha a reputação de alguém que fazia muitas coisas e contribuía de forma razoável com a Universidade de Stanford, onde eu trabalhava, e com a disciplina de filosofia, que era meu campo de ensino. Um paradoxo. — Perry, John

Quantas vezes ficamos nessa situação? Muitos projetos na cabeça, mas nenhum concluído, mas por outro lado, outros tipos de trabalhos fazemos. O John definiu como um procrastinador estruturado.

Entendi que eu mesmo era o que chamei de procrastinador estruturado: uma pessoa que faz muito ao não fazer outras coisas. — Perry, John

Ou seja, somos profissionais em fazermos muitas tarefas, mas nos deparamos com o fato de que não eram realmente importantes, que não estavam na categoria da prioridade máxima. O mais interessante é que o livro não traz métodos para buscarmos o nosso melhor para acabarmos com isso, coisa que existem em muitas outras obras por ai, mas termos atitudes que possamos conviver e usar esse problema ao nosso favor, fazendo com que a coisa mude de figura.

Todos os procrastinadores adiam as coisas que precisam fazer. A procrastinação estruturada é a arte de fazer esse traço negativo trabalhar por você. A ideia central é que a procrastinação não significa que você não vai fazer absolutamente nada.

Procrastinadores raramente não fazem absolutamente nada; eles fazem coisas marginalmente úteis, como jardinagem, apontar lápis ou criar um diagrama de como vão reorganizar seus arquivos quando se decidirem a iniciar. Por que o procrastinador faz essas coisas? Porque são uma forma de não fazer algo mais importante.

Se tudo que o procrastinador tivesse de fazer fosse apontar lápis, nenhuma força na Terra o obrigaria a fazer isso. O procrastinador pode ser motivado a fazer tarefas difíceis, convenientes e importantes, desde que essas tarefas sejam uma forma de não fazer algo ainda mais importante. — Perry, John

Ele mostra que com a procrastinação estruturada, podemos moldar a forma que definimos as nossas tarefas “para fazer de uma forma que se explore esse fato”. Tentamos minimizar os nossos compromissos ao básico, pensando que vamos conseguir fazê-los. Pode funcionar por um momento, mas depois vem aquela decaída novamente, que é a nossa autosabotagem. Ele fica pairando sobre você, enquanto consegue um maravilhoso momento em que está produzindo, sendo útil para a sociedade, mas qualquer descuido, ele nos ataca. Volta todo o sentimento de inutilidade e desânimo. Entenda, ele vai estar sempre ao lado querendo acabar com seu desempenho, mas precisamos aprender a usar a nosso favor.

O truque é pegar o tipo certo de projetos para pôr no alto da lista. A espécie ideal de tarefas tem duas características. Primeiro, elas parecem ter prazos claros (mas realmente não é assim). Segundo, parecem incrivelmente importantes (mas realmente não são). Felizmente, a vida está cheia de tarefas assim. — Perry, John

E é verdade. Quem nunca retomou pela enésima vez para sua lista de afazeres, e depois queremos definir suas prioridades, mas com o tempo acaba que todos são urgentes? Por mais que ninguém aceite, nem toda tarefa vai ter sempre um prazo claro e vai ser importante. Para nós são tarefas e pronto. Mas o que fazemos quando vier o sentimento de fazer para depois?

Preencha o “fazer a tarefa para depois”, colocando outra tarefa

Sempre faça uma tarefa

Sim, é isso mesmo. Quando você olha para uma tarefa, e bate aquele incômodo de fazer e em sequência vem o desejo de fazer depois, procure outra tarefa na sua lista diária e faça. Isso evita o problema de criar tempo ocioso aonde não pode ter, e não fica com aquele sentimento que não fez nada no dia.

Se encontrou tarefas que só aumentam o desejo de adiá-las, quebre em pequenas partes

Faça em partes

Dividir para conquistar ou dividir para reinar, já dizia César. Se uma tarefa que definiu é assustador suficiente para desanimar, quebre em pequenos passos. Assim, alivia o sentimento de adiamento, focando um item de cada vez (dica: use o pomodoro para focar em cada passo), que no final do dia vai ver o seu progresso e vai se sentir feliz com isso.

O perfeccionismo é o amigo da procrastinação

Não quer dizer que você não pode buscar a fazer o melhor, mas o que estou dizendo é simplesmente faça. Porque o perfeccionismo que temos, é do tipo fantasioso.

Acho que perfeccionismo leva à procrastinação. Demorei para ver a conexão entre os dois, porque não me vejo como perfeccionista. Muitos procrastinadores não percebem que são perfeccionistas, pela simples razão de que nunca fizemos nada com perfeição, não chegamos nem perto disso. — Perry, John

Eu sou perfeccionista em muitas coisas que faço, e depois de fazer uma auto-análise, vejo que acabo perdendo tempo pensando nas melhores formas de fazer algo, do que simplesmente começar, e depois melhorando com o tempo. É o que meu colega Henrique Bastos já falou em um curso de desenvolvimento de sistemas com Python e Django que fiz com ele. Ele chamou isso de síndrome do astronauta.

Nós programadores temos ou tivemos o síndrome do astronauta. Ficamos pensando na melhor solução, planejando e quando vemos estamos no mundo da lua. Bastos, Henrique (com modificações)

E vejo que isso não se limita a minha área, mas a todos os procrastinadores. Então controle o seu perfeccionismo, faça o que precisa ser feito mesmo não estando do jeito que gostaria. Depois, analise o que criou e melhore. Recomendo que estudem sobre Kaizen.

Nunca desista das suas listas de tarefas. Mesmo!

Tenha uma lista colado em você.

Falamos de como podemos lidar com as tarefas, mas vamos sempre precisar de listas. Não confie na sua mente, um hora aquele pedido que recebeu do seu chefe vai ficar entulhado no emaranhado de idéias que sempre surge na sua mente, então procure uma melhor abordagem para você. Eu hoje uso o GTD (Getting Things Done) idealizado por David Allen, e recomendo que faça uma breve leitura sobre ela. Mesmo que você não use a metodologia 100% (coisa que ela não exige, pode começar aos poucos), ela pode trazer bons insights para o seu worfklow.

O importante é que ela esteja sempre com você, e a cada compromisso que venha ao seu encontro, coloque nela. Não se preocupe caso acabar esquecendo da lista, mas quando lembrar, pegue-a e tente novamente até não conseguir mais ficar sem ela.

Respeite o seu ritmo

Cada um tem o seu ritmo, saiba o seu e respeite-a.

Todos são diferentes, inclusive o ritmo em produzir algo. As vezes queremos acelerar para fazer o máximo possível em menos tempo, e isso para um procrastinador é um veneno, no início. Antes faça no seu ritmo, porque caso forçar demais poderá acabar abandonando o que estava fazendo. Quando sentir que pode aumentar sua velocidade, faça. As vezes é melhor fazer algo no seu tempo e terminá-la, do que fazer ligeiro e ficar pela metade.

Use o computador e a internet com sabedoria

Computador e Internet veio para ajudar, e não atrapalhar.

Talvez para alguns não é um problema, mas para mim é uma das grandes. Eu desenvolvo sistemas, e o computador e a internet são ferramentas essenciais, para consulta, estudo, download, etc. E preciso tomar o cuidado de não cair na tentação de acessar e-mails além do normal e redes sociais, e pior, durante a pesquisa entrar no caminho infinito de links dentro de links, que no final absorvi informação além do que preciso.

Para sanar esse problema, acabo usando ferramentas em navegadores para bloquear certos sites durante momentos em que preciso de foco. Para quem usa o Chrome recomendo a extensão Stay Focusd que você pode configurar o intervalo de tempo e quais sites deseja bloquear.

Outro que gosto de usar, é o Rescue Time que é um serviço que monitora o tempo que gasta em cada aplicação no seu desktop, como também em cada site na web. Você pode classificar cada um deles como produtivo ou não, e depois recebe por e-mail um relatório semanal do tempo gasto e quanto tempo foi produtivo ou não. Acho legal, porque vejo quais sites que não estão na lista e atualizo. São ferramentas que vão ajudar, mas o mais importante é você fazer sua parte.

Atualizado (11/01/20): Depois de alguns anos depois desse post, eu e toda a Sociedade passou por situações no mínimos bizarras na Internet, principalmente nas Redes Sociais, que tornou a discussão sobre política e tudo mais em um extremo cada vez pior, graças as bolhas que vivemos. Diante dessa selva digital, precisamos nos condicionar a ter um comportamento adequado não só no mundo real. Mais uma vez o Henrique Bastos, trouxe alguns insights necessários hoje e sempre sobre como levdar com essa selva binária:

12 regras para sobreviver na selva da Internet

A internet eliminou as distâncias, mas ainda não sabemos superar o ruído. Descubra como sobreviver e aproveitar o que a rede tem de melhor.

Fique ao lado de pessoas que te ajudem a crescer

Sempre temos alguém que nos quer bem

Procrastinadores que recebem apoio de pessoas que querem o seu bem, é sempre importante. Elas ajudam a criarmos um “compromisso público” de que temos que fazer algo. Já trabalhei em projetos com alguém que um vigiava o outro nas tarefas que fazíamos (de forma saudável claro, sem exageros), e que trouxe ganhos. Assim, se puder contar com algum amigo, colega de trabalho ou alguém da família para acompanhar na sua jornada, junte-se a eles e vai ver os frutos disso.

Se alguma tarefa pode ser feita por outra pessoa, delegue-a na medida do possível

Delegue, mas com bom senso.

Aqui é preciso um bom senso. Não quero dizer que deve sempre jogar suas responsabilidades para os outros, mas se alguém pode ajudar você a terminar alguma tarefa, e ela tenha capacidade de fazer isso sozinha sem a comprometer, delegue. Isso vai ajudar a tornar sua lista diária menos, e consequentemente vai esvaziá-la no fim do dia. Por outro lado, sempre acompanhe a pessoa que te ajudou, caso precise de algo, porque como falei é uma questão de bom senso.

Procrastinadores irritam outras pessoas, então mostre para elas como é difícil ser assim

Mostre sua visão de mundo para outras pessoas.

Eu sou casado, e minha esposa precisa de muita paciência comigo, porque acabo esquecendo de fazer o que precisa, não presto atenção algumas das vezes porque uma idéia surgiu na minha cabeça na hora, e quando vai ver estou sendo puxado de volta com uma reclamação dela. Temos que ter a consciência que nós irritamos pessoas que não são procrastinadoras, seja esposa ou marido, familiares, colegas de trabalho, etc. Mas o que eles não sabem é que isso nos entristece. Ficamos chateados quando esquecemos ou não fazemos algo que foi pedido, ou quando perdemos o prazo e que isso tudo está prejudicando alguém. Quando acontece, volta o momento desmotivação. Quantas vezes em final de ano vem aquele desapontamento de que não conquistou praticamente nada?

Então, converse e mostre o seu lado nisso tudo. Eu sempre converso com as pessoas que convivo sobre o meu problema, e como procuro melhorar para que isso não afete ao meu redor. Mostre que mesmo quando as deixamos estressadas, não é nossa intenção, e que buscamos o máximo para consertar e evitar isso. Assim, em algum momento vão entender e talvez possam refletir nisso, para que caso isso aconteça possam ter um pouco de paciência e ajudar a sairmos do outro lado. Então, converse e procurem entrar em consenso na medida do possível.

Desistir é natural, mas continuar na desistência é burrice

Just do it!

Sempre vai vir momentos em que vamos desistir em lidar com a procrastinação, é comigo e vai acontecer com você. Mas o que não devemos deixar, é que isso continue. Então, volte e repense no que fez, procure ser melhor um dia de cada vez.

Somos procrastinadores sim, mas podemos lidar com isso e vivermos bem. Bom deixa eu voltar na tarefa que deixei para escrever esse artigo. Até mais!

Vamos supor que temos um um arquivo input.txt em que possui no seu texto uma palavra hello. O que queremos é substituir para world. Segue o exemplo do conteúdo:

Hi,

My name is Gilson and Hello There!
And hello to his family.

E para alterar isso podemos utilizar a seguinte sintaxe:

sed SCRIPT INPUTFILE...

Em que SCRIPT é o local que o programa vai executar as transformações com base no seu sintaxe e também via RegeX.

Com isso podemos utilizar a sintaxe interna do programa com o s/<old>/<new>/[<flag>, ...] para alterar hello para world:

sed 's/hello/world/' input.txt

Usando dessa forma, por padrão o sed irá utilizar a saída padrão para trazer o resultado da substituição:

sed 's/hello/world/' input.txt                                                                                                                                                                                                                                                                                                                                          
Hi,

My name is Gilson and Hello There!
And world to his family.

Caso precisa fazer a alteração no próprio arquivo e por todas as ocorrências encontradas, podemos utilizar algumas funções adicionais:

• Argumento -i: utilizado para aplicar uma mudança in-place, sem saída padrão.
• Flag g do comando s//: utilizado para aplicar a mudança em todas as ocorrências encontradas no conteúdo
• Flag i do comando s//: utilizado para aplicar a mudança independente de maiúscula ou minúscula (conhecido como case-insensitive).

sed -i 's/hello/world/gi' input.txt

cat input.txt
Hi,

My name is Gilson and world There!
And world to his family.

Caso queira testar os parâmetros e comandos disponíveis em um modo live preview existe uma ferramenta interessante para verificar se a sintaxe utilizada no sed está correta, é o GNU sed REPL.

Mas antes vamos precisar seguir algumas configurações necessárias para fazer esse procedimento como:

• Habilitar o uso do BigQuery
• Habilitar o IP público da sua instância Cloud SQL
• Criar uma conexão externa do Cloud SQL no BigQuery
• Garantir que o seu usuário ou service account tenha as roles adequadas

Exemplos de uso

Com as queries federadas você utilizar para dois tipos de necessidades que vamos exemplificar: cruzar dados de bases diferentes e efetuar ingestão de dados.

Exemplo 1: Cruzando dados de bases diferentes

Imagine que você tem dois serviços independentes, focados em dados de clientes e vendas respectivamente. Cada um deles armazena em uma base diferente. Precisamos fazer uma busca em que queremos saber qual foi a data da primeira compra feita por cada cliente.

Essa query pode ser feita no BigQuery e utiliza a função EXTERNAL_QUERY. A consulta abaixo mostra como isso é feito:

SELECT c.customer_id, c.name, rq.first_order_date
FROM mydataset.customers AS c
LEFT OUTER JOIN EXTERNAL_QUERY(
  'us.orders_db',
  '''SELECT customer_id, MIN(order_date) AS first_order_date
    FROM orders  
    GROUP BY customer_id''') AS rq ON rq.customer_id = c.customer_id
GROUP BY c.customer_id, c.name, rq.first_order_date;

Nesse trecho temos o seguinte:

• O primeiro argumento da função é o ID da conexão externa que foi criada no BQ, e isso é importante para ter acesso a base
• O segundo argumento é a query SQL que será executada no banco externo, respeitando toda a sintaxe do fornecedor (como PostgreSQL por exemplo). Os dados retornados serão incluídos em uma tabela temporária.
• Com base na tabela temporária é feito um JOIN, utilizando o campo customer_id
• E por fim a consulta principal faz a seleção dos dados e os agrupa.

Dessa forma você consegue extrair informações que precisa, sem ter que ficar copiando um grande volume.

Exemplo 2: Efetuando ingestão de dados

Seguindo o mesmo cenário do primeiro exemplo, vamos supor que agora queremos fazer a ingestão de todos os dados da tabela orders, como fazer nesse caso? A query abaixo mostra como fazer:

INSERT INTO `foobar-project.ecommerce.orders`
SELECT orders.* FROM EXTERNAL_QUERY(
  "us.orders_db",
  '''SELECT * FROM orders;'''

) orders;

Aqui é mais simples de entender, mas basicamente o resultado da query feita na tabela orders da base externa, vai para a tabela temporária e com isso as informações vão servir como insumo para a ingestão dos dados na tabela orders do dataset ecommerce no BQ.

Aqui temos algumas considerações a colocar no uso desse cenário:

• Ao utilizar o asterisco (*) na consulta, o nome das colunas da tabela BQ precisam ser idênticas a tabela externa. Caso contrário defina os nomes de forma explícita (nas duas entidades de preferência)
• A ingestão é feita se os dados externos respeitarem os tipos de dados que as colunas da tabela BQ foram declaradas. Na documentação existe uma tabela de mapeamento dos dados, que explica melhor.

Em ambos os casos, o uso das Queries Federadas podem ser de grande utilidade para quem lida com dados no dia a dia.

Infelizmente se fizermos a consulta abaixo em que queremos retornar 10 registros em uma base de 1Tb por exemplo não vai economizar na cobrança:

SELECT * FROM dataset.table1 LIMIT 10

Seguindo a mesma idéia, usando uma base pública do BigQuery, que é os dados dos aluguéis de bicicletas em Nova York. A query abaixo traz pouca informação, mas olha a quanidade de dados que ele vai precisar processar para executar:

Para ficar claro que o LIMIT nesse contexto não funciona vamos fazer o seguinte: vamos selecionar todas as colunas da tabela:

Aumentou para 7.5 GiB!

Ou seja, mesmo que solicitamos somente uma pequena amostra, a cobrança vai ser dentro dos dados que ele vai percorrer. Se a ferramenta disse que precisa passar por 800Gb por exemplo, ele vai fazer isso mesmo assim. Isso é ruim porque quanto mais fazer suas consultas e elas exigirem mais dados para percorrer, mais caro vai ficar no final do mês. O BigQuery tem algumas formas de resolver isso.

Consultas em tabelas particionadas

Uma forma é fazer o particionamento das tabelas, baseado em alguma informação como a data de registro de um produto como _PARTITIONDATE em que a plataforma, ou a partir dos dados de uma coluna da tabela. Assim você pode escolher por exemplo uma data em que tem uma quantidade pequena de dados para criar suas consultas:

SELECT * FROM dataset.table1 WHERE _PARTITIONDATE = '2021-01-01'

Dessa forma, o particionamento pode ajudar inclusive em produção para tornar suas consultas mais baratas e rápidas.

Consultas em amostragem

Uma segunda forma é fazer uma consulta em cima de uma seleção menor, um subconjunto de dados através do TABLESAMPLE. Ele traz uma quantidade aleatória de dados de uma tabela a partir de um determinada porcentagem. Por exemplo, em uma tabela de 10.000 registros, eu quero consultar em uma amostra de 1%, ou seja, 100 registros:

SELECT * FROM dataset.table1 TABLESAMPLE SYSTEM(1 PERCENT)

Dessa forma ele atua algo como um LIMIT nos bancos relacionais, mas principalmente diminuir os custos fazendo com que a plataforma percorra por menos dados. No nosso exemplo da base pública, se definirmos uma amostra de 1% em cima dos 7.5 GiB de dados diminuimos para 80.5 MB na consulta e com isso fica mais barato.

Consulta em uma amostra de uma amostra

Além disso você pode consultar em uma amostra menor ainda, a partir de outra. Por exemplo, você deseja ler 20% dos blocos de dados armazenados e quer selecionar 10% das linhas desses blocos:

SELECT * FROM dataset.table1 TABLESAMPLE SYSTEM (20 PERCENT) WHERE rand() < 0.1

Referências

• Table sampling. BigQuery Documentation. Disponível em: https://cloud.google.com/bigquery/docs/table-sampling. Acesso em: 22/09/2022

• Conexões seguras: o Auth Proxy automaticamente encripta todo o tráfego de dados de ponta a ponta utilizando TLS 1.3 com 256-bit AES cipher. Em toda a comunicação é utilizado certificados SSL para verificar a identidade do client e do server, independente do protocolo do banco de dados, fora que não precisa gerenciá-los.
• Autorização de conexão facilitada: é utilizado as permissões IAM para controlar quem e quando conectar na sua instância. Além disso o Auth Proxy lida com a autenticação com o Cloud SQL, de forma que remove a necessidade de prover um endereço de IP estático.
• Autenticação do banco via IAM: opcionalmente o Auth Proxy suporta a opção de atualização automática de tokens OAuth 2.0

O Auth Proxy não fornece um novo caminho de conectividade, então ele depende da conectividade existente. Para conectar utilizando o IP privado, é preciso estar em um recurso com acesso à mesma rede VPC da instância.

Requisitos de utilização

Para fazer uso dela precisa seguir algumas premissas:

• Precisa ter o Cloud SQL Admin API habilitado
• Prover para o Auth Proxy credenciais de autenticação do GCP
• Prover para o Auth Proxy as contas de usuário e senhas do banco válidos
• A instância deve ter um IP público IPv4 ou ser configurado para utilizar o IP privado

Para fazer a instalação, siga as instruções da documentação.

Como o Cloud SQL Auth Proxy funciona?

O serviço segue alguns passos para chegar no objetivo que é disponibilizar uma conexão disponível no banco:

1. Começando por um client local executando no mesmo ambiente da aplicação, por exemplo. Ela comunica com o Auth Proxy através do protocolo do banco de dados, como seria comunicado diretamente com a base de dados.
2. Em seguida, o Auth Proxy usa um túnel seguro para comunicar com o processo semelhante sendo executado no servidor. Cada conexão estabelecida através do Auth Proxy cria uma conexão para a instância Cloud SQL.
3. Quando essa aplicação conecta através do Auth Proxy, o client local verifica se já possui uma conexão disponível entre ela, e a instância Cloud SQL. Caso contrário, é solicitado uma nova, gerando inclusive certificados SSL efêmeros e assim utilizados nessa comunicação

Abaixo a imagem traz uma visão geral de tudo isso:

Observação: Esse certificados efêmeros expiram em aproximadamente 1 hora, mas o Auth Proxy tem a inteligência de solicitar uma renovação antes disso acontecer.

Autenticação via Service Account

O Cloud SQL Auth Proxy se utiliza dos Service Accounts para autorizar a conexão entre o client e a instância. Dessa forma, tenha disponível essa chave e passe via parâmetro para o cloud_sql_proxy. Quando for utilizar esse meio, se certifique que sua chave tenha a role que gerencia as ações necessárias no Cloud SQL, portanto, dentre sua lista de permissões adicione cloudsql.instance.connect entre elas para que tenha disponível ações relacionados a:

• Cloud SQL Client
• Cloud SQL Editor
• Cloud SQL Admin

Criando conexão para acesso ao banco de dados

Abaixo temos um exemplo de execução do comando cloud_sql_proxy para criar uma nova conexão com uma instância, a partir do seu Connection Name, que é o mais recomendado porque ele atua como um “DNS” do recurso, sem recorrer a IP estáticos:

cloud_sql_proxy -instance=projecttest-1235:us-central1:my-cloudsql-instance=tcp:5432

Com o comando acima é disponibilizado um acesso a instância a partir do protocolo TCP, utilizando o host localhost e a porta 5432. Quando é executado esse comando, aparece algumas informações interessantes que traz relação ao que falamos anteriormente:

2022/03/22 14:56:54 Rlimits for file descriptors set to {Current = 8500, Max = 524288}
2022/03/22 14:56:55 Listening on 127.0.0.1:5432 for projecttest-1235:us-central1:my-cloudsql-instance
2022/03/22 14:56:55 Ready for new connections
2022/03/22 14:56:55 Generated RSA key in 86.817487ms

Isso significa que a instância está disponível. Agora se tentarmos uma conexão ao banco de dados, utilizando o cliente da mesma ferramenta, que no nosso caso seria o psql, e passasse os dados necessários como o nome do banco, host, porta e credenciais, ele vai gerar o certificado efêmero e finalizar a comunicação para finalmente acessar a base:

psql -U postgres -h 0.0.0.0 -p 5432 -d my-database

2022/03/22 14:57:06 New connection for "projecttest-1235:us-central1:my-cloudsql-instance"
2022/03/22 14:57:06 refreshing ephemeral certificate for instance projecttest-1235:us-central1:my-cloudsql-instance
2022/03/22 14:57:07 Scheduling refresh of ephemeral certificate in 54m59.591751748s

Além da sua aplicação, vamos precisar de uma imagem que possua o binário cloud_sql_proxy, como a imagem gcr.io/cloudsql-docker/gce-proxy.

Abaixo vamos fazer a execução e o bind via adhoc com o comando docker como exemplo:

docker run -d \
    -v PATH_TO_KEY_FILE:/config \
    -p 127.0.0.1:5432:5432 \
    gcr.io/cloudsql-docker/gce-proxy:1.32.0 /cloud_sql_proxy \
    -instances=INSTANCE_CONNECTION_NAME=tcp:0.0.0.0:5432 \
    -credential_file=/config

Seguindo essa mesma premissa, vamos preparar o docker-compose.yaml

version: "3.8"
services:
  app:
    # ...

  database:
    container_name: "cloud-sql-proxy"
    image: gcr.io/cloudsql-docker/gce-proxy:1.32.0
    volumes:
      - ./serviceAccount.json:/config
    ports:
      - 5432:5432
    command: "/cloud_sql_proxy -instances=project-12e2:us-central1:database-instance=tcp:0.0.0.0:5432 -credential_file=/config"

Tópicos e Partições

O Kafka oferece binários para podemos efetuar operações nele, e uma delas é relacionado aos tópicos. Um tópico é nada mais que um fluxo de dados nomeado, e esse tópico armazena logs e são distribuídos e particionados, ou seja, divididos em pequenas partes. Pense no tópico como uma categoria ou um feed em que os registros são publicados.

Cada partição possui uma sequência ordenada e imutável, que é continuamente anexado (appended) para uma estrutura de log. Como pode ver na imagem acima, cada registro na partição tem um número sequencial atribuído, chamado de offset, que identifica unicamente cada registro da partição.

O cluster Kafka persiste todos os registros publicados, mesmo sendo consumidos ou não, usando uma configuração de retenção. Por exemplo, se na configuração foi setada que a política de retenção é de dois dias, então dentro desse período os registro serão inseridos nos tópicos e mantidos. Caso passe dos dois dias, eles serão descartados.

Uma característica interessante do Kafka é também armazenar metadados por consumer, que são o deslocamento ou a posição dele no log. Veja a imagem abaixo:

Esse offset é controlado pelo consumer, então ele avança linearmente para consumir os registros, mas se ele quiser resetar esse metadado para reprocessar os dados ele pode, ou pular para o registro mais recente e começar a consumir a partir de "agora", isso é possível.

Operações nos Tópicos

Por meio do kafka-topics podemos criar, listar, alterar e remover tópicos quando necessário. Abaixo vamos mostrar como efetuar cada operação, e os detalhes de cada parâmetro podemos explicar mais a frente.

Criando um tópico

$ kafka-topics --zookeeper 127.0.0.1:2181 --create --topic first_topic --partition 3 --replication-factor 1

A sáida deve ser parecida com essa:

Created topic "first_topic"

Se tentar criar um tópico com o mesmo nome, o Kafka não vai autorizar porque cada nome de tópico é único. Será preciso removê-la para criar outro com o mesmo nome.

Listando tópicos

$ kafka-topics --zookeeper 127.0.0.1:2181 --list

A saída deve ser parecida com essa:

__consumer_offsets
logs-broker
first_topic

Removendo tópicos

$ kafka-topics --zookeeper 127.0.0.1:2181 --topic first_topic --delete

A saída deve ser parecida com essa:

Topic first_topic is marked for deletion
Note: This will have no impact if delete.topic.enable is not set to True

O tópico não é removido se:

• Possuir producers vinculados
• Possuir consumers vinculados
• Tiver registros salvos

Uma das formas de remover definitivamente é reiniciando e removendo fisicamente o diretório do tópico.

Detalhando tópico

$ kafka-topics --zookeeper 127.0.0.1:2181 --topic first_topic --describe

A saída deve ser parecida com essa:

Topic:first_topic       PartitionCount:3        ReplicationFactor:1     Configs:
        Topic: first_topic      Partition: 0    Leader: 0       Replicas: 0     Isr: 0
        Topic: first_topic      Partition: 1    Leader: 0       Replicas: 0     Isr: 0
        Topic: first_topic      Partition: 2    Leader: 0       Replicas: 0     Isr: 0

Enviando mensagens com Producers

Vamos fazer o primeiro envio de mensagens ao tópico que acabamos de criar na seção anterior. O Kafka possui um script chamado de kafka-console-producer.sh em que faz o papel de um producer. Abaixo está o comando que vamos executar para enviar um texto de exemplo:

$ kafka-console-producer.sh --broker-list localhost:9092 --topic first_topic
This is a message
This is another message

Quando damos enter no comando, ele abre a comunicação no terminal, para receber o conteúdo e assim enviar ao tópico. a cada texto inserido seguindo de será uma mensagem enviada, então no exemplo acima foi enviado duas informações.

Consumindo mensagens com Consumers

Vamos seguir a mesma idéia, só que para o consumo das mensagens enviadas. No mesmo diretório de binários do Kafka, tem o script kafka-console-consumer.sh em que atua como um consumidor de um determinado tópico. O comando abaixo exemplifica o acesso as mensagens do tópico _firsttopic:

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --from-beginning
This is a message
This is another message

Ele abre também a comunicação no terminal, só que para a saída padrão. O comando pediu para o Kafka consumir as mensagens do tópico desde o início. Isso é importante porque o consumer pode escolher acessar as informações da seguinte forma:

• Início do tópico (earliest): Consome as mensagens partindo do offset 0 de todas as partições, ou de uma específica
• Fim do tópico (latest): Consome as mensagens partindo do último offset de todas as partições ou de uma específica
• Offset específico: Consome mensagem de um offset ID específico que foi definido pelo consumidor, então nesse caso precisa saber o seu índice.

Vamos mostrar alguns exemplos:

• Consumindo a partir do offset inicial, de todas as partições

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --offset earliest
This is a message
This is another message

• Consumindo a partir do offset inicial, de uma partição específica

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --partition 0 --offset earliest
This is a message

• Consumindo a partir do offset final, de todas as partições

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --offset latest
Message sended after the two first

• Consumindo a partir do offset final, de uma partição específica

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --partition 1 --offset latest
This is another message
Message sended after the two first

• Consumindo a partir de um offset específico (índice 1)

$ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic first_topic --offset 1
This is another message

Com as informações abordadas aqui, já podemos fazer uso da ferramenta para atuar como broker de mensagens. No terceiro post vamos aprofundar sobre os Consumer Groups, e como isso é importante no consumo de grande volume de dados.

O que é o Apache Kafka?

O Apache Kafka é uma plataforma de streaming de eventos distribuída, ou seja, ele possui três capacidades chave:

• Faz publish e subscribe de streaming de dados, simular a uma fila de mensagens ou sistema de mensageria enterprise.
• Armazena streaming de dados em um modo fault-tolerant (tolerante a falhas)
• Processa stream de dados

Ele é geral usado para dois tipos de aplicações:

• Construção de pipeline de streaming de dados em tempo real que precisa de dados confiáveis entre sistemas ou aplicações
• Construção de aplicações em tempo real que transforma ou reage com o fluxo de dados
• Arquiteturas de microserviços que faz uso de um sistema de mensageria para a comunicação entre os módulos de uma aplicação dessa modalidade, e que precisa de uma alta velocidade.

Fonte: https://www.confluent.io/what-is-apache-kafka/

Arquitetura Pub/Sub

O Kafka segue a arquitetura de mensageria no estilo Publisher/Consumer, em que um componente publica uma mensagem em uma fila chamado de tópico a um intermediário e um outro componente consome essa mensagem a partir do intermediário, no tópico que essa informação está. Essas mensagens não são direcionadas a determinados consumidores, então para que eles possam acessar os dados eles se inscrevem nessa fila do intemediário para aguardarem novas informacões.

• Publisher: responsável por publicar as mensagens a um broker
• Broker: intermediário entre um Publisher e Consumer, que no nosso caso é o Kafka
• Tópico: Recurso nomeado para qual as mensagens são enviadas
• Consumer: responsável por consumir as mensagens de um determinado tópico

Fonte: https://www.cloudkarafka.com/blog/2016-11-30-part1-kafka-for-beginners-what-is-apache-kafka.html

Instalação e Configuração

O Kafka precisa do Apache Zookeeper para coordenar os brokers do Kafka, principalmente quando envolve múltiplos brokers em um ambiente clusterizado. Então siga as instruções de instalação do Zookeeper antes de seguir nos procedimentos abaixo.

• Faça o download do Apache Kafka e descompacte no diretório desejado. No nosso caso tanto o Zookeeper como o Kafka estará no /opt:

$ cd /opt
$ wget https://www-eu.apache.org/dist/kafka/2.2.1/kafka_2.11-2.2.1.tgz
$ tar -zxvf kafka_2.11-2.2.1.tgz
$ mv kafka_2.11-2.2.1 kafka

• Inicie o servidor Zookeeper caso não tenha feito, e após isso inicie o servidor do Kafka:

# Iniciando Zookeeper

$ cd /opt/zookeeper
$ ./bin/zkServer.sh start

# Iniciando Kafka

$ cd /opt/kafka
$ ./bin/kafka-server-start.sh config/server.properties

Para confirmar se estão de pé, verifique se na sua máquina tem as seguintes portas abaixo:

$ netstat -tlpn | grep -E "2181|9092"
tcp6       0      0 :::9092                 :::*                    OUÇA       6531/java
tcp6       0      0 :::2181                 :::*                    OUÇA       6498/java

A porta 2181 é do Apache Zookeeper e o 9092 é a porta padrão do Apache Kafka.

Conceitos do Kafka

Ele possui alguns conceitos que são relevantes saber:

• Kafka é executado como um cluster de um ou mais servidores que pode abranger para múltiplos datacenters
• Esse cluster armazena fluxos de dados em categorias chamados de topics.
• Cada registro consistem de uma chave, um valor e um timestamp.

Ele é composto por quatro APIs:

• O Producer API faz com que uma aplicação possa publicar um fluxo de registros para um ou mais tópicos Kafka
• O Consumer API faz com que a aplicação possa assinar um ou mais tópicos e processar o fluxo de registros produzidos por alguém.
• O Streams API faz com que a aplicação possa atuar como um stream processor, consumindo um fluxo de entrada (input stream) de um ou mais tópicos e produzir um fluxo de saída (output stream) para um ou mais tópicos, transformando de forma eficiente.
• O Connector API permite construir e executar producers ou consumers reutilizáveis que conecta tópicos a aplicativos ou sistemas de dados existentes. Por exemplo, um conector para um banco relacional captura cada mudança de uma tabela.

A comunicação entre os clientes e servidores é feito de forma simples e com alta performance, usando o protocolo TCP. Além disso, o Kafka provêm um cliente Java, mas tem disponíveis outros clientes para várias linguagens.

Fonte: https://kafka.apache.org/intro

No próximo post, vamos falar mais sobre os tópicos e qual é a idéia das partições no Kafka. Além disso vou mostrar como podemos criar, alterar e remover tótpicos, como também atuar na ação de publicar e consumir mensagens de um tópico, e como fazemos com que mais de um consumer possa acessar o tópico sem buscar dados duplicados, por meio de consumer group.

Até mais! ;)

Preparando o ambiente

Antes de mais nada vamos deixar tudo pronto para podemos fazer isso, tanto no ambiente local como no Heroku. Primeiro você precisa ter os requisitos abaixo para conseguir seguir tudo o que está aqui sem problemas:

• Heroku Toolbelt
• Python 3
• Virtualenv

Se está com os itens acima, vamos começar. Primeiro crie um ambiente virtual para instalarmos as dependências necessárias:

$ mkdir airflow-heroku && cd airflow-heroku
$ python3.6 -m venv .venv

Ative o ambiente e instale as dependências. Não esqueça de salvar no arquivo requirements.txt para que o Heroku saiba o que instalar:

$ source .venv/bin/activate
$ pip install "apache-airflow[postgres,password]" cryptography
$ pip freeze > requirements.txt

Agora precisamos usar o airflow init para criar os arquivos necessários para executarmos o ambiente localmente. O que vamos precisar mais na frente para o deploy é o arquivo airflow.cfg:

$ export AIRFLOW_HOME=$PWD  # Definindo a raiz do airflow na pasta corrente
$ airflow initdb

O airflow irá criar vários arquivos e pastas como o exemplo abaixo:

.
├── airflow.cfg
├── airflow.db
├── logs
└── unittests.cfg

Vamos aproveitar o momento e preparar o repositório do projeto, como também incluir os arquivos que não serão versionados:

$ git init
$ cat <<EOF >> .gitignore
*.pyc
*.db
.venv/
logs/
EOF

Observação: Ao executar com Python 3.7, pode ocorrer de aparecer a seguinte saída:

ERROR [airflow.models.DagBag] Failed to import: /tmp/airflow-heroku/.venv/lib/python3.7/site-packages/airflow/example_dags/example_http_operator.py
Traceback (most recent call last):
  File "/tmp/airflow-heroku/.venv/lib/python3.7/site-packages/airflow/models.py", line 377, in process_file
    m = imp.load_source(mod_name, filepath)
  File "/home/gilson/.pyenv/versions/3.7.1/lib/python3.7/imp.py", line 171, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 696, in _load
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/tmp/airflow-heroku/.venv/lib/python3.7/site-packages/airflow/example_dags/example_http_operator.py", line 27, in <module>
    from airflow.operators.http_operator import SimpleHttpOperator
  File "/tmp/airflow-heroku/.venv/lib/python3.7/site-packages/airflow/operators/http_operator.py", line 21, in <module>
    from airflow.hooks.http_hook import HttpHook
  File "/tmp/airflow-heroku/.venv/lib/python3.7/site-packages/airflow/hooks/http_hook.py", line 23, in <module>
    import tenacity
  File "/tmp/airflow-heroku/.venv/lib/python3.7/site-packages/tenacity/__init__.py", line 352
    from tenacity.async import AsyncRetrying
                      ^
SyntaxError: invalid syntax

Mesmo assim os arquivos serão criados e será executado sem problemas. O erro acontece por conta de uma DAG de exemplo.

Por fim, crie o arquivo generate_fernet_key.py e insira na pasta contrib. Ela irá gerar uma chave para que o Airflow use para encriptação de dados sensíveis. Insira o conteúdo abaixo no módulo citado:

#!/usr/bin/env python

from cryptography import fernet

print(fernet.Fernet.generate_key().decode("utf-8"))

Dessa forma que preparamos o ambiente, já podemos criar as DAGS e fazer o teste rodando localmente.

Tornando o ambiente mais semelhante ao de produção

Mesmo o heroku oferecendo toda a facilidade de implantação, é uma boa ter localmente o ambiente minimamente parecido com o que as suas DAGs serão executados. Vamos fazer algumas mudanças no arquivo airflow.cfg

O arquivo airflow.cfg apesar de versionarmos, será usado mais para uso local, então aproveite para deixar o ambiente mais próximo da produção como:

• Definir um banco relacional para o Airflow como PostgreSQL
• Registrar o tipo de executor adequado para rodar as DAGS
• Gerar uma chave com Fernet por meio do generate_fernet_key.py

Faça a alteração no arquivo de configuração para inserir informações acerca do banco de dados e o tipo de executor desejado que o Airflow irá usar para executar o agendamento dos workflows:

# ...
sql_alchemy_conn = postgresql+psycopg2://postgres:postgres@localhost:5432/airflow

# ...
executor = LocalExecutor

# ...
fernet_key = $(python "contrib/generate_fernet_key.py")

Dessa forma o Airflow irá usar o banco PostgreSQL para armazenar os metadados das DAGs e suas execuções como o também o seu scheduler.

Remova o arquivo airflow.db e rode novamente o airflow initdb para que as migrations do airflow seja aplicados no banco.

Configurando projeto para o Heroku

Agora vamos fazer algumas mudanças para que o Airflow seja executado corretamente no Heroku, juntamente com um usuário para acessar o painel de administração da ferramenta.

No caso do Heroku vamos aproveitar o uso de variávels de ambiente para sobrescrever propriedades do Airflow. Faça uso do config:set. Lembre-se de criar o app e os addons necessários:

$ heroku apps:create heroku-airflow
$ heroku addons:create heroku-postgresql:hobby-dev

$ heroku config:set SLUGIFY_USES_TEXT_UNIDECODE=yes
$ heroku config:set AIRFLOW_HOME="/app"
$ heroku config:set AIRFLOW__CORE__DAGS_FOLDER="/app/dags"
$ heroku config:set AIRFLOW__CORE__FERNET_KEY=`python contrib/generate_fernet_key.py`
$ heroku config:set AIRFLOW__CORE__LOAD_EXAMPLES=False
$ heroku config:set AIRFLOW__CORE__SQL_ALCHEMY_CONN=`heroku config:get DATABASE_URL`
$ heroku config:set AIRFLOW__CORE__EXECUTOR="LocalExecutor"

Crie o arquivo Procfile para o Heroku inicializar a aplicação corretamente:

release: airflow initdb
web: airflow webserver -p $PORT --daemon && airflow scheduler

Agora vamos versionar e enviar os arquivos para o Heroku:

$ git add .
$ git commit -m "Arquivos para o ambiente Airflow"
$ git push heroku master

Com isso conseguimos fazer com que o Airflow execute no ambiente:

Mas como pode perceber, deixar aberto o painel dessa forma não é seguro. Vamos tornar mais seguro.

Inserindo autenticação no Airflow

Vamos inserir uma nova variável de ambiente para que o Airflow invoque a autenticação:

heroku config:set AIRFLOW__WEBSERVER__AUTHENTICATE=True
heroku config:set AIRFLOW__WEBSERVER__AUTH_BACKEND="airflow.contrib.auth.backends.password_auth"

Reinicie o seu dyno, e então vai encontrar uma página parecida com a imagem abaixo, se seguiu os procedimentos corretamente:

Agora que está preparado para autenticar, vamos criar um novo usuário. Acesse o shell do Python no Heroku com heroku run python e execute os comandos abaixo:

import airflow
from airflow import models, settings
from airflow.contrib.auth.backends.password_auth import PasswordUser

user = PasswordUser(models.User())
user.username = 'admin'
user.email = 'me@gilsondev.in'
user.password = 'password'

session = settings.Session()
session.add(user)
session.commit()
session.close()
exit()

Com usuário criado, se autentique com o seu username e senha e então irá acessar o painel administrativo novamente.

E pronto! Temos um airflow preparado no Heroku para receber suas DAGs.

Bônus: Inserindo sua primeira DAG

Para fechar bem o post, vamos inserir uma DAG de exemplo para entenderem como usar no Airflow. Crie uma pasta dags na raiz do projeto e crie dentro dele um módulo chamado tutorial_dag.py:

"""
Code that goes along with the Airflow tutorial located at:
https://github.com/apache/incubator-airflow/blob/master/airflow/example_dags/tutorial.py
"""
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime, timedelta


default_args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'start_date': datetime(2015, 6, 1),
    'email': ['airflow@example.com'],
    'email_on_failure': False,
    'email_on_retry': False,
    'retries': 1,
    'retry_delay': timedelta(minutes=5),
    # 'queue': 'bash_queue',
    # 'pool': 'backfill',
    # 'priority_weight': 10,
    # 'end_date': datetime(2016, 1, 1),
}

dag = DAG('tutorial', default_args=default_args, schedule_interval=timedelta(days=1))

# t1, t2 and t3 are examples of tasks created by instantiating operators
t1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag)

t2 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    retries=3,
    dag=dag)

templated_command = """
    {% for i in range(5) %}
        echo "{{ ds }}"
        echo "{{ macros.ds_add(ds, 7)}}"
        echo "{{ params.my_param }}"
    {% endfor %}
"""

t3 = BashOperator(
    task_id='templated',
    bash_command=templated_command,
    params={'my_param': 'Parameter I passed in'},
    dag=dag)

t2.set_upstream(t1)
t3.set_upstream(t1)

Vamos aproveitar o código que está no tutorial da documentação do Airflow para focarmos no funcionamento. Faça o versionamento dessa nova DAG e envie para o heroku:

$ git add .
$ git commit -m "Inserção da primeira DAG"
$ git push heroku master

Agora acesse novamente o seu Airflow que você verá a DAG que acabamos de criar:

E agora ativando o schedule da DAG, já começou sua execução:

Depois de vários passos, agora temos um Airflow preparado para usar no Heroku.

Até mais pessoal!

Depois de pesquisar um pouco sobre isso na documentação, encontrei uma forma de lidar com isso sem afetar o funcionamento real da aplicação. Mas como assim?

Como os unmanaged models funciona?

Todos os modelos que você cria no seu projeto Django, por padrão eles são managed, ou seja, o django irá criar a tabela no banco de dados apropriadamente, baseando no que o modelo representa. Segue um exemplo:

class Question(models.Model):
    text = models.TextField()

Segue um modelo bem simples, mas que ele diz muita coisa para a ORM poder criar uma tabela como definida abaixo:

CREATE TABLE app_question(
    id int not null,
    text text not null,
    PRIMARY KEY(id)
);

Caso for executar esse SQL em um banco que respeite o ANSI SQL, ela será criada. O django faz essa conversão por debaixo dos panos e preparar para a criação por meio das migrations. Você que conhece o framework sabe como funciona.

Agora pode ocorrer de a gestão desses objetos do banco de dados, como as tabelas, já existam ou são controladas fora do framework, por inúmeros motivos, e por isso não faz sentido o Django criá-las senão o encontrará problemas, sendo que não tem como ter tabelas duplicadas. Dessa forma o framework oferece no Meta do seu modelo a propriedade managed. Se você definir como False, ela não será responsável pela criação, alteração e remoção da tabela que o modelo se espelha.

O caso comum de uso de modelos não-gerenciáveis é quando precisa usar um banco de dados legado em que sua aplicação Django precisará acessar. O comando inspectdb do manage.py é um ótimo auxílio para fazer o parser das tabelas desse banco para classes de modelo. Se nunca usou, recomendo que faça um teste e acredito que vai ser bem útil um dia.

Classes não-gerenciáveis e os testes

Por não serem gerenciáveis pelo Django, não quer dizer que não vai poder:

• Inserir/alterar/remover registros
• Efetuar consultas nos registros

Mas como disse antes, não poderá criar/alterar/remover a tabela. Quando você faz testes automatizados no Django e isso envolver modelos, ao rodar os testes o comportamento do framework é:

• Criar tabelas no banco de testes usando as migrations (default em SQLite: test_nome_do_banco.sqlite)
• Prepara o suite de testes
• Faz o uso do método setUp
• Executa os testes automatizados
• Se for usado os modelos para criar dados fake, insere na tabela recém criada
• Faz o uso do método tearDown
• Remove os registros criados nos testes
• Elimina o suite de testes
• Remove as tabelas do banco de dados de teste

Esse passo a passo foi descrito de forma bem grosseira, mas no geral é como funciona. O problema é que no caso de modelos não-gerenciados não irá funcionar porque se for criar dados fake com o modelo, vai dar erro dizendo que a tabela não existe e que o modelo não autoriza o Django a criar a tabela. Como lidar com isso?

Uma abordagem simples

Buscando alternativas de lidar com isso encontrei uma solução que é alterar o valor do managed no teste ou criar um TestRunner para isso. Se um o outro vai ser melhor, vai depender do problema que quer resolver, mas a primeira é a mais prática.

Como assim? Digamos que temos um modelo não gerenciado que queremos testar:

class LegacyTable(models.Model):
    id = models.PositiveIntegerField(primary_key=True, db_column="cod_legacy")
    name = models.CharField(max_length=255, db_column="txt_name")

    class Meta:
        db_table = "legacy_table"
        managed = False

Criando ele e rodar o makemigrations para o app que o modelo está, irá criar uma migração parecido com essa:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations, models


class Migration(migrations.Migration):

    dependencies = []

    operations = [
        migrations.CreateModel(
            name='LegacyTable',
            fields=[
                ('id', models.PositiveIntegerField(db_column='cod_legacy', primary_key=True, serialize=False)),
                ('name', models.CharField(db_column='txt_name', max_length=255)),
            ],
            options={
                'db_table': 'legacy_table',
                'managed': False,
            },
        ),
    ]

O que podemos fazer é definir uma variável no nosso settings.py para que caso formos rodar testes automatizados ele esteja como True:

# settings.py

# ...
DEBUG = True
TESTING = True

E com isso alteramos a migração para ficar assim:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations, models
from django.conf import settings


class Migration(migrations.Migration):

    dependencies = []

    operations = [
        migrations.CreateModel(
            name='LegacyTable',
            fields=[
                ('id', models.PositiveIntegerField(db_column='cod_legacy', primary_key=True, serialize=False)),
                ('name', models.CharField(db_column='txt_name', max_length=255)),
            ],
            options={
                'db_table': 'legacy_table',
                'managed': settings.TESTING,
            },
        ),
    ]

Dessa forma, quando rodarmos manage.py test app a suíte de testes irá considerar como um modelo convencional, criará a tabela no banco que será usado nos testes, e assim poderemos criar os dados fake perfeitamente. Claro que ao rodar em ambiente que não irá precisar desse tipo de situção, a propriedade TESTING precisa estar False.

Com isso conseguimos criar testes perfeitamente sem precisar fazer customizações malucas. Quem tiver outras soluções, coloque aqui nos comentários!

Até mais!

Um exemplo disso:

• Migrar dados de uma tabela para outra
• Importar dados a partir de várias fontes e juntar em uma única base
• Seguir o passo acima e trabalhar com tratamento e filtragem das informações

Entre várias outras necessidade, mas no final acabamos tendo algo em comum que é definir um workflow, em que será composto por várias etapas para alcançarmos um objetivo, seja unificar, seja tratar, etc. Nesse post vamos falar do Apache Airflow, que é uma ferramenta opensource e que nos auxilia nesses tipos de situações.

O que é o Airflow?

Ela foi criada pelo time de desenvolvedores do AirBnB, com o intuito de definir fluxos de trabalho que envolve consulta de dados de inúmeras fontes, tratamento e mineração de dados, de forma que possa ser feito de forma periódica ou não, ou seja, uma pipeline de dados. Ela se tornou open source em meados de 2015, sendo divulgado por um post no blog aonde os engenheiros e cientistas de dados da empresa compartilham suas experiências. Depois de algum tempo, ela foi cedida para o Apache em que se tornou um dos inúmeros projetos que ela mantém, hoje chamado de apache-airflow.

Instalação e configuração minima

Vamos preparar o ambiente e criar o primeiro workflow para entender como funciona. Primeiramente, vamos criar um ambiente virtual para instalarmos a ferramenta, então sugiro que use Python 3:

$ mkdir airflow-tutorial
$ cd airflow-tutorial
$ python3 -m venv .venv
$ source .venv/bin/activate

Instale o airflow usando pip:

(.venv)$ pip install apache-airflow

Conforme a documentação, após a instalação é necessário definirmos a raiz para que possa ser gerado toda a base do airflow em que será usado.

# Definindo o diretório airflow-tutorial como raiz do Airflow
$ export AIRFLOW_HOME=$PWD

Agora vamos gerar o ambiente com o comando abaixo.

(.venv)$ airflow initdb

Esse comando irá criar os arquivos necessários para o Airflow, e rodar as migrações em um banco SQLite, em que ele armazena os metadados dos workflows. Para uso local e didático, com esse tipo de banco é o suficiente, mas tem outros procedimentos para preparar o seu uso em produção. Outra observação: não se preocupe com o pedido do módulo cryptography. Isso não vai afetar na experiência, isso é importante quando precisa encriptar algumas informações que não é o caso levantar agora, mas o seu uso real é necessário.

Vamos criar uma pasta chamada dags, em que vamos armazenar os fluxos implementados. Mais na frente irei explicar melhor:

(.venv)$ mkdir dags

Após preparar tudo, vamos iniciar o servidor local para vermos o painel administrativo da ferramenta.

(.venv)$ airflow webserver

Agora é acessar o http://localhost:8080. Feito isso você vai ver algo parecido com isso:

Nessa página ele lista todos os workflows instalados, e que nesse caso são os exemplos que vem com a ferramenta, em que mostra várias formas de construir a sua pipeline. O bacana de usar pela interface é que pode ter um controle das execuções e o histórico de cada um deles, como qual etapa do fluxo falhou acompanhado de um log de execução, mas essa não é a única forma de usar, temos também a opção de linha de comando que veremos em breve nesse post.

Criando nosso primeiro workflow

Agora com tudo pronto, vamos criar nosso exemplo. Vamos supor que precisamos fazer o fluxo abaixo:

1. Imprimir a data na saída padrão
2. Definir um sleep de 5 segundos
3. Salvar a data em um arquivo texto

A idéia é que ele seja executado diariamente, e que não seja cíclico. Outro ponto importante, é que a próxima etapa será executada se a anterior teve êxito no que foi criada a fazer após o seu processamento.

Explicando a estrutura de uma DAG

Essa estrutura que preparamos, para o Airflow é chamada de DAG:

DAG = Directed Acyclic Graph

É um grafo acíclico, em que todas as tarefas que são executadas e organizadas de uma forma que reflete os seus relacionamentos e dependências. Você pode definir que um determinado nó deve ser executado se a anterior for um sucesso ou não, ou que o nó A terá um timeout de 5 minutos, e o nó B pode ser reiniciado até 5 vezes caso não tenha sucesso.

Dessa forma cada arquivo python armazena uma DAG, e ela é reconhecida pelo Airflow para sua execução na pasta dags que criamos anteriormente. Você pode mudar o caminho dessa pasta, alterando as configurações da ferramenta.

Vamos ao código

Explicado como é um workflow para o Airflor, vamos criar a DAG do nosso exemplo.

Preparando a DAG

Crie um novo arquivo chamado de fluxo_simples.py na pasta dags e implemente o código abaixo:

import airflow

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import, timedelta

args = {
    'owner': 'airflow',
    'start_date': airflow.utils.dates.days_ago(2)
}

dag = DAG(
    dag_id='fluxo_simples',
    default_args=args,
    schedule_interval=timedelta(days=1),
    dagrun_timeout=timedelta(minutes=60)
)

O que fizemos aqui é preparar a criação da DAG em que ela possui algumas definições iniciais:

• Possui um ID único chamado de _fluxosimples: dag_id
• Recebe argumentos padrão e que reflete nos nós do grafo: defaul_args
• Define a periodicidade de execução. Nesse caso é diária: schedule_interval
• Define o tempo em que a DAG terá antes de ser interrompida: dagrun_timeout

A variável dag será necessária para vincular os nós que vamos criar.

Criando os nós do fluxo

Continuando, no mesmo arquivo vamos criar os nós, baseado na estrutura que definirmos no exemplo:

# (...)
# Depois da preparação da DAG

# 1. Imprime a data na saída padrão
task1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag)

# 2. Faz uma sleep de 5 segundos.
# Dando errado tente em no máximo 3 vezes
task2 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    retries=3,
    dag=dag)

# 3. Salve a data em um arquivo texto
task3 = BashOperator(
    task_id='save_date',
    bash_command='date > /tmp/date_output.txt',
    retries=3,
    dag=dag)

Com isso temos a DAG pronta. Criamos três tarefas em que cada uma delas é representado por um nó do nosso grafo e são criadas a partir de Operators, que são classes Python que oferece variados tipos de processamento. Aqui estamos usando do tipo BashOperator em que iremos executar comandos bash no console, passados no argumento bash_command. Cada tarefa criada também tem um ID único, então caso crie outro com o mesmo identificador, o Airflow vai gerar um erro antes de executá-la. Além disso, vinculamos as tarefas a dag criada através do argumento dag.

Por fim, precisamos definir a interligação dos nós e sua ordem de execução:

# Interligando task1 ao task2
task1.set_downstream(task2)

# Interligando task2 ao task3
task2.set_downstream(task3)

Cada tarefa instanciada possui métodos para fazer ligação entre eles. No exemplo acima, usamos o set_downstream para definir que será a próxima tarefa a interligar no nó em questão. Temos também o set_upstream que define quem será o nó anterior. Segue a imagem para ficar mais claro a ligação:

Os operators são importantes para a definição das DAGS. Abaixo segue alguns que a ferramenta disponibiliza:

• BashOperator: executa comandos shellscript
• DummyOperator: cria um nó que não executa nada, somente para representação
• EmailOperator: envia e-mail
• HdfsOperator: aguarda por um arquivo ou pasta no HDFS
• HiveOperator: executa código hql em um banco de dados Hive específico
• SimpleHttpOperator: faz uma requisição de um endpoint HTTP
• MySqlOperator: executa códigos SQL em um banco MySQL
• PostgresOperator: executa códigos SQL em um banco PostgreSQL
• PythonOperator: executa um código callable em Python

Isso são alguns dos vários operators disponíveis, como existem outros operators criados e mantidos pela comunidade.

Agora é executar

Com a nossa DAG totalmente finalizada, vamos testar executando na linha de comando:

(.venv)$ airflow backfill fluxo_simples -s 2018-06-09

Com isso, através do identificador que passamos via parâmetro ele irá localizar a DAG e executar todo o nosso fluxo. A data é importante para saber a data inicial da execução. Você vai ver várias saídas no console, como qual a tarefa que está alocada no momento para executar, o seu processamento e saída gerada, entre outras informações que consegue acessar também pelo Painel Administrativo. Abaixo vou colocar alguns trechos que faz sentido para o nosso tutorial:

[2018-06-09 12:14:36,996] {base_task_runner.py:98} INFO - Subtask: [2018-06-09 12:14:36,996] {bash_operator.py:97} INFO - Output:
[2018-06-09 12:14:36,997] {base_task_runner.py:98} INFO - Subtask: [2018-06-09 12:14:36,997] {bash_operator.py:101} INFO - Sáb Jun 09 12:14:36 -03 2018

Aqui ele executa o comando date e traz o resultado para a saída padrão.

[2018-06-09 12:14:53,475] {base_task_runner.py:98} INFO - Subtask: [2018-06-09 12:14:53,475] {bash_operator.py:88} INFO - Running command: date > /tmp/date_output.txt
[2018-06-09 12:14:53,477] {base_task_runner.py:98} INFO - Subtask: [2018-06-09 12:14:53,477] {bash_operator.py:97} INFO - Output:
[2018-06-09 12:14:53,479] {base_task_runner.py:98} INFO - Subtask: [2018-06-09 12:14:53,479] {bash_operator.py:105} INFO - Command exited with return code 0

E por aqui mostra que a execução do date e o resultado salvo em um arquivo foi feito com sucesso. Se for fazer um cat no arquivo gerado vai encontrar algo parecido:

(.venv)$ cat /tmp/date_output.txt
Sáb Jun 09 12:14:53 -03 2018

Alguns comandos interessantes

Outros comandos que pode acabar usando na linha de comando:

Disparar a execução de uma DAG para que possa preparar o agendamento, caso isso esteja habilitado:

$ airflow trigger_dag fluxo_simples -e 2018-06-10

Testar uma tarefa específica, ao invés de toda a DAG:

$ airflow test fluxo_simples print_date 2018-06-09

Nesse caso ele se basea em alguma configuração específica para testes no arquivo unittest.cfg e que não precisa usar alguma configuração no airflow.cfg.

Caso queira saber o status da execução de uma DAG:

$ airflow dag_state fluxo_simples 2018-06-09

Executar uma tarefa específica, ao invés de toda a DAG:

$ airflow run fluxo_simples print_date 2018-06-09

Listar todas as tarefas de uma DAG:

$ airflow list_tasks fluxo_simples

Listar todas as DAGS disponíveis:

$ airflow list_dags

Iniciar uma instância de scheduler. Isso vamos aprofundar quando abordarmos sobre os Executors do airflow. Aqui fica a título de curiosidade, ele é importante para verificar quais as próximas DAGS que estão perto de serem iniciadas a partir do que configurou na sua periodicidade:

$ airflow scheduler

Limpar o conjunto de instâncias de tarefas de uma DAG, como se nunca tivesse sido executado:

$ airflow clear fluxo_simples

Visualizando no Painel

Agora vamos verificar como conseguimos acessar as informações da nossa DAG no Painel Administrativo. Com o airflow webserver executado, você deverá visualizar algo parecido das imagens abaixo:

1. Página inicial do Painel, contendo a lista das dags e a nossa no final. Ela mostra a quantidade de vezes que teve sucesso e falha na DAG inteira, como na quantidade de tarefas.

1. Podemos ver abaixo a linha com a nossa DAG. Quando executei estava com o nome tutorial, mas não é nada diferente do que fizemos nesse post:

Explicando cada tipo de estado e a quantidade em que cada DAG e tarefa o Airflow registrou:

1. Clicando no nome da DAG, temos mais detalhes dela, como diferentes formas de visualizar todo os metadados gerados durante seu processamento.

Visão em árvore

Visão em grafo

Visão por tarefa e sua duração

Visão em Gantt da execução das tarefas

Visão do código da DAG

E agora?

Esse post procurou trazer uma visão geral do Airflow, e o potencial que ele tem para auxiliar em automatização de fluxos de trabalho em geral.

Espero que tenham gostado. Quaisquer dúvidas e sugestões comentem embaixo e vamos trocar idéias.

Até mais!

Nesse post vamos supor que temos um pequeno projeto em Django, e precisamos definir um valor de configuração para o arquivo settings.py. Para isso vamos importar a função config do pacote para procurar o valor em uma variável nos arquivos que ele busca.

Ele basicamente passa a ler informações de configuração em arquivos .env ou com a extensão .ini. Caso a variável definida não encontrar, ele usa um valor padrão, se definido. Abaixo segue um pequeno exemplo pego no README do projeto:

from decouple import config

Usamos a função para recuperar os valores:

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', default=False, cast=bool)
EMAIL_HOST = config('EMAIL_HOST', default='localhost')
EMAIL_PORT = config('EMAIL_PORT', default=25, cast=int)

Assim, se no arquivo .env ou um .ini tenha uma variável SECRET_KEY, então ele irá atribuir o valor ao existente no arquivo de configuração da aplicação. Para mais detalhes da aplicação, veja o README do projeto.

Usando integração contínua

Para quem usa serviços de integração contínua, é necessário colocar configurações da aplicação para que possa executar o trabalho desejado, que normalmente é executar os testes automatizados para caso todos passarem, efetuar uma segunda ação (enviar cobertura, efetuar deploy em um PaaS, etc). Aqui, com o Travis CI, caso queiramos definir valores de configuração, a boa prática é não colocar no código, mas em variáveis de ambiente. No caso do Travis CI, podemos fazer da seguinte forma:

language: python
 python:
   - "3.5"
 global:
   -DEBUG=False
   -SECRET_KEY="vg$ita%40wm=q1h4sr2jf+zjzyi*dt!*j-@8(b0b(4#d(0#a67"
 install:
   # (...)

Assim, no arquivo de configuração do seu projeto, você usa o os.environ.get do módulo os do Python para capturar o valor, como o exemplo abaixo:

import os

# (...)

SECRET_KEY = os.environ.get('SECRET_KEY', '')

Dessa forma, ao executar o job, as variáveis serão inseridas no ambiente do Travis, e então quando a aplicação ler seu arquivo de configuração, o SECRET_KEY irá possuir o valor desejado, porque o módulo pegou da variável de ambiente. Mas no caso do python-decouple, ele não lê dessa forma, mas como a documentação orienta, nos arquivos ditos anteriormente. Como fazer com essa situação?

Adaptando o job

A solução que encontrei, foi usar a opção before_script do .travis.yml para fazer uma escrita de um arquivo .env usando o comando echo:

language: python
 python:
   - "3.6"
 install:
   # (...)
 before_script:
   - echo "DEBUG=False" >> .env
   - echo "SECRET_KEY=$SECRET_KEY" >> .env

Como pode ver, eu usei o comando echo para inserir a saída que coloquei em aspas duplas no arquivo .env. No caso do SECRET_KEY, eu fui nas configurações do job no Travis CI e coloquei o SECRET_KEY, para justamnete não exibir no log, já que fiz isso em um projeto aberto no Github. Dessa forma, o decouple irá ler o arquivo recém-criado e efetuar o que desejar no seu projeto (executar os testes, etc).

Espero que isso tenha ajudado, e com isso recomendo o uso desse pacote.

Até mais!