#apache-iceberg

EDB converges analytics on Postgres to support AI agents

EDB bổ sung khả năng phân tích hội tụ cho dịch vụ cơ sở dữ liệu EDB Postgres AI, sử dụng Apache Iceberg làm lớp danh mục chia sẻ kết nối ClickHouse, WarehousePG và Spark, đồng thời cung cấp tính năng "agentic database" tự động hóa nhiệm vụ DBA định kỳ. Giải pháp này nhấn mạnh quyền kiểm soát dữ liệu tại chỗ cho doanh nghiệp, khác biệt với cách tiếp cận lakehouse của Databricks, và có mức giá theo lõi CPU ổn định hơn so với các nền tảng cloud theo mức tiêu thụ.

Lập trình viên cần đọc bài này để hiểu cách Postgres AI của EDB kết hợp với Iceberg và các công cụ phân tích khác để tạo ra một hệ sinh thái tích hợp, giúp tối ưu hóa quy trình phát triển ứng dụng AI với tính linh hoạt, kiểm soát dữ liệu và chi phí dự đoán hơn so với các giải pháp cloud tiêu thụ.

How to Eliminate Training-Serving Skew in MLOps (2026)

Training-serving skew — the divergence between features used during model training and those seen at inference time — silently degrades ML accuracy and doubles infrastructure costs. The solution is a unified kappa architecture: compute features once in Apache Flink, dual-write to an offline store (Apache Iceberg or Delta Lake) for training and an online key-value cache for serving. DoorDash measured a 35.7% feature-value mismatch in their dual-pipeline setup; Netflix replaced a $93M/year dual-pipeline backfill with a $2M/year kappa replay. The reference architecture covers Kafka ingestion via Confluent's Kora engine, serverless Flink with event-time watermarks and exactly-once semantics, Tableflow for automated Iceberg/Delta materialization, and Stream Governance for schema enforcement and lineage. A tooling comparison covers Databricks, SageMaker+Kinesis, Tecton, Feast, and Confluent, with a decision framework based on latency requirements, existing stack investment, and pipeline fragmentation. The post is authored by a Confluent employee and promotes the Confluent Data Streaming Platform throughout.

Bridge Queries in Redpanda SQL

Redpanda SQL introduces bridge queries, a feature that lets you query live Redpanda topic data and historical Iceberg table data together through a single virtual SQL table. This eliminates the classic streaming-to-lakehouse tradeoff between data freshness and Parquet file quality. Previously, frequent flushes to Iceberg were needed for low-latency analytics, resulting in thousands of tiny Parquet files, poor compression, high S3 costs, and constant compaction overhead. With bridge queries, the topic itself serves the freshness gap at query time, so Iceberg flushes can happen on a longer cadence (hours instead of seconds/minutes), producing larger, analytics-optimized Parquet files. Configuration involves raising the iceberg lag target and optionally the flush size threshold. The result is lower query latency, reduced S3 costs, and no need for a compaction service.