DataOps — Escalando a engenharia de dados no Luizalabs
No Magalu, temos uma cultura forte em ser data driven. Este é um ponto muito importante nas tomadas de decisões dentro da empresa e consequentemente gera expectativa sobre a qualidade do ciclo de vida dos dados, desde a aquisição até a disponibilização do mesmo. O objetivo deste artigo é compartilhar como endereçamos os desafios de escalar a engenharia de dados através de uma PLATAFORMA usando DataOps.
DataOps is a collaborative data management practice focused on improving the communication, integration and automation of data flows between data managers and data consumers across an organization. The goal of DataOps is to deliver value faster by creating predictable delivery and change management of data, data models and related artifacts. DataOps uses technology to automate the design, deployment and management of data delivery with appropriate levels of governance, and it uses metadata to improve the usability and value of data in a dynamic environment.
https://www.gartner.com/en/information-technology/glossary/dataops
Organização e responsabilidades
O componente chave para conseguirmos escalar a engenharia de dados numa empresa do tamanho do Magalu, que possui centenas de sistemas, databases, serviços entre outros componentes de uma arquitetura de micro serviços, é justamente a construção de uma plataforma de dados.
No labs, a squad Data Engineering (DE) é responsável pela construção e manutenção dessa plataforma, através dela podemos dar a autonomia necessária para que outras squads e as áreas de negócio interajam com os dados da empresa. Essa autonomia é importante, pois nos ajuda a democratizar o acesso aos dados, além de distribuir a responsabilidade sobre os pipelines, tanto no desenvolvimento quanto na sustentação. Um exemplo dessa autonomia é a responsabilidade de enviar dados para o Lake ser da própria squad responsável pelos sistema, e não do time de DE.
Entretanto, essa abordagem possui alguns trade offs. Quando falamos sobre governança por exemplo, uma consequência da autonomia dos times é a criação de vários datasets no lake com o mesmo dado, porém de diferentes origens, isso nos leva a segunda responsabilidade do time de DE, que é a criação e zeladoria pelos datasets que chamamos de SSOT (single source of truth), que possuem os dados “oficiais” dos principais assuntos da empresa. Algumas literaturas chamam esses datasets de “Master Data”:
Master data is the consistent and uniform set of identifiers and extended attributes that describes the core entities of the enterprise including customers, prospects, citizens, suppliers, sites, hierarchies and chart of accounts.
https://www.gartner.com/en/information-technology/glossary/master-data-management-mdm
Quando falamos sobre essa autonomia dos times, uma pergunta comum é: todas as pessoas que precisam dos dados terão que aprender a usar as tecnologias do ecossistema de Big Data?
Minha resposta é: depende.
Pense no cenário em que um usuário de negócio precise de um dado que está na tabela “X” para criar um relatório ou um dashboard. O caminho seria:
1- Solicitar ao time que sustenta o sistema responsável por essa tabela a inclusão da mesma no lake.
2- O dev que pegar essa atividade cadastra em um arquivo yaml o nome da tabela com algumas informações sobre o database.
Pronto o dado fica disponível no lake para o usuário de negócio consumir com sua ferramenta preferida, seguindo todos os padrões que foram pré-estabelecidos pelo time de DE, o mesmo dataset é cadastrado no catálogo de dados corporativo, e a cada nova execução um processo de quality checa se houve algum desvio nos metadados desse dataset para identificar possíveis problemas com os dados.
Perceba que nesse cenário não foi necessário conhecimento sobre nenhum tipo de tecnologia do ecossistema de Big Data, e a plataforma fez praticamente tudo após o cadastro da tabela no yaml.
Agora, num cenário mais complexo onde, por exemplo, seja necessário processar terabytes de dados, cruzar diferentes datasets e disponibilizar o resultado disso para sua aplicação web acessar, o dev terá que aprender um pouco sobre spark, mas mesmo assim a plataforma o ajudará nessa curva de aprendizagem, principalmente no provisionamento da infra para executar seu pipeline.
Para que esse modelo funcione é muito importante que todos os times tenham um canal aberto com o time de DE e as funcionalidades da plataforma sejam bem definidas e documentadas.
A Plataforma
Legal, mas o que é essa plataforma? O que ela faz? E como ela faz isso? Vamos tentar esclarecer esses pontos.
Chamamos de plataforma de dados um conjunto de projetos que desenvolvemos no time de Engenharia de Dados para democratizar o uso do dado na empresa, e ao mesmo tempo garantir escala, governança, segurança, performance, monitoria, qualidade e principalmente facilitar a interação de pessoas que nunca tiveram contato com tecnologias de dados, tais como Spark, Airflow, Hadoop, etc.
Abaixo alguns dos principais projetos da nossa plataforma :
Obs.: Todos os projetos de DE são batizados em homenagem ao universo dos games.
Arcade
É um bot no slack responsável pela criação de um ambiente de exploração de dados baseado em Jupyter e Spark. Basta você mandar um “create cluster” e em 5 min seu cluster está no ar.
Sness-lib
Responsável por toda interação que o usuário tem com o lake, essa lib é o coração da plataforma. Através da Sness-Lib podemos estabelecer diversos padrões que entendemos ser boas práticas para trabalhar com dados, por exemplo fixar o formato parquet quando um dataset for criado no lake, versionar o dataset sempre que o mesmo for escrito, anonimizar dados sensíveis, entre outros. Dentro do Airflow, podemos ainda importar operadores customizados e criar clusters otimizados para a necessidade de cada usuário. As possibilidades são infinitas aqui, e é o lugar que direcionamos os principais pontos sobre governança e segurança dos dados.
Alguns exemplos para ilustrar:
from sness import SnessSparkss = SnessSpark()# Retorna um dataframe spark
df = ss.read.parquet(
environment='PROD',
zone='TRUSTED',
namespace='exemplo_namespace',
dataset='exemplo_dataset'
)# Aplica alguma transformacao
df_2 = df.filter('Exemplo de regra de negocio')# Gravar dataset refinado no lake
ss.write.parquet(
dataframe=df_2,
environment='PROD',
zone='REFINED',
namespace='exemplo_namespace',
dataset='exemplo_dataset_refinado',
mode='overwrite'
)
Sness-CLI
Utilitário cli que os usuários instalam localmente para interagir com a plataforma. Suas funções são:
- Criar pipeline: cria uma estrutura de códigos para uma DAG no Airflow localmente seguindo os padrões já estabelecidos pela plataforma, dessa forma o usuário adiciona sua lógica no meio e já pode deployar seu pipe.
- Deploy de pipeline: sobe o pipe local para o servidor Airflow
- Cria job sqoop : comando em que o usuário responde algumas perguntas para criar um job no sqoop metastore. (Atualmente estamos desligando o sqoop e migrando para o Witcher)
Witcher
Projeto de ingestão automática de dados no lake. Atualmente suporta as origens Kafka, databases (JDBC) e csv. Nele, os usuários cadastram as informações em um yaml e o Witcher automaticamente cria uma DAG no Airflow, que executará no schedule determinado e carregará os dados no lake. Ex.:
Ingestão via Kafka :
pipeline_1
namespace_1:
scheduler_time: ‘0 */6 * * *’
tables:
table_1:
topic: ‘topic_name_1’
ignore_columns: [“customer_name”]
send_to_bq: ‘true’
table_2:
topic: ‘topic_name_2’
ignore_columns: “”
send_to_bq: ‘true’Ingestão via JDBC:
pipeline_2:
namespace_2:
scheduler_time: ’10 */6 * * *’
connection_name: ‘conn_name’
tables:
table_1:
topic: ‘’
ignore_columns: [“message”]
full_charge_table_name: ‘table_1’
run_once: ‘true’
send_to_bq: ‘true’
table_2:
topic: ‘’
ignore_columns: []
full_charge_table_name: ‘table_2’
run_once: ‘true’
send_to_bq: ‘true’Niagara
Projeto para ingestão de eventos em tempo real no lake. Basta plugar o Niagara em um tópico que o dado ficará disponível no lake. Diferente do Witcher que executa mini batches Spark, o Niagara é baseado no Dataflow (Apache Beam).
Pacman
Job responsável por cadastrar os datasets no nosso catalogo de dados.
DataDix
Nosso catálogo de dados. Fizemos uma implementação baseada no CKAN e o customizamos de acordo com as nossas necessidades.
Conclusão
Com esse modelo de trabalho conseguimos agilizar a entrega do dado para os usuários, evitamos que a squad de DE seja um gargalo na empresa e estabelecemos padrões dentro da plataforma que aumentaram nosso nível de governança, performance e segurança dos pipelines.
Cada projeto endereça algum ponto específico sobre o fluxo de vida dos dados dentro do Magalu, e ficaria muito extenso detalhar aqui todas as funcionalidades, métodos e parâmetros de cada um deles, mas o importante é passar a vocês o objetivo de cada um. A interação entre eles formam a nossa plataforma que utiliza o conceito de DataOps para automatizar diversos pontos desde a aquisição até a disponibilização dos dados para o cliente. O desenvolvimento da plataforma é um trabalho constante, sempre estamos pensando em algo que podemos automatizar para trazer mais qualidade aos processos buscando alcançar nosso principal objetivo, que é democratizar o acesso ao dado dentro do Magalu com escala, qualidade e segurança.
