Arquivo da tag: data lake

Há Uma Coisa em Comum entre os Duendes que Vivem Embaixo da sua Cama, e os Bancos de Dados Schemaless

Ambos não existem!


Do ponto de vista da aplicação, na prática, schemaless não existe.

Schemaless, ou schema on read, é quando não existe a estrutura de dados definida [colunas, datatypes, constraints] quando se escreve, pois quem a define é quem lê [a aplicação]. O oposto é Schema-full, ou schema on write, normalmente utilizado pelos bancos de dados Relacionais: define-se a estrutura, e depois insere os dados.

Provavelmente a fábula do schemaless parece ter sido criada por desenvolvedores de front-end que, supostamente, teriam muito mais agilidade para desenvolver e mudar as aplicações sem depender do banco de dados [e seus agregados, como DBAs, indisponibilidade, processos de mudança, etc].

Mas a realidade não é bem assim: tudo SEMPRE tem schema, e se tem schema, mudanças SEMPRE têm esforço.

Schema é o conjunto de regras de integridade que você define para organizar os dados. O sufixo full é quando o BANCO DE DADOS exerce o schema, e o sufixo less é quando VOCÊ exerce. SEMPRE ALGUÉM EXERCE O SCHEMA.

Nos últimos 30 anos os principais bancos de dados criaram mecanismos para implementar recursos de integridade com escalabilidade e disponibilidade. Em alguns bancos de dados é possível fazer alterações de estrutura com zero downtime para a aplicação, e mesmo assim garantir toda a integridade.

Não há como uma aplicação não ter schema. Se você utiliza um Document Store por exemplo, onde os dados persistem como documentos JSON [logo, schemaless], a aplicação tem que saber como ler esses documentos. Saber como ler significa ter schema. Quando você lê um documento JSON e extrai dele um valor numérico para fazer um cálculo, terá que convertê-lo para int, float ou Decimal [um type, logo, um schema]. A propósito, Python é uma linguagem dinamicamente tipada, e mesmo que você não especifique o type estaticamente enquanto programa, deve especifica-lo mentalmente [logo, um schema] para não gerar erro durante a execução.

No final do dia, quando você entende que sempre existe um schema, não há nada que um banco de dados schemaless faça com mais agilidade do que um banco de dados schema-full. A questão é se você quer deixar que o banco de dados exerça o schema por você, ou você adia o trabalho inevitável de VOCÊ exercer o schema depois.  

Eu tenho uma preferência particular por bancos de dados Multi-Model, pois há situações onde o uso conjunto da persistência Relacional e Documentos oferece o melhor da flexibilidade com o melhor da integridade.

Publicidade

O Erro Mais Caro da Sua Vida É Não Usar Python ou SQL pra Arrumar Toda Aquela Bagunça

Conhecer Python ou SQL para fazer data wrangling é igual gravidez: quanto antes você souber, melhor!


Boa parte do trabalho de um cientista de dados, e de um engenheiro de machine learning, é arrumar os dados. Você precisa organizar tudo antes de começar a explorar, e colocar os algoritmos pra máquina aprender.

Eu conheço SQL há muito tempo, e já fiz cada transformação que até a Álgebra Relacional dúvida!

Não é só a linguagem em si, mas o banco de dados também ajuda. Por exemplo, no Oracle você pode criar colunas virtuais, trocar partes da tabela com dados por partes sem dados, inserir em várias tabelas diferentes ao mesmo tempo em que lê a partir de uma query, utilizar funções PL/SQL que podem executar com paralelismo pipeline, persistir em vários formatos de dados, enfim, é uma miríade de capacidades de transformação, tanto para a performance, como para a funcionalidade.

Mais tarde eu aprendi como fazer essa arrumação com Python – já tendo conhecido outras linguagens, como Java por exemplo. Neste post vou comparar brevemente como é fazer esse trabalho de wrangling com SQL e Python [através de uma biblioteca com essa finalidade].

Definitivamente SQL e Python são as melhores ferramentas não-Nutella [sem o apoio de uma ferramenta de transformação própria pra isso] para limpar e arrumar dados.


Meu primeiro contato com Pandas ocorreu há mais ou menos um ano. Confesso que achei que estava re-construindo a roda. Praticamente tudo que eu fazia com essa biblioteca em Python eu acreditava que conseguia fazer em SQL com muito mais simplicidade. Bom, primeiro eu explico o que é o Pandas.

Pandas é uma biblioteca open-source em Python para análise de dados.

Pandas basicamente é composto por um objeto chamado Dataframe [uma planilha!], e este dispõe de vários métodos com uma boa usabilidade para manipular dados. Minha primeira impressão ao utilizar o dataframe foi a de utilizar o Excel em forma de código, mas com muito mais performance.

Para instalar, como todo pacote Python, basta executar o comando abaixo no sistema operacional [Terminal no Mac ou Linux, e Command Window no Windows]:

pip install pandas

Para utilizar, em um notebook [Jupyter ou Zeppelin] ou em um arquivo Python .py:

import pandas as pd
meuDataFrame = pd.read_csv('arquivo.csv')
meuDataFrame.describe()

O código acima importa o pacote Pandas, carrega um arquivo csv no dataframe meuDataFrame, e faz um describe nos dados. Describe() é fantástico! Ele retorna uma tabela com uma série de dados estatísticos para cada coluna, como count, avg, sum, stddev, min, max e percentis. Essa primeira exploração é bem interessante com Pandas em relação ao SQL. Mas a vantagem do Pandas começa e termina aqui. Quase que todo o resto do trabalho de wrangling [limpeza dos dados] eu achei muito mais simples e mais rápido com SQL, por isso a sensação de estar reinventando a roda.

Limpar e transformar dados sobre grandes volumes requer critério. Cada minuto pensando na estratégia de implementação equivale a horas de processamento.

A manipulação dos dados em si com dataframes consiste em criar dataframes a partir de dataframes, sendo que as cópias vão transformando os dados aos poucos, com colunas novas a mais, ou a menos. Há também agregações [groupby], filtros [query], unicidade [unique], ordenações [sort_values], e merges e joins [este último me lembra…. SQL!]. É necessário registrar também que há uma miríade de funções estatísticas para utilizar que são bem interessantes. 

Em Python com Pandas:

# Adicionar nova coluna somando 10 sobre uma coluna existente
meuDataFrame['nova_coluna'] = meuDataFrame['col1'] + 10

# Somar
meuDataFrame.col1.sum()

# Filtrar coluna maior que 100
meuDataFrame.query('(col1 > 100)')

# Eliminar duplicidade
meuDataFrame.col1.unique()

# Ordenar
meuDataFrame.sort_values(by='col1', ascending=False)

Em SQL:

# Adicionar nova coluna somando 10 sobre uma coluna existente
SELECT a.*, a.col1 + 10 as nova_coluna FROM tab a

# Somar
SELECT SUM(col1) FROM tab

# Filtrar coluna maior que 100
SELECT * FROM tab WHERE col1 > 100

# Eliminar duplicidade
SELECT DISTINCT col1 FROM tab

# Ordenar
SELECT * FROM tab ORDER BY col1 DESC

Pandas tem também uma excelente integração com o pacote Numpy para processamento de arrays e matrizes multidimencionais, e o Matplotlib, para visualização de gráficos

A documentação do Pandas está aqui neste link.

Pandas é facil, mas SQL é mais human-readable, na minha opinião. Com SQL a manipulação de dados é extremamente trivial. Ao invés de criar dataframes a partir de outros dataframes para incluir, transformar ou remover colunas, você faz subquery ou transforma na própria cláusula SELECT. Todas as APIs que você pode imaginar para trabalhar um dado existem nos sistemas gerenciadores de banco de dados que suportam o SQL ANSI. Desde funções descritivas simples, como SUM ou COUNT, até funções mais complexas como as Regressões Lineares, Testes de Hipótese e Análises de Variância. Adicionalmente, existem também as funções analíticas [esta última me lembra… Pandas!] e as de machine learning. Com Pandas, bom, para machine learning, teria que utilizar algum outro pacote [como scikit-learn, por exemplo].

Uma Conversa Franca sobre Não Perder Tempo

No final do dia eu prefiro SQL, mas depende.

Eu prefiro Pandas quando manipulo arquivos que não precisam persistir por muito tempo [análises pontuais] e não precisam de integração com outras fontes de dados, e não precisa de tanta performance.

Por exemplo: costumo fazer análises de infraestrutura com centenas de servidores, cada um com centenas métricas, e depois de tomar as conclusões, apago tudo – criar um banco, criar as tabelas, carregar os dados, e só então explorar os dados leva tempo… é melhor fazer esse tipo de análise com Pandas.

Quando preciso de um acabamento mais enterprise, isto é, algo que vai existir por mais tempo, com grande volume de dados, que vai ser utilizado por outras pessoas, que será reutilizado, compartilhado, que precisa de segurança, e claro, extrema performance e escalabilidade, não há dúvidas que SQL, na minha opinião, é melhor.

Tente conhecer os dois: SQL e Pandas. Use Pandas quando for mais conveniente, do contrário use SQL. Você escala mais conhecendo ambos.