O fim do Big Data (2023)

• Com base na experiência inicial de engenharia no BigQuery, o gargalo em muitas organizações estava mais na forma de usar os dados e na estrutura de custos do que no tamanho dos dados
• Pelo feedback de clientes do BigQuery e do setor, a maioria dos data warehouses tinha menos de 1 TB, e mesmo entre os clientes mais ativos a mediana era bem menor que 100 GB
• A separação entre armazenamento e computação na nuvem aumentou muito o volume armazenado, mas a demanda de computação analítica não cresceu na mesma proporção, porque se concentra em dados recentes e agregações
• No BigQuery, 90% das consultas de clientes que gastavam mais de US$ 1.000 por ano processavam menos de 100 MB, e mesmo clientes com datasets enormes não executavam consultas grandes com frequência
• Dados antigos podem se tornar passivo por causa de regulação, litígios, perda de significado e lógica de tratamento especial, então vale revisar se agregar, apagar ou resumir não é melhor do que guardar tudo bruto

---

A diferença entre o medo do Big Data e os gargalos reais

• Há mais de 10 anos se repete a mensagem de que é difícil obter insights acionáveis dos dados por causa do tamanho dos dados
• Em seguida vinha a receita de que comprar uma nova tecnologia capaz de escalar resolveria o problema, mas mesmo após adquirir novas ferramentas e migrar sistemas legados, muitas organizações continuaram tendo dificuldade para entender seus dados
• Em 2023, a situação é diferente de quando os alertas sobre Big Data começaram
  • O grande cataclismo de dados previsto não aconteceu
  • O volume de dados cresceu um pouco, mas o hardware evoluiu ainda mais rápido
  • Os fornecedores continuam vendendo escalabilidade, mas os profissionais começaram a questionar como isso se conecta aos problemas reais

O tamanho dos dados dos clientes visto pela experiência no BigQuery

• O autor, engenheiro fundador do Google BigQuery, demonstrava a capacidade de processar dados em grande escala executando consultas de 1 PB em apresentações públicas
• Depois disso, depurou problemas de clientes do BigQuery, coescreveu 2 livros e, desde 2018, atuou como gerente de produto, conduzindo conversas com clientes e analisando métricas do produto
• A observação mais surpreendente foi que a maioria dos usuários do “BigQuery” na prática não tinha Big Data
  • Mesmo clientes com muitos dados tinham muitos workloads que usavam apenas uma pequena parte do dataset completo
  • Quando o BigQuery foi lançado, a velocidade de processamento parecia ficção científica, mas depois abordagens mais tradicionais também alcançaram esse nível
• Os gráficos do texto são esboços de memória, não números exatos, e o importante não é o valor preciso, mas o formato da distribuição
• A base vem de logs de consultas, análises pós-transação, resultados de benchmarks, tickets de suporte, conversas com clientes, logs de serviço, posts públicos de blog e intuição

A maioria das organizações não tem tantos dados assim

• Os slides de vendas dizendo que o “Big Data está chegando” transmitiam a mensagem de que em breve todos seriam soterrados por dados, mas mesmo 10 anos depois esse futuro não se concretizou
• Olhando o porte dos clientes do BigQuery, a maior parte deles armazenava menos de 1 TB no total
  • Havia clientes com centenas de PB, mas o tamanho seguia uma distribuição de lei de potência que caía rapidamente
  • Havia milhares de clientes pagando menos de US$ 10 por mês em armazenamento, o que equivale a cerca de 0,5 TB
  • Mesmo entre os clientes que mais usavam o serviço, a mediana de armazenamento era bem menor que 100 GB
• Em conversas com analistas do setor como Gartner e Forrester, o feedback também era de que a maioria dos data warehouses corporativos era menor que 1 TB
  • Pela percepção do mercado, um tamanho adequado para um data warehouse era algo em torno de 100 GB
  • A equipe do BigQuery fez desse porte um foco principal de seus esforços de benchmark
• Um investidor que pesquisou empresas do seu portfólio descobriu que, mesmo em empresas de tecnologia, onde o volume de dados tende a ser relativamente maior, a maior empresa B2B tinha cerca de 1 TB, a maior B2C cerca de 10 TB, e a maioria era bem menor
• Mesmo em exemplos de negócios de porte médio, os dados não crescem tão facilmente a ponto de virar algo gigantesco
  • Mesmo que 1.000 clientes gerem 1 pedido por dia com 100 itens de linha, isso representa menos de 1 MB por dia e, após 3 anos, cerca de 1 GB
  • Mesmo que um banco de marketing tenha 1 milhão de leads e dezenas de campanhas, a tabela de leads teria menos de 1 GB e o rastreamento de campanhas provavelmente ficaria em alguns GB
  • Mesmo quando a SingleStore era um unicórnio em Series E crescendo rapidamente entre 2020 e 2022, somando warehouse financeiro, dados de clientes, rastreamento de campanhas de marketing e logs de serviço, o total era de apenas alguns GB

A ilusão criada pela separação entre armazenamento e computação

• Todas as plataformas modernas de dados em nuvem adotam a separação entre armazenamento e computação, para que o cliente não fique preso a um único form factor
• Essa mudança pode ter sido mais importante para a arquitetura de dados dos últimos 20 anos do que o próprio scale-out
  • Em vez da estrutura shared-nothing, difícil de gerenciar, a arquitetura shared disk permite expandir armazenamento e computação de forma independente
  • Armazenamentos de objetos escaláveis e suficientemente rápidos, como S3 e GCS, aliviam restrições de projeto em bancos de dados
• Na prática, o tamanho dos dados cresce muito mais rápido do que o tamanho da computação
  • Os dados são gerados ao longo do tempo e, mesmo em negócios estáticos, o volume armazenado cresce linearmente com o tempo
  • Como a análise costuma se concentrar em dados recentes, a demanda de computação não precisa crescer como o armazenamento
  • Como dados antigos não mudam, continuar escaneando-os o tempo todo é quase desperdício, e muitas respostas importantes podem ser produzidas por agregações
• Clientes que migraram de on-premise para nuvem com separação de armazenamento e computação muitas vezes aumentaram muito o volume armazenado sem grande mudança na demanda de computação
  • Um grande cliente de varejo do BigQuery tinha um data warehouse on-premise de cerca de 100 TB, mas após a migração para a nuvem ele cresceu para 30 PB
  • O armazenamento aumentou 300 vezes, mas o custo de computação não cresceu na mesma proporção, e a empresa não passou a gastar bilhões de dólares com análise
• Essa estrutura mostra que, com um object store escalável, pode bastar muito menos computação do que se imagina, e talvez processamento distribuído nem seja necessário

Os workloads reais de consulta são muito menores que o volume total de dados

• O volume de dados processado por workloads analíticos pode ser menor do que a intuição sugere
  • Dashboards costumam ser construídos sobre dados agregados
  • Usuários normalmente consultam a última hora, o último dia ou a última semana
  • Tabelas pequenas são consultadas com mais frequência, enquanto tabelas gigantes são consultadas de forma mais seletiva
• Ao analisar consultas de clientes do BigQuery que gastavam mais de US$ 1.000 por ano, 90% das consultas processavam menos de 100 MB
  • A análise foi segmentada de várias formas para evitar que o volume de consultas de um único cliente distorcesse os resultados
  • Consultas apenas de metadados, que não leem dados, foram excluídas
  • Consultas na faixa de GB só apareciam em percentis mais altos, e consultas na faixa de TB eram muito raras
• Mesmo clientes com volumes enormes de dados quase nunca consultavam volumes enormes
  • Quando executavam consultas grandes, em geral era para gerar relatórios, e desempenho não era a prioridade
  • Uma grande empresa de mídia social executava consultas muito grandes no fim de semana para relatórios executivos de segunda-feira, mas isso era uma parte ínfima entre centenas de milhares de consultas feitas durante a semana
• Bancos analíticos modernos usam várias técnicas para reduzir o volume realmente lido
  • Projeção de colunas para ler apenas os campos necessários
  • Partition pruning para ler apenas intervalos curtos de data
  • Eliminação de segmentos por clustering ou micro-particionamento automático para explorar localidade dos dados
  • Cálculo sobre dados comprimidos, projeção e predicate pushdown também reduzem I/O no momento da consulta
• Reduzir I/O também reduz a computação necessária, além de baixar custos e latência
  • Material relacionado: reduzir custos de data warehouse em nuvem
  • Material relacionado: diagnosticar gargalos de desempenho em data warehouses

O custo do processamento pressiona por consultas menores

• O fato de ser possível processar rapidamente com scale-out não significa que esse processamento seja barato
• Se forem necessários 1.000 nós para obter um resultado, o custo pode ser muito alto
• A consulta de 1 PB executada nas demos do BigQuery custava US$ 5.000 pelo preço de tabela
• Esse tipo de ineficiência faz parte do big data tax para equipes que não operam realmente em escala de PB
• O incentivo financeiro para reduzir o volume processado vale mesmo fora do modelo de cobrança por bytes escaneados
  • Seja pelo custo de scan do BigQuery ou pelo custo ocioso de uma instância Snowflake, os principais data warehouses em nuvem podem inflar sua fatura
  • Se a consulta for menor, dá para usar instâncias menores, a consulta roda mais rápido e é possível ter mais execuções simultâneas

A maior parte dos dados quase nunca é consultada

• Uma grande proporção dos dados processados é composta por dados recentes com menos de 24 horas
• Depois de cerca de 1 semana, a chance de um dado ser consultado fica aproximadamente 20 vezes menor do que a dos dados do último dia
• Depois de 1 mês, os dados em geral continuam lá, mas só são consultados em execuções raras de relatórios
• A distribuição de idade dos dados armazenados é muito mais suave do que o padrão de acesso
  • Muitos dados são descartados rapidamente, mas muitos também seguem sendo anexados ao fim da tabela
  • Mesmo que os dados do último ano representem só 30% do total, eles podem responder por 99% dos acessos
  • Mesmo que os dados do último mês representem só 5% do total, eles podem responder por 80% dos acessos
• Quando os dados “esfriam” com o tempo, o working set real fica em um tamanho mais administrável do que se imagina
  • Mesmo que exista uma tabela de 1 PB com 10 anos de histórico, o que é acessado com frequência pode ser só o dado do dia
  • Os dados do dia podem ter menos de 50 GB já comprimidos

O limite de uma única máquina continua avançando

• Se Big Data for definido como “aquilo que não cabe em uma única máquina”, o número de workloads que se encaixam nisso vem diminuindo a cada ano
• Quando o artigo do Google MapReduce foi escrito, em 2004, era comum que workloads típicos de dados não coubessem em uma única máquina de uso geral
• Quando a AWS lançou o EC2 em 2006, as instâncias oferecidas tinham apenas um núcleo e 2 GB de RAM, e muitos workloads não cabiam nessa máquina
• Hoje, uma instância padrão da AWS usa 64 núcleos e 256 GB de RAM por servidor físico
  • Isso representa um aumento de RAM de várias ordens de magnitude em relação às instâncias iniciais do EC2 em 2006
  • Pagando mais por instâncias otimizadas para memória, a RAM pode crescer ainda mais, em múltiplas ordens de magnitude
  • Isso leva à pergunta: quantos workloads realmente precisam de mais de 24 TB de RAM ou 445 núcleos de CPU?
• Na nuvem, o custo de VMs grandes cresce quase linearmente com a capacidade de computação
  • Uma VM que usa o servidor inteiro custa apenas 8 vezes mais do que uma VM que usa 1/8 do servidor
  • A avaliação é de que hoje é possível obter, em um único nó, desempenho próximo ao benchmark de 3.000 nós paralelos do artigo original do Dremel

Dados podem virar passivo, não ativo

• Outra definição de Big Data seria um estado em que “o custo de decidir o que descartar é maior do que o custo de continuar guardando os dados”
• Em muitas organizações, o data lake é mais um grande pântano que cresceu não por necessidade, mas porque ninguém apagou nada
  • Ninguém sabe exatamente o que há lá dentro
  • Ninguém sabe se é seguro fazer uma limpeza
• O custo de retenção de dados é maior do que o custo físico de armazenar bytes
  • Regulamentações como GDPR e CCPA exigem rastrear o uso de certos dados
  • Alguns dados precisam ser apagados dentro de determinados prazos
  • Se números de telefone ficarem tempo demais em arquivos parquet do data lake, isso pode violar exigências legais
• Dados antigos também podem ser usados contra a organização em litígios
  • Assim como muitas organizações limitam a retenção de e-mails para reduzir responsabilidade potencial, os dados do data warehouse também podem virar evidência desfavorável
  • Se logs de 5 anos atrás mostrarem um bug de segurança no código ou descumprimento de SLA, manter esses dados por mais tempo pode prolongar a exposição jurídica
• Dados também podem perder significado com o tempo, como o bit rot no código
  • As pessoas podem esquecer o significado exato de campos especiais
  • Bugs antigos nos dados podem sair da memória
  • Por exemplo, pode ter havido um curto período em que todos os customer id foram definidos como null, ou uma grande transação fraudulenta pode ter feito os resultados do 3º trimestre de 2017 parecerem melhores do que realmente foram
  • A lógica de negócio para consultar períodos antigos pode ficar cada vez mais complexa, como “antes de 2019 é revenue, de 2019 a 2021 é revenue_usd, e a partir de 2022 é revenue_usd_audited”

Verificando se você está no 1% do Big Data

• Big Data existe de fato, mas talvez a maioria das pessoas não precise se preocupar com isso
• Para avaliar se você faz parte do 1% do Big Data, vale fazer as seguintes perguntas
  • Você realmente gera um volume imenso de dados?
  • Se sim, você realmente precisa usar um volume imenso de dados de uma vez só?
  • Se sim, isso realmente é grande demais para caber em uma única máquina?
  • Se sim, você não é apenas alguém acumulando dados?
  • Se sim, resumir esses dados não seria melhor?
• Se a resposta a qualquer uma dessas perguntas for “não”, você pode ser candidato a uma nova geração de ferramentas de dados ajustadas ao tamanho real dos seus dados
• Como exemplo relacionado, é citada uma alternativa moderna ao BigQuery
• Em vez de ter medo do tamanho dos dados que talvez um dia venha a existir, as organizações deveriam escolher ferramentas e políticas de retenção com base no tamanho real dos dados que possuem e nos padrões reais de consulta

[GN⁺]

Opiniões do Hacker News

• Em um emprego anterior, quando contratávamos cientistas de dados, uma pergunta-armadilha que gostávamos de usar era: “se o requisito diz que há no máximo 6 TiB de dados, que stack/arquitetura você criaria?”
  Ao ouvir respostas grandiosas como BigQuery e Hadoop e perguntar também sobre custos de hardware/software/licenças, as estimativas costumavam chegar a dezenas de milhares de dólares por ano
  No fim, quem passava era quem entendia que 6 TiB é uma quantidade que as 6 pessoas na sala poderiam distribuir entre seus smartphones, que um HDD empresarial de US$ 199 — ou três, para redundância — bastaria, e que os dados poderiam até ser carregados várias vezes na memória em CSV e processados com scripts awk
  Eu também sou propenso ao erro de, quando aprendo a usar um martelo, ver tudo como prego, mas em contratação não ter noção de escala do que é “big data de verdade” era motivo para reprovação

  • O próprio contexto de uma entrevista de contratação pode ter influenciado a resposta. O candidato está passando por uma entrevista técnica, então acaba esperando que o entrevistador queira avaliar sua compreensão de stacks tecnológicas
    Em vez de concluir, só por esse tipo de resposta, que a pessoa projeta tudo de forma excessiva, é mais correto ver isso como alguém caindo em uma pergunta-armadilha numa situação artificial em que o entrevistador está em posição de vantagem
    Recentemente fiz uma entrevista técnica com um entrevistador de senioridade e experiência parecidas com as minhas e respondi mal; o entrevistador foi julgador em relação à minha resposta ruim. Se os papéis estivessem invertidos, eu poderia tê-lo deixado igualmente em apuros com um tema que eu conheço melhor
    Como entrevistador, é preciso ter cuidado especial para não abusar da posição de superioridade. Isso é contraproducente para a empresa e também não é bom para a pessoa à sua frente
  • https://x.com/garybernhardt/status/600783770925420546 postagem de Gary Bernhardt de 2015:
    “Serviço de consultoria: você me traz seu problema de big data, eu digo ‘seu dataset cabe na RAM’, e você me paga US$ 10 mil por eu ter poupado US$ 500 mil para você”
  • Algumas pessoas ficam bem incomodadas quando você diz que os dados delas não são big data de verdade
    Alguns anos atrás, um diretor me mostrou um sistema criado pela TI com Hadoop, API gateway, vários desenvolvedores e custo anual de centenas de milhares de dólares; quando eu disse que, considerando a escala atual e a escala previsível no futuro, aquilo poderia rodar perfeitamente com um drive USB conectado ao notebook dele e alguns scripts Python, ele ficou muito irritado, e depois disso nunca mais pude me envolver naquele projeto
    Vejo isso como parte de um ciclo de ostentação disseminado na empresa. É uma estrutura em que não se pode admitir que “estamos fazendo uma coisa simples”
  • Entendo a solução de escalar verticalmente, mas, sinceramente, ela é a solução errada para quase todos os casos de uso. Consumidores de dados não querem awk e, mesmo que queiram, varrer 6 TB em uma única CPU a cada consulta, sem particionamento nem armazenamento orientado a colunas, sempre será lento
    Para esse tipo de uso, em geral o BigQuery funcionava bem. A interface de console é suficiente para análises ad hoc, e muitas ferramentas como Metabase e Tableau também conseguem se conectar
    Se o particionamento for feito corretamente, o custo não é excessivo; se virar um problema, basta adicionar tabelas de rollup
  • Arquivos .parquet são completamente subestimados, e ainda há muita gente que não conhece esse formato
    Ao contrário de CSV, eles preservam tipos de dados, são 10 vezes menores que CSV — então 6 TB viram 600 GB — e a leitura é 50 vezes mais rápida. Também são um padrão aberto da Apache Foundation
    Não dá para inspecionar tão facilmente quanto CSV, mas esse compromisso vale a pena. Gostaria que todo lugar que oferece CSV para download também oferecesse .parquet

• No geral, concordo com boa parte do texto, mas há algumas ressalvas. Primeiro, MongoDB é um ponto de referência inadequado. Nunca vi algo que o MongoDB faça que o PostgreSQL não faça melhor, e soluções de big data normalmente não são NoSQL/MongoDB, e sim bancos de dados orientados a colunas, MapReduce, Cassandra e coisas do tipo
  Segundo, é preciso planejar para o sucesso. 95% das empresas não viram unicórnios, mas, se você mira nos outros 5%, não chegará lá sem se preparar. O motivo para projetar pensando em escalabilidade quando você tem 5 clientes é conseguir segurar o momento em que o crescimento exponencial chegar
  Ainda assim, a lição central está correta. A maior parte dos dados não é grande, e até dados sobre todas as pessoas do mundo podem caber em um Chromebook de US$ 100. A maioria dos dados é consultada raramente, as consultas também são pequenas, e o primeiro passo em trabalhos de big data muitas vezes é reduzir terabytes para os GB, MB e, às vezes, KB que realmente são necessários. Por causa de regulações, o custo dos dados também está aumentando

  • “Planeje para o sucesso” é exatamente o que astronautas de arquitetura dizem em qualquer lugar. Pela minha experiência, isso não é totalmente verdadeiro e, muitas vezes, reduz muito a produtividade e a agilidade, que são ainda mais importantes para startups
    As pessoas não apenas planejam; normalmente acabam implementando também. Planejar os próximos 3 meses pode tornar você muito mais ágil e produtivo. Se você não consegue executar, não vai virar um unicórnio
  • Vi muito mais casos em que se garante o fracasso por excesso de preparação para o sucesso do que casos de pânico por precisar lidar com sucesso repentino
    Parece uma combinação de síndrome do segundo sistema com viés de sobrevivência. Pessoas que limparam a bagunça de um bom MVP reclamam “deveríamos ter feito isso antes”, mas as empresas que de fato planejaram e projetaram tudo antecipadamente não sobreviveram, então nem viram alvo dessas reclamações
  • Um detalhe pequeno, mas com 8 bits nem dá para armazenar um ID inteiro único por pessoa. Isso exige 8 bytes por pessoa, e aí já estamos na faixa de 60 GB
    Concordo com quase todo o restante, mas esse ponto parece errado e eu não consegui deixar passar
  • Acho que “para criar a possibilidade de virar um unicórnio, é preciso planejar todas as partes do negócio para agora e para depois” na prática é contraproducente
    A runway de uma startup é limitada, e, se os engenheiros estão gastando dinheiro em algo que só será recompensado daqui a alguns anos, isso aumenta a chance de a empresa fracassar antes de esse momento chegar
  • Tenho dúvidas sobre a ideia de que é preciso projetar escalabilidade desde que há 5 clientes para conseguir segurar o crescimento exponencial quando ele chegar
    Um produto ganhar tração tão forte normalmente vem de um efeito composto gerado pela existência e pelas necessidades da base de usuários. Mesmo que a adição de novos usuários tropece durante o crescimento, é improvável que os usuários existentes voltem ao produto antigo ou vão para outro lugar
    No Twitter antigo, ver a fail whale todos os dias fazia parte da rotina, mas a maioria não saiu, e também não houve uma migração em massa para uma alternativa que escalasse melhor. Produtos que passam por esse tipo de crescimento exponencial são raros, e é comum sofrer com escalabilidade e ter pior disponibilidade durante o processo. Fico curioso para saber quais produtos de crescimento exponencial realmente fracassaram por não conseguir escalar

• Na época em que “big data” estava na moda, eu era pesquisador no Large Hadron Collider. Para nós, analisar todos os dados era um caso de uso que fazia sentido e, na estatística frequentista, quanto mais dados, melhor.
  Mas, mesmo usando uma rede mundial de supercomputadores, descobrimos que um armazenamento local rápido era melhor do que esperar uma tarefa gigantesca terminar. No fim, todos os pós-graduandos reduziram os dados relevantes para exatamente 1 a 5 TB, sem perder muita flexibilidade de análise.
  Parece haver algo como uma lei da conveniência, comparável à lei de escalabilidade de Amdahl.

  • Se eu fosse formular uma, seria algo como: “Se você não consegue fazer análise estatística com 1 a 5 TB de dados, sua metodologia está errada”.
    Isso parece mais uma limitação humana do que matemática. Há um teto claro para a flexibilidade de que conseguimos tirar proveito. Isso poderia mudar se surgissem formas de executar novos tipos de análise com mais facilidade, mas imagino que cresça de forma parecida com um logaritmo em relação ao número de coisas que queremos fazer.
  • Acho que a lei da conveniência existe. Ela também explica por que muitas tecnologias melhoram a uma taxa exponencial constante.
    As pessoas são muito boas em encontrar maneiras convenientes de melhorar um pouco a cada ano, mas qualquer ideia precisa de um tempo mínimo para ser executada.
  • Nos anos 80 e 90, a NASA criou o National Aerodynamic Simulator, um sistema que rodava simulações de análise por elementos finitos em máquinas grandes, como os Cray. Pelos padrões atuais, talvez estivesse no nível de uma placa de vídeo barata.
    Se minha memória não falha, a fila daquele equipamento era tão longa quanto, ou maior que, o tempo necessário para rodar o trabalho em hardware barato, e sistemas de processamento massivamente paralelo como o Beowulf surgiram a partir desses esforços.
  • Acho que a lei da conveniência está correta. Conversando com desenvolvedores de sistemas comerciais, os clientes sempre pressionam para que o sistema seja feito da forma mais barata possível.
    Reduzir o tamanho do banco de dados armazenado e o volume de computação é uma ótima forma de minimizar a fatura mensal do cliente.

• Pela minha experiência, os dados continuam crescendo exponencialmente, mas a quantidade de informação não cresce assim.
  Em finanças, se você quiser, é fácil obter 100 milhões de pontos de dados por dia para uma única série temporal, e também lidar com milhares de séries temporais. Mas essa taxa de amostragem e esse número de séries geralmente são 99,99% redundantes. Isso porque os autovalores caem para quase zero depois de algo como 10 dimensões — às vezes muito antes disso.
  Há pouquíssimo motivo para armazenar petabytes de dados de ticks que você nunca vai consultar. Em muitos casos, faz muito mais sentido fazer uma redução de dimensionalidade agressiva e com perdas no momento da coleta, armazenar apenas os primeiros componentes principais e os outliers, e monitorar a estabilidade dos autovalores para ver se algum novo fator antes desprezível passa a ser importante.
  Como resultado, o conjunto de dados fica muito menor e mais fácil de lidar e, por ser realmente utilizável, muitas vezes acaba gerando mais insights.

  • Interessante; fico curioso sobre como lidar com isso quando os autovetores mudam ao longo do tempo.
  • Seria ótimo se alguém pudesse indicar algum material que explique essa conversa sobre autovalores e dimensões.
    Parece interessante, mas é um tema totalmente novo para mim.

• O engraçado do “big data” é que havia incentivos perversos para evitar até as otimizações mais básicas e óbvias no nível de software. Afinal, requisitos de hardware maiores serviam para provar o quão impressionante você era.
  Por exemplo, se alguém dissesse: “Chefe, em vez de calcular o conjunto de dados inteiro, podemos ler uma amostra e calcular as médias deste relatório só com um notebook”, o chefe entenderia como: “O que você quer dizer com amostra? O que está insinuando com esse papo de matemático/engenheiro? Não está dizendo que desperdicei milhões de dólares, está?”

  • Nessa moda também havia a onda de ex-funcionários do Google convertendo stock options em dinheiro.
    Por um tempo, houve muito exagero comercial e ruído em torno de big data, além de uma disputa de ostentação para ver de quem eram os dados grandes o suficiente.
  • Essa é uma visão externa bem sarcástica e, na prática, não está correta. No começo da minha carreira, tentei reduzir custos de computação como engenheiro de dados.
    Por muito tempo foi muito difícil obter mais de 64 GB de memória em uma única máquina, e quando existe um limite rígido a complexidade de implementação dispara rapidamente.
    Um processo que falha 1 vez em 50 porque os dados cresceram um pouco é extremamente destrutivo. As equipes rodam dezenas desses cron jobs regulares, e se cada um quebra com frequência você acaba ficando de plantão só para recortar pedaços.
    Hadoop e MapReduce não eram extremamente eficientes, mas, usados corretamente, eram razoáveis, e rodar de forma confiável era muito mais importante. Eram melhores do que um código C++ otimizado bit a bit em que ninguém confiava nem conseguia manter, e que morria toda quinta-feira com um erro de segmentação bizarro.
    Hoje em dia eu simplesmente usaria Snowflake, mas na época eram ferramentas razoáveis.

• Este texto não é totalmente preciso. Originalmente, big data era definido em três dimensões: volume, velocidade e variedade
  O volume foi, em geral, resolvido; a velocidade também, mas é caro. A variedade ainda não foi resolvida
  Hoje, big data não é tanto “falta armazenamento ou computação”, mas algo mais próximo de “falta capacidade cognitiva para integrar e entender isso”

  • Ouvi falar desses 3Vs pela primeira vez em uma palestra de Michael Stonebraker. Ele é uma lenda na área de DBMS e vencedor do Turing Award
    Também recomendo fortemente as palestras relacionadas. A maioria está no YouTube
    [1] https://www.youtube.com/watch?v=KRcecxdGxvQ
    [2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
  • Fico curioso para saber o que “variedade” quer dizer aqui
  • Para mim, ainda faltam armazenamento e computação. Seis vezes por ano, passo duas semanas em campo coletando dados; em campo, fazemos coletas de radar de abertura sintética em quatro bandas e dupla polarização com duas aeronaves
    Cada aeronave tem um sistema de radar e, dentro dele, há 8 unidades de armazenamento SSD RAID-0 de 16 drives, com 20 TiB cada. Normalmente não enchemos os RAIDs, então geramos cerca de 176 TiB por dia; com 7 voos em duas semanas, dá 1,2 PiB por campanha, ou cerca de 7,2 PiB por ano
    O motivo de precisarmos descansar um dia entre os voos é que temos de baixar os dados por fibra óptica para um servidor de armazenamento enfiado de qualquer jeito num canto do hangar ao lado do pátio. Depois, replicamos em um segundo servidor por segurança e, quando a missão termina, enviamos tudo para a sede para armazenamento e processamento
    Esses dados são valiosos, mas não no nível de “bilhões de dólares”. São usados para extração de recursos, cartografia, estudos ambientais e geodésicos, e guardamos cada byte desde 2008. Isso porque, quando surgem novos algoritmos, podemos reprocessar dados antigos segundo os novos padrões
    Os arquivos, de 800 GiB a 2 TiB, são transmitidos por streaming para servidores de processamento com GPU e não são compressíveis. A maior parte do que capturamos, a radiação cósmica de fundo em micro-ondas, é bastante aleatória. Houve uma época em que achei, equivocadamente, que gravar em fita reduziria nossa infraestrutura pela metade, mas a capacidade das fitas parecia ser calculada como quando se armazenam arquivos de texto de vários gigabytes compostos só de zeros
    As GPUs são lentas, as CPUs são lentas, o barramento PCIe é lento, a RAM é lenta e até minha velocidade de digitação é lenta. Tudo precisa ficar sempre mais rápido
    Tudo é lento demais, difícil demais e pequeno demais. Os discos rígidos são pequenos demais, e ajustar o kernel do Linux e configurar uma rede rápida e estável para o cluster de processamento é difícil demais. Mesmo atualizações de kernel/pacotes que são simples mudanças internas quebram nossos sistemas de maneiras que parecem acontecer só conosco
    As configurações padrão vivem na ilusão de que RAM é escassa, então economizam memória nas operações de rede. Mas o servidor de arquivos tem 0,5 TB de RAM, então eu queria que ele usasse tudo isso para tornar a rede e o sistema de arquivos rápidos. No fim, preciso passar 6 horas lendo a documentação da pilha de rede e levar a E/S para um nível de bom senso compatível com 2024
    Provavelmente conheço sysctl.conf melhor do que quase qualquer pessoa no planeta
    Armazenamentos distribuídos de objetos persistentes que se dizem feitos para big data ou desmoronam completamente sob nossa carga de trabalho, ou custam centenas de milhões de dólares. Quando digo que o tamanho dos objetos é de aproximadamente 1 TB, os vendedores de sistemas de arquivos distribuídos param de responder. Um fornecedor leu os requisitos e me encaminhou para o responsável por clientes de agências de inteligência. Eu não sou a NSA, nem tenho o orçamento da NSA
    Às vezes aparece um MBA ou PMP que leu uma matéria sobre nuvem na Bloomberg, olha o custo do datacenter on-premises e pergunta sobre migrar para AWS ou Azure; quando mostro os números, tanto em dinheiro quanto em tempo, a pessoa faz cara de quem vai vomitar e muda de assunto
    Além disso, todos os fornecedores entraram na onda de AI/cloud e estão descontinuando as linhas de produtos que serviam para nós. Agora precisamos disputar GPUs com hedge funds e startups de IA que querem minerar dados de clientes para exibir anúncios
    Faltam armazenamento e computação, e o armazenamento e a computação que temos são lentos demais. DPU/IPU é interessante, mas, quando os objetos ficam maiores do que consultas a bancos de dados SQL ou pedaços de vídeo comprimido em streaming, eles batem no limite imediatamente

• Antigamente trabalhei em uma empresa que gerava 20 GB de dados analíticos por dia, e talvez esse tenha sido o maior volume de dados com que vou lidar
  Como projeto júnior, escrevi uma tarefa de processamento de dados que fazia agregações em lote e em tempo real, e salvava os resultados em blobs Parquet no Azure
  Meu chefe era inteligente o bastante para organizar reuniões regulares com stakeholders para discutir o que manter e o que descartar, e, graças a bons algoritmos, conseguíamos comprimir os dados para cerca de 200 MB por dia
  Os últimos 2 meses eram colocados no SQL Server, os últimos 2 anos eram agregados ainda mais e colocados em outro servidor, e a empresa inteira conseguia consultar tudo pelo Excel em um tempo razoável. O big data bruto está apodrecendo em armazenamento em fita, para o caso de um dia ser necessário
  Meu chefe era um mau gerente, mas entendia de dados; olhando para trás, ele fez muita coisa certa, e eu também aprendi bastante

• Ao longo de vários anos, vi muita engenharia em excesso em ferramentas e pipelines de dados “grandes”. Em muitos casos de uso, data warehouses e data lakes ficam na faixa de GB ou de poucos TB, então dá para simplificar muito, por exemplo rodando DuckDB em uma instância EC2 decente
  Pela minha experiência, assim os resultados aparecem antes mesmo de outros sistemas começarem a executar a consulta. Estou falando de você, Athena
  Hoje em dia acho que muitas consultas também podem rodar no navegador, então, com a ajuda do DuckDB WASM(https://github.com/duckdb/duckdb-wasm) e do perspective.js(https://github.com/finos/perspective), criei https://sql-workbench.com/

• Parece que esse ciclo de hype acabou chegando ao “platô da morte”. Não é um desfecho raro neste setor, que é extremamente movido por modas

  • Só mudou de nome para IA
    IA também usa todos os dados e acopla redes neurais mágicas para descobrir o que eles significam

• Pessoalmente, acho que o principal motor do big data foi o ego dos fundadores das empresas. Algo como: “é claro que nossa empresa vai crescer explosivamente e alcançar sucesso em escala planetária, então precisamos projetar tudo para essa escala”
  É trágico cometer esse tipo de erro quando um único banco SQLite bastaria até o produto chegar à Series C. Toda a energia deveria estar concentrada no produto, não na escala, que ainda não existe

  • Não. O big data foi, de fato, impulsionado por pessoas que tinham problemas de dados grandes
    O Hadoop começou inspirado no que existia no Google e ganhou popularidade entre empresas do mundo todo que queriam lidar com dados de uma forma mais barata e melhor que com a Oracle
    O Spark surgiu como uma solução para a complexidade de Hive/Pig etc.; quando as empresas passaram a conseguir criar pipelines de dados confiáveis, tornou-se possível colocar IA em cima deles
  • Depende do tipo de dado com que se lida. Modelos de dados importantes, como geoespaciais, sensoriamento e telemetria, podem chegar à escala de petabytes já no estágio de “Hello, world”
    Modelos de dados gerados por ações humanas intencionais, como clicar em links, enviar mensagens ou fazer compras, são geralmente pequenos. Isso porque há limites para o número de seres humanos e para a quantidade de eventos intencionais que uma pessoa consegue gerar por segundo
    Por outro lado, modelos de dados gerados por máquinas podem ter velocidade e volume algumas ordens de grandeza maiores, e não há um limite claro para o tamanho do modelo de dados. Esses dados muitas vezes estão entre os mais interessantes e subutilizados, porque permitem obter muitos fatos sobre o mundo que não seriam acessíveis por modelos de dados intencionais humanos
  • Em geral está certo, mas há exceções em que datasets acima de 10 TB são muito comuns, como IoT ou GIS