Deep Lake, um Lakehouse para Deep Learning: Visão geral do sistema Deep Lake

Tabela de links

• Resumo e introdução
• Desafios Atuais
• Formato de armazenamento tensor
• Visão geral do sistema Deep Lake
• Casos de uso de aprendizado de máquina
• Referências de desempenho
• Discussão e Limitações
• Trabalho relatado
• Conclusões, agradecimentos e referências

4. VISÃO GERAL DO SISTEMA DE LAGOS PROFUNDOS

Conforme mostrado na Figura 1, Deep Lake armazena dados brutos e visualizações em armazenamento de objetos como S3 e materializa conjuntos de dados com linhagem completa. O streaming, as consultas da Tensor Query Language e o mecanismo de visualização são executados junto com a computação de aprendizado profundo ou no navegador, sem exigir serviço externo gerenciado ou centralizado.

4.1 Ingestão

4.1.1 Extrair. Às vezes, os metadados já podem residir em um banco de dados relacional. Além disso, construímos um conector de destino ETL usando Airbyte[3] [22]. A estrutura permite conectar-se a qualquer fonte de dados compatível, incluindo bancos de dados SQL/NoSQL, data lakes ou data warehouses, e sincronizar os dados no Deep Lake. O protocolo Connector transforma os dados em um formato colunar.

4.1.2 Transformar. Para acelerar significativamente os fluxos de trabalho de processamento de dados e evitar que os usuários se preocupem com o layout dos blocos, Deep Lake oferece uma opção para executar transformações python em paralelo. A transformação recebe um conjunto de dados, itera por amostra na primeira dimensão e gera um novo conjunto de dados. Uma função python definida pelo usuário espera dois argumentos obrigatórios 𝑠𝑎𝑚𝑝𝑙𝑒_𝑖𝑛, 𝑠𝑎𝑚𝑝𝑙𝑒_𝑜𝑢𝑡 e é decorada com @𝑑𝑒𝑒𝑝𝑙𝑎𝑘𝑒. 𝑐𝑜𝑚𝑝𝑢𝑡𝑒. Um único 𝑠𝑎𝑚𝑝𝑙𝑒_𝑖𝑛 pode criar dinamicamente vários 𝑠𝑎𝑚𝑝𝑙𝑒_𝑜𝑢𝑡𝑠. Ele permite transformações um para um e um para muitos. A transformação também pode ser aplicada no local sem criar um novo conjunto de dados.

Nos bastidores, o agendador agrupa transformações baseadas em amostras operando em partes próximas e as agenda em um pool de processos. Opcionalmente, a computação pode ser delegada a um cluster Ray [53]. Em vez de definir um conjunto de dados de entrada, o usuário pode fornecer um iterador arbitrário com objetos personalizados para criar fluxos de trabalho de ingestão. Os usuários também podem empilhar várias transformações e definir pipelines complexos.

4.2 Controle de Versão

Deep Lake também atende à necessidade de reprodutibilidade de experimentos e conformidade com uma linhagem de dados completa. Existem diferentes versões do conjunto de dados no mesmo armazenamento, separadas por subdiretórios. Cada subdiretório atua como um conjunto de dados independente com seus arquivos de metadados. Ao contrário de um conjunto de dados sem versão, esses subdiretórios contêm apenas pedaços modificados na versão específica, junto com um chunk_set correspondente por tensor contendo os nomes de todos os pedaços modificados. Um arquivo de informações de controle de versão presente na raiz do diretório rastreia o relacionamento entre essas versões como uma árvore ramificada de controle de versão. Ao acessar qualquer pedaço de um tensor em uma versão específica, a árvore de controle de versão é percorrida a partir do commit atual, indo em direção ao primeiro commit. Durante a travessia, o conjunto de blocos de cada versão é verificado quanto à existência do bloco necessário. Se o pedaço for encontrado, a travessia será interrompida e os dados serão recuperados. Para acompanhar as diferenças entre as versões, para cada versão, um arquivo diff de commit também é armazenado por tensor. Isso torna mais rápida a comparação entre versões e ramificações. Além disso, os ids das amostras são gerados e armazenados durante a população do conjunto de dados. Isto é importante para acompanhar as mesmas amostras durante as operações de mesclagem. A interface de controle de versão do Deep Lake é a API Python, que permite aos engenheiros de aprendizado de máquina versionar seus conjuntos de dados dentro de seus scripts de processamento de dados sem alternar entre a CLI. Ele suporta os seguintes comandos:

• Commit : cria um instantâneo imutável do estado atual do conjunto de dados.

• Checkout : faz check-out em um branch/commit existente ou cria um novo branch se não existir.

• Diff : compara as diferenças entre 2 versões do conjunto de dados.

• Mesclar : mescla duas versões diferentes do conjunto de dados, resolvendo conflitos de acordo com a política definida pelo usuário.

4.3 Visualização de Tensores

A visualização de dados é uma parte crucial dos fluxos de trabalho de ML, especialmente quando os dados são difíceis de analisar analiticamente. A visualização rápida e contínua permite coleta de dados, anotação, inspeção de qualidade e iterações de treinamento mais rápidas. O mecanismo visualizador Deep Lake fornece uma interface da web para visualizar dados em grande escala diretamente da fonte. Considera o htype dos tensores para determinar o melhor layout para visualização. Tensores primários, como imagem, vídeo e áudio, são exibidos primeiro, enquanto dados e anotações secundários, como texto, class_label, bbox e binary_mask são sobrepostos. O visualizador também considera as informações do metatipo, como sequência, para fornecer uma visualização sequencial dos dados, onde as sequências podem ser reproduzidas e pular para a posição específica da sequência sem buscar os dados inteiros, o que é relevante para casos de uso de vídeo ou áudio. . O Visualizer atende a necessidades críticas em fluxos de trabalho de ML, permitindo que os usuários entendam e solucionem problemas dos dados, descrevam sua evolução, comparem previsões com dados reais ou exibam múltiplas sequências de imagens (por exemplo, imagens de câmeras e mapas de disparidades) lado a lado.

4.4 Linguagem de consulta tensorial

Consultar e balancear conjuntos de dados é uma etapa comum no treinamento de fluxos de trabalho de aprendizagem profunda. Normalmente, isso é conseguido dentro de um dataloader usando estratégias de amostragem ou etapas separadas de pré-processamento para subselecionar o conjunto de dados. Por outro lado, os data lakes tradicionais se conectam a mecanismos de consulta analítica externos [66] e transmitem Dataframes para fluxos de trabalho de ciência de dados. Para resolver a lacuna entre o formato e o acesso rápido aos dados específicos, fornecemos um mecanismo de consulta incorporado semelhante ao SQL implementado em C++ chamado Tensor Query Language (TQL). Um exemplo de consulta é mostrado na Figura 5. Embora o analisador SQL tenha sido estendido de Hyrise [37] para projetar a Tensor Query Language, implementamos nosso planejador e mecanismo de execução que pode opcionalmente delegar a computação para estruturas externas de computação de tensores. O plano de consulta gera um gráfico computacional de operações de tensores. Em seguida, o agendador executa o gráfico de consulta.

A execução da consulta pode ser delegada a estruturas externas de computação de tensores, como PyTorch [58] ou XLA [64] e utilizar com eficiência o hardware acelerado subjacente. Além dos recursos SQL padrão, o TQL também implementa computação numérica. Existem duas razões principais para implementar uma nova linguagem de consulta. Primeiro, o SQL tradicional não suporta operações de array multidimensionais, como calcular a média dos pixels da imagem ou projetar arrays em uma dimensão específica. O TQL resolve isso adicionando indexação no estilo Python/NumPy, fatiamento de arrays e fornecendo um grande conjunto de funções convenientes para trabalhar com arrays, muitas das quais são operações comuns suportadas em NumPy. Em segundo lugar, o TQL permite uma integração mais profunda da consulta com outros recursos do Deep Lake, como controle de versão, mecanismo de streaming e visualização. Por exemplo, o TQL permite consultar dados em versões específicas ou potencialmente em várias versões de um conjunto de dados. O TQL também oferece suporte a instruções específicas para personalizar a visualização do resultado da consulta ou integração perfeita com o carregador de dados para streaming filtrado. O mecanismo de consulta incorporado é executado junto com o cliente durante o treinamento de um modelo em uma instância de computação remota ou compilado no navegador por meio do WebAssembly. TQL estende SQL com cálculos numéricos sobre colunas multidimensionais. Ele constrói visualizações de conjuntos de dados, que podem ser visualizados ou transmitidos diretamente para estruturas de aprendizagem profunda. No entanto, as visualizações de consulta podem ser esparsas, o que pode afetar o desempenho do streaming.

4.5 Materialização

A maioria dos dados brutos usados para aprendizagem profunda são armazenados como arquivos brutos (compactados em formatos como JPEG), localmente ou na nuvem. Uma maneira comum de construir conjuntos de dados é preservar ponteiros para esses arquivos brutos em um banco de dados, consultá-los para obter o subconjunto de dados necessário, buscar os arquivos filtrados em uma máquina e, em seguida, treinar um modelo iterando sobre os arquivos. Além disso, a linhagem dos dados precisa ser mantida manualmente com um arquivo de proveniência. O Tensor Storage Format simplifica essas etapas usando tensores vinculados - armazenando ponteiros (links/urls para um ou vários provedores de nuvem) para os dados originais. Os ponteiros dentro de um único tensor podem ser conectados a vários provedores de armazenamento, permitindo assim que os usuários obtenham uma visão consolidada de seus dados presentes em múltiplas fontes. Todos os recursos do Deep Lake, incluindo consultas, controle de versão e streaming para estruturas de aprendizado profundo, podem ser usados com tensores vinculados. No entanto, o desempenho do streaming de dados não será tão ideal quanto o dos tensores padrão. Existe um problema semelhante com visualizações esparsas criadas devido a consultas, que seriam transmitidas de forma ineficiente devido ao layout do bloco. Além disso, a materialização transforma a visualização do conjunto de dados em um layout ideal para transmitir em estruturas de aprendizagem profunda para iterar mais rapidamente. A materialização envolve buscar os dados reais de links ou visualizações e distribuí-los com eficiência em pedaços. A execução desta etapa no final dos fluxos de trabalho de aprendizado de máquina leva a uma duplicação mínima de dados, garantindo ao mesmo tempo um desempenho ideal de streaming e uma duplicação mínima de dados, com linhagem de dados completa.

4.6 Carregador de dados de streaming

À medida que os conjuntos de dados aumentam, o armazenamento e a transferência pela rede a partir de um armazenamento distribuído remotamente tornam-se inevitáveis. O streaming de dados permite o treinamento de modelos sem esperar que todos os dados sejam copiados para uma máquina local. O dataloader de streaming garante a busca, descompactação de dados, aplicação de transformações, agrupamento e transferência de dados para o modelo de treinamento. Os dataloaders de aprendizagem profunda normalmente delegam a busca e a transformação para processos de execução paralela para evitar a computação síncrona. Em seguida, os dados são transferidos para o trabalhador principal por meio de comunicação entre processos (IPC), que introduz sobrecarga de cópia de memória ou usa memória compartilhada com alguns problemas de confiabilidade. Em contraste, o dataloader Deep Lake delega busca altamente paralela e descompactação local em C++ por processo para evitar o bloqueio global do intérprete. Em seguida, ele passa o ponteiro na memória para a função de transformação definida pelo usuário e os agrupa antes de expô-los ao loop de treinamento no layout de memória nativa de aprendizado profundo. A transformação é executada simultaneamente em paralelo quando usa apenas chamadas de rotina da biblioteca nativa e libera o bloqueio de interpretador global (GIL) do python de acordo. Como resultado, obtemos:

• Desempenho : entrega de dados ao modelo de aprendizagem profunda com rapidez suficiente para que a GPU seja totalmente utilizada ou seja prejudicada pela computação.

• Smart Scheduler : diferenciando dinamicamente a priorização de trabalhos com uso intensivo de CPU em relação aos menos intensivos.

• Alocação Eficiente de Recursos : Prever o consumo de memória para evitar interrupções no processo de treinamento devido ao excesso de memória.

[3] Código-fonte disponível: https://github.com/activeloopai/airbyte na filial @feature/connector/deeplake