What Is a Data Lake?

The Spark job has been running for forty-three minutes and is at sixty percent. It used to take eight. The cluster size has not changed. The dataset is bigger, but not five-times-bigger.

Someone says we need a Trino cluster. Someone else says we need to reorganize the lake.

I have been at spark-ui-first for hours that turned into a different problem than the one on the screen. Executor OOM, shuffle spill, skew — these are real failure modes and they are usually not what is wrong. The job is reading from Parquet files that are too small in some directories and too big in others, written by three different services with three different partitioning schemes, none of which were agreed.

This is what data lakes look like in practice. The cluster is the loud system. The cause is one layer up, in a schema-on-read promise that nobody enforced when the writers shipped.

Step One — The Wrong Assumption

"Schema-on-read means we figure out the schema later."

"It's a data lake. We dump everything in raw and figure out the schema at query time. That's the whole point."

This is the founding myth of the data lake, and it is the source of most of its later pain. "Schema-on-read" was a useful architectural pattern in 2014 when the alternative was a rigid warehouse that took six months to add a column. It was never an excuse to write whatever shape you felt like writing.

What "later" turns out to mean is "at every query, by every consumer, forever, without coordination." Each downstream team makes its own assumptions about what the data means. Each team's assumptions diverge. The next person to query the table inherits the union of every assumption ever made about it. That is not flexibility. That is technical debt with a marketing name.

Step Two — The Partial Signal

The job runs. The numbers come out. Three months later they no longer match.

The early signal that something is wrong is not that queries fail. They run. The dashboards refresh. The notebook compiles. What goes wrong is that two analysts running what should be the same query get different numbers, and neither of them did anything wrong.

The reason is that the upstream writer changed the encoding of a column three months ago. Both queries returned a result. Neither query had a way to know the encoding had changed, because the table did not have an enforced schema; it had a directory of files that happened to look schema-compatible at write time. The producer shipped, the consumer queried, the schema-on-read inferred something different on Tuesday than it did on Monday.

Spark engineers see this exact pattern in shuffle spills. The job worked yesterday. The job is failing today. Nothing visible has changed. What changed was upstream, in the writer, in a way the executor cannot see.

Step Three — The Failed Fix

You add Iceberg. The schema is enforced. The writers don't use Iceberg.

The technical fix is well known by now. Move the lake to a table format — Apache Iceberg, Delta Lake, Apache Hudi — that enforces a schema, supports ACID transactions, tracks history, and prevents the writer from breaking the contract.

The technical fix is the easy part. The hard part is that the lake has been accumulating writers for three years from teams that do not coordinate, do not share a release cadence, and do not have an SLA with the platform team. Iceberg cannot fix the writers it does not see. You can make the new tables Iceberg-native. The thirty existing tables, which is where the actual queries run, are still raw Parquet with whatever shape someone decided in 2022.

The migration project is now larger than the original lake project. It will take a year. During that year, the lake will continue to accumulate writers from teams who are not on the migration roadmap. The fix did not fix anything; it just gave you a new system that contains the same problem alongside the old one.

Step Four — The Real Failure

It was never a storage decision. It was a contract decision made by default.

The actual failure is the moment a writer was allowed to write to the lake without agreeing to a schema. That moment is invisible at the time. Nobody calls a meeting to say "we are about to skip the contract." It just happens, because the data lake architecture explicitly allowed it, and the alternative felt like the rigid warehouse the team was trying to leave behind.

What the architecture does not say out loud is that "schema-on-read" is a contract decision masquerading as a storage decision. By the time you are at query time, the contract has already been made or not made. The lake is just where the consequences pile up.

This is the lesson Spark engineers, DBAs, and integration teams keep relearning in different forms. The system that is loudest about the failure is downstream of the system that caused the failure. Tuning the loud system is satisfying and almost never fixes anything for more than a quarter.

Step Five — The Definition

Now the definition lands.

A data lake is a governed object store of structured and semi-structured data — in open formats like Parquet, with table-format guarantees from Iceberg, Delta, or Hudi — where the contract between writers and readers is enforced before the first query runs, not inferred after the third year.

Most definitions describe a data lake as "a centralized repository for raw data at any scale." That description is not wrong, but it is the part of the definition that produces data swamps. The part that prevents data swamps is the contract: an enforced schema, a defined retention policy, a named owner per dataset, and a writer registry that the platform team actually maintains.

The lake is the storage. The lakehouse pattern, with table-format guarantees, is the contract. Without the second, you do not have a data lake; you have a directory of files.

What Solix Enforces

The contract layer is the lake. The bucket is just where it lives.

Solix's Common Data Platform is built around the same principle that distinguishes a usable data lake from a data swamp: the governance layer sits above the storage, and the contract is enforced at the boundary every dataset crosses on the way in.

Whether the source is an SAP module being decommissioned, a custom application being retired, or a continuous AI inference stream, the data lands in the platform under policy — with retention, lineage, access controls, and schema agreement bound at capture. The lake stays a lake, not a directory of files that happen to share a bucket.

Three things to do this week

• Pick the largest dataset in your lake and find its writer. If the writer is unnamed, or the writer is a service that has been deprecated, you have a data swamp tile. Surface it to the platform team. The number of these tiles you find is a leading indicator of how much migration work is ahead of you.
• Audit which of your tables have an enforced schema. Count tables under Iceberg/Delta/Hudi versus raw Parquet/JSON. The ratio tells you how much of your lake is governed and how much is in the swamp pile. The number is almost always worse than the team thinks it is.
• Write the schema-change protocol before you migrate the next table. Before lifting any new dataset into a table format, define the protocol: who proposes, who reviews, who notifies consumers, what the rollback path is. The protocol is what makes the table format actually enforce. Without it, you have shifted the problem one layer up, not solved it.

References

• Forrester Research — The Forrester Wave™: Data Lakehouses, Q2 2024. Report ID RES180732
• Gartner Peer Insights, market category — Cloud Database Management Systems. Reviewed 2026
• Gartner Peer Insights, market category — Metadata Management Solutions. Reviewed 2026