Spark, Hadoop e Microservices: extraindo informações de milhões de eventos. Abril 2017

Transcrição

1 Spark, Hadoop e Microservices: extraindo informações de milhões de eventos Abril 2017

2 Abril 2017

3 Um pouco sobre o negócio da SoundCloud

4 CREATORS querem um público. O aumento de listeners gera a oportunidade para que creators sejam ouvidos. LISTENERS querem conteúdo original SoundCloud oferece diferente modelos de subscriptions - incluindo um modelo gratuito. Crescimento dos CREATORS impulsiona o crescimento de LISTENING TIME.

5 Indispensável para Creators Identidade Audiência Ganhar dinheiro

6 Indispensável para Listeners

7 Uma plataforma, muitos requisitos Creators decidem como distribuir seu conteúdo: Monetização por território. Disponível somente para subscribers. Listeners utilizam SoundCloud app em diferentes plataformas: IOs, Android, Web, ChromeCast. Em background, SoundCloud precisa entregar o conteúdo para os usuários e extrair/armazenar métricas (de forma durável) das requisições.

8 Nosso foco hoje será a pipeline de monetização da SoundCloud!

9 A monetização é derivada do número de plays

10 Número de plays é importante: zoom na track timeline Como armazenar 37 segundos ouvidos de uma track? Listener pode ou não continuar escutando a track.

11 ` A cada X segundos a track timeline emite um evento. //////////////////////////////////////////////// Ao iniciar uma track um evento PlayEvent é emitido. //////////////////////////////////////////////// //////////////////////////////////////////////// Conforme o progresso da track, ListeningEvent são emitidos. //////////////////////////////////////////////// message PlayEvent { message ListeningEvent { //////////////////////////////////// required uint64 at = 1; //////////////////////////////////// optional string identifier = 2; } //////////////////////////////////// //////////////////////////////////// required uint64 at = 1; //////////////////////////////////// optional string play_ref = 2; } ////////////////////////////////////

12 Vamos abrir um parênteses e explorar um pouco mais a estrutura de um evento.

13 O que é um evento? Uma ação realizada por um usuário (sound_played). Um evento pode ser: Um evento não é: Uma ação realizada por um sistema (user_assigned_to_experiment). Uma alteração de estado de um objeto persistente (user_updated). Logs operacionais que são examinados em caso de erros. Um objeto persistente (como uma track ou user).

14 O que podemos fazer com eventos? Emitir eventos. Consumir eventos em tempo real. Ler eventos de long-term storage. Desacoplar triggers de ações. Que nos permite: Analisar comportamento de usuários e sistemas. Implementar funcionalidades orientada a dados.

15 Anatomia de um evento na SoundCloud Metadata Payload message Event { required uint64 at = 1; optional string identifier = 2; Event type UUID Timestamp Encoding Protobuf-encoded de acordo com um schema }

16 Fechando parênteses! Vamos voltar para a timeline emissora de eventos.

17 A cada X segundos a track timeline emite um evento: ListeningEvent. Ao iniciar uma track um evento PlayEvent é emitido. Conforme o progresso da track, ListeningEvent são emitidos. message PlayEvent { message ListeningEvent { required uint64 at = 1; required uint64 at optional string identifier = 2; } = 1; optional string play_ref = 2; }

18 A duração de uma play é uma informação importante. Não Essa variável é importante para identificação de spam e para a regra de monetização é preciso criar um evento para indicar que uma track não Algo como StopEvent é desnecessário está mais em execução.

19 Esse comportamento da track timeline permite: 1 Menos dependência de ações do listener: Não precisa apertar o botão 2. Menos corner cases para serem tratados: Pause & Play em outra track. Aplicativo foi fechado ou parou de funcionar.

20 Em contrapartida: Surge a necessidade de agregar ListeningEvent por play_ref. Também deve ser feito um join do resultado da agregação com PlayEvent.

21 message PlayEvent { required uint64 at = 1; message ListeningEvent { optional string id = 2; required uint64 at } = 1; optional string play_ref = 2; } message SoundPlayedEvent { required uint64 at = 1; optional Context context = 2; optional User actor = 3; optional Playable sound = 4; optional uint32 duration = 5; }

22 Entender a estrutura dos dados é essencial em Big Data. Vamos continuar nessa linha e explorar um pouco mais como esses dados são gerados.

23 Arquitetura com isolamento de responsabilidades: Microservices Upload de novas tracks Registro de novos usuários Track DB User DB Registro de novos publishers Publisher? DB

24 Funcionalidade com dependência transversal de Microservices Upload de novas tracks Registro de novos usuários Registro de novos publishers Agora o relatório de uso pode ser construído sem dependência Exemplo: Relatório de uso direcionado para o Parceiro X Publisher de A dependência está nos dados. Trackmicroservices. DB User DB precisa dos metadados da track, do usuário e do? publisher. DB Desafio: não existe padronização no armazenamento.

25 Dependência transversal dos dados dos Microservices Upload de novas tracks Registro de novos usuários Registro de novos publishers Agora o relatório de usode pode construído semo dependência Exemplo: Relatório usoser direcionado para Partner X Publisher da API dependência está nos dados. Trackdos DB microservices. User DB do usuário precisa dos metadados da A track, e do publisher? DB Desafio: não existe padronização no armazenamento.

26 Flush dos dados para o HDFS Upload de novas tracks Registro de novos usuários Track DB User DB Padronizar acesso aos dados. Registro de novos publishers Publisher? DB

27 ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// Registro de Registro de Upload de ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// novos publishers novos usuários novas tracks ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// Publisher User DB Track DB /////////////////////////? DB ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// ///////////////////////// Agora o relatório de uso pode ser construído sem dependência de microservices. A dependência é de dados e o acesso a esses dados está padronizado. Track metadata User metadata Publisher metadata

28 Consistência eventual dos dados Não significa que às vezes é consistente e às vezes não. Significa que mais cedo ou mais tarde será consistente - você não tem controle sobre isso. Algumas funcionalidades toleram uma fração de inconsistência - algoritmo de recomendação. Agora imagina inconsistência em $$$$ O cálculo de royalties é baseado em plays. Se os dados são inconsistentes o dinheiro também se torna inconsistente. Não existe meio dinheiro. Hello auditor!!!

29 Adotamos um processo de curadoria dos dados. Validação de dados, preenchimento de dados obrigatórios que estão faltando consistência É importante identificar onde consistência é um requisito Entenda como seus dados são gerados e como eles são consumidos. Transação distribuída (XA) não é sua única opção para garantir consistência para aumentar a confiabilidade e não afetar o desempenho Se o seu dado se transforma em dinheiro, sua pipeline precisa ser transparente e auditável de serviços que toleram uma fração de inconsistência.

30 Vocês se lembram dessa fórmula? SoundPlayedEvent = PlayEvent + ListeningEvent

31 HDFS message SoundPlayedEvent { required uint64 at = 1; optional Context context = 2; Agregar ListeningEvent e fazer join com PlayEvent Build SoundPlayedEvent (protobuf schema) optional User actor = 3; optional Playable sound = 4; optional uint32 duration = 5; } > hdfs dfs -ls /semantic-events/playduration/2017 Found 2 items /semantic-events/playduration/2017/01-01 /semantic-events/playduration/2017/01-02

32 > hdfs dfs -ls /semantic-events/playduration/2017/01-01 Found 3 items /semantic-events/playduration/2017/01-01/part-r /semantic-events/playduration/2017/01-01/part-r /semantic-events/playduration/2017/01-01/part-r Sequence File > hdfs dfs -cat /semantic-events/playduration/2017/01-01/part-r SEQ^F!org.apache.hadoop.io.LongWritable"org.apache.hadoop.io.BytesWritable^A^ A)org.apache.hadoop.io.compress.SnappyCodec^@^@^@^@ϑ'^^2<B7><CA>Ⱥ^N< E5><91>... Binary File allplays.map(play => Writer[EnrichedPlay].write(play) match { case Good(bytesWritable) => play.at -> byteswritable case Bad(errors) => sys.error(errors.tostring) }).saveassequencefile(path = ".../2017/01-01")

33 Pipeline de monetização funciona baseado em plays e metadados: Conteúdo monetizável: métricas das plays Relatórios de uso para parceiros em diferentes períodos: diários, semanais, mensais, etc. Relatório de músicas mais tocadas para agências de ranking.

34 $$$ $$$ Spam Filter plays plays audited-plays $$$ plays plays plays plays plays track-rules-set Usage reports $ $$ plays plays enriched-plays $$$ Enricher User snapshot Aggregator Publisher snapshot Legacy pipeline $$$ loader Repoting DB metrics $$ $ $$$ $$$ plays plays aggregated-plays plays plays subscriptions $$$ monetizable-usage Usage reports $$$ Royalties Calculator

35 HDFS Filtrar / Agrupar / Agregar plays de um mês Filtrar / Agrupar / Agregar plays de um mês Filtrar / Agrupar / Agregar plays de um mês Gerar CSV Gerar DDEX Gerar XML

36 HDFS Filtrar / Agrupar / Agregar plays de um mês Gerar CSV val plays = PlayAggregator.group(monetizablePlays).persist(StorageLevel.MEMORY_ONLY) Gerar DDEX Gerar XML

37 message PlayAggregation { required uint64 id Filtrar / Agrupar / Agregar plays de um mês = 1; optional string name = 2; HDFS } Job relatório de uso Partner X Job relatório de uso Publishers Job relatório de uso Label Y Ler dados e agrupar por quadrimestre Gerar CSV Gerar DDEX Gerar XML Gerar CSV

38 Agregar plays não é suficiente. É preciso enriquecer as plays. Um evento de play é um dado muito simples. Ele não contém informação suficiente para ser utilizado como input da pipeline de monetização. A play é um simples agregador de ids. Mas é através de uma play que montamos o quebra-cabeça dos dados.

39 Diferentes microservices geram diferentes tipos de dados em um ambiente persistente. Alteração de copyright de uma track Renovação de assinatura mensal Alteração de policy de uma track HDFS HDFS HDFS

40 Alteração de Renovação de Alteração de copyright de assinatura policy de uma /events/2017/01-01/01_00/plays_audited uma track mensal track /events/2017/01-01/01_00/track_rightsholders_changed /events/2017/01-01/01_00/subscription_activated /events/2017/01-01/01_00/track_ruleset_changed HDFS HDFS HDFS

41 HDFS message RichPlay { required Play play = 1; Play Enrichersubscription optional Subscription = 2; HDFS optional TrackMetadata track = 3; optional UserMetadata user = 4; Track DB Job optional PublihserMetadata publisher = 5; User DB } Publisher service

42 A tarefa de enriquecimento poderia ser bem mais complicada Audited Plays Play Enricher Job Track DB User DB Publisher Service HTTP API HDFS

43 Mas ela se torna mais fácil quando os dados estão padronizados Audited Plays Play Enricher Job Track Metadata User Metadata Publisher Metadata HDFS

44 Diferentes data sources mas um único source of truth Filtro e enriquecimento dos dados para preparar dados - abastecer - para diversos jobs Relatório Label A Relatório Label B Relatório Label N??? Possibilidade de utilizar o framework adequado para cada task

45 Pipeline possui um ponto único de falha. Enricher Play é o gargalo. Se ele falha então o abastecimento dos dados falhará. Consequentemente todos os jobs dependentes também falharão. X Relatório Label A Relatório Label B Relatório Label N???

46 Cuidado com dados específicos na camada de dados comum. Dados específicos podem impactar jobs que não dependem desse dado. Quanto mais data sources mais custoso é a operação de join. Relatório Label A Relatório Label B Relatório Label N Dado grande, mais custo para fazer shuffle

47 Projeções dos dados Projeção está diretamente ligado com seleção de dados. Por exemplo, dado uma fonte de dados com muitos atributos (fat data), selecione apenas o que é estritamente necessário para realizar a tarefa.

48 Múltiplas visões de play select * from enriched_plays Play Enricher Play Enricher JobEnricher Play Job Job Play Enriched select play, subscription, user from enriched_plays select play, subscription, track, user from enriched_plays Play Job 1 Play Job 2 Play... Job N???

49 Múltiplas visões de play case class Play(...) Play Enricher Play Enricher JobEnricher Play Job Job Play Enriched case class Play( subs: Subscription, user: User ) case class Play( subs: Subscription, user: User, track: Track Play Job 1 Play Job 2 Play... Job N??? )

50 Por quê devo projetar meus dos dados? Coesão: menos dados para ler então é mais fácil para entender. Seja minimalista, selecione apenas o necessário. Performance: menos dados na memória - somente os dados necessários são projetados. Portanto menos tráfego na rede quando realizar operações que exigem shuffle.

51 Vamos agora explorar um pouco mais dos detalhes técnicos: escolher o momento certo para fazer shuffle.

52 Ainda dá tempo para falar sobre o que é Spark? Engine para processamento de dados em larga escala - big data. Promessa: executar programas 100x mais rápido que o Hadoop MapReduce em memória ou 10x mais rápido no disco. Spark roda em cima do Hadoop - yarn, standalone ou em cloud services.

53 Conceito de Map / Reduce map() lê dados e gera <key, value> - usuário define a função de transformação. D1 map() <key, value> reduce() lê <key, value> e gera result - usuário define a função de agrupamento. <key, value> reduce() result

54 D1 map() D2 map() reduce() O 1 D3 map() reduce() O n Dn map() Fase de agrupamento (resultados intermediários)

55 Operações: Narrow x Wide Narrow operations: operações que não implicam em transferência de dados entre nodes através da rede. Wide operations: operações que transferem dados entre nodes através da rede.

56 Partição Partição Partição map, filter, union, join com dados co-partionados Executor Executor Partição Partição Partição Executor Executor Partição Partição Partição Partição Partição Partição groupbykey, join com dados não partionados

57 Melhorando o desempenho do seus Spark jobs Existem diversas variáveis que podem ser ajustadas em um spark job: número de executors, número de cores, memória, etc. Uma das variáveis mais importantes é o número de partições. Controlar esse fator gera impacto direto no gerenciamento de troca de dados através da rede - shuffle.

58 Redistribuição de dados: Collapse vs Repartition Collapse: é uma operação narrow. Se você reduzir de 1000 partições para 100 partições não haverá shuffle. Cada uma das novas 100 partições reivindicarão 10 das partições atuais. Repartition: é uma operação wide. Redistribuí os dados utilizando shuffle. Se você está reduzindo o número de partições, considere utilizar collapse.

59 Quando redistribuir meus dados? Após realizar filtro: Antes de realizar join: val monetizableplays = allplays.filter(ismusic).filter(islongplay).filter(ispolicymonetize).coalesce(???) // ou.repartition(???) val tracks = allplays.map(keybytrackid(_) -> 1L).reduceByKey(_ + _) criar partições com tamanho entre 64 e 100 MB, conforme recomendado pela apache spark tracks.leftouterjoin(publishers) val publishers = allpublishers.map(keybytrackid(_)).alignpartitioningto(tracks) alinhar o número de partições dos datasets antes de aplicar o join

60 Constante vigilância no crescimento dos dados e parâmetros dos jobs Os dados são dinâmicos. Os parâmetros selecionados para execução eficiente de um job no período X podem ser ineficazes no período Y.

61 Manter o comportamento previsível da pipeline é uma batalha Para construir o estado atual de uma entidade, basta aplicar todos os eventos - em ordem cronológica. Potencial problema: O tempo não para e os eventos também não. Quanto maior a volatilidade dos dados, mais cedo um job precisará ser ajustado. Previsibilidade da quantidade dos dados evitará maiores dores de cabeça.

62 Quantidade máxima de eventos necessários Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez Janela (deslizante) no tempo Track Ruleset Snapshots Checkpoint do estado Redução do efeito nocivo do tempo na pipeline. Geração de snapshots adequam-se a velocidade de alteração dos dados.

63 Obrigado :)

64 Estamos contratando: soundcloud.com/jobs