3 Notas
Guillem Borrell Nogueras edited this page 2022-08-27 09:09:02 +02:00

Puntos clave

  • Es imposible separar la arquitectura de la funcionalidad. Hagamos lo que hagamos, la arquitectura terminará adaptándose para realizar la funcionalidad de manera más optitma. Si aceptamos este hecho, podemos adaptarlo todo y conseguir sistemas muy eficientes.
  • Apache Arrow es la tecnología más relevante de lo que llevamos de década, y probablemente lo sea en la siguiente.
  • Python es un lenguaje tan válido para la ingeniería de datos como Java.
    • Hace 5 años un cliente me dijo que no correría pyspark en el cluster porque era lento. Me recordó a la gente que prefería el ensamblador al Fortan porque el segundo tardaba mucho en compilar en el año 66
  • Python es un lenguaje tan válido para el cálculo distribuido como los lenguajes funcionales
    • El hecho que en el fondo async sean generadores (yield from) demuestra que se trata de un concepto clave. Hay una charla muy interesante de David Beazley al respecto

Setup

  • No usaremos una Raspberry pi porque compilar todos los paquetes necesarios a esa arquitectura es un montón de tiempo
  • Me tiré un buen rato ya sólo compilando libarrow a armv7l, para lo que tuve que pasar manualmente la arquitectura del procesador a cmake porque no era capaz de detectarla manualmente. Nadie asume que vas a intentar hacer big data con un embedded o una tablet.
  • Al final he comprado un PC de segunda mano que está literalmente en la mesa de mi despacho con el que he preparado la charla y ejectaré todo el código
    • Ha costado prácticamente lo mismo que una RPi de 8 GB, pero tiene un procesador decente y 16G de RAM. Eso sí, el disco es más malo que el agua del bacalao.
  • Haré la presentacin y programaré en una tablet vieja, con el teclado bluetooth más barato que encontré en la tienda donde compran los que creen que no son tontos.

Datos

  • Muchos están en el error que lo más importante del cálculo distribuido es el proceso en paralelo. En realidad es la gestión de los metadatos

    • Los metadatos permiten a los query engines optimizar el acceso a disco mediante filter pushdown.
    • Dentro de poco Arrow podrá hacer predicate pushdown, con lo que todo será más eficiente aún
  • Diferencias entre una base de datos para una aplicación y una base de datos para proceso masivo de datos

    • La primera está normalizada, la segunda muy probablemente no lo esté
  • La operación más frecuente en una base de datos relacional (join) es muy cara si los datos están particionados

  • Dask es una herramienta muy práctica, pero seguramente por los motivos equivocados que creéis. Su capacidad para escalar algoritmos en paralelo es importante, pero también lo es que permita ejecutar tareas out-of-core de manera asíncrona. Si alguna vez habéis pensado "esto lo puedo procesar a cachitos, tardará más, pero no necesitaré una máquina tran grande..." dask es vuestra herramienta.

  • La principal diferencia en arquitectura entre Dask y Spark es que Dask rompe la paralelización en elementos más pequeños. Hace visible cada operación al scheduler, no cada bloque de operaciones como Spark. Eso permite al scheduler utilizar mejor los recursos.

  • Otra herramienta que es ya fundamental en muchos teck stacks es duckdb. Lo es gracias a Arrow. Si Arrow puede cargar algo en memoria, duckdb podrá ejecutar una consulta sobre ello.

  • También tenemos pyarrow. El obeto Table de pyarrow ahora tiene un montn de cosas interesantes en el módulo compute.

  • El análisis de un casino es un buen ejemplo de data quality check

WEB

El futuro será webassembly.

  • shell.duckdb.org