BigQuery in the Right Lane: Five Checkpoints for AI Data Pipelines
A five-checkpoint workflow for keeping BigQuery in the right lane: land and shape data once, tune partitions and history windows, and federate instead of copying.
Loading…
Topic
8 posts about Data Warehousing. Every summary links to the original.
See the idea
A five-checkpoint workflow for keeping BigQuery in the right lane: land and shape data once, tune partitions and history windows, and federate instead of copying.
Apache Iceberg replaces Hive's partition-based metadata with a versioned catalog layer, trading operational simplicity for ACID guarantees, schema evolution, and cross-engine compatibility.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
OLTP handles high-volume, low-latency transactions on current operational data for online banking, e-commerce, and inventory, while OLAP handles complex analytical queries on large historical datasets for financial analysis and business intelligence. OLTP databases ensure data integrity through ACID compliance and use normalized row-oriented tables; OLAP systems use denormalized dimensional models and columnar storage for efficient scans and aggregations. Data pipelines such as ETL or CDC tools like Debezium connect OLTP and OLAP systems, but latency and pipeline complexity rise with analytical freshness requirements. For mixed workloads, HTAP or lakehouse architectures can reduce synchronization overhead and analytical lag. The choice between OLTP and OLAP depends on the workload’s read-write pattern, latency needs, and data volume, with TPC-C and TPC-H as reference benchmarks.
Data warehouses have been the standard for structured SQL analytics for two decades but cannot serve modern AI, ML, streaming, and unstructured data workloads. The data lakehouse now matches warehouse SQL performance while serving all these workloads from a single governed foundation. Databricks Lakehouse improved production SQL workload performance by 77% from a 2022 baseline, with BI queries improving 14% over a recent five-month period. Customer migrations show 90% faster queries and 30–40% cost reduction at Lumen Technologies, and 80–90% faster analytics at Trek Bicycle. The lakehouse eliminates redundant data copies, supports open formats like Delta Lake and Iceberg, and extends governance to AI agents through Unity Catalog and Unity Gateway.
The data warehouse served structured SQL workloads for two decades, but the lakehouse now supports BI, data engineering, ML, streaming, and AI agents from a single governed platform. Databricks reports a 77% improvement in its production SQL workload mix since 2022, with customer migrations showing 90% faster queries (Lumen) and 80-90% faster analytics (Trek Bicycle). Lakehouse//RT delivers sub-second analytical queries at high concurrency directly on governed lakehouse tables, with Databricks reporting sub-100-ms latency at 12,000 queries per second, collapsing the traditional architecture of separate serving databases. The lakehouse eliminates data copying between systems, handles unstructured data, and runs on open formats like Delta Lake and Apache Iceberg, governed by Unity Catalog. Customer cost reductions range from 25% to 75%, with AXA Japan reducing warehouse costs by 60% and ETL costs by 70%, driven by eliminating redundant systems and data copies.
Analytic applications are packaged business intelligence systems designed to measure, analyze and improve performance for defined business domains. They combine data integration, modeling, visualization, reporting and workflow support so technical and non-technical users can turn operational data into decisions. Typically, they connect ERP, CRM and supply chain systems with a data warehouse or lakehouse, process historical and real-time data, and deliver dashboards, reports, scorecards or embedded insights through preconfigured schemas, connectors, governance controls and business logic. Unlike general-purpose BI tools built for open-ended exploration, they support standardized, domain-specific workflows such as sales performance management, financial planning, risk assessment and inventory optimization. Organizations can start with descriptive analytics and adopt predictive or prescriptive capabilities as data maturity increases, while choosing standalone or embedded deployment based on workflow needs and data readiness.
The post presents data-agent-mnist, an open harness for measuring analytical agents on correctness, cost, and speed against a warehouse-shaped workload rather than a single text-to-SQL query. The authors extracted 201 production analytics questions from DWAINE, curated and anonymized them, reconstructed a deterministic synthetic warehouse with 18 tables and 865 columns, and evaluated 28 proprietary and open-weight models. The benchmark preserves schema discovery, multi-turn querying, planning, and multi-hop joins across curated marts and a dimensional CRM layer, with provider-diverse ground truth and judging described as part of the workflow. On the authors’ warehouse, Claude Fable 5.1 ranked first for correctness at 76.6%, while the full run cost $1 with DeepSeek V4 Flash versus $52 with Fable 5.1, an 11-percentage-point correctness difference. The harness is intended to identify the best production fit for a specific warehouse, not a universal winner.
The guide presents data warehouse design as a business-aligned process for building, modernizing, or scaling analytics infrastructure, rather than merely storing data. It recommends defining analytics use cases and stakeholder needs first, then organizing a three-tier architecture of source, storage, and semantic output layers; cloud designs can decouple compute and storage and use open formats. A Bronze–Silver–Gold medallion flow preserves raw lineage, applies cleansing and deduplication, and produces consumption-ready dimensional models, while retention and archival policies control sprawl. For modeling, it favors star schemas for user-facing BI, uses snowflake normalization when redundancy is material, and stresses explicit fact-table granularity, domain-owned data marts, and workload-specific refresh cadences. Governance and operations include Unity Catalog, access controls, masking, lineage, multi-region deployment, disaster recovery, and CI/CD, followed by phased rollout through high-value domains.
BI dashboards can become slow and expensive when teams respond to latency with separate aggregate tables, refresh pipelines, extracts, and tool-specific semantic layers. The post presents Databricks’ BI serving stack from physical storage through Unity Catalog’s governed semantic layer, recommending Gold-layer star schemas, managed tables, liquid clustering, and Predictive Optimization to reduce scanned data and improve query plans. Metric Views centralize KPI definitions and semantic metadata for dashboards, Genie, SQL notebooks, third-party BI tools, and AI agents, while materialization automatically maintains incremental pre-aggregations and routes queries transparently. Additional TCO guidance covers serverless SQL warehouse autoscaling, DBSQL disk and query-result caching, direct lakehouse connections, and system-table monitoring. The stated outcome is compounded lower latency and compute cost, including an observed average 22% performance improvement from Predictive Optimization and sub-second performance from materialized metrics.
Data warehouse tools are presented as a strategic choice for analytics and ML teams facing fragmented estates of warehouses, lakes, and standalone ML systems. The guide proposes evaluating platforms across query performance, scalability, data integration, BI connectivity, total cost of ownership, and governance and security, with attention to MPP, columnar storage, and decoupled compute and storage. It contrasts traditional warehouses, data lakes, and lakehouses: warehouses favor structured SQL analytics, lakes offer native-format flexibility but weaker quality and performance guarantees, and lakehouses combine these capabilities using open formats such as Delta Lake and Apache Iceberg. The stated conclusion is that a lakehouse can provide a single governed foundation for SQL, BI, streaming, ML, and AI workloads, while teams should select tools according to workload, scale, budget, and future AI needs.
The best engineering reads, once a week.