Jasper Alblas
Jasper Alblas
Data Engineering • Analytics • Business Intelligence
How Data Moves From Source Systems to Business Insights
In the previous article, we explored how data is stored and organized.
You learned about:
You now understand where data lives.
But a modern data platform needs more than storage.
Data is constantly being created, changed, and moved.
A customer places an order.
A sensor sends a measurement.
An application creates a log.
A user clicks a button.
A company receives information from an external API.
All of this data needs to travel from the systems where it is created into systems where it can be analyzed.
That is where data pipelines come in.
A data pipeline is a process that moves data from one location to another and prepares it for use.
A simple example:
Source System
↓
Extract Data
↓
Transform Data
↓
Store Data
↓
Analytics
A pipeline is the connection between the different parts of a data ecosystem.
Without pipelines, data would remain isolated in individual systems.
A sales application might know what customers bought.
A marketing platform might know what emails were opened.
A website might know what pages visitors viewed.
A data pipeline brings these pieces together so the company can understand the complete picture.
Imagine an online store.
A customer buys a product.
Several things happen:
The order is stored in the company’s operational database.
Example:
OrderID: 50001
CustomerID: 1001
ProductID: 501
Amount: 499
At this point, the data is useful for running the website.
But it is not yet ready for analytics.
A pipeline collects the new order data.
It might extract data from:
The raw data might need cleaning.
Examples:
The cleaned data is stored in an analytical system.
For example:
Now analysts can answer questions:
The pipeline made this possible.
A typical modern data pipeline looks like this:
Data Sources
↓
Ingestion
↓
Raw Storage
↓
Transformation
↓
Data Modeling
↓
Data Quality
↓
Serving Layer
↓
Consumption
Let’s explore each step.
Every pipeline starts somewhere.
These are called data sources.
Examples:
A company database might contain:
Example:
SQL Server
PostgreSQL
MySQL
Oracle
Many systems provide data through APIs.
Examples:
The QuakeFlow project will use this approach.
The earthquake data source will be an API providing information about earthquake events.
Companies still exchange enormous amounts of data through files.
Examples:
Modern applications generate huge amounts of data.
Examples:
Data ingestion is the process of collecting data from sources and bringing it into your data platform.
Think of ingestion as the “entry point” of the pipeline.
Example:
USGS API
↓
Python Script
↓
Raw JSON Files
The goal is usually not to transform everything immediately.
A common modern approach is:
First capture the data. Then process it.
This gives you the ability to:
The most common type of ingestion is batch processing.
Batch means data is collected at intervals.
Examples:
Every night:
00:00
Extract yesterday's sales
Every hour:
10:00
Load new customer data
Every 15 minutes:
10:15
Refresh marketing data
Batch processing works well when data does not need to be available instantly.
Streaming means data is processed continuously as it arrives.
Examples:
Instead of:
Collect data
↓
Process data
Streaming works like:
New Event
↓
Process Immediately
Streaming systems often use technologies like:
| Batch | Streaming | |
|---|---|---|
| Timing | Scheduled | Continuous |
| Example | Daily sales report | Fraud detection |
| Complexity | Lower | Higher |
| Cost | Usually lower | Usually higher |
For beginners, batch pipelines are usually the best place to start.
That is also where QuakeFlow begins.
After ingestion, data is often stored in a raw layer.
This is sometimes called:
The purpose is simple:
Keep the original data.
Example:
The API returns:
{
"id": "abc123",
"magnitude": 4.8,
"location": "California",
"time": "2026-07-18"
}
The raw layer stores this exactly as received.
You might wonder:
“Why not clean the data immediately?”
Keeping raw data provides several advantages.
If your transformation logic changes, you can rebuild everything from the original data.
If something goes wrong, you can compare:
Original data
↓
Transformed data
You preserve what the source system actually provided.
Raw data is rarely ready for reporting.
Transformation prepares data for use.
Examples:
Before:
Country
DK
Denmark
Danish
After:
Country
Denmark
Before:
CustomerID
1001
1001
1002
After:
CustomerID
1001
1002
Combining information from multiple sources.
Example:
Customers:
CustomerID
Name
Orders:
CustomerID
Amount
Combined:
Customer
Order Amount
Example:
A company defines:
“Active customer = customer who purchased within the last 90 days.”
The transformation creates this calculation.
Two important approaches in data engineering are:
Traditional approach:
Extract
↓
Transform
↓
Load
Data is cleaned before entering the target system.
Example:
Database
↓
Python Transformation
↓
Data Warehouse
This approach was common when storage and computing power were expensive.
Modern cloud platforms often use:
Extract
↓
Load
↓
Transform
The raw data is loaded first.
Transformations happen inside the warehouse or lakehouse.
Example:
API
↓
Data Lake
↓
SQL Transformations
↓
Analytics Tables
Modern cloud platforms provide:
Companies can keep raw data and transform it later.
Technologies like:
are designed around this approach.
After data has been cleaned and transformed, we need to organize it in a way that makes sense for users.
This is called data modeling.
Data modeling is the process of designing how data should be structured.
A common beginner mistake is thinking:
“If the data exists in a database, we are finished.”
But storing data is not the same as making it useful.
A company might have hundreds of tables.
The challenge is creating a structure where people can easily answer business questions.
Imagine you have these tables:
| OrderID | CustomerID | ProductID | Date |
|---|---|---|---|
| 50001 | 1001 | 501 | 2026-07-18 |
| CustomerID | Name | Country |
|---|---|---|
| 1001 | Anna | Denmark |
| ProductID | Product | Category |
|---|---|---|
| 501 | Keyboard | Accessories |
An analyst wants to answer:
“How much revenue did we generate by product category last year?”
They need to combine information from multiple places.
A good data model makes this simple.
One of the most common approaches in analytics is a star schema.
A star schema contains:
Example:
DimCustomer
|
|
DimProduct ---- FactSales ---- DimDate
|
|
DimStoreA fact table stores measurable business events.
Examples:
A fact table usually contains:
Example:
FactSales
| DateID | CustomerID | ProductID | Amount |
|---|---|---|---|
| 20260718 | 1001 | 501 | 499 |
Dimension tables describe the context around facts.
Examples:
DimCustomer
Who?
DimProduct
What?
DimDate
When?
DimLocation
Where?
Example:
DimCustomer
| CustomerID | Name | Country |
|---|---|---|
| 1001 | Anna | Denmark |
Because the pipeline does not end when data arrives.
A Data Engineer must think about:
The final design affects everyone downstream.
After transformation and modeling, data needs to be delivered to users.
This is called the serving layer.
The serving layer is where prepared data becomes useful.
Examples:
A typical flow:
Raw Data
↓
Transformations
↓
Data Model
↓
Power BI DashboardA BI Developer usually does not want to work directly with raw data.
They want clean, understandable tables.
Instead of:
Raw_Events_20260718_JSONthey want something like:
FactEarthquake
DimLocation
DimDateThis is why Data Engineering and BI work closely together.
The Data Engineer prepares the foundation.
The BI Developer builds the experience.
A pipeline that runs successfully is not necessarily a good pipeline.
The data also needs to be correct.
This is called data quality.
Imagine a pipeline runs every night.
The process completes successfully.
But today’s sales numbers are 90% lower than yesterday.
Something is wrong.
The pipeline worked technically.
The data is still incorrect.
Example:
Expected:
| CustomerID | Country |
|---|---|
| 1001 | Denmark |
Received:
| CustomerID | Country |
|---|---|
| 1001 | null |
Example:
| OrderID | Amount |
|---|---|
| 50001 | 499 |
| 50001 | 499 |
One order appears twice.
Example:
Age:
-5or:
Country = "Unknown123"Imagine yesterday:
Orders: 150,000Today:
Orders: 500The pipeline may have a problem.
Professional pipelines include automated checks.
Examples:
“Did we receive approximately the expected number of records?”
“Are primary keys unique?”
“Are required fields populated?”
“Are values within acceptable ranges?”
A simple example:
If orders_today < orders_yesterday * 0.5
Send alertA pipeline is rarely just one script.
A real data platform may have hundreds of processes.
Example:
Extract Customers
↓
Extract Orders
↓
Clean Data
↓
Update Warehouse
↓
Refresh DashboardSomething needs to control the order.
This is called orchestration.
An orchestration tool can:
Example:
Run every night at 02:00.
Example:
Do not update the dashboard until the warehouse is ready.
Example:
The API fails.
Try again after 10 minutes.
See:
Examples:
You do not need to master these as a beginner.
But understanding their purpose is important.
Professional pipelines need visibility.
A Data Engineer needs to answer:
A pipeline might record:
2026-07-18 02:00
Started ingestion
Received 15,432 records
Transformation completed
Loaded warehouse table
Completed successfullyIf something fails:
2026-07-18 02:15
ERROR:
API connection failedFailures happen.
Examples:
Good pipelines handle failures gracefully.
Instead of:
Pipeline crashedA professional system:
Pipeline failed
↓
Logged error
↓
Alert sent
↓
Retry attempted
↓
Engineer notifiedA beginner pipeline might look like:
load_data()
transform_data()
save_data()A production pipeline needs much more:
Extract
↓
Validate
↓
Transform
↓
Test
↓
Load
↓
Monitor
↓
DocumentThe difference between a script and a data engineering system is reliability.
Now we can combine everything.
This is the pipeline we will build in the practical phase.
USGS Earthquake API
|
|
↓
Python Ingestion
|
|
↓
Raw JSON Data
|
|
↓
Data Storage Layer
|
|
↓
SQL Transformations
|
|
↓
Analytical Data Model
|
|
↓
Power BI DashboardPython connects to the earthquake API.
It downloads earthquake events.
The original JSON response is saved.
Why?
Because we want the ability to:
We clean and prepare the data.
Examples:
We create analytical tables.
Example:
FactEarthquake
DimLocation
DimDatePower BI connects to the final model.
Users can explore:
Many beginners start with tools:
“I want to learn Airflow.”
“I want to learn Databricks.”
“I want to learn Spark.”
But tools only make sense when you understand the problem they solve.
A Data Engineer is not valuable because they know a specific tool.
They are valuable because they understand:
Tools change.
The principles remain.
After this article, you should understand:
You have now completed the Data Fundamentals phase.
You understand:
The next step is no longer theory.
It is time to build.
In the next part of the series:
You will:
The goal is simple:
Stop learning about Data Engineering. Start doing Data Engineering.