Serving Data for Analytics, ML, and Reverse ETL

In one sentence

You think the pipeline ends when data lands in the warehouse; it actually ends when someone makes a decision or takes an action based on it. This chapter builds three ideas: the first principle of serving is trust, and one mistake is hard to undo; before serving, ask who uses it and for what, because analytics, machine learning and reverse ETL want completely different things; and definitions should live in exactly one place — while writing data back into business systems sends any error straight into business actions, so it needs guardrails.

Glossary

Where it sits

The last chapter of Part II, "The Data Engineering Lifecycle in Depth". It follows Chapter 8 (queries, modeling and transformation — the data is now shaped) and leads into Part III on security and privacy. It covers the lifecycle's final stage, serving — where, in the authors' framing, data engineers get to shine and the value of the work is truly tested. In practice: BI reporting, external data products, feature delivery and reverse ETL syncs.

What problem this chapter solves

Picture a company selling SaaS to merchants: a few hundred modeled tables in the warehouse; leadership reads a daily business report at 8 a.m.; twenty-odd analysts query ad hoc; the product embeds a "My Sales" dashboard for 20,000 merchants, with a thousand or more refreshing at peak; a fraud model trains on three years of orders; and sales wants each lead's win probability right inside the CRM. Typical consequences of ignoring this chapter:

• Trust collapses. The daily report arrives two hours late, or disagrees with finance once, and leadership goes back to Excel; the platform becomes decoration.
• One warehouse carries every workload. A warehouse tuned for batch reports serves a customer-facing dashboard with a thousand concurrent users, and latency goes from milliseconds to over ten seconds.
• Definitions split. "Active merchant" is computed separately in BI, notebooks and the external dashboard — three numbers, three answers.
• Models degrade in production. Training data used fields only known after the fact; offline metrics look great and the model fails once deployed.

The core ideas, explained

1. General principles: trust, users, data products

Trust comes first. The authors' judgment: trust in data takes a long time to build and only one incident to lose. Two tools protect it: data validation and observability, so you catch problems before users do; and an agreed SLA with consumers — for example, "the daily report is ready by 8 a.m. and key metrics reconcile exactly with finance" — measured continuously with SLOs. When data is late or wrong, tell people proactively instead of waiting to be asked.

Ask about the use case and the user first. The good question isn't "what data do you want?" but "what action will you take once you have it?" The same order data becomes a trend chart for the CEO, sliceable detail for an analyst, and labeled historical examples for a model.

Data products. The authors borrow the "jobs to be done" lens — users hire a product to get a job done. Treat the datasets you serve as products, with clear users, a problem to solve and a feedback channel, rather than one-off data pulls.

Self-service is not the default answer. Letting everyone drag and drop their own reports sounds great, but the book warns that self-service often fails in practice: executives want conclusions, not to build charts themselves. The people who truly need self-service are analytical users who ask new questions, and they need bounded freedom — clean models, clear definitions, appropriate permissions.

Data definitions and data logic. A data definition is what a word means (what counts as a "customer"); data logic is the formula (does GMV include refunds, is it counted at order time or payment time). This knowledge often lives only in veterans' heads; the authors argue for writing it down explicitly and maintaining it in one place. Data mesh pushes serving outward: each business domain treats its data as a product and serves other domains directly.

2. Analytics: business, operational, embedded

Business analytics uses historical and current data to support decisions, in three forms: dashboards (a few KPIs at a glance), reports (fixed format, sent regularly) and ad hoc analysis (an analyst digging into one question; useful findings graduate into reports).

Operational analytics is about right now, in real time or near real time: application monitoring, inventory alerts, a sudden drop in conversion. It asks "what is happening and what should we do immediately", with data latency measured in seconds.

Embedded analytics is customer-facing analytics built into a product: the energy chart in a smart thermostat app, the sales dashboard in a merchant back office. The authors point out how much it raises the bar: data must be fresh, queries fast (users won't wait ten seconds), concurrency high (thousands of customers at once), and each customer may see only their own data — multitenant isolation down to the row. This load usually goes to dedicated real-time OLAP engines (such as Druid, Pinot or ClickHouse) rather than a batch warehouse.

3. Machine learning: how much a data engineer should know

The authors admit the line between data engineering and ML engineering varies by organization: some data engineers only deliver clean raw data, others own everything up to computing and serving features. Wherever the line falls, data engineers should know ML basics: supervised vs unsupervised learning, classification vs regression, when to use classical models vs deep learning, feature engineering, batch training vs online learning, and where labeled data comes from. Knowing these tells you what kind of data to deliver.

The easiest place to go wrong is point-in-time correctness: each feature in a training example may only use values known at the moment of prediction. If you predict whether an order will be refunded but train on a field that only exists in the order's final state, the model is peeking at the answer — great offline, useless in production. Another trap is training–serving skew: a batch job computes features for training while different code computes them live, and small differences between the two degrade the model. Feature stores exist to serve one feature definition to both offline training and online inference.

4. Seven ways to serve data

File exchange: export CSV or Excel, or drop files into a shared object-storage bucket for a partner. The most primitive and still the most common, but versions, permissions and freshness are hard to manage. Databases: the usual way — users query the warehouse or an OLAP store directly; cloud warehouses can give each team isolated compute so one person's huge query doesn't slow everyone. Streaming systems: continuously updated results for operational analytics. Query federation: an engine like Trino queries many sources at once without moving data first — good for exploration and one-off needs, but it pushes load onto the sources. Data sharing: cloud warehouses grant direct access to the same data, no copies and no pipelines; Snowflake, BigQuery and others support it. Semantic and metrics layers: see the next section. Notebooks: the main entry point for data scientists; the authors note that pandas loads everything into one machine's memory, so larger data needs Spark, Dask, Ray or a managed cloud environment — and database credentials should never sit in plain text in a notebook.

5. The semantic layer: define each metric once

A semantic layer / metrics layer centralizes business metric definitions as code — for example, "GMV = sum of paid order amounts, minus refunds in the month" — and compiles them into SQL for each database. Every downstream consumer — BI, notebooks, external dashboards — gets numbers through it instead of writing its own version. The authors cite Looker's LookML and dbt's metric definitions. The gain is "write once, consistent everywhere"; the cost is one more abstraction to maintain and learn.

6. Reverse ETL: sending results back to business systems

Reverse ETL writes results computed in the warehouse back into business systems: lead scores into Salesforce, user segments into the marketing platform, risk flags into the support tool. The authors aren't fond of the name but endorse the value: salespeople won't open a BI tool to look up a score, so the data has to go where they already work. Dedicated tools such as Hightouch and Census exist, or you can build your own.

The most memorable point in the book is the risk: the feedback loop. The authors' example is ad bidding — a model computes bids from warehouse data, reverse ETL writes them into the ad platform, the new campaign results flow back into the warehouse, and they drive the next round of bids. If the logic is wrong, the loop amplifies itself: bids climb and ad spend burns away before anyone notices. The remedy is caps, monitoring and human review.

7. Who you work with, and the undercurrents

Serving puts you face to face with data analysts, data scientists, ML engineers and the business. Among the undercurrents the authors single out security (least privilege, row- and column-level visibility, views or masked data when sharing externally), DataOps (monitoring whether data arrives on time, whether quality is off, whether queries are slowing) and orchestration (serving depends on every upstream step finishing in order). Serving is where users notice failures first, so monitoring has to reach this layer.

Key trade-offs and choices

Table 1 · Seven ways to serve data (plus reverse ETL)

Table 2 · What the three kinds of analytics demand

Self-service is a trade-off too: open it to analytical users who ask new questions, backed by clean models and a semantic layer; give people who only want conclusions good fixed dashboards. With ML teams, agree up front which layer data engineering delivers — raw data, cleaned tables or ready features — or the feature logic ends up written twice.

Why it matters / real systems

A strong answer to the interview question "build a real-time sales dashboard for merchants" lands like this: model order facts in the warehouse and define metrics once in a semantic layer; serve the external dashboard from a real-time OLAP engine ingesting from Kafka, with row-level isolation per merchant and a sub-second p99 target; keep the internal daily report on the cloud warehouse with a monitored ready-by-8-a.m. SLA; build fraud training sets with point-in-time correctness; push win probabilities into the CRM through reverse ETL, with caps on how much values may change and alerts on the sync. Every step maps to a concept in this chapter.

Pitfalls and debates

• "Once it's in the warehouse, it's delivered." Data nobody uses or trusts might as well not exist; serving is the acceptance test.
• "Self-service BI will make data requests disappear." Most people want conclusions; self-service suits a minority of analytical users, and needs boundaries.
• "One warehouse can carry every workload." Batch reports and a customer dashboard with a thousand concurrent users are different loads; mixed together, they drag each other down.
• "More complete training data is always better." Using fields not yet known at prediction time is peeking at the answer: the better it looks offline, the worse it does live.
• "Federation avoids moving data, so it's free." The load shifts to the source systems, and production databases can slow under analytical queries.
• "Reverse ETL is just another sync job." It turns analysis into business actions; its errors are the most expensive, so it needs guardrails and alerts.
• Dated by its time. The book came out in 2022, when semantic layers and reverse ETL were emerging categories; some of it has since been absorbed by warehouse and BI vendors, but "ask about the use, protect trust, define once" still holds.

Key takeaways