Data Lakes Are Not Just For Big Data
Data Lakes Are Not Just For Big Data
Data lakes are not just for 'big data' and you have more opportunities than ever to have them be part of your data stack.
Join the DZone community and get the full member experience.Join For Free
We recently wrote an article debunking common myths about data lake architectures, data lake definitions, and data lake analytics. It is called "What is a Data Lake? Get A Leg Up Avoiding The Biggest Myths." In that article, we framed the current conversation about data lakes and how they fit within enterprise data strategies. This topic has historically been confusing and opaque for those wanting to get value from a data lake due to conflicting advice from consultants and vendors.
One area that can be particularly confusing is the perception that lakes are only for "big data." If you spend any time reading materials on lakes, you would think there is only one type and it would look like the Capsian Sea (it’s a lake despite “sea” in the name). People describe data lakes as massive, all-encompassing entities, designed to hold all knowledge. The good news is that lakes are not just for "big data" and you have more opportunities than ever to have them be part of your data stack.
Yes, There Are Different Types of Data Lakes
Just as they do in nature, lakes come in all different shapes and sizes. Each has a natural state, often reflecting ecosystems of data, just like those in nature reflect ecosystems of fish, birds, or other organisms.
Unfortunately, the “big data” angle gives the impression that lakes are only for “Caspian” scale data endeavors. This certainly makes the use of data lakes intimidating. As a result, describing things in such massive terms makes the concept of a lake inaccessible to those who can benefit from them on a smaller scale. Here are a few data lake examples;
- The Great “Caspian”: Just like the Caspian is a large body of water, this type of lake is a large, broad repository-diverse set of data. This broad collection of diverse data reflects information from across the enterprise. This is how most data lake efforts are framed.
- Temporary “Ephemeral”: Just like deserts can have small, temporary lakes, an Ephemeral exists for a short period of time. They may be used for a project, pilot, PoC or a point solution and they are turned off as quickly as they were turned on.
- Domain “Project”: These lakes, like Ephemeral data lakes, are often focused on specific knowledge domains. However, unlike the Ephemeral lake, this lake will persist over time. These may also be “shallow,” meaning they may be focused on a narrow domain of data such as media, social, web analytics, email, or similar data sources.
We recently worked with a customer to create a "Domain" type lake. This lake would hold Adobe event data to an AWS to support an enterprise Oracle Cloud environment. Why AWS to Oracle? It was an efficient and cost-effective data consumption pattern for the customer Oracle BI environment, especially considering the agility and economics of using an AWS lake and Athena as the on-demand query service for lake content.
By design, all types of lakes should embrace an abstraction that minimizes risk and affords you greater flexibility. Also, they should be structured for easy consumption independent of their size. This ensures a lake used by a data scientist or business user or analyst all have an environment structured for easy data consumption.
Getting Started With Data Lakes
Being a successful early adopter means taking a business value approach rather than a technology one. Here are a few tips as you think about how to get started:
- Focus: Seek opportunities where you can deploy an “Ephemeral” or “Project” solution. This will ensure you reduce risk and overcome technical and organizational challenges so your team can build confidence with lakes.
- Passion: Make sure you have an “evangelist” or “advocate” internally, someone who is passionate about the solution and adoption within the company.
- Simple: Embrace simplicity and agility, put people, processes, and technology choices through this lens. The lack of complexity should not be seen as a deficiency but a byproduct of thoughtful design.
- Narrow: Keep the scope narrow and well defined by limiting your lake to understand data, say exports from ERP, CRM, Point-of-Sales, Marketing, or Advertising data. Data literacy at this stage will help you understand workflow around data structure, ingest, governance, quality, and testing.
- Experiment: Pair your lake with a modern BI and analytics tools like Tableau, Power BI, Amazon Quicksight, or Looker. This will allow non-technical users an opportunity to experiment and explore data access via a lake. This allows you to engage a different user base that can assess performance bottlenecks, discover opportunities for improvements, possible linkages to any existing EDW systems (or other data systems), and additional candidate data sources.
Focusing on business value, rather than technology, affords you an opportunity to frame your efforts in the context of a holistic data and analytics strategy. This increases velocity and helps you can achieve your data lake goals and measure progress in business performance. This also results in the refinement shared terminology, best practices, and investments into building better platforms.
Opinions expressed by DZone contributors are their own.