Organizing big data

Top 5 reasons to go for a data lake architecture

Lucas Turner
big data
© Shutterstock / Alessandro Cancian

Data lakes are just one way to organize and structure big data, and is one of the most relaxed in terms of data preparation and organization. As we are on the brink of a paradigm change fueled by the explosion of available information, here are the top reasons to look at data lakes as a data management option. Let’s take a look.

As Big Data grows in importance and acceptance, there is also an increased need to think about ways to organize and host it. One of the answers is a data lake, a data architecture system that is one of the most relaxed in terms of data preparation and organization.

In basic terms, it allows companies to first store data and then retrieve it later when necessary. It is like having a storage unit where you just put your stuff and figure out what exactly you are going to do with it at some later point.

This approach is a world away from traditional data warehouses which require data to be structured, usually in a table-like form before recording it. Data warehouses are a fixed-form solution which is less likely to be agile and implies additional reconfiguration costs. Yet until now, it has been the go-to option for businesses around the world.

As we are on the brink of a paradigm change fueled by the explosion of available information, here are the top reasons to look at data lakes as a data management option.


Since there is no need to design the schema of the data before storing it, there are no upfront development expenses. The Hadoop system that handles data lakes is open-source, so there is no added software licensing costs.

SEE ALSO: Big data in a nutshell

The difference from traditional data warehouses is that with data lakes, the ETL stage is completely eliminated. You don’t have to know what kind of data will be stored in the lake, how many fields it has or their types. Removing the ETL processes means no costs related to licenses, maintenance, or growing the data structure.


Adding a new department or a single new item can change the entire data structure you have in place, triggering additional costs. Furthermore, the implementation time necessary to make these changes can vary from days to weeks. 

In the case of a data lake, all the data is already there, with minimal changes, ready to be queried. 

This approach helps companies stay agile in the ever-changing world of today. We can expect the emergence of new data formats in the following years, some of which are not even foreseeable now. Therefore, enterprise data storage systems need to be flexible enough to accommodate all of this without significant structural changes.

Multiple formats

Data lakes can handle a wide variety of data formats. Even if some bits of data seem unrelated to other ones in a data lake, when put together and analyzed from a holistic perspective, it can offer essential business insights. 

For example, if a data lake contains recordings about clients like name, age, spending for the last year, and the heat map of clients’ behavior on the online store, it can be hard to see the direct link between these details and cues to selling more. However, putting everything together can reveal that clients of a certain age tend to make purchasing decisions faster, which can influence your targeting techniques.

Speaking of multiple formats, there is also the contextual perspective concerning data sources. The most common sources include customer–facing applications, BI apps, sales logs, and more. The rise of IoT will increase the number of data sources and formats, making data lakes the only reliable solution.


Since data lakes operate with unstructured data, they are unfit to be queried with traditional, SQL-based tools. Instead, since most of that data has the appropriate 3Vs (volume, velocity, variety), it can be qualified as Big Data and used to train AI algorithms. 

In fact, the goal of having a data lake is to have the information ready for processing in real time (or nearly real time). This dynamic approach offers companies the opportunity to react instantly. Having all data in the same place means less time for retrieving it before the analysis.

Flexibility and scale

Probably the most impressive feature of data lakes is their scalability and flexibility, which can accommodate any changes a company goes through without requiring significant changes to the infrastructure. Since the entire architecture is cloud-based and usually accessible via a pay-per-use business model, any upscale or downgrading simply means changing your payment plan.

SEE ALSO: Impact of big data on mobile application development

This flexibility is in contrast with legacy systems which can’t be modified on the spot. Adding or merging data becomes easy with data lakes. The best comparison is with the natural lake, which can be fed by multiple streams and at any time a new stream can be added without disturbing the previous setup. Meanwhile, legacy systems are like a water bottling facility, where any change requires more bottles, more labels, and rescheduling.

A heads up

Although data lakes have considerable benefits, this is not a fool-proof solution and is definitely not a panacea. The biggest risk of data lakes is that they can turn into data swamps, where data is just dumped pointlessly, without any plan or intention from the company to use it. The previously mentioned flexibility should not be permission for a lack of business goals and saving everything for later.

All the saved data streams should be linked to KPIs and business objectives as in this case study. One way of avoiding information paralysis is creating visual dashboards where the data is properly displayed and can be comprehended even by front-line employees, not only data scientists.

Another risk is the ever-growing size of data lakes, an upward trend that is here to stay, forcing organizations to move all their data storage to the cloud. 

Last but not least, the biggest struggle is finding specialists who can create the right algorithms to extract value from data lakes.


Lucas Turner

Lucas Turner is a tech writer with extensive experience in requirement gathering, writing business and functional requirements, translating business requirements into technical specifications.

1 Comment
Inline Feedbacks
View all comments
Mohit Agarwal
Mohit Agarwal
2 years ago

Pretty sure the whole schema-on-read hasn’t worked out well. Simply storing data without any understanding of how to interpret it later will lead to a data swamp. You still need metadata to make sense of the data persisted in the data lake at least for structured and semi-structured data.