Data engineering for the numbers your business uses.

Grainset Data builds pipelines, analytical models and metric definitions. We connect source records to reporting tables and work through the calculations behind the figures.

Bring the sources together

Retain the records that explain the output.

Define the model

Give each row an explicit meaning.

Build the measure

Keep the calculation tied to its definition.

We build the data behind
your reporting.

A new source, an unreliable refresh or two reports that disagree can each be a starting point. We work on the part of the data environment that needs attention, with maintained code and examples that explain the output.

A working connection
from source to report.

Data engineering services for a new reporting environment or the models your team already maintains.

Source to reporting modelIllustrative structure
Source fields
Ordersorder_id · accepted_at · amount
Order linesorder_id · line_id · quantity
Shipmentsshipment_id · order_id
Analytical modelfct_accepted_orders

One row per accepted order

order_keyaccepted_dateorder_value
Use in reporting

Accepted order value

Sum the order value for the agreed acceptance period.

The same source may support several models. Each output needs its own row grain, keys and calculation.

Data pipelines

Build the connection between a source system and the reports that depend on it.

A database table, a recurring spreadsheet and an application API provide different accounts of the same business. One exposes a current state. Another delivers a replacement file. A third returns a sequence of changes. Those differences determine how a useful analytical load should work.

Explore pipelines
First and incremental loads
Resent files and late corrections
Incremental loadExample
Source updateRecord received
Load decisionInsert or replace?

A stable key lets a repeated delivery update the intended record.

Analytical models

Define the reporting tables, their relationships and the calculations they support.

An order, an order line and a shipment are related records, but they are not interchangeable units of analysis. A useful model starts by deciding which of those things each output row represents. That decision affects its key, the joins it can support and the measures it can safely carry.

Explore models
Row grain and relationships
Model changes and downstream use
A changing customer regionExample
Customer ARegion history
EastThrough April 30
WestFrom May 1

The April order is assigned to East.

In this example, each order uses the region recorded for its order date. A current-region report would answer a different question.

Metric definitions

Settle what a measure includes, then build and check the calculation.

One team may use sales to mean accepted orders. Another may mean shipped goods, and another may use issued invoices. All three can produce internally consistent numbers while describing different activity.

Explore definitions
Dates, units and inclusion rules
Record-level reconciliation
Definition in the modelExample
Accepted order value
Include

Orders accepted in the selected period.

Exclude

Cancelled orders and test records.

Reconcile

Trace model totals to the included source orders.

A definition identifies the records behind the number.

A correct source can still
produce the wrong total.

One order. Two shipments. Follow what happens when the order value is repeated across joined rows.

Read the model note
Order A$120one order
Shipment 1$120
Shipment 2$120
Order value$120

One order contributes its value once.

Illustrative records. Two shipments repeat the same order value; they do not create a second order.

Model notes

Worked examples and implementation choices, explained from the records up.

Before a data project.

Can the work focus on an existing report?

Yes. An assignment can start with one disputed calculation or a model that needs to change. We identify the source fields, intended definition and consumers included in the scope.

What is useful for a first conversation?

Describe the source systems, the report or dataset you need and where the current process causes difficulty. Arrange a suitable channel before sharing source records or credentials.

Do we need to replace our data stack?

That depends on the task and the tools already in use. A focused model change or pipeline repair may fit within the existing environment. We scope those constraints before recommending a build.

Start with the data
you have.

A new pipeline, a model change or a reporting discrepancy. Tell us where the work begins.

Discuss your project