Arquitetura de dados para pequenas empresas (small data)
Uma proposta de arquitetura para small data barata e escalável
Empresas de pequeno e médio porte frequentemente enfrentam desafios para definir uma arquitetura de dados. Este tipo de negócio costuma apresentar uma baixa volumetria (entenda aqui valores que não estejam na casa dos terabytes ou petabytes de dados) e um orçamento modesto. O propósito por trás dessa definição varia entre o estabelecimento de um área, busca pela tão sonhada cultura data driven, ou mesmo uma solução sólida para problemas que envolvem cruzamento de dados de diferentes sistemas e melhor acompanhamento de KPI’s. As ferramentas disponíveis no mercado são as mais variadas possíveis, e profissionais muito experientes e qualificados escassos e (merecidamente) bem remunerados. O que fazer?
Neste artigo pretendo explorar diferentes alternativas de arquiteturas que podem ser eficientes neste contexto, para um público com alguma familiaridade com os principais conceitos relacionados. As imagens ilustrarão produtos, mas podem ser adaptadas para ferramentas similares em outros provedores, apegue-se aos conceitos.
Infraestrutura
A disputa travada entre arquiteturas on-premises e cloud nos últimos anos parece ter tido um claro vencedor para a grande maioria dos cenários. No que diz respeito a empresas menores, a ideia de se alugar uma casa ao invés de compra-lá, além da possibilidade de pagar apenas pela energia elétrica que consome, tendo interruptores por todo lugar, é muito convidativa. Portanto infraestrutura na nuvem, ✅.
Open-source?
A partir daqui chegamos a mais um dilema: open-source (código aberto) ou serviços serverless (sem servidor) do provedor de cloud escolhido? A princípio, a ideia de utilizar ferramentas sem custo para aquisição ou mensalidade é muito atrativa, mas com pouca experiência prática terá a clareza de que interfaces por vezes pouco amigáveis, e a necessidade de provisionar e manter a infraestrutura - ainda que em nuvem - exigirá profissionais muito qualificados. Não obstante, exigirá maior tempo de desenvolvimento, e consequentemente para entrega de resultados. Creio que para muitos nesta situação produtos de código aberto podem não ser a melhor escolha.
Custo na nuvem
Pesquisando pelos produtos necessários através de conteúdo oficial do fornecedor e eventuais reuniões com seus arquitetos, encontrará respostas formulaicas, tais quais:
Microsoft Azure: Azure Synapse Analytics para Data Warehousing e ETL (Microsoft Fabric)
AWS: Amazon Redshift para Data Warehousing e AWS Glue para ETL.
Elas não estão de tudo erradas, mas a próxima pesquisa talvez lhe fruste um pouco, pois aqui entra um desafio bastante brasileiro: temos uma das nuvens mais caras do mundo, e para ajudar, a cotação do dólar está altíssima. Além do mais, com volumetria pequena, o poder de processamento da menor instância desses Data Warehouses e serviços de transformação baseados em Spark é absolutamente exagerado. Podemos - ou precisaremos - ser mais criativos.
Bancos de dados relacionais
O caminho talvez esteja nos bancos de dados relacionais, serviços que deve ter cogitado pela possibilidade de serem utilizados no formato sem servidor, e com preços acessível para instâncias pequenas. Manipulados com linguagem SQL, são base importante para todos da área a décadas, facilitando assim a procura por profissionais capacitados. Se as limitações que este tipo de banco de dados apresentam - e que motivaram o desenvolvimento de Data Lakes e outras arquiteturas modernas - como inflexibilidade de esquema, não forem impeditivos à sua realidade, acredito ser uma excelente escolha a se fazer. Em outras palavras, se tuas origens são sistemas relacionais (ERP, CRM...) e não há dispositivos IOT ou muitas APIs lhe enviando JSONs para todo lado, bancos relacionais podem lhe atender perfeitamente.
Alie isso a serviços que executem códigos rápidos como AWS Lambda ou Azure Functions para seu ETL e pronto, orquestração via Step Functions ou Azure Data Factory não são muito custosas. Veja uma seguinte proposta, em ambiente AWS:
Mas Matheus! Esses serviços que sugeriu para ETL, embora muito baratos, são muito limitados em termos de processamento, pois uma Lambda tem tempo máximo de execução de 15 minutos com 10 Gb de memória (Jul/23). De fato, mas assumindo uma abordagem prática, sugiro fortemente que movimente algumas dezenas ou centenas de linhas (condizentes com tua realidade), aplique transformações simples e utilizando um destes serviços insira no banco de dados destino. Verás que a execução finalizará em poucos segundos utilizando um pequeno percentual do máximo de memória possível. Presumo que os planos de crescimento da empresa sejam agressivos, mas será que tão arrojados a ponto de uma estrutura como essa não lhe atender por bastante tempo?
Storage + Banco de dados relacional
Caso as limitações mencionadas sejam impeditivos, especialmente por arquivos semi-estruturados vindo de APIs (redes sociais, sistemas terceiros...), será difícil evitar serviços de armazenamento de objetos, e consequentemente estruturas que remetam a Data Lakes. Mantendo um banco relacional em camadas mais adiantadas para consumo de usuários finais e ferramentas de visualização, temos o seguinte desenho na AWS:
Perceba que a entrada de dados se dá através de AWS Lambda, onde esse dado bruto é armazenado em um bucket no S3 para então, através de outra Lambda, ser transformado e inserido em tabelas relacionais. Este banco de dados pode cumprir o papel de um Data Warehouse ou apenas armazenar dados prontos para consumos, tendo uma ferramenta de BI ligada a ele.
🚫 Bancos Relacionais
Em um contexto onde bancos relacionais não sejam desejados, simulando arquiteturas robustas e modernas de Big Data, é possível sim eliminá-los, criando um ambiente similar a de um Data Lakehouse:
Neste desenho há um Data Lake de exemplo com com quatro camadas, cujo serviço de armazenamentos de objetos é o (S3), cumprindo o papel de repositório principal, e para o ETL AWS Lambdas.
Para consultas podemos utilizar o Amazon Athena, seja através do próprio console e queries SQL, ou com conexão JDBC para um client local ou ferramenta de visualização. Este serviço cobra pelo volume de dados escaneado, o que se adapta a realidade em que estamos. Outro ponto importante é que esta cobrança também se molda bem a arquivos colunares comprimidos, por isso parquet com compressão snappy é excelente opção. O risco que este modelo de cobrança apresenta é para usuários pouco preparados executando queries descontroladamente, ou mesmo uma ferramenta de visualização sem sistema de importação ou caching, ou seja, que ao atualizar um dashboard vai até a origem buscar os dados.
Este desenho é completado pelo Glue Catalog que o Athena utilizará para encontrar os dados, Step Functions para orquestração (mais Event Bridge para rotinas baseadas gatilhos temporais) e Lake Formation para governança. Um desafio que certamente enfrentará é o de atualização do catálogo de dados, que geralmente é feito com Crawlers do Glue cobrados como jobs Spark. A melhor e mais amigável solução talvez seja a AWS SDK for Pandas, que permite criação de atualização de objetos no catálogo e manipulação de arquivos parquet de forma muito similar ao do Apache Spark.
O meu apresso por essa arquitetura reside na flexibilidade de trabalhar com arquivos, na simplicidade de realizar consultas com SQL e de criar todo ETL com Python, e em seu baixo custo caso a volumetria e frequência de cargas seja baixa. Nos contras estão os inevitáveis desafios técnicos propiciados por produtos que exigem bastante hard skill, e falta de transações ACID.
Data Lakehouse
A última arquitetura que gostaria de discutir neste artigo resolve, ao menos em partes, os problemas do ambiente anterior, pois um Data Lakehouse utilizando Databricks (Delta Lake) tem muito dos benefícios citados acrescidos de transações ACID. Ainda que este fator talvez não seja limitante, afinal serão poucos os profissionais consumindo e movimentando dados simultaneamente, é uma vantagem indiscutível. Seu principal contra estará no preço, superior ao da arquitetura anterior, mas que possivelmente caiba no teu orçamento visto que os seus maiores ofensores serão clusters, cobrados pelo tempo de uso (pay as you go), em jobs que certamente serão rápidos e não necessariamente frequentes, além do baixo número de analistas realizando consultas. Esta plataforma é agnóstica, bastante escalável e muito mais facilmente configurável caso precise de entregas mais rápidas.
Conclusão
Os elementos a serem considerados para a definição da arquitetura de dados ideal para o momento da empresa passam não apenas pela volumetria e formato de dados utilizados, velocidade com que são gerados e consumidos, e orçamento disponível, mas também pela expertise e conhecimentos do time. Nestes anos de trabalho vi diferentes empresas atingirem resultados positivos com todas elas e acredito serem boas inspirações para a solução de seus desafios. Lembre-se que melhoria continua é uma necessidade, e que a jornada possivelmente lhe trará mudanças de rota e ensinamentos.