Deep Learning & Neural Networks

Chapter 5
Data Engineering and Deep Learning Frameworks

Advance Diploma in Artificial Intelligence and Machine Learning
Deep Learning & Neural Networks   •   Advance Diploma

Data Engineering and Deep Learning Frameworks

Introduction

Deep learning systems are often described through their neural-network architectures, but reliable performance depends equally on the quality of the data pipeline and the engineering framework surrounding the model. A convolutional network, transformer, or recurrent network cannot compensate for corrupted labels, data leakage, inconsistent preprocessing, inefficient batching, or irreproducible experiments.

Data engineering for deep learning is the disciplined design of processes that acquire, validate, transform, store, batch, and deliver data to models. A framework such as PyTorch, TensorFlow, or Keras provides abstractions for tensors, automatic differentiation, neural-network layers, optimisers, hardware acceleration, model export, and distributed training. The professional objective is not merely to make a model run, but to create a pipeline that is correct, observable, reproducible, efficient, and maintainable.

This chapter develops those principles and applies them to practical deep-learning workflows.

Learning Objectives

By the end of this chapter, a learner should be able to:

  1. Explain tensors, shapes, dtypes, devices, datasets, batching, and preprocessing.
  2. Design training, validation, and test pipelines without data leakage.
  3. Compare important abstractions in PyTorch, TensorFlow, and Keras.
  4. Construct a reproducible training loop with checkpointing and experiment tracking.
  5. Explain GPU execution, memory constraints, mixed precision, and performance bottlenecks.
  6. Evaluate data and model pipelines using appropriate technical and governance criteria.

1. The Deep-Learning Pipeline as a System

A production-oriented pipeline usually contains the following stages:

  1. Data acquisition: collecting files, records, sensor readings, text, images, or events.
  2. Validation: checking schema, ranges, missing values, duplicates, corrupt files, and labels.
  3. Partitioning: creating training, validation, and test sets.
  4. Preprocessing: resizing, tokenisation, numerical scaling, augmentation, and encoding.
  5. Dataset construction: exposing examples through a consistent interface.
  6. Batching and loading: grouping examples and transferring them efficiently to the accelerator.
  7. Model computation: forward propagation, loss calculation, backpropagation, and parameter updates.
  8. Evaluation: measuring performance and analysing errors.
  9. Tracking and storage: recording configurations, metrics, artifacts, and checkpoints.
  10. Deployment: exporting the model and reproducing the preprocessing used during training.

The pipeline should preserve a strict distinction between data, configuration, code, model parameters, and results. A run is reproducible when another practitioner can reconstruct these components sufficiently to obtain comparable results.

Data leakage

Data leakage occurs when information unavailable at prediction time influences training. Common examples include normalising all data before splitting, using future records to predict the past, allowing the same patient in both training and test data, or selecting features using the complete labelled dataset. Leakage produces optimistic evaluation and is a methodological failure, not merely a software bug.

For a dataset D, a typical partition is:

D = Dtrain ∪ Dvalidation ∪ Dtest

where the three sets are disjoint. In ordinary supervised learning, preprocessing parameters such as a mean or standard deviation must be estimated using D_train only, then applied unchanged to validation and test data.

2. Tensors: The Fundamental Data Structure

A tensor is a multidimensional numerical array. A scalar has rank 0, a vector rank 1, a matrix rank 2, and higher-rank tensors represent structured data such as images, video, and batches.

Important tensor properties include:

  • Shape: the size along each dimension, such as (32, 3, 224, 224).
  • Rank: the number of dimensions.
  • Dtype: numerical representation, such as float32, float16, int64, or Boolean.
  • Device: CPU, CUDA-enabled GPU, or another accelerator.
  • Layout/strides: how elements are arranged in memory.
  • Requires-gradient status: whether operations participate in automatic differentiation.

For a colour-image batch in a channels-first convention, the shape is commonly (N, C, H, W), where N is batch size, C is the number of channels, H is height, and W is width. A channels-last convention uses (N, H, W, C). Confusing these conventions can produce incorrect results or runtime errors.

A tensor’s memory requirement is approximately:

M = Nelements × bytesperelement

For a tensor of shape (32, 3, 224, 224) in float32, the number of elements is 4,816,896. Since float32 normally uses 4 bytes, its storage is approximately 19,267,584 bytes, or 18.38 MiB when divided by 1,048,576. This estimate excludes gradients, intermediate activations, allocator overhead, and model parameters; actual training memory is therefore higher.

Tensor operations

Frameworks provide operations for reshaping, slicing, concatenation, matrix multiplication, broadcasting, reduction, and device transfer. Reshaping is safe only when the intended element order and total number of elements are preserved. Broadcasting allows compatible dimensions to interact without explicitly copying data, but it must be understood carefully because an unexpected singleton dimension can silently produce an incorrect result.

Numerical stability is also important. For example, probabilities should generally be produced by a framework’s combined logits-and-loss function rather than by manually applying a softmax and then taking logarithms. Fused functions are usually more stable and efficient.

3. Datasets, Sampling, and Batching

A dataset abstraction maps an index or key to an example. An example may be a pair (x, y), where x is an input and y is a target, or a richer record containing metadata. A data loader combines examples into batches, optionally shuffles them, uses worker processes, and performs memory transfer.

If a dataset contains N examples and uses batch size B, the number of batches per epoch, when the final incomplete batch is retained, is:

K = ⌈N ÷ B⌉

If incomplete batches are discarded, the number is floor(N ÷ B). For N = 10,000 and B = 64, retaining the final batch gives K = 157 batches, with the final batch containing 16 examples.

Why batching matters

Batching improves hardware utilisation and provides a practical compromise between noisy single-example updates and expensive full-dataset updates. Larger batches may increase throughput but require more memory. They can also alter optimisation dynamics because gradient estimates become less variable.

For a batch loss with examples i = 1,…,B, the mean loss is:

Lbatch = (1 ÷ B) ∑ᵢ₌₁ᴮ ℓᵢ

where ℓᵢ is the loss for example i. The formula assumes each example contributes equally. Weighted losses are needed when class importance, sampling probabilities, or business costs differ.

Sampling strategies

Uniform random sampling is suitable for many balanced datasets. Imbalanced classification may require class-weighted losses, weighted sampling, stratified splitting, or carefully designed augmentation. Oversampling the minority class can improve exposure but may increase overfitting because some examples are repeated. Evaluation should normally preserve the natural deployment distribution unless a different evaluation objective is explicitly justified.

For time series, random shuffling can be invalid. A chronological split is required when future information must not enter the past. For grouped data, such as multiple records from one patient, customer, or machine, splitting must occur by group rather than by individual row.

4. Preprocessing and Feature Pipelines

Preprocessing transforms raw data into model-ready representations. Common operations include:

  • numerical imputation and scaling;
  • categorical encoding;
  • text tokenisation and vocabulary management;
  • image resizing, cropping, normalisation, and augmentation;
  • audio resampling and spectrogram generation;
  • padding and masking for variable-length sequences.

For feature x, standardisation is commonly defined as:

z = (x − μtrain) ÷ σtrain

where μ_train and σ_train are the training-set mean and standard deviation. This transformation is appropriate when a numerical feature benefits from centring and scale adjustment; it is not automatically appropriate for every variable. If σ_train = 0, the feature is constant in the training data and requires removal or a defined fallback rather than division by zero.

Min–max scaling to [0, 1] is:

x' = (x − xmin) ÷ (xmax − xmin)

where x_min and x_max are estimated from training data. It is sensitive to outliers and should not be fitted independently on the test set.

Training-time augmentation

Augmentation creates altered training examples that preserve the target, such as image flips, crops, colour changes, or text masking. Augmentation must reflect plausible variation. A horizontal flip may be invalid for text or medical images where laterality matters. Validation and test data should usually receive deterministic preprocessing only, not random augmentation.

Pipeline consistency

The same conceptual preprocessing must be represented in training, evaluation, and deployment. A frequent operational defect is training with one tokeniser or image normalisation scheme and deploying another. Preprocessing configuration should therefore be versioned and, where possible, packaged with the model.

5. Frameworks and Their Abstractions

PyTorch

PyTorch provides tensors, automatic differentiation, neural-network modules, optimisers, data loaders, and extensive accelerator support. A typical workflow defines a Dataset, wraps it in a DataLoader, creates an nn.Module, computes a loss, and performs optimisation through an explicit training loop. This explicitness is valuable for research, custom objectives, and unusual training procedures.

A conceptual PyTorch loop is:

for epoch in epochs:
    model.train()
    for x, y in train_loader:
        x, y = x.to(device), y.to(device)
        optimiser.zero_grad()
        prediction = model(x)
        loss = criterion(prediction, y)
        loss.backward()
        optimiser.step()
    model.eval()
    evaluate_without_gradient_tracking(model, validation_loader)

model.train() and model.eval() control behaviours such as dropout and batch normalisation. Evaluation should disable gradient recording when gradients are not required, reducing memory use.

TensorFlow and tf.data

TensorFlow represents computation through tensors and supports automatic differentiation with gradient tapes. The tf.data API constructs input pipelines using operations such as map, shuffle, batch, cache, and prefetch. TensorFlow can execute eagerly for convenient debugging and can trace functions for graph-based optimisation and deployment.

A typical pipeline conceptually follows:

dataset = dataset.map(preprocess)
dataset = dataset.shuffle(buffer_size)
dataset = dataset.batch(batch_size)
dataset = dataset.prefetch(autotune)

The order matters. Shuffling before batching generally mixes individual examples; batching before shuffling shuffles batches instead. Caching requires sufficient memory or a suitable cache location and must not accidentally preserve random transformations that are intended to change each epoch.

Keras

Keras provides a high-level API for defining, training, evaluating, and exporting models. The Sequential API is convenient for simple stacks; the Functional API represents graphs with branches, multiple inputs, and multiple outputs. Custom training loops remain available when fit() is insufficient.

Keras can operate with TensorFlow and, in contemporary versions, supports multiple computational backends. Its strengths include rapid prototyping, callbacks, readable model definitions, and accessible deployment workflows. The trade-off is that highly customised research may require lower-level control.

ConcernPyTorchTensorFlowKeras
Typical styleExplicit, Python-oriented loopEager plus graph pipelinesHigh-level model and training API
Input abstractionDataset/DataLoadertf.dataArrays, datasets, generators
Custom trainingVery flexibleGradient tapes/custom loopsCustom train_step or loops
StrengthResearch control and debuggingProduction ecosystem and input graphsProductivity and readability
Main riskInconsistent manual conventionsPipeline complexityHidden defaults or insufficient control

These are not mutually exclusive categories. Professional teams choose according to the task, existing infrastructure, deployment target, team expertise, and maintenance requirements.

6. The Training Loop and Model State

A supervised training step generally consists of:

  1. obtain a batch;
  2. move data to the appropriate device;
  3. compute predictions;
  4. calculate loss;
  5. compute gradients;
  6. update parameters;
  7. record metrics.

For parameters θ and learning rate η, basic gradient descent is:

θt+1 = θt − η ∇_θ L(θt)

Here θ_t is the parameter vector at step t, L is the objective function, and ∇_θ L is the gradient with respect to θ. The equation describes a basic update; practical optimisers such as Adam maintain additional state and use adaptive estimates.

A model checkpoint should include more than the network weights when training must resume faithfully. It may include optimiser state, scheduler state, current epoch or step, random-number-generator states, preprocessing configuration, and the code or environment version. Saving only weights is adequate for inference in some settings but not for exact training continuation.

Loss and metrics

The loss is the quantity optimised; a metric is a quantity reported for interpretation. They may be identical, but need not be. For binary classification, binary cross-entropy for one example with target y ∈ {0,1} and predicted probability p ∈ (0,1) is:

ℓ = −[y ln(p) + (1 − y) ln(1 − p)]

The logarithm is natural, and the expression assumes a binary target and a valid probability. In implementation, a numerically stable logits-based loss is generally preferred.

Accuracy may be inappropriate for severe class imbalance. Precision, recall, F1 score, calibration, area under a relevant curve, confusion matrices, and cost-sensitive measures may provide better evidence. Metrics must be selected according to the decision consequences of errors.

7. GPUs, Performance, and Numerical Precision

GPUs accelerate deep learning through massive parallelism, particularly for matrix multiplication and tensor operations. Performance depends on more than the presence of a GPU. Bottlenecks include slow storage, expensive Python preprocessing, insufficient batch size, repeated device transfers, synchronisation, and poor kernel utilisation.

Good practice includes:

  • transfer batches to the accelerator efficiently;
  • use pinned host memory where supported;
  • overlap data preparation and computation through prefetching;
  • avoid unnecessary CPU–GPU transfers;
  • profile before optimising;
  • monitor memory, throughput, and utilisation;
  • use appropriate worker counts rather than assuming more workers are better.

Mixed precision

Mixed-precision training uses lower precision for selected operations while retaining sufficient precision for sensitive computations. It can reduce memory usage and increase throughput on compatible hardware. Loss scaling may be used to prevent small gradients from underflowing. Mixed precision is not universally safe: numerical ranges, model operations, and convergence must be validated.

A useful throughput measure is:

Throughput = processedexamples ÷ elapsedtime

Units might be examples per second. This measure should be reported with hardware, batch size, precision, input dimensions, and whether data-loading time is included.

8. Reproducibility and Experiment Tracking

Reproducibility has several levels:

  • Repeatability: the same team obtains similar results in the same environment.
  • Reproducibility: another team reconstructs the experiment using the documented materials.
  • Robustness: conclusions remain valid under reasonable changes in seeds, splits, or environments.

A seed alone does not guarantee reproducibility. Sources of variation include data ordering, parallel workers, GPU kernels, nondeterministic operations, library versions, hardware, and external data. Deterministic modes may reduce performance and still cannot solve undocumented preprocessing or changing data sources.

An experiment record should contain:

  • dataset identifier and split definition;
  • code revision and environment specification;
  • model architecture and parameter count;
  • hyperparameters;
  • random seeds and determinism settings;
  • training and validation metrics by step or epoch;
  • checkpoints and preprocessing artifacts;
  • hardware and runtime information;
  • evaluation results and error analysis.

Tools such as TensorBoard, MLflow, Weights & Biases, and platform-specific tracking systems can store metrics, plots, artifacts, and metadata. Tracking tools do not create scientific validity automatically; they support disciplined practice.

9. A Reproducible Project Structure

A maintainable project may separate concerns as follows:

deep_learning_project/
  data/
    raw/
    processed/
  src/
    data.py
    preprocessing.py
    model.py
    train.py
    evaluate.py
  configs/
    baseline.yaml
  tests/
  notebooks/
  checkpoints/
  reports/
  environment.yml
  README.md

Configuration files should define parameters rather than burying them in code. Data should be immutable where possible, and generated artifacts should record their source and transformation version. Unit tests can verify tensor shapes, label ranges, preprocessing behaviour, and dataset partitioning before an expensive training run begins.

10. Illustrative Case: Predictive Maintenance for Industrial Pumps

Background

An engineering company monitors pumps using vibration, temperature, pressure, and operating-load sensors. The objective is to predict whether a pump will require maintenance within the next seven days.

Problem

The raw data contains irregular timestamps, missing sensor readings, multiple records for each pump, and a strong imbalance: failures are uncommon. A random row-level split would place records from the same pump in both training and test sets and could allow temporal leakage.

Analysis

The team first defines the prediction time and the seven-day outcome window. Features are constructed only from measurements available before that time. Pumps are assigned to splits by asset identifier, and the final evaluation uses a chronological holdout. Missingness indicators are retained because a sensor failure may itself be informative.

Training-set statistics are used to scale continuous variables. Windows are padded or masked where sequence length varies. The minority class is handled with a weighted loss, but the team also reports precision–recall performance and the number of false alarms because maintenance staff have limited capacity.

Approach

A sequence model is implemented in PyTorch. A Dataset returns a sensor window, mask, label, and asset identifier. The loader batches windows and uses pinned memory. The model checkpoint stores weights, optimiser state, scaling parameters, feature definitions, and the split manifest. Each experiment logs configuration, code revision, validation metrics, calibration plots, and a confusion matrix.

The validation threshold is selected using operational cost rather than automatically choosing 0.5. The final test set is opened only after model and threshold decisions are frozen.

Outcome

The resulting model is not judged solely by accuracy. The company evaluates recall at an acceptable alert volume, calibration, detection lead time, stability across pump types, and performance under sensor missingness. Monitoring is added for feature distributions, alert rates, delayed labels, and data pipeline failures.

Learning points

The case demonstrates that the central challenge is not simply selecting a neural architecture. Correct temporal definitions, group-aware splitting, versioned preprocessing, appropriate metrics, checkpoint discipline, and post-deployment monitoring determine whether the model is trustworthy.

11. Governance, Security, and Limitations

Deep-learning pipelines process data that may contain personal, confidential, or commercially sensitive information. Governance should address lawful collection, purpose limitation, access control, retention, encryption, audit trails, and deletion procedures. Sensitive data should not be copied into experiment trackers or notebooks without justification.

Dataset documentation should describe provenance, collection conditions, known biases, labelling procedures, exclusions, and permitted uses. Model documentation should state intended use, limitations, evaluation populations, and failure modes.

Security threats include poisoned training data, malicious model files, compromised dependencies, exposed credentials, and adversarial inputs. Dependency pinning, vulnerability scanning, least-privilege access, signed artifacts, and isolated execution reduce risk.

Important limitations include:

  • training metrics may not represent deployment conditions;
  • benchmark improvements may result from leakage or tuning to the test set;
  • preprocessing pipelines can silently change data distributions;
  • GPU nondeterminism can complicate exact replication;
  • high throughput may conflict with energy, cost, or environmental objectives;
  • automated predictions may amplify historical bias.

Responsible deployment requires human oversight when errors have significant consequences and a mechanism for appeal, correction, and model withdrawal.

12. Contemporary Engineering Practices

Modern systems increasingly use data and model versioning, containerised environments, continuous integration, automated tests, feature and model registries, and monitoring platforms. Distributed training can shorten training time, but introduces issues of communication overhead, gradient synchronisation, checkpoint coordination, and reproducibility.

An emerging emphasis is the data-centric development cycle: improving labels, coverage, documentation, and difficult examples rather than repeatedly enlarging model complexity. Efficient inference techniques include quantisation, pruning, distillation, compilation, and hardware-specific optimisation. These methods must be evaluated for accuracy, latency, memory, and fairness rather than adopted solely because they reduce model size.

Best-Practice Checklist

Before training:

  • define the prediction target and information-availability time;
  • validate schema, labels, ranges, duplicates, and missingness;
  • create leakage-resistant splits;
  • fit preprocessing only on training data;
  • record code, data, configuration, and environment versions.

During training:

  • verify tensor shapes and dtypes;
  • monitor loss, meaningful metrics, learning rate, throughput, and memory;
  • checkpoint model and optimiser state;
  • evaluate with deterministic preprocessing;
  • profile input and compute pipelines.

Before deployment:

  • test on a locked holdout set;
  • package preprocessing with the model;
  • assess calibration, subgroup performance, and failure cases;
  • document intended use and limitations;
  • establish monitoring, rollback, and retraining procedures.

Chapter Summary

Deep learning is an engineered pipeline rather than an isolated neural-network definition. Tensors provide the common representation for data and computation, while datasets and loaders organise examples into efficient, reproducible batches. Preprocessing must be fitted without leakage and must remain consistent across training and deployment. PyTorch, TensorFlow, and Keras offer overlapping but differently structured abstractions for data, models, automatic differentiation, and training.

Reliable systems manage tensor shape, dtype, device placement, memory, precision, checkpoint state, and experiment metadata. GPU acceleration is valuable only when data loading and computation are coordinated. Reproducibility requires versioned data, code, configurations, environments, seeds, and evaluation procedures. Finally, governance, security, bias analysis, monitoring, and operational constraints are essential to responsible application.

Key Terms

Tensor: A multidimensional numerical array used to represent data and parameters.

Shape: The size of a tensor along each dimension.

Dtype: The numerical or logical data type stored by a tensor.

Device: The processor location, such as CPU or GPU, on which a tensor resides.

Dataset: An abstraction that provides examples and targets to a training process.

Data loader: A component that batches, samples, and transfers dataset examples.

Batch: A group of examples processed in one computation step.

Data leakage: Use of information during training that would not be available at prediction time.

Preprocessing: Transformation of raw data into model-ready inputs.

Augmentation: Creation of plausible altered training examples.

Automatic differentiation: Computation of derivatives through recorded operations.

Checkpoint: A saved model and, potentially, training state.

Mixed precision: Use of more than one numerical precision during computation.

Throughput: Number of examples processed per unit of time.

Epoch: One complete pass through the training dataset.

Experiment tracking: Recording configurations, metrics, artifacts, and metadata for runs.

Data drift: Change in input-data distribution over time.

Calibration: Agreement between predicted probabilities and observed frequencies.

Inference: Using a trained model to generate predictions.

Reproducibility: Ability to reconstruct and obtain comparable experimental results.

Review Questions

Short Answer Questions

  1. What are the roles of shape, dtype, and device in a tensor?
  2. Why must preprocessing statistics normally be fitted on training data only?
  3. State two differences between PyTorch data loading and TensorFlow’s tf.data approach.
  4. Why should model evaluation generally disable gradient tracking?
  5. Name four items that should be recorded for a reproducible experiment.

Long Answer Questions

  1. Explain how a complete deep-learning data pipeline moves from raw data to deployment, including validation and monitoring.
  2. Compare PyTorch, TensorFlow, and Keras in terms of abstraction, flexibility, and typical use.
  3. Explain batching, sampling, class imbalance, and the implications of batch size for memory and optimisation.
  4. Discuss GPU performance bottlenecks and propose a systematic profiling strategy.
  5. Explain why model weights alone may be insufficient to reproduce a training run.

Analytical / Application Questions

  1. A medical dataset contains multiple scans per patient. Design a leakage-resistant training, validation, and test split and justify it.
  2. A model has 98% accuracy but misses most rare failures. Which additional metrics and pipeline changes would you investigate, and why?
  3. A training run is fast on synthetic data but slow on real images. Develop a diagnostic plan covering storage, preprocessing, batching, device transfer, and GPU utilisation.

Multiple Choice Questions with Answers

Question 1

Which property specifies the numerical representation used by a tensor?

A. Shape

B. Dtype

C. Device

D. Rank

Correct Answer: B. Dtype

Question 2

A dataset has 10,000 examples and uses batches of 64 while retaining the final incomplete batch. How many batches are processed per epoch?

A. 156

B. 157

C. 160

D. 10,064

Correct Answer: B. 157

Question 3

Why should scaling parameters normally be estimated using the training set only?

A. To increase tensor rank

B. To prevent test information from influencing training

C. To make every feature binary

D. To eliminate the need for validation

Correct Answer: B. To prevent test information from influencing training

Question 4

Which split is most appropriate for predicting future events in a time series?

A. Random row-level split

B. Chronological split

C. Split by tensor dtype

D. Split after test evaluation

Correct Answer: B. Chronological split

Question 5

In PyTorch, what is the main purpose of model.eval()?

A. It deletes model parameters

B. It activates random augmentation

C. It switches evaluation-sensitive layers to evaluation behaviour

D. It moves the model automatically to the GPU

Correct Answer: C. It switches evaluation-sensitive layers to evaluation behaviour

Question 6

Which item is especially important for resuming training faithfully?

A. Only the final accuracy

B. Only the model name

C. The optimiser state as well as model parameters

D. The screen resolution

Correct Answer: C. The optimiser state as well as model parameters

Question 7

What does prefetching primarily help achieve in an input pipeline?

A. Overlap data preparation with model computation

B. Guarantee perfect accuracy

C. Remove all missing values

D. Convert labels into images

Correct Answer: A. Overlap data preparation with model computation

Question 8

For binary classification, why are precision and recall useful in addition to accuracy?

A. They require no labels

B. They can reveal performance when classes are imbalanced

C. They measure GPU memory directly

D. They replace preprocessing

Correct Answer: B. They can reveal performance when classes are imbalanced

Question 9

Which practice best reduces leakage in a patient-level medical dataset?

A. Place scans from each patient in every split

B. Split records randomly regardless of patient

C. Assign whole patients to separate splits

D. Fit preprocessing on the test set

Correct Answer: C. Assign whole patients to separate splits

Question 10

What is a principal benefit of mixed-precision training on compatible hardware?

A. It guarantees deterministic results

B. It can reduce memory use and increase throughput

C. It removes the need for validation

D. It prevents all numerical errors

Correct Answer: B. It can reduce memory use and increase throughput

Deep Learning & Neural Networks
Chapter 5 of 15