Implementando o banco de dados de mídia da Netflix

Netflix Technology Blog Blocked Unblock Seguir Seguindo 14 de dezembro de 2018

Nos posts anteriores desta série, introduzimos o N etflix M EDIA D ase ata B (NMDB) e sua salientes “Documento de mídia” modelo de dados. Neste post iremos fornecer detalhes da arquitetura do sistema NMDB, começando com os requisitos do sistema – estes irão servir como a motivação necessária para as escolhas arquitetônicas que fizemos. Um requisito fundamental para qualquer sistema de dados duradouro é que ele seja dimensionado junto com o crescimento dos aplicativos de negócios que ele deseja atender. O NMDB foi criado para ser um sistema de metadados de mídia altamente escalável e multilocatário que pode atender a um alto volume de rendimento de gravação / leitura, além de oferecer suporte a consultas quase em tempo real. A qualquer momento, pode haver vários aplicativos que estão tentando manter dados sobre um recurso de mídia (por exemplo, imagem, vídeo, áudio, legendas) e / ou tentando aproveitar esses dados para resolver um problema de negócios.

Alguns dos elementos essenciais de tal sistema de dados são (a) confiabilidade e disponibilidade – sob condições variáveis de carga, bem como uma ampla variedade de padrões de acesso; (b) escalabilidade – persistindo e servindo grandes volumes de metadados de mídia e dimensionamento diante de solicitações intermitentes para servir sistemas de backend críticos como codificação de mídia, (c) extensibilidade – suportando uma lista exigente de recursos com uma lista crescente de casos de uso de negócios da Netflix e (d) consistência – semântica de acesso a dados que garante um comportamento de leitura repetível de dados para aplicativos clientes. A seção a seguir enumera os principais traços do NMDB e como o design visa abordá-los.

Requisitos de sistema

Suporte para dados estruturados

O crescimento dos bancos de dados NoSQL foi amplamente acompanhado pela tendência de “falta de esquema” dos dados (por exemplo, os armazenamentos de valores-chave geralmente permitem armazenar quaisquer dados sob uma chave). Um sistema sem esquema parece ser menos imponente para os desenvolvedores de aplicativos que estão produzindo os dados, pois (a) os poupa do fardo de planejar e preparar futuramente a estrutura de seus dados e (b) permite que eles desenvolvam formatos de dados com facilidade e facilidade. para o seu gosto. No entanto, os esquemas estão implícitos em um sistema sem esquema, pois o código que lê os dados precisa considerar a estrutura e as variações nos dados ("esquema de leitura"). Isso sobrecarrega os aplicativos que desejam consumir esse suposto tesouro de dados e pode levar a um forte acoplamento entre o sistema que grava os dados e os aplicativos que os consomem. Por esse motivo, implementamos o NMDB como um sistema “schema-on-write” – os dados são validados contra o esquema no momento da gravação no NMDB. Isso oferece vários benefícios, incluindo: (a) o esquema é semelhante a um contrato de API e vários aplicativos podem se beneficiar de um contrato bem definido; (b) os dados têm uma aparência uniforme e podem ser consultados, bem como Extract, Transform e Load. (ETL), (c) facilita uma melhor interoperabilidade de dados entre inúmeras aplicações e (d) otimiza o desempenho de armazenamento, indexação e consulta melhorando, assim, a Qualidade de Serviço (QoS). Além disso, isso facilita as altas taxas de transferência de dados, pois eliminamos a lógica complexa da aplicação no momento da leitura dos dados.

Um componente crítico de um sistema “schema-on-write” é o módulo que garante a integridade dos dados de entrada. Dentro do sistema NMDB, H EDIA D ados V ALIDAÇÃO S ervice (MDVs), é o componente que garante que os dados a serem escritas para NMDB está em conformidade com um esquema acima mencionado. O MDVS também serve como depósito e gerenciador do próprio esquema de dados. Como foi observado no post anterior , o próprio esquema de dados pode evoluir ao longo do tempo, mas todos os dados, até agora ingeridos, devem permanecer em conformidade com o esquema mais recente. O MDVS garante isso aplicando tratamento meticuloso à modificação do esquema, garantindo que todas as atualizações do esquema sejam totalmente compatíveis com os dados já existentes no sistema.

Multilocação e Controle de Acesso

Nós visualizamos o NMDB como um sistema que ajuda a promover a inovação em diferentes áreas dos negócios da Netflix. Análises de dados de mídia criadas por um aplicativo desenvolvido por uma equipe podem ser usadas por outro aplicativo desenvolvido por outra equipe sem atrito. Isso torna a multilocação, bem como o controle de acesso de dados, problemas importantes a serem resolvidos. Todas as APIs do NMDB são autenticadas (AuthN) para que a identidade de um aplicativo de acesso seja conhecida na frente. Além disso, o NMDB aplica filtros de autorização (AuthZ) que whitelists aplicativos ou usuários para determinadas ações, por exemplo, um usuário ou aplicativo poderia ser whitelisted para leitura / gravação / consulta ou um acesso de leitura mais restritivo para alguns metadados de mídia.

No NMDB, pensamos no universo de metadados de mídia em unidades de “DataStores”. A análise de mídia específico que tenha sido realizada em vários ativos de mídia (por exemplo, análise de volume para todos os arquivos de áudio) seriam normalmente armazenados dentro da mesma D ata S rasgou (DS). enquanto diferentes tipos de análises de mídia (por exemplo, limite de captura de vídeo e detecção de face de vídeo) para o mesmo ativo de mídia normalmente seriam persistidos em diferentes DataStores. Um DS nos ajuda a atingir duas finalidades muito importantes (a) serve como um espaço lógico para a mesma análise de mídia para vários ativos de mídia no catálogo Netflix e (b) serve como uma unidade de controle de acesso – um aplicativo ) que define um DataStore também configura as permissões de acesso aos dados. Além disso, conforme descrito no artigo do blog anterior , cada DS é associado a um esquema para os dados que armazena. Como tal, um DS é caracterizado por três tuplos (1) um namespace, (2) um tipo de análise de mídia (por exemplo, dados de limite de captura de vídeo) e (3) uma versão do tipo de análise de mídia (diferentes versões de um análise de mídia correspondem a diferentes esquemas de dados). Isso é mostrado na Figura 1.

Figura 1: Semântica do NMDB DataStore

Escolhemos a parte do namespace de uma definição do DS para corresponder a um nome de grupo LDAP . O NMDB usa isso para inicializar o processo de autoatendimento, no qual os membros do grupo LDAP recebem privilégios de " administrador " e podem executar várias operações (como criar um DS, excluir um DS) e gerenciar políticas de controle de acesso (como adicionar / remover " escritores "). ”E“ leitores ”). Isso permite um processo de autoatendimento perfeito para criar e gerenciar um DS. A noção de um DS é, portanto, fundamental para as maneiras como oferecemos suporte a multilocação e controle de acesso refinado.

Integração com outros sistemas Netflix

No ambiente de microsserviços Netflix, diferentes aplicativos de negócios servem como o sistema de registro para diferentes ativos de mídia. Por exemplo, embora os recursos de mídia reproduzíveis, como vídeo, áudio e legendas de um título, possam ser gerenciados por um "serviço de reprodução", os ativos promocionais, como imagens ou trailers de vídeos, podem ser gerenciados por um "serviço de promoções". O NMDB introduz o conceito de “ M edia ID ” ( MID ) para facilitar a integração com esses sistemas de gerenciamento de ativos díspares. Pensamos no MID como uma chave estrangeira que aponta para uma instância do documento de mídia no NMDB. Vários aplicativos podem trazer seus identificadores / chaves específicos de domínio para endereçar uma instância de documento de mídia no NMDB. Nós implementamos MID como um mapa de strings para strings . Assim como o esquema de dados de mídia, um NMDB DS também está associado a um único esquema MID. No entanto, ao contrário do esquema de dados de mídia, o esquema MID é imutável. No momento da definição do DS, um aplicativo cliente poderia definir um conjunto de pares (nome, valor) com os quais todas as instâncias do documento de mídia seriam armazenadas nesse DS. Um identificador MID pode ser usado para buscar documentos dentro de um DS no NMDB, oferecendo acesso conveniente aos documentos mais recentes ou a todos os documentos para um recurso de mídia específico.

Garantias de SLA

O NMDB atende a diferentes aplicativos de negócios em camadas, alguns dos quais são considerados mais críticos para os negócios do que outros. O subsistema de transcodificação de mídia da Netflix é um exemplo de aplicativo crítico para os negócios. As aplicações dentro deste subsistema têm necessidades rigorosas de consistência, durabilidade e disponibilidade, enquanto um grande enxame de microsserviços atua gerando conteúdo para nossos clientes. Uma falha no fornecimento de dados com baixa latência paralisaria vários pipelines potencialmente se manifestando como um impacto indireto nos serviços secundários de back-end. Esses requisitos de negócios nos motivaram a incorporar a consistência de imutabilidade e leitura após gravação como preceitos fundamentais, enquanto persistem dados no NMDB.

Escolhemos a alta capacidade de dados e o banco de dados Cassandra (C *) de alto desempenho como a implementação de back-end que serve como fonte de verdade para todos os nossos dados. Um serviço front-end, conhecido como M EDIA D ados P ersistence S ervice (MDPS), administra o C * backend e serve de dados a velocidades ardentes (latência na ordem de algumas dezenas de milissegundos) para alimentar estes aplicações críticas de negócios. O MDPS usa o quorum local para leituras e gravações para garantir a consistência de leitura após gravação. A imutabilidade dos dados nos ajuda a evitar qualquer problema de conflito que possa surgir de atualizações simultâneas para o C *, ao mesmo tempo em que nos permite executar operações de ES em um clipe muito rápido. Usamos um UUID como a chave primária para C *, dando a cada operação de gravação (MID + uma instância de documento de mídia) uma chave única e evitando assim conflitos de gravação quando vários documentos são mantidos contra o mesmo MID. Esse UUID (também chamado de DocumentID) também serve como a chave primária da instância do documento de mídia no contexto do sistema global do NMDB. Vamos abordar a imutabilidade novamente em seções posteriores para mostrar como também nos beneficiamos em alguns outros aspectos de design do NMDB.

Flexibilidade de Consultas

O principal benefício da modelagem de dados e de um sistema de "esquema sobre gravação" é a capacidade de consulta. Os metadados técnicos que residem no NMDB são inestimáveis para desenvolver novos insights de negócios nas áreas de recomendações de conteúdo, promoção de títulos, controle de qualidade de conteúdo assistido por máquina (QC), bem como inovações na experiência do usuário. Um dos principais objetivos do NMDB é que ele pode servir como um data warehouse. Isso traz a necessidade de indexar os dados e disponibilizá-los para consultas, sem conhecimento prévio de todos os possíveis padrões de consulta.

Em princípio, um banco de dados gráfico pode responder a consultas arbitrárias e promete um ótimo desempenho de consulta para junções. Por esse motivo, exploramos um modelo de dados semelhante a um gráfico para abordar nossos casos de uso de consulta. No entanto, aprendemos rapidamente que nosso principal caso de uso, que é consultas espaço-temporais na linha de tempo da mídia , fazia uso limitado de junções de banco de dados. E nessas consultas, onde as junções eram usadas, o grau de conexão era pequeno. Em outras palavras, o poder do modelo gráfico foi subutilizado. Concluiu-se que para o limitado consulta de junção casos de uso, lado da aplicação junta pode proporcionar um desempenho satisfatório e poderia ser tratado por uma aplicação que chamamos M EDIA D ata erviço Q uery S (MDQS). Além disso, outro padrão de consultas surgiu – pesquisando dados textuais não estruturados, por exemplo, dados de scripts de filmes de mineração e pesquisa de legendas. Ficou claro para nós que um banco de dados de documentos com recursos de pesquisa atenderia a maioria de nossos requisitos, como permitir uma pluralidade de metadados, desenvolvimento de algoritmo rápido, servir consultas não-estruturadas e também consultas estruturadas mesmo quando os padrões de consulta não são conhecidos a priori.

Elasticsearch (ES), uma implementação de banco de dados escalonável de alto desempenho, atende nossas necessidades muito bem. O ES suporta uma ampla gama de possibilidades para consultas e, em particular, brilha na pesquisa textual não estruturada, por exemplo, procurando uma palavra culturalmente sensível em um recurso de legenda que precise de pesquisa com base em um radical da palavra. Em essência, o ES usa o Lucene – um poderoso mecanismo de indexação e busca rico em recursos. Um serviço front-end, conhecido como M EDIA D ados A nálise S ervice (MDAS), gere o servidor NMDB ES para as operações de escrita e de consulta. O MDAS implementa várias otimizações para responder a consultas e indexar dados para atender às demandas de armazenamento de documentos que possuem características e tamanhos variados. Isso é descrito mais detalhadamente posteriormente neste artigo.

Um sistema de dados de bancos de dados

Como indicado acima, os requisitos de negócios exigiam que o NMDB fosse implementado como um sistema com vários microsserviços que gerenciam um poliglota de bancos de dados (DBs). Os diferentes bancos de dados constituintes têm finalidades complementares. Temos, no entanto, o desafio de manter os dados consistentes entre eles diante das deficiências clássicas dos sistemas distribuídos – às vezes os serviços de dependência podem falhar, às vezes os nós de serviço podem ficar inativos ou até mais nós adicionados para atender a uma demanda em rajada. Isso motiva a necessidade de um serviço de orquestração robusto que possa (a) manter e executar uma máquina de estado, (b) repetir operações em caso de falhas transitórias e (c) suportar operações assíncronas (possivelmente de longa duração) como consultas. Usamos a estrutura de orquestração Conductor para coordenar e executar fluxos de trabalho relacionados às operações NMDB Create, Read, Update, Delete (CRUD) e para outras operações assíncronas, como consulta. O Conductor nos ajuda a alcançar um alto grau de disponibilidade de serviços e consistência de dados em diferentes back-ends de armazenamento. No entanto, dada a coleção de sistemas e serviços que funcionam em uníssono, não é possível fornecer garantias sólidas sobre a consistência dos dados e ainda assim permanecer altamente disponível para certos casos de uso, o que implica que as distorções de leitura de dados não são totalmente evitáveis. Isso é verdade, em particular, para as APIs de consulta – elas dependem da indexação bem-sucedida de instâncias do documento de mídia, que é feita como uma operação de segundo plano assíncrona no ES. Portanto, as consultas no NMDB devem ser consistentes.

Figura 2: Diagrama de blocos do sistema NMDB

A Figura 2 mostra o diagrama de blocos do sistema NMDB. Um serviço front-end que compartilha seu nome com o sistema NMDB serve como o gateway para todas as operações de consulta e CRUD. As APIs de leitura são executadas de forma síncrona, enquanto as APIs de consulta de gravação e longa duração são gerenciadas de forma assíncrona por meio de fluxos de trabalho do Conductor. Voltando ao ponto de imutabilidade de dados que foi discutido anteriormente – outro de seus benefícios é que ele preserva todas as gravações que poderiam ocorrer, por exemplo, quando um cliente ou a estrutura do Conductor tenta novamente uma gravação, talvez devido a problemas de conexão temporários. Embora isso implique em pegada de dados, os benefícios, como (a) permitir novas tentativas de bloqueio, (b) eliminar a necessidade de resolver conflitos de gravação e (c) mitigar a perda de dados, superam em muito os custos de armazenamento.

Incluído na Figura 2 está um componente chamado Armazenamento de objeto, que faz parte da infraestrutura de dados do NMDB. O Object Store é um serviço de armazenamento seguro altamente disponível na Web, como o Simple Storage Service (S3) da Amazon . Esse componente garante que todos os dados que estão sendo persistidos sejam fragmentados e criptografados para um ótimo desempenho. Ele é usado nos caminhos de gravação e leitura. Esse componente serve como o principal meio de troca de instâncias de documentos de mídia entre os vários componentes do NMDB. As instâncias de documentos de mídia podem ser grandes em tamanho (várias centenas de MBs – talvez porque uma análise de mídia pudesse modelar metadados, por exemplo, sobre cada quadro em um arquivo de vídeo. Além disso, os dados por quadro poderiam explodir em tamanho devido a alguma modelagem de atributos espaciais como caixas delimitadoras). Esse mecanismo otimiza o desempenho da largura de banda e da latência, garantindo que as instâncias do Document de mídia não precisem transitar entre os diferentes microsserviços envolvidos no caminho de leitura ou gravação e só possam ser baixadas quando necessário.

NMDB em ação

Embora as seções anteriores tenham discutido os principais traços arquitetônicos, nesta seção vamos nos aprofundar na implementação do NMDB.

Escrevendo dados no NMDB

Figura 3: Escrevendo uma Instância de Documento de Mídia para o NMDB

A animação mostrada na Figura 3 detalha o mecanismo que é colocado em ação quando gravamos no NMDB. O processo de gravação começa com um aplicativo cliente que comunica sua intenção de gravar uma instância do documento de mídia. O NMDB aceita a solicitação de gravação enviando a tarefa para a estrutura de orquestração (Conductor) e retorna um identificador exclusivo para identificar a solicitação. Isso pode ser usado pelo cliente para consultar o status da solicitação. A seguir, as etapas de validação de esquema, persistência de documento e indexação de documento são executadas nessa ordem. Quando o documento é mantido em C *, ele fica disponível para leitura com fortes garantias de consistência e está pronto para ser usado por aplicativos somente leitura. A indexação de um documento em ES pode ser uma operação de alta latência, pois é um procedimento relativamente mais intensivo que requer vários processos coordenados para analisar o conteúdo do documento e atualizar várias estruturas de dados que permitem pesquisa e consultas eficientes.

Também é digno de nota o uso de um armazenamento de objeto para otimizar o IO através dos componentes de serviço (como foi discutido anteriormente). O NMDB utiliza um serviço de armazenamento em nuvem (por exemplo, serviço do AWS S3 ) para o qual um cliente faz o upload dos dados da instância do documento de mídia. Para cada solicitação de gravação para o NMDB, o NMDB gera um UUID do tipo IV usado para compor uma chave. A chave, por sua vez, é usada para compor uma URL única para a qual o cliente carrega os dados que deseja gravar no NMDB. Essa URL é então passada como referência para os dados da instância do documento de mídia.

Estratégias de Escala

Do ponto de vista da gravação para o NMDB, alguns dos componentes do NMDB são pesados, enquanto outros são IO pesados. Por exemplo, o gargalo do MDVS é a CPU e também a memória (já que precisa trabalhar com documentos grandes para validação). Por outro lado, o MDAS também é vinculado pela rede IO (as instâncias do Document de mídia precisam ser baixadas do NMDB Object Store para o MDAS para que possam ser indexadas). Métricas diferentes podem ser usadas para configurar uma plataforma de implantação contínua, como o Spinnaker para balanceamento de carga e escalonamento automático para o NMDB. Por exemplo, “solicitações por segundo” (RPS) é comumente usado para dimensionar automaticamente os serviços de micro para atender a leituras ou consultas aumentadas. Embora o uso de RPS ou CPU possa ser uma métrica útil para escalonar serviços síncronos, APIs assíncronas (como o armazenamento de um documento no NMDB) trazem o requisito da profundidade da fila de monitoramento para antecipar a construção do trabalho e escalonar adequadamente.

Figura 4: Escalando o plano de serviço NMDB

A estratégia discutida acima nos dá uma boa maneira de dimensionar automaticamente a camada de micro serviços do NMDB (identificada como “Plano de Serviços” na Figura 4) de forma quase linear. No entanto, como visto na Figura 4, o RPS de estado estável que o sistema pode suportar eventualmente platôs no ponto em que o dimensionamento do Plano de Serviço não ajuda a melhorar o SLA. Neste ponto, deve ficar claro que os nós de dados (identificados como "Data Backend") atingiram seus limites máximos de desempenho e precisam ser dimensionados. No entanto, os bancos de dados distribuídos não dimensionam tão rapidamente quanto os serviços, e o dimensionamento horizontal ou vertical pode levar de algumas horas a dias, dependendo do tamanho do espaço de dados. Além disso, embora o escalonamento do Plano de Serviço possa ser um processo automatizado, a adição de mais nós de dados (C * ou ES) para dimensionar o back-end de dados é normalmente feita manualmente. No entanto, observe que, quando o Data Backend é dimensionado (horizontal e / ou verticalmente), os efeitos do dimensionamento do Service Plane se manifestam como um RPS de estado estável aumentado, como visto na Figura 4.

Um ponto importante relacionado ao escalonamento de nós de dados, que vale a pena mencionar é a chave da estratégia de hashing que cada DB implementa. C * emprega hashing de chave consistente e, portanto, a adição de um nó distribui os dados uniformemente entre os nós. No entanto, ES implementa um hashing distribuído baseado em módulo. Aqui, a adição de um nó de dados melhora a distribuição de fragmentos entre os nós disponíveis, o que ajuda a aliviar gargalos de consulta / gravação em uma extensão. No entanto, como o tamanho dos fragmentos aumenta com o tempo, o dimensionamento horizontal pode não ajudar a melhorar o desempenho de consulta / gravação, conforme mostrado na Figura 5.

Figura 5: estratégia de dimensionamento de ES

ES mandatos escolhendo o número de fragmentos para cada índice no momento da criação de um índice, que não pode ser modificado sem passar por uma etapa de reindexação que é caro e demorado para grandes quantidades de dados. Uma estratégia fixa de tamanho de fragmento pré-configurada poderia ser usada para dados cronometrados, como logs, onde novos shards poderiam ser criados enquanto os shards antigos são descartados. No entanto, essa estratégia não pode ser empregada pelo NMDB, já que vários aplicativos críticos para os negócios podem estar usando os dados, em outras palavras, os dados no NMDB precisam ser duráveis e nem sempre podem ser descartados. No entanto, conforme discutido acima, grandes tamanhos de fragmentos afetam negativamente o desempenho da consulta. Isso requer algum gerenciamento de nível de aplicativo para realocar shards em múltiplos índices, como mostrado na Figura 6.

Figura 6: Criando novos índices ES ao longo do tempo

Da mesma forma, quando um índice ultrapassa um limite, o MDAS cria um índice diferente para o mesmo DS do NMDB, permitindo que os índices cresçam ao longo do tempo e mantendo o tamanho do fragmento dentro de um limite para desempenho ideal de gravação / consulta. O ES tem um recurso chamado alias de índice que é particularmente útil para aliviar a degradação de desempenho causada por grandes tamanhos de fragmentos, o que é adequado para o cenário que explicamos. Um alias de índice poderia apontar para vários índices e atender a consultas agregando resultados de pesquisa em todos os índices dentro do alias.

Indexando dados no NMDB em escala

Uma única instância de documento de mídia pode ser grande, variando de centenas de MBs a vários GBs. Muitos bancos de dados de documentos (incluindo ES) têm um limite no tamanho de um documento, após o qual o desempenho do banco de dados se degrada significativamente. A indexação de documentos grandes pode apresentar outros desafios em um sistema de dados, como a necessidade de conexões de I / O de alta rede, maiores custos de computação e memória, altas latências de indexação e outros efeitos adversos.

Em princípio, poderíamos aplicar o relacionamento pai-filho ES nos vários níveis da hierarquia do documento de mídia e dividir uma instância de documento de mídia em vários documentos de ES menores. No entanto, o relacionamento pai-filho do ES é um relacionamento de dois níveis e o desempenho da consulta sofre quando vários desses relacionamentos são encadeados para representar um modelo profundamente aninhado (o modelo NMDB Media Document exibe até cinco níveis de aninhamento). Como alternativa, poderíamos considerar modelá-lo como um relacionamento de dois níveis com as entidades de alta cardinalidade ("Evento" e "Região") no lado "filho" do relacionamento. No entanto, o documento de mídia pode conter um grande número de entidades "Evento" e "Região" (centenas de milhares de eventos e dezenas de regiões por evento são típicos para uma hora de conteúdo), o que resultaria em um grande número de documentos filhos. Isso também pode afetar negativamente o desempenho da consulta.

Para lidar com essas limitações opostas, surgiu a ideia de usar “ desnormalização de dados . Adotar isso precisa de mais atenção, pois a desnormalização de dados pode potencialmente levar à explosão de dados. Por meio de um processo denominado “chunking”, dividimos grandes cargas de documentos em vários documentos menores antes de indexá-los no ES. Os documentos em partes menores podem ser indexados usando vários encadeamentos de computação (em um único nó de serviço) ou vários nós de serviço – isso resulta em melhor distribuição de carga de trabalho, uso eficiente de memória, evita pontos de acesso e melhora as latências de indexação (porque estamos processando fragmentos menores de dados simultaneamente). Utilizamos essa abordagem simultaneamente com algumas decisões cuidadosas em torno de quais dados desnormalizamos para fornecer uma indexação ideal e consultar o desempenho. Mais detalhes de nossa implementação são apresentados a seguir.

Instâncias do documento de mídia em blocos

A natureza hierárquica do modelo de documento de mídia (como explicado na postagem do blog anterior) requer uma consideração cuidadosa durante o agrupamento, pois contém relações entre suas entidades. A Figura 7 descreve o pré-processamento que realizamos em uma instância do documento de mídia antes de indexá-lo no ES.

Figura 7: Uma estratégia eficiente para indexação de instâncias de documentos de mídia no ES

  • Cada instância de documento de mídia é dividida igualmente em vários blocos com tamanho menor (da ordem de alguns MBs).
  • As informações de nível de ativos, trilhos e componentes são desnormalizadas em todos os trechos e um documento-pai por trecho com essas informações é indexado no ES. Essa desnormalização do documento pai em diferentes partes também nos ajuda a superar uma grande limitação com o relacionamento pai-filho ES, que é o documento pai e todos os documentos filhos devem pertencer ao mesmo fragmento.
  • No nível de um evento, os dados são desnormalizados em todas as regiões e um documento filho por região é indexado no ES.

Essa arquitetura permite a distribuição de instâncias de documentos de mídia em vários nós e acelera a indexação, bem como o desempenho das consultas. No momento da consulta, o MDAS usa uma combinação de estratégias diferentes, dependendo dos padrões de consulta para atender consultas de maneira eficiente

  • As consultas ES de junção pai-filho são usadas para acelerar o desempenho da consulta quando necessário.
  • Em outro padrão de consulta, os documentos pai são consultados, seguidos por documentos filhos e as junções do lado do aplicativo são executadas no MDAS para criar resultados de pesquisa.

Servindo consultas e análises

Como observado anteriormente, o NMDB tem um tesouro de metadados de mídia indexados e muita informação interessante poderia ser desenvolvida ao analisá-lo. O backend do MDAS com ES forma a espinha dorsal das capacidades analíticas do NMDB. Em um uso típico de análise, os usuários do NMDB estão interessados em dois tipos de consultas:

  1. Uma consulta no nível do DS para recuperar todos os documentos que correspondem à consulta especificada. Isso é semelhante à filtragem de registros usando a cláusula SQL ' WHERE '. A filtragem pode ser feita em qualquer uma das entidades em uma instância de documento de mídia usando vários operadores de condição '=', '>' ou '<' etc. As condições também podem ser agrupadas usando operadores lógicos como OR, AND ou NOT etc.
  2. Uma consulta mais direcionada em uma instância de documento de mídia usando um identificador de documento ID para recuperar partes específicas do documento. Nesse tipo de consulta, os usuários podem aplicar a filtragem condicional em cada uma das entidades de uma instância do documento de mídia e recuperar entidades correspondentes.

Os dois tipos de consulta visam diferentes casos de uso. Consultas do primeiro tipo abrangem todo um DS do NMDB e podem fornecer insights sobre quais documentos em um DS correspondem à consulta especificada. Considerando a enorme carga de dados correspondente às instâncias do documento de mídia que correspondem a uma consulta do primeiro tipo, o NMDB somente retorna as coordenadas (DocumentID e MID) dos documentos correspondentes. O segundo tipo de consulta pode ser usado para direcionar uma instância específica do documento de mídia usando DocumentID e recuperar partes do documento com a filtragem condicional aplicada. Por exemplo, apenas um conjunto de eventos que satisfazem uma consulta especificada pode ser recuperado, juntamente com metadados no nível de Rastreio e Componente. Embora seja típico usar os dois tipos de consultas em sucessão, no caso em que um identificador de documento já é conhecido, é possível obter mais informações sobre os dados executando diretamente o segundo tipo de consulta em uma instância específica do documento de mídia.

Como explicado anteriormente, a fragmentação das instâncias do documento de mídia no momento da indexação é muito útil na otimização de consultas. Como os relacionamentos entre as diferentes entidades de uma instância do documento de mídia são preservados, as consultas entre entidades podem ser tratadas na camada ES. Por exemplo, uma trilha pode ser filtrada com base no número de eventos que ela contém ou se ela contém eventos correspondentes à consulta especificada. A estratégia de indexação, conforme explicado anteriormente, pode ser contrastada com a abordagem de documento aninhado do ES. A indexação de informações de eventos e regiões como documentos infantis nos ajuda a produzir os resultados da pesquisa com mais eficiência.

Qual é o próximo

Conforme explicado no post anterior, o modelo de documento de mídia tem uma estrutura hierárquica e oferece uma maneira lógica de modelar dados de linha de tempo de mídia. No entanto, essa estrutura hierárquica não é ideal para processamento paralelo. Em particular, os serviços de validação (MDVS) e indexação (MDAS) podem se beneficiar imensamente ao processar uma grande instância de documento de mídia em paralelo, reduzindo assim as latências de gravação. Uma estrutura de composição para as instâncias do documento de mídia seria mais acessível ao processamento paralelo e, portanto, ajudaria bastante a aliviar os desafios impostos pelas grandes instâncias do documento de mídia. Resumidamente, tal estrutura implica que uma única linha de tempo de mídia é composta de múltiplas linhas de tempo de mídia “menores”, onde cada linha de tempo de mídia é representada por uma instância de documento de mídia “menor” correspondente. Esse modelo também permite leituras direcionadas que não exigem a leitura de toda a instância do documento de mídia.

No lado da consulta, prevemos uma necessidade crescente de executar junções em diferentes armazenamentos de dados NMDB – isso poderia ser computacionalmente intensivo em alguns cenários. Isso, juntamente com os altos custos de armazenamento associados ao ES, está nos motivando a procurar outras soluções de armazenamento de “big data”. Como o NMDB continua a ser a plataforma de metadados de mídia preferida para aplicativos em toda a Netflix, continuaremos a considerar cuidadosamente novos casos de uso que talvez precisem ser suportados e avaliar tecnologias que precisaremos integrar para resolvê-los. Algumas áreas interessantes de trabalho futuro poderiam envolver a exploração de estruturas Map-Reduce, como o Apache Hadoop, para computação distribuída, processamento de consultas, bancos de dados relacionais para seu suporte transacional e outras tecnologias de Big Data. Oportunidades são abundantes na área de sistemas de dados orientados a mídia na Netflix, especialmente com o crescimento previsto em aplicativos de negócios e dados associados.

– por Shinjan Tiwary, Sreeram Chakrovorthy, Subbu Venkatrav, Arsen Kostenko, Yi Guo e Rohit Puri