Data Science, Data Analysis, and ML: Drawing the Real Lines
Three titles, endless overlap, and a lot of job-post confusion. Here's how I actually separate data analysis, data science, and machine learning — by the question each one answers.
"Data scientist," "data analyst," and "ML engineer" get used interchangeably, and it causes real confusion — in job posts, in interviews, in what people expect you to deliver. The cleanest way I've found to separate them isn't by tools or job title. It's by the question each one answers.
The three questions
- Data analysis answers "What happened, and why?" — it looks backward at data that already exists and explains it.
- Data science answers "What's likely to happen, and what should we do?" — it uses data to model and predict.
- Machine learning engineering answers "How do we run that model reliably for real users?" — it's software engineering for models.
Everything else — Python vs SQL, notebooks vs pipelines — flows from which question you're being paid to answer.
Data analysis: making the past legible
An analyst takes messy, existing data and turns it into a decision. Which features drive churn? Which region is dragging the quarter? The output is usually a chart, a dashboard, or a number a human acts on.
The core skills are SQL, a spreadsheet or BI tool, and the statistical honesty to not mislead with a badly-chosen axis. The hard part isn't the math — it's asking the right question and cleaning the data enough to trust the answer.
-- The bread and butter: aggregate, segment, compare
SELECT region, COUNT(*) AS users, AVG(sessions) AS avg_sessions
FROM events
WHERE created_at >= '2026-01-01'
GROUP BY region
ORDER BY users DESC;Data science: modeling the future
A data scientist starts where analysis leaves off and asks what the data predicts. That means framing a problem as a model — classification, regression, clustering — engineering features, training something, and honestly measuring whether it generalizes.
The overlap with analysis is huge (you still clean data, you still explore it), but the deliverable is different: a model and a claim about how well it works on data it hasn't seen.
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
model = RandomForestClassifier().fit(X_train, y_train)
model.score(X_test, y_test) # the number that actually mattersML engineering: making it survive production
Training a model in a notebook is a science problem. Serving it to users at low latency, monitoring it for drift, retraining it on fresh data, and rolling back a bad version — that's an engineering problem, and it's mostly the engineering I already do on backends.
An ML engineer cares about the things a backend engineer cares about: latency, throughput, versioning, observability, failure handling. The model is just another dependency with an unusual failure mode — it can be quietly wrong instead of loudly broken.
Why the lines blur
At a small company one person does all three. At a large one they're separate teams. The skills form a ladder more than three separate boxes: analysis is the foundation (know your data), science adds modeling, engineering adds the production discipline to run it.
The part that's the same everywhere
Under all three, the unglamorous truth holds: most of the work is data cleaning and framing the question. The model is a few lines. The reason a project succeeds or fails is almost always whether the question was well-posed and the data was trustworthy — which is exactly where I'd tell anyone to spend their attention first.