Como o Druid permite análises no Airbnb

Análise em tempo real e em lote no Airbnb e o papel que o Druid desempenha em nossa arquitetura de sistema de análise

Pala Blocked Unblock Seguir Seguindo 13 de novembro de 2018

Por Pala Muthiah e Jinyang Li

Wikipedia: Um druida era um membro da classe profissional de alto escalão em antigas culturas celtas. Acredita-se que os druidas realizam rituais secretos nas florestas, ao contrário desta experiência única no Airbnb !

O Airbnb atende a milhões de convidados e anfitriões em nossa comunidade. A cada segundo, suas atividades no Airbnb.com, como pesquisas, reservas e mensagens, geram uma enorme quantidade de dados que anonimizamos e usamos para melhorar a experiência da comunidade em nossa plataforma.

A Equipe da Plataforma de Dados da Airbnb se esforça para aproveitar esses dados para melhorar as experiências de nossos clientes e otimizar os negócios da Airbnb. Nossa missão é fornecer infra-estrutura para coletar, organizar e processar esse dilúvio de dados (tudo de forma segura para a privacidade) e capacitar várias organizações em todo o Airbnb para obter análises necessárias e tomar decisões informadas a partir dele.

A principal maneira como a análise de alto nível é exposta e compartilhada na empresa é por meio de vários painéis. Muitas pessoas usam esses painéis todos os dias para tomar várias decisões. Os painéis também permitem rastreamento em tempo real e monitoramento de vários aspectos de nossos negócios e sistemas. Como resultado, a pontualidade desses painéis é fundamental para o funcionamento diário do Airbnb. No entanto, nos deparamos com três desafios:

Primeiro, levaria muito tempo para agregar dados no warehouse e gerar os dados necessários para esses painéis usando sistemas como Hive e Presto no momento da consulta. O Hive / Presto precisa ler todos os dados e agregá-los sob demanda, resultando em todo o cálculo necessário sendo chamado no momento da consulta. Mesmo que esses mecanismos sejam usados para pré-computar a agregação e armazená-los, o formato de armazenamento não é otimizado para o fatiamento repetido e o corte de dados que as consultas analíticas exigem.

Em segundo lugar, o sistema precisa ser confiável e escalável. Ele está potencializando os casos de uso do analytics principal na Airbnb, portanto, qualquer tempo de inatividade terá um impacto severo nos negócios e em seus funcionários. Além disso, o volume de dados, consultas e usuários continua a crescer e nosso sistema de análise deve ser capaz de lidar com a crescente demanda.

Terceiro, precisamos de um sistema que se integre bem à nossa infraestrutura de dados baseada em estruturas de código aberto. Por exemplo, a maioria dos nossos conjuntos de dados são armazenados no Hadoop e usamos o Kafka e o Spark Streaming para processar nossos fluxos de dados.

É aqui que entra o druida .

Vantagens do Druida

Tempo de consulta rápida

Com fontes de dados predefinidas e agregações pré-calculadas, o Druid oferece latência de consulta abaixo do segundo. Os painéis construídos em cima do Druid podem ser notavelmente mais rápidos do que aqueles construídos em outros sistemas. Comparado a Hive e Presto, Druid pode ser uma ordem de grandeza mais rápida.

Arquitetura que oferece confiabilidade e escalabilidade

A arquitetura de druida é bem separada em diferentes componentes para ingestão, serviço e coordenação geral. Descobrimos que essa arquitetura componentizada é confiável e estável para nossa carga de trabalho e nos permitiu dimensionar o sistema com facilidade, conforme necessário.

A arquitetura do Druid de separar o armazenamento de dados em armazenamento profundo para armazenamento a longo prazo de dados enquanto o armazenamento em cache dos dados temporariamente no nó histórico funcionou bem para nós. Manter os dados analíticos permanentemente no S3 nos oferece recuperação de desastres gratuitamente e nos permite gerenciar facilmente a atualização e a manutenção do hardware do cluster (por exemplo, alternar facilmente os tipos de nós para aproveitar o hardware mais recente).

Integração com Open Source Frameworks

O Druid também se integra perfeitamente à infraestrutura de dados de código aberto baseada principalmente no Hadoop e Kafka:

  1. A API do Druid nos permite facilmente ingerir dados do Hadoop para análises em lote
  2. O Druid permite análises em tempo real por meio de mecanismos de processamento de fluxo. O Druid fornece uma API cliente de streaming, Tranquility, que é integrada aos mecanismos de streaming, como Samza ou Storm, e pode ser integrada a qualquer outro mecanismo de streaming baseado em JVM. Na Airbnb, a ingestão contínua de dados no Druid para análise em tempo real é implementada através de tarefas do Spark Streaming empregando o cliente Tranquility.
  3. O Druid está bem integrado ao Apache Superset , um sistema de visualização de dados de código aberto desenvolvido e aberto pela Airbnb. Superset serve como interface para que os usuários componham e executem consultas de análise no Druid e visualizem os resultados.

Como o Airbnb usa o Druid: Dual Cluster Configuration

No Airbnb, dois clusters de druida estão sendo executados em produção. Dois clusters separados permitem suporte dedicado para diferentes usos, mesmo que um único cluster Druid possa manipular mais fontes de dados do que o que precisamos. No total, temos 4 Corretores, 2 Senhores Suspensos, 2 Coordenadores, 8 Gerentes Intermediários e 40 nós Históricos. Além disso, nossos clusters são suportados por um servidor MySQL e um cluster ZooKeeper com 5 nós. Os clusters de druida são relativamente pequenos e de baixo custo, comparando com outros clusters de serviço, como HDFS e Presto.

Dos dois clusters Druid, um é dedicado a serviços de métricas críticas centralizadas . Com o objetivo de atender a todos os painéis do Airbnb, os usuários podem definir facilmente suas métricas por meio de arquivos YAML simples. Os usuários podem visualizar seus painéis e métricas no Superset sem saber nada sobre o Druid.

Todos os trabalhos em lote são agendados com o Airflow , ingerindo dados do nosso cluster do Hadoop.

Todas as fontes de dados em tempo real e outras para usuários de autoatendimento são manipuladas pelo outro cluster do Druid. Os dados em tempo real são processados por meio da configuração do cliente Spark Streaming + Tranquility.

Melhorando o Uso de Druida no Airbnb

Embora o Druid ofereça muitos recursos poderosos amplamente aplicáveis que satisfazem a maioria das empresas, implementamos recursos dentro ou no topo do Druid para melhor atender nossos casos de uso especiais.

Uma estrutura para responder instantaneamente a consultas ad-hoc do Google Analytics

A Airbnb possui um grande número de cientistas de dados inseridos em diferentes equipes de negócios. Cada um deles pode ter perguntas ad hoc sobre a empresa que precisam de insights derivados dos dados, o que geralmente requer formas arbitrárias de agregar dados.

Para atender a essa necessidade, criamos um sistema de autoatendimento sobre o Druid que permite que equipes individuais definam facilmente como os dados que o aplicativo ou serviço produz devem ser agregados e expostos como uma fonte de dados de druida. Os cientistas e analistas de dados podem, então, consultar o Druid para responder a perguntas ad-hoc.

Os usuários definem sua fonte de dados com a configuração tão simples como abaixo. Os dados em tempo real do Kafka e os dados em lote do HDFS / S3 serão processados de acordo com o arquivo de configuração.

O Druid agrega seus dados em tempo real em janelas de 5 minutos, além de latência de 1 minuto nos pipelines.

O fluxo em tempo real do Druid nos permite ativar diversas funcionalidades sofisticadas para nossos usuários. Um dos casos de uso interessantes para ingestão em tempo real é a detecção de anomalias. Com dados em tempo real ingeridos e agregados rapidamente no Druid, podemos detectar qualquer coisa na produção que não esteja em conformidade com um padrão esperado muito rapidamente.

Integração com o Presto

O Druid possui um mecanismo de consulta maduro com a API RESTful JSON sobre HTTP, além do suporte à consulta SQL com versões recentes. No entanto, uma das limitações do Druid é que ele ainda não permite consultas cruzadas de fontes de dados (de maneira simplista, uma consulta de junção). Todas as consultas agregadas estão limitadas a uma única fonte de dados. No Airbnb, no entanto, temos cenários em que várias fontes de dados com dimensões sobrepostas precisam ser unidas para determinadas consultas. A alternativa é manter todos os dados em uma única fonte de dados, o que não é ideal em nosso cenário por várias razões, incluindo cadência de geração de dados, fonte de dados diferente (por exemplo, serviços diferentes produzem os dados) e assim por diante. No entanto, a necessidade de consulta cruzada de fontes de dados é real e recentemente se tornou um requisito difícil.

Para atender a esses cenários, desenvolvemos uma solução interna baseada no Presto. Especificamente, introduzimos um conector Presto para Druid que pode empurrar consultas para o Druid por fontes de dados individuais e pode recuperar e juntar os dados para concluir a execução da consulta de fontes de dados cruzadas. Os detalhes da implementação ainda estão em evolução e estão fora do escopo deste artigo. Forneceremos mais detalhes em um post separado no futuro.

Melhorar o desempenho de backfill

O segredo de por que as consultas de Druid são muito mais rápidas do que outros sistemas é que existe um custo imposto à ingestão. Cada segmento de dados precisa ser ingerido a partir de jobs do MapReduce antes de estar disponível para consultas. Isso funciona muito bem em um modelo write-once-read-multiple-times , e o framework só precisa ingerir novos dados diariamente.

No entanto, surgem problemas quando um proprietário de uma fonte de dados deseja reformulá-lo e gerar novamente dados históricos. Isso significa que os dados nos últimos anos precisam ser reinseridos no Druid para substituir os antigos. Isso requer um trabalho de processamento muito grande com uma tarefa MapReduce de longa duração, o que o torna caro, especialmente quando ocorre um erro no meio da re-ingestão.

Uma solução potencial é dividir a grande ingestão em várias solicitações para obter melhor confiabilidade. No entanto, os resultados da consulta serão inconsistentes, pois serão computados a partir de uma combinação de dados existentes antigos e novos. Os trabalhos de preenchimento são, na verdade, mais freqüentes do que esperávamos, à medida que as funcionalidades de requisitos de usuários e de estrutura de ingestão evoluem, tornando seu desempenho um ponto problemático que requer melhorias.

Para resolver isso, criamos uma solução que basicamente mantém todos os segmentos recém-inativos inativos até a ativação explícita . Isso permite que a estrutura de ingestão divida a fonte de dados em intervalos menores com tamanhos aceitáveis. A estrutura então ingere esses intervalos em paralelo (tão paralelos quanto os recursos do cluster Yarn permitem). Como os dados recém-ingeridos ainda estão inativos, os segmentos ficam ocultos em segundo plano e não há combinação de diferentes versões de dados ao calcular resultados para consultas que estão sendo executadas enquanto o processamento de preenchimento ainda está em andamento. Quando ativamos a última versão de segmentos para a fonte de dados, ela será atualizada com a nova versão sem tempo de inatividade. Dividir e atualizar melhorou muito o desempenho do aterramento e tornou os aterros que costumavam ser executados por mais de um dia em uma hora .

Monitoramento e Operação

Nós monitoramos o Druid continuamente para um serviço confiável e melhor desempenho. O Druid é robusto e resiliente a falhas de nó. A maioria das falhas de nós é transparente e imperceptível para os usuários. Mesmo se uma função que é um único ponto de falha (como Coordenador, Overlord ou até ZooKeeper) falhar, o cluster Druid ainda poderá fornecer o serviço de consulta aos usuários. No entanto, para honrar nosso SLA com os usuários, qualquer interrupção no serviço deve ser detectada no tempo ou até mesmo antes que a falha ocorra.

Como outros clusters, monitoramos cada máquina no cluster do Druid coletando estatísticas da máquina e gerando um alerta, se qualquer instância atingir sua capacidade ou entrar em mau estado. Para monitorar a disponibilidade geral do cluster, nós ingerimos uma peça de dados canário no Druid a cada 30 minutos e verificamos se o resultado da consulta de cada nó do Broker corresponde aos dados mais recentes ingeridos a cada 5 minutos. Qualquer degradação no serviço, incluindo consulta, ingestão ou instabilidade do HDFS downstream, pode ser detectada no SLA.

O Druid funciona na Airbnb há anos e é um dos sistemas com o menor custo de manutenção. O design multifuncional do Druid torna as operações fáceis e confiáveis. Os administradores de cluster podem ajustar a configuração de cluster e adicionar / remover nós com base nas métricas de monitoramento. À medida que os dados crescem em nosso cluster Druid, podemos continuar adicionando capacidade de nó histórico para armazenar em cache e atender facilmente a maior quantidade de dados. Se a carga de trabalho de ingestão em tempo real mostrar um aumento, podemos facilmente adicionar nós do gerenciador intermediário de acordo. Da mesma forma, se for necessária mais capacidade para lidar com consultas, podemos aumentar a contagem de nós do agente. Graças à arquitetura desacoplada do Druid, conseguimos realizar uma grande operação que migrou todos os dados no armazenamento profundo do HDFS para o S3 com um cluster recém-recondicionado, com apenas alguns minutos de inatividade.

Desafios e melhorias futuras

Enquanto o Druid nos serviu bem em nossa arquitetura de plataforma de dados, há novos desafios à medida que nosso uso de Druid cresce dentro da empresa.

Um dos problemas com os quais lidamos é o crescimento do número de arquivos de segmento que são produzidos todos os dias e que precisam ser carregados no cluster. Os arquivos de segmento são a unidade básica de armazenamento de dados do Druid, que contém os dados pré-agregados prontos para veiculação. Na Airbnb, estamos encontrando alguns cenários em que um grande número de nossas fontes de dados em algum momento precisam ser recalculadas inteiramente, resultando em um grande número de arquivos de segmento que precisam ser carregados de uma só vez no cluster. Atualmente, os segmentos ingeridos são carregados pelos coordenadores sequencialmente em um único thread, centralmente. À medida que mais e mais segmentos são produzidos, o coordenador não consegue acompanhar e vemos um aumento no atraso entre o tempo que um trabalho de processamento é concluído e o tempo em que os dados ficam disponíveis para consulta (depois de serem carregados pelo coordenador). Às vezes, o atraso pode durar horas.

A solução usual é tentar aumentar o tamanho do segmento de destino e, assim, reduzir a contagem de segmentos. No entanto, em nosso uso, o volume de entrada de dados para produzir um segmento maior (por uma tarefa de processamento de execução do Hadoop) é tão alto que o trabalho do Hadoop seria executado por muito tempo processando esses dados e muitas vezes falharia devido a vários motivos .

No momento, estamos explorando várias soluções, incluindo a compactação de segmentos logo após a ingestão e antes de serem entregues ao coordenador, além de diferentes configurações para aumentar o tamanho do segmento sem prejudicar a estabilidade do processamento quando possível.

Conclusão

O Druid é um mecanismo de análise de big data projetado para escalabilidade, capacidade de manutenção e desempenho. Sua arquitetura bem planejada permite fácil gerenciamento e dimensionamento da implantação do Druid, e seu formato de armazenamento otimizado permite consultas analíticas de baixa latência. Implementamos com sucesso o Druid na Airbnb para nossos casos de uso e observamos um crescimento contínuo em sua presença, à medida que nossa base de usuários e casos de uso crescem.