Fazendo beleza com dados em nuvem: a acelerada jornada de dados do Grupo Boticário
No final de janeiro de 2020, iniciei no Grupo Boticário com um desafio gigantesco: não somente estruturar uma área nova, mas também entender todo o cenário atual de dados da empresa, mapear quem eram as pessoas chave que precisavam ser ouvidas e envolvidas no processo, definir a nuvem pública que utilizaríamos, contratar e formar a equipe, desenvolver parceiros e construir a nova plataforma de dados da empresa.
Entendendo o cenário e conhecendo as pessoas
Logo nas primeiras semanas, reunimos diversas áreas técnicas e não técnicas para entender como a empresa vinha atuando com dados até o momento.
Fizemos uma dinâmica de 3 dias, na qual exploramos vários aspectos para mapearmos o que já tínhamos de bom dentro do nosso cenário on-premises e o que as equipes vinham produzindo com dados. Aproveitamos também para entender de forma macro quais eram as principais dores que precisávamos atacar.
Logo de início, foi notável que tínhamos muita gente competente trabalhando com dados no grupo, porém, de uma forma desconexa, em silos. A empresa tem várias unidades de negócio e todas elas tinham bastante autonomia. Tal autonomia possibilitou o crescimento acelerado da empresa nos anos anteriores. Entretanto, estávamos em um momento em que era preciso conectar as pontas e olhar os dados de forma cross, utilizando-os de forma estratégica, como um grande impulsionador para a inovação e tomada de decisão.
Outro fato constatado nessas conversas iniciais foi o potencial e a complexidade da cadeia de dados que tínhamos pela frente. O Grupo Boticário é um parque de diversão para quem gosta de dados, pois possui os mais variados contextos para serem explorados. É como termos vários segmentos de atuação do mercado dentro uma única empresa. Para exemplificar, cito alguns a seguir:
- Dados históricos de pesquisa e desenvolvimento para essências utilizadas nos produtos desenvolvidos;
- Dados de indústria 4.0 e IoT, pois temos fábricas e produzimos os nossos produtos;
- Dados de logística e abastecimento, pois distribuímos não só para todo Brasil, como para outros 15 países;
- Dados de varejo, pois atuamos em canais como lojas, venda direta, comércio eletrônico e B2B;
- Dados de marketing e comunicação;
- Dados financeiros, pois temos uma fintech no grupo, a Mooz;
- Dados de colaboradores, pois somos mais de 40 mil (diretos e indiretos).
Tecnologias para todos os gostos
Quando olhamos para o cenário tecnológico, tínhamos as mais variadas tecnologias sendo utilizadas dentro da empresa. Porém, nem todas sendo suportadas pelo time de tecnologia. Em um breve levantamento que realizamos, algumas das tecnologias que mapeamos em nosso ambiente on-premises foram:
- SAP BW Hana;
- SAP Data Services;
- IBM Netezza;
- Microsoft SSIS;
- UC4;
- SPSS;
- Alteryx;
- Knime;
- Qlik;
- Power BI;
- Metabase;
- E, claro, o outro SAP: “Sistema Avançado de Planilhas”.
Arquitetura inicial
Basicamente, tínhamos diversas origens de dados sendo integradas e consolidadas em um ambiente SAP Hana on-premises. Os processos de ETL sendo realizados através do SAP Data Services e distribuindo dados para uma base analítica em um appliance IBM Netezza, disponibilizando dados para diversas aplicações de dashboards.
Processo de escolha da nuvem pública que suportaria nossa plataforma de dados
Uma vez entendidas as principais dores, os perfis de usuários e profissionais de dados que tínhamos na empresa e todo o contexto de ferramental que possuíamos, estruturamos nosso processo de definição do nosso futuro parceiro de nuvem para suportar a nova plataforma de dados.
O primeiro passo foi elencar os pré-requisitos e descrevê-los em um formato de RFP (Request For Proposal). Para isso, consideramos não somente os inputs que tivemos de todas as áreas, mas também documentações e reuniões com especialistas da Gartner. Também elencamos um case de negócio que seria utilizado pelas cloud providers para desenvolver uma prova de conceito (PoC). A definição deste case foi realizada por meio de votação pelas áreas naqueles 3 dias iniciais de dinâmica.
Na sequência, selecionamos os fornecedores que gostaríamos que participassem do processo e tivemos agendas para apresentação de toda gama de ferramentas relacionadas a dados, analytics e machine learning. Tanto as áreas técnicas como as não técnicas tiveram a oportunidade de participar e entender as características e benefícios das ferramentas.
Com os participantes familiarizados com os conceitos e potencial das ferramentas, foi a hora de ver na prática como seria a dinâmica. Disponibilizamos uma semana para cada fornecedor desenvolver o case, que se tratava de um modelo de score de crédito, enquanto permeávamos desde o processo de ingestão de dados, processamento, treinamento, atribuição de score e consumo da informação por meio de consultas simples ou disponibilização de serviços e APIs. Durante o desenvolvimento da PoC pelos fornecedores, tivemos pessoas das áreas técnicas e não técnicas participando conjuntamente.
Por fim, ponderamos todos os prós e contras de cada plataforma e tomamos a decisão de seguir com o desenvolvimento de nossa plataforma no Google Cloud.
O desafio ficou maior com a chegada da pandemia
Nosso processo de avaliação da plataforma finalizou exatamente na semana que iniciou a pandemia. Com isso, veio o direcionamento da empresa para que todos os colaboradores passassem a atuar de forma remota. Naquele momento, o time de Engenharia de Dados contava com a minha liderança, um arquiteto de dados que acabara de se transferir para a área e outro arquiteto recém-contratado (que até o presente momento não tive a oportunidade de conhecer pessoalmente - aliás, nossas áreas atuam seguindo o modelo remote first, mesmo após a pandemia - mas isso deixamos para um outro papo). Entramos, então, em um processo de negociação com o Google, ao mesmo tempo em que os projetos e a estratégia da nossa empresa eram revisitados considerando os impactos causados pela pandemia.
Somente em julho de 2020 conseguimos, de fato, viabilizar o projeto e botar a mão na massa, ou melhor dizendo, na cloud! Porém, durante o período em que a negociação e as priorizações ocorriam, trabalhamos fortemente no planejamento do que teríamos pela frente. E aproveitamos o tempo para definir questões de governança, conectividade, padrões de ferramentas, estratégia de migração de dados, priorização de roadmap e principalmente de toda a parte de fundação necessária quando se inicia o uso de nuvem em uma grande organização.
Mas afinal, o que estamos utilizando atualmente?
Desde o segundo semestre de 2020 estamos atuando forte na migração e integração de dados, levando todo o workload analítico para a plataforma; Começamos a liberar visões para áreas de negócios e já temos centenas de pessoas acessando a plataforma GCP. Aos poucos estamos desidratando a arquitetura inicial apresentada acima, tendo o BigQuery como principal serviço de consulta e armazenamento de dados; inclusive, com capacitações ocorrendo para as áreas de negócio.
O conjunto de ferramentas utilizadas no dia a dia pelas nossas pessoas de engenharia de dados, basicamente, resume-se a:
- Linguagens: Pyhton, SQL e PySpark;
- BigQuery;
- Cloud SQL;
- Composer (Airflow);
- Dataflow (Apache Beam);
- Data Fusion (CDAP);
- Dataflow;
- Pub/Sub;
- Cloud Build;
- DataCare (ferramenta de deduplicação);
- SAP Data Services (para ingestão de dados de origem SAP).
Organização e visibilidade
Desde o início, quando começamos estruturar a parte de fundação da plataforma de dados, cuidamos da flexibilidade para segmentar a organização dos projetos, de forma que tivéssemos a possibilidade de compartilhar o que seria de uso comum e separar por áreas ou projetos o que deveria seguir de forma apartada. Para isso, lançamos mão dos recursos de hierarquia do GCP, representados abaixo:
Além disso, integramos os grupos do nosso active directory com os recursos do Google Cloud IAM. Assim, os responsáveis por cada área administram os seus respectivos grupos de usuários e nossa equipe de Engenharia de Dados fica responsável por atribuir e administrar as permissões que cada grupo pode ter aos recursos da plataforma.
E os times, como estão organizados?
Nossa estrutura de Engenharia e Arquitetura de Dados atua como um chapter, de forma cross, apoiando todas as áreas da empresa. O time, que começou apenas comigo, um ano e meio depois cresceu muito e deve ultrapassar a marca de 80 colaboradores ainda em 2021. Nos organizamos em squads que, por sua vez, possuem os seguintes papéis:
- Data Squad Leader: responsável pela gestão da squad;
- Data Product Owner: responsável pelo entendimento, detalhamento, catalogação e priorização das demandas relacionadas à engenharia de dados;
- Data Engineer: responsável por todos os pipelines de ingestão, processamento e disponibilização de dados;
- Data Architect: responsável pela definição dos padrões e ferramentas utilizadas para cada projeto;
- Data Reliability Engineer: responsável por toda a parte de automação de esteiras, confiabilidade, segurança, escalabilidade e disponibilidade da plataforma.
Em um outro artigo abordamos, com mais detalhes, os papéis dentro do time de Engenharia de Dados e também das áreas pares que fazem parte de nossa diretoria. Essas áreas são Data Science, BI & Analytics e CoE (Center of Excellence).
Onde estamos e para onde iremos?
Desde o início de 2021 começamos dar escala no onboarding de novas áreas que começaram a utilizar a plataforma. Continuamos atuando forte no processo de migração e integração de novas origens de dados (atualmente já temos mais de 2 mil objetos em nossa camada de dados brutos) e estamos migrando nossos modelos de machine learning para GCP.
Além disso, temos diversos projetos em andamento, desde a ingestão de dados até a implementação de esteiras de MLOps e modelos, criação de frameworks de automação e muito mais.
Ficou interessado? Fica ligado no Medium gb.tech que estamos lançando conteúdos focados em dados e explorando com maiores detalhes tudo que permeamos nesta publicação!
