Data Lake Plumbers: Operationalizing the Data Lake
Gain insight into data lakes, their benefits, when they are appropriate, and how to operationalize them. How do they compare to the data warehouse?
Many of my blogs promote the business benefits of the data lake, both from a “save me more money” as well as the “make me more money” perspectives. But I fear that I’m making this thing called the data lake sound like a “silver bullet[1]” – just drop the data into the data lake and everything magically works. But much like in the world of data warehousing, there is significant work that needs to be done under the covers – in areas such as metadata management, data governance and security – to ensure that the data lake will perform for a business in a production environment. Many of the processes and techniques we learned in the data warehouse will benefit us here, though there are many new tools to be aware of that can help us in the operationalization task.
I’ve asked an industry expert in metadata management and data governance, Joe DosSantos (follow Joe on twitter: @JoeDosSantos) to co-author this blog with me. Well, to be honest, this mostly reflects Joe’s experience and thinking; I just wanted to get credit for being smart enough to know when to bring someone smarter than me into the conversation!
Data Lake Benefits
You know from previous blogs that there are many benefits to the data lake including:
- Capture data from wide range of traditional (operational, transactional) and new sources (structured and unstructured) as-is
- Store all your data in one environment for cross-functional business analysis
- Support the analytics and data science to uncover new customer, product, and operational insights
- Empower front-line employees and managers, and drive a more profitable customer engagement leveraging customer, product and operational insights
- Integrate analytic insights into operational (Finance, Manufacturing, Marketing, Sales Force, Procurement, Logistics) and management systems (Business Intelligence reports and dashboards)
The data lake is ideal for your data science team in that it liberates them from the constraints and limitations of the data warehouse, enabling the data science team to quickly ingest, test and determine if there is any value to different data sets and analytic techniques without having to go through the rigorous operational procedures that govern the data warehouse.
However, this liberty can be quite terrifying in highly regulated environments. Companies have spent years developing governance and stewardship organizations specifically to control patient information, personal contact information, account balances, and other sensitive information. The description above seems to undo all of this work by creating free and easy access to data that should be locked down.
This is why the controls of a data lake need to be very clear. Data that is onboarded into a lake must go through a rigorous set of operational procedures to manage and govern that data set to make sure that it is appropriately tagged and protected, and then provisioned only to people who have the proper authorization. Modern data tools allow for this kind of governance capability to balance the quick and easy access to data that a data scientist needs with the security that good practices (and often the government) demand.
Operationalizing the Data Lake
Operationalizing the data lake requires several non-obvious disciplines, many of which we learned from our data warehouse experiences. These disciplines include data ingestion, indexing, cataloging, metadata management, data governance and security[2].
As with a data warehouse, you will need a method to bring data into your environment. As batch windows became longer and longer in the data warehouse world and business users clamored for increasingly up-to-date information, practitioners began shifting from conventional data ETL (Extract, Transform, Load) to lower latency streaming and micro-batch. This trend was extended in the big data universe with tools like Kafka, a streaming message bus, and with Spring and Sqoop to accelerate data ingest. In the big data world, you might also want to ingest unstructured data sets as well, introducing new tools like Flume. Finally, you may want to trigger complex events based on this data stream and you might do so via Spark, Gemfire, or other in-memory grids. And just to make it more complex, you will likely use several of these tools in combination depending on your data feed needs. Keep in mind that in the world of ELT (Extract, Load, Transform) (note that the order differs from E-T-L), most of these data movements are data dumps. At this point, you have simply collected lots of raw data. It’s now time to make sense of it.
Next, it is useful to tag files that you have ingested. What kind of file is this? What would be useful to know about it so that I could search for it later? Zaloni Bedrock is an example of a tool to apply metadata tags to the files, which is useful for both structured and unstructured data sets.
We mentioned above that one of the key requirements of our data lake is having control over who can have access to specific data sources. Generally speaking, the data loaded in steps 1 and 2 is what we call “Bronze” data, meaning that it is good enough for the business process that created it. Data in these sets will likely be sensitive and your security should reflect it. However, we need to determine rules for how the data should be modified, obfuscated, or deleted in order to make it consumable for broader audience, or what we might call “Silver” status. You need to create business rules to manage data (e.g. birthdays should be masked and social security numbers should be stored as only the last 4). Collibra is an example of a tool for this rules definition and management. It allows data rules to be set up based on logical business entities by business people rather than technologists.
For those people who are familiar with governance concepts, you will recognize the difference between a policy and a control. A policy is like a speed limit sign along the highway. The control is the police officer that pulls you over if you are driving over that speed limit. Data works the same way. While Collibra establishes the policy, you need to create a method for enforcing that policy. To do this, you need to find the logical entities buried in the data (i.e. “oh look, I found a social security number!”). Examples of such products include Global IDs for scanning structured data sets with the operational systems and Waterline for scanning data inside of Hadoop.
Once you have found the data that you want, you want to implement the rules. For this, there is an open source tool called Atlas that contains an orchestration capability called Falcon that helps implement the rules.
- Apache Atlas is a scalable and extensible set of core foundational governance services that enables enterprises to effectively and efficiently meet their compliance requirements within Hadoop and allows integration with the complete enterprise data ecosystem.
- Apache Falcon is a data governance engine that defines, schedules, and monitors data management policies. Falcon allows Hadoop administrators to centrally define their data pipelines, and then Falcon uses those definitions to auto-generate workflows in Apache Oozie
Now that the data is loaded, you will want to enforce security through your LDAP capability or possibly through Kerberos. There are also tools like Blue Talon that simplify the ability to authorize, provision, protect, enforce and audit data security policies across your data lake.
Finally, audit controls are critical. Cloudera introduced Navigator specifically to allow simple transparency to data history and lineage. Hortonworks will rely on Atlas to provide this capability.
Data that has gone through the above processes creates a view and accessibility of the data that can be made available to a wide set of users – both business analysts and data science teams.
Summary
When you build a house, the vast majority of the creative work is in the features and curbside appeal. That’s the fun part. But without the underlying plumbing, the house would quickly degrade into a money pit.
Consider the metaphor of a retail store: stocking the shelves vs. purchasing goods. When you go to the store, you don’t care about how the goods got there, but the rules for accessing the goods are everywhere. Cigarettes are behind the front desk. Pharmaceuticals must be dispensed with a prescription. Razor blades are under lock and key (for some strange reason). There are policies and enforcements on stocking the shelves so that the shopping experience is clear and easy.
To successfully operationalize the data lake, organizations need to address all of the plumbing requirements outlined in this blog that enable the business users and data science teams to have confidence in the wealth of data that the organization is amassing. The data lake plumbing processes may not be very glamorous, but without them, you’ll end up with a stinky data dump instead of a glorious data lake.
[1] A “silver bullet” is a simple and seemingly magical solution to a complicated problem.
[2] While I mention several tools, this blog is not meant to be an endorsement of these tools nor is this intended to be a comprehensive list of such tools. However, many of these tools are the same tools that we use in our data lake implementations at EMC.
Bio: William (Bill) Schmarzo, the "Dean of Big Data," is the CTO of EIM Service Line at EMC. An avid blogger, Bill speaks frequently on the use and application of big data and advanced analytics to drive an organization’s key business initiatives.
Original. Reposted with permission.
Related: