Delta Lake is a transactional table format and multi-engine connector suite. In production it writes Parquet data files alongside a JSON transaction log (`_delta_log`) and periodic checkpoints; every commit is an atomic append of log actions. Readers reconstruct table snapshots by replaying the log and checkpoints, enabling ACID operations, time travel, schema evolution, and incremental streaming on object storage. This repository is the reference implementation of that protocol, not an end-user data platform. The architecture is a multi-module Scala/Java/Python monorepo: `spark/` contains the Spark V1 and V2 connectors plus SQL extensions; `kernel/` is a standalone Java, engine-agnostic library exposing `Engine`, `TableManager`, `TransactionBuilder`, and a default Hadoop engine; `storage/` provides LogStore abstractions and cloud-specific commit coordination; and `flink/`, `iceberg/`, `sharing/`, and `python/delta` provide additional engine integrations. Key entry points are `DeltaTable`, `DeltaSparkSessionExtension`, `io.delta.kernel.TableManager`, and Flink's `DeltaDynamicTableSource`/`DeltaDynamicTableSink`. The central data flow is client -> `OptimisticTransaction`/Kernel `Transaction` -> log action -> LogStore commit; reads use `Snapshot`/`SnapshotBuilder` to replay log actions. External dependencies include Apache Spark, Hadoop FileSystem, Parquet, Jackson, and optional cloud SDKs. Maintenance is genuinely active: recent commits, CI matrices for Spark 4.0-4.2, Flink, Iceberg, Kernel, and Unity Catalog, plus a large compatibility test suite. The codebase nevertheless carries transitional complexity: a V2/Kernel-backed Spark connector coexists with the legacy V1 path, many Spark-version shims exist, test suites are partly auto-generated, and the old `connectors/` directory is explicitly in maintenance mode. Those factors prevent a perfect score, but this is a mature, high-craft storage-format project.
This is the NVIDIA RAPIDS Accelerator for Apache Spark (formerly cudf-spark), a high-performance Spark SQL plugin that replaces CPU-based Spark physical operators with GPU-accelerated equivalents using the cuDF library. The codebase provides a comprehensive shim layer supporting over 20 distinct Spark versions (3.3.x through 5.0.x) including Databricks runtimes, along with deep integrations for Delta Lake (2.x–4.x) and Apache Iceberg (1.6–1.11). It implements GPU versions of nearly every Spark SQL execution node: scans, joins, aggregates, windows, shuffles, file format readers/writers for Parquet, ORC, CSV, JSON, Avro, and Hive. The architecture relies on a sophisticated multi-version shim pattern, service-loading providers, and extensive use of Spark internal APIs to intercept and redirect execution to GPU columnar operations. The repository also includes a UDF compilation framework that converts Scala UDFs to GPU expressions, and a set of performance profiling and metrics tools. Despite its massive scope and high shim count, the codebase is well-structured with clear separation of concerns, comprehensive testing, and active release cadence. It is primarily an application (Spark plugin) with some auxiliary tooling for data generation and testing, but no data research elements.
pg_mooncake is a Postgres extension that adds a custom table access method ('mooncake') backed by Apache Iceberg, enabling real-time analytics on columnar data stored in Iceberg tables. It integrates DuckDB (via pg_duckdb) as the query engine for fast analytics and provides a background worker (moonlink) that streams changes from regular Postgres heap tables to Iceberg tables via logical replication, ensuring sub-second data freshness. The extension exposes SQL procedures to create columnstore mirrors of Postgres tables, manage snapshots, load files, and optimize storage. It is built using the pgrx framework for Rust-based Postgres extensions and supports Postgres versions 14-18. The architecture is a hybrid of a shared library loaded into the Postgres backend and a separate background worker process. The codebase is well-structured and actively developed, though many table access method callbacks are still stubs, indicating it is in an early but functional stage.