Big Data 2015

Big data amadureceu de um jeito curioso. Durante muito tempo, o desafio parecia puramente físico. Guardar mais dados, trazer mais máquinas, empilhar mais processamento, abrir espaço para mais logs, mais eventos, mais tabelas, mais qualquer coisa que surgisse no caminho. Só que, em algum momento, ficou claro que o problema nunca foi apenas guardar. O problema era confiar no que estava guardado, entender o que tinha mudado, permitir leituras simultâneas sem bagunça, ajustar esquemas sem quebrar o que já funcionava e, no fim das contas, fazer tudo isso sem transformar a vida do time em uma coleção de remendos.

É nesse ponto que o assunto fica interessante de verdade. Quando a conversa sai do volume puro e entra no terreno da confiabilidade, o big data deixa de ser uma história sobre armazenamento barato e passa a ser uma história sobre estrutura, metadados, transações e desenho de plataforma. Em outras palavras, o centro da arquitetura muda de lugar.

Muita gente ainda imagina um data lake como um grande terreno baldio digital. Os arquivos chegam, são despejados em pastas, e alguém, em algum momento, tenta organizar aquilo para análise. Funciona até certo ponto. Depois começa a doer. Uma partição mal definida, um esquema que mudou silenciosamente, uma sobrescrita indevida em dados históricos, um job que falha no meio do caminho e deixa metade do conjunto em um estado esquisito. Quem já viveu isso sabe que o problema aparece menos no slide bonito e mais na terça-feira às 7h12, quando o dashboard amanhece errado.

Foi desse incômodo cotidiano que nasceu a virada mais importante da arquitetura moderna de dados. O lakehouse não ganhou espaço porque o nome é sedutor. Ganhou espaço porque ele tenta resolver o que mais desgasta um ambiente de dados real: a distância entre armazenar barato e operar com segurança.

O que mudou quando a tabela virou protagonista

Vale prestar atenção numa ideia que parece pequena, mas reorganiza tudo. No mundo tradicional do data lake, o arquivo era a unidade mais visível. Parquet aqui, ORC ali, CSV em algum canto menos digno da casa. O analista e o engenheiro precisavam pensar demais na disposição física desses arquivos, nas partições, na leitura, no catálogo, nas convenções. O trabalho intelectual ficava espalhado pela infraestrutura.

Com os formatos de tabela abertos, a tabela volta ao centro da experiência. Isso muda o jogo porque a tabela deixa de ser apenas uma abstração lógica sobre arquivos soltos e passa a carregar memória operacional. Ela passa a saber qual é seu esquema atual, quais snapshots existiram, quais arquivos compõem cada versão, quais mudanças foram feitas, como a partição evoluiu e em que ponto no tempo uma leitura consistente pode ser reproduzida.

Essa troca de foco parece sutil, mas é ela que transforma um lago de arquivos em uma plataforma analítica confiável.

Quando se fala em Apache Iceberg, Delta Lake e Apache Hudi, a conversa costuma cair rápido em comparações de features. Só que o ponto mais importante é anterior às features. Esses formatos entendem que big data não pode continuar tratando consistência, evolução de esquema e rastreabilidade como detalhes secundários. Em escala, esses detalhes são o sistema nervoso do ambiente.

O problema nunca foi só performance

Tem uma armadilha comum nessa discussão. Alguém ouve falar em Iceberg, Delta ou Hudi e pensa logo em performance. Claro que performance importa. Leitura mais eficiente, pruning melhor, menos arquivos ruins espalhando latência pelo ambiente, tudo isso conta. Mas o ganho mais subestimado costuma vir da previsibilidade.

Considere um cenário banal de varejo digital. Entram eventos de navegação, pedidos, pagamentos, devoluções, atualizações de catálogo e dados de campanhas. Em algum momento, o esquema do evento de pedido muda porque um novo campo de meio de pagamento precisa ser incluído. Em outro, a chave de partição pensada no começo do projeto deixa de fazer sentido porque o volume cresceu e a distribuição ficou desigual. Em outro, o time de produto pede uma análise histórica reprodutível, exatamente como estava em determinada manhã, porque houve divergência em indicadores enviados para a diretoria.

No modelo improvisado, cada uma dessas situações vira um problema local que alguém resolve com criatividade e um certo cansaço acumulado. No modelo moderno, parte dessa dor é absorvida pelo próprio formato de tabela. Evolução de esquema deixa de ser um ritual perigoso. Evolução de partição não exige reescrever o passado inteiro só para acomodar o futuro. Time travel deixa de ser truque e passa a ser ferramenta de trabalho. O dado ganha memória.

E memória, em big data, é uma forma de sanidade.

Um jeito simples de enxergar a diferença

Essa tabela ajuda, mas não conta tudo. A mudança real é psicológica também. O time deixa de sentir que está domando arquivos e passa a operar entidades de dados com identidade própria. Isso reduz atrito. E, quando o atrito cai, a qualidade do raciocínio sobe. Parece frase de efeito, eu sei, mas basta conversar com quem viveu a transição para perceber como a energia do time muda.

Iceberg merece atenção por um motivo bem específico

Entre os formatos abertos, o Apache Iceberg se tornou um ponto de referência forte em arquiteturas modernas. Não porque seja a única opção séria, e sim porque ele encaixou bem em uma demanda que cresceu muito nos últimos anos: permitir que múltiplos motores leiam e escrevam sobre tabelas grandes com uma semântica melhor do que a velha lógica herdada do Hive.

O detalhe que faz muita diferença está na forma como o estado da tabela é mantido. Em vez de depender de um arranjo frágil entre diretórios e convenções, o Iceberg trabalha com arquivos de metadados, snapshots e manifests que descrevem a composição da tabela em cada momento. Mudanças no estado viram novas versões de metadados. Isso traz uma sensação de solidez que falta em lagos improvisados.

Quem olha só de fora enxerga um nome elegante para uma tabela. Quem opera por dentro percebe que aquela tabela agora tem uma história formal.

Outra peça interessante é a tal partição oculta. Em ambientes antigos, muita gente precisou aprender na marra que modelagem de partição não é só detalhe físico. Ela transborda para consulta, para escrita e para manutenção. O Iceberg tenta aliviar isso ao esconder parte dessa complexidade do usuário e manter a inteligência de particionamento no nível da tabela. Isso faz o uso ficar mais natural, especialmente para times que não querem que cada analista precise pensar como administrador de arquivos distribuídos.

Quando a engenharia consegue proteger o usuário de detalhes físicos sem perder eficiência, a plataforma começa a parecer madura.

Catálogo não é acessório

Num desenho moderno, o catálogo deixa de ser quase burocracia e passa a ser uma peça central. Ele é a ponte entre motores, metadados, governança e descoberta. Sem catálogo bem resolvido, a arquitetura parece unificada só no diagrama.

Esse ponto costuma passar despercebido porque catálogos são menos fotogênicos do que clusters e benchmarks. Ninguém se apaixona por um catálogo à primeira vista. Só que é ele que ajuda a responder perguntas que parecem simples e são tudo menos simples. Onde essa tabela vive. Quem a enxerga. Qual motor consegue operá-la. Qual versão está ativa. Como garantir que a leitura feita por uma ferramenta seja coerente com a escrita realizada por outra.

A abertura do ecossistema também passa por aí. Quando formatos como Iceberg trabalham com APIs e especificações que favorecem interoperabilidade, o catálogo deixa de ser apenas uma agenda interna e vira uma camada de coordenação do ambiente inteiro. Isso interessa muito a empresas que não querem amarrar cada parte da plataforma a um único fornecedor ou a um único motor de execução.

No mundo real, esse tipo de liberdade nunca é total. Sempre existe fricção, adaptação, nuance. Ainda assim, sair de uma arquitetura em que cada ferramenta entende os dados de um jeito meio particular para uma arquitetura em que a tabela fala uma língua mais padronizada já representa um avanço enorme.

Spark e Trino entram em cena sem disputar o mesmo papel

Uma arquitetura de big data mais adulta também melhora quando para de pedir que uma ferramenta resolva tudo. Esse é outro sinal de maturidade. Cada motor entra no desenho pelo que faz melhor.

O Apache Spark continua fortíssimo quando a conversa envolve transformação pesada, pipelines distribuídos, processamento incremental e integrações robustas com o ecossistema de engenharia de dados. Já o Trino brilha quando a necessidade é consulta interativa distribuída, especialmente em cenários onde várias fontes precisam ser acessadas com SQL de forma rápida e relativamente transparente.

Os dois convivem muito bem em lakehouses modernos. E esse convívio é um daqueles pontos que fazem a teoria encontrar a prática. O time de engenharia pode usar Spark para ingestão, enriquecimento e escrita de tabelas analíticas. O time de análise pode consultar essas mesmas tabelas por Trino com baixa fricção. Em vez de exportar dados de um lugar para outro como quem move caixas entre depósitos, o ambiente começa a operar sobre uma camada comum de dados tabulares bem descritos.

Isso não quer dizer que a interoperabilidade seja sempre mágica. Não é. Há diferenças de suporte, detalhes de versão, capacidades específicas e limitações que precisam ser respeitadas. Só que a direção é muito melhor do que a antiga rotina de duplicar dataset, duplicar custo e duplicar dúvida.

Streaming deixa de ser um anexo do batch

Outro momento em que a arquitetura mostra sua qualidade é quando streaming entra na conversa. Durante muito tempo, stream e batch pareciam dois universos que mal se cumprimentavam. Havia times, pipelines e até linguagens mentais diferentes para cada um. Só que o negócio não vive assim. O evento nasce agora, mas quase sempre vai acabar convivendo com histórico, curadoria, reprocessamento e análise retrospectiva.

Quando uma plataforma trata fluxo contínuo como algo que conversa com a mesma camada tabular usada pelo batch, muita coisa encaixa melhor. O raciocínio sobre dado fica menos fragmentado. O histórico não fica divorciado do presente. O trabalho de servir analytics, machine learning e auditoria ganha continuidade.

O Spark Structured Streaming ajuda justamente porque aproxima a mentalidade de stream da linguagem de tabela. Em vez de obrigar o time a pensar sempre em outra categoria de sistema, ele permite expressar boa parte do processamento contínuo com uma semântica mais próxima do que já se conhece em batch. Esse tipo de continuidade vale ouro para manutenção e para formação de equipe. O sistema fica mais coerente por dentro e mais ensinável para quem chega depois.

E tem um detalhe pouco glamouroso, mas decisivo: quando falamos de dados que chegam sem parar, a garantia de processamento e a recuperação após falha deixam de ser luxo conceitual. Elas são a diferença entre um pipeline confiável e uma fábrica silenciosa de divergências na organização estruturada de big data.

O custo invisível de um lago mal resolvido

Uma das piores ilusões em big data é acreditar que a opção mais simples no início sempre será a mais barata no tempo. Guardar arquivos em objeto storage e ir tocando parece um caminho econômico. Em certo sentido, é mesmo. O armazenamento costuma ser barato. Só que boa parte do custo real não aparece na linha do storage. Aparece na manutenção, nas leituras erradas, nos retrabalhos, na dificuldade de governança, na duplicação de datasets, nos jobs defensivos e na insegurança que se instala quando ninguém consegue afirmar com calma qual versão do dado está valendo.

Times experientes aprendem isso de um jeito quase emocional. Não se trata apenas de custo financeiro. Trata-se de desgaste cognitivo. Quando a plataforma não oferece confiança estrutural, cada entrega analítica carrega uma pequena tensão. Será que esse dado está completo. Será que houve overwrite indevido. Será que a mudança de esquema contaminou histórico. Será que a consulta de hoje é comparável com a da semana passada. Será que alguém mexeu numa partição e esqueceu de avisar.

Em algum momento, o time passa mais tempo construindo defesas do que criando valor.

É por isso que a discussão sobre lakehouse não deve ser reduzida a moda. Em muita empresa, ela é simplesmente o reconhecimento de que a dívida operacional do data lake cru ficou cara demais.

Onde muita equipe tropeça

Tem um ponto delicado aqui. Mudar para lakehouse não salva automaticamente um desenho ruim. O formato de tabela pode ser excelente e, ainda assim, a plataforma seguir confusa. Isso acontece quando a organização imagina que tecnologia corrige ausência de modelo operacional.

Se os domínios de dados são nebulosos, se ninguém sabe quem é dono de quê, se naming é caótico, se contratos mudam sem disciplina, se qualidade de dados só aparece na reunião de crise, o melhor formato do mundo vai apenas tornar o caos mais sofisticado.

O mesmo vale para pequenas decisões que parecem inocentes. Granularidade mal pensada. Tabelas grandes demais para tudo e pequenas demais para nada. Explosão de arquivos por escrita descuidada. Camadas sem propósito claro. Catálogo usado só como registro, não como centro de governança. Muitas equipes descobrem tarde que não basta adotar uma tecnologia moderna. É preciso aprender a operar com intenção.

Esse talvez seja o trecho menos sedutor do artigo, mas é um dos mais honestos. Arquitetura boa não nasce só da ferramenta certa. Ela nasce quando ferramenta, modelo de operação e cultura técnica passam a conversar.

Um desenho que costuma fazer sentido

Sem transformar isso em receita rígida, dá para visualizar um fluxo saudável.

Os dados chegam de sistemas transacionais, aplicações, filas de eventos e fontes externas. Entram numa camada inicial mais próxima do bruto, onde integridade e rastreabilidade importam mais do que refinamento imediato. Depois passam por enriquecimento, padronização e validações que tornam os conjuntos úteis para leitura ampla. Só então desembocam em tabelas curadas, mais estáveis, pensadas para consumo analítico, ciência de dados e produtos de dados.

Nada disso é novo como ideia. O que muda no lakehouse moderno é a base operacional que sustenta essas camadas. Em vez de cada estágio depender de uma coleção de convenções frágeis, ele se ancora em tabelas com histórico, metadados fortes e capacidade real de evolução. A conversa sobre qualidade fica menos abstrata porque o suporte técnico para versionar, auditar e recuperar estados passa a existir de forma concreta.

Essa é a parte em que muita gente percebe que o grande ganho não foi só unificar storage e analytics. Foi unificar o raciocínio sobre o ciclo de vida do dado.

O lado humano dessa arquitetura

Talvez esse seja o trecho mais importante, justamente porque costuma ser o menos documentado. Uma boa arquitetura de big data muda a qualidade da conversa entre pessoas.

Quando a base é frágil, a relação entre engenharia, analytics, dados e negócio fica contaminada por desconfiança. A área de negócio pede um número. Analytics entrega com cautela. Engenharia revisa pipeline defensivamente. A liderança sente que tudo parece sofisticado, mas ninguém transmite paz. Isso desgasta mais do que parece.

Quando a base melhora, o dado continua complexo, claro. Só que a conversa muda de tom. Fica mais fácil discutir definição de métrica porque a rastreabilidade do conjunto melhorou. Fica mais fácil explicar divergências porque o histórico das versões existe. Fica mais fácil reprocessar porque a camada tabular já foi pensada para isso. Fica mais fácil conciliar batch e streaming porque a plataforma não trata esses mundos como inimigos.

No fim, lakehouse é um tema técnico. Só que seu efeito mais perceptível aparece nas relações de confiança ao redor do dado. E confiança, em big data, quase sempre vale mais do que uma demonstração vistosa de throughput.

O que realmente merece ser lembrado

Se eu tivesse de condensar tudo numa imagem mental, seria esta: o big data moderno está deixando de ser uma pilha enorme de arquivos acessados por ferramentas poderosas e está se tornando um ecossistema em que a tabela carrega semântica, memória e governança suficientes para servir como ponto de encontro entre engenharia, análise e inteligência.

Isso explica por que formatos de tabela abertos ganharam tanta relevância. Explica por que o catálogo saiu da periferia e foi para o centro. Explica por que engines diferentes conseguem cooperar melhor. Explica por que streaming ficou menos separado do batch. Explica, sobretudo, por que tantas empresas começaram a tratar a camada tabular como produto de infraestrutura, e não como detalhe de implementação.

Big data continua sendo escala, distribuição, custo, paralelismo e desempenho. Nada disso desapareceu. Só que a maturidade do campo está mostrando uma verdade simples, quase óbvia depois que alguém a diz em voz alta: armazenar petabytes nunca foi a parte mais difícil. Difícil mesmo sempre foi transformar esse volume em um ambiente confiável o bastante para que as pessoas possam pensar melhor com ele.

E, curiosamente, é nesse ponto que a arquitetura deixa de parecer um desenho técnico distante e começa a parecer uma escolha profundamente prática. Uma escolha sobre como evitar que o crescimento dos dados produza desordem. Uma escolha sobre como permitir que o passado continue consultável sem engessar o futuro. Uma escolha sobre como fazer a plataforma ajudar o time, em vez de exigir heroísmo diário.

Quando isso acontece, o lakehouse deixa de ser tendência. Vira simplesmente a maneira mais sensata de não enlouquecer.

O continente africano, de forma diversificada e culturalmente rica, está experimentando um boom tecnológico (de 2015-2023) que está redefinindo o cenário econômico. Esse desenvolvimento é ainda mais proeminente nos países de língua inglesa como África do Sul, Nigéria, Quênia, Gana e outros. A digitalização está transformando vários setores, incluindo o setor financeiro. O uso de Big Data e Machine Learning está se tornando mais prevalente, criando um impacto significativo na operação e na prestação de serviços financeiros.

Explicando o contexto financeiro e econômico

A África tem uma economia heterogênea com uma mistura de mercados emergentes e em desenvolvimento. Economias-chave como a Nigéria, a África do Sul e o Quênia têm setores financeiros relativamente avançados. O setor bancário é sólido e bem regulamentado, e o sistema financeiro se estende além do setor bancário tradicional, incluindo seguros, fundos de pensão, mercados de capitais, entre outros.

No entanto, um grande desafio permanece: a inclusão financeira. Uma grande parcela da população africana ainda está desbancarizada ou sub-bancarizada. O acesso limitado a serviços financeiros formais deixa muitos dependentes de serviços financeiros informais, que muitas vezes são caros e inseguros.

Cenário Tecnológico e Oportunidades

As tecnologias digitais estão transformando o cenário financeiro africano, criando oportunidades sem precedentes. Com uma população jovem e tecnologicamente alfabetizada, a África está pronta para um boom tecnológico. A revolução móvel na África é notável. De acordo com o GSMA, mais da metade da população africana estará conectada à internet móvel até 2025. Este alto nível de penetração da tecnologia móvel tem sido um catalisador para o crescimento de serviços financeiros digitais, tais como o mobile banking, que contribuem significativamente para a inclusão financeira.

O cenário de startups africanas também é vibrante. Startups financeiras, em particular, têm atraído um investimento significativo, com empresas fintech liderando o caminho. Um dos segmentos que mais vem ganhando espaço na região é a negociação de opções binárias e derivativos com plataformas como Deriv in Africa.

A Inserção de Big Data e Machine Learning no Setor Financeiro

O Big Data e o Machine Learning estão no centro dessa transformação digital. Eles permitem que as instituições financeiras analisem grandes volumes de dados em tempo real, identifiquem padrões, façam previsões precisas e tomem decisões informadas.

Considerando o setor de crédito e empréstimos, o uso de Big Data e Machine Learning tem mexido bastante com a dinâmica natural. Ao analisar uma variedade de dados, as instituições financeiras podem fazer avaliações de crédito mais precisas e personalizadas. Isso é particularmente útil para incluir aqueles sem histórico de crédito formal. Startups como a Tala e a Branch usam o Machine Learning para analisar dados de smartphones e redes sociais para determinar a solvabilidade.

A detecção de fraudes é outra área onde o Big Data e o Machine Learning estão fazendo uma diferença significativa. Eles podem ajudar as instituições financeiras a identificar padrões de comportamento suspeitos e a agir rapidamente para prevenir fraudes.

O Big Data e o Machine Learning permitem a personalização de serviços financeiros, oferecendo produtos e serviços que se alinham com as necessidades individuais dos clientes. Isso pode incluir tudo, desde a oferta de produtos de seguro personalizados até a personalização da experiência do usuário no banking digital.

Os desafios atuais

Embora o uso de Big Data e Machine Learning no setor financeiro africano apresente oportunidades significativas, também há desafios a serem superados. Primeiro, as questões de privacidade e segurança dos dados são uma preocupação crescente. O manuseio responsável dos dados dos clientes e a garantia de que eles são protegidos contra violações de segurança são de vital importância.

Segundo, a infraestrutura tecnológica necessária para suportar o uso eficaz do Big Data e do Machine Learning ainda está em desenvolvimento em muitas partes da África. Isso inclui tudo, desde a qualidade da internet até o fornecimento de eletricidade.

O desenvolvimento de habilidades é crucial para aproveitar ao máximo essas tecnologias. A formação e a educação em áreas como data science e machine learning são vitais para construir um pipeline de talentos que possam apoiar o crescimento do setor financeiro.

Particularmente acreditamos que serviços financeiros mais inclusivos, seguros e personalizados pode colaborar para a continuação do crescimento e utilização de tecnologias avançadas na África. O cenário está pronto para uma revolução financeira digital, com tecnologia móvel, investimento em fintechs e uma população jovem e alfabetizada. Com os desafios abordados e as oportunidades aproveitadas, a África tem uma oportunidade única de liderar no uso dessas tecnologias emergentes para criar um setor financeiro mais forte e, sobretudo, inclusivo.

O aprendizado de máquina é uma das maiores conquistas científicas da atualidade. Previsto no século XX, o machine learning apenas conseguiu mostrar resultado incontestável no século XXI, após o desenvolvimento de hardware específico com múltiplos núcleos para tarefas paralelas, a partir da inspiração de processamento gráfico (GPUs), inicialmente construída para carregamento de vídeos e renderização de efeitos em games (tecnologia, diga-se de passagem, que vem evoluindo por meio do ray tracing como a Nvidia tem publicado), nos últimos 10 anos tem servido para permitir cálculos de ponto flutuante em larga escala em redes neurais profundas. É nesse ponto que estamos hoje, e você deveria estar por dentro desse movimento. Se ainda não está convencido, leia o próximo parágrafo.

Por que aprender machine learning?

Simplesmente porque é a tecnologia que mais irá automatizar empregos na próxima década. O machine learning permite que as máquinas aprendam tarefas e funções que antes eram restritas ao ser humano. A partir do conceito de aprendizado por reforço – respaldado por imenso poder computacional – as máquinas estão dominando habilidades em nichos cada vez mais específicos, sem a necessidade de código instrutivo, ou seja, não é necessário escrever todas as regras de execução no código, o algoritmo sozinho cria suas próprias estratégias. As previsões de máquinas substituindo trabalhadores são assustadoras. Se você pensa que seu emprego não pode ser substituído, está enganado.

Contudo, em meio ao crescimento da automatização, outros empregos novos serão criados, e justamente serão aqueles relacionados às tecnologias de robótica, inteligência artificial e, provavelmente em sua maioria: machine learning.

Onde aprender machine learning?

Não se engane: você é o responsável por seu aprendizado! Não é um curso, uma formação ou um livro que irá fazer você aprender. Acima de tudo, você precisa ter garra e disposição de correr atrás e adquirir o conhecimento, sem ser dependente de um tutor específico. A internet hoje deu esse poder, permitiu um avanço sem precedentes na possibilidade de pesquisa individual (que, aliás, é fruto do trabalho de agentes autônomos, agentes de busca). Não negligencie essa responsabilidade.

Mas é evidente que é possível aprender machine learning em diferentes locais e de diferentes formas. Por isso, iremos citar aqui alguns portais para ajudar você. O critério mais importante que consideramos para elaborar essa lista é a didática dos cursos. Não há nada mais importante em um material do que a capacidade explicativa do mesmo. Por isso, entenda que se um conteúdo é passado de forma objetiva e didática, com explicações razoáveis e bem fundamentadas, seu aprendizado será muito otimizado e acelerado. A curva de aprendizado ao se estudar com um material bem organizado é muito mais acentuada e vertical.

Em primeiro lugar na nossa lista, indicamos o site Didática Tech. Além de possuir cursos muito focados em machine learning, o portal apresenta diversos cursos gratuitos de programação (em Python e linguagem R) e também de matemática para capacitar o aluno antes de ingressar no ramo. Ou seja, é um arsenal completo de conteúdo para canalizar o conhecimento no objetivo do domínio das técnicas de aprendizado de máquina e inteligência artificial. A didática e organização apresentadas é simplesmente a melhor do mercado, superior inclusive a cursos em inglês (sim, é difícil encontrar material didático em qualquer idioma).

O segundo lugar para aprender machine learning com didática é o Stat Quest. Josh Starmer é, sem dúvida, um dos melhores professores da internet, e felizmente possui muitos vídeos destinados ao aprendizado de máquina, principalmente sob a ótica da estatística. Com explicações detalhadas passo a passo, muitas vezes você compreenderá em poucos minutos conceitos que não havia compreendido em horas de estudo em outros locais. Porém, uma desvantagem é esse portal não possuir conteúdo sobre redes neurais e aprendizado profundo.

Para se motivar no aprendizado de machine learning, com bom humor, um bom ponto de partida é o canal de Siraj Raval. Siraj faz vídeos com muita regularidade e aborda os mais diversos temas de inteligência artificial, desde dados de treino e teste e pré-processamento, até redes neurais, deep learning, redes neurais convolucionais, redes neurais recorrentes, processamento de linguagem natural, assistentes virtuais, entre outros (incluindo computação quântica). Não espere aprender conceitos com didática de forma exemplificada no canal de Siraj, mas você pode ter certeza de que motivação e entusiasmo não vão faltar para impulsionar sua jornada de aprendizado.

Começando com essas indicações, você estará muito bem servido de conteúdo para iniciar sua especialização.

Atualizado em 07/08/2019

As mais recentes tecnologias têm permitido com que o big data cresça e tenha cada vez mais valor. Principalmente nos ramos de Business Intelligence (BI), engenharia e ciência de dados, o conceito de big data tem permitido com que modelos de aprendizado de máquina reconheçam padrões e tragam insights relevantes para empresas e indústrias.

Uma das tecnologias mais emergentes do momento é o blockchain. Blockchain, como o próprio nome diz, consiste em uma cadeia ordenada de blocos. Esses blocos, por sua vez, contêm informações armazenadas na forma de dados, como transações financeiras, por exemplo.

O blockchain surgiu dentro do conceito de Bitcoin, que é um sistema de pagamentos global descentralizado. A forma com que as transações são validadas e armazenadas é justamente nesse livro-razão chamado blockchain, funcionando como um registro contábil. Muitas pessoas, inclusive, acreditam que uma forma de investir em blockchain é por meio de BTC, aprendendo como comprar Bitcoin e guardando para o longo prazo, até a tecnologia florescer mais e atingir todo o seu potencial, como defende o site Confio na Compra com seus artigos fundamentalistas.

Um dos pontos interessantes do blockchain é a sua segurança. Cada vez mais, a privacidade dos dados e questões relacionadas a segurança têm sido um assunto sério. Uma forma de garantir segurança no blockchain é por meio de duplas camadas de criptografia (o Bitcoin, por exemplo, utiliza SHA 256 e ECDSA), porém as assinaturas Schorr provavelmente serão implementadas no core da rede para aumentar a eficiência e a escalabilidade/velocidade.

Outra forma de garantir segurança é por meio do protocolo de consenso utilizado para introduzir novos blocos na cadeia, que no caso do Bitcoin é o Proof of Work (PoW). Nesse processo, múltiplos computadores ao redor do mundo tentam resolver um problema matemático, encontrando um número que possua uma saída da função menor ou igual a certo número bem pequeno (função de via única). O primeiro a resolver, informa o número no hash do bloco e transmite para os fullnodes da rede validarem. O criador de um novo bloco também é chamado de minerador.

Mas blockchain não serve apenas para transações financeiras, muitos outros projetos têm trabalhado com blockchain para armazenar os mais diversos tipos de dados, desde a área médica até cadeias de suprimento e logística. A IBM, por exemplo, possui uma área de pesquisa focada nisso.

Evidentemente, a tecnologia ainda enfrenta alguns desafios como escalabilidade limitada, devido a sua estrutura descentralizada. O fato é que veremos cada vez mais soluções sendo apresentadas, o que permitirá que o valor do big data seja cada vez mais explorado.

*Obs: além de blockchain, outras tecnologias de ledger distribuído (DLT) como block lattice, DAG, entre outras estão no mercado concorrendo com a tecnologia de cadeia de blocos. Algumas criptomoedas como Nano e IOTA são bons exemplos disso, o que reflete a tentativa de aplicar conceitos de descentralização com outros métodos além do próprio blockchain originado com o Bitcoin.

O estudo da análise de dados está ficando cada vez mais abrangente. Partindo de uma simples estrutura que avalia e classifica informações, a análise de dados se transformou no campo amplo do Big Data, que consiste na manipulação de grandes quantidades de dados visando a extrair insights e informações relevantes.

Atualmente, o conteúdo que verdadeiramente é analisado profundamente na internet é de menos de 5%. Todo o restante é desprezado pela dificuldade de tratamento (realmente, existe muito conteúdo inútil, e a dificuldade está exatamente no fato de se conseguir separar dados relevantes dos irrelevantes).

Paralelamente ao surgimento e crescimento do Big Data, outro ramo emergente ganhou muita força: o ramo da inteligência artificial!

A inteligência artificial restrita tem hoje dois principais campos de ação: o machine learning e o deep learning, campos de estudo que têm revolucionado a forma como interagimos com as máquinas. A robótica, por exemplo, está avançando a passos largos graças ao avanços desses campos.

Mas o machine learning também sobre do mesmo problema do big data: obtenção de grande quantidade de dados para tratamento. O aprendizado não-supervisionado, por exemplo, precisa de muitos dados para que o programa possa ser treinado repetidas vezes até atingir a perfeição.

Algumas estratégias no campo da inteligência artificial colaboram para a obtenção de melhores resultados, como as redes neurais convolucionais, que possuem inspiração biológica a partir de um campo receptivo e um mapa de ativação. Esse tipo de abordagem é muito utilizado no processamento de imagens, por exemplo.

Além da inteligência artificial, o processamento de dados também tem apresentado aplicações em tecnologias mais emergentes como o blockchain, que tem mostrado vantagens de processamento em diversos campos, principalmente no quesito autenticidade dos dados e validação da imutabilidade das informações via consenso (que pode ser via Proof of Work – PoW ou Proof of Stake – PoS). Essa tecnologia teve origem no protocolo do Bitcoin e depois passou a ser adotado em outros projetos como Ethereum.

O vídeo abaixo ajuda a compreender um pouco melhor a jornada da ciência de dados e quais serão os próximos passos dessa tecnologia: