Sistema de control de versiones de datos

 (dvc.org)
2 puntos por GN⁺ 2024-10-21 | 1 comentarios | Compartir por WhatsApp
  • Data Version Control es un conjunto de herramientas con un modelo similar a Git para gestionar datos como si fueran código, lo que permite aplicar prácticas de ingeniería de software a equipos de datos, IA/ML y ciencia de datos
  • lakeFS responde a las necesidades de infraestructura de datos y de IA/ML a gran escala, con un enfoque en manejar almacenamiento de objetos multimodal y data lakes de escala petabyte en operaciones complejas de IA y entornos de big data
  • Para proyectos pequeños de ciencia de datos, la extensión Git de DVC está orientada a que científicos de datos individuales incorporen el control de versiones de datos a su flujo de trabajo con baja sobrecarga
  • DVC se ofrece como software libre y de código abierto, también cuenta con la extensión DVC for VS Code, y en su repositorio de GitHub aparecen 15,713 estrellas
  • Con la incorporación de la comunidad de DVC a la familia lakeFS, se puede consultar por separado la distinción de roles entre lakeFS y DVC, así como las preguntas frecuentes relacionadas

El papel de Data Version Control

  • Data Version Control plantea como objetivo “gestionar los datos de la misma forma en que se gestiona el código”
  • Mediante un modelo similar a Git, ayuda a que los equipos de datos, IA/ML y ciencia de datos aprovechen las mejores prácticas de ingeniería de software
  • Los casos de uso se dividen en dos grandes grupos
    • Equipos de infraestructura de IA/ML y datos
    • Flujos de trabajo locales y proyectos pequeños de ciencia de datos

Público objetivo y ruta de inicio por producto

  • lakeFS es una infraestructura de control de versiones de datos para equipos empresariales de IA e ingeniería de datos
    • Está dirigido a operaciones complejas de IA y entornos de big data
    • Maneja almacenamiento de objetos multimodal y data lakes de escala petabyte
    • Se ofrecen como enlaces de inicio Get started with lakeFS y Book a Demo
  • DVC es una extensión de Git para científicos de datos individuales
    • Su objetivo es un control de versiones de datos sencillo adaptado a proyectos pequeños de ciencia de datos
    • Puede aplicarse a flujos de trabajo de ciencia de datos con una sobrecarga mínima
    • El enlace de inicio es Get started with DVC
  • También puede usarse desde VS Code mediante la extensión DVC for VS Code
  • La comunidad de DVC se unió a la familia lakeFS, y la información relacionada enlaza a lakeFS and DVC y FAQs
  • El repositorio de GitHub de DVC es treeverse/dvc, y en la página aparecen 15,713 estrellas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-21
Comentarios de Hacker News

  • He usado DVC en la mayoría de mis proyectos durante los últimos 5 años, y la ventaja es que funciona como Git
    Si los científicos entienden ramas, commits y diferencias, entonces también pueden entender DVC. La desventaja es que también funciona como Git, y en la práctica muchos científicos no entienden bien ni usan ramas, commits y diferencias. Lo mejor es que prácticamente te obliga a seguir Ten Simple Rules for Reproducible Computational Research. En los equipos donde trabajé, la reproducibilidad era un gran reto

    • A mí me pasó algo parecido, y la resistencia al aprendizaje de Git es bastante fuerte, lo cual hasta cierto punto se entiende
      Los investigadores saben qué es Git y que tiene valor, pero piensan que aprenderlo toma demasiado tiempo y quieren avanzar rápido. Para este tipo de investigadores empecé a crear una herramienta llamada Calkit(https://github.com/calkit/calkit) para simplificar e integrar Git y DVC. Quiero convencerlos de que trabajar de forma reproducible es más rápido a largo plazo y, al final, permite dedicar el trabajo de manera más directa a hacer avanzar todo el campo más rápido

  • Soy mantenedor y autor de DVC, y me alegra ver a DVC en la portada
    Puedo responder preguntas sobre DVC y su proyecto hermano DataChain https://github.com/iterative/datachain. DataChain es una herramienta de control de versiones de datos con supuestos algo distintos, con transformaciones de datos integradas y sin copiar archivos

    • Si todos los archivos de datos fueran archivos de texto, me pregunto cuál sería la diferencia entre DVC y Git puro
    • Principalmente hago consultoría como ingeniero de datos y no soy especialista en MLOps, pero esto me interesa
      Tengo archivos Parquet de 10 años provenientes de más de 300 tópicos de Kafka, y ahora estoy migrando a Apache Iceberg. Planeo hacer backfill solo cuando sea necesario, y sería bueno poder rastrear ese proceso con Git. Me pregunto si encaja bien con ese uso. Otra posibilidad es rastrear los cambios de esquema de una manera mejor que la actual. Llevo más de 20 años en este campo y veo que anything-as-code encaja bien con los datos

  • Qué bueno ver que DVC se discuta aquí
    Como herramienta, simplificó mucho el control de versiones de datos y modelos, y fue un gran punto de inflexión para mucha gente en el espacio de MLOps. En particular, es una forma ingeniosa de almacenar archivos grandes conectándolos directamente desde un repositorio Git a un almacén de objetos arbitrario, sin un servidor de aplicaciones separado como git-lfs ni reescritura de Git. En DagsHub https://dagshub.com llevamos mucho tiempo integrándonos directamente con DVC para que los equipos puedan hacer visualización y etiquetado de datasets, gestión de modelos, ejecución colaborativa de experimentos y seguimiento de código, datos y modelos en un solo lugar. Si ya usas DVC o lo estás considerando, también existe la opción de usarlo como parte de una cadena de herramientas más cercana al extremo a extremo

  • Me pregunto cómo se compara con Oxen
    https://github.com/Oxen-AI/Oxen

    • Soy mantenedor de Oxen, y la razón por la que lo creamos originalmente fue que DVC era bastante lento y tenía muchas funciones que no necesitábamos
      Optimizamos internamente la estructura de árbol de Merkle, los algoritmos hash, los protocolos de red y demás para hacerlo rápido incluso con datasets grandes. En https://oxen.ai también hay un frontend bastante bueno para ver y consultar datos
    • Si pudiera usar esto junto con GitHub, creo que me cambiaría de DVC de inmediato
    • No conocía Oxen hasta ahora, pero parece una alternativa muy interesante, y me gustaría oír a alguien que haya usado ambos
      Mi primera impresión es que DVC está hecho para usarse junto con Git, como una forma de que DVC administre carpetas arbitrarias dentro de un repositorio Git, mientras que Oxen parece más cercano a una alternativa de repositorio de datos aparte. Además, Oxen parece cubrir áreas que DVC no tiene, con muchas integraciones con dataframes, datos tabulares y datos de entrenamiento e inferencia de IA. En cambio, DVC integra un motor completo de pipelines DAG, importación y exportación, y backends intercambiables

  • No me queda muy claro cómo interactúa esto con los datos
    Guardo tablas Delta en ADLS y no puedo traer datos de producción a local; me pregunto si aun así se puede usar. Si para cambiar a una versión pasada basta con mirar el log de Delta, también dudo cuál sería la razón para usar DVC

    • Por la forma en que yo lo uso, DVC se parece más a git LFS con soporte para varios backends, y también podría verse como un git-annex más simple
      Encima de eso, tiene funciones adicionales especializadas en MLOps. Es útil para versionar entrenamiento de modelos cuando cambian los datos sobre S3

  • Nosotros también evaluamos DVC, pero en ciertos casos de uso el paradigma de Git no resultó tan útil
    Eran archivos de video gigantes que casi no cambiaban, y necesitábamos una copia de los datos del lado del origen y otra copia en cada sistema que ejecutaba el entrenamiento. Al final nos fuimos por archivos y carpetas en un NAS, y funcionó bastante bien. Un enfoque híbrido en el que solo se administre con DVC el metadato del dataset y eso sí se versione parece posible. Pero fue hace algunos años, y me pregunto si ahora hay más soluciones de control de versiones de datos on-premise. La última vez que busqué, la mayoría parecían orientadas a la nube

  • Me gustaría saber cuáles son las ventajas de DVC frente a Apache Iceberg
    Si alguien ha usado ambos, me gustaría conocer su opinión

    • Si eso te interesa, también deberías ver Icechunk, que fue liberado como open source esta semana
      Es parecido a Apache Iceberg, pero es una herramienta para datos multidimensionales como Zarr. https://earthmover.io/blog/icechunk y https://news.ycombinator.com/item?id=41850352
    • No le veo una ventaja clara; más bien se siente como usar una herramienta conocida en un lugar donde no encaja
      Puede que Iceberg esté más orientado a modelos que cambian con menos frecuencia que en este enfoque
    • No lo tengo del todo ordenado en la cabeza, pero si intento explicarlo, un buen ejemplo de los datos blob de los que se habla aquí sería un conjunto de archivos de video 1080p muy largos
      En resumen, lo correcto sería poner los datos blob no estructurados en DVC y los datos estructurados en Iceberg. Lo que DVC hace mejor que Iceberg es que no obliga a meter los datos blob a la fuerza en un formato tabular, evitando los molestos pasos de procesamiento que eso trae consigo. En la práctica, ni siquiera hace falta ejecutar una etapa de procesamiento para extraer los datos blob desde archivos Parquet; basta con descargar cada archivo tal cual con un comando como dvc pull. Luego puedes modificar los archivos localmente y hacer commit con más o menos tres comandos, sin necesitar tampoco un pipeline de ingestión que fuerce los datos blob dentro de una tabla. Al no tener esquema por completo, puedes guardarlos en el repositorio y hacer commit sin preocuparte por tipos. También puedes hacer rollback siguiendo todo el historial de commits, no solo hasta el último vacuum/checkpoint. Meter datos blob en un formato de datos tabular es casi una receta para el sufrimiento, y poner blobs en un repositorio tipo Git es mucho más rápido y sencillo. Eso aplica especialmente si necesitas historial completo de versiones o ramas para distintos resultados; por ejemplo, sería una pesadilla hacerlo en Iceberg si quieres aplicar distintos filtros de ffmpeg por rama a archivos largos de video 1080p y luego permitir que la gente acceda a todos los resultados y al historial, mientras que en DVC es fácil. Al final, como todo queda versionado, se siente como construir un data lake que no termina convertido en un pantano de datos

  • Cuando lo usé con un dataset compuesto por muchos archivos jpg, tuve bastantes problemas
    En cada dvc status, el indexado tardaba varios minutos porque revisaba todos los archivos, y además el caché no funcionaba. Lamentablemente tuve que abandonarlo

    • Sí, correcto; el rendimiento es bastante malo y el caché puede traer muchos dolores de cabeza
      Sobre todo si usas un sistema de archivos que no soporta reflink. Para datasets grandes con shards, como WebDataset, otras soluciones pueden ser mejores, especialmente si tu pipeline de machine learning puede hacer streaming directamente desde el object storage

  • También he oído de lakeFS como herramienta de versionado de datos sobre almacenamiento de objetos S3
    Me pregunto si DVC realmente puede competir en este espacio