It has always revolved around the concept of a data lake, with data stored as objects, a series of data engineering pipelines moving data around and a query engine on top. And in almost every enterprise company this is the high level architecture you see today.
And this model only continues to grow in popularity as the use of siloed SaaS products drives data sprawl and the need for tools like Spark, Fivetran etc to move it all back to a centralised data lake for analysis.
A data lake is one way to deal with it. It's convenient but not always the best.
Are you going to spend months upfront carefully modelling the data in order to ingest it making sure to handle schema and DQ issues etc. All to support one use case who only needs a handful of fields.
No. Which is why data lakes exist. Because it's cost effective. You simply dump the data and ask the Engineer or Data Scientist building the use case to do the heavy lifting rather than a centralised data team.