Data Inlining in DuckLake: Unlocking Streaming for Data Lakes β DuckLake
TL;DR: DuckLakeβs data inlining stores small updates directly in the catalog, eliminating the βsmall files problemβ and making continuous streaming into data lakes practical. Our benchmark shows 926Γ faster queries and 105Γ faster ingestion when compared to Iceberg.
Data lakes let users avoid being locked into a single database. They work by storing data in open formats (most commonly Parquet ). Most data lakes, like Iceberg , Hudi , and Delta , also store their metadata (the bits of information that tell you which files you need to read for a certain query) in open formats such as JSON and Avro files. This means anyone can implement a system that reads and writes these formats, freeing users from being locked into a single commercial solution.
Storing data in traditional data lakes is often connected to performance issues. The root of the problem is that every small write creates a new data file and updates the metadata. This leads to a proliferation of tiny objects in storage. On the read side, queries now have to traverse an increasing number of metadata entries just to figure out what to scan.
These are particularly painful problems for streaming workloads as they perform many small insertions over long periods of time: every insert creates a tiny Parquet file and metadata files. A thousand inserts per second means a thousand of these little files accumulating, which causes performance to degrade. At this point, you are then forced to compact your files, which requires you to schedule and execute these maintenance operations to keep your data lake running, which in turn affects performance even more while the maintenance job executes.
DuckLake flips the script: because it uses a database as its catalog, it can store small updates directly in the catalog instead of immediately writing them to storage as Parquet files. We call this technique data inlining and will describe it in this blog post.
The typical example of a streaming workload is sensor data that is updated at a constant interval. For a practical example consider a case where we insert 100 observations to the datalake.