Jay Chia argues that many machine learning data platforms can start with S3, Parquet, and Daft instead of a large collection of specialized systems.
2
Daft lets Python users clean, transform, analyze, and load multimodal data such as images, tensors, URLs, and embeddings through one dataframe interface.
3
The demo turns scraped JSON web-page records into one-image-per-row Parquet data with thumbnails and URLs, then streams selected columns into training.
Summary
Jay Chia presents Daft as a Python-native data engine for the difficult middle stage of machine learning: turning raw, multimodal data into a usable training set. He reduces the basic platform to S3 for storage, Parquet for open file formats, and Daft for ETL, analytics, and data loading. In the demo, scraped JSON contains web pages, text, image metadata, URLs, and similarity matrices. Daft explodes the nested records into image rows, downloads and decodes images, handles missing URLs, resizes thumbnails, uploads JPEGs, and writes a clean Parquet dataset. The same interface then filters rows and iterates over selected columns for training. Chia explains why Daft avoids some Python and JVM friction found in Spark and Flink, and describes local and Ray-based distributed execution. He is also building SQL support and integrations with lake formats, so Daft can cover more of a bronze-to-gold workflow for complex data.
Data curation needs ETL, analytics, and fast loading
Jay Chia describes three practical requirements for an ML data platform. ETL means transforming raw data, filtering it, joining tables, or running a model over a column. Analytics means asking questions about multimodal records with SQL, such as how many images show pedestrians or empty roads. Data loading must move the curated result into training fast enough to make use of expensive GPUs. He calls these three functions the core of data curation, with multimodal types making each one harder than ordinary tabular processing.
S3, Parquet, and Daft cover most of the initial platform
Jay proposes what he calls the 80% ML stack: Parquet stored in S3, with Daft or another query engine on top. S3 provides scalable cloud storage, while Parquet remains readable by Spark, dbt, pandas, and PyArrow. He recommends storing image URLs in Parquet and keeping the image bytes in native formats such as JPEG. This keeps the data open and lets tools such as browsers and FFmpeg work with the files. Catalogs, table formats, feature stores, vector search, and orchestration can be added later.
Daft flattens nested multimodal records into workable rows
The demo starts with an MMC4 JSON dataset where each row represents a scraped web page containing text, images, metadata, and similarity values. Jay uses Daft to explode the image information and similarity matrix so that each image becomes its own row. He then splats the image struct into ordinary columns such as the raw URL, image name, matched text index, and similarity. This converts a nested web-page representation into an image dataset that can be filtered and processed through a dataframe interface.
The image pipeline handles dirty internet data in a few operations
Daft downloads images from URL columns and decodes them into image values. The first attempt exposes missing files because many scraped URLs no longer work. Jay then configures failed downloads to become null values and converts valid images to RGB, allowing the operation to continue across the dataset. He resizes images to 64 by 64 thumbnails, uploads full images as JPEGs, removes the heavyweight image column, and writes the result to Parquet. The output keeps thumbnails and URLs while avoiding large embedded image values.
The same curated data can feed analytics and training
After writing the dataset, Jay selects columns and filters rows using a similarity threshold. He then iterates over the result and calls next to receive arrays and other requested fields for a training pipeline. This gives Daft one interface for data processing, inspection, and loading. The full-size images remain in cloud storage, while the Parquet file contains compact metadata and thumbnails. The design avoids making a separate training loader for every data preparation workflow.
Jay says Daft is designed for users who need to call Python libraries and models during feature engineering. He contrasts this with Spark and Flink workloads where Python code crosses into a JVM system, requiring data conversion, serialization, and communication across the boundary. Daft has a Python API with an implementation in Rust, which lets it use columnar access and SIMD execution. His argument is practical: Python operations are easier to express, and the engine avoids some of the friction caused by Java-to-Python handoffs.
Daft can run locally or through Ray when the workload grows
Jay says Daft handles terabytes of multimodal data and can run on one machine or a cluster. His usual local setup is a laptop or a large EC2 machine, while distributed execution uses a Ray cluster launched on Kubernetes or directly on Amazon EC2. He describes a planned project intended to make starting a Daft cluster from the command line easier for AWS users. Orchestrators such as Flyte and Prefect can request a large node or a Ray cluster, then use Daft for the compute inside a workflow step.
SQL support would extend Daft from raw data to analyzed datasets
Jay says Daft is already focused on early machine learning data work, especially cleaning complex data and writing to Iceberg or Delta Lake. He is also adding SQL so users can query the resulting datasets. He describes a common enterprise pattern where Python handles bronze-to-silver and silver-to-gold transformations, followed by SQL for analysis. Daft's intended direction is to cover more of that path when the data includes images, tensors, URLs, or other complex values, while retaining the same Python-oriented system.
