Arquivo da categoria: Histórias com Dados

Transformação Digital, sem Buzzwords

1. Seus ambientes não-produtivos são efêmeros, e você os recria do zero todo dia. Quando precisa. Quanto precisa. Por código. Imediato.

2. Você não move seus dados nunca. Todos eles são necessariamente virtualizados e convergidos, acessados sempre com a mesma interface. Não importa o formato, o tamanho, e a velocidade.

3. Zero ETL. Real-time analytics, sempre.

4. Criptografia por padrão em qualquer coisa: in-flight, in-memory, e at rest.

5. Mudanças em produção ocorrem a todo tempo, sem parada.

6. Sua capacidade escala do zero ao máximo, por segundo. Sem interrupção. O máximo é ilimitado.

7. Data Lineage de tudo que você tem com no máximo dois cliques de esforço.

Winter is Coming: Como Sobreviver em um Mundo com Persistência Poliglota?

Eu costumo dizer que bancos de dados são como queijos e vinhos, pois eles melhoram enquanto envelhecem.


No início existia apenas uma arquitetura de dados one-size-fits-all: a solução para todo e qualquer problema.

O que vemos hoje é uma verdadeira miscelânea, centenas de combinações e permutações possíveis de formatos diferentes, tecnologias, e integrações de todas as latências. Você já não sabe se tem que ser streaming ou batch, síncrono ou assíncrono, schema-less ou schema-full, SQL ou NoSQL, se a consistência mais adequada é eventual ou forte, o relacionamento é entre nós de um grafo ou entre chaves de tabelas, se precisa ser scale-up ou scale-out, e se é necessário um Data Lake ou um Data Warehouse.

Se identificou? Continue lendo.

Este artigo é sobre uma das maiores tendências a respeito de como organizar toda essa bagunça: persistência poliglota multi-modelo. Esta coisa de nome complicado, longo, e difícil de falar [eu entendo], é a fusão de uma dezena de tecnologias já testadas em batalha, e que provavelmente será, eu estimo, o futuro da arquitetura de dados. Será como antes só que o oposto: de one-size-fits-all, para all-fits-one-size.

O Início de Tudo: a Jornada do Herói

Nos primeiros sistemas de banco de dados, se é que podemos chamá-los de “sistemas” diante da primitividade que pairava no início, eu me lembro de ter lido que para conseguir uma informação você tinha que [1] saber qual era o arquivo onde ela estava, e [2] qual era o registro nesse arquivo, e [3] então quais eram as suas posições de início e término no registro. Essas posições eram sempre fixas, a propósito. Nessa estrutura, que se chamava ISAM, basicamente, você tinha que ter um mapa que lhe explicava como os dados que eram gravados, para poder buscá-los depois.

Não vou detalhar com mais profundidade sobre a estrutura de dados ISAM, pois assim como eu, hoje, você não vai querer saber!

Um senhor chamado Edgar Codd, pesquisador da IBM [claro, todos os pesquisadores da época eram da IBM] disse que as pessoas não deveriam ter que se preocupar em como os dados estavam organizados para entendê-los. Isso se tornaria um caos num futuro reservado para os Megabytes [hoje, Terabytes].

Codd então criou o Modelo de Dados Relacional. Era um mecanismo engenhoso, porém simples, que desacoplava os dados da organização física deles. Uma simples frase como “selecione os dados do cliente, na tabela de clientes” foi capaz de substituir milhares de linhas de código, e acelerar em ordens de magnitude o tempo para buscar as informações.

Eis que surge Larry Ellison, com mais alguns amigos. Enquanto uns apenas viam o que seus olhos enxergavam, Larry enxergava o que seus olhos viam: nada inventado antes era mais completo e eficiente do que o Modelo de Dados Relacional. Naqueles anos 70, era o futuro. E foi mesmo. E esse futuro ainda não acabou.

Surgiu o Oracle Database como o primeiro sistema gerenciador de banco de dados baseado no Modelo de Dados Relacional. Uma locomotiva de inovação a toda velocidade passou entre os anos 80, 90 e 2000. Foi incrível a quantidade de recursos criados, e até hoje alguns desses recursos ainda são exclusivos.

Muitas outras tecnologias surgiram: ora morriam pelo caminho, ora apenas sobreviviam com uma vida de ócio e defasagem diante da constante evolução do Oracle.

CAP, e os 300

O ano 2000 entra, a internet começa, e o suposto declínio do Modelo Relacional é ensaiado. A internet é um colosso perto dos sistemas empresariais. Por um minuto você tem 10 usuários, e no momento seguinte, instantaneamente, você tem 1 milhão. Projetado para funcionar em servidores que escalam verticalmente, os Bancos de Dados Relacionais realmente não funcionam nesse novo paradigma.

Eric Brewer formula uma conjectura que alguns anos mais tarde se tornara um teorema, o teorema CAP. Esse teorema basicamente forma a base para a criação de estruturas de dados que seriam mais adequados para a internet do que o Banco de Dados Relacional. Em essência, são estruturas de dados que escalam horizontalmente.

O teorema CAP é realmente uma ideia estranha, mas foi provada matematicamente. A letra A do CAP significa “sempre disponível para leitura e escrita“, o que implica em uma disponibilidade de 100%. Ora, nada nesse mundo tem 100% de disponibilidade. Nem o mundo tem 100% de disponibilidade. Bom, essa é uma premissa que não concordo, mas em função dela o CAP é um teorema, e com teoremas não se discute.

A ideia colou, mais de 300 bancos de dados Não-Relacionais foram criados, e a internet explode. Todo hype é então construído baseado em estruturas Não-Relacionais.

Dá-se então início a vários formatos de dados diferentes.

Timidamente, primeiro foram as estruturas Objeto-Relacionais. Essas morreram rápido. Prometeram de mais, fizeram de menos. Cometeram o mesmo pecado do ISAM: era necessário compreender os Objetos para entender os dados. Retrocesso. Curiosamente, os Bancos Relacionais absorveram o modelo lógico Objeto-Relacional, junto do Relacional, para quem quisesse usar, inclusive, no mesmo comando SQL.

É o início dos Bancos de Dados Multi-Modelo. Relacional com Objeto.

Depois surgiram as estruturas de armazenamento XML. Menos complexas do que os Objeto-Relacionais, pois elas tinham schema, e XPath para percorrer os dados. XML ficou bons anos em evidência. Mas também falhou. E novamente, os bancos relacionais absorveram o modelo lógico XML, junto do Relacional, para quem quisesse usar, no mesmo comando SQL.

Relacional, Objeto e Documento XML.

Em paralelo surgiu a necessidade de bancos de dados com capacidades de geo-processamento, os Bancos de Dados Espaciais. Nenhum fez sucesso como um produto a parte, porém, essa camada de persistência se juntou aos Relacionais, como uma outra camada lógica, e ainda é usada hoje, desta forma, como parte dos bancos relacionais.

Relacional, Objeto, Documento XML e Geo-Espacial.

Mais próximo dos tempos atuais, despontou como uma forma de armazenamento bastante comum o formato JSON, com grande flexibilidade e agilidade: os desenvolvedores adoram. No entanto, apesar de alguns bancos de dados puramente baseados nesse formato terem se tornado relevantes, os bancos de dados relacionais que outrora haviam absorvido vários outros modelos lógicos, também absorveram o formato JSON.

A partir de agora é muito mais fácil um Banco de Dados Multi-Modelo acrescentar uma nova estrutura lógica, do que um banco de dados especializado implementar as capacidades mais básicas, como Consistência Forte, ou mesmo SQL, por exemplo.

Relacional, Objeto, Documento XML e JSON, e Geo-Espacial.

Outras estruturas de dados com usos mais específicos também fizeram parte do big bang causado pelo teorema CAP: Grafos, Chave/Valor, Colunares e Motores de Busca. Adivinha? Os bancos de dados relacionais adicionaram mais camadas lógicas para suportar essas estruturas.

Destaco que de todos esses, o Modelo de Grafos é o mais diferente. É o mais engenhoso. E provavelmente é o que eu gosto mais. É também assunto para outro artigo.

Enquanto que do ponto de vista de estrutura de dados os Bancos Relacionais fizeram grandes intervenções para suportar tudo o que o mercado demandava, por outro lado, num passe metamorfósico, esses bancos também passaram a escalar horizontalmente, para os lados e não somente para cima, como todos os outros 300 bancos de dados Não-Relacionais já faziam. Dá-se o nome de NewSQL, uma alusão aos bancos Não-Relacionais [NoSQL] com a consistência forte dos Relacionais e o suporte completo ao SQL [basicamente, SQL é um sonho de toda a vida de um NoSQL, Apache Hive que o diga].

Esses super Bancos de Dados Relacionais, que suportam vários modelos de dados, e escalam tanto para cima como para os lados, são chamados finalmente de Bancos de Dados Poliglotas Multi-Modelo. Eles possuem toda a herança de inovação dos fundamentos essenciais para gestão de dados, o suporte aos principais formatos de dados dos últimos 40 anos, e a capacidade de escala que é um dos requerimentos para aplicações modernas de internet e Big Data.

Um outro fator relevante se soma a esses super bancos de dados: cloud automation. Poucos cliques ou chamadas de API permitem que toda essa estrutura seja criada, e mantida automaticamente.

De Codd ao Uber

As arquiteturas de dados são como um trem em alta velocidade, com curvas e hypes pelo caminho. Sempre surgem aquelas tecnologias que só elas fazem aquilo, que são mais típicas de “aplicações de ponta”, mas depois elas acabam convergindo para o mainstream porque as aplicações de ponta hoje são as aplicações mainstream de amanhã.

É por isso que tenho uma preferência particular por Bancos de Dados Multi-Modelo. Você absorve todas as inovações que surgem ao longo dos anos, e herda todas as capacidades fundamentais que as aplicações de ponta ainda não têm.

Meu Uber chegou! A propósito, ele me localizou com geo-processamento, o pagamento da minha corrida vai persistir com a integridade de um modelo relacional, e todas as outras coisas devem estar agregadas em documentos JSON em uma estrutura scale-out, pois afinal é mobile e precisa ser escalável.

Como poderia dizer Codd: as pessoas não deveriam ter que se preocupar em como os dados estão organizados para entendê-los. Isso pode se tornar um caos num futuro reservado para os Pegabytes…

Se Você é um DBA Ocupado que Não Gosta de Ler, Leia Isto!

Duas pessoas se encontraram à meia-noite naquela sala que fica no final do corredor de um prédio antigo, numa cidade estranha…


Eram dois administradores de banco de dados, de uma mesma consultoria, e estavam prestando serviço para um cliente. Eles viajaram por horas para estarem lá naquele momento.

Ambos eram qualificados, certificados, e com boa experiência em lidar com ambientes de alta criticidade. Mas havia uma certa tensão, como sempre. Era uma janela de manutenção importante que envolvia várias atividades complicadas [daquelas que se você fizer bem leva um tapinha nas costas, e se fizer errado leva um chute no traseiro – você sabe do que estou falando!].

Houve alguns problemas. Os pré-requisitos para aplicar um patch não foram seguidos corretamente. Houve falha no planejamento de capacidade e o espaço em disco acabou durante a execução de um processo batch, resultando em erros e reprocessamentos. O backup de uma tabela precisou ser restaurado, mas não funcionou de primeira [culpa do time de storage]. Eles tiveram que fazer muitas ações manuais e usar a expertise, mas no final deu tudo certo.

Esta foi só mais uma noite de um final de semana. Não muito diferente de outras que ocorrem durante o ano.


Dez anos se passaram.

Aquelas duas pessoas estavam trabalhando juntas na mesma empresa, porém em uma outra consultoria.

E havia uma diferença. Um deles ainda era DBA, porém MUITO MAIS EXPERIENTE do que antes, mas com a vida de sempre. O outro era o SÓCIO-FUNDADOR da consultoria que eles trabalhavam. E ele estava tranquilo, pois tinha acabado de fechar mais um negócio milionário com um cliente novo.

Você Encara os Fatos – Ou Se Esquiva?

O fato é que hoje as empresas buscam ser data-driven, e aquelas que já são, precisam muito de profissionais na área de dados com skill em cloud, engenharia e ciência de dados, e menos de DBAs.

Como um engenheiro de dados, você terá que ser capaz de desenvolver, construir e manter arquiteturas que suportam sistemas em qualquer escala, e explorações e análises em uma grande quantidade de dados, feitas por cientistas de dados.

Você não terá que instalar e configurar uma infraestrutura de banco de dados: você irá apenas criar um serviço de persistência na nuvem; Você não vai dimensionar pelo pico e projetar o crescimento para os próximos 3 anos: você vai provisionar pelo uso, e otimizar a utilização; Você não vai criar scripts de monitoração em shell para os bancos de dados e os backups: você vai carregar arquivos dos mais diversos formatos usando Python e SQL; Você não vai sentar aqui e os desenvolvedores lá: vocês vão sentar juntos e colocar os algoritmos pra máquina aprender; Você não vai reportar quais são as queries lentas quando houver um problema de performance: você vai resolver o problema de performance!

O sócio-fundador, e ex-DBA, percebeu que a área dele estava passando por um estágio de grande automação. Ele deixou de lado seu foco em infraestrutura e administração de banco de dados, e aprendeu Python, REST, JSON, Spark, integração, cloud, DevOPs, melhorou muito seus conhecimentos em SQL, conheceu técnicas de data wrangling, e os diferentes tipos de banco de dados. Familiarizou-se com IoT, microserviços, machine learning, IA e blockchain.

Ele ainda trabalha até as 4 AM, mas a diferença é que ele ama cada minuto: ele abriu essa startup de consultoria que só cresce, e hoje é dono do seu tempo.


Fazendo isso você pode não chegar aonde ele chegou – fundar uma startup [talvez nem queira isso]. Mas você estará preparado para a evolução tecnológica que estamos passando, e vai trabalhar nas melhores oportunidades com os melhores salários do mercado.

Há um trem em alta velocidade passando. Você pode encarar os fatos [da evolução tecnológica] e aceitar o desafio de entrar nesse trem, como o sócio-fundador fez, ou então ver ele passar.