"Data Engineering Weekly #277" — Ananth Packkildurai
Why this is in the vault
Issue 277 arrives at an interesting intersection: the Databricks LTAP announcement (OLTP semantics on Lakehouse storage) continues the LTAP/LakeDB vocabulary thread from issue 276, while Addy Osmani's Loop Engineering piece — already vaulted from its direct source — gets a data engineering framing from Ananth that's worth preserving. The Expedia Spark+LLM article is a concrete, benchmarked implementation of LLM-assisted query debugging with an open-source MCP server, directly applicable to phData client engagements. Two sponsor placements noted.
Sponsorships
- Dagster (top placement): Live session CTA — "Deep Dive: See how Dagster uses AI internally." Promotes their internal AI workflows for concept validation and engineering decisions. Session-specific CTA with registration link.
- Unnamed vendor (mid-issue, labeled "Sponsored"): "The Data Platform Fundamentals Guide" eBook — covers ingestion/transformation design patterns, data modeling strategies, data quality tips. Download CTA only, no vendor entity named in body text.
Issue contents
Editor's Note — aidataengineer.io & leetdata.ai launches (SELF-PROMO)
Ananth announces two new DEW-adjacent platforms: leetdata.ai (career entry path for aspiring data engineers) and aidataengineer.io / AIDE (peer validation of daily design decisions for working practitioners). Framed as addressing two reader gaps identified from direct conversations. Both are DEW-owned properties.
Databricks: "From monolith to Lakebase to LTAP: rethinking the database from storage up" (THIRD-PARTY)
- Domain: databricks.com
- Takeaway: Databricks publishes the design rationale for LTAP — an OLTP-style system built on Postgres protocol with replication and page-server over network, bringing transactional guarantees into the Lakehouse layer. Framed as infrastructure for the agent era: agents need structured, unstructured, embedded, and multi-dimensional data unified under one storage model.
- Ananth's angle: The LTAP architecture is appealing for data engineering teams that historically managed separate OLTP and analytics stores.
Boaz Palgi (RegattaDB): "Databricks LTAP and the Unfinished Problem of Unified Data" (THIRD-PARTY)
- Domain: regatta.dev
- Takeaway: Critical read of the Databricks LTAP announcement. RegattaDB's CTO raises valid concerns about concurrent write guarantees and the copy-on-write model. Iceberg's well-known weakness at concurrent writes and fast-changing records applies directly here.
- Ananth's angle: The tension between LTAP's promise and its current COW/concurrency limitations is real — anyone who has operated Iceberg at scale knows this.
Addy Osmani: "Loop Engineering" (THIRD-PARTY — ALREADY VAULTED)
- Domain: addyosmani.com
- Takeaway: Reframes coding-agent leverage from prompts to durable system design: scheduled automations, isolated worktrees, SKILL.md context files, maker-checker sub-agent pairs writing to on-disk state. Each agent run starts cold; the loop is what survives.
- Ananth's angle: The loop engineering pattern maps directly onto data engineering workflows — DEW projects this becoming a standard pattern for data engineering functions as well.
- Vault cross-ref: Already vaulted in full at [[2026-07-04-addy-osmani-loop-engineering]].
Microsoft: "Introducing Durable Functions in PostgreSQL" (THIRD-PARTY)
- Domain: techcommunity.microsoft.com
- Takeaway:
pg_durableformalizes the "Postgres as job queue" pattern that many companies have been running informally. Attempts to streamline durable, stateful workflows directly inside PostgreSQL without external orchestration tooling. - Ananth's angle: Postgres-as-queue is a widely adopted anti-pattern; pg_durable tries to make it a first-class supported pattern.
Meta: "Meta's AI Storage Blueprint at Scale" (THIRD-PARTY)
- Domain: engineering.fb.com
- Takeaway: Meta rebuilt its AI training storage layer to eliminate GPU stall from slow metadata lookups and data proxy hops. Solution: unified metadata schema for fast lookups, direct-streaming client SDK replacing data proxies, tiered caching (regional flash + memory) for on-demand data hydration.
- Ananth's angle: The primary bottleneck limiting GPU utilization was a storage metadata/proxy architecture problem — a useful mental model for any team optimizing AI training infrastructure.
Affirm: "Re-architecting Affirm's Upfunnel Platform: How We Cut Experiment Cycle Time from Months to Days" (THIRD-PARTY)
- Domain: medium.com/affirmengineering
- Takeaway: Migrated a monolithic Python upfunnel messaging service to a standalone Kotlin microservice. Key moves: replaced a static database-driven rule model with a dynamic in-memory rule engine, and added a shadow-validation pipeline for safe rollout. Result: independent deployability and dramatically shorter experiment cycles.
- Ananth's angle: Standard monolith decomposition pattern, but the in-memory rule engine + shadow validation combo is a clean implementation of safe microservice extraction.
Stripe: "Scaling up your microservice testing with Apache Spark" (Parts 1 & 2) (THIRD-PARTY)
- Domain: stripe.dev
- Takeaway: Stripe isolated deterministic decision logic from its request path and wrapped it in a Spark harness that replays years of production traffic through both current and candidate implementations side-by-side. Production history becomes an executable regression asset; engineers can quantify rule changes before shipping, anchored to a decision-engine boundary shared across online and offline paths.
- Ananth's angle: The Spark replay harness as a regression testing primitive for high-risk microservice changes is a powerful pattern for fintech-scale decision engines.
Target: "Scaling Marketing Campaign Forecasting with Generative AI" (THIRD-PARTY)
- Domain: tech.target.com
- Takeaway: Target replaced rule-based campaign matching (which decays as campaign types diversify) with a RAG architecture: historical campaigns embedded into a grounding index, LLM filters and ranks top-3 against an explicit matching hierarchy. Coverage lifted from 75% at top-1 to 100% at top-3, eliminating manual search while grounding offer-propensity modeling in contextually relevant historical data.
- Ananth's angle: A concrete production RAG deployment for marketing forecasting — the explicit matching hierarchy as a constraint is what makes the LLM output reliable rather than freeform.
Expedia: "Using LLMs to Analyze Spark SQL Plans: A Practical Approach to Debugging Long-Running Jobs" (THIRD-PARTY — DEEP-FETCHED)
- Domain: medium.com/expedia-group-tech
- Takeaway: Expedia built a pipeline targeting the Spark History Server that selects the slowest SQL queries first, extracts physical and final query plans, and passes structured execution metadata (stage IDs, operator names, shuffle bytes, spill, skew ratios) to an LLM with output constrained to strict JSON. A validation step requires the model to cross-check each finding against actual metric values before reporting — preventing hallucinated diagnoses. The open-source MCP server is
kubeflow/mcp-apache-spark-history-server, with its primary toollist_slowest_sql_queries. - Results: Broadcast join optimization: ~1 hour to ~30 minutes. Missing partition filters: ~20 minutes to ~1 minute (20x). Oversized broadcast fix: same 20x. Skewed partition fixes: multi-hour jobs to expected baselines. Across the full test set: runtime -40 to 95%, compute cost -50 to 90%.
- Architectural insight: The physical plan supplies structural grounding (operator types, join strategies, table references) while stage/task metrics supply quantitative evidence (shuffle volume, spill, skew ratios). Both together let the LLM correlate a specific plan operator to an anomalous metric — precise root-cause identification rather than generic advice. Strict JSON output + evidence-validation instruction prevents unsupported findings from surfacing.
Mapping against Ray Data Co
Expedia's Spark+LLM pattern is directly applicable to phData client engagements. Data engineering clients routinely struggle with Spark job tuning — this is one of the highest-friction, highest-cost problems in production DE work. The kubeflow/mcp-apache-spark-history-server is open-source and already MCP-native, meaning it plugs into a Claude Code workflow with minimal integration work. For the Snowflake GenAI Specialty cert (target 2026-08-24), the pattern of structured metadata ingestion + constrained LLM output + evidence validation is exactly the kind of grounded AI application the cert assesses. Worth bookmarking the MCP server for a phData demo context.
Databricks LTAP continues the vocabulary thread from issue 276. The Vanlightly taxonomy debate (LTAP/LakeDB vs. OLTP/OLAP/HTAP) is now reinforced by Databricks actually shipping under the LTAP name. The RegattaDB critical take is a useful counterweight — in client advisory conversations, acknowledging the Iceberg COW/concurrency limitations is more credible than presenting LTAP as a solved problem.
Loop Engineering (Osmani) getting a DE-community signal boost. The fact that Ananth featured it in DEW and explicitly connected it to the data engineering function means this framing is now circulating in Ray's professional peer community. It's worth watching how fast "loop engineering" enters client conversations about AI-assisted DE workflows.
Target's RAG campaign forecasting is a reference architecture for AI-in-marketing DE work. If any phData client is in retail/CPG and asking about AI-augmented campaign analytics, this is a credible enterprise-scale reference with published coverage numbers (75% → 100% top-3).
Related
- [[2026-07-04-addy-osmani-loop-engineering]] — full treatment of Loop Engineering (DEW #277 featured piece already vaulted)
- [[2026-06-29-data-engineering-weekly-issue-276-agent-isolation-taxonomy]] — previous issue, covers LTAP taxonomy debate and Grab/Palana agent isolation pattern
- [[2026-07-02-dataengineeringweekly-de-practice-infrastructure-ai-fundamentals]] — DEW issue 2 weeks prior, AI fundamentals framing
- [[2026-07-05-alphasignal-agents-rewrite-harness]] — AI agents rewriting their own scaffolding; pairs with loop engineering framing