Como o Apache Hudi transformou o data lake de Yuno

Descubra como a Yuno transformou sua infraestrutura de dados com o Apache Hudi, otimizando o desempenho do data lake, reduzindo os custos em 70% e permitindo insights de dados em tempo real. Saiba como os recursos avançados do Hudi, como viagem no tempo, indexação e gerenciamento automatizado de arquivos, melhoraram a eficiência e a escalabilidade, revolucionando a estratégia de gerenciamento de dados da Yuno.

Como chefe de dados da Yuno, testemunhei em primeira mão os desafios e as oportunidades que surgem com o gerenciamento de uma infraestrutura de dados moderna. Os dados estão no centro de tudo o que fazemos, gerando insights, decisões e inovações em toda a empresa.

No entanto, com o aumento do volume e da complexidade dos dados, enfrentamos obstáculos significativos para manter a eficiência, a consistência e a relação custo-benefício. Portanto, nosso objetivo principal era aprimorar nossos recursos de gerenciamento de dados. Precisávamos de uma solução que pudesse oferecer melhor controle sobre nossas tabelas, melhorar o desempenho e oferecer um alto grau de organização.

Os critérios para nosso novo sistema eram claros: ele tinha que ser compatível com ACID (compatível com atomicidade, consistência, isolamento e durabilidade) e capaz de lidar com problemas e exclusões de forma eficiente. Depois de avaliar várias opções, o Apache Hudi surgiu como a escolha ideal.

O Apache Hudi é uma estrutura de data lake que simplifica o gerenciamento de dados no armazenamento em nuvem ao permitir a ingestão, atualizações e exclusões eficientes em grandes conjuntos de dados. Ele também oferece benefícios como ingestão incremental e excelente compatibilidade com fontes de dados em tempo real.

Alta personalização em diferentes casos de uso

Antes de mergulhar em estratégias específicas, é importante entender a flexibilidade que o Apache Hudi oferece em diferentes casos de uso. Se sua prioridade é otimizar o desempenho de leitura ou gravação, o Hudi oferece opções personalizadas para suas necessidades específicas.

1. COW e MOR

O Apache Hudi oferece uma ampla gama de opções, mas a escolha mais fundamental que você fará é selecionar o tipo de mesa que melhor atenda às suas necessidades. Essa decisão depende se você deseja priorizar o desempenho de leitura ou escrita.

Se você precisa de um desempenho de escrita mais rápido e pode tolerar leituras mais lentas, a estratégia MOR (Merge on Read) é a melhor opção.

Se você quiser otimizar para leituras mais rápidas em detrimento de gravações mais lentas, use a estratégia COW (Copy on Write).

2. Partições não bastam, e quanto ao INDEX?

Embora a escolha entre COW e MOR seja fundamental, é apenas uma peça do quebra-cabeça. À medida que os conjuntos de dados crescem, o particionamento sozinho não é suficiente para garantir o desempenho. É aqui que a indexação se torna um fator crucial para melhorar a eficiência das consultas e reduzir a latência.

Ao lidar com grandes conjuntos de dados, desafios comuns geralmente surgem com operações como atualizações, atualizações ou leitura de linhas específicas. Particionar sua tabela é essencial, mas é apenas o ponto de partida. À medida que seus dados crescem, até mesmo as tabelas particionadas podem se tornar grandes, e você precisará identificar com eficiência qual partição contém a linha específica que você está procurando.

Para reduzir a latência, minimizar a quantidade de dados lidos e melhorar o desempenho da consulta, você precisará de mais do que apenas partições — você precisará considerar a indexação. É aqui que o Apache Hudi brilha, oferecendo suporte robusto para indexação multimodal.

Entre as várias estratégias de indexação que a Hudi fornece, a Índice de nível de registro (RLI) se destaca. O RLI aproveita o HBase, um armazenamento de valores-chave dentro da pasta de metadados, oferecendo um desempenho de pesquisa excepcional em comparação com outros índices globais.

No entanto, nem todo caso de uso exige um índice global. Para essas situações, o Hudi oferece alternativas eficientes, como as conhecidas Índice Bloom, adaptado para necessidades específicas sem a sobrecarga de um índice global.


3. Manutenção de mesas

Além da indexação, manter suas tabelas de forma eficaz é essencial para a otimização do desempenho a longo prazo. Isso inclui garantir um gerenciamento eficiente de arquivos, como dimensionamento, agrupamento, limpeza e compactação de arquivos. Vamos examinar mais de perto como esses recursos contribuem para manter seu processamento de dados tranquilo e eficiente.

O serviço de clustering é tão crucial quanto a indexação quando se trata de desempenho. Os mecanismos de consulta funcionam com mais eficiência quando os dados consultados com frequência são ordenados fisicamente. O Apache Hudi oferece suporte nativo ao agrupamento com uma variedade de estratégias para atender a diferentes necessidades.

O serviço de dimensionamento de arquivos aborda problemas comuns, como arquivos pequenos, que podem diminuir significativamente o desempenho de leitura em data lakes. Quando as tabelas são fragmentadas em muitos arquivos pequenos, as consultas exigem mais solicitações, o que aumenta o tempo de processamento. O tamanho adequado do arquivo também melhora compactação, pois arquivos mal dimensionados podem levar a uma compactação ineficiente e, consequentemente, a maiores requisitos de armazenamento.

O serviço de limpeza é importante para recuperar o espaço ocupado por versões desatualizadas dos dados. Ao limpar as versões antigas, você pode liberar espaço de armazenamento e manter uma estrutura de mesa mais eficiente.

Todos esses recursos são totalmente suportados pelo Apache Hudi. Você pode executar esses processos em linha (como parte do seu pipeline) ou de forma assíncrona como trabalhos separados, dependendo de seus requisitos específicos.

4. Viagem no tempo para depuração e auditoria de dados

Além das otimizações de desempenho, o recurso de viagem no tempo do Hudi agrega outra camada de valor ao melhorar a integridade dos dados e permitir depuração e auditoria eficientes. Esse recurso desempenha um papel fundamental na manutenção da qualidade dos dados ao longo do tempo.

Um dos recursos de destaque do Apache Hudi é seu viagem no tempo capacidade, que permite reverter para versões anteriores das tabelas. Esse recurso revolucionou nossos processos de depuração e auditoria de dados, melhorando significativamente a eficiência de nossas operações de controle de qualidade. A capacidade de acessar e revisar os estados históricos dos dados nos permitiu identificar e resolver problemas rapidamente, aprimorando, em última análise, a integridade geral dos dados.

5. Exemplo de COW na vida real

Para entender melhor como uma tabela COW (Copy on Write) opera com agrupamento e limpeza em linha, veja o exemplo abaixo. Esse exemplo também pode servir como uma referência prática ao implementar configurações semelhantes em seu próprio ambiente.

Superando os desafios de implementação

Como acontece com qualquer tecnologia avançada, a implementação do Apache Hudi traz seu próprio conjunto de desafios. No nosso caso, a complexidade do Spark e a abundância de novas opções de Hudi apresentaram algumas dificuldades. Para resolver isso, desenvolvemos modelos para a maioria dos nossos casos de uso e incorporamos o DBT (Data Build Tool) em nosso fluxo de trabalho.

Essa abstração nos permitiu aproveitar totalmente o Spark SQL e suas funções integradas de alto desempenho sem nos sobrecarregarmos com as complexidades do Spark. Ao criar modelos reutilizáveis, reduzimos significativamente o tempo de desenvolvimento e mantivemos a consistência em nossos canais de processamento de dados.

Além disso, estruturamos nosso data lake seguindo a arquitetura medallion, que normalmente inclui:

The image illustrates Yuno's data lake medallion architecture at the 'Landing' stage.
A imagem ilustra a arquitetura do medalhão do data lake de Yuno no estágio de “Landing”.

Landing

Armazenamos os dados brutos sem nenhuma transformação e com a extensão original, se aplicável.

The image illustrates Yuno's data lake medallion architecture at the 'Raw' stage.
A imagem ilustra a arquitetura do medalhão de data lake de Yuno no estágio "Raw".

Raw

Convertemos os dados para o formato Parquet para consumo, mas não realizamos nenhum outro tipo de transformação de dados.

The image illustrates Yuno's data lake medallion architecture at the 'Master' stage.
A imagem ilustra a arquitetura do medalhão de data lake de Yuno no estágio "Master".

Master

Temos nossas tabelas Hudi, e a fonte pode ser uma tabela bruta ou uma tabela Hudi mestre para criar um novo modelo.

Essa estrutura, junto com o DBT, garante um processamento eficiente de dados e suporta nossas crescentes cargas de trabalho.

Como gerenciamos nossos recursos

Gerenciar recursos com eficiência é fundamental para garantir a escalabilidade à medida que suas operações de dados crescem. Para facilitar isso, criamos perfis personalizados em nosso repositório DBT para alocar recursos com base no tamanho e na complexidade da carga de trabalho.

Para gerenciar nossos recursos com eficiência, criamos perfis diferentes — XS, S, M, L e XL — no arquivo profiles.yml em nosso repositório DBT. Esses perfis nos permitem alocar recursos adequadamente com base no tamanho e na complexidade da carga de trabalho, garantindo um desempenho eficiente e escalável em vários casos de uso.

Integração com o AWS Glue e criação de modelos para abstrair a complexidade do Spark e do Hudi

Depois de abordar os desafios iniciais, buscamos simplificações adicionais. A integração do conector dbt-glue nos permitiu abstrair as complexidades do Spark e do Hudi, proporcionando mais controle e eficiência em nossas operações.

O cola dbt O conector eliminou a necessidade de gerenciar um cluster Spark, permitindo que executássemos tudo sem problemas no AWS Glue. Para agilizar ainda mais nossas operações, adaptamos nosso repositório DBT com um garfo do conector dbt-glue para melhor atender aos nossos requisitos de Hudi. Ao criar modelos predefinidos, simplificamos o processo de implementação e adaptamos nossa configuração para funcionar com a versão 0.14.1 do Hudi.

Durante todo esse processo, identificamos opções importantes, como Índice de nível de registro (RLI), Sincronização do Glue Data, e tamanhos mínimos e máximos de arquivo que são comumente usados em nossos fluxos de trabalho. Essas opções podem ser incorporadas ao seu código para personalizar seus próprios modelos e otimizar suas operações.

Ao usar o Conector AWS Glue, reduzimos significativamente a complexidade do gerenciamento do Spark e do Hudi, mantendo o alto desempenho e a flexibilidade.

Orquestração e resultados da implementação do Hudi

Para garantir fluxos de trabalho suaves e automatizados, usamos o Airflow para orquestração, o que simplificou o agendamento e o monitoramento de tarefas. Isso, combinado com nossa configuração do AWS Glue, nos ajudou a obter melhorias significativas de desempenho e reduções de custos.

Para gerenciar nossos fluxos de trabalho de dados com eficiência, usamos Fluxo de ar para orquestração, garantindo operações suaves sem complicações desnecessárias. Ao aproveitar o Airflow, conseguimos programar, monitorar e gerenciar com eficiência nossos trabalhos de ETL com facilidade.

Emparelhado com AWS Glue, obtivemos acesso a um ambiente escalável e sem servidor que eliminou a necessidade de gerenciamento manual da infraestrutura, permitindo que nos concentrássemos em nossas tarefas de processamento de dados. Essa combinação de ferramentas ajudou a otimizar nossas operações e otimizar o desempenho.

Os resultados da implementação do Apache Hudi foram impressionantes. Ao incorporar os recursos avançados do Hudi, vimos quase Redução de 70% nos custos em nossos processos que mais demandam recursos. Os recursos do Hudi, como viagem no tempo, indexação e gerenciamento de arquivos, melhoraram drasticamente nossa eficiência no gerenciamento de dados. Isso não só nos ajudou a cortar custos, mas também melhorou o desempenho geral do nosso pipeline de dados, tornando-o mais escalável e econômico.

Planos futuros: migrar cargas de trabalho para o data lake

Com essas otimizações implementadas, nosso foco agora está no futuro. Planejamos migrar cargas de trabalho de alto desempenho para o data lake, uma medida projetada para reduzir ainda mais os custos e melhorar a escalabilidade.

No futuro, planejamos migrar cargas de trabalho de alto desempenho do nosso armazém Snowflake para o data lake. Essa mudança estratégica visa reduzir ainda mais os custos e permitir que o Snowflake leia diretamente do data lake para determinados modelos, otimizando assim nossos recursos e aumentando a eficiência. Ao mover essas cargas de trabalho, esperamos aproveitar a escalabilidade do nosso data lake e, ao mesmo tempo, manter os recursos analíticos do Snowflake.

Nossa visão definitiva é evoluir para um lago de dados, integrando todas as operações de dados em toda a empresa. Essa plataforma unificada impulsionará insights e inovação, promovendo uma cultura baseada em dados em toda a organização. Um data lakehouse combina os melhores recursos de data lakes e data warehouses, fornecendo uma plataforma única para cargas de trabalho analíticas e operacionais. Essa integração nos permitirá gerenciar nossos dados com mais eficiência e obter insights acionáveis em tempo real.

A melhor parte é que já estamos trabalhando em nossa próxima etapa e com dados em tempo real em nosso data lake usando o HoodieStreamer, outra ótima ferramenta da Hudi. Esse avanço nos permitirá aproveitar os insights de dados em tempo real, impulsionando nossas operações a novos patamares. O processamento de dados em tempo real nos permite reagir às mudanças instantaneamente, melhorando nossos processos de tomada de decisão e eficiência operacional.

À medida que continuamos inovando e otimizando nossa infraestrutura de dados, continuamos comprometidos em aproveitar tecnologias de ponta para impulsionar a eficiência e promover o crescimento. Se você tiver alguma dúvida ou quiser saber mais sobre nossa experiência, sinta-se à vontade para entrar em contato.