The raw data that emerges from your company's operations often contains valuable business insights and opportunities. Trends in historical data can help mold your present and future business decisions. For example, a department restructuring in the past might have had cascading effects on sales that can teach important lessons to your management.
However, an enterprise’s instinct has always been to retain only the data that employees of the time assumed would be directly useful in decision-making. There were good reasons for this prioritization in the past. Expensive data storage costs, weak hardware, and limitations of data analysis techniques made storing all data a complex, expensive effort that was difficult to justify to management.
But in recent years, cloud services have made it possible to cheaply store and process petabytes of data. Simultaneously, data science and machine learning techniques have also improved to a point where they can find associations and correlations across petabytes of data.
These two developments enable all data to be stored and analyzed in systems called data lakes.
The key philosophy behind data lakes is that all your data is valuable because business insights can emerge from any part of it at any time. This idea has found widespread acceptance given that demand for data lakes is projected to grow by 20.6% every year from 2020 to 2027.
In this practical guide, you'll get to know the principles, architectures, and technologies we use for your data lake implementation.
What Is a Data Lake?
A data lake is a software and ETL pipeline system for long-term storage, retrieval, and analysis of all the data in any form that an enterprise consumes and produces over its lifetime.
This may sound underwhelming but consider that "all the data in any form over a lifetime" implies handling:
Data of every variety: Relational data, text, filesystems, time series, images, or audio
Data of any volume: From kilobytes to petabytes and more
Data with any structure: Structured, semi-structured, or unstructured data
Data in any processing state: Raw, modified, curated, or generated data
Data from any data source: From databases, data warehouses, or real-time streaming data from Internet of Things (IoT) devices
Data from any time: Historical, contemporary, and future data
Seen in this light, it's obvious that a data lake is orders of magnitude more complex than any other big data management system. We use a set of core principles to control this complexity when implementing data lakes.
Principles for a Data Lake Implementation
We use these foundational principles to guide all our architecture and technology decisions.
Business Insights Can Come From Anywhere at Anytime
We recommend preserving all your data because business insights can come from any subset of that data at any time. They emerge from imaginative business analysts and data scientists who can creatively join the dots across datasets and times. Such creativity is impossible unless you have preserved the data systematically.
Raw Data Has Business Value
We believe that all your data — even raw, messy data — holds inherent business value just waiting to be discovered. The mere ownership of some enterprise data may open up new business opportunities for you in future.
A data lake's workflows should ensure that no data is discarded based on the business or engineering thinking of a particular time period. At the same time, it should not become an unorganized data swamp where data is simply dumped without any context.
Your raw data may be semi-structured data or unstructured data. All data has some structure but the relevance of that structure to your particular enterprise decides if it's semi-structured or unstructured.
For example, the XML structure of XML-ACH bank transaction data is relevant to a financial enterprise but because it can’t be queried without modification, it's termed semi-structured. A scanned image of an official letter also has some structure — perhaps one defined by the JPEG standard. But since the enterprise is only interested in the text captured in that image and not its JPEG encoding, it's considered unstructured.
Support Diverse Users and Roles
Your data lake should support all the different data roles and their use cases in your company:
Your business analysts expect business intelligence data in relational databases.
Your data scientists expect data in raw formats like JSON and CSV or in relational databases.
Your data engineers expect data in binary formats like Parquet to optimize performance.
A data lake should provide self-service features to all its end users. Your employees can search for the data they need, request and receive access automatically, explore the data, run their analytics, and add any new data or results to the data lake.
Traditionally, databases and data warehouses needed an IT division to support analysts and data scientists. Such an approach is just not practical at the scale of a data lake.
We derive a set of architectural principles from these foundations to guide all our architecture decisions.
Support for diverse roles implies that a data schema can't be imposed on incoming data. Incoming data is stored in a common format such as JSON or Parquet. Data that already has associated schema — such as relational data — has its schema stored as metadata in the same common format.
Schema-on-read means a task-specific schema is applied by your analyst or data scientist only at the time of reading the data. This may involve an interface that presents a relational or another view over the data, or it may involve temporarily exporting data to a database.
For example, Siemens Mobility, a transportation solution provider, receives streaming data from thousands of IoT sensors installed on their customers’ rail assets. All this unstructured data is stored raw in their cloud data lake. Their data scientists then apply schema-on-read (using Amazon Athena) over this raw sensor data to be able to query it by country, customer, location, asset ID, and so on for tasks like rail defect detection.
Your data lake should provide mechanisms to describe each dataset in detail. It should include the business and regulatory context in which the data is created and used. It should support other metadata such as schema and semantics of data fields. It should support the versioning of data. Since creating metadata manually is laborious, it should support mechanisms for automated inference of field types using machine learning.
Blackline Safety, a global provider of safety monitoring solutions, stores unstructured streaming data from their safety devices in a cloud data lake and manages their metadata to be able to find relevant datasets easily.
Searchability Using Data Catalogs
Your employees should be able to first discover the data before they can discover any insights from them. Self-serviceability means the diverse sets of data in a data lake are easily found through their metadata. It should provide data cataloging features that offer user-friendly Amazon-like search with queries, suggestions, and search filters.
For example, the BMW Group stores massive volumes of vehicle telemetry data every day. Their data teams transform this raw data into structured data whose technical schemas and human-readable notes are registered with the lake’s catalog service (provided by AWS Glue Data Catalog) and made available through a searchable data portal for use by other data and business intelligence teams.
Integrations With Existing Data Stores
Most enterprises don't start with data lakes. You probably started with a few relational databases, grew to multiple siloed databases, and scaled up to data marts and data warehouses. It's impractical and expensive to migrate your existing line-of-business applications to read directly from a data lake. Future applications too may prefer to use specialized databases.
A data lake architecture should support interfaces to pull data from all your existing and future data stores.
For example, Nasdaq stores billions of equities-related data records every day in their data lake. They combine this raw data with existing data in their Redshift warehouse using a data integration service like Redshift Spectrum to provide their data analysts with a unified SQL query layer over all their data.
Data Lake Governance
Data lake governance are policies that govern data quality, metadata quality, data discoverability, data access control, data security, data privacy, and regulatory compliance. Well-defined policies and systematic workflows are essential to avoid turning it into a messy data swamp.
The scalability of every architectural layer, every component, and every technology is crucial to store, search, and run analytics on these petabyte-sized data lakes.
For Nielsen, a global media and advertising metrics company with thousands of customers around the world, managing 30-petabyte data lakes without any availability and latency problems requires frictionless scalability.
The principle that business insights can come from anywhere anytime implies that data lake storage has to remain resilient across space and time over the lifetime of an enterprise. Storage redundancies, disaster recovery workflows, longevity, business continuity planning, and geographical redundancies are all essential for long-term data preservation.
Sysco, a global food service distribution company, follows this principle by hosting their data lakes on multiple geographically distributed, redundant storage services like Amazon S3 and S3 Glacier.
Machine Learning and Data Analytics
Machine learning, data analytics, and business analytics are the creative approaches that can discover business insights from your data. A data lake's architecture should enable running machine learning and data analytic workloads without governance and performance challenges. It should provide interfaces to import data for processing and to add newly generated data, including machine learning models.
Mueller, a manufacturer of water distribution products for municipalities, collects sensor data from their water supply networks in a data lake. Their data scientists apply machine learning models for pipe leak event detection using a service like SageMaker that is tightly integrated with the data lake’s storage interfaces for minimum governance hurdles and maximum performance.
Data security and data privacy present major challenges in data lake implementations. Regulations and societal attitudes over security and privacy may change over time, requiring data lakes to catch up. Your data lakes are prime attack targets because they may contain data profiles of thousands of people and organizations gathered over long periods of time. Robust data governance and security policies are absolutely essential for data lakes.
At the same time, the main idea of a data lake is to foster a culture of data creativity to discover business insights. Your security policies should not be so restrictive that this goal is missed.
Capital One, a large digital bank, migrated its entire data lake infrastructure to the cloud while following all data security protocols required by banking regulators. Despite their precautions, an employee of their cloud provider managed to breach their protections and obtained sensitive financial data of some 100 million customers that resulted in a $80 million fine on the bank. The incident is a cautionary tale about the importance of the security policies of both your company and your providers.
Data Lake Components
With these foundational and architectural principles in place, we can explore different architectural approaches and the components that constitute them.
Data Lake Catalogs
Catalogs are essential components for self-serviceability and governance of your data lake.
They should support:
APIs to add and remove data packages programmatically
Graphical user interface for managing and searching data packages
Automated cataloging of data packages by inferring field types
Provide unified views across geographically separated data lakes
Data Lake Zones
Placing your diverse employee roles under a single set of governance policies may hamper their creativity. Data science can be a repetitive trial-and-error process that produces many intermediate datasets. Applying strict data quality rules to these intermediate datasets would be laborious and discourage creative experiments.
Zones are an intuitive way of solving this. Multiple zones can be created for each kind of task:
A raw zone for all raw data that your data scientists and machine learning engineers can use
A sandbox zone for data science experiments that your data scientists and machine learning engineers can use
A production zone for processed data of a similar quality to ETL data from a data warehouse that is suitable for your business analysts
A sensitive zone for data that requires higher levels of security and privacy
Each zone will have different governance policies optimized for its respective target users.
The governance layer is critical for administering your data lake and preventing it from turning into a swamp. It supports workflows for:
Requesting, granting, and revoking access to data packages
Enforcing privacy and de-identification of data
Regulatory and data sovereignty compliance
Managing security permissions
Data Storage Layer
The storage layer stores all data under scalability, resilience, availability, and security guarantees. A distributed object store like S3 or Ceph, thanks to its versatility and simplicity, is often preferred over a filesystem or database. The storage layer has interfaces for data ingestion, addition, versioning, deletion, and transfer.
Performance is better when your machine learning and analytics operations are run as close as possible to the data, preferably in the same network, to reduce data transfer delays.
A data lake can optionally contain an analytics layer that:
Supports interfaces to ingest data
Provides SQL, NoSQL, or filesystem views over the underlying data
Supports interfaces to create and run machine learning models
Supports interfaces to create and run data analytics and visualizations
Data Lake Deployments
Deployment architecture decides where to host your data lake in a way that satisfies all architectural principles.
Data Lake in the Cloud
Cloud services like Amazon AWS, Microsoft Azure, and Google Cloud have emerged as preferred deployment choices for these reasons:
Tightly integrated and tested components: No problems due to version incompatibilities
Scalability, availability, and resilience track record: Large enterprises already host their data lakes and data warehouses on these services
Infrastructure expertise: No need for hiring in-house expertise, which is especially attractive if you’re a startup or SMB who cannot afford expert talent on demand
Pay only for used resources: No risk of buying unnecessary hardware only to leave it unused
Ready-to-use services: For security and governance
Quality of service guarantees: Through service level agreements
Customer support: Enterprises prefer somebody they can talk to
Logical or Virtual Data Lakes
A logical or virtual data lake is a lake-like unified interface over multiple physical data lakes.
Redundancy, performance, or regulatory compliance can require multiple data lake deployments in different locations. The cataloging and governance components coordinate between them to provide a unified interface to your analysts and data scientists.
On-Premises Data Lakes
Cloud deployments on platforms like Google Cloud, Azure, and AWS have their benefits but you may prefer hosting your data lakes entirely on-prem in your own data centers for business, security, or regulatory reasons.
On-prem deployments come with huge capital and operational expenditures. First, you have to procure adequate storage, server, and networking hardware. Next, you’ll need to purchase commercial software licenses and support contracts. And finally, you’ll have to hire experienced hardware and software experts to run them.
For these reasons, only the largest enterprises prefer this capital-intensive deployment approach.
Let's look at some cloud and open-source data lake solutions we use to realize these architectures.
Amazon Web Services
We use these services to build data lakes on the AWS cloud:
AWS Lake Formation: Governance, administration, security, and coordination services
AWS Glue: Data lake catalog service
Amazon S3: Scalable redundant object store is the storage layer
Amazon EMR: Run analytics
Amazon Athena: SQL query service for business analysts
Amazon Redshift: Data warehouse service for exporting data to the lake and importing data from it
Amazon SageMaker: Machine learning models
A disadvantage of AWS is that AWS Glue is limited to cataloging only data lakes hosted on AWS. As a result, multi-cloud or hybrid virtual data lakes are more complex to deploy on AWS.
We use these services to build data lakes on the Azure cloud:
Azure Purview: Provides a unified data governance layer
Data Lake Store: Serves as the storage layer
Data Catalog: Implements a data lake cataloging service
Data Lake Analytics: Runs batch and streaming analytics
Google Cloud is less feature-rich compared to AWS or Azure when building data lakes. We use the following services:
Cloud Storage: Serves as the storage layer
Dataflow: Exposes interfaces for batch and streaming data ingestion
Google Data Catalog: Implements a cataloging service
Dataproc: Runs analytics
BigQuery: Provides SQL query service for business analysts
Data Studio: Supports visualization for business analysts
Snowflake is an independent data management platform in the cloud that provides an ecosystem of data lake, warehouse, and analytics services. Unlike the other cloud services, they focus only on data management and tightly integrate their services with one another to achieve a high quality of service.
On-premises deployments tend to use the following open source technologies:
Apache Atlas: Data governance and cataloging software
Apache HDFS: Distributed file system as a storage layer
Ceph: Distributed object store as a storage layer
Apache Hadoop: Analytics for batch data
Apache Spark: Analytics for batch and streaming data
Apache Storm: Analytics for streaming data
Apache Hive: SQL view over Hadoop
Since each of these is a complex system in itself, a tightly integrated stack like Cloudera is strongly preferred.
Build Your Enterprise Data Lake With Width.ai
Data lakes are complex because they have to preserve data for the long term. They have several subsystems that require careful thought even when using cloud services. Every decision has to be evaluated against the essential principles underlying data lakes. But the insights they can deliver can propel your startup, SMB, or enterprise to new heights.
Contact us to learn how we can help you build your data lakes.
Stay up to date with the world of machine learning & ai
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Ai & machine learning consulting company focused on increasing revenue for clients. We specialize in data science and deep learning development that give businesses a better understanding of their revenue streams and building tools to make them more profitable.