The GPU-Resident Astronomy Pipeline
A GPU-resident astronomy pipeline keeps every stage of image analysis — load, align, subtract, detect, review — inside GPU memory instead of round-tripping through the CPU.
Loading…
Topic
Data Pipelines
247 posts about Data Pipelines. Every summary links to the original.
- 247 posts
- 25 companies
- 9 explainers
See the idea
Data Pipelines explainers
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.
How to Make Apache Hudi Copy-On-Write Upserts Less Wasteful
Learn how Apache Hudi copy-on-write upserts can use row-level file and page locations to update changed data while avoiding unnecessary decompression and rewriting.
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
Posts
Rill and ClickHouse: real-time operational BI for a metered world
Granular operations across cloud computing, payment platforms, and artificial intelligence workloads produce high-volume event streams that traditional business intelligence tools struggle to unify and aggregate. Operational BI platform Rill addresses this challenge by combining declarative data loading through the dlt framework with ClickHouse's high-performance analytical aggregation engine. Data transformations, SQL-based measure expressions, and dashboard configurations are defined entirely as code using SQL and YAML. This declarative, metrics-first architecture allows developers to validate analytics locally, track changes in Git, and eliminate intermediate caching layers when querying live data. By querying ClickHouse directly and linking AI-generated insights back to underlying queries, the system provides traceable, real-time operational analytics for enterprise environments.
How Padlet uses ClickHouse Cloud to power real-time classroom analytics
Padlet needed a real-time analytics system to provide teachers with immediate insights into student engagement across 40 million monthly unique users. To avoid the operational overhead of managing database clusters with a small engineering team, the company adopted ClickHouse Cloud and ClickPipes for managed data ingestion. Active user sessions emit 30-second heartbeat events that stream alongside page views into ClickHouse. Materialized views pre-aggregate engagement duration and view counts by date, while native HyperLogLog sketches process unique visitor calculations efficiently across arbitrary time ranges. In production, this architecture ingested roughly eight billion events in a single month and delivered analytical query results with a 45-millisecond median latency.
Building Biz Ask Anything: From Prototype to Product
Yelp expanded Yelp Assistant to business pages by developing a question-answering architecture that extracts concise, evidence-backed answers from reviews, photos, and structured facts. The production system replaces static snapshots with near-real-time streaming pipelines for reviews and structured properties alongside weekly batch ingestion for menus and website data. For each incoming query, the system evaluates intent, retrieves relevant context through keyword and embedding searches, and constructs targeted prompts with dynamically selected few-shot examples. Synthesized answers are augmented with supporting visuals and citations before being streamed token-by-token to users. Generating suggested questions directly from specific business content rather than generic categories improved user engagement by roughly fifty percent and reduced unanswerable queries by twenty-six percent.
ClickHouse is data lake ready
ClickHouse announced expanded data lake capabilities, enabling direct querying, accelerated ingestion into MergeTree, and writes across Apache Iceberg and Delta Lake tables. Open lake architectures provide storage portability across cloud providers and catalogs, but standard query engines often struggle with latency for real-time workloads. Over two years of development, ClickHouse engineered a native Parquet reader with page-level parallelism, integrated the Delta Rust Kernel, and introduced support for schema evolution, time travel, and DML operations. The platform functions across AWS Glue, Unity Catalog, Polaris, and Iceberg REST Catalog on storage systems including Amazon S3, Google Cloud Storage, and Azure Blob Storage. These enhancements allow organizations to execute federated, high-concurrency SQL queries across multiple catalogs or write processed analytical results back to their lakes without vendor lock-in.
Intelligent security at ClickHouse speed: How Cogent Security built an AI-native vulnerability management platform
Enterprise security defenders face shrinking exploitation windows alongside massive volumes of vulnerability findings across disconnected tools. To overcome query bottlenecks from traditional relational databases, Cogent Security designed a lakehouse serving architecture using Apache Iceberg and per-customer ClickHouse instances. The architecture relies on query-driven denormalized tables, custom compression codecs, and pre-computed projections to serve hundreds of millions of rows with sub-second latency. On top of this data layer, Cogent implemented an agentic text-to-SQL system that iteratively queries live data, references an in-house Ontology Service for semantic context, and applies majority-voted evaluations. This combination improved text-to-SQL accuracy from 40% to 94% while providing sub-three-second response times across 98.7% of queries at 100 million rows.
Querying DateTimes in ClickHouse
ClickHouse provides specialized functions to filter, bucket, and compute durations on native DateTime columns without requiring external processing tools. Using the New York City taxi dataset imported into a MergeTree table, queries bucket pickup timestamps into hour and 15-minute intervals using toStartOfHour and toStartOfFifteenMinutes while casting values to the Time type to group across dates. The dateDiff function calculates journey durations in minutes, which enables trip speed calculations across time windows and powers inline ASCII visualizations generated by the bar function. By combining toDayOfWeek with conditional aggregations like countIf and the lag window function, queries uncover distinct morning surge trajectories between weekdays and weekends. The analysis demonstrates that weekday trip volumes peak around 8:45 AM alongside dropping speeds, whereas weekend volumes increase steadily across the morning.
Unordered mode for GCS ClickPipes is now available
ClickHouse Cloud has added unordered mode to its Google Cloud Storage (GCS) ClickPipes connector, enabling continuous data ingestion regardless of file naming or arrival sequence. Standard GCS ClickPipes rely on polling every 30 seconds and require files to arrive in strict lexicographical order, which causes out-of-order data and backfills to be ignored. Unordered mode replaces polling by consuming OBJECT_FINALIZE notifications from Google Cloud Pub/Sub whenever objects land in a bucket. State tracking is managed through a metadata store, and the connector automatically reprocesses batches upon failure while maintaining exactly-once insertion guarantees. Setup requires configuring a Pub/Sub topic and bucket notifications via tools like gcloud, followed by configuring the ClickPipe via the console or Terraform provider.
5 ways to parse Dates and DateTimes in ClickHouse
ClickHouse provides several ways to convert dates and datetimes from Unix timestamps, packed numeric values, known-format strings, mixed inputs, and file data. The examples use fromUnixTimestamp and its millisecond and microsecond variants, YYYYMMDDToDate and YYYYMMDDhhmmssToDateTime, plus parseDateTime or parseDateTimeInJodaSyntax when the input format is known. For unknown or mixed formats, parseDateTimeBestEffort and its DateTime64 counterpart accept inputs such as ISO 8601 strings, dates, and timestamp strings; invalid values otherwise raise an exception, while OrNull returns NULL and OrZero returns January 1, 1970 at midnight. The post also shows direct ::DateTime casting, controlled by cast_string_to_date_time_mode: basic supports standard forms, whereas best_effort broadens parsing but still throws for completely invalid dates. An inline or session setting lets the same casting approach parse rows from a CSV file.
Announcing chDB 4: write Pandas, run ClickHouse, now on Hex
chDB 4 introduces Data Store, a native component that allows users to write Pandas-like code that executes on the ClickHouse OLAP SQL engine. Standard Pandas workflows suffer from eager execution, excessive memory materialization, and lack of automatic query optimizations. To solve this, Data Store implements a four-layer architecture that lazily records operations as a chain of LazyOp objects and compiles them into optimized ClickHouse SQL plans upon evaluation triggers. When encountering operations unsupported by ClickHouse, the QueryPlanner splits the pipeline into segments, routing tasks between ClickHouse and Pandas while using Python's memoryview to minimize data copying overhead. This release also integrates natively into Hex notebooks.
Introducing Storage Buckets on the Hugging Face Hub
Hugging Face introduces Storage Buckets as a mutable, S3-like object storage layer on the Hub for intermediate machine-learning artifacts such as checkpoints, optimizer states, processed shards, logs, and traces. Unlike versioned Models and Datasets repositories, Buckets support frequent writes, overwrites, directory synchronization, and cleanup while retaining standard Hub permissions and public or private visibility. Built on Xet, they chunk and deduplicate content across files, reducing repeated bytes, bandwidth, transfer time, and, for Enterprise customers, billed storage. The CLI and Python APIs support creation, syncing, dry runs, plans, inspection, individual file operations, and programmatic workflows; HfFileSystem and fsspec also allow compatible libraries to read and write through hf:// paths. Pre-warming can place hot data near AWS or GCP compute, while roadmap work aims to connect Buckets directly with versioned repos.
How Critical Manufacturing uses ClickHouse to bring real-time intelligence to the factory floor
Critical Manufacturing faced performance and scaling bottlenecks while processing millions of factory floor events using a legacy Microsoft SQL Server analytics stack. Increasing data volumes caused historical queries to take hours, straining real-time dashboards and escalating operational maintenance. The engineering team replaced this architecture by migrating analytics workloads to ClickHouse connected directly to streaming Kafka topics. They implemented an ELT pattern alongside ReplacingMergeTree engines to deduplicate late-arriving sensor records and utilized TTL policies for automated lifecycle management. The resulting platform delivers sub-second analytical queries across historical and real-time operational data, expands into OpenTelemetry observability storage, and maintains embeddings for retrieval-augmented generation workloads.
What Replo learned optimizing 100+ billion events in ClickHouse
Replo built an analytics pipeline on ClickHouse to serve more than 4,000 Shopify merchants processing 3,000 to 5,000 events per second. The initial single-table architecture recalculated session metrics on the fly, leading to poor query efficiency as volume scaled. To speed up dashboard queries, the team implemented a mark-and-unmark pattern with SummingMergeTree and refreshable materialized views, but real-time deduplication and fractional attribution caused runaway query backlog loops. Replo resolved the issue by limiting real-time recomputations to a specialized table holding only the last 40 minutes of purchase-related events. This architecture allowed processing over 100 billion records while keeping query times fast and ingestion lag to approximately one minute.
Trusting the Untestable: Validation and Diagnostics for the Doubly Robust Models
When randomized A/B tests are infeasible for evaluating partnerships or long-term effects, Lyft applies Augmented Inverse Propensity Weighting (AIPW) doubly robust models to estimate treatment effects from observational data. The quasi-experimentation platform mandates rigorous confounder selection prior to treatment exposure and adjusts for downsampling bias via propensity score conversions and outcome reweighting. When comparing AIPW against experimental ground truths, initial estimates understated effects because trimming extreme propensity scores removed key users and unobserved confounders persisted. To evaluate model health and external validity, the platform incorporates diagnostic scorecards featuring common support checks, Marginal Sensitivity Models, and covariate comparisons between trimmed and untrimmed cohorts.
Introducing SyGra Studio
SyGra 2.0.0 introduces Studio, an interactive environment for building, previewing, executing, and debugging synthetic data generation flows on a visual canvas. Users can configure connectors and models, preview source rows, reference automatically created state variables in prompts, define structured outputs, and inspect the generated YAML or JSON graph configuration. Studio streams node-level execution status, token usage, latency, cost, logs, and guardrail outcomes, while storing run history in .executions/runs/*.json and autosaving drafts. It also runs existing workflows, including a Glaive Code Assistant example with conditional revision loops, tunable dataset and batching inputs, and observable intermediate critiques; generated outputs can support training, evaluation, or annotation workflows.
Lyft’s Feature Store: Architecture, Optimization, and Evolution
Lyft built a centralized Feature Store to optimize feature management, deployment, and data consistency for machine learning workflows across its rideshare platform. The system ingests batch features defined by Spark SQL and JSON metadata into Airflow DAGs, which simultaneously write data to Hive for model training and to an online serving layer for low-latency inference. Real-time streaming features are processed with Apache Flink and Apache Kafka before being ingested into the serving infrastructure. The online layer, dsfeatures, couples DynamoDB with a ValKey write-through LRU cache and OpenSearch to serve embeddings. Infrastructure optimizations reduced standard P95 read latency by a third while supporting over a trillion additional read and write operations.
Treating Data as Code at Two Sigma
Scaling research and trading platforms across thousands of data sources created bottlenecks at Two Sigma, where reliance on database snapshots and fragmented infrastructure slowed dataset delivery to data scientists. To address operational costs and architectural complexity, the data engineering team adopted software development principles by treating data as code. The organization migrated to Google BigQuery's serverless architecture, standardized SQL transformations using dbt, and defined declarative pipelines with Terraform under continuous integration workflows. Internal tooling was introduced to track directed acyclic graph dependencies, automate anomaly detection, and streamline data discovery. These shifts eliminated manual data movement routines, reduced operational overhead, and enabled formal data contracts to safeguard downstream consumers and emerging language model integrations.
Aligning to What? Rethinking Agent Generalization in MiniMax M2
MiniMax M2 addresses the performance gap between agent benchmark scores and real-world deployment across diverse scaffolding frameworks and environments. While initial alignment efforts relied on scaling tool variety, models continued to fail when subjected to slight variations in prompts, scaffolding, and tool responses. To resolve this instability, the team introduced interleaved thinking, which enables models to execute internal reasoning at arbitrary steps throughout long-horizon tasks to adapt dynamically to external tool outputs. Additionally, developers constructed a data pipeline designed for full-trajectory generalization by introducing perturbations across system prompts, user objectives, environments, and tool feedback. In internal evaluations, MiniMax M2 maintained robust tool-calling and instruction-following performance when tested against unfamiliar, cold-start agent scaffolding frameworks.
Streaming datasets: 100x More Efficient
Training machine learning models on multi-terabyte datasets often requires long download times or suffers from network request storms when multiple DataLoader workers initialize independently. Hugging Face revamped the backend of its datasets library to make dataset streaming viable for large-scale distributed training without modifying the standard API. Startup latency was reduced by caching resolved data file lists across workers and bundling API calls, cutting initial request volume up to one hundred times. The team also implemented background prefetching for Parquet files and added configurable buffering parameters to keep GPUs fully saturated during training runs. Benchmark tests demonstrated up to twice the sample processing throughput and zero worker crashes across 256 concurrent workers on 64 H100 GPUs.
LeRobot v0.4.0: Supercharging OSS Robot Learning
LeRobot v0.4.0 expands the open-source robot-learning stack with scalable datasets, simulation benchmarks, processing tools, policies, and hardware integrations. LeRobotDataset v3.0 introduces chunked episodes, video streaming, unified Parquet metadata, improved loading and memory efficiency, plus utilities for editing and converting datasets. A modular Processor system separates policy and robot pipelines, while direct Accelerate integration simplifies multi-GPU training; the release also adds LIBERO, Meta-World, PI0, PI0.5, and GR00T N1.5 support. A plugin architecture enables third-party robots, cameras, and teleoperators to be installed without changing the core library, with Reachy 2 and phone teleoperation included, alongside a self-paced Robot Learning Course and hands-on tutorial.
Platform Thinking: Three Views from Two Sigma Leaders
Two Sigma structures its quantitative investment operations around foundational platforms that balance operational speed with scientific rigor. In data engineering, foundational teams provide both raw and curated datasets using BigQuery, CI/CD-managed transformation pipelines, and reusable data contracts termed ice cubes to serve ninety percent of use cases. Quantitative modeling incorporates open-source large language models trained strictly on point-in-time data to rapidly generate features while preventing temporal leakage. Long-term platform innovation follows an epsilon and omega strategy that couples overarching vision with iterative, learning-focused steps. Platform leadership categorizes artificial intelligence applications into advisory, oracle, operational, and agentic functions designed to enhance human productivity rather than replace researchers.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.