I think Steve has a point here, but I think it also goes deeper, into the philosophy (if you want to call it that) of having a pre-defined "structure" or "model" or not. This was debated before SQL databases took over the world, and it is still unresolved.
Some users really do want to work with data "as captured" and work with tools which allow them to impose their own structure on it. I've worked with some of them, and they are often people who understand the value of a formal model. In fact that seems to be what they are trying to construct. In my experience they are also quite rare. A more common breed are the ones who "want pre-built structures they can count on and use reliably to answer questions". They are not interested in the abstract thinking required to create the model, they just want data which they can use to give them reliable answers to their questions.
The last time I did it, creating the data model was one of the "hard bits". That kind of abstract thinking is rarely easy and many of the people who want (and need) to use a data model are not well suited to creating it. This is a paradox.
I agree that "learning how to access new sources, like Hadoop, and present that data back to users in a familiar format" seems like a good thing to do. Myself, I'm trying work out how to do it! On the one hand I want to retain the flexibility which is inherent in NoSQL, but on the other I want the reliability of "columns and rows" (and constraints too, if I can have them) and I want to get from one to the other quickly, without the struggles I remember from the past.
Coincidentally, I just stumbled across a 30-year-old text on converting a logical data model to a _hierarchical_ database design. I guess that is going from "logical" to something one or more stages less flexible than a relational database. Problems in this area are not new!