Key concepts of analytics engineering

What changes when an analysis becomes a model

An analysis can answer a question once. An analytics model needs to answer the same question again, for other people, after the source data changes. That means the model needs an explicit row shape, keys, checks, and a clear owner.

For example, a spreadsheet that sums orders may answer "what was revenue last month?" A customer_daily_revenue model can answer that question every day if its grain, update rule, and checks are clear.

Glossary

• Analytics engineering is the work of turning source data into maintained datasets for reporting, analysis, and downstream applications. It includes SQL or Python, testing, documentation, and the way changes are reviewed and run.
• Model is a named dataset produced by a query or program. A good model represents one business concept, such as orders, customers, subscriptions, or daily revenue.
• Grain is what one row represents. "One row per order" and "one row per customer per day" are different grains, even if both contain a customer ID and a date.
• Primary key is the column or combination of columns that should identify one row at the model's grain. If two rows share the same primary key, either the input or the model logic needs attention.
• Source is the system or raw dataset that supplies the data. A source table may reflect operational needs, so it often needs cleaning before it is ready for analysis.
• Staging model is a model close to the source that standardizes names, types, timestamps, and basic filters. It gives later models a predictable input instead of making every report clean the source again.
• Analytics model or mart is a model designed for a business use case. It normally joins or aggregates staging models into a dataset such as fct_orders or customer_daily_revenue.
• Materialization is the rule that determines how a model's result is stored or updated. Examples include replacing a table, appending new rows, merging changes, or refreshing a time interval.
• Quality check tests an assumption about the data. A check can catch null keys, duplicate rows, an unexpected value, or data that has not arrived on time.
• Lineage is the path from a model back through its inputs to the source. It helps you find the likely cause when a metric changes or a check fails.
• Environment separates development from shared or production work. It lets you test the same project with different connections, schemas, or variables.

Work through one small model

Assume the question is: "How much revenue did each customer generate each day?"

• The grain is one row per customer per calendar day.
• The primary key is customer_id plus order_date.
• The source may be raw order records, where one order can have several line items.
• A staging model can make the order timestamp and amount consistent.
• The analytics model groups the staging rows by customer and date.
• A duplicate-key check tells you whether the model still has one row at the intended grain.

The point is not to memorise names. It is to make each decision visible before the SQL becomes complicated.

Questions to answer before writing SQL

• What business question should this model answer repeatedly?
• What does one row mean?
• Which columns make a row unique?
• Which source models does it depend on?
• How can source records change after the first load?
• Which check would catch the most expensive mistake?

Official links

• Bruin asset overview
• Bruin materialization reference
• Bruin lineage concepts