Deep Lake, um Lakehouse para Deep Learning: Discussão e Limitações

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

7. DISCUSSÃO E LIMITAÇÕES

Os principais casos de uso do Deep Lake incluem (a) Treinamento de modelo de aprendizado profundo, (b) Linhagem de dados e controle de versão, (c) Consulta e análise de dados, (d) Inspeção de dados e controle de qualidade. Tomamos os arrays NumPy [55] como um bloco fundamental e implementamos

controle de versão, dataloaders de streaming, mecanismo de visualização do zero.

7.1 Espaço de Design de Formato

O Tensor Storage Format (TSF) é um formato de arquivo binário projetado especificamente para armazenar tensores, que são matrizes multidimensionais de valores numéricos usados em muitos algoritmos de aprendizado de máquina e aprendizado profundo. O formato TSF foi projetado para ser eficiente e compacto, permitindo armazenamento e acesso rápido e eficiente de dados tensores. Uma vantagem importante do formato TSF é que ele suporta uma ampla variedade de tipos de dados de tensores, incluindo tensores de formato dinâmico.

Em comparação, os formatos Parquet [79] e Arrow [13] são formatos de arquivo colunares projetados para armazenar e processar grandes conjuntos de dados analíticos. Ao contrário do TSF, que é projetado especificamente para dados tensores, o Parquet e o Arrow são otimizados para armazenamento e consulta eficientes de cargas de trabalho analíticas em dados tabulares e de série temporal. Eles usam técnicas de armazenamento e compactação colunares para minimizar o espaço de armazenamento e melhorar o desempenho, tornando-os adequados para aplicativos de big data. No entanto, o TSF tem algumas vantagens sobre o Parquet e o Arrow quando se trata de dados tensores. O TSF pode oferecer suporte a operações de tensor e streaming eficiente para estruturas de aprendizado profundo.

Outros formatos de tensor [18, 52, 23, 57] são eficientes para cargas de trabalho massivamente paralelizáveis, pois não requerem coordenação entre blocos. A principal compensação do formato de armazenamento do tensor permite armazenar matrizes de forma dinâmica dentro de um tensor sem preencher o espaço de memória. Por exemplo, em visão computacional é muito comum armazenar múltiplas imagens com formatos diferentes ou vídeos com duração dinâmica. Para apoiar a flexibilidade, uma pequena sobrecarga é introduzida na forma do codificador de partes discutido anteriormente que, na prática, não observamos impacto nas cargas de trabalho de produção.

7.2 Carregador de dados

Deep Lake alcança resultados de última geração em configurações locais e remotas, como visto em benchmarks para iteração em imagens grandes Fig. 7. Principalmente, foi mais rápido que FFCV [39], que alegou uma redução no treinamento do modelo ImageNet até 98 centavos por treinamento de modelo. Além disso, Deep Lake atinge desempenho de ingestão semelhante ao WebDataset [19]. Deep Lake tem desempenho significativamente superior em imagens maiores. O Parquet é otimizado para células pequenas e cargas de trabalho analíticas, enquanto o Deep Lake é otimizado para dados tensoriais grandes e de formato dinâmico. Em comparação com outras soluções de data lake, seu design de pacote python mínimo permite que o Deep Lake seja facilmente integrado em treinamento distribuído em grande escala ou cargas de trabalho de inferência.

7.3 Trabalho futuro

A implementação atual do Deep Lake oferece oportunidades para melhorias adicionais. Em primeiro lugar, o formato de armazenamento não suporta ordenação personalizada para um layout de armazenamento ainda mais eficiente, necessário para pesquisa vetorial ou indexação de valores-chave. Em segundo lugar, Deep Lake implementa bloqueios baseados em ramificações para acesso simultâneo. Semelhante ao modelo de transação Delta ACID [27], Deep Lake pode ser estendido para cargas de trabalho paralelas de alto desempenho. Em terceiro lugar, a implementação atual do TQL suporta apenas um subconjunto de operações SQL (ou seja, não suporta operações como join). O trabalho futuro se concentrará em torná-lo SQL completo, estendendo-se a operações mais numéricas, executando consultas federadas em fontes de dados externas e comparando-as com mecanismos SQL.