Jerry Held, Michael Stonebraker, Thomas H. Davenport, Ihab Ilyas, Michael L. Brodie, Andy Palmer & James Markarian

Tackling the Challenges of Big Data Volume and Variety

Getting Data Right

Fuel your decision-making with all available data

In unifying enterprise data for

better analytics, Tamr unifies

enterprise organizations –

bringing business and IT

together on mission critical

questions and the information

needed to answer them.

unified data. optimized decisions.

This Preview Edition of Getting Data Right: Tackling the Challenges of Big Data Volume and Variety, is a work in progress. The final book is

expected in late 2015.

Jerry Held, Michael Stonebraker, Thomas H.Davenport, Ihab Ilyas, Michael L. Brodie,

Andy Palmer, and James Markarian

Getting Data RightTackling The Challenges of Big Data

Volume and Variety

978-1-491-93529-3

[LSI]

Getting Data RightJerry Held, Michael Stonebraker, Thomas H. Davenport, Ihab Ilyas, Michael L. Bro‐die, Andy Palmer, and James Markarian

Copyright © 2015 Tamr, Inc. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA95472.

O’Reilly books may be purchased for educational, business, or sales promotional use.Online editions are also available for most titles (http://safaribooksonline.com). Formore information, contact our corporate/institutional sales department:800-998-9938 or corporate@oreilly.com .

Editor: Shannon Cutt Cover Designer: Randy Comer

June 2015: First Edition

Revision History for the First Edition2015-06-17: First Release2015-08-24: Second Release2015-09-02: Third Release2015-11-09: Fourth Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Getting DataRight, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

While the publisher and the authors have used good faith efforts to ensure that theinformation and instructions contained in this work are accurate, the publisher andthe authors disclaim all responsibility for errors or omissions, including withoutlimitation responsibility for damages resulting from the use of or reliance on thiswork. Use of the information and instructions contained in this work is at your ownrisk. If any code samples or other technology this work contains or describes is sub‐ject to open source licenses or the intellectual property rights of others, it is yourresponsibility to ensure that your use thereof complies with such licenses and/orrights.

Table of Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

1. The Solution: Data Curation at Scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Three Generations of Data Integration Systems 1Five Tenets for Success 5

2. An Alternative Approach to Data Management. . . . . . . . . . . . . . . . . . 9Centralized Planning Approaches 10Common Information 10Information Chaos 11What Is to Be Done? 12Take a Federal Approach to Data Management 13Use All the New Tools at Your Disposal 14Don’t Model, Catalog 16Cataloging Tools 17Keep Everything Simple and Straightforward 18Use an Ecological Approach 19

3. Pragmatic Challenges in Building Data Cleaning Systems. . . . . . . . . 21Data Cleaning Challenges 21Building Adoptable Data Cleaning Solutions 26

4. Understanding Data Science: An Emerging Discipline for Data-Intensive Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Introduction 29Data Science: A New Discovery Paradigm That Will

Transform Our World 30

iii

Data Science: A Perspective 36Understanding Data Science From Practice 37Research For An Emerging Discipline 44

5. From DevOps to DataOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Why It’s Time to Embrace “DataOps” as a New Discipline 49From DevOps to DataOps 50Defining DataOps 51Changing the fundamental infrastructure 51DataOps Methodology 52Integrating DataOps into Your Organization 53The Four Processes of DataOps 54Better information, analytics, and decisions 57

6. Data Unification Brings Out the Best in Installed Data ManagementStrategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Positioning ETL and MDM 60Clustering to Meet the Rising Data Tide 61Embracing Data Variety with Data Unification 62Data Unification Is Additive 63Probabilistic Approach to Data Unification 65

iv | Table of Contents

Introduction

—Jerry Held

Companies have invested an estimated $3-4 trillion in IT over thelast 20-plus years, most of it directed at developing and deployingsingle-vendor and applications to automate and optimize key busi‐ness processes. And what has been the result of all of this disparateactivity? Data silos, schema proliferation, and radical data heteroge‐neity.

With companies now investing heavily in big data analytics, thisentropy is making the job considerably more complex. This com‐plexity is best seen when companies attempt to ask “simple” ques‐tions of data that is spread across many business silos (divisions,geographies or functions). Questions as simple as “Are we gettingthe best price for everything we buy?” often go unanswered becauseon their own, top-down, deterministic data unification approachesaren’t prepared to scale to the variety of hundreds, thousands, ortens of thousands of data silos.

The diversity and mutability of enterprise data and semantics shouldlead CDOs to explore — as a complement to deterministic systems— new bottom-up, probabilistic approach that connects data acrossthe organization and exploits big data variety. In managing data, weshould look for solutions that find siloed data and connect it into aunified view. “Getting Data Right” means embracing variety andtransforming it from a roadblock into ROI. Throughout this report,you’ll learn how to question conventional assumptions, and explorealternative approaches to managing big data in the enterprise.

v

Chapter 1, The Solution: Data Curation at ScaleMichael Stonebraker, 2015 A.M. Turing Award winner, arguesthat it’s impractical to try and meet today’s data integrationdemands with yesterday’s data integration approaches. Dr.Stonebraker reviews three generations of data integration prod‐ucts, and how they have evolved. He explores new third-generation products that deliver a vital missing layer in the dataintegration “stack” — data curation at scale. Dr. Stonebrakeralso highlights five key tenets of a system that can effectivelyhandle data curation at scale.

Chapter 2, An Alternative Approach to Data ManagementIn this chapter, Tom Davenport, author of Competing on Analyt‐ics and Big Data at Work proposes an alternative approach todata management. For much of the sixty years or so that organi‐zations have been managing data in electronic form, many ofthe centralized planning and architectural initiatives created arenever completed or fully implemented because of their com‐plexity. Davenport describes five approaches to realistic, effec‐tive data management in today’s enterprise.

Chapter 3, Pragmatic Challenges in Building Data Cleaning SystemsIhab Ilyas of the University of Waterloo points to “dirty, incon‐sistent data” (now the norm in today’s enterprise) as the reasonwe need new solutions for quality data analytics and retrieval onlarge-scale databases. Dr. Ilyas approaches this issue as a theo‐retical and engineering problem, and breaks it down into sev‐eral pragmatic challenges. He explores a series of principles thatwill help enterprises develop and deploy data cleaning solutionsat scale.

Chapter 4, Understanding Data Science: An Emerging Discipline forData Intensive Discovery

Michael Brodie, Research Scientist at MIT’s Computer Scienceand Artificial Intelligence Laboratory, is devoted to understand‐ing data science as an emerging discipline for data-intensiveanalytics. He explores data science as a basis for the FourthParadigm of engineering and scientific discovery. Given thepotential risks and rewards of data-intensive analysis and itsbreadth of application, Dr. Brodie argues that it’s imperative weget it right. In this chapter, he summarizes his analysis of morethan 30 large-scale use cases of data science, and reveals a bodyof principles and techniques with which to measure and

vi | Introduction

improve the correctness, completeness, and efficiency of data-intensive analysis.

Chapter 5, From DevOps to DataOpsTamr Co-Founder and CEO, Andy Palmer argues in support of“DataOps” as a new discipline – echoing the emergence of“DevOps”, which has improved the velocity, quality, predictabil‐ity and scale of software engineering and deployment. Palmerdefines and explains DataOps, and offers specific recommenda‐tions for integrating it into today’s enterprises.

Chapter 6, Data Unication Brings Out the Best in Installed Data Man‐agement Strategies

Former Informatica CTO James Markarian looks at current datamanagement techniques such as Extract, Transform, Load(ETL); Master Data Management (MDM); and data lakes. Whilethese technologies can provide a unique and significant handleon data, Markarian argues that they are still challenged in termsof speed and scalability. Markarian explores adding data unifi‐cation as a front-end strategy to quicken the feed of highlyorganized data. He also reviews how data unification works withinstalled data management solutions — allowing businesses toembrace data volume and variety for more productive dataanalysis.

Introduction | vii

CHAPTER 1

The Solution: Data Curation atScale

—Michael Stonebraker, Ph.D.

Integrating data sources isn’t a new challenge. But the challenge hasintensified in both importance and difficulty, as the volume andvariety of usable data - and enterprises’ ambitious plans for analyz‐ing and applying it - have increased. As a result, trying to meettoday’s data integration demands with yesterday’s data integrationapproaches is impractical.

In this chapter, we look at the three generations of data integrationproducts and how they have evolved. We look at new third-generation products that deliver a vital missing layer in the dataintegration “stack”: data curation at scale. Finally, we look at five keytenets of an effective data curation at scale system.

Three Generations of Data IntegrationSystemsData integration systems emerged to enable business analysts toaccess converged data sets directly for analyses and applications.

First-generation data integration systems - data warehouses -arrived on the scene in the 1990s. Led by the major retailers,customer-facing data (e.g., item sales, products, customers) wereassembled in a data store and used by retail buyers to make betterpurchase decisions. For example, pet rocks might be out of favor

1

while Barbie dolls might be “in.” With this intelligence, retailerscould discount the pet rocks and tie up the Barbie doll factory with abig order. Data warehouses typically paid for themselves within ayear through better buying decisions.

First-generation data integration systems were termed ETL (Extract,Transform and Load) products. They were used to assemble the datafrom various sources (usually fewer than 20) into the warehouse.But enterprises underestimated the “T” part of the process - specifi‐cally, the cost of data curation (mostly, data cleaning) required to getheterogeneous data into the proper format for querying and analy‐sis. Hence, the typical data warehouse project was usually substan‐tially over-budget and late because of the difficulty of dataintegration inherent in these early systems.

This led to a second generation of ETL systems, whereby the majorETL products were extended with data cleaning modules, additionaladapters to ingest other kinds of data, and data cleaning tools. Ineffect, the ETL tools were extended to become data curation tools.

Data curation involves:

• ingesting data sources• cleaning errors from the data (-99 often means null)• transforming attributes into other ones (for example, Euros to

dollars)• performing schema integration to connect disparate data sour‐

ces• performing entity consolidation to remove duplicates

In general, data curation systems followed the architecture of earlierfirst-generation systems: toolkits oriented toward professional pro‐grammers. In other words, they were programmer productivitytools.

Second-generation data curation tools have two substantial weak‐nesses:

ScalabilityEnterprises want to curate “the long tail” of enterprise data.They have several thousand data sources, everything from com‐pany budgets in the CFO’s spreadsheets to peripheral opera‐tional systems. There is “business intelligence gold” in the long

2 | Chapter 1: The Solution: Data Curation at Scale

tail, and enterprises wish to capture it - for example, for cross-selling of enterprise products. Furthermore, the rise of publicdata on the web leads business analysts to want to curate addi‐tional data sources. Anything from weather data to customsrecords to real estate transactions to political campaign contri‐butions are readily available. However, in order to capture long-tail enterprise data as well as public data, curation tools must beable to deal with hundreds to thousands of data sources ratherthan the typical few tens of data sources.

ArchitectureSecond-generation tools typically are designed for central ITdepartments. A professional programmer does not know theanswers to many of the data curation questions that arise. Forexample, are “rubber gloves” the same thing as “latex hand pro‐tectors?” Is an “ICU50” the same kind of object as an “ICU?”Only business people in line-of-business organizations cananswer these kinds of questions. However, business people areusually not in the same organization as the programmers run‐ning data curation projects. As such, second-generation systemsare not architected to take advantage of the humans best able toprovide curation help.

These weaknesses led to a third generation of data curation prod‐ucts, which we term scalable data curation systems. Any data cura‐tion system should be capable of performing the five tasks notedabove. However, first- and second-generation ETL products willonly scale to a small number of data sources, because of the amountof human intervention required.

To scale to hundreds or even thousands of data sources, a newapproach is needed - one that:

1. Uses statistics and machine learning to make automatic deci‐sions wherever possible.

2. Asks a human expert for help only when necessary.

Instead of an architecture with a human controlling the process withcomputer assistance, move to an architecture with the computerrunning an automatic process, asking a human for help only whenrequired. And ask the right human: the data creator or owner (abusiness expert) not the data wrangler (a programmer).

Three Generations of Data Integration Systems | 3

Obviously, enterprises differ in the required accuracy of curation, sothird-generation systems must allow an enterprise to make tradeoffsbetween accuracy and the amount of human involvement. In addi‐tion, third-generation systems must contain a crowdsourcing com‐ponent that makes it efficient for business experts to assist withcuration decisions. Unlike Amazon’s Mechanical Turk, however, adata-curation crowdsourcing model must be able to accommodate ahierarchy of experts inside an enterprise as well as various kinds ofexpertise. Therefore, we call this component an expert sourcing sys‐tem to distinguish it from the more primitive crowdsourcing sys‐tems.

In short: a third-generation data curation product is an automatedsystem with an expert sourcing component. Tamr is an early exam‐ple of this third generation of systems.

Third-generation systems can co-exist with currently-in-placesecond-generation systems, which can curate the first tens of datasources to generate a composite result that in turn can be curatedwith the “long tail” by third-generation systems.

Table 1-1. Evolution of Three Generations of Data Integration Systems

First Generation1990s

Second Generation2000s

Third Generation 2010s

Approach ETL ETL+>Data Curation Scalable Data Curation

Target DataEnvironment(s)

Data Warehouse Data Warehouses or DataMarts

Data Lakes & Self-ServiceData Analytics

Users IT/Programmers IT/Programmers Data Scientists, DataStewards, Data Owners,Business Analysts

IntegrationPhilosophy

Top-down/rules-based/IT-driven

Top-down/rules-based/IT-driven

Bottom-up/demand-based/business-driven

Architecture Programmerproductivity tools(task automation)

Programmingproductivity tools (taskautomation withmachine assistance)

Machine-driven, human-guided process

Scalability (# ofdata sources)

10s 10s to 100s 100s to 1000s+

4 | Chapter 1: The Solution: Data Curation at Scale

To summarize: ETL systems arose to deal with the transformationchallenges in early data warehouses. They evolved into second-generation data curation systems with an expanded scope of offer‐ings. Third-generation data curation systems, which have a verydifferent architecture, were created to address the enterprise’s needfor data source scalability.

Five Tenets for SuccessThird-generation scalable data curation systems provide the archi‐tecture, automated workflow, interfaces and APIs for data curationat scale. Beyond this basic foundation, however, are five tenets thatare desirable in any third-generation system.

Tenet 1: Data curation is never doneBusiness analysts and data scientists have an insatiable appetite formore data. This was brought home to me about a decade ago duringa visit to a beer company in Milwaukee. They had a fairly standarddata warehouse of sales of beer by distributor, time period, brandand so on. I visited during a year when El Niño was forecast to dis‐rupt winter weather in the US. Specifically, it was forecast to be wet‐ter than normal on the West Coast and warmer than normal in NewEngland. I asked the business analysts: “Are beer sales correlatedwith either temperature or precipitation?” They replied, “We don’tknow, but that is a question we would like to ask.” However temper‐ature and precipitation were not in the data warehouse, so askingwas not an option.

The demand from warehouse users to correlate more and more dataelements for business value leads to additional data curation tasks.Moreover, whenever a company makes an acquisition, it creates adata curation problem (digesting the acquired’s data). Lastly, thetreasure trove of public data on the web (such as temperature andprecipitation data) is largely untapped, leading to more curationchallenges.

Even without new data sources, the collection of existing data sour‐ces is rarely static. Hence, inserts and deletes to these sources gener‐ates a pipeline of incremental updates to a data curation system.Between the requirements of new data sources and updates to exist‐ing ones, it is obvious that data curation is never done, ensuring that

Five Tenets for Success | 5

any project in this area will effectively continue indefinitely. Realizethis and plan accordingly.

One obvious consequence of this tenet concerns consultants. If youhire an outside service to perform data curation for you, then youwill have to rehire them for each additional task. This will give theconsultant a guided tour through your wallet over time. In my opin‐ion, you are much better off developing in-house curation compe‐tence over time.

Tenet 2: A PhD in AI can’t be a requirement for successAny third-generation system will use statistics and machine learningto make automatic or semi-automatic curation decisions. Inevitably,it will use sophisticated techniques such as T-tests, regression, pre‐dictive modeling, data clustering, and classification. Many of thesetechniques will entail training data to set internal parameters. Sev‐eral will also generate recall and/or precision estimates.

These are all techniques understood by data scientists. However,there will be a shortage of such people for the foreseeable future,until colleges and universities produce substantially more than atpresent. Also, it is not obvious that one can “retread” a business ana‐lyst into a data scientist. A business analyst only needs to under‐stand the output of SQL aggregates; in contrast, a data scientist istypically knowledgeable in statistics and various modeling techni‐ques.

As a result, most enterprises will be lacking in data science expertise.Therefore, any third-generation data curation product must usethese techniques internally, but not expose them in the user inter‐face. Mere mortals must be able to use scalable data curation prod‐ucts.

Tenet 3: Fully automatic data curation is not likely to besuccessfulSome data curation products expect to run fully automatically. Inother words, they translate input data sets into output withouthuman intervention. Fully automatic operation is very unlikely to besuccessful in an enterprise for a variety of reasons. First, there arecuration decisions that simply cannot be made automatically. Forexample, consider two records; one stating that restaurant X is at

6 | Chapter 1: The Solution: Data Curation at Scale

location Y while the second states that restaurant Z is at location Y.This could be a case where one restaurant went out of business andgot replaced by a second one or it could be a food court. There is nogood way to know the answer to this question without human guid‐ance.

Second, there are cases where data curation must have high reliabil‐ity. Certainly, consolidating medical records should not createerrors. In such cases, one wants a human to check all (or maybe justsome) of the automatic decisions. Third, there are situations wherespecialized knowledge is required for data curation. For example, ina genomics application one might have two terms: ICU50 andICE50. An automatic system might suggest that these are the samething, since the lexical distance between the terms is low. However,only a human genomics specialist can decide this question.

For these reasons, any third-generation data curation system mustbe able to ask a human expert - the right human expert - when it isunsure of the answer. Therefore, one must have multiple domains inwhich a human can be an expert. Within a single domain, humanshave a variable amount of expertise, from a novice level to enterpriseexpert. Lastly, one must avoid overloading the humans that it isscheduling. Therefore, when considering a third generation datacuration system, look for an embedded expert system with levels ofexpertise, load balancing and multiple expert domains.

Tenet 4: Data curation must fit into the enterpriseecosystemEvery enterprise has a computing infrastructure in place. Thisincludes a collection of DBMSs storing enterprise data, a collectionof application servers and networking systems, and a set of installedtools and applications. Any new data curation system must fit intothis existing infrastructure. For example, it must be able to extractfrom corporate databases, use legacy data cleaning tools, and exportdata to legacy data systems. Hence, an open environment is requiredwhereby callouts are available to existing systems. In addition,adapters to common input and export formats is a requirement. Donot use a curation system that is a closed ”black box.”

Five Tenets for Success | 7

Tenet 5: A scheme for “finding” data sources must bepresentA typical question to ask CIOs is “How many operational data sys‐tems do you have?”. In all likelihood, they do not know. The enter‐prise is a sea of such data systems connected by a hodgepodge set ofconnectors. Moreover, there are all sorts of personal datasets,spreadsheets and databases, as well as datasets imported from publicweb-oriented sources. Clearly, CIOs should have a mechanism foridentifying data resources that they wish to have curated. Such a sys‐tem must contain a data source catalog with information on a CIO’sdata resources, as well as a query system for accessing this catalog.Lastly, an “enterprise crawler” is required to search a corporateinternet to locate relevant data sources. Collectively, this represents aschema for “finding” enterprise data sources.

Collectively, these five tenets indicate the characteristics of a goodthird generation data curation system. If you are in the market forsuch a product, then look for systems with these characteristics.

8 | Chapter 1: The Solution: Data Curation at Scale

CHAPTER 2

An Alternative Approach to DataManagement

—Thomas H. Davenport

For much of the sixty years or so that organizations have been man‐aging data in electronic form, there has been an overpowering desireto subdue it through centralized planning and architectural initia‐tives.

These initiatives have had a variety of names over the years, includ‐ing the most familiar: “information architecture,” “information engi‐neering,” and “master data management”. These initiatives have allhad certain key attributes and beliefs in common:

• Data needs to be centrally-controlled• Modeling is an approach to controlling data• Abstraction is a key to successful modeling• An organization’s information should all be defined in a com‐

mon fashion• Priority is on efficiency in information storage (a given data ele‐

ment should only be stored once)• Politics, ego, and other common human behaviors are irrelevant

to data management (or at least not something that organiza‐tions should attempt to manage)

Each of these attributes has at least a grain of truth in it, but takentogether and to their full extent, I have come to believe that they

9

simply don’t work. I rarely find business users who believe theywork either, and this dissatisfaction has been brewing for a longtime. For example, in the 1990s I interviewed a marketing managerat Xerox Corporation who had also spent some time in IT at thesame company. He explained that the company had “tried informa‐tion architecture” for 25 years, but got nowhere — they alwaysthought they were doing it incorrectly.

Centralized Planning ApproachesMost organizations have had similar results from their centralizedarchitecture and planning approaches.

Not only do centralized planning approaches waste time and money,they also drive a wedge between those who are planning them, andthose who will actually use the information and technology. Regula‐tory submissions, abstract meetings, and incongruous goals can leadto months of frustration, without results.

The complexity and detail of centralized planning approaches oftenmean that they are frequently never completed, and when they arefinished, managers often decide not to implement them. The resour‐ces devoted to central data planning are often redeployed into otherIT projects of more tangible value. If by chance they are imple‐mented, they are hopelessly out of date by the time they go intoeffect.

For one illustration of how the key tenets of centralized informationplanning are not consistent with real organizational behavior, let’slook at one: the assumption that all information needs to be com‐mon.

Common InformationCommon information—agreement within an organization on howto define and use key data elements—is a useful thing, to be sure.But it’s also helpful to know that uncommon information—informa‐tion definitions that suit the purposes of a particular group or indi‐vidual—can also be useful to a particular business function, unit, orwork group. Companies need to strike a balance between these twodesirable goals.

10 | Chapter 2: An Alternative Approach to Data Management

After speaking with many managers and professionals about com‐mon information, and reflecting on the subject carefully, I formula‐ted “Davenport’s Law of Common Information” (you can Google it,but don’t expect a lot of results). If by some strange chance youhaven’t heard of Davenport’s Law, it goes like this:

The more an organization knows or cares about a particular busi‐ness entity, the less likely it is to agree on a common term andmeaning for it.

I first noticed this paradoxical observation at American Airlinesmore than a decade ago. They told me during a research visit thatthey had eleven different usages of the term “airport.” As a frequenttraveler on their planes, I was initially a bit concerned about this,but when they explained it, the proliferation of meanings madesense. They said that the cargo workers at American Airlines viewedanyplace you can pick up or drop off cargo as the airport; the main‐tenance people viewed anyplace you can fix an airplane as the air‐port; the people who worked with the International Air TransportAuthority relied on their list of international airports, and so on.

The next week I was doing some consulting work at Union PacificRailroad, where they sheepishly admitted at some point during myvisit that they had great debates about what constitutes a “train.” Forsome, it’s an abstract scheduling entity; for others it’s the locomotive;for others it’s the locomotive and whatever railcars it’s pulling at thetime. By an amazing twist of fate shortly thereafter, I visited the U.S.Department of Justice; they were going through an informationmodeling exercise, and ran into a roadblock in creating a commondefinition of “trial.”

Information ChaosSo just like Newton being hit on the head with an apple and discov‐ering gravity, the key elements of Davenport’s Law hit me like abrick. This was why organizations were having so many problemscreating consensus around key information elements. I also formu‐lated a few corollaries to the law, such as:

If you’re not arguing about what constitutes a “customer,” yourorganization is probably not very passionate about customers.

Davenport’s Law, in my humble opinion, makes it much easier tounderstand why companies all over the world have difficulty estab‐

Information Chaos | 11

lishing common definitions of key terms around their organiza‐tions.

Of course, this should not be an excuse for organizations to allowalternative meanings of key terms to proliferate. Even though thereis a good reason for why they proliferate, organizations may have tolimit—sometimes even stop—the proliferation of meanings andagree on one meaning for each term. Otherwise they will continueto find that when the CEO asks multiple people how many employ‐ees a company has, he/she will get different answers. The prolifera‐tion of meanings, however justifiable, leads to information chaos.

But Davenport’s Law offers one more useful corollary about how tostop the proliferation of meanings. Here it is:

A manager’s passion for a particular definition of a term will not bequenched by a data model specifying an alternative definition.

If a manager has a valid reason to prefer a particular meaning of aterm, he or she is unlikely to be persuaded to abandon it by a com‐plex, abstract data model that is difficult to understand in the firstplace, and is likely never to be implemented.

Is there a better way to get adherence to a single definition of aterm?

Here’s one final corollary:Consensus on the meaning of a term throughout an organization isachieved not by data architecture, but by data arguing.

Data modeling doesn’t often lead to dialog because it’s simply notcomprehensible to most nontechnical people. If people don’t under‐stand your data architecture, it won’t stop the proliferation of mean‐ings.

What Is to Be Done?There is little doubt that something needs to be done to make dataintegration and management easier. In my research, I’ve conductedmore than 25 extended interviews with data scientists about whatthey do, and how they go about their jobs. I concluded that a moreappropriate title for data scientists might actually be “data plumber.”It is often so difficult to extract, clean, and integrate data that datascientists can spend up to 90% of their jobs doing those tasks. It’s nowonder that big data often involves “small math”—after all the prep‐

12 | Chapter 2: An Alternative Approach to Data Management

aration work, there isn’t enough time left to do sophisticated analyt‐ics.

This is not a new problem in data analysis. The dirty little secret ofthe field is that someone has always had to do a lot of data prepara‐tion before the data can be analyzed. The problem with Big Data ispartly that there is a large volume of it, but mostly that we are oftentrying to integrate multiple sources. Combining multiple data sour‐ces means that for each source we have to determine how to clean,format, and integrate it. The more sources and types of data, themore plumbing work is required.

So let’s assume that data integration and management are necessaryevils. But what particular approaches to them are most effective?Throughout the remainder of this chapter, I’ll describe fiveapproaches to realistic, effective data management, including:

1. Taking a federal approach to data management2. Using all of the new tools at your disposal3. Don’t model, catalog4. Keep everything simple and straightforward5. Use an ecological approach

Take a Federal Approach to Data ManagementFederal political models—of which the United States is one example—don’t try to get consensus on every issue. They have some lawsthat are common throughout the country, and some that are allowedto vary from state-to-state or by region or city. It’s a hybrid approachto the centralization/decentralization issue that bedevils many largeorganizations. Its strength is its practicality, in that it’s easier to getconsensus on some issues than on all of them. If there is a downsideto federalism, it’s that there is usually a lot of debate and discussionabout which rights are federal, and which are states’ or other units’rights. The United States has been arguing about this issue for morethan 200 years.

While federalism does have some inefficiencies, it’s a good model fordata management. It means that some data should be defined com‐monly across the entire organization, and some should be allowed tovary. Some should have a lot of protections, and some should be rel‐

Take a Federal Approach to Data Management | 13

atively open. That will reduce the overall effort to manage data, sim‐ply because not everything will have to be tightly-managed.

Your organization will, however, have to engage in some “data argu‐ing.” Hashing things out around a table is the best way to resolve keyissues in a federal data approach. You will have to argue about whichdata should be governed by corporate rights, and which will beallowed to vary. Once you have identified corporate data, you’ll thenhave to argue about how to deal with it. But I have found that ifmanagers feel that their issues have been fairly aired, they are morelikely to comply with a policy that goes against those issues.

Use All the New Tools at Your DisposalWe now have a lot of powerful tools for processing and analyzingdata, but we haven’t had them for cleaning, integrating, and “curat‐ing” data. (“Curating” is a term often used by librarians, and thereare typically many of them in pharmaceutical firms who manage sci‐entific literature). These tools are sorely needed and are beginningto emerge. One source I’m close to is a startup called Tamr, whichaims to help “tame” your data using a combination of machinelearning and crowdsourcing. Tamr isn’t the only new tool for this setof activities, and I am an advisor to the company. So I would adviseyou to do your own investigation. The founders of Tamr are AndyPalmer and Michael Stonebraker. Palmer is a serial entrepreneurand incubator founder in the Boston area.

Stonebraker is the database architect behind INGRES, Vertica,VoltDB, Paradigm4, and a number of other database tools. He’s alsoa longtime computer science professor, now at MIT. As noted in hischapter of this book, we have a common view of how well-centralized information architecture approaches work in largeorganizations.

In a research paper published in 2013, Stonebraker and several co-authors wrote that they tested “Data-Tamer” (as it was then known)in three separate organizations. They found that the tool reducedthe cost of data curation in those organizations by about 90%.

I like the idea that Tamr uses two separate approaches to solving theproblem. If the data problem is somewhat repetitive and predictable,the machine learning approach will develop an algorithm that willdo the necessary curation. If the problem is a bit more ambiguous,

14 | Chapter 2: An Alternative Approach to Data Management

the crowdsourcing approach can ask people who are familiar withthe data (typically the owner of that data source) to weigh in on itsquality and other attributes. Obviously the machine learningapproach is more efficient, but crowdsourcing at least spreads thelabor around to the people who are best qualified to do it. These twoapproaches are, together, more successful than the top-downapproaches that many large organizations have employed.

A few months before writing this chapter, I spoke with several man‐agers from companies who are working with Tamr. Thomson Reu‐ters is using the technology to curate “core entity master” data—creating clear and unique identities of companies and their parentsand subsidiaries. Previous in-house curation efforts, relying on ahandful of data analysts, found that 30%-60% of entities requiredmanual review. Thomson Reuters believed manual integrationwould take up to six months to complete, and would identify 95% ofduplicate matches (precision) and 95% of suggested matches thatwere, in fact, different (recall).

Thomson Reuters looked to Tamr’s machine-driven, human-guidedapproach to improve this process. After converting the company’sXML files to CSVs, Tamr ingested three core data sources—factualdata on millions of organizations with more than 5.4 millionrecords. Tamr de-duplicated the records and used “fuzzy matching”to find suggested matches, with the goal of achieving high accuracyrates, while reducing the number of records requiring review. Inorder to scale the effort and improve accuracy, Tamr appliedmachine learning algorithms to a small training set of data and fedguidance from Thomson Reuters’ experts back into the system.

The “big pharma” company Novartis has many different sources ofbiomedical data that it employs in research processes, making cura‐tion difficult. Mark Schreiber, then an “informatician” at NovartisInstitutes for Biomedical Research (he has since moved to Merck),oversaw the testing of Tamr going all the way back to its academicroots at MIT. He is particularly interested in the tool’s crowdsourc‐ing capabilities, as he wrote in a blog post:

“The approach used gives you a critical piece of the workflowbridging the gap between the machine learning/automated dataimprovement and the curator. When the curator isn’t confident inthe prediction or their own expertise, they can distribute tasks toyour data producers and consumers to ask their opinions and draw

Use All the New Tools at Your Disposal | 15

on their expertise and institutional memory, which is not stored inany of your data systems.”

I also spoke with Tim Kasbe, the COO of Gloria Jeans, which is thelargest “fast fashion” retailer in Russia and Ukraine. Gloria Jeans hastried out Tamr on several different data problems, and found it par‐ticularly useful for identifying and removing duplicate loyalty pro‐gram records. Here are some results from that project:

We loaded data for about 100,000 people and families and ran ouralgorithms on them and found about 5,000 duplicated entries. Aportion of these represented people or families that had signed upfor multiple discount cards. In some cases, the discount cards hadbeen acquired in different locations or different contact informa‐tion had been used to acquire them. The whole process took aboutan hour and did not need deep technical staff due to the simple andelegant Tamr user experience. Getting to trustworthy data to makegood and timely decisions is a huge challenge this tool will solve forus, which we have now unleashed on all our customer referencedata, both inside and outside the four walls of our company.

I am encouraged by these reports that we are on the verge of abreakthrough in this domain. Don’t take my word for it—do a proofof concept with one of these types of tools.

Don’t Model, CatalogOne of the paradoxes of IT planning and architecture is that thoseactivities have made it more difficult for people to find the data theyneed to do their work. According to Gartner, much of the roughly$3-4 trillion invested in enterprise software over the last 20 years hasgone toward building and deploying software systems and applica‐tions to automate and optimize key business processes in the con‐text of specific functions (sales, marketing, manufacturing) and/orgeographies (countries, regions, states, etc.). As each of these idio‐syncratic applications is deployed, an equally idiosyncratic datasource is created. The result is that data is extremely heterogeneousand siloed within organizations.

For generations, companies have created “data models,” “master datamodels,” and “data architectures” that lay out the types, locations,and relationships for all the data that they had have now and willhave in the future. Of course, those models rarely get implementedexactly as planned, given the time and cost involved. As a result,organizations have no guide to what data they actually have in the

16 | Chapter 2: An Alternative Approach to Data Management

present and how to find it. Instead of creating a data model, theyshould create a catalog of their data—a straightforward listing ofwhat data exists in the organization, where it resides, who’s responsi‐ble for it, and so forth.

One other reason why companies don’t create simple catalogs oftheir data is that the result is often somewhat embarrassing and irra‐tional. Data are often duplicated many times across the organiza‐tion. Different data are referred to by the same term, and the samedata by different terms. A lot of data that the organization no longerneeds is still hanging around, and data that the organization couldreally benefit from is nowhere to be found. It’s not easy to face up toall of the informational chaos that a cataloging effort can reveal.

Perhaps needless to say, however, cataloging data is worth the trou‐ble and initial shock at the outcome. A data catalog that lists whatdata the organization has, what it’s called, where it’s stored, who’sresponsible for it, and other key metadata can easily be the most val‐uable information offering that an IT group can create.

Cataloging ToolsGiven that IT organizations have been preoccupied with modelingthe future over describing the present, enterprise vendors haven’treally addressed the catalog tool space to a significant degree. Thereare several catalog tools for individuals and small businesses, andseveral vendors of ETL (extract, transform and load) tools havesome cataloging capabilities relative to their own tools. Some also tiea catalog to a data governance process, although “governance” isright up there with “bureaucracy” as a term that makes many peoplewince.

At least a few data providers and vendors are actively pursuing cata‐log work, however. One company, Enigma, has created a catalog forpublic data, for example. The company has compiled a set of publicdatabases, and you can simply browse through their catalog (for freeif you are an individual) and check out what data you can access andanalyze. That’s a great model for what private enterprises should bedeveloping, and I know of some companies (including Tamr, Infor‐matica, Paxata, and Trifacta) that are developing tools to help com‐panies develop catalogs.

Cataloging Tools | 17

In industries such as biotech and financial services, for example, youincreasingly need to know what data you have. And it’s not only soyou can respond to business opportunities. Industry regulators arealso concerned about what data you have and what you are doingwith it. In biotech companies, for example, any data involvingpatients has to be closely monitored and its usage controlled. Infinancial services firms there is increasing pressure to keep track ofyour customers’ and partners’ “legal entity identifiers,” and to ensurethat dirty money isn’t being laundered.

But if you don’t have any idea of what data you have today, you’regoing to have a much tougher time adhering to the demands fromregulators. You also won’t be able to meet the demands of your mar‐keting, sales, operations, or HR departments. Knowing where yourdata is, seems perhaps the most obvious tenet of information man‐agement, but thus far, it has been among the most elusive.

Keep Everything Simple and StraightforwardWhile data management is a complex subject, traditional informa‐tion architectures are generally more complex than they need to be.They are usually incomprehensible not only to nontechnical people,but also to the technical people who didn’t have a hand in creatingthem. From IBM’s Business Systems Planning—one of the earliestarchitectural approaches—up through Master Data Management,architectures feature complex and voluminous flow diagrams andmatrices. Some look like the circuitry diagram for the latest Intelmicroprocessor. “Master Data Management” has the reasonableobjective of ensuring that all important data within an organizationcomes from a single authoritative source, but it often gets boggeddown in discussions about who’s in charge of data and whose data ismost authoritative.

It’s unfortunate that information architects don’t emulate architectsof physical buildings. While they definitely require complex dia‐grams full of technical details, good building architects don’t showthose blueprints to their clients. For clients, they create simple andeasy-to-digest sketches of what the building will look like when it’sdone. If it’s an expensive or extensive building project, they may cre‐ate three-dimensional models of the finished structure.

More than thirty years ago, Michael Hammer and I created a newapproach to architecture based primarily on “principles.” These are

18 | Chapter 2: An Alternative Approach to Data Management

simple, straightforward articulations of what an organizationbelieves and wants to achieve with information management; it maybe the equivalent of a sketch for a physical architect. Here are someexamples of the data-oriented principles from that project:

• Data will be owned by its originator but will be accessible tohigher levels;

• Critical data items in customer and sales files will conform tostandards for name, form, and semantics;

• Applications should be processed where data resides.

We suggested that an organization’s entire list of principles—includ‐ing those for technology infrastructure, organization, and applica‐tions, as well as data management—should take up no more than asingle page. Good principles can be the drivers of far more detailedplans, but they should be articulated at a level that facilitates under‐standing and discussion by business people. In this age of digitalbusinesses, such simplicity and executive engagement is far morecritical than it was in 1984.

Use an Ecological ApproachI hope I have persuaded you that enterprise-level models (or reallymodels at any level) are not sufficient to change individual andorganizational behavior, with respect to data. But now I will go evenfurther and argue that neither models, nor technology, policy, or anyother single factor is enough to move behavior in the right direction.Instead organizations need a broad, ecological approach to data-oriented behaviors.

In 1997 I wrote a book called Information Ecology: Mastering theInformation and Knowledge Environment. It was focused on thissame idea—that multiple factors and interventions are necessary tomove an organization in a particular direction with regard to dataand technology management. Unlike engineering-based models,ecological approaches assume that technology alone is not enoughto bring about the desired change, and that with multiple interven‐tions an environment can evolve in the right direction. In the book,I describe one organization, a large UK insurance firm called Stan‐dard Life, that adopted the ecological approach and made substan‐tial progress on managing its customer and policy data. Of course,

Use an Ecological Approach | 19

no one—including Standard Life—ever achieves perfection in datamanagement; all one can hope for is progress.

In Information Ecology, I discussed the influence on a company’sdata environment, of a variety of factors, including staff, politics,strategy, technology, behavior and culture, process, architecture, andthe external information environment. I’ll explain the lesser-knownaspects of this model briefly.

Staff, of course, refers to the types of people and skills that arepresent to help manage information. Politics refers primarily to thetype of political model for information that the organizationemploys; as noted earlier, I prefer federalism for most large compa‐nies. Strategy is the company’s focus on particular types of informa‐tion and particular objectives for it. Behavior and culture refers tothe particular information behaviors (e.g., not creating new datasources and reusing existing ones) that the organization is trying toelicit; in the aggregate they constitute “information culture.” Processinvolves the specific steps that an organization undertakes to create,analyze, disseminate, store, and dispose of information. Finally, theexternal information environment consists of information sourcesand uses outside of organization’s boundaries that the organizationmay use to improve its information situation. Most organizationshave architectures and technology in place for data management,but they have few, if any, of these other types of interventions.

I am not sure that these are now (or ever were) the only types ofinterventions that matter, and in any case the salient factors will varyacross organizations. But I am quite confident that an approach thatemploys multiple factors to achieve an objective (for example, toachieve greater use of common information) is more likely to suc‐ceed than one focused only on technology or architectural models.

Together, the approaches I’ve discussed in this chapter comprise acommon-sense philosophy of data management that is quite differ‐ent from what most organizations have employed. If for no otherreason, organizations should try something new because so manyhave yet to achieve their desired state of data management.

20 | Chapter 2: An Alternative Approach to Data Management

CHAPTER 3

Pragmatic Challenges in BuildingData Cleaning Systems

—Ihab Ilyas

Acquiring and collecting data often introduces errors, includingmissing values, typos, mixed formats, replicated entries of the samereal-world entity, and even violations of business rules. As a result,“dirty data” has become the norm, rather than the exception, andmost solutions that deal with real-world enterprise data suffer fromrelated pragmatic problems that hinder deployment in practicalindustry and business settings.

In the field of big data, we need new technologies that provide solu‐tions for quality data analytics and retrieval on large-scale databasesthat contain inconsistent and dirty data. Not surprisingly, develop‐ing pragmatic data quality solutions is a challenging venue and isrich with deep theoretical and engineering problems. In this Chap‐ter, we discuss several of the pragmatic challenges caused by dirtydata, and a series of principles that will help you develop and deploydata cleaning solutions.

Data Cleaning ChallengesIn process of building data cleaning software, there are many chal‐lenges to consider. In this section, we’ll explore seven characteristicsof real-world applications, and the often-overlooked challenges theypose to the data cleaning process.

21

1. ScaleOne of the building blocks in data quality is record linkage and con‐sistency checking. For example, detecting functional dependencyviolations involves (at least) quadratic complexity algorithms — forexample, those that enumerate all pairs of records to assess if there isa violation (e.g., Figure 3-1 illustrates the process of determiningthat if two employee records agree on the zip code, they have to bein the same city). In addition, more expensive activities, such asclustering and minimum vertex work to consolidate duplicaterecords, or to accumulate evidence of data errors. Given the com‐plexity of these activities, cleaning large-scale data sets is prohibitive,both computationally and in terms of cost. (In fact, scale rendersmost academic proposals inapplicable to real-world settings.) Large-scale blocking and hashing techniques are often used to trade-offthe complexity and recall of detected anomalies, and sampling isheavily used in both assessing the quality of the data, and to produceclean data samples for analytics.

Figure 3-1. Expensive operations in record de-duplication

2. Human in the LoopData is not born an orphan, and enterprise data is often treated as anasset guarded by “data owners” and “custodians”. Automatic changesare usually based on heuristic objectives, such as introducing mini‐mal changes to the data, or trusting a specific data source over oth‐ers. Unfortunately these objectives cannot lead to viable deployablesolutions, since often times human-verified or trusted updates arenecessary to actually change the underlying data.

22 | Chapter 3: Pragmatic Challenges in Building Data Cleaning Systems

A major challenge in developing an enterprise-adoptable solution isallowing only trusted fixes to data errors, where “trusted” refers toexpert interventions or verification by master data, or knowledgebases. The high cost involved in engaging data experts, and the het‐erogeneity and limited coverage of reference master data, make trus‐ted fixes a challenging task. We need to judiciously involve expertsand knowledge bases (reference sources) to repair erroneous datasets.

Effective user engagement in data curation will necessarily realizedifferent roles of humans in the data curation loop: data scientistsare usually aware of the final questions that need to be answeredfrom the input data, and what tools will be used to analyze it; busi‐ness owners are the best to articulate the value of the analytics, andhence control the cost/accuracy trade-off; while domain experts areuniquely qualified to answer data-centric questions, such as whetheror not two instances of a product are the same (Figure 3-2).

Figure 3-2. Humans in the loop

What makes things even more interesting is that enterprise data isoften protected by layers of access control and policies to guide whocan see what. Solutions that involve humans or experts have toadhere to these access control policies during the cleaning process.While that would be straightforward if these policies are explicitlyand succinctly represented to allow porting to the data curationstack, the reality is that most of these access controls are embeddedand hard-wired in various applications and data access points. Todevelop a viable and an effective human-in-the-loop solution, fullawareness of these access constraints is a must.

Data Cleaning Challenges | 23

3. Expressing and Discovering Quality ConstraintsWhile data repairing is well-studied for closed-form integrity con‐straints formulae (such as functional dependency or denial con‐straints), real world business rules are rarely expressed in theserather limited languages. Quality engineers often require runningscripts written in imperative languages to encode the various busi‐ness rules (Figure 3-3). Having an extensible cleaning platform thatallows for expressing rules in these powerful languages, yet limitingthe interface to rules that are interpretable and practical to enforce,is a hard challenge. What is even more challenging is discoveringthese high-level business rules from the data itself (and ultimatelyverifying them via domain experts). Automatic business and qualityconstraints discovery and enforcement, can play a key role in con‐tinually monitoring the health of the source data and pushing datacleaning activities upstream, closer to data generation and acquisi‐tion.

Figure 3-3. Sample business rules expressed as denial constraints

4. Heterogeneity and Interaction of Quality RulesData anomalies are rarely due to one type of error; dirty data oftenincludes a collection of duplicates, business rules violations, missingvalues, misaligned attributes, and un-normalized values. Most avail‐able solutions focus on one type of error to allow for sound theoreti‐cal results, or for a practical scalable solution. These solutionscannot be applied independently because they usually conflict onthe same data. We have to develop “holistic” cleaning solutions thatcompile heterogeneous constraints on the data, and identify themost problematic data portions by accumulating “evidence oferrors” (Figure 3-4).

24 | Chapter 3: Pragmatic Challenges in Building Data Cleaning Systems

Figure 3-4. Data cleaning is holistic

5. Data and Constraints Decoupling and InterplayData and integrity constraints often interplay and are usually decou‐pled in space and time, in three different ways. (1) While errors areborn with the data, they are often discovered much later in applica‐tions, where more business semantics are available; hence, con‐straints are often declared and applied much later, and in multiplestages in the data processing life cycle. (2) Detecting and fixingerrors at the source, rather than at the application level, is importantin order to avoid updatability restrictions and to prevent futureerrors. (3) Data cleaning rules, themselves, are often inaccurate;hence, a cleaning solution has to consider “relaxing” the rules toavoid over-fitting and to respond to business logic evolution. Clean‐ing solutions need to build on causality and responsibility results, inorder to reason about the errors in data sources. This allows foridentifying the most problematic data, and logically summarizingdata anomalies using predicates on the data schema, and accompa‐nying provenance information.

6. Data VarietyConsidering only structured data limits the complexity of detectingand repairing data errors. Most current solutions are designed towork with one type of structured data — tables — yet, businessesand modern applications process a large variety of data sources,most of which are unstructured. Oftentimes, businesses will extractthe important information and store it in structured data warehousetables. Delaying the quality assessment until after this information isextracted and loaded into data warehouses becomes inefficient andinadequate. More effective solutions are likely to push data qualityconstraints to the information extraction subsystem to (1) limit the

Data Cleaning Challenges | 25

amount of dirty data pumped into the business intelligence stack;and (2) get closer to the sources of errors, where more context isavailable for trusted and high-fidelity fixes (Figure 3-5).

Figure 3-5. Iterative by design

7. Iterative by Nature, Not DesignWhile most cleaning solutions insist on “one-shot-cleaning”, datatypically arrives and is handled incrementally, and quality rules andschema are continuously evolving. One-shot-cleaning solutions can‐not sustain large-scale data in a continuously-changing enterpriseenvironment, and are destined to be abandoned. The cleaning pro‐cess is iterative by nature, and has to have incremental algorithms atthe heart of the solution. This usually entails heavy collection andmaintenance of data provenance (e.g., meta data that describes thesources and the types of changes the data is going through), in orderto keep track of data “states”. Keeping track of data states allowsalgorithms and human experts to add knowledge, change previousbeliefs, and even to roll-back previous actions.

Building Adoptable Data Cleaning SolutionsWith hundreds of research papers on the topic, data cleaning effortsin industry are still pretty much limited to one-off solutions that area mix of consulting work, rule-based systems, and ETL scripts. Thedata cleaning challenges we’ve reviewed in this chapter present realobstacles in building “cleaning platforms”. Tackling all of these chal‐lenges in one platform is likely to be a very expensive software engi‐neering exercise. On the other hand, ignoring them is likely toproduce throwaway system prototypes.

Adoptable data cleaning solutions are likely to tackle at least a few ofthese pragmatic problems by:

26 | Chapter 3: Pragmatic Challenges in Building Data Cleaning Systems

1. Having humans or experts in the loop as a first-class cleaningprocess for training models and verification

2. Focusing on scale from the start, and not as an after thought,which will exclude most naïve brute-force techniques currentlyused in problems like deduplication and schema mapping

3. Realizing that curation is a continuous incremental process,which requires a mix of incremental algorithms and a full-fledged provenance management system in the backend, toallow for controlling and revising decisions long after the cura‐tion life cycle

4. Coupling data-clearing activities to data consumption end-points (e.g., data warehouses and analytics stacks) for moreeffective feedback

Building practical, deployable data cleaning solutions for big data isa hard problem that is full of both engineering and algorithmic chal‐lenges; however, being programmatic does not mean being unprin‐cipled.

Building Adoptable Data Cleaning Solutions | 27

CHAPTER 4

Understanding Data Science: AnEmerging Discipline for Data-

Intensive Discovery

—Michael L. Brodie

IntroductionOver the past two decades, Data-Intensive Analysis (DIA) — alsoreferred to as Big Data Analytics — has emerged not only as a basisfor the Fourth Paradigm of engineering and scientific discovery, butas a basis for discovery in most human endeavors for which data isavailable. Originating in the 1960s, the recent emergence of Data-Intensive Analysis, due to big data and massive computing power, isleading to widespread deployment. Yet — it is in its infancy in itsapplication and our understanding of it, and likewise in its develop‐ment. Given the potential risks and rewards of Data-Intensive Anal‐ysis, and its breadth of application, it is imperative that we get itright.

The objective of this emerging Fourth Paradigm is more thanacquiring data and extracting knowledge. Like its predecessor thescientific method, the objective of the Fourth Paradigm is to investi‐gate phenomena by acquiring new knowledge, and correcting andintegrating it with previous knowledge. In addition, data science is abody of principles and techniques with which to measure andimprove the correctness, completeness, and efficiency of Data-Intensive Analysis. It is now time to identify and understand the

29

fundamentals. In my research, I have analyzed more than 30 verylarge-scale use cases to understand current practical aspects, to gaininsight into the fundamentals, and to address the fourth “V” of BigData – veracity — the accuracy of the data and the resulting analyt‐ics.

Data Science: A New Discovery Paradigm ThatWill Transform Our WorldThe emergence of big data has opened the door to profound change– to new ways of reasoning, problem solving, and processing, that inturn bring new opportunities and challenges.

To better understand DIA, and its opportunities and challenges, myresearch has examined over 30 DIA use-cases that are at very large-scale — in the range where theory and practice may break. Thischapter summarizes some key results of this research, related tounderstanding and defining data science as a body of principles andtechniques with which to measure and improve the correctness, com‐pleteness, and efficiency of Data-Intensive Analysis. As with its prede‐cessor, discovery paradigms, establishing this emerging FourthParadigm and the underlying principles and techniques of data sci‐ence may take decades.

Significance of DIA and Data ScienceData Science is transforming discovery in many human endeavorsincluding healthcare, manufacturing, education, financial model‐ling, policing, and marketing [10, 13]. It has been used to producesignificant results in areas from particle physics (e.g., Higgs Boson),to identifying and resolving sleep disorders using Fitbit data, to rec‐ommenders for literature, theatre, and shopping. More than 50national governments have established data-driven strategies as anofficial policy, in science and engineering [2], as well as in health‐care, e.g., US National Institutes of Health and President Obama’sPrecision Medicine Initiative for “Delivering the right treatments, atthe right time, every time to the right person.” The hope, supportedby early results, is that data-driven techniques will accelerate the dis‐covery of treatments to manage and prevent chronic diseases withmore precision and that are tailored to specific individuals, as wellas being at dramatically lower-cost.

30 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

Data Science is being used to radically transform entire domains,such as medicine and biomedical research, as stated as the purposeof the newly created Center for Biomedical Informatics at HarvardMedical School. It is also making an impact in economics [14], drugdiscovery [16], and many other domains. As a result of its successesand potential, data science is rapidly becoming a sub-discipline ofmost academic areas. These developments suggest the strong beliefin the potential value of data science — but can it deliver?

Early successes and clearly-stated expectations of data science aretruly remarkable; however, its actual deployment, like many hottrends, is far less than it appears. According to Gartner’s 2015 surveyof Big Data Management and Analytics, 60% of the Fortune 500companies claim to have deployed data science, yet less than 20%have implemented consequent significant changes, and less than 1%have optimized its benefits. Gartner concludes that 85% will beunable to exploit big data in 2015. The vast majority of deploymentsaddress tactical aspects of existing processes and static businessintelligence, rather than realizing the power of data science, by dis‐covering previously unforeseen value and identifying strategicadvantages.

Illustrious Histories: The Origins of Data ScienceData science is in its infancy. Few individuals or organizationsunderstand the potential of, and the paradigm shift associated withdata science, let alone understand it conceptually. The high rewardsand the equally-high risks, and its pervasive application make itimperative that we better understand data science – its models,methods, processes, and results.

Data science is inherently multi-disciplinary, drawing on over 30allied disciplines, according to some definitions. Its principle com‐ponents include mathematics, statistics, and computer science —especially areas of artificial intelligence such as machine learning,data management, and high performance computing. While thesedisciplines need to be evaluated in the new paradigm, they havelong, illustrious histories.

Data analysis developed over 4,000 years ago, with origins in Baby‐lon (17th-12th C BCE) and India (12th C BCE). Mathematical anal‐ysis originated in the 17th C around the time of the ScientificRevolution. While statistics has its roots in 5th C BCE and the 18th

Data Science: A New Discovery Paradigm That Will Transform Our World | 31

C, its application in Data Science originated in 1962 with John W.Tukey [19] and George Box[4]. These long illustrious histories sug‐gest that Data Science draws on well-established results that tookdecades or centuries to develop. To what extent do they (e.g., statisti‐cal significance) apply in this new context?

Data Science constitutes a new paradigm in the sense of Thomas S.Kuhn’s scientific revolutions [12]. Data Science’s predecessor para‐digm, the Scientific Method, has approximately 2,000 years in thedevelopment of empiricism starting with Aristotle (384-322 BCE),Ptolemy (1st C), and the Bacons (13th, 16th C). Today, data scienceis emerging following the ~1,000-year development of its threepredecessor paradigms of scientific and engineering discovery:theory, experimentation, and simulation [8]. Data Science that hasdeveloped and been applied for over 50 years qualitatively changedin the late 20th century with the emergence of Big Data — data atvolumes, velocities, and variety that current technologies, let alonehumans, cannot handle efficiently. This chapter addresses anothercharacteristic that current technologies and theories do not handlewell — veracity.

What Could Possibly Go Wrong?Do we understand the risks of recommending the wrong product,the wrong medical diagnoses, treatments, or drugs? The risks of aresult that fails to achieve its objectives may include losses in time,resources, customer satisfaction, customers, and potentially a loss ofbusiness. The vast majority of data science applications face suchsmall risks, however, that veracity has received little attention.

Far greater risks could be incurred if incorrect data science resultsare acted upon in critical contexts, such as those already underway indrug discovery [17] and personalized medicine. Most scientists inthese contexts are well aware of the risks of errors, and go toextremes to estimate and minimize them. The wonder of the “dis‐covery” of the Higgs Boson by CERN’s ATLAS and CMS projects,announced on July 4, 2012, might suggest that the results wereachieved overnight — they were not. The results took 40 years andincluded data science techniques developed over a decade, andapplied over big data by two independent projects, ATLAS andCMS, each of which were subsequently peer-reviewed and published[1][11] with a further year-long verification. To what extent do thevast majority of data science applications concern themselves with

32 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

verification and error bounds, let alone understand the verificationmethods applied at CERN? Informal surveys of data scientists con‐ducted in my research at data science conferences suggest that 80%of customers never ask for error bounds.

The existential risks of applying Data Science have been raised byworld-leading authorities in organizations such as the Organizationfor Economic Cooperation and Development, the Artificial Intelli‐gence (AI) [3][7][9][18], and legal [5] communities. The mostextreme concerns have been stated by the Future of Life Institute,which has the objective of safeguarding life and developing optimis‐tic visions of the future in order to mitigate existential risks facinghumanity from AI.

Given the potential risks and rewards of DIA and its breadth ofapplication across conventional, empirical scientific and engineeringdomains, as well as across most human endeavors, we better get thisright! The scientific and engineering communities place high confi‐dence in their existing discovery paradigms, with well-definedmeasures of likelihood and confidence within relatively-preciseerror estimates. Can we say the same for modern data science as adiscovery paradigm, and for its results? A simple observation of theformal development of the processes and methods of its predeces‐sors suggest that we cannot. Indeed, we do not know if, or underwhat conditions the constituent disciplines, like statistics, may breakdown.

Do we understand DIA to the extent that we can assign probabilisticmeasures of likelihood to its results? With the scale and emergingnature of DIA-based discovery, how do we estimate the correctnessand completeness of analytical results relative to a hypothesized dis‐covery question, when the underlying principles and techniquesmay not apply in this new context?

In summary, we do not yet understand DIA adequately to quantifythe probability or likelihood that a projected outcome will occurwithin estimated error bounds. While CERN used data science andbig data to identify results, verification was ultimately empirical, asit must be in drug discovery [17] and other critical areas, until ana‐lytical techniques are developed and proven robust.

Data Science: A New Discovery Paradigm That Will Transform Our World | 33

Do We Understand Data Science?Do we even understand what data science methods compute or howthey work? Human thought is limited by the human mind. Accord‐ing to Miller’s Law [14], the human mind (short term workingmemory) is capable of conceiving less than ten (7 +/- 2) concepts atone time. Hence, humans have difficulty understanding complexmodels involving more than ten variables. The conventional processis to imagine a small number of variables, and then abstract orencapsulate that knowledge into a model that can subsequently beaugmented with more variables. Thus, most scientific theoriesdevelop slowly over time into complex models. For example, New‐ton’s model of physics was extended for 350 years through Bohr,Einstein, Heisenberg, and more, up to Higgs — to form The Stan‐dard Model of Particle Physics. Scientific discovery in particle phys‐ics is wonderful and has taken over 350 years. Due to its complexity,no physicist has understood the entire Standard Model for decades,rather it is represented in complex, computational models.

When humans analyze a problem, they do so with models with alimited number of variables. As the number of variables increase, itis increasingly difficult to understand the model and the potentialcombinations and correlations. Hence, humans limit their modelsand analyses to those that they can comprehend. These human-scalemodels are typically theory-driven, thus limiting their scale (numberof variables) to what can be conceived.

What if the phenomenon is arbitrarily complex or beyond immedi‐ate human conception? I suspect that this is addressed iterativelywith one model (theory) becoming abstracted as the base foranother more complex theory, and so on (standing on the shouldersof those who have gone before), e.g., the development of quantumphysics from elementary particles. That is, once the human mindunderstands a model, it can form the basis of a more complexmodel. This development under the scientific method scales at a ratelimited by human conception, thus limiting the number of variablesand complexity. This is error-prone since phenomena may not man‐ifest at a certain level of complexity. Models correct at one scale maybe wrong at a larger scale or vice versa — a model wrong at one scale(hence discarded) may become correct at a higher scale (more com‐plex model).

34 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

Machine learning algorithms can identify correlations betweenthousands, millions, or even billions of variables. This suggests thatit is difficult or even impossible for humans to understand what orhow these algorithms discover. Imagine trying to understand such amodel that results from selecting some subset of the correlations onthe assumption that they may be causal, and thus constitute a modelof the phenomenon with high confidence of being correct withrespect to some hypotheses, with or without error bars.

Cornerstone of A New Discovery ParadigmThe Fourth Paradigm - eScience supported by data science - is para‐digmatically different from its predecessor discovery paradigms. Itprovides revolutionary new ways [12] of thinking, reasoning andprocessing - new modes of inquiry, problem solving, and decision-making. It is not the Third Paradigm augmented by big data, butsomething profoundly different. Losing sight of this difference for‐feits its power and benefits, and loses the perspective that it is ARevolution That Will Transform How We Live, Work, and Think[13].

Paradigm shifts are difficult to notice as they emerge. There are sev‐eral ways to describe the shift. There is a shift of resources from(empirically) discovering causality (Why the phenomenon occurs) –the heart of the scientific method – to discovering interesting corre‐lations (What might have occurred). This shift involves moving froma strategic perspective driven by human-generated hypotheses(theory-driven, top-down) to a tactical perspective driven by obser‐vations (data-driven, bottom-up).

Seen at their extremes, the scientific method involves testinghypotheses (theories) posed by scientists, while data science can beused to generate hypotheses to be tested based on significant corre‐lations among variables that are identified algorithmically in thedata. In principle, vast amounts of data and computing power canbe used to accelerate discovery simply by outpacing human thinkingin both power and complexity.

The power of data science is growing rapidly due to the develop‐ment of ever more powerful computing resources and algorithms,such as deep learning. So rather than optimize an existing process,data science can be used to identify patterns that suggest unforeseensolutions.

Data Science: A New Discovery Paradigm That Will Transform Our World | 35

However, even more compelling is one step beyond the simple ver‐sion of this shift — namely, a symbiosis of the both paradigms. Forexample, data science can be used to offer highly-probable hypothe‐ses or correlations from which we select those with acceptable errorestimates, and that are worthy of subsequent empirical analysis. Inturn, empiricism is used to pursue these hypotheses until some con‐verge and some diverge, at which point data science can be appliedto refine or confirm the converging hypotheses, and the cycle startsagain. Ideally, one would optimize the combination of theory-drivenempirical analysis, with data-driven analysis to accelerate discoveryfaster than either on their own.

While data science is a cornerstone of a new discovery paradigm, itmay be conceptually and methodologically more challenging thanits predecessors since it involves everything included in its predeces‐sor paradigms – modelling, methods, processes, measures of cor‐rectness, completeness, and efficiency – in a much more complexcontext, namely that of big data. Following well-established develop‐ments, we should try to find the fundamentals of data science – itsprinciples and techniques – to help manage the complexity andguide its understanding and application.

Data Science: A PerspectiveSince data science is in its infancy and is inherently multi-disciplinary, there are naturally many definitions that emerge andevolve with the discipline. As definitions serve many purposes, it isreasonable to have multiple definitions, each serving different pur‐poses. Most definitions of data science attempt to define Why (it’spurpose), What (constituent disciplines), and How (constituentactions of discovery workflows).

A common definition of data science is the activity of extractingknowledge from data. While simple, it does not convey the largergoal of data science or its consequent challenges. A DIA activity isfar more than a collection of actions, or the mechanical processes ofacquiring and analyzing data. Like its predecessor paradigm, the sci‐entific method, the purpose of data science and a DIA activity is toinvestigate phenomena by acquiring new knowledge, and correctingand integrating it with previous knowledge – continually evolvingour understanding of the phenomena, based on newly-availabledata. We seldom start from scratch. Hence, discovering, understand‐

36 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

ing, and integrating data must precede extracting knowledge, all atmassive scale, i.e., largely by automated means.

The scientific method that underlies the Third Paradigm is a body ofprinciples and techniques that provide the formal and practicalbases of scientific and engineering discovery. The principles andtechniques have been developed over hundreds of years originatingwith Plato and are still evolving today with significant unresolvedissues such as statistical significance, (i.e., P values) and reproduci‐bility.

While data science had its origins 50 years ago with Tukey [18] andBox [4], it started to change qualitatively, less than two decades ago,with the emergence of big data and the consequent paradigm shiftwe’ve explored. The focus of this research into modern data scienceis on veracity – the ability to estimate the correctness, completeness,and efficiency of an end-to-end DIA activity and of its results.Therefore, we will use the following definition, in the spirit of: [16]

Data Science is a body of principles and techniques for applying data-intensive analysis to investigate phenomena, acquire new knowledge,and correct and integrate previous knowledge with measures of cor‐rectness, completeness, and efficiency of the derived results, withrespect to some pre-defined (top down) or emergent (bottom up) speci‐fication (scope, question, hypothesis).

Understanding Data Science From PracticeMethodology to Better Understand DIADriven by a passion for understanding data science in practice, myyear-long and ongoing research study has investigated over 30 verylarge scale big data applications — most of which have produced orare daily producing significant value. The use cases include particlephysics; astrophysics and satellite imagery; oceanography; econom‐ics; information services; several life sciences applications in phar‐maceuticals, drug discovery, and genetics; and various areas ofmedicine including precision medicine, hospital studies, clinical tri‐als, and intensive care unit and emergency room medicine.

The focus is to investigate relatively well-understood, successful usecases where correctness is critical and the big data context is at mas‐sive scale; such use cases constitute less than 5% of all deployed big

Understanding Data Science From Practice | 37

data analytics. The focus is on these use cases, as we do not knowwhere errors may arise outside normal scientific and analyticalerrors. There is a greater likelihood that established disciplines, e.g.,statistics and data management, might break at very large scale,where errors due to failed fundamentals may be more obvious.

The breadth and depth of the use cases revealed strong, significantemerging trends, some of which are listed below. These confirmedfor some use case owners, and suggested to others, solutions anddirections that they were pursuing, but could not have seen withoutthe perspective of 30+ use cases.

DIA ProcessesA Data-Intensive-Activity is an analytical process that consists ofapplying sophisticated analytical methods to large data sets that arestored under some analytical models (Figure 4-1). While this is thetypical view of data science projects or DIA use cases, this analyticalcomponent of the DIA activity constitutes ∼20% of an end-to-endDIA pipeline or workflow. Currently it consumes ∼20% of theresources required to complete a DIA analysis.

38 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

Figure 4-1. Conventional View of Data-Intensive Analysis

An end-to-end DIA activity (???) involves two data managementprocesses that precede the DIA process, namely Raw Data Acquisi‐tion and Curation, and Analytical Data Acquisition. Raw DataAcquisition and Curation starts with discovering and understandingdata in data sources and ends with integrating and storing curateddata in a repository that represents entities in the domain of interest,and metadata about those entities. Analytical Data Acquisition startswith discovering and understanding data within the shared reposi‐tory and ends with storing the resulting information, specific enti‐

Understanding Data Science From Practice | 39

ties and interpretations, into an analytical model to be used by thesubsequent DIA process.

Figure 4-2. End-to-end Data-Intensive Analysis Workflow

Sophisticated algorithms, such as machine learning, largely auto‐mate DIA processes, as they have to be automated to process suchlarge volumes of data using complex algorithms. Currently, RawData Acquisition and Curation, and Analytical Data Acquisitionprocesses are far less automated, typically requiring 80% or more ofthe total resources to complete.

This understanding leads us to the following definitions:

• Data-Intensive Discovery (DID) is the activity of using bigdata to investigate phenomena, to acquire new knowledge, andto correct and integrate previous knowledge. **“-Intensive” isadded when the data is “at scale”. Theory-driven DID is thehuman-generated scientific, engineering, or other hypothesesover big data. Data-Driven DID employs automatic hypothesisgeneration.

• Data-Intensive Analysis (DIA) is the process of analyzing bigdata with analytical methods and models.

40 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

— DID goes beyond the Third paradigm of scientific or engi‐neering discovery by investigating scientific or engineeringhypotheses using DIA. A DIA activity is an experiment overdata thus requiring all aspects of a scientific experiment, e.g.,experimental design, expressed over data, a.k.a.* data-basedempiricism*.

• A DIA Process (workflow or pipeline) is a sequence of opera‐tions that constitute an end-to-end DIA activity from the sourcedata to the quantified, qualified result.

Currently, ~80% of the effort and resources required for the entireDIA activity are due to the two data management processes – areaswhere scientists / analysts are not experts. Emerging technologies,such as those for data curation at scale, aims to flip that ratio from80:20 to 20:80, to let scientists do science and analysts do analysis.This requires an understanding of the data management processesand their correctness, completeness, and efficiency in addition tothose of the DIA process. Another obvious consequence is that pro‐portionally, 80% of the errors that could arise in DIA may arise inthe data management processes, prior to DIA even starting.

Characteristics of Large-Scale DIA Use CasesThe focus of my research is successful, very large-scale, multi-yearprojects with 100s-1,000s of ongoing DIA activities. These activitiesare supported by a DIA ecosystem, consisting of a community ofusers (e.g., over 5,000 scientists in the ATLAS and CMS projects atCERN and similar numbers of scientists using the worldwide Can‐cer Genome Atlas) and technology (e.g., science gateways, collec‐tively referred to in some branches of science as networked science).Some significant trends that have emerged from the analysis of theseuse cases are listed, briefly, below.

The typical view of data science appears to be based on the vastmajority (~95%) of DIA use cases. While they share some character‐istics with those in this study, there are fundamental differences,such as the concern for and due diligence associated with veracity.

Based on this study data, analysis appears to fall into three classes.Conventional data analysis over “small data” accounts for at least95% of all data analysis, often using Microsoft Excel. DIA over bigdata has two sub-classes, simple DIA, i.e., the vast majority of DIAuse cases mentioned above, and complex DIA such as the use cases

Understanding Data Science From Practice | 41

analyzed in this study that are characterized by complex analyticalmodels, and a corresponding plethora of analytical methods. Thecomplexity of the models and methods are as complex as the phe‐nomena being analyzed.

The most widely used DIA tools for simple cases claim to supportanalyst self-service, in point-and-click environments, some claiming“point us at the data and we will find the patterns of interest for you”.This characteristic is infeasible in the use cases analyzed. A require‐ment common to the use cases analyzed is not only the principle ofbeing machine-driven and human-guided, but extensive attempts tooptimize this man-machine symbiosis for scale, cost, and precision(too much human-in-the-loop leads to errors, too little leads to non‐sense).

DIA ecosystems are inherently multi-disciplinary (ideally interdis‐ciplinary), collaborative, and iterative. Not only does DIA (BigData Analytics) require multiple disciplines, e.g., genetics, statisticsand machine learning, so too do the data management processesrequire multiple disciplines, e.g., data management, domain andmachine learning experts for data curation, statisticians for sam‐pling, etc.

In large-scale DIA ecosystems, a DIA is a virtual experiment [6].Far from claims of simplicity and point-and-click self-service, mostlarge-scale DIA activities reflect the complexity of the analysis athand and are the result of long-term (months to years) experimentaldesigns that involve greater complexity than their empirical counter‐parts, to deal with scale, significance, hypotheses, null hypotheses,and deeper challenges, such as determining causality from correla‐tions and identifying and dealing with biases, and often irrationalhuman intervention.

Finally, veracity is one of the most significant challenges and criticalrequirements of all DIA ecosystems studied. While there are manycomplex methods in conventional data science to estimate veracity,most owners of use cases studied expressed concern for adequatelyestimating veracity in modern data science. Most assume that alldata is imprecise; hence require probabilistic measures and errorbars and likelihood estimates for all results. More basically, mostDIA ecosystem experts recognize that errors can arise across an end-to-end DIA activity and are investing substantially in addressing

42 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

these issues in both the DIA processes and the data managementprocesses that currently require significant human guidance.

An objective of this research is to discover the extent to which theabove characteristics of very large scale, complex DIAs also apply tosimple DIAs. There is a strong likelihood that they apply directly,but are difficult to detect. That is — the principles and techniques ofDIA apply equally to simple and complex DIA.

Looking Into A Use CaseDue to the detail involved, there is not space in this chapter or bookto describe a single use case considered in this study. However, let’slook into a single step of a use case involving a virtual experimentconducted at CERN in the Atlas project. The heart of empirical sci‐ence is experimental design. It starts by identifying, formulating, andverifying a worthy hypothesis to pursue. This first complex step typ‐ically involves a multi-disciplinary team, called the collaborators forthis virtual experiment, often from around the world for more thana year. We consider the second step, the construction of the controlor background model (executable software and data) that creates thebackground (e.g., executable or testable model and a given data set)required as the basis within which to search (analyze) for “signals”that would represent the phenomenon being investigated in thehypothesis. This is the control that completely excludes the data ofinterest. The data of interest (the signal region) is “blinded” com‐pletely so as not to bias the experiment. The background (control) isdesigned using software that simulates relevant parts of the standardmodel of particle physics plus data from Atlas selected with theappropriate signatures with the data of interest blinded.

Over time Atlas contributors have developed simulations of manyparts of the standard model. Hence, constructing the modelrequired for the background involves selecting and combining rele‐vant simulations. If there is no simulation for some aspect that yourequire, then it must be requested or you may have to build it your‐self. Similarly, if there is no relevant data of interest in the experi‐mental data repository, it must be requested from subsequentcapture from the detectors when LHC is next fired up in the appro‐priate energy levels. This comes from a completely separate teamrunning the (non-virtual) experiment.

Understanding Data Science From Practice | 43

The development of the background is approximately a one person-year activity as it involves the experimental design, the design andrefinement of the model (software simulations), the selection ofmethods and tuning to achieve the correct signature (i.e., get theright data), verify the model (observe expected outcomes when tes‐ted), and dealing with errors (statistical and systematic) that arisefrom the hardware or process. The result of the Background phase isa model approved by the collaborative to represent the backgroundrequired by the experiment with the signal region blinded. Themodel is an “application” that runs on the Atlas “platform” usingAtlas resources - libraries, software, simulations, and data muchdrawing on the ROOT framework, CERN’s core modeling and anal‐ysis infrastructure. It is verified by being executed under varioustesting conditions.

This is an incremental or iterative process each step of which isreviewed. The resulting design document for the Top Quark experi‐ment was approximately 200 pages of design choices, parameter set‐tings, and results - both positive and negative! All experimental dataand analytical results are probabilistic. All results have error bars; inparticle physics they must be at least 5 sigma to be accepted. Thisexplains the year of iteration in which analytical models are adjus‐ted, analytical methods are selected and tuned, and results reviewedby the collaboration. The next step is the actual virtual experiment.This too takes months. You might be surprised to find that once thedata is un-blinded (i.e., synthetic data is replaced in the region ofinterest with experimental data), the experimenter, often a PhD can‐didate, gets one and only one execution of the “verified” model overthe experimental data.

Hopefully this portion of a use case illustrates that Data-IntensiveAnalysis is a complex but critical tool in scientific discovery usedwith a well-defined understanding of veracity. It must stand up toscrutiny that evaluates if the experiment - consisting of all models,methods, and data with probabilistic results and error bounds betterthan 5 sigma – is adequate to be accepted by Science or Nature asdemonstrating that the hypothesized correlation is causal.

Research For An Emerging DisciplineThe next step in this research to better understand the theory andpractice of the emerging discipline of data science, to understand

44 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

and address its opportunities and challenges, and to guide its devel‐opment, is given in its definition. Modern data science builds onconventional data science and on all of its constituent disciplinesrequired to design, verify, and operate end-to-end DIA activities,including both data management and DIA processes, in a DIA eco‐system for a shared community of users. Each discipline must beconsidered with respect to which it contributes to investigating phe‐nomena, acquiring new knowledge, and correcting and integratingnew with previous knowledge. Each operation must be understoodwith respect to which correctness, completeness, and efficiency canbe estimated.

This research involves identifying relevant principles and techni‐ques. Principles concern the theories that are established formally,e.g., mathematically, and possibly demonstrated empirically. Techni‐ques involve the application of wisdom [20], i.e., domain knowledge,art, experience, methodologies, practice, often called best practices.The principles and techniques, especially those established for con‐ventional data science, must be verified and if required, extended,augmented, or replaced for the new context of the Fourth Paradigm— especially its volumes, velocities, and variety. For example, newdepartments at MIT, Stanford, and the University of California,Berkeley, are conducting such research under what some are calling21st Century Statistics.

A final, stimulating challenge is what is called meta-modelling ormeta-theory. This area emerged in the physical sciences in the 1098sand subsequently in statistics and machine learning and is nowbeing applied in other areas. Meta-modelling arises when usingmultiple analytical models and multiple analytical methods, to ana‐lyze different perspectives or characteristics of the same phenom‐enon. This extremely natural and useful methodology, calledensemble modelling, is required in many physical sciences, statistics,and AI, and should be explored as a fundamental modelling meth‐odology.

AcknowledgementI gratefully acknowledge the brilliant insights and improvementsproposed by Prof Jennie Duggan, Northwestern University and ProfThilo Stadelmann, Zurich University of Applied Sciences.

Research For An Emerging Discipline | 45

References[1] G. Aad et al. 2012. Observation of a new particle in the searchfor the Standard Model Higgs boson with the ATLAS detector at theLHC. Physics Letters B 716, 1 (2012), 1–29.

[2] Accelerating Discovery in Science and Engineering ThroughPetascale Simulations and Analysis (PetaApps), National ScienceFoundation, Posted July 28, 2008.

[3] J. Bohannon, “Fears of an AI pioneer,” Science, vol. 349, no. 6245,pp. 252–252, Jul. 2015.

[4] G.E.P. Box. Science and Statistics. Journal of the American Statis‐tical Association 71, 356 (April 2012), 791–799 reprint of originalfrom 1962

[5] N. Diakopoulos. Algorithmic Accountability Reporting: On theInvestigation of Black Boxes. Tow Center. February 2014.

[6] Duggan, Jennie and Michael Brodie, Hephaestus: Data Reuse forAccelerating Scientific Discovery, In CIDR 2015.

[7] S.J. Gershman, E.J. Horvitz, and J.B. Tenenbaum. 2015. Compu‐tational rationality: A converging paradigm for intelligence inbrains, minds, and machines. Science 349, 6245 (2015), 273–278.

[8] Jim Gray on eScience: a transformed scientific method, in A.J.G.Hey, S. Tansley, and K.M. Tolle (Eds.): The fourth paradigm: data-intensive scientific discovery. Proc. IEEE 99, 8 (2009), 1334–1337.

[9] E. Horvitz and D. Mulligan. 2015. Data, privacy, and the greatergood. Science 349, 6245 (July 2015), 253–255.

[10] M.I. Jordan and T.M. Mitchell. 2015. Machine learning: Trends,perspectives, and prospects. Science 349, 6245 (July 2015), 255–260.

[11] V. Khachatryan et al. 2012. Observation of a new boson at amass of 125 GeV with the CMS experiment at the LHC. Physics Let‐ters B 716, 1 (2012), 30–61.

[12] Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rded. Chicago, IL: University of Chicago Press, 1996.

[13] Mayer-Schönberger, V., & Cukier, K. (2013-03-05). Big Data: ARevolution That Will Transform How We Live, Work, and Think.Houghton Mifflin Harcourt

46 | Chapter 4: Understanding Data Science: An Emerging Discipline for Data-IntensiveDiscovery

[14] Miller, G. A. (1956). “The magical number seven, plus or minustwo: Some limits on our capacity for processing information”. Psy‐chological Review 63 (2): 81–97.

[15] D.C. Parkes and M.P. Wellman. 2015. Economic reasoning andartificial intelligence. Science 349, 6245 (July 2015), 267–272.

[16] F. Provost and T. Fawcett. 2013. Data Science and its Relation‐ship to Big Data and Data-Driven Decision Making. Big Data 1, 1(March 2013), 51–59.

[17] Scott Spangler, et. al. 2014. Automated hypothesis generationbased on mining scientific literature. In Proceedings of the 20th ACMSIGKDD international conference on Knowledge discovery and datamining (KDD ’14). ACM, New York, NY, USA, 1877-1886.

[18] J. Stajic, R. Stone, G. Chin, and B. Wible. 2015. Rise of theMachines. Science 349, 6245 (July 2015), 248–249.

[19] J. W. Tukey, “The Future of Data Analysis,” Ann. Math. Statist.pp. 1–67, 1962.

[20] Bin Yu, Data Wisdom for Data Science, ODBMS.org, April 13,2015.

Research For An Emerging Discipline | 47

CHAPTER 5

From DevOps to DataOps

—Andy Palmer

Why It’s Time to Embrace “DataOps” as a NewDisciplineOver the past 10 years, the technology industry has experienced theemergence of “https://en.wikipedia.org/wiki/DevOps[DevOps].”This new set of practices and tools have improved the velocity, qual‐ity, predictability, and scale of software engineering and deployment.Starting at the large Internet companies, the trend towards DevOpsis now transforming the way that systems are developed and man‐aged inside an enterprise — often dovetailing with enterprise cloudadoption initiatives. Regardless of your opinion about on-prem vs.multi-tenant cloud infrastructure, the adoption of DevOps isimproving how quickly new features and functions are delivered atscale for end-users.

There is a lot to learn from the evolution of DevOps — across themodern Internet, as well as within the modern enterprise — mostnotably for those who work with data every day.

At its core, DevOps is about the combination of software engineer‐ing, quality assurance, and technology operations (Figure 5-1).DevOps emerged because traditional systems management (versussoftware development management) was not adequate enough tomeet the needs of modern, web-based application development anddeployment.

49

Figure 5-1. DevOps in the Enterprise

From DevOps to DataOpsIt’s time for data engineers and data scientists to embrace a new,similar discipline — let’s call it “DataOps” — that at its core,addresses the needs of data professionals inside the modern enter‐prise.

Two trends are creating the need for DataOps:

1. The democratization of analytics gives more individuals accessto cutting-edge visualization, data modeling, machine learning,and statistics.

2. The implementation of “built-for-purpose” database enginesimproves the performance and accessibility of large quantitiesof data, at unprecedented velocity. The techniques to improvebeyond legacy relational DBMS’s vary across markets, and thishas driven the development of specialized database engines suchas StreamBase, Vertica, VoltDB and SciDB.

More recently, Google made its massive Cloud Bigtable database(the same one that powers Google search, Maps, YouTube, and

50 | Chapter 5: From DevOps to DataOps

Gmail) available to everyone in a scalable NoSQL database servicethrough the ApacheHBase API.

Together, these trends create pressure from both ‘ends of the stack’.From the top of the stack, users want access to more data in morecombinations. From the bottom of the stack, more data is availablethan ever before — some aggregated, and much of it not. The onlyway for data professionals to deal with the pressure of heterogeneityfrom both the top and bottom of the stack is to embrace a newapproach to managing data This new approach blends operationsand collaboration. The goal is to organize and deliver data frommany sources, to many users reliably. At the same time, it’s essentialto maintain the provenance required to support reproducible dataflows.

Defining DataOpsDataOps is a data management method facilitated among data engi‐neers, data scientists and other data professionals that emphasizes:

• Communication• Collaboration• Integration• Automation

DataOps acknowledges the interconnected nature of data engineer‐ing, integration, quality, and security and privacy. It aims to help anorganization rapidly-deliver data that accelerates analytics, and ena‐bles previously-impossible analytics.

The “ops” in DataOps is very intentional. The operation of infra‐structure required to support the quantity, velocity, and variety ofdata available in the enterprise today is radically different than whattraditional data management approaches have assumed. The natureof DataOps embraces the need to manage many data sources andmany data pipelines, with a wide variety of transformations.

Changing the fundamental infrastructureWhile people have been managing data for a long time, we’re at apoint now where the quantity, velocity, and variety of data availableto a modern enterprise can no longer be managed without a signifi‐

Defining DataOps | 51

cant change in the fundamental infrastructure. The design point ofthis infrastructure must focus on:

• The thousands of sources that are not centrally-controlled, andwhich frequently change their schema without notification(much in the way that websites change frequently without noti‐fying search engines); and

• Treating these data sources (especially tabular data sets) as ifthey were websites being published inside of an organization.

DataOps challenges preconceived notions of how to engage the vastquantities of data being collected every day. Satisfying the enormousappetite for this data requires that we sort it in a way that is rapid,interactive, and flexible. The key to DataOps is that you don’t haveto theorize and manage your data schemas up front, with a mis‐placed idealism about how the data should look.

DataOps MethodologyUsing DataOps methodology, you start with the data as it is andwork from the bottom up. You work with it, integrate it, uncoverinsights along the way, find more data, and more data sources thatsupport or add to what you have discovered. Eventually, you comeaway with more quality outcomes than if you had tried to sortthrough the information from the top down with a specific goal inmind.

DataOps methodology brings a more agile approach to interrogat‐ing and analyzing data, on a very large scale. At some point, whatyou want is all the data. If you have all the data in a clear, compre‐hensible format, then you can actually see things that other peoplecan’t see. But you can’t reach that monumental goal by simplydeclaring that you’re going to somehow conjure up all of the data inone place — instead you have to continually iterate, execute, evalu‐ate and improve, just like when you are developing software.

If you want to do a better job with the quality of the data you areanalyzing, you’ve got to develop information-seeking behaviors. Thedesire to look at more information and use more data sources, givesyou better signals from the data and uncovers more potential sour‐ces of insight. This creates a virtuous cycle: as data is utilized and

52 | Chapter 5: From DevOps to DataOps

processed, it becomes well-organized and accessible, allowing moredata to emerge and enter the ecosystem.

Any enterprise data professional knows that data projects canquickly become insurmountable if they rely heavily on manual pro‐cesses. DataOps requires automating many of these processes toquickly incorporate new data into the existing knowledge base. Firstgeneration DataOps tools (such as Tamr’s Data Unification plat‐form) focus on making agile data management easier.

Integrating DataOps into Your OrganizationMuch of what falls under the umbrella of big data analytics today ismostly idiosyncratic and manual processes for breaking-down data.Often, companies will have hundreds of people sifting through datafor connections, or trying to find overlap and repetition. Despite theinvestment of these resources, new sources of data actually makethis work harder — much, much harder — which means more datacan limit instead of improve outcomes. DataOps tools will eliminatethis hypo-linear relationship between data sources and the amountof resources required to manage them, making data managementautomated and truly scalable.

To integrate this revolutionary data management method into anenterprise, you need two basic components. The first is cultural —enterprises need to create an environment of communication andcooperation among data analytics teams. The second component istechnical — workflows will need to be automated with technologieslike machine learning to recommend, collect, and organize informa‐tion. This groundwork will help radically simplify administrativedebt and vastly improve the ability to manage data as it arrives.

Integrating DataOps into Your Organization | 53

Figure 5-2. Four processes of DataOps

The Four Processes of DataOpsFour processes work together to create a successful DataOps work‐flow:

• engineering• integration• quality• security

If you treat these processes within the context of DataOps, theywork together to create meaningful methods of handling enterprisedata. Without them, working with data becomes expensive,unwieldy or worse — unsecure.

Data EngineeringOrganizations trying to leverage all the possible advantages derivedfrom mining their data need to move quickly to create repeatableprocesses for productive analytics. Instead of starting with a specificanalytic in mind, and working through a manual process to get tothat endpoint, the data sifting experience should be maximized so

54 | Chapter 5: From DevOps to DataOps

that the most traditionally challenging, but least impactful, aspectsof data analysis are automated.

Take, for example, the management of customer information in aCRM database or other database product. Sorting through customerdata to make sure that the information is accurate is a challenge thatmany organizations either address manually — which is bad — ordon’t address at all, which is worse. No company should be expectedto have bad data or be overwhelmed by working with their data inan age when machine learning can be used as a balm to these prob‐lems.

The central problem of previous approaches to data managementwas the lack of automation. The realities of manually bringingtogether data sources restricted projects’ goals and therefore limitedthe focus of analytics — and if the analytical outcomes did notmatch the anticipated result, the whole effort was wasted. Moving toDataOps ensures that foundational work for one project can give ajump-start to the next, which expands the scope of analytics.

A bias towards automation is even more critical when addressingthe huge variety of data sources that enterprises have access to. Onlyenterprises that engineer with this bias will truly be able to be data-driven — because only these enterprises will begin to approach thatlofty goal of gaining a handle on all of the enterprise’s data.

To serve your enterprise customers the right way, you have to deliverthe right data. To do this, you need to engineer a process that auto‐mates getting the right data to your customers, and to make surethat the data is well integrated for that customer.

Data IntegrationData integration is the mapping of physical data entities, in order tobe able to differentiate one piece of data from another.

Many data integration projects fail because most people and systemslack the ability to differentiate data correctly for a particular use case.There is no one schema to rule them all; rather, you need the abilityto flexibly create new logical views of your data within the context ofyour users’ needs. Existing processes that enterprises have createdusually merge information too literally — leading to inaccurate datapoints. For example, often you will find repetitive customer names,or inaccurate email data for a CRM project; or physical attributes

The Four Processes of DataOps | 55

like location or email addresses may be assigned without being vali‐dated.

Tamr’s approach to data integration is “machine driven, human gui‐ded.” The “machines” (computers running algorithms) organize cer‐tain data that is similar and should be integrated into one data point.A small team of skilled analysts validate whether the data is right orwrong. The feedback from the analysts informs the machines, con‐tinually improving the quality of automation over time. This cyclecan remove inaccuracies and redundancies from data sets, which isvital to finding value and creating new views of data for each usecase.

This is a key part of DataOps, but it doesn’t work if there is nothingactionable that can be drawn from the data being analyzed. Thatvalue depends on the quality of the data being examined.

Data QualityQuality is purely subjective. DataOps moves you toward a systemthat recruits users to improve data quality in a bottom-up, bidirec‐tional way. The system should be bottom-up in the sense that dataquality is not some theoretical end state imposed on the data fromon high, but rather is the result of real users engaging with andimproving the data. It should be bidirectional in that the data can bemanipulated and dynamically changed.

If a user discovers some weird pattern or duplicates while analyzingdata, resolving these issues immediately is imperative; your systemmust give users this ability to submit instant feedback. It is alsoimportant to be able to manipulate and add more data to anattribute as correlating or duplicate information is uncovered.

Flexibility is also key — the user should be open to what the datareveals, and approach the data as a way to feed an initial conjecture.

Data SecurityCompanies usually approach data security in one of two ways —they either apply the concept of access control, or they monitorusage.

The idea of an access control policy is that there has to be a way totrace back who has access to which information. This ensures thatsensitive information rarely falls into the wrong hands. Actually

56 | Chapter 5: From DevOps to DataOps

implementing an access control policy can slow down the process ofdata analysis – and this is the existing infrastructure for most organ‐izations today.

At the same time, many companies don’t worry about who hasaccess to which sets of data. They want data to flow freely throughthe organization, and put a policy in place about how informationcan be used and they watch what people use and don’t use. Thisallows for a more free-flowing process, but it also leaves companiespotentially susceptible to malicious misuse of data.

Both of these data protection techniques pose a challenge to com‐bining various data sources, and make it tough for the right infor‐mation to flow freely.

As part of a system that uses DataOps, these two approaches need tobe combined. There needs to be some access control and use moni‐toring. Companies need to manage who is using their data and why,and they also always need to be able to trace back how people areusing the information they may be trying to leverage to gain new bigdata insights. This framework for managing the security of yourdata is necessary if you want to create a broad data asset that is alsoprotected. Using both approaches — combining some level of accesscontrol with monitor usage — will make your data more fluid andsecure.

Better information, analytics, and decisionsBy incorporating DataOps into existing data analysis processes, acompany stands to gain a more granular, better-quality understand‐ing of the information they have and how best to use it. The mosteffective way to maximize a system of data analytics is through view‐ing data management not as an unwieldy monolithic effort, butrather as a fluid, incremental process that aligns the goals of manydisciplines.

If you balance out the four processes we’ve discussed above (engi‐neering, integration, quality, and security), you’ll empower the peo‐ple in your organization and give them a game-changing way tointeract with data, and create analytical outcomes that improve thebusiness.

Just as the movement to DevOps fueled radical improvements in theoverall quality of software, and unlocked the value of information

Better information, analytics, and decisions | 57

technology to many organizations, DataOps stands to radicallyimprove the quality and access to information across the enterprise,unlocking the true value of enterprise data.

58 | Chapter 5: From DevOps to DataOps

CHAPTER 6

Data Unification Brings Out theBest in Installed Data

Management Strategies

—James Markarian

Companies are now investing heavily in technology designed tocontrol and analyze their expanding pools of data — spending $44billion for big data analytics alone, in 2014. In relation, data manage‐ment software now accounts for over 40 percent of the total spend onsoftware in the U.S. With companies focusing on strategies likeExtract, Transform, Load (ETL); Master Data Management (MDM);and data lakes, it’s critical to understand that while these technolo‐gies can provide a unique and significant handle on data, they stillfall short in terms of speed and scalability — with the potential todelay, or fail to surface insights that can propel better decision-making.

Data is generally too siloed and too diverse for systems like ETL,MDM, and data lakes, and analysts are spending too much timefinding and preparing data manually. On the other hand, the natureof this work defies complete automation. Data unification is anemerging strategy that catalogs data sets, combines data across theenterprise and publishes the data for easy consumption. Using dataunification as a front-end strategy can quicken the feed of highly-organized data into ETL, MDM and data lakes — increasing thevalue of these systems and the insights they enable. In this chapter,we’ll explore how data unification works with installed data manage‐

59

ment solutions — allowing businesses to embrace data volume andvariety for more productive data analysis.

Positioning ETL and MDMWhen enterprise data management software first emerged, it wasbuilt to address data variety and scale. ETL technologies have beenaround in some form since the 1980s. Today, the ETL vendor mar‐ket is full of large, established players, including Informatica, IBM,and SAP, with mature offerings that boast massive installed basesspanning virtually every industry. ETL makes short work of repack‐aging data for a different use, for example, taking inventory datafrom a car parts manufacturer and plugging it into systems at deal‐erships that provide service, or cleaning customer records for moreefficient marketing efforts.

Extract, Transform, LoadMost major applications are built using Extract, Transform, Load(ETL) products, from finance and accounting applications to opera‐tions. ETL products have three primary functions for integratingdata sources into single, unified datasets for consumption:

1. Extract data from data sources within and outside of the enter‐prise

2. Transform the data to fit the particular needs of the target store,which includes conducting joins, rollups, lookups, and cleaningof the data

3. Load the resulting transformed dataset into a target repository,such as a data warehouse for archiving and auditing, a reportingtool for advanced analytics (e.g., business intelligence), or anoperational database/flat file to act as reference data

Master Data ManagementMaster Data Management (MDM) arrived shortly after ETL to cre‐ate an authoritative, top-down approach to data verification. A cen‐tralized dataset serves as a “golden record,” holding the approvedvalues for all records. It performs exacting checks to assure the cen‐tral data set contains the most up-to-date and accurate information.For critical business decision-making, most systems depend on a

60 | Chapter 6: Data Unification Brings Out the Best in Installed Data Management Strategies

consistent definition of master data, which is information referringto core business operational elements. The primary functions ofmaster data management include:

• Consolidating all master data records to create a comprehen‐sive understanding of each entity, such as an address or dollarfigure.

• Establishing survivorship, or selecting the most appropriateattribute values for each record.

• Cleansing the data by validating the accuracy of the values.• Ensuring compliance of the resulting single ‘good’ record

related to each entity as it is added or modified.

Clustering to Meet the Rising Data TideEnterprise data has changed dramatically in the last decade — creat‐ing new difficulties for products that were built to handle mostlystatic data, from relatively few sources. These products have beenextended and overextended to adjust to modern enterprise datachallenges, but the work-around strategies and patches that havebeen developed are no match for current expectations.

Today’s tools, like Hadoop and Spark, help organizations reduce thecost of data processing and give companies the ability to host mas‐sive and diverse datasets. With the growing popularity of Hadoop, asignificant number of organizations have been creating data lakes,where they store data derived from structured and unstructureddata sources, in their raw formats.

Upper management and shareholders are challenging their compa‐nies to become more competitive using this data. Businesses need tointegrate massive information silos – both archival and streaming -and accommodate sources that change constantly in content andstructure. Further, every organizational change brings new demandfor data integration or transformation. The cost in time and effort tomake all of these sources analysis-ready is prohibitive.

There is a chasm between the data we can access thanks to Hadoopand Spark and the ordered information we need to perform analysis.While Hadoop, ETL, and MDM technologies (as well as many oth‐ers) prove to be useful tools for storing and gaining insight from

Clustering to Meet the Rising Data Tide | 61

data, collectively they can’t resolve the problem of bringing massiveand diverse datasets to bear on time-sensitive decisions.

Embracing Data Variety with Data UnificationData variety isn’t a problem; it is a natural and perpetual state. Whilea single data format is the most effective starting point for analysis,data comes in a broad spectrum of formats for good reason. Thesedata sets typically originate in their most useful formats, and impos‐ing a single format on data negatively impacts that original useful‐ness.

This is the central struggle for organizations looking to competethrough better use of data. The value of analysis is inextricably tiedto the amount and quality of data used, but data siloed throughoutthe organization is inherently hard to reach and hard to use. Theprevailing strategy is to perform analysis with the data that is easiestto reach and use, putting expediency over diligence in the interest ofusing data before it becomes out of date. For example, a review ofsuppliers may focus on the largest vendor contracts, focusing onsmall changes that might make a meaningful impact, rather thanaccounting for all vendors in a comprehensive analysis that returnsfive times the savings.

Data unification represents a philosophical shift, allowing data to beraw and organized at the same time. Without changing the sourcedata, data unification prepares the varying data sets for any purposethrough a combination of automation and human intelligence.

The process of unifying data requires three primary steps:

1. Catalog: Generate a central inventory of enterprise metadata. Acentral, platform-neutral record of metadata, available to theentire enterprise, provides visibility of what relevant data isavailable. This enables data to be grouped by logical entities(customers, partners, employees), making it easier for compa‐nies to discover and uncover the data necessary to answer criti‐cal business questions.

2. Connect: Make data across silos ready for comprehensive anal‐ysis at any time while resolving duplications, errors, and incon‐sistencies among source data’s attributes and records. Scalabledata connection enables data to be applied to more kinds of

62 | Chapter 6: Data Unification Brings Out the Best in Installed Data Management Strategies

business problems. This includes matching multiple entities bytaking into account relationships between them.

3. Publish: Deliver the prepared data to the tools used within theenterprise, to perform analysis — from a simple spreadsheet tothe latest visualization tools. This can include functionality thatallows users to set custom definitions and enrich data on the fly.By being able to manipulate external data as easily as if it weretheir own, business analysts can use the data to resolve ambigui‐ties, fill in gaps, enrich their data with additional columns andfields, and more.

Data Unification Is AdditiveData unification has significant value on its own, but when added toan IT environment that already includes strategies like ETL, MDMand data lakes, it turns those technologies into the best possible ver‐sions of themselves. It creates an ideal data set for these technologiesto perform the functions for which they are intended.

Data unification and Master Data ManagementThe increasing volume and frequency of change pertaining to datasources poses a big threat to MDM speed and scalability. Given thehighly manual nature of traditional MDM operations, managingmore than a dozen data sources requires a large investment in timeand money. Consequently, it’s often very difficult to economically-justify scaling the operation to cover all data sources. Additionally,the speed at which data sources are integrated is often contingent onhow quickly employees can work, which will be at an increasinglyunproductive rate as data increases in volume.

Further, MDM products are very deterministic and up-front in thegeneration of matching rules. It requires manual effort to under‐stand what constitutes potential matches, and then define appropri‐ate rules for matching. For example, in matching addresses, therecould be thousands of rules that need to be written. This processbecomes increasingly difficult to manage as data sources becomegreater in volume; as a result, there’s the risk that by the time newrules (or rule changes) have been implemented, business require‐ments have changed.

Data Unification Is Additive | 63

Using data unification, MDM can include the long tail of data sour‐ces as well as handle frequent updates to existing sources — reduc‐ing the risk that the project requirements will have changed beforethe project is complete. Data unification, rather than replacingMDM, works in unison with it as a system of reference, recom‐mending new ‘golden records’ via matching capability and acting asa repository for keys.

Data unification and ETLETL is highly manual, slow, and not scalable to the number of sour‐ces used in contemporary business analysis. Integrating data sourcesusing ETL requires a lot of up-front work to define requirements,target schemas, and establish rules for matching entities andattributes. After all of this up-front work is complete, developersneed to manually apply these rules to match source data attributes tothe target schema, as well as deduplicate or cluster entities thatappear in many variations across various sources.

Data unification’s probabilistic matching provides a far better enginethan ETL’s rules when it comes to matching records across all ofthese sources. Data unification also works hand-in-hand with ETLas a system of reference to suggest transformations at scale, particu‐larly for joins and rollups. This results in a faster time-to-value andmore scalable operation.

Changing infrastructureAdditionally, data unification solves the biggest challenges associ‐ated with changing infrastructure, namely unifying datasets inHadoop, to connect and clean the data, so that it’s ready for analyt‐ics. Data unification creates integrated, clean datasets with unrivaledspeed and scalability. Because of the scale of business data today, it isvery expensive to move Hadoop-based data outside of the data lake.Data unification can handle all of the large-scale processing withinthe data lake, eliminating the need to replicate the entire data set.

Data unification delivers more than technical benefits. In unifyingenterprise data, enterprises can also unify their organization. By cat‐aloging and connecting dark, disparate data into a unified view, forexample, organizations illuminate what data is available for analysts,and who controls access to the data. This dramatically reduces dis‐

64 | Chapter 6: Data Unification Brings Out the Best in Installed Data Management Strategies

covery and prep effort for business analysts and “gatekeeping” timefor IT.

Probabilistic Approach to Data UnificationThe probabilistic approach to data unification is reminiscent ofGoogle’s full-scale approach to web search and connection. Thisapproach draws from the best of machine and human learning tofind and connect hundreds or thousands of data sources (both visi‐ble and dark) vs. the few that are most familiar and easiest to reachwith traditional technologies.

The first step in using a probabilistic approach is to catalog all meta‐data available to the enterprise in a central, platform-neutral placeusing both machine learning and advanced collaboration capabili‐ties. The data unification platform automatically connects the vastmajority of sources while resolving duplications, errors, and incon‐sistencies among source data of attributes and records. The next stepis critical to the success of a probabilistic approach — where algo‐rithms can’t resolve connections automatically, the system must callfor expert human guidance. It’s integral that the system work withpeople in the organization familiar with the data, to have themweigh-in on mapping and improving the quality and integrity of thedata. While expert feedback can be built into the system to improvethe algorithms, it will always play a role in this process. Using thisapproach, the data is then provided to analysts in a ready-to-consume condition, eliminating the time and effort required fordata preparation.

Probabilistic Approach to Data Unification | 65