O que é e como funciona o Dremio?
Uma introdução sobre o que é essa ferramenta fantástica, de onde vem tanto poder e como ela pode turbinar seu Data Lake!
Apesar de estar na boca do povo, construir um Enterprise Data Lake não é uma coisa fácil… Como eu sempre digo: ter um bom Storage distribuído e jogar terabytes de dados nele não basta. Um Data Lake de verdade tem 3 pilares, que vão além do desempenho e custo:
- Segurança — que envolve Auditoria e Governança de Acesso
- Catálogo — que envolve Discovery e Indexação
- Coleta — que envolve Exploração de novas fontes e Enriquecimento
As ferramentas que estão há mais tempo no mercado, são gigantescas, logo morosas para aprender. Consultores Cloudera, MapR ou Teradata são mais raros que Desenvolvedor R feliz (hehehe zoeira, Lages =p).
Porém, uma ferramenta chegou há pouco tempo mostrando que as coisas podem sim ser complexas por dentro, mas fáceis de controlar por fora…
O Fantástico Dremio
Essa plataforma surgiu da experiência de 2 caras que trabalharam anos uma das maiores empresas que trabalham com Big Data do Mundo: o Tomer Shiran e o Jacques Nadeau, ex-MapR. Jacques, inclusive, é um dos criadores e PMC do Apache Drill, ferramenta que faz bem o que o Dremio se propõe a fazer hoje, só que em uma escala menor.
O Dremio é um Barramento de Dados, ou seja, é uma plataforma que unifica as camadas de storage/bancos de dados com interfaces de consulta — como ferramentas de BI, códigos-fonte e etc, igual mostra a figura ao lado. Normalmente, um Databus (termo em inglês) usa um protocolo específico (HTTP, Thrift, protobuf, etc) e uma linguagem única (Python, SQL, GraphQL, etc) para prover a capacidade de recuperação e manipulação de dados de diversas fontes. Exemplos de DataBus são, além do Drill, o AWS Athena, o PrestoDB e o Impala, talvez até o SparkSQL, com algumas ressalvas, mas que desempenham bem este papel dentro do ecossistema Hadoop.
No caso do Dremio, as fontes vão desde arquivos brutos — JSON, CSVs, Parquet — até datastores — MySQL, Mongo, Elastic. O protocolo de acesso é JDBC/ODBC, que por sua vez, proveem dados pra quase toda ferramenta de BI existente atualmente: Tableau, Power BI, Qlik, Dbeaver…— menos o Metabase =(
Como funciona?
Coordinator e Executor Nodes
Como maioria dos clusteres de processamento de dados distribuídos, o Dremio funciona em uma configuração quase que padrão. Roda sobre a JVM, e tem 2 classes de nós:
- Coordinators: São os cérebros: responsáveis pela UI, coordenação entre executores, fase de “Reduce” das queries e guardar os metadados/wiki.
- Executors: São os braços: Responsáveis pelo trabalho pesado, execução da fase de “Map” das queries, processamento e persistência das Reflections na camada de Storage Distribuído e Spilling (caso de queries que são pesadas demais pra se fazer toda operação em memória)
Dá pra se ter um deploy single-node, onde a mesma instancia se porta como Coordinator e Executor ao mesmo tempo. MAS CUIDADO! Um deploy single-node não consegue se transformar em multi-node. Nem mesmo com backup/restore. Tenho discutido isso neste tópico do fórum inclusive.
A ferramenta já foi desenvolvida pra ser independente da camada de storage, assim como no Spark, Presto e outros. Os Executores tem um serviço de leitura/persistência implementada sobre o Apache Arrow, o que dá uma performance absurda, principalmente por estar combinada com o Apache Parquet (falarei mais sobre logo abaixo).
O controle de estado do cluster é feito via Zookeeper, dando a “facilidade” de se ter um numero par de masters elegíveis. A instalação do Dremio já coloca um Zookeeper embeded, porém você pode usar o seu próprio zk, se tiver.
Reflections
O grande poder do Dremio, na minha opinião, vem mesmo das Reflections. Segundo a própria documentação, são:
Representações físicas e otimizadas do dado fonte. O otimizador de query pode acelerar uma consulta utilizando uma ou mais Data Reflection, para satisfazer parcialmente ou completamente essa query, ao invés de processar o dado bruto da fonte subjacente
Simplificando: Imagina que você tem uma tabela MySQL conectada como fonte no Dremio. Você pode configurar para ele fazer o offload dos dados dessa tabela periodicamente para o seu Storage Distribuido (Distributed Storage). Neste caso, o Storage pode ser o S3, um HDFS, um EBS ou Azure Data Lake Storage.
Os arquivos são salvos em Parquet comprimido, seguindo também as configurações de particionamento feitas na própria telinha do Dremio. Imagina que você tem um campo “Categoria” na sua tabela. Você marca ele pra ser particionado e o Dremio vai pra cada categoria no seu dado, criar uma partição no S3.
FUCKING SIMPLES LIKE THAT!!!
As Reflections podem ser de 3tipos:
- Raw: dados brutos, particionados e pré-ordenados, com eficiência para consultas needle in a haystack (drill-down e listagem de dados)
- Aggregation: dados pré-agregados, com granularidade de dia ou mais, de acordo com um campo de data, com eficiência para queries analíticas (groupby + sum/avg/min/max…).
- External: de complexidade bem maior pra criar, mas é uma tabela externa mapeada em outra fonte, fora do Distributed Storage do Dremio.
Outras features
Além disso, ele usa o Apache Calcite, (sim, eu também não conhecia…) uma tool incrível de Álgebra Relacional que otimiza o Query Plan ao ponto de escolher se vale mais a pena recuperar os dados de uma (das várias que podem haver) Reflection Raw, uma Aggregated ou até da fonte direto.
Também tem uma Wiki, que é escrita em Markdown para qualquer Tabela,View ou Space, facilitando e muito a documentação e o discovery de dados.
Onde e como usar?
Com todas essas features, o Dremio se mostra como ferramenta candidata para se organizar boa parte do Data Lake. Apesar da versão Open-Source não ter um bom controle de usuários e o Data Lineage, ele se encaixa por abstrair grandes problemas na estruturação de Data Lakes:
- Offloading de grandes volumes de dados
- Unificação de fontes diversas
- Separação fácil da modelagem física e modelagem lógica do Data Lake
- Facilidade de upload de arquivos para exploração e enriquecimento
E muitos outros. A plataforma é então ideal para a camada de Analytics Sandbox do Data Lake, aquela área onde os Cientistas e Analistas de Dados tem a liberdade de trabalhar seus dados, sem exigir interação constante (e demorada) com os Engenheiros de Dados.
O Dremio não é parrudo o suficiente pra substituir o que chamamos de Transformation Engine, que seria o responsável por fazer ETLs complexos. Mesmo assim, seu SQL é potente e temos utilizado bem suas definições de Virtual DataSets pra organizar várias etapas de transformações, materializando-as ou não.
Se você quer entender mais sobre essas particularidades de Data Lakes, leia esse post e a palestra anexada nele.
Na AWS, sua instalação é simples e bem documentada. Sua integração com o S3 está muito madura e, incrivelmente, funciona melhor que a dupla Athena/Glue, na minha experiência, seja em performance, seja em estabilidade. Tem bastante gente usando em produção, inclusive tem um case brasileiro, construído pelo Paulo na Hotmart, publicado em sua página, olha aí.
Temos utilizado o Dremio em vários projetos na Data Sprints, com resultados realmente impressionantes. Apesar de ser uma ferramenta recente e quase-beta, os ganhos para times que são tecnicamente bem fundamentados — como obviamente é um time de uma consultoria em engenharia de dados — são indiscutíveis. Até lançamos um curso pra espalhar a palavra por aí!
Para entender mais detalhes de como essa plataforma maravilhosa funciona por baixo dos panos e quais são os conceitos que levaram os seus criadores a criá-la, recomendo que você assista a talk do Nadeau no DataEngConf NYU de 2017.
E aí? Bora colocar em produção? Se sim, deixa sua palma aí! Se não, comenta aí quais são os seus medos de se utilizar essa ferramenta que vai revolucionar os times de Engenharia de Dados por aí. Abraço, galera! Até mais!
