企业级大数据湖-全-

企业级大数据湖（全）

原文：zh.annas-archive.org/md5/4fbaabadb8bbc4b1aa4f0f7f3b941d59

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

近年来，许多企业已经开始尝试使用大数据和云技术来构建数据湖，支持数据驱动的文化和决策，但是这些项目经常停滞或失败，因为在互联网公司行之有效的方法必须为企业所适应，并且没有全面的实用指南来成功做到这一点。我写这本书是希望提供这样一个指南。

作为 IBM 和 Informatica（主要数据技术供应商）的高管，Menlo Ventures（一家领先的风投公司）的创业者驻地企业家，以及 Waterline（一家大数据初创公司）的创始人兼 CTO，在这些角色中，我很幸运有机会与数百名专家、远见者、行业分析师和实践者交流，探讨构建成功数据湖和创建数据驱动文化的挑战。这本书是我在社交媒体到银行和政府机构等各行各业以及首席数据官和其他 IT 高管、数据架构师、数据科学家和业务分析师等角色中遇到的主题和最佳实践的综合。

大数据、数据科学和分析支持数据驱动的决策，承诺为我们与数据合作、与客户合作以及寻找治愈癌症的方法带来前所未有的洞察力和效率，但数据科学和分析依赖于对历史数据的访问。鉴于此，公司正在部署大数据湖，将所有数据汇聚到一个地方并开始保存历史数据，以便数据科学家和分析师可以访问他们所需的信息，从而实现数据驱动的决策。企业级大数据湖弥合了现代互联网公司自由文化与数据是所有实践核心、每个人都是分析师、大多数人能编码并自行处理数据集的鸿沟，以及企业数据仓库之间的差异，后者将数据视为宝贵商品，由专业 IT 人员精心管理，并以精心准备的报告和分析数据集的形式提供。

为了取得成功，企业数据湖必须提供三个新能力：

• 成本效益、可扩展的存储和计算，以便可以存储和分析大量数据而不会产生禁止性的计算成本

• 成本效益的数据访问和治理，使每个人都能找到并使用正确的数据，而不会产生与编程和手动即时数据获取相关的昂贵人力成本

• 分层治理访问，使不同级别的数据根据用户的需求和技能水平以及适用的数据治理政策可以被不同用户访问

Hadoop、Spark、NoSQL 数据库和弹性云基础系统是令人兴奋的新技术，实现了成本效益和可扩展存储和计算的第一个承诺。虽然它们仍在成熟过程中并面临任何新技术固有的一些挑战，但它们正在迅速稳定并成为主流。然而，这些强大的技术仅实现了成本效益和分层数据访问的第一个承诺。因此，当企业创建大型集群并摄入大量数据时，他们发现，他们不是在拥有一个数据湖，而是一个数据泥潭——一个庞大的无法使用或理解的数据集合，对于任何决策来说都太危险。

本书指导读者理解和实践大数据湖的所有承诺，并探讨了启动和扩展数据湖的各种方法，包括数据水坑（分析沙盒）和数据池（大数据仓库），以及从头开始构建数据湖。它探讨了不同数据湖架构的利弊——本地部署、基于云的和虚拟的，并涵盖了设置不同区域以容纳从原始未处理数据到精心管理和汇总数据的一切，并管理对这些区域的访问。它解释了如何实现自助服务，让用户自行找到、理解和提供数据；如何为具有不同技能水平的用户提供不同的界面；以及如何在符合企业数据治理政策的情况下完成所有这些操作。

谁应该阅读本书？

本书面向大型传统企业的以下受众：

• 数据服务和治理团队：首席数据官和数据监护人

• IT 高管和架构师：首席技术官和大数据架构师

• 分析团队：数据科学家、数据工程师、数据分析师和分析负责人

• 合规团队：首席信息安全官、数据保护官、信息安全分析师和法规合规负责人

本书利用了我 30 年的职业生涯，开发先进的数据技术并与世界上一些最大的企业合作解决他们最棘手的数据问题。它借鉴了来自世界领先的大数据公司和企业的最佳实践，通过实用的从业者和行业专家的文章和成功案例，提供了一个全面指南，教你如何架构和部署一个成功的大数据湖。如果您有兴趣利用这些令人兴奋的新大数据技术和方法为企业提供的机会，这本书是一个绝佳的起点。管理层可能希望阅读一次，并在工作场所出现大数据问题时定期参考它，而对于实际从业者来说，它可以作为他们规划和执行大数据湖项目时的有用参考。

本书中使用的约定

本书使用以下排版约定：

斜体

表示新术语、URL、电子邮件地址、文件名和文件扩展名。

等宽字体

用于程序清单，以及在段落内引用程序元素，如变量或函数名称、数据库、数据类型、环境变量、语句和关键字。

等宽斜体

显示应用程序列表中应由用户提供的值或由上下文确定的值。

奥莱利在线学习

注

近 40 年来，奥莱利传媒一直为企业提供技术和商业培训、知识和见解，帮助公司取得成功。

我们独特的专家和创新者网络通过书籍、文章、会议以及我们的在线学习平台分享他们的知识和专业知识。奥莱利的在线学习平台为您提供按需访问的实时培训课程、深入学习路径、交互式编码环境，以及奥莱利及其他 200 多家出版商的大量文本和视频内容。欲了解更多信息，请访问http://oreilly.com。

如何联系我们

请将有关本书的评论和问题发送至出版商：

• 奥莱利传媒公司

• 1005 Gravenstein Highway North

• Sebastopol, CA 95472

• 800-998-9938（美国或加拿大）

• 707-829-0515（国际或本地）

• 707-829-0104（传真）

我们为本书建立了一个网页，列出勘误、示例和任何其他信息。您可以访问http://bit.ly/Enterprise-Big-Data-Lake。

要对本书发表评论或提出技术问题，请发送电子邮件至bookquestions@oreilly.com。

有关我们的图书、课程、会议和新闻的更多信息，请访问我们的网站http://www.oreilly.com。

在 Facebook 上找到我们：http://facebook.com/oreilly

在 Twitter 上关注我们：http://twitter.com/oreillymedia

在 YouTube 上关注我们：http://www.youtube.com/oreillymedia

致谢

首先，我要深深感谢所有与我分享他们的故事、专业知识和最佳实践的专家和从业者——这本书是为您而写的！

也特别感谢所有帮助我完成这个项目的人。这是我的第一本书，没有他们的帮助，我真的无法完成它。感谢：

• O'Reilly 团队：Andy Oram，我的 O'Reilly 编辑，在我精疲力竭时为这本书注入新生，并帮助将其从意识流状态提升到一定程度的连贯性；Tim McGovern，最初的编辑，帮助推动这本书的起步；Rachel Head，拷贝编辑，经过两年多的写作、编辑、重写、审阅、再重写、再编辑之后，她令我震惊地发现书籍还能做出多么多的改进；还有 Kristen Brown，负责引导书籍走向出版过程。

• 行业内的贡献者们在他们的文章中分享了他们的思考和最佳实践，你将在书中找到他们的名字和简介。

• 那些通过他们新鲜的视角、批判的眼光和行业专业知识做出了巨大改进的审阅者们：Sanjeev Mohan，Opinder Bawa 和 Nicole Schwartz。

最后，这本书的诞生离不开我美好家庭的支持和爱—我的妻子 Irina，我的孩子们 Hannah，Jane，Lisa 和 John，以及我的妈妈 Regina—还有我的朋友们和我美好的 Waterline 家人。

第一章：数据湖介绍

数据驱动的决策正在改变我们的工作和生活方式。从数据科学、机器学习和高级分析到实时仪表盘，决策者需要数据来帮助做出决策。像 Google、Amazon 和 Facebook 这样的公司是以数据驱动为主导的巨头，正在通过利用数据来接管传统业务。金融服务组织和保险公司一直以来都是数据驱动的，量化分析和自动交易处于领先地位。物联网正在改变制造业、交通运输、农业和医疗保健。从各个行业的政府和公司到非营利组织和教育机构，数据被视为一个游戏规则的改变者。人工智能和机器学习正在渗透我们生活的方方面面。世界正在因为其潜力而狂热地消耗数据。我们甚至为这种狂热有一个术语：大数据，由 Gartner 的 Doug Laney 根据三个 V（容量、多样性和速度）定义，后来他又添加了第四个 V，也是我认为最重要的 V——真实性。

随着如此多的多样性、数量和速度，旧系统和流程已经无法支持企业的数据需求。对于高级分析和人工智能来说，数据的真实性是一个更大的问题，因为在统计和机器学习模型中，“GIGO”（垃圾进 = 垃圾出）原则更加关键，几乎不可能判断数据是否有误导致了错误的决策，还是模型本身存在问题。

为了支持这些努力并解决这些挑战，数据管理正在发生革命，涉及数据的存储、处理、管理和提供给决策者的方式。大数据技术实现了比传统数据管理基础设施可能的规模性和成本效率的数量级增长。自服务正在取代过去精心设计和劳动密集型方法，过去需要 IT 专业人员创建良好治理的数据仓库和数据集市，但需要数月才能进行任何更改。

数据湖 是一种大胆的新方法，它利用大数据技术的力量，与自服务的灵活性结合起来。今天，大多数大型企业都已经部署了或正在部署数据湖。

这本书是基于与一百多个组织的讨论而写成的，这些组织涵盖了从新型数据驱动公司如 Google、LinkedIn 和 Facebook 到政府和传统企业的数据湖计划、分析项目、经验和最佳实践。该书旨在面向正在考虑构建数据湖、正在构建数据湖或已经构建了数据湖但难以提高其生产力和广泛采纳的 IT 高管和从业者。

什么是数据湖？我们为什么需要它？它与我们已有的有什么不同？本章节提供了一个简要概述，将在接下来的章节中详细展开。为了保持摘要简洁，我不打算在这里详细解释和探讨每个术语和概念，而是将深入讨论留到后续章节。

数据驱动的决策正在风靡。从数据科学、机器学习和高级分析到实时仪表盘，决策者们都需要数据来帮助做出决策。这些数据需要一个家，而数据湖是创建这个家的首选解决方案。这个术语是由 Pentaho 的首席技术官詹姆斯·迪克森（James Dixon）发明并首次描述的，他在他的博客中写道：“如果你把数据集市比作装瓶水的商店——经过清洁、包装和结构化，方便消费——那么数据湖则是一个更 自然 状态的大水体。数据湖的内容从源头流入填满湖泊，并供湖泊的 各种用户 检查、潜入或取样。”我用斜体强调了关键点，它们是：

• 数据是以其原始形式和格式 (自然 或原始数据) 存在。

• 数据被 各种用户 使用（即大型用户群体访问和可访问）。

本书关注如何构建一个数据湖，将原始（以及经过处理的）数据带给业务分析师的大型用户群体，而不仅仅是用于 IT 驱动的项目。使原始数据可供分析师进行自助服务分析的原因在于，自助服务已成为数据民主化的重要巨大趋势。它始于使用自助可视化工具如 Tableau 和 Qlik（有时被称为 数据发现 工具），让分析师能够分析数据而不必从 IT 获取帮助。自助服务的趋势继续发展，包括帮助分析师整理数据以进行分析的数据准备工具，帮助分析师找到他们需要的数据的目录工具以及帮助进行高级分析的数据科学工具。对于通常被称为数据科学的更高级分析，一个名为数据科学家的新用户类别也通常把数据湖作为他们的主要数据来源。

当然，自助服务面临的一个大挑战是治理和数据安全。每个人都同意数据必须保持安全，但在许多受监管的行业中，有指定的数据安全政策必须实施，而且给分析师访问所有数据是非法的。甚至在一些非受监管的行业中，这被认为是一个坏主意。问题变成了，我们如何在不违反内部和外部数据合规法规的情况下向分析师提供数据？这有时被称为数据民主化，并将在后续章节中详细讨论。

数据湖成熟度

数据湖是一个相对较新的概念，因此定义您可能观察到的成熟阶段，并清楚阐明这些阶段之间的区别是非常有用的：

• 数据水坑基本上是使用大数据技术构建的单一用途或单一项目数据集市。这通常是采用大数据技术的第一步。数据水坑中的数据加载是为单个项目或团队的目的而进行的。通常情况下，这些数据是众所周知且深入理解的。采用大数据技术而不是传统数据仓库的原因是为了降低成本并提供更好的性能。

• 数据池是数据水坑的集合。它可能类似于设计不佳的数据仓库，实际上是共同放置的数据集合，或者它可能是现有数据仓库的卸载。虽然技术成本较低且可扩展性更好是明显且有吸引力的优点，但这些结构仍需要高水平的 IT 参与。此外，数据池将数据限制为仅满足项目需要的数据，并且仅用于需要该数据的项目。考虑到高 IT 成本和有限的数据可用性，数据池实际上并未帮助我们实现数据使用民主化或推动业务用户的自助服务和数据驱动决策的目标。

• 数据湖与数据池在两个重要方面有所不同。首先，它支持自助服务，业务用户能够找到并使用他们想要的数据集，无需依赖 IT 部门的帮助。其次，它旨在包含业务用户可能会需要的数据，即使当前没有项目需要使用这些数据。

• 数据海洋扩展了自助服务数据和数据驱动的决策到所有企业数据，无论数据是否加载到数据湖中。

图 1-1 展示了这些概念之间的区别。随着成熟度从水坑到池塘再到湖泊再到海洋的增长，数据量和用户数量有时会显著增长。使用模式从高度依赖 IT 的互动转变为自助服务，数据也扩展到超出当前项目所需的范围。

图 1-1. 成熟度的四个阶段

数据池和数据湖之间的关键区别在于焦点。数据池提供了相对于现有的关系型数据仓库和数据集市更廉价和更可扩展的技术替代方案。而后者侧重于运行例行、生产就绪的查询，数据湖使业务用户能够利用数据自主做出决策，通过使用各种新类型的数据和工具进行自由分析和实验，正如图 1-2 所示。

在深入探讨如何创建成功的数据湖之前，让我们更仔细地看看导致其之前的两个成熟阶段。

图 1-2. 数据湖的价值主张

数据池

数据池通常为一个小而专注的团队或专业用例构建。这些“池子”是由单个团队拥有的中等规模的数据集合，通常由业务单位在云中使用影子 IT 构建。在数据仓库时代，每个团队习惯为其项目构建关系型数据集市。构建数据池的过程非常相似，只是使用了大数据技术。通常，数据池是为需要大数据强大规模支持的项目而构建的。许多高级分析项目，如那些专注于客户流失或预测性维护的项目，属于这一类别。

有时，数据池被构建来帮助 IT 处理自动化计算密集和数据密集的流程，比如详细介绍的数据抽取、转换和加载（ETL）卸载，其中所有的转换工作从数据仓库或昂贵的 ETL 工具转移到大数据平台上。另一个常见的用途是为单个团队提供一个工作区，称为沙盒，供数据科学家进行实验。

数据池通常范围小、数据种类有限；它们由小型、专用的数据流填充，并且构建和维护它们需要高度技术的团队或者 IT 的深度参与。

数据池

数据池是数据小块的集合。正如您可以将数据小块视为使用大数据技术构建的数据集市，您可以将数据池视为使用大数据技术构建的数据仓库。它可能是有机地形成的，随着更多小块被添加到大数据平台。创建数据池的另一种流行方法是作为数据仓库卸载的一部分。与 ETL 卸载不同，后者使用大数据技术执行一些处理以填充数据仓库所需，这里的想法是将数据仓库中的所有数据加载到大数据平台中。其愿景通常是最终摆脱数据仓库以节省成本并提高性能，因为与关系数据库相比，大数据平台要便宜得多且可扩展性更强。然而，仅仅卸载数据仓库并不能使分析师访问原始数据。因为数据仓库所遵循的严格架构和治理依然存在，组织无法解决数据仓库的所有挑战，比如长期且昂贵的变更周期、复杂的转换以及作为所有报告基础的手工编码。最后，分析师通常不喜欢从经过精细调整的、具有闪电般快速查询的数据仓库转移到预测性较差得多的大数据平台，虽然在大数据平台上大批量查询可能比数据仓库中快，但更典型的小查询可能需要几分钟。图 1-3 展示了数据池的一些典型局限性：缺乏预测性、敏捷性和访问原始未经处理数据的能力。

图 1-3. 数据仓库卸载的缺点

创建成功的数据湖

那么，成功的数据湖需要什么？与任何项目一样，将其与公司的业务策略对齐，并获得高管赞助和广泛支持至关重要。此外，基于与部署数据湖的数十家公司的讨论，可以确定三个关键前提条件：

• 正确的平台

• 正确的数据

• 正确的接口

正确的平台

像 Hadoop 和云解决方案（如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform）这样的大数据技术是数据湖的最流行平台。这些技术共享一些重要优势：

体积

这些平台被设计为扩展性外扩——换句话说，可以在不显著降低性能的情况下无限扩展。

成本

我们一直有能力在相对便宜的存储介质上存储大量数据，比如磁带、WORM 磁盘和硬盘。但直到大数据技术出现之前，我们才有能力以如此低廉的成本存储和处理大量数据，通常是商业关系数据库成本的十分之一至百分之一。

多样性

这些平台使用文件系统或对象存储，允许它们存储各种文件：Hadoop HDFS，MapR FS，AWS 的简单存储服务（S3），等等。不像关系型数据库需要预定义数据结构（写入时模式），文件系统或对象存储并不关心你写入了什么。当然，要想有意义地处理数据，你需要知道它的模式，但那只有在使用数据时才需要。这种方法被称为读取时模式，是大数据平台的重要优势之一，促成了所谓的“无摩擦摄入”。换句话说，数据可以在不经任何处理的情况下加载，这与关系型数据库不同，后者必须将数据转换为数据库所期望的模式和格式后才能加载。

未来的保障

因为我们的需求和所处的世界在变化，确保我们拥有的数据能够帮助未来的需求变得至关重要。今天，如果数据存储在关系型数据库中，只能由该关系型数据库访问。另一方面，Hadoop 和其他大数据平台非常模块化。同一个文件可以被各种处理引擎和程序使用——从 Hive 查询（Hive 提供对 Hadoop 文件的 SQL 接口）到 Pig 脚本，再到 Spark 和自定义 MapReduce 作业，各种不同的工具和系统都可以访问和使用同一个文件。由于大数据技术正在迅速发展，这使人们对任何未来项目仍能访问数据湖中的数据充满信心。

正确的数据

今天企业收集的大部分数据都被丢弃了。少部分被汇总并保存在数据仓库中几年，但大多数详细的操作数据、机器生成的数据和旧历史数据要么被汇总，要么完全被丢弃。这使得进行分析变得困难。例如，如果分析人员认识到一些传统上被丢弃的数据的价值，可能需要数月甚至数年才能积累足够的数据历史来进行有意义的分析。因此，数据湖的承诺在于能够尽可能地存储大量数据以供将来使用。

所以，数据湖有点像一个存钱罐（Figure 1-4）——你经常不知道为什么要保存数据，但你希望以防一天需要。此外，因为你不知道如何使用数据，所以过早地转换或处理它是没有意义的。你可以将它看作是带着你的存钱罐在不同国家旅行，在当地货币的国家增加货币，并将内容保留在其原生货币中，直到你决定在哪个国家使用这些钱；然后你可以将所有钱转换为该货币，而不是每次过境时都不必要地转换资金（并支付转换费用）。总结一下，目标是尽可能以其原生格式保存数据。

图 1-4. 数据湖就像一个存钱罐，让你以其原生或原始格式保存数据。

获取正确数据的另一个挑战是数据孤岛。不同部门可能囤积他们的数据，一是因为提供数据困难且昂贵，二是因为在政治和组织上不愿意分享。在典型企业中，如果一个组需要另一个组的数据，它必须解释需要哪些数据，然后拥有数据的组必须实施 ETL 作业以提取和打包所需数据。这是昂贵、困难且耗时的，因此团队可能会尽可能推迟数据请求，然后尽可能长时间地提供数据。这种额外工作常被用作不分享数据的借口。

有了数据湖，因为湖通过无摩擦摄取原始数据（基本上是按原样摄取），这种挑战（和借口）消失了。一个良好治理的数据湖也是集中化的，并为组织内的人们提供获取数据的透明流程，因此所有权不再是障碍。

正确的界面

一旦我们拥有了正确的平台并加载了数据，我们进入了数据湖更为困难的部分，这也是大多数公司失败的地方——选择正确的界面。为了获得广泛采用并享受帮助业务用户做出数据驱动决策的好处，公司提供的解决方案必须是自助服务的，这样他们的用户可以在不需要 IT 帮助的情况下找到、理解和使用数据。IT 简直无法扩展以支持如此庞大的用户群体和如此多样化的数据。

启用自助服务有两个方面：为用户提供适合其专业水平的数据，确保用户能够找到正确的数据。

为用户提供适合其专业水平的数据是另一个挑战。

为了使数据湖得到广泛采用，我们希望所有人，从数据科学家到业务分析师，都能使用它。然而，考虑到这些具有不同需求和技能水平的不同受众时，我们必须小心确保将正确的数据提供给正确的用户群体。

例如，分析师通常没有使用原始数据的技能。原始数据通常具有太多细节，太精细，并且经常存在太多质量问题，以至于难以轻松使用。例如，如果我们收集来自使用不同应用程序的不同国家的销售数据，那么该数据将以不同的格式和不同的字段（例如，一个国家可能有销售税而另一个国家没有）以及不同的计量单位（例如，磅对公斤，美元对欧元）的形式出现。

为了让分析师使用这些数据，必须对其进行协调 —— 将其放入相同的架构中，并使用相同的字段名称和计量单位 —— 并且通常还需要将其聚合到每日产品或每客户的销售额。换句话说，分析师想要“熟制”的准备好的餐点，而不是原始数据。

数据科学家则完全相反。对他们来说，处理过的数据往往会丢失他们正在寻找的重要信息。例如，如果他们想要看看两种产品一起购买的频率，但他们能获取的唯一信息是按产品的日常总量计算，数据科学家将会陷入困境。他们就像需要原材料来制作他们烹饪或分析杰作的厨师。

我们将在本书中看到如何通过设置多个区域来满足不同的需求，这些区域包含满足特定要求的数据。例如，原始区域或着陆区包含输入到数据湖中的原始数据，而生产区或黄金区包含高质量的、受管理的数据。我们将快速查看“组织数据湖”中的区域；更详细的讨论可以在第七章中找到。

获取数据

我与大多数公司交流的情况是，它们都正在采用“购物数据”的范式，分析师使用类似于Amazon.com-style的界面来查找、理解、评价、注释和消费数据。这种方法的优势多种多样，包括：

一个熟悉的界面

大多数人对在线购物都很熟悉，并且喜欢使用关键词搜索和使用分类、评分和评论，因此他们不需要或只需要很少的培训。

分类搜索

搜索引擎被优化用于多层次搜索。当可能的搜索结果数量很大而用户试图找到正确结果时，多层次搜索非常有帮助。例如，如果你在亚马逊搜索烤面包机（图 1-5），多层次搜索将列出制造商、烤面包机是否需要接受贝果、需要烤多少片面包等选项。类似地，当用户搜索合适的数据集时，多层次搜索可以帮助他们指定数据集中希望的属性、数据集的类型和格式、保存数据集的系统、数据集的大小和新鲜度、拥有数据集的部门、数据集的权限以及任何其他有用的特征。

排名和排序

根据特定标准选择正确资产的能力，这是由搜索引擎广泛支持的，并且对于选择合适的资产非常重要。

上下文搜索

随着目录变得更加智能，使用语义理解分析师正在寻找的数据资产的能力将变得更加重要。例如，一个销售人员寻找客户时，可能实际上是在寻找潜在客户，而技术支持人员寻找客户时可能实际上是在寻找现有客户。

图 1-5. 一个在线购物界面

数据污泥

虽然数据湖始终以良好的意图开始，有时候它们会走错方向，最终成为数据污泥。数据污泥是一个数据池，它已经扩展到数据湖的大小，但由于缺乏自助服务和治理设施，未能吸引广泛的分析师社区。在最好的情况下，数据污泥像数据池一样使用，而在最坏的情况下，根本不被使用。通常情况下，虽然各个团队在其项目中使用湖的小区域（图 1-6 中的白色数据池区域），但大部分数据是黑暗的、未记录的和无法使用的。

图 1-6. 一个数据污泥

当数据湖首次出现时，许多公司急忙购买 Hadoop 集群并填充原始数据，但并没有清晰地理解如何利用这些数据。这导致了大量数据污泥的形成，其中包含数百万个文件，总计几十 PB 的数据，但却无法对这些数据做出任何意义上的解释。

只有最复杂的用户能够导航这些沼泽地，通常是通过开辟他们和他们的团队可以利用的小水洼。此外，治理规定禁止在不保护敏感数据的情况下向广大用户开放沼泽地。由于没有人能告诉哪些数据是敏感的，用户无法获得访问权限，数据很大程度上保持不可用和未使用。一位数据科学家与我分享了他的经历，他的公司建立了一个数据湖，将湖中所有数据加密以保护它，并要求数据科学家证明他们想要的数据不是敏感的，然后才会解密并允许他们使用。这被证明是一个进退两难的局面：因为所有东西都被加密了，我跟他谈过的那位数据科学家什么也找不到，更不用说证明它不是敏感的了。结果，没有人在使用这个数据湖（或者正如他所说的，这个沼泽地）。

数据湖成功的路线图

现在我们知道数据湖成功所需及其需要避免的陷阱，那么我们如何开始建设一个数据湖呢？通常，公司按照以下流程进行：

1. 搭建基础设施（启动和运行 Hadoop 集群）。

2. 组织数据湖（为各种用户社区创建使用区域并摄入数据）。

3. 为自助服务设置数据湖（创建数据资产目录，设置权限，并提供分析师使用的工具）。

4. 开放数据湖给用户使用。

建立数据湖

当我在 2015 年开始写这本书时，大多数企业正在使用开源或商业的 Hadoop 分布式在本地构建数据湖。到 2018 年，至少一半的企业要么完全在云中构建他们的数据湖，要么构建混合数据湖，既在本地又在云中。许多公司还拥有多个数据湖。所有这些多样性正在推动公司重新定义数据湖的概念。现在我们看到了逻辑数据湖的概念：跨多个异构系统的虚拟数据湖层。底层系统可以是 Hadoop、关系型数据库或 NoSQL 数据库，在本地或云中。

图 1-7 比较了这三种方法。它们都提供了用户查询数据资产的目录。这些数据资产要么已经在 Hadoop 数据湖中，要么被提供给它，分析师可以使用它们。

图 1-7. 不同的数据湖架构

组织数据湖

我遇到的大多数数据湖大致都是按照不同区域组织的：

• 原始或着陆区，数据被摄入并尽可能保持其原始状态。

• 金牌或生产区，存放清洁、加工后的数据。

• 一个开发或工作区域，更多技术型用户如数据科学家和数据工程师在此进行工作。这个区域可以按用户、项目、主题或其他方式进行组织。一旦工作区中进行的分析工作被产品化，它就会移动到金区。

• 一个敏感区域，包含敏感数据。

图 1-8 展示了这种组织形式。

图 1-8. 典型数据湖的区域

多年来，数据治理团队的普遍看法是，无论数据位于何处或用途如何，都应该受到相同的治理。然而，近年来，来自 Gartner 的行业分析师们开始推广多模式 IT的概念——基本上是治理应反映数据使用和用户社区的需求。这种方法已被数据湖团队广泛采纳，不同的区域具有不同的治理级别和服务级别协议（SLA）。例如，金区的数据通常受到严格的治理，具有良好的策展和文档化，以及质量和新鲜度的 SLA，而工作区的数据则有较少的治理（主要确保没有敏感数据），其 SLA 可能会因项目而异。

不同的用户群体自然而然地倾向于不同的区域。业务分析师主要在金区使用数据，数据工程师在原始区（将其转换为用于金区生产的数据）处理数据，数据科学家则在工作区进行实验。尽管每个区域都需要一定的治理来确保敏感数据被检测和保护，但数据监护人员主要关注敏感区域和金区的数据，以确保其符合公司和政府的法规要求。图 1-9 展示了不同区域的治理级别和不同用户群体。

图 1-9. 区域治理期望

设置自助数据湖

无论是业务分析师、数据分析师还是数据科学家，通常都要经历四个步骤来完成他们的工作。这些步骤在图 1-10 中有所展示。

图 1-10. 分析的四个阶段

第一步是查找和理解数据。一旦找到合适的数据集，他们需要提供数据，即获取对其的访问权限。一旦拥有数据，他们通常需要准备数据，即清理并将其转换为适合分析的格式。最后，他们需要使用数据来回答问题或创建可视化和报告。

理论上，前三个步骤是可选的：如果数据被分析师所熟知并理解，分析师已经可以访问该数据，并且数据已经适合进行分析，那么分析师可以直接进行最后一步。然而实际情况是，大量研究显示，前三个步骤通常占据了典型分析师时间的 80%，其中最大的开销（60%）发生在第一步中，即查找和理解数据（例如参见 Boris Evelson 的《通过融合大数据和商业智能提升您的业务洞察力》，Forrester Research，2015 年 3 月 25 日）。

让我们逐步分析这些，以便让你更好地了解每个阶段发生了什么。

查找和理解数据

为什么在企业中找到数据如此困难？因为可用数据的种类和复杂性远远超出了人类记忆的能力。想象一个非常小的数据库，只有一百个表（一些数据库有数千甚至数万个表，因此这确实是一个非常小的现实生活数据库）。现在想象每个表都有一百个字段——对于大多数数据库来说，特别是数据倾向于去规范化的分析数据库来说，这是一个合理的假设。这给我们带来了 10,000 个字段。有人能记住 10,000 个字段的含义以及这些字段所在的表，并且在使用数据进行新事物时随时跟踪它们，这有多现实呢？

现在想象一下一个企业有几千（或者几十万）个数据库，大多数比我们假设的有 10,000 个字段的数据库大一个数量级。我曾经与一个只有 5,000 名员工的小银行合作过，但他们设法创建了 13,000 个数据库。我只能想象一个有数十万名员工的大银行可能有多少数据库。我说“只能想象”的原因是因为在我职业生涯的 30 年里，我与数百个大型企业合作过，他们无法告诉我他们有多少个数据库——更不用说有多少个表或字段了。

希望这能让你对分析师在寻找数据时面临的挑战有所了解。

一个典型的项目涉及到分析员“四处打听”，看看是否有人曾经使用过某种特定类型的数据。他们被人引荐来引荐去，直到偶然发现某个数据集曾被他人在其项目中使用过。通常情况下，他们不知道这是否是最佳的数据集可供使用，数据集是如何生成的，甚至数据是否可信。然后，他们面临着一个令人痛苦的选择，要么使用这个数据集，要么再继续打听一段时间，也许找不到更好的选择。

一旦决定使用数据集，他们会花费大量时间尝试解读数据集中包含的意义。有些数据显而易见（例如客户姓名或账号），而其他数据则比较神秘（例如客户代码 1126 代表什么？）。因此，分析师还要花费更多时间寻找能帮助他们理解数据的人。我们称这种信息为“部落知识”。换句话说，知识通常是存在的，但它散布在整个部落中，并且必须通过痛苦、漫长和容易出错的发现过程重新组装起来。

幸运的是，有一些新的分析师众包工具正在通过收集部落知识来解决这个问题，该过程允许分析师使用由业务术语组成的简单描述文档化数据集，并建立搜索索引来帮助他们找到所需内容。这些工具已经在谷歌和 LinkedIn 等现代数据驱动公司进行了定制开发。由于在这些公司中数据非常重要且“每个人都是分析师”，因此对问题的认识和为解决方案作出贡献的意愿要高得多，而在传统企业中则低得多。当数据集刚刚创建时，文档化就变得容易得多，因为信息是新鲜的。然而，即使在谷歌，虽然一些热门数据集已经有了很好的文档化，但仍然存在大量暗数据或未文档化的数据。

在传统企业中，情况更为糟糕。除非这些数据集（文件和表格）被使用，否则分析师永远不会对数百万个现有数据集进行文档化，但如果不文档化，这些数据集就永远不会被找到和使用。唯一的实际解决方案是将众包与自动化结合起来。Waterline Data 是我和我的团队开发的工具，用于提供这样的解决方案。它采用从分析师工作的数据集中众包收集的信息，并将其应用于所有其他暗数据集。该过程称为指纹识别：该工具遍历企业中的所有结构化数据，为每个字段添加唯一标识符，并在分析师对字段进行注释或标记时，寻找类似字段并为其提供标签建议。当分析师搜索数据集时，他们既可以看到由分析师标记的数据集，也可以看到由工具自动标记的数据集，并有机会接受或拒绝这些建议的标签。然后，该工具应用机器学习（ML）根据用户反馈改进其自动标记。

核心思想是，单靠人工注释无法胜任数据的广度和复杂性，而纯自动化注释又无法靠谱，因为数据具有独特且不可预测的特征——因此，必须将二者结合起来以达到最佳效果。Figure 1-11 说明了这种良性循环。

图 1-11。利用人类知识和机器学习

访问和供应数据

一旦确定了正确的数据集，分析员需要能够使用它们。传统上，分析员在开始或加入项目时被授予访问权限。然后很少会被收回，因此老成员最终会获得对企业中可能有用的几乎所有数据的访问权限，而新人几乎没有访问权限，因此无法找到或使用任何数据。为了解决数据湖中的数据访问问题，企业通常会选择以下两个极端之一：要么向所有人授予对所有数据的完全访问权限，要么除非分析员能证明有需求，否则所有访问权限都会受到限制。在某些情况下，授予完全访问权限是可行的，但在受监管的行业中则不然。为了使其更可接受，企业有时会去识别敏感数据，但这意味着他们必须做一些可能没有人需要的数据摄取工作。此外，随着法规的变化，可能需要去识别的数据会越来越多（这个话题将在后续章节中深入讨论）。

更实际的方法是在元数据目录中发布所有数据集的信息，这样分析员可以找到有用的数据集，然后根据需要申请访问权限。这些请求通常包括访问的理由、需要数据的项目以及所需的访问时长。这些请求会被路由到所需数据的数据管理员那里。如果他们批准访问权限，访问权限将会被授予一段时间。这段时间可以延长，但不是无限期的，从而消除了传统的访问问题。新的请求也可能会触发去识别敏感数据的工作，但现在只有在需要时才会进行。

数据的供应或物理访问可以通过多种方式授予：

• 用户可以被授予对整个数据集的读取权限。

• 如果只需要部分访问权限，可以创建一个仅包含适合用户数据的文件副本（并保持更新），或者创建一个仅包含分析员应看到的字段和行的 Hive 表或视图。

• 如果需要，可以生成一个去识别版本的数据集，用随机生成的等效信息替换敏感信息，这样所有应用程序仍然能够运行，但不会泄漏敏感数据。

准备数据

有时，数据是完全干净且可以立即用于分析的。不幸的是，大多数情况下，数据需要经过处理才能使其适合分析。数据准备通常涉及以下操作：

塑形

选择要处理的字段和行的子集，将多个文件和表合并成一个（联接），转换和聚合，分桶化（例如，从离散值到范围或桶的转换，例如将 0 到 18 岁的人放入“青少年”桶，将 19 到 25 岁的人放入“青年”桶等），将变量转换为特征（例如，将年龄转换为一个特征，如果一个人超过 65 岁则值为 0，否则为 1），以及许多其他可能的步骤。

清洗

填补缺失值（例如，从名字猜测缺失的性别或在地址数据库中查找地址），纠正错误值，解决冲突数据，将计量单位和代码规范化为常见的单位等。

混合

将不同的数据集调整到相同的模式、相同的计量单位、相同的代码等。

从这些例子中可以看出，数据准备涉及到大量复杂的工作和思考。自动化至关重要，以利用通过转换所学到的经验，并避免在成千上万个表格和数据集上重复相同的繁琐步骤。

最常见的数据准备工具是 Excel。不幸的是，Excel 并不适用于数据湖大小，但是大量新工具为大规模数据集提供了类似 Excel 的功能。例如，Trifacta 应用复杂的机器学习技术来建议转换，并帮助分析员准备数据。许多大型供应商也推出了数据准备工具，像 Tableau 和 Qlik 等分析供应商也在他们的工具中增强了数据准备功能。

分析和可视化

一旦数据准备好，就可以进行分析。分析范围从创建简单的报告和可视化到复杂的高级分析和机器学习。这是一个非常成熟的领域，数百家供应商为各种类型的分析提供解决方案。特别是对于 Hadoop 数据湖，Arcadia Data、AtScale 等公司提供本地运行并利用 Hadoop 处理能力的分析和可视化工具。

数据湖架构

最初，我与大多数公司的交谈中他们认为他们会拥有一个包含所有数据的庞大的本地数据湖。随着他们的理解和最佳实践的发展，大多数企业意识到单一的去中心化点并不理想。在数据主权法规（例如，禁止将数据带出德国）和组织压力之间，多个数据湖通常被证明是更好的解决方案。此外，随着公司意识到支持大规模并行集群的复杂性，并且因为无法找到和雇佣有经验的 Hadoop 和其他大数据平台管理员而感到沮丧，他们开始选择由亚马逊、微软、谷歌等公司的专家管理大部分硬件和平台组件的基于云的数据湖。

公共云中的数据湖

除了访问大数据技术专业知识和快速部署时间的好处外，存储成本低和云计算的弹性特性使其成为实施数据湖的极具吸引力的选择。由于大量数据被存储以备将来使用，因此将其尽可能廉价地存储是有意义的。这与通过亚马逊等提供的各种存储层级支持的成本优化可能性很好地配合：访问速度从高速到冰川级别不等，而慢速访问媒体的价格显著便宜。

此外，云计算的弹性允许在需要时按需启动非常大的集群。与本地集群相比，后者具有固定大小并将数据存储在附加存储中（尽管正在探索具有网络附加存储的新架构）。这意味着随着节点存满数据，需要添加新节点仅用于存储。此外，如果分析负载 CPU 密集且需要更多计算能力，则即使可能仅需短时间使用，也需要添加节点。

在云中，您只需支付所需的存储空间（即不必购买额外的计算节点来获取更多存储空间），并且可以短时间内启动大型集群。例如，如果您有一个 100 节点的本地集群和一个需要 50 小时的作业，则购买和安装 1000 节点仅为了使此作业运行更快是不划算的。然而，在云中，您支付的计算能力大约为 100 节点 50 小时的费用，与 1000 节点 5 小时的费用相当。这是弹性计算的巨大优势。

逻辑数据湖

企业意识到单一集中式数据湖并不是一个好的解决方案后，逻辑数据湖的理念开始流行起来。采用这种方法，不是将所有数据加载到数据湖中以备将来可能需要，而是通过集中目录或数据虚拟化软件向分析师提供数据访问。

逻辑数据湖解决了完整性和冗余性问题，如图 1-12 所示。

图 1-12. 完整性和冗余性问题

这些问题可以总结如下：

完整性

分析师如何找到最佳数据集？如果分析师只能找到已经存在于数据湖中的数据，那么没有被摄取到数据湖中的其他数据将无法找到或使用（如图 1-12 中右侧的弯月区域所示）。

冗余性

如果我们将所有数据摄入数据湖，数据源和数据湖之间将存在冗余（如图 1-12 中两个圆的重叠区域所示）。有了多个数据湖，为了实现完整性，我们需要将相同的数据摄入每个数据湖中。

更糟糕的是，企业中已经存在大量冗余。传统上，在启动新项目时，最便捷和政治上简单的方法是由项目团队启动新的数据集市，从其他来源或数据仓库复制数据，并添加自己的独特数据。这比研究现有数据集市并与当前所有者和用户协商共享使用要容易得多。因此，存在大量几乎相同的数据集市。如果我们将所有这些数据集市中的数据盲目加载到数据湖中，我们的数据湖中将存在极高水平的冗余。

我见过的解决完整性和冗余挑战的最佳方法涉及一些简单的规则：

• 要解决完整性问题，请创建所有数据资产的目录，以便分析师可以找到并请求企业中可用的任何数据集。

• 要解决冗余问题，请按照图 1-13 所示的过程进行操作：

  • 存储在数据湖中没有存储在其他地方的数据。

  • 如果需要，将存储在其他系统中的数据带入数据湖，并在需要时保持同步。

  • 将每个数据集仅一次性地为所有用户引入。

图 1-13. 管理逻辑数据湖中的数据

虚拟化与基于目录的逻辑数据湖

虚拟化（有时也称为联邦化或 EII，用于企业信息集成）是上世纪 80 年代开发的一种技术，并经过几代改进直到 2010 年代。它基本上创建了一个虚拟视图或表，隐藏了物理表的位置和实现方式。在图 1-14 中，通过连接来自不同数据库的两个表创建了一个视图。然后，查询将查询该视图，并由数据虚拟化系统决定如何访问和连接这两个数据库中的数据。

图 1-14. 通过视图创建自定义数据集

尽管这项技术对某些用例效果很好，在逻辑数据湖中，为了实现完整性，需要将每个数据集发布为虚拟表，并在底层表模式更改时保持更新。

即使解决了发布每个数据资产的初始问题，视图仍然存在重大问题：

• 创建虚拟视图并不会使数据更容易找到。

• 从多个异构系统中联接数据是复杂且计算密集型的，通常会对系统造成巨大的负载和长时间的执行周期。这些所谓的分布式联接，涉及到内存容量不足的表，是出名的资源密集型。

相比之下，在基于目录的方法中，仅发布关于每个数据集的元数据，以便使其可找到。然后将数据集配置到同一系统（例如 Hadoop 集群）以在本地处理，如图 1-15 所示。

图 1-15. 通过目录提供元数据

除了使所有数据对分析师可查找和可访问之外，企业目录还可以作为访问、治理和审计的单一访问点，如图 1-16 所示。顶部，没有集中目录，对数据资产的访问处处都有，难以管理和跟踪。底部，有了集中的目录，所有访问请求都通过目录。按需授予特定时间段的访问权限，并由系统进行审计。

图 1-16. 数据配置和治理通过目录

结论

总之，获取正确的平台，加载正确的数据，并通过技能和需求适当的界面组织和设置为自助服务，是创建成功的数据湖的关键。在本书的其余部分，我们将探讨如何完成这些任务。

第二章：历史视角

数据已存在很长时间。首先是视觉形式：洞穴壁画、特定排列的土堆。一旦人类发展出书写系统，他们开始用它们来记录事物：许多古代泥板和手稿似乎包含清单、账簿、买卖和债务的记录。后来，更多的通用数据被收集并出版在年鉴和百科全书中：最长的河流、最高的山脉、最深的湖泊、人口最多的国家、平均降雨量、最高和最低温度等等。我们似乎对测量、计数、比较和追踪有着无尽的迷恋。传统上，这种测量和计数过程是费时且手动的，因此我们发明了机器来帮助我们。最终，这些机器演变成了现代计算机。

很早就显而易见，计算机具有远远超出人类的计数、测量和存储信息的能力。然而，计算机在其他方面也非常擅长，比如应用逻辑和执行业务流程。在计算机早期，大部分关注点都集中在程序和逻辑上。数据被认为是程序的产物，只有原始存储它的程序才能访问并理解它。

为了使数据对人类更易访问，程序员开发了报告，将数据打包成人类可读的形式。如果分析师想以不同方式查看数据，他们必须提出请求并等待开发人员创建新的报告。

自助数据驱动力——数据库的诞生

自助数据革命的第一步是电子表格。它允许非开发人员直接处理数据。分析师第一次能够自行处理数据并将其操纵成他们想要的形状。一旦这只神灯被释放出来，就无法将其收回。但尽管电子表格迅速成为最常见的决策支持工具，它们无法扩展到大量数据，并且只能解决分析师希望解决的问题的一小部分。

与此同时，公司开始意识到数据而非应用程序才是最宝贵的资产。丢失数据意味着业务将停滞不前。数据必须被精心管理，确保一致性，并进行备份。不再让每个程序都自行开发这些能力，而是通过一种新的系统类别提取和提供，这类系统称为数据库管理系统（DBMS）。这些系统不包含编程逻辑，专注于数据管理。

早期系统仍然与应用程序紧密耦合，并需要应用逻辑来理解数据，但随着关系数据库的出现，数据和应用程序之间的分离逐渐得到制度化。

关系型数据库管理系统（RDBMSs）允许用户明确描述数据到数据库中。用户创建一个模式—一组可供人类阅读的表格和字段。而不是总是通过程序获取数据，RDBMSs 的用户能够直接查询数据。最终，一种称为结构化查询语言（SQL）的标准语言出现，并成为数据库的通用语言。使用这种语言，用户可以编写自己的查询并对数据进行分析。

虽然现在可以直接分析应用程序使用的数据，但大多数数据库模式仍然设计用于支持应用程序。由于从磁盘读写数据比在内存中处理数据慢几个数量级，一种称为规范化的模式设计技术将数据分解为尽可能小的块，以确保每个数据库更新尽可能少地写入数据。这对于更新和检索特定数据片段（例如单个客户的信息）效果良好，但在进行大规模分析（例如查看客户所有活动）时效率极低，因为需要连接多个表。

关于关系型数据库理论和模式设计已经写了很多书籍，所以我在这里只介绍关系、主键和外键以及规范化的关键概念。关系数据库包含具有列和行的表格。想象一下，试图将您对客户的所有信息存储在一个表格中—您将有不同客户属性的列，如姓名、地址、年龄、性别等等。现在想象一下，您还想跟踪每位客户的订单。您可以添加新的列用于订单号、日期、金额和其他订单属性。如果每位客户只有一个订单，您将为每位客户及其订单拥有一行。但如果客户下了多个订单呢？您现在是否为每个订单都有一行？这意味着所有客户数据将为每个订单复制一次，如在表 2-1 所示。如果一个客户有一千个订单，他们的数据将被复制一千次。更糟糕的是，如果他们的信息发生变化—例如客户搬家或结婚后更改姓名，您将不得不更新这一千条记录。显然，这不是一种非常有效的方法。

表 2-1. 客户订单表

姓名	性别	婚姻状况	邮政编码	订单号码	金额	日期
玛丽·吴	女	已婚	94301	2123123	987.19	7/12/18
玛丽·吴	女	已婚	94301	2221212	12.20	9/2/18
玛丽·吴	女	已婚	94301	2899821	5680.19	10/15/18
汤姆·琼斯	男	单身	93443	2344332	1500.00	9/12/18

在关系数据库中解决此问题的解决方案称为规范化。这是一种将表分解为较小表以避免重复信息的方法。例如，我们可以将客户信息存储在一张表中，将所有客户的所有订单存储在另一张表中。然后，为了确定哪些订单属于哪些客户，我们会生成一个键，比如顾客 _ID，并将其作为顾客表和订单表的一部分，使得每个订单都包含对应于顾客表中记录的顾客 _ID值的顾客 _ID值。顾客表中的顾客 _ID列(Table 2-2)将被称为主键，因为它唯一标识客户，而订单表中的顾客 _ID列(Table 2-3)将被称为外键，因为它引用了顾客表中的顾客 _ID列。主键预期是唯一的，例如，顾客表中的顾客 ID 将唯一标识每个客户，而外键预期是主键的一个适当子集。如果我们在订单表中有一个不对应于顾客表中任何顾客 _ID值的顾客 _ID值，我们就有了所谓的孤立的外键，将无法确定哪位客户下了该订单。主键和外键之间的这种对应关系称为参照完整性。请注意，通过将数据分解为单独的顾客和订单表，我们可以在顾客表中仅存储一次客户信息，而不管每个客户下了多少订单。

Table 2-2. 顾客表

顾客 _ID	姓名	性别	婚姻状况	邮政编码
112211	Mary Ng	F	已婚	94301
299821	Tom Jones	M	单身	93443

Table 2-3. 订单表

顾客 _ID	订单号	金额	日期
112211	2123123	987.19	7/12/18
112211	2221212	12.20	9/2/18
112211	2899821	56.80.19	10/15/18
299821	2344332	1500.00	9/12/18
299821	2554322	11.99	9/13/18

为了确定例如，已婚客户与未婚客户下了多少订单，查询将必须通过执行称为联接的 SQL 操作从订单和顾客表中组合数据。它看起来会像这样：

select customers.marital_status, sum(orders.total) as total_sales from customers 
join orders on
customers.customer_id = orders.customer_id group by customers.marital_status

此查询将返回每种婚姻状况的订单总数，通过将两个表联接在一起，如 Table 2-4 所示。

Table 2-4. 已婚和单身顾客的总订单数

婚姻状况	总销售额
已婚	2,221,222.12
单身	102,221,222.18

虽然连接非常强大和灵活，但计算成本高昂。对于将数据规范化为数十甚至数百个表的较大系统而言，为每个查询执行所需的所有连接可能会使高度规范化的操作性数据库陷入困境。为了解决这个问题，开发出了一个新的解决方案。其思想是完全将数据与应用程序分离，并实际上将多个应用程序的数据合并到一个系统中，并将该系统用于分析。

分析的必要性——数据仓库的诞生

最初的愿景是创建一个“仓库”，用于存储企业的所有数据和历史信息，并使其可供分析使用。1990 年，沃尔玛创建了其现今著名的数据仓库，通过管理物流，帮助其主导零售界，并引发了分析黄金时代。很快，每个企业都意识到可以从数据中获得巨大的价值，并希望利用它来击败竞争对手。同样重要的是，企业们意识到，如果不投资于分析，竞争对手可能会压垮它们。突然之间，每个人都在建立数据仓库。不幸的是，与许多由恐惧和希望驱动而非充分的用例和业务需求推动的跨数年、数百万美元项目一样，这些项目中许多都是惊人的、广为人知的失败案例。

幸运的是，行业从这些失败中吸取了教训，并继续创新和改进。为了优化这些分析平台，针对特定用例开发了各种专业技术，解决了高效存储和分析大量数据的问题：将大型数据仓库拆分为数据集市，发明利用硬件优化处理查询的设备，并使用列存储和内存数据库。随着时间的推移，开发了大量工具生态系统，用于创建和管理数据仓库、管理数据质量，并跟踪数据模型和元数据。一些较为突出的技术包括：

• 抽取、转换、加载（ETL）和抽取、加载、转换（ELT）工具

• 数据质量（DQ）和分析工具

• 数据建模工具

• 业务词汇表

• 元数据存储库

• 数据治理工具

• 主数据管理（MDM）系统

• 企业信息集成（EII）、数据联合和数据虚拟化工具

此外，还开发了用于创建报告和分析的工具，包括：

• 报告工具

• 在线分析处理（OLAP）工具

• 商业智能（BI）工具

• 数据可视化工具

• 高级分析工具

在接下来的部分中，我们将看看其中一些工具。

数据仓库生态系统

图 2-1 说明了数据通过数据仓库生态系统的流动。后续章节将探讨每个组件的功能和数据流。这些工具不是本书的主题，但必须理解并置于上下文中，以便了解今天大多数组织中的数据处理流程及我们试图用数据湖复制或替代的功能。

图 2-1. 数据仓库生态系统中的数据流

除了数据流之外，数据仓库生态系统还有丰富的元数据流，以及许多特定于元数据的工具，如图 2-2 所示。后续章节将描述各种工具之间的元数据流。生态系统中面向最终用户的两个组件位于图表顶部：业务词汇表和各种报表工具。广泛的 IT 人员群体——ETL 开发人员、数据和系统架构师、数据建模者、数据管理员、报表和 BI 开发人员以及数据库管理员——使用其余工具确保最终用户获取其报告和分析数据。请注意，我没有包括一般的管理、备份、管理和其他与数据仓库无关的工具，并简化了一些组件——例如，我将数据剖析归入 DQ，ETL 中的血统等等。

图 2-2. 数据仓库生态系统中的元数据流

数据存储与查询

数据库是数据仓库的核心。通常，它是为分析型处理而优化的关系型数据库：大型、长时间查询；聚合；以及多表连接。数据库通常经过大量索引和调优，以确保对最常见的查询有最佳的性能。

维度建模和星型模式

当关系型数据库用于支持操作系统和应用程序时，数据通常存储在高度规范化的数据模型中。规范化的数据模型试图创建最小冗余和最少字段的表；这使得更新非常迅速。

例如，表示销售的表可能除了一些用于产品、买家、零售位置等生成的键之外几乎不包含任何信息。为了找到有用的信息，例如与零售位置对应的城市，必须将该表与另一表进行昂贵的计算。

另一方面，大多数数据仓库更青睐去规范化的数据模型，其中每个表尽可能包含多个相关属性。这样，所有信息可以通过一次数据遍历进行处理。

接下来，因为数据仓库通常包含来自许多来源和应用程序的数据，每个都有自己的架构，因此需要将这些来源的数据规范化，以转换为单一模式。数据仓库常用的数据模型是由 Ralph Kimball 和 Margy Ross 在 1996 年的《数据仓库工具包》第一版中引入的星型模式。该模式包括一组维度和事实表。

维度表代表正在分析的实体：在销售背景下，可能存在包含客户所有属性（姓名、地址等）的客户维度表，包含所有时间属性（日期、财政年度等）的时间维度表，以及包含所有产品属性（制造商、型号、价格等）的产品维度表。

事实表包含涉及维度的所有活动。例如，交易事实表中每个订单的每一行都会有一条记录。记录中包含来自客户维度表的客户关键字，该客户下订单的时间维度表的时间关键字，以及产品维度表中所订购产品的产品关键字，以及交易本身的属性（订单和行项目 ID、数量、付款价格等）。表的结构通过图 2-3 进行符号表示。将数据组织成星型模式后，即使是如 Oracle、IBM DB2 和 Microsoft SQL Server 等通用关系数据库也能够实现合理的性能，而且现在许多数据库还包括了处理星型模式连接的专门查询优化。

图 2-3. 简单星型模式中的表

缓慢变化维度

为了进行准确的数据分析，有必要随时间追踪个人的状态。这确保了每个交易都对应于交易时个人的状态。由于个人的状态不经常变化，因此开发了一种特殊的结构来表示这些变化：缓慢变化维度。这一概念也由 Kimball 和 Ross 在《数据仓库工具包》中引入。

缓慢变化维度的目标是随时间跟踪维度实体（例如个人）的状态，以便与实体状态相对应的交易（或事实）反映出长期分析中的状态，从而使分析更加准确。

本节通过描述最常见的缓慢变化维度类型来阐述基本概念，该类型通过创建多条记录来跟踪历史数据。这被称为类型 2 维度。

假设我们有一个商店，该商店记录了客户购买及其人口统计信息。在我们的示例中，假设玛丽是一个单身人士，在该商店购物已有五年时间。五年后，玛丽结婚成为房主；两年后成为父母。她继续在该店购物。

在图 2-4 中，玛丽年份 1-5 的购买反映了可能由单个人完成的购买；年份 5-7 反映了一个房主的购买；随后的年份反映了一个新父母的购买。

图 2-4. 具有慢变化维度的购物数据

如果没有慢变化维度，我们在客户表中只会有一个玛丽的单一记录，反映她当前作为一个家长的状态（见图 2-5）。因此，如果我们分析有多少有孩子的人在昂贵的旅行或运动装备上花了多少钱，我们会错误地将她年份 1-7 的购买（作为一个没有孩子的人）归因于她当前的类别。

图 2-5. 没有慢变化维度的购物数据

然而，借助专门捕获交易时个人状态的慢变化维度的帮助，客户表将对玛丽的每次状态变化都有不同的记录，如图 2-6 所示。因此，当分析玛丽的购买时，它们将被归因于具有正确状态的人。

图 2-6. 每次状态变化都会在客户维度表中为玛丽创建一个新记录，字段包括记录有效性的开始和结束日期

由于慢变化维度给 ETL 作业和分析查询增加了如此多的复杂性，只有最关键属性的历史（例如前面示例中的家庭状态）被跟踪。这意味着如果未跟踪的属性之一变得关键，其演变历史将不可用。

大规模并行处理（MPP）系统

使用大量并行计算机集群作为单个数据库的替代方法，这些计算机对最终用户或 BI 工具呈现为单个数据库。在开发了这种 MPP 技术后，Teradata 迅速成为最大数据仓库的首选数据库。通过使用专有的硬件、软件和网络协议，Teradata 数据仓库能够实现业界无与伦比的可扩展性，这一优势在 Hadoop 出现之前是无法匹敌的。由于 Teradata 能够并行操作计算机，因此不需要用户按照特定方式对数据建模。相反，它依赖于其查询优化器以尽可能高效的方式执行复杂查询。

数据仓库（DW）设备

DW 设备试图解决的问题是将运行在专有硬件和软件上的高性能数据库，比标准的现成数据库更容易部署和管理。IBM Netezza 就是这种 DW 设备的一个很好的例子。虽然不如诸如 Teradata 和 IBM DB2 等 MPP 系统可扩展，但这些设备更容易部署和调优，并且可以满足大多数数据仓库和数据集市的需求。

列存储

关系数据库将数据建模为包含行（有时称为记录）和列（有时称为字段）的表。例如，假设您有一个Customers表，其中有 300 列，每列包含有关客户的数据，例如姓名，地址，年龄，第一次购买日期等。传统的关系数据库将每行数据存储在一起，因此所有关于第一个客户的信息都被存储，然后是所有关于第二个客户的信息，依此类推。为了存储 300 个属性，每个属性的平均大小为 5 字节，数据库需要使用 1,500 字节，或者大约 1.5 KB，来存储每个用户。如果有一百万个客户，数据库至少需要 1.5 TB 的存储空间来存储所有客户数据（实际上，需要更多的存储空间，因为记录不会整齐地适配到磁盘块中，并且还有底层数据结构和索引占用的空间）。如果用户想要知道年龄小于 30 岁的客户数量，数据库将不得不读取表中的每条记录，换句话说，它将不得不读取所有的 1.5 TB。

列存储数据库将每列的所有数据一起存储，而不是将每行的所有数据一起存储。例如，它会将每位客户的年龄与记录标识符一起存储在相同的存储块中，指示这个值属于哪个客户记录。如果年龄占用 2 个字节，记录标识符占用 6 个字节，那么数据库每个字段需要 8 个字节，或者对于一百万个客户需要 8 GB。由于只需读取 8 GB 即可回答“30 岁以下客户有多少”的问题，它能够比原来快约 200 倍。当然，这仅对于需要少数列的查询性能有所改进。如果查询想要返回单个用户的所有信息（全部 300 列），行存储数据库只需读取一个块，而列存储数据库则需要读取 300 个块。换句话说，列存储数据库用于非常特定的查询模式，而关系模型则更通用。一些知名的竖直数据库包括 Sybase IQ 和 Vertica。

内存数据库

尽管传统上内存访问速度比磁盘快几个数量级，但也更昂贵。因此，数据库开发的大部分工作集中在优化磁盘访问上。正如我的斯坦福数据库教授 Gio Wiederhold 喜欢重复的那样，“任何一位合格的数据库工程师都会计算块读取次数。”大量工作投入到通过优化磁盘访问、缓存和预缓存、创建索引以减少块读取次数等来最小化这些块读取次数。

随着内存价格下降并且在内存中存储更大量数据变得实际可行，第一批设计用于在内存中保留和处理数据的数据库系统应运而生。TimesTen 就是其中的先驱之一；正如其名称所示，它试图通过专注于在内存中存储和处理数据来实现传统基于磁盘系统 10 倍的性能。最近，像 SAP 的 HANA 系统和 Apache Spark 项目等厂商也再次推动内存数据库的发展。

加载数据——数据集成工具

一个重要的事情要记住是数据仓库中的数据是从应用程序和操作系统加载的。因此，首要任务是用数据加载数据仓库。

有各种方法、工具和技术可以实现这一点。

ETL

ETL 技术已经存在 20 多年了。大多数现代 ETL 工具是作为数据仓库运动的一部分在 1990 年代中期至晚期开发的。当关系数据库用于支持操作系统和应用程序时，数据通常存储在高度归一化的数据模型中。我们不会详细讨论这些细节，这些内容在大多数关系数据库书籍中都有描述，但归一化数据模型试图创建具有最小冗余量和最少字段数量的表，因此更新非常快速。另一方面，正如我们在“维度建模和星型模式”中看到的那样，大多数数据仓库倾向于非归一化数据模型，其中每个表包含尽可能多的相关属性，因此所有信息可以通过数据的单次通过来处理。

来自操作系统的数据可能包含不同格式和表示的多个表中的客户信息。ETL 工具的工作是将各种表示转换为一个共同的客户维度，就像我们在图 2-3 中看到的那样，并确保来自不同系统的同一客户记录用于创建或更新客户维度中的单个客户记录（图 2-7）。这样的维度称为符合维度，因为客户维度将所有传入的数据符合到一个单一的格式，并且相同的客户将在不同系统中的各种记录中被识别。在图 2-7 中，操作系统使用两个表存储客户数据。此外，这些表有不同的客户信息表示。例如，名字和姓氏在不同的字段中，有出生日期而不是年龄，并且每个客户保存多个地址。ETL 工具的任务是通过将名字连接到一个字段中，从出生日期计算年龄，并选择最佳地址并将其连接成一个字符串来将此表示转换为数据仓库客户维度表期望的表示。

图 2-7. ETL 工具从多个表中提取数据以创建客户维度

此外，由于数据仓库通常包含来自许多不同源和应用程序的数据，每个都有其自己的模式，因此来自这些源的数据必须被归一化并转换为单一模式。

ETL 与 ELT

多年来，Teradata 和其他高端数据库供应商鼓励其客户使用其数据库引擎来执行所需的转换，而不是将其留给 ETL 工具处理。他们认为只有像他们的这样高度可扩展的系统才能处理其数据仓库的体积和复杂性。这个处理过程被称为 ELT（提取、加载、转换）。换句话说，数据以其原样加载到数据仓库中，然后使用数据库引擎将其转换为正确的表示形式（图 2-8）。

图 2-8. ETL 与 ELT 的比较

联合、EII 和数据虚拟化工具

当数据来自多个系统时，数据仓库的方法是将所有数据汇总到一个地方，将其集成到单一的符合模式中，然后用于分析查询。另一种方法是在多个系统之间创建逻辑或虚拟模式，然后针对该虚拟模式发出查询。这种方法有许多名称，最常见的是联合、企业信息集成（EII）和数据虚拟化。比使用数据仓库更适合的主要情况包括：

• 当面对数据必须保持更新时。因为这些工具针对原始源执行查询，所以结果始终是最新的，而数据仓库通常有一定的滞后取决于刷新频率。

• 当数据访问不频繁时。为可能只会被使用一年甚至更少的数据建立非常昂贵的数据仓库并不划算。

• 当合规性和数据驻留条款可能限制数据从一个源位置复制到目标位置时。

另一方面，这种方法有几个重要的缺点：

劳动密集型的手动过程

虚拟表必须手动定义在不同系统之间。

架构和逻辑变更

尽管架构更改可能导致加载数据仓库的 ETL 作业中断，但仅会影响最新数据，大部分数据仍然可用于分析。使用数据虚拟化工具时，架构更改可能会导致查询中断，并使所有数据在修复查询之前都不可用。

性能

某些涉及多个系统的查询（称为联合查询）存在显著的性能挑战。例如，复杂的多表连接和跨多个数据库的相关子查询执行时间比所有表都在同一数据库时要长得多。此外，虽然数据仓库可以通过额外的索引和调整进行分析优化，但操作源系统通常不能在不减慢其设计用途的操作的情况下优化分析查询。

频率

每个查询在每次运行时都有效执行完整的集成作业。因此，如果对虚拟模式有大量查询，一次性提取数据并将其存储在数据仓库中，然后在那里进行查询会更有利。这样做大大减少了源系统的负载，并且在计算上比每次读取和集成源表要更有效。一些数据虚拟化工具通过在某些临时区域缓存数据来减少浪费，但总体而言，如果访问频率非常高且数据新鲜度不是关键问题，数据仓库可能是更好的选择。

随着数据量和多样性的持续增长，数据虚拟化工具通过改进查询优化和增加内存处理和缓存来跟上发展。

图 2-9 说明了数据仓库方法与数据虚拟化方法的比较。在顶部图表中，在 ETL 过程中将来自不同数据库的两个表合并，并将结果持久化为数据仓库中的一个表。然后，所有查询都针对这个表执行。在底部图表中，通过数据虚拟化创建虚拟视图，而数据仍然物理上存储在原始数据库中。

图 2-9. 数据仓库与虚拟化方法的比较

组织和管理数据

数据仓库的规模和复杂性促使开发了多种工具来组织它们、检查数据质量并管理访问权限。本节最后解释了这些工具的目的和基本操作。

数据质量工具

数据质量是数据管理中的一门成熟学科。它涉及定义质量规则，将这些规则应用于数据以检测违规（通常称为异常），并修复这些异常。数据质量是一个广泛的话题，已经有很多书籍专门讨论这个问题，因此本节仅提供一个旨在传达一般方法的快速总结。

数据质量规则有多种形式和大小，但通常可以分为几个主要类别：

标量

应用于特定值。例如，Name是必填字段并且应该有值；Salary应该是一个数字；Age应该在 0 到 150 之间。

字段级别

应用于字段中的所有值。最常见的例子与字段的唯一性有关（例如，Customer_ID应该是唯一的）和字段的密度（例如，Name不能为空），但也可能存在其他规则，比如Income应该在X到Y的范围内。虽然其中一些规则，如密度规则，可能看起来是多余的，例如，Name不为空可以通过标量测试来表达，但在字段级别执行的优势在于我们可以提供公差；例如，我们可以容忍高达 10%的客户姓名为空。

记录级别

应用于单个记录的所有字段。例如，我们可以指定如果 US_CITIZEN 字段为 True，则 Social_Security_Number 字段不应为空，或者 JSON 文件中 Orders 记录中的根元素应有确切的三个子元素。

数据集（表/文件）级别

应用于整个数据集。这些情况并不常见，通常涉及记录数量。例如，包含传感器数据的数据集应每小时至少有一个事件。

跨数据集级别

应用于数据集。在关系系统中，参照完整性规则非常常见。它们基本上规定主键应该是唯一的，并且外键字段不应该有任何不存在于主键字段中的值：select count(distinct order_id) from orders where fulfilled = 1 应该与 select count(distinct order_id) from shipments 相同，或者文件 1 中的行数应该小于或等于文件 2 中的行数。

一些数据质量规则可以通过程序固定，而另一些则需要手动干预。例如，一个缺失的客户姓名可以在主客户列表中查找，或者缺失的性别可以从称谓或名字中推断出来。另一方面，有时无法通过程序修复数据质量问题。在这种情况下，数据需要手动修复，或者根据正在处理的项目以不同方式进行修复。例如，如果帐户号码的交易缺少一位数字，负责筛选数据的分析师可能需要手动搜索帐户，查看可能匹配的帐户，并查看帐户历史记录以确定该日期的该金额是否有交易。如果客户收入信息丢失且分析师无法获取，则可能决定删除缺失收入值的记录，将收入视为 0，或者用平均收入替换缺失的收入值，具体取决于他们正在处理的项目类型。

在没有数据质量规则的情况下，数据剖析是一种自动收集关于数据统计信息的技术，然后确定其质量的技术。剖析工具通常会读取所有数据，并针对每个字段跟踪哪些类型的值有多少（字符串、数字、日期），有多少空值（NULL），最小和最大值，以及每个字段的最频繁值和其他统计信息取决于字段类型。使用剖析的优点在于它不需要设计任何质量规则，并且分析师可以使用结果来确定数据在他们正在处理的具体项目中的质量。例如，如果Age字段大部分为空，但对于特定项目不需要，数据集可能具有可接受的质量水平。尽管几乎所有数据质量工具都包括剖析，但剖析也被各种其他工具使用，从数据准备到数据发现等各个方面。

流行的剖析和数据质量工具包括 IBM 信息分析器，Informatica DQ，SAS DataFlux 等等。

MDM 系统

一种特殊类别的数据质量工具称为主数据管理系统，用于创建各种实体的主列表：主要是客户，但也包括产品（称为产品信息管理或 PIM 系统），供应商等等。这些是非常复杂的系统，它们从一个或多个系统获取数据，将数据协调到一个通用的架构和表示（计量单位，代码等），并执行所谓的实体解析：找到适用于同一实体的多个记录。例如，一些系统可能有同一客户的多条记录，因为重复数据输入，收购（一个客户公司收购另一个公司，它们成为一个单一客户），人为错误或其他多种原因。此外，不同的系统可能使用不同的标识客户的方法——一个可能使用税号，另一个依赖于姓名和地址，第三个使用帐号号码。调和所有这些是 MDM 系统的工作。

一旦识别出同一实体的记录，通常会发现它们包含冲突信息——地址不同，姓名拼写略有不同等等。因此，MDM 系统的另一个任务是修复这些冲突，可以自动进行或触发手动干预，以创建黄金记录：每个实体应使用的正确记录。

MDM 供应商包括传统供应商如 IBM，Oracle 和 Informatica，以及一些提供机器学习能力来自动化过程的下一代供应商，如 Tamr。

数据建模工具

数据建模工具用于创建关系模式。理论上，数据建模师可以使用诸如 Erwin 和 IBM InfoSphere Data Architect 之类的工具来创建物理、逻辑和语义模型，但在实践中，大多数时候这些工具用于创建数据的实体关系模型，包含主键和外键（也称为参照完整性约束）。

模式设计是运营数据库中非常重要的活动。设计良好的模式可以提高数据库性能，而设计不良的模式则会减慢速度——有时会显著减慢。模式必须根据使用情况设计：如果是运营模式，它必须良好规范化，并优化以处理许多小事务；如果是数据仓库模式，则应使用维度设计来优化分析查询。模式设计师还必须考虑可理解性和可扩展性。模式会改变，设计良好的模式通常很容易通过添加新列来改变，而设计不良的模式则经常需要昂贵的重构。

在本章的早些时候，我们讨论了参照完整性和规范化。由于它是一个核心概念，所有关系数据库都提供了执行参照完整性的设施。不幸的是，为了做到这一点，每当在我们之前的示例中的Orders表中添加新订单时，数据库必须检查Customers表，以确保Orders表中的Customer_ID存在于Customers表中，如果值不存在，就中止或拒绝事务。这给Orders表的更新增加了显著的性能开销。这也使得处理订单的所有应用程序变得复杂，因为它们需要一种处理此类拒绝事务的方法。在实践中，我没有见过任何执行参照完整性的生产数据库。相反，关于主键和外键的信息保存在数据建模工具中，数据质量工具用于检查参照完整性。

元数据存储库

元数据存储库包含跨数据资产的技术元数据（关于数据的数据）。元数据是手动收集的或通过与各种其他工具（如 ETL 工具、BI 工具等）集成来收集的。元数据存储库有三种主要用例：

寻找数据资产

例如，数据架构师可能想知道哪些数据库中的哪些表包含Customer_ID。

追踪血统 跟踪血统（来源）

许多法规要求企业记录数据资产的血统——换句话说，这些资产的数据来源以及它是如何生成或转换的。

影响分析

如果开发人员在一个复杂的生态系统中进行更改，总是有破坏某些东西的危险。影响分析允许开发人员在进行更改之前，看到所有依赖于特定字段或集成作业的数据资产。

元数据存储库供应商包括 IBM、Informatica、ASG Rochade 等许多其他公司。然而，这些供应商正在迅速被称为数据目录的新产品类别所取代，该类产品在第八章中有详细介绍 Chapter 8。

数据治理工具

数据治理工具记录、记录，有时管理治理政策。这些工具通常定义每个数据资产的数据监护人是谁。数据监护人负责确保数据资产正确，记录其目的和血统，并为它们定义访问和生命周期管理策略。

在某些公司中，数据监护人可以是一个全职、专职的角色。在其他公司中，这一角色可能分配给直接与数据相关的业务责任人员。组织结构也各不相同：一些数据监护人属于正式的数据治理组织，通常由首席数据官（CDO）管理，而其他人则属于功能团队、业务单位或者更少见的 IT 部门。例如，销售数据的数据监护人可能是销售运营团队的成员。

数据监护常常是复杂且跨职能的。例如，每个销售组可能有自己的客户关系管理（CRM）系统和自己的数据监护人，而将所有系统的销售和客户数据汇总到一个数据仓库中可能也会有自己的数据监护人。数据治理工具最重要的功能是识别谁对什么负责，以便可以咨询他们并授权访问和其他数据政策。

一旦所有权已记录，推出数据治理程序的下一步是记录数据治理政策。广义上讲，这些政策通常包括以下几个方面：

访问控制和敏感数据法规合规性

谁可以看到什么。对于敏感数据和符合相关法规的情况尤为重要。例如，信用卡行业有定义如何处理敏感信用卡数据的支付卡行业（PCI）法规，美国医疗行业有称为《健康保险便携性和责任法案》（HIPAA）的政府法规，以及任何拥有欧洲客户的公司必须遵守的新法规《通用数据保护条例》（GDPR）。

文档管理或元数据管理

每个数据集需要记录的内容，通常包括数据血统和再次强调的法规合规性。对于金融行业，Basel III 合规要求在规则 BCBS 239 中有详细记录，要求公司报告的所有财务结果都要维护详细的血统。

数据生命周期管理

保留政策、备份政策等。

数据质量管理

可接受的质量水平及应使用的数据质量规则。

业务词汇表

数据代表的各种术语。术语表组织和记录这些术语：通常包含每个术语的官方名称和描述以及它们的数据表示（例如，“利润”术语可能描述利润如何计算，而“客户状态”术语可能描述法律状态列表及其如何分配）。

数据的消费

一旦数据加载并可用，分析师可以用它来生成报告，运行特别分析，并创建仪表板。有大量此类工具可用，包括许多开源和免费产品。

从历史上看，这些工具曾分为报告工具（如 Crystal Reports 和 Jasper Reports，生成可打印报告）、BI 工具（如 Business Objects 和 Cognos，创建特别报告和图表）以及 OLAP 工具（如创建内存立方体并允许用户“切片和切块”或分析各种维度的工具）。这些立方体可以在内存中构建（例如 ArborSoft/Hyperion）或按需从关系数据库构建（也称为 ROLAP；例如 MicroStrategy）。最终，大多数这些功能都整合到一个工具中，因此像 MicroStrategy 这样的工具现在提供所有这些功能。

这些工具的第一代设计供开发人员创建报告、仪表板或 OLAP 立方体，并让分析师使用这些工件。在 2000 年代，新一代产品如 Tableau 和 Qlik 凭借提供分析师简单工具的方式，让他们直接处理数据表和文件，而无需等待 IT 编写报告，开始占据主导地位。这引领了我们将在第六章中广泛探讨的自助式分析时代。

高级分析

多年来，高级分析已在许多行业中存在。从工程到保险再到金融，统计模型和预测模型被用来衡量风险和模拟现实场景。许多自然科学领域，从人类学到物理学，都使用统计学来衡量、推断和预测。华尔街的量化分析师几十年来一直在构建自动化交易模型。保险精算师已经模拟风险和概率超过一个世纪。一个名为数据挖掘的计算机科学分支已经存在超过 20 年。围绕提供统计和高级分析专业工具的数十亿美元产业已经蓬勃发展，包括诸如 SAS、MATLAB、SPSS（现在是 IBM 的一部分）等供应商。

传统上，高级分析主要是统计学家和科学家的领域，但现在正在逐渐走向主流。像 Excel 这样的流行消费者软件现在已经包括了基本的统计功能，比如常规回归。更重要的是，许多面向消费者的应用展示了预测或统计模型。从像Zillow.com这样使用统计模型计算房屋价值的房地产网站，到信用评分应用和金融管理软件模拟储蓄和退休收入，人们在日常生活中越来越多地遇到预测分析的结果，并开始思考如何将其应用于他们的商业生活中。

越来越多关于“公民数据科学家”的讨论——基本上是指商业分析师在解决问题时应用高级分析，而不需要聘请统计学家和专业数据科学家。就像现在很多高中都教授编程一样，大多数分析师已经习惯使用 Excel 宏、SQL 查询，甚至简单的脚本语言，高级分析正在逐步从“高级”走向普及。

结论

这段关于数据和数据管理技术的简要历史将我们带到了 2010 年代初期。在下一章中，我们将讨论大数据现象及其对数据管理实践所带来的颠覆。

第三章：大数据与数据科学简介

大数据的流行可以追溯到 2004 年发表的一篇研究论文：《MapReduce: Simplified Data Processing on Large Clusters》，由 Jeffrey Dean 和 Sanjay Ghemawat 撰写。在这篇 13 页的论文（包括源代码）中，Google 的两位工程师解释了公司如何通过一种全新的基于大规模并行集群的算法，将其庞大的索引需求降低到合理的处理要求。MapReduce 的基本思想是将工作分解为可以并行运行的“映射器”和处理映射器输出的“减少器”。第一个操作称为“映射”，因为它将输入数据的每个元素“映射”到一个函数上，将输出留给减少器处理。

例如，要统计集群中所有节点上所有文档中的单词数，假设每个文档存储在单个节点上，我们可以有成千上万个并行运行的映射器，生成每个文档及其单词计数的列表，并将该列表发送给减少器。然后，减少器将创建包含所有文档及其单词计数的主列表，并通过将所有文档的所有计数相加来计算总单词计数（图 3-1）。假设磁盘比网络慢得多，映射器读取文档比发送总数给减少器慢得多，这个程序将在大型集群中非常好地扩展，而且性能几乎没有明显的下降。

图 3-1。MapReduce 的基本架构

Hadoop 领导历史性的大数据转型

虽然 Google 没有发布其内部的 MapReduce 工具，但受论文启发的开发者创建了一个名为 Hadoop 的免费开源实现，它很快成为各个组织处理大数据的核心工具。

Hadoop 文件系统

MapReduce 需要一个特殊的文件系统来高效提供数据，而最流行的就是 Hadoop 文件系统（HDFS）。它是一个大规模并行、高可用、自我修复的文件系统。然而，它并未试图实现关系模型（尽管后来在其之上构建了类似 SQL 的接口）。相反，与当时正在成长的许多其他 NoSQL 数据库一样，HDFS 是一种复杂的键值存储系统。

它会为每个块创建多个副本（默认情况下为三个副本），并将这些副本存储在不同的节点上。这样，如果一个节点失效，仍然可以使用另外两个副本，并且在检测到故障后，会将该块复制到第三个节点，而不会影响可用性。多个副本还有助于负载均衡，因为我们可以选择将工作发送到包含数据的最不繁忙的节点。例如，在图 3-2 中，文件 11 存储在不同的节点上。它有两个块。块 1 存储在节点 1、2 和 3 上，而块 2 存储在节点 1、3 和 4 上。在处理文件时，可以在存储块 1 的任何节点上执行块 1 的工作，选择最不繁忙的节点。类似地，可以在存储块 2 的三个节点中的任何一个上执行块 2 的工作。如果其中一个节点（例如节点 3）损坏或变得不可用，HDFS 仍然可以访问存储在节点 3 上的每个块的另外两个副本，并确保在其他仍然运行的节点上为最初存储在节点 3 上的块创建替代副本。

图 3-2. HDFS 中分布式存储的示例

如何处理和存储在 MapReduce 作业中的交互

在我们之前的计算单词示例中，将创建一个作业，其中包含所有文件中所有块的列表，并且作业管理器将将每个块的工作发送到包含它的最少负载节点，从而平衡集群中的负载。当然，为了创建文件列表，我们现在必须从块中重新组装文件。假设这对于单个节点来说太多了，我们可以有多个减少者来处理工作。为了确保同一个减少者获得单个文件的所有块，我们将利用 MapReduce 的shuffle步骤，其中映射器的输出包含键和值，并且对键应用洗牌函数，以便将所有具有相同键的工作发送到同一个减少者。例如，我们可以使用一个哈希函数，该函数获取文件名并返回 0 或 1，例如通过添加文件名中所有字母的 ASCII 值并除以 2 来执行此操作。所有名称哈希为 0 的文件的输出都会发送到减少者 1，而名称哈希为 1 的文件的输出则会发送到减少者 2。

当存在多个 Reducer 时，为了创建单个文件，我们需要将所有 Reducer 引导到一个单独的 Reducer，将最终输出组合成一个文件，增加了复杂性和处理时间。相反，为了优化多个并行工作的 Reducer，大多数 MapReduce 作业生成多个文件，通常在同一个目录中。为了实现这一点，大多数 Hadoop 组件处理目录而不是文件。例如，Pig 脚本、Hive 和其他项目期望目录作为输入而不是文件，并将该目录中的所有文件视为单个“逻辑”文件。在图 3-3 中，创建了一个名为WordCount的文件夹，包含两个 Reducer 输出的文件。文件的名称通常是自动生成的，因此它们没有实际意义，也从不直接使用，除非内部程序代码需要读取它们。所有工作都在WordCount文件夹上进行，将其视为单个逻辑文件。这等同于连接文件夹中的所有文件。

图 3-3. Hadoop 中的 Mapper、Reducer 和文件存储

因为大部分工作在块级别进行，Hadoop 通常具有较大的块大小，默认为 64 或 128 MB。由于一个块只能存储一个文件，这使得 Hadoop 不适合存储小文件 —— 一个 1 KB 的文件仍然需要整个 64 或 128 MB 的块。为了优化存储，序列文件 被引入。序列文件是键/值对的集合，通常用于将大量小文件存储在一个大文件中，使用较小文件的名称作为键和内容作为值。

虽然非常高效和优雅，MapReduce 要求开发人员仔细思考他们的逻辑并正确划分工作。如果工作没有正确分布，作业可能会遭受显著的性能下降。例如，如果我们有 1,000 个 mapper 运行在一个 1,000 节点的集群上，其中 999 个 mapper 花费 5 分钟运行，但最后一个 mapper 花费 5 小时，整个作业仍然需要 5 小时才能完成。

Schema on Read

在关系数据库中，表的模式（列的列表、它们的名称和它们的类型）在创建表时被定义。当数据插入表中时，它必须符合这个预定义的结构。这要求对模式管理采取非常正式和谨慎的方法，因为如果数据不符合表的模式，它将无法被插入或存储在数据仓库中。事实上，没有任何地方可以插入它，因为插入它将需要定义一个与数据匹配的模式。

由于 HDFS 是一个文件系统（对用户来说基本上看起来像是 Linux 文件系统），它可以存储各种类型的数据。当然，为了进行任何处理，数据必须具有模式或结构。为此，Hadoop 采用“读时模式”方法——它在读取数据时应用模式。例如，用户可以为 HDFS 中的文件定义一个外部 Hive 表。当查询该表时，Hive 将尝试将文件中的数据映射到表定义中，赋予其一个模式。如果数据与模式定义不匹配，则查询将失败。然而，与关系数据库不同的是，数据仍然存储在 HDFS 中并得以保存。只是在应用正确的模式之前无法使用。由于这种方法，可以轻松地向 HDFS 添加数据，无需任何检查和无需定义任何模式。

Hadoop 项目

Hadoop 已经衍生出一个丰富的项目生态系统，涵盖从数据摄入到管理和管理的所有内容。表 3-1 和 3-2 涵盖了一些传统上包含在 Hadoop 发行版中最受欢迎的项目。大多数是开源的，尽管 Cloudera 和 MapR 的某些组件需要商业订阅（在 Table 3-1 中用 * 标示）。

Table 3-1. 与 Hadoop 和 HDFS 相关的热门本地工具

	Apache Hadoop	Cloudera	Hortonworks（包括 IBM、Microsoft Azure 和 Pivotal）	MapR
摄入	Sqoop, Flume		NiFi
关系接口/数据库	Hive	Hive, Impala*	Hive	Hive, Drill
NoSQL	HBase	HBase, Kudu	HBase	MapRDB（HBase 的变种）
安全	Ranger	Sentry*	Ranger
治理	Atlas	Navigator*	Atlas	Resells Waterline*
文件系统	HDFS	HDFS	HDFS	MapR-FS

Table 3-2. 与 Hadoop 和 HDFS 相关的热门云工具

	AWS	Azure	Google Cloud Platform
摄入	Kinesis	事件中心	Cloud Pub/Sub
集成	Glue	ADF	Cloud Dataflow
关系接口/数据库	Hive, Presto, RedShift, Aurora	Hive	Cloud Spanner
NoSQL	DynamoDB	AzureNoSQL	Bigtable
安全		安全中心
治理	Glue	Azure 治理
文件系统	EBS, EFS	ADLS	ECFS
对象存储	S3	Blob 存储	GCS

Hadoop 生态系统中最重要的发展之一是Spark，这是一个概念的扩展，比 MapReduce 提供了更快的速度和更大的灵活性。随着网络速度的提高，Spark 起源于 UC Berkeley 的 AMPLab 于 2009 年，并成为 Apache 顶级项目。它得到了 Databricks 的商业支持，并包含在每个 Hadoop 发行版中。

Spark 的核心思想是在计算机集群上创建一个大的内存数据集。如果 HDFS 努力在集群中创建一个单一的持久性文件系统，那么 Spark 有效地在集群中创建一个大的内存空间。Spark 的核心是弹性分布式数据集（RDD），对于使用 Spark 的程序来说，它看起来像一个单一的数据集。

另一个 Spark 的改进是对旧的 MapReduce 模型的泛化。不再是由单一的包含映射器、分组器和减少器的管道（可能并行运行多个实例）组成，而是复杂的管道可以通过多个不同阶段的多个实例传递数据。例如，Spark 可以轻松地将一个减少器的输出传递给另一个减少器，在 Hadoop 中则需要繁琐的手动编码，并且读写磁盘时速度缓慢。

尽管 Spark 是用 Scala 编写的，但也可以通过 Java、Python、R 和其他语言的接口使用，以及 SparkSQL，它是基于称为 DataFrame 的抽象层的 RDD 的 SQL 接口。

数据科学

很多分析是描述性的：它们回顾过去发生的事情，并依赖人类专家来审查历史并做出关于未来的决策。有时人类在这方面做得很好，但有时却不尽如人意。他们常常依赖直觉和个人经验，并很少有机会验证他们的决定。想象一下，如果你能在事情发生之前就预测会发生什么，并根据历史数据验证它？或者如果你能在大规模推广之前在小部分用户中实际测试这些事物呢？

数据科学的理念是根据以数据形式表示的事实信息来进行行动建议。甚至这个学科的名称也显示了其基本原则。当我询问起“数据科学”这一术语的创始人 DJ Patil 时，为什么要这样称呼，他告诉我他如何在 LinkedIn 开展了一个新的团队，专注于使用数据和高级分析来回答关于 LinkedIn 用户体验和业务的各种问题。为了决定如何称呼这个团队，他们发布了三个不同的招聘广告，描述他们正在寻找的人才。这三个广告都是同一个职位和同一个工作描述，首选经验要求相同，发布在同一个招聘网站上。唯一的区别在于名称：“数据科学家”，“数据分析师”和“数据工程师”。吸引最多申请者的广告是“数据科学家”，因此他们将团队命名为“数据科学”。

这是一个很好的例子，通常被称为A/B或分割测试：你在不同的人群中尝试 A 和 B，并严格测量哪个更好，然后再做出决定。像 LinkedIn 和 Google 这样的数据驱动型公司，在发布任何代码之前，都要加入仪器，以便测量其效果。他们还会在几个不同的市场上测试新功能，然后再将其推广给更广泛的用户群体。

数据科学的核心是数学（特别是统计学）、计算机科学（尤其是数据处理和机器学习）以及领域或业务知识的结合。领域知识对于数据科学家来说至关重要，因为它帮助他们理解需要解决的问题、哪些数据是相关的，以及如何解释结果。有很多书籍和文章专注于数据科学的技术方面，但在本书中，我们将关注大企业实践的数据科学。为了介绍核心概念，我将重印一下 Veijko Krunic 的下面这篇文章，他向大企业咨询如何开始实践数据科学。

您的分析组织应该关注哪些问题？

Veljko Krunic 是一名独立顾问和培训师，帮助客户从数据科学和大数据中获得最佳业务结果。他曾与从财富前十到初创企业的组织合作，指导它们完成大数据和分析解决方案的整个生命周期，从早期概念验证到改进关键任务系统。他曾在 Hortonworks、VMware 的 SpringSource 部门以及 Red Hat 的 JBoss 部门工作过。他在科罗拉多大学博尔德分校获得了计算机科学博士学位和工程管理硕士学位，专注于战略规划和质量科学中的应用统计学。他还是一名 Six Sigma Master Black Belt。

许多公司正在对大数据和数据科学进行投资，并且理所当然地期望获得显著的业务利益。同时，由此产生的大数据系统和数据科学方法可能是近年来进入企业市场的最复杂技术之一。努力的规模使得很难将您采用的工具和技术与组织的目标相匹配。

作为一名高管，您将接触到大量新技术和概念。您可能已经被诸如深度学习、HMM、贝叶斯网络、GLM、SVM 等术语轰炸过。在大数据基础设施方面，您可能听说过 Spark、HDFS、MapReduce、HBase、Cassandra、Hadoop、Impala、Storm、Hive、Flink 等术语，以及许多其他技术。截至 2018 年底，Hortonworks Hadoop 发行版单独包含 26 个 Apache 项目，而 Apache 软件基金会有超过 300 个活跃项目，其中许多与数据相关。还有数百种商业产品在生态系统中争夺一席之地。在这些噪音中很容易迷失方向，即使是您技术训练有素的员工也可能感到不知所措。很难找到一位数据科学家或架构师在所有这些领域都具有优秀（甚至是强大的实践者级别）的技能。更可能的情况是系统的各个部分的知识分散在团队不同成员之间。甚至可能是团队第一次进行类似您现在正在做的项目。

这篇文章旨在让您集中精力回答作为一名高管需要解决的重要问题。您如何知道自己正在引导项目走向最佳的商业成功之路，而不仅仅是按照团队已有知识决定的方向前进？当没有任何一个人精通项目涵盖的所有领域时，您如何确保投资于将带来最佳回报的领域？您如何避免进行不幸的“知识扑克”游戏，其中假设各个团队成员持有项目成功所需的牌，但实际上没有人确切知道团队共同知道什么，以及项目的完整范围是否被覆盖？

前面提到的技术对许多项目至关重要。然而，如果在与数据科学和大数据团队交流时，您听到的只有这些术语，您应该问自己是否正确关注了整个系统，或者您的团队是否过于专注于系统的某些组件而忽视了整体系统。特别是，焦点是在您作为高管需要的事务上，还是在您的团队了解（或希望学习）的事务上？考虑工程与您的业务之间的关系，并侧重于最终结果，这就是“整体系统工程”的学科。

如果你的团队没有专注于整体系统，这并不是他们的错。可以公正地说，目前整个行业普遍缺乏对系统的关注。大多数演示文稿、聚会和营销材料只关注成功分析堆栈的一小部分技术。在系统工程方面投入的时间远远不足。至于这一点，我们在社区中甚至有多少讨论大数据系统是为业务目的而设计的系统的简单但基本的概念？

作为关注系统各部分的当前倾向的例子，目标是在备选方法之间做出正确选择，许多墨水被浪费在讨论单个机器学习方法的相对优势和劣势上。这些是重要的战术决策，但你的工作是在你了解你的战略之前避免被技术决策困住。

举个例子来说，MNIST 数据集呈现了一个分类问题：计算机应该将手写数字分类为 0 到 9 的数字。这可能是当今计算机视觉中使用最广泛的数据集，用于测试在从课堂项目到主要互联网公司的设置中开发的计算机视觉算法。从 1998 年到 2016 年，分类准确率从使用相对简单的k-最近邻算法达到的错误率 2.4%改进到 0.21%（使用深度神经网络集成）。¹ 18 年来，一些机器学习领域最聪明的人努力将错误率提高了 2.19%。这是一个显著的改进，例如，允许计算机扫描仪自动读取大多数信封上写的地址，而不是人类几乎需要查看每个信封。

然而，当你在运行一个商业项目时，你不会对单一分类算法的行为感兴趣。你需要问的根本问题是：“这个x%的差异是否显著促进了项目的成功？”有时会，有时不会。有时你不需要人类已知的最佳分类方法；你可能更多受益于简单地收集可能产生更好总体结果的额外数据源。

系统工程的现实是，避免你无法恢复的大坑比在两个竞争对手（无论是方法还是产品）之间做出最佳选择更为重要得多。当然，如果你没有对系统的特定部分做出最佳决策，你可能会给你的竞争对手带来显著优势，这样的错误甚至可能在未来毁了你。但在“未来”成为问题之前，你必须首先有能力开发一个可行的产品，可以开始在那条道路上前行。

尽管大数据和数据科学确实为企业带来了重要的新元素，但它们并没有显著改变系统工程的最佳实践。作为一名高管，在与你的数据科学团队会面后，如果你能够清晰而简洁地回答以下问题，那么你正在朝着开发一个可行产品的良好方向前进：

1. 他们所谈论的数据科学概念与你的业务有何关联？

2. 你的组织是否准备根据分析结果采取行动？（仅仅因为你完成了分析并不意味着商业结果会神奇地出现——只有在根据分析结果采取适当的商业行动时，商业结果才会出现。在项目开始和整个过程中，你需要清楚地了解你的组织可以采取哪些商业行动。）

3. 你的机器学习系统的哪一部分应该投资，以获取最大的“回报率”？

4. 如果团队需要进行更多研究来回答之前的问题，那么这些研究究竟是什么，他们预期获得的可能答案范围是什么，以及完成这些研究所需的事项（尝试方法的时间、额外数据等）？

成功的关键在于区分你是否正在进行能够产生可预测结果（或一系列可能结果）的系统工程努力，还是一项研究项目，其结果可能很好，但并非完全可预测或市场化。虽然在商业和行业中两者都有存在的空间，但你绝对不应该混淆这两种类型的项目。而且你还应该引导你的团队，使其专注于执行正确类型的项目。无法清晰回答前述问题是一个主要的警示信号，直到你能够“完美”回答这些问题之前，更好的方法并不会对你有太大帮助。

整个系统工程的过程超出了本书的范围，但有一个关键组成部分，如果你应用了这里建议的技术，你将能够做到正确。那个关键组成部分是意识到需要理解你的数据，并且了解你的数据是一个非平凡的挑战。

一些团队犯了一个错误，即认为仅仅因为将数据记录在某个数据库或数据湖中，他们就自动成为了数据专家。从这个前提出发，似乎将所有注意力都集中在“其他更重要的问题”上是合理的。然而，现实是，编目和解释现代企业数据是一个复杂的问题，组织必须在数据治理上进行重大投资才能完成这些任务。实际上，如果你有错误的数据，将分类提高 2.19%并不一定有帮助。如果你使用的是错误的数据或者误解了你的数据，你必须尽快改变方向。幸运的是，你可能能够重复利用你在工具上的投资。

找到并实施适合您数据的正确方法是系统工程的关键方面，应在项目开始阶段评估该方法，以确保您走在正确的道路上。

机器学习

机器学习指的是根据数据训练计算机程序构建统计模型的过程。这是一个非常广泛和深刻的主题，我们在这里无法充分涵盖；本节仅旨在简要介绍机器学习的基本概念。

机器学习可以是有监督的或者是无监督的。有监督机器学习涉及将训练数据输入以创建模型。例如，如果我们想预测特定区域房屋的价格，我们可以将历史销售数据输入模型，并创建一个能够准确预测其他类似房屋价值的公式。

多年来，已有各种机器学习算法，这些算法被深入理解和信任。虽然有成千上万的算法并且它们总是可以改进，但最常见的算法，如线性回归，甚至在常见工具如 Microsoft Excel 中也是可以找到的。机器学习的难点通常不在于模型，而在于数据。

没有正确的数据，模型会变得不稳定。如果模型在测试数据上表现良好，但在实际场景中不能准确预测结果，就称其为不稳定。一个常见的技术是将历史数据随机分成两组，一组用于训练模型（训练数据集），另一组用于应用模型（测试数据集），以查看其是否能准确预测结果。这可能会捕捉到一些问题，但如果整个数据集有偏差，当模型应用于真实世界数据时仍然会是不稳定的。此外，模型训练时的条件可能会发生变化，模型可能不再适用。这称为“模型漂移”。例如，在房屋价格预测中，新的道路或新的商业可能会显著影响价格，因此我们需要重新训练模型以融入这些新信息。

总的来说，创建良好模型的关键在于拥有正确的特征——决定结果的模型输入。想象一下，在我们的房屋定价示例中，如果没有考虑学校质量，同一条街上两个相同的房子但在学区边界的对立面可能会有显著不同的价格，如果一个学校比另一个显著好。无论我们有多少数据来训练我们的模型，如果缺少这个变量，我们将无法准确预测房价。即使我们拥有正确的特征，我们也必须拥有具有代表性的数据。例如，如果我们所有的数据都来自表现类似的学区，模型将被训练忽略学校成绩，因为它们不会在房价中产生任何变化。为了准确训练模型，我们需要来自高、低表现学区的代表性混合数据。特征工程是每个数据科学家必须执行的最关键任务之一。

不仅拥有正确的数据很重要，而且数据质量也应该很高。与常规分析不同，常规分析中数据问题通常会导致不合理的结果，但在机器学习中，除非数据使模型不稳定，否则很难发现糟糕的数据。例如，在我们的情况中，如果学区信息损坏或错误，只要训练数据集和测试数据集都一致损坏，我们可能能够建立一个稳定的模型，但是在真实数据中，这些信息没有损坏，模型可能就毫无用处了。

非监督学习是指未经过训练的机器学习。例如，客户分群通常使用非监督机器学习完成。程序会提供一组客户和大量不同的人口统计信息，然后将数据分成“相似”的客户组。与监督学习一样，如果在糟糕的数据上进行分群，可能会产生不可靠的结果，而且很难发现例如你产生了 10 万名客户中的 7 个分群都有问题。由于模型往往非常复杂，以至于人类难以理解，可解释性已成为机器学习中的一个重要主题。

可解释性

曾经我与一位数据科学家进行过一次有趣的讨论，他告诉我他被聘请进行客户分群。当他向客户展示了模型的结果时，市场副总裁从同一个分组中挑选出两个客户记录，并问为什么这两个客户被归为一组。数据科学家无法解释结果，只能重述他训练模型的过程，然后副总裁宣布如果没有人能向他解释，他不会投资数十万美元用于基于此分群的市场活动。

解释性不仅仅是好奇心或调试的帮助。这是信任的一个根本问题。分析用户经常被要求证明他们使用的模型不会做出不适当或非法的决定。歧视是其中一个棘手的领域。想象一下一个镇，其中一个民族平均收入大约是另一个民族的四分之一。模型是否应被允许将种族作为一个变量来考虑？大多数人（以及反歧视法律）可能会说不。但是，如果我们基于收入做出决定呢？收入更高的人可能会在当地银行或商店获得更高的信用额度；这似乎是公平和常识的体现。然而，如果我们不知道申请信用时人们的真实收入水平怎么办？大多数商店信用申请不要求提供所得税单或工资单的复印件。此外，一些人可能参与零工经济，即使他们的家庭收入非常高，也没有正式收入，而其他人可能没有信用历史或分数可用于验证目的。该怎么办？

一个聪明的数据科学家可能会被诱惑从申请人的姓和名来推断种族，并将该镇该种族的平均收入与申请人报告的收入进行交叉参考。如果推断的收入和报告的收入相差甚远，申请过程将需要额外的信用检查。这是否合法？我们现在是在通过种族歧视吗？信贷官员又如何知道“计算机”为何要求额外的信用检查？如果数据科学家并非有意检查种族，而是算法盲目地发现了姓名与收入水平之间的相关性呢？

这些问题需要解释性。是哪些变量导致了这个决定？这些变量的值是多少？这是一个困难但有前景的机器学习领域。学术界以及像 FICO 这样的机器学习公司正在进行大量工作。

变更管理

由于现实世界很少保持不变，一度代表其的模型可能会失去其预测能力。这被称为模型漂移。由于模型的输出是预测性的，因此很难判断预测有多准确，因此模型是否仍然相关直到实际事件发生。因此，持续监控是保持模型准确运行的关键。如果检测到漂移，模型需要重新基于新数据进行训练。甚至数据本身也可能会漂移。例如，在像油田这样的恶劣条件下的物联网传感器可能会出问题。其中一些可能会开始喷出错误数据，这些数据不能影响模型的结果。必须检查这些数据漂移中的异常值，以确保错误数据不会破坏模型。

不幸的是，将现有模型重新运行在新数据上可能不会产生稳定的模型，因为模型不会反映可能影响结果的任何新变量。例如，曾经在一个社区准确预测房价的模型可能并未考虑到新的高速公路正在该社区建设中，而且这个高速公路的接近会显著影响房价。在这种情况下，除非将这个新变量（新高速公路的接近度）添加到模型中，否则模型可能无法准确预测房价。简言之，人们必须定期建立新模型或使用最合适的当前机器学习算法重新训练现有模型。

结论

高级分析、机器学习、预测分析、推荐引擎——这些技术应用广泛，但还有许多挑战需要克服，这些技术非常有前景。它已经改变了我们的生活，应用从自动驾驶汽车，到大大改进的语音识别和视觉识别技术，再到寻找基因密码中的疾病信号，读取物联网信号以提供预测性维护，或者预测我们的房屋价值。所有这些都依赖于数据——而获取数据的更好地方又何处比企业数据湖更好呢？

¹ 请参阅http://yann.lecun.com/exdb/mnist/和http://rodrigob.github.io/are_we_there_yet/build/classification_datasets_results.html。

第四章：开始建立数据湖

正如前一章所讨论的，数据湖的承诺在于以一种最大化可用性和可访问性的方式存储企业数据，以支持分析和数据科学。但是，最佳的起步方式是什么呢？本章讨论了企业建立数据湖的各种路径。

Apache Hadoop 是一个经常用于此目的的开源项目。虽然在云中有许多其他替代品，但基于 Hadoop 的数据湖能很好地展示它们的优势，因此我们将以 Hadoop 作为例子。我们将从回顾其定义和支持数据湖的一些关键优势开始。

Hadoop 的定义与优势

Hadoop 是一个大规模并行存储和执行平台，自动化了构建高度可伸缩和可用的集群的许多困难方面。它拥有自己的分布式文件系统 HDFS（尽管一些 Hadoop 发行版如 MapR 和 IBM 提供了自己的文件系统来替代 HDFS）。HDFS 自动在集群上复制数据，以实现高并行性和可用性。例如，如果 Hadoop 使用默认的三倍复制因子，则将每个数据块存储在三个不同的节点上。这样，当作业需要数据块时，调度程序可以选择使用三个不同的节点，并根据正在运行的其他作业以及数据位置等信息决定哪个节点最佳。此外，如果其中一个三个节点失败，系统会动态重新配置自身，以创建每个曾经位于该节点上的数据块的另一个副本，并在其余两个节点上运行当前作业。

正如我们在前一章中看到的，MapReduce 是一个运行在 Hadoop 之上的编程模型，利用 HDFS 创建大规模并行应用程序。它允许开发人员创建两种类型的函数，称为 mapper 和 reducer。Mapper 并行处理数据以计算结果，并将结果流向 reducer，用于最终输出数据。例如，一个统计文件中单词数量的程序可以有一个 mapper 函数，读取文件中的一个数据块，计算单词数量，并输出文件名及其在该数据块中计数的单词数。Reducer 将从 mapper 接收到的单词计数流，并在输出最终计数之前将文件的各个数据块合并。一个中间服务称为 排序与洗牌 确保将同一文件的单词计数路由到同一个 reducer。Hadoop 的美妙之处在于，单个 MapReduce 作业无需知道或担心数据的位置优化，也不需要关注哪些节点失败并正在恢复——Hadoop 会在背后透明地处理所有这些事务。

Apache Spark，它随每个 Hadoop 发行版一起提供，提供了一个能够在内存中跨多个节点处理大量数据的执行引擎。Spark 比 MapReduce 更高效且更易编程，非常适合于即席或接近实时处理，并且像 MapReduce 一样利用由 HDFS 提供的数据本地性来优化处理。Spark 还带有一系列有用的模块，如 SparkSQL，为 Spark 程序提供了 SQL 接口，并通过 DataFrame 支持异构数据源的通用处理。

然而，Hadoop 的主要吸引力在于，正如 图 4-1 所示，它是一个完整的平台和生态系统，包括开源和专有工具，解决各种各样的使用案例。最突出的项目包括：

Hive

与 Hadoop 文件类似的 SQL 接口

Spark

内存中执行系统

Yarn

分布式资源管理器

Oozie

工作流系统

图 4-1. 一个样例 Hadoop 架构

Hadoop 的几个特性使其作为长期数据存储和管理平台具有吸引力。这些特性包括：

极限可扩展性

大多数企业的数据都是在不断增长的，通常呈指数增长。这种增长意味着需要更多的计算能力来处理数据。Hadoop 设计上能够通过简单地增加更多节点来保持扩展（通常被称为“横向扩展”）。它被应用在全球一些最大的集群中，如雅虎和 Facebook。

成本效益

Hadoop 设计用于与现成的低成本硬件配合使用；运行在 Linux 之上；并使用许多免费的开源项目。这使得它非常具有成本效益。

模块化

传统的数据管理系统是单体化的。例如，在传统的关系数据库中，数据只能通过关系查询来访问，因此如果有人开发出更好的数据处理工具或更快的查询引擎，它无法利用现有的数据文件。关系数据库管理系统（RDBMSs）还需要严格的模式控制——在添加任何数据之前，必须预定义数据的结构（称为模式），并且如果数据发生变化，必须谨慎更改该结构。这种方法被称为“写入时模式”。另一方面，Hadoop 从头开始设计成模块化的，因此同一个文件可以被任何应用程序访问。例如，一个文件可以被 Hive 访问以执行关系查询，或者被自定义的 MapReduce 作业访问以进行一些重型分析。这种模块化使得 Hadoop 作为长期管理数据的平台非常有吸引力，因为新的数据管理技术可以通过开放接口使用存储在 Hadoop 中的数据。

松散的模式耦合，或者“读取时模式”

与传统关系型数据库不同，Hadoop 在写入数据时不会强制执行任何类型的模式。这使得所谓的无摩擦摄入成为可能——数据可以在不进行任何检查或处理的情况下被摄入。由于我们不一定知道数据将如何被使用，使用无摩擦摄入使我们能够避免处理和策划我们可能不需要的数据，并且可能会在未来的应用程序中处理不正确。将数据保留在其原始或原始状态，并在需求和用例明确时进行工作要好得多。

如果你正在为数据建立一个长期存储和分析系统，你希望它具有成本效益、高度可扩展和可用性。你还希望添加数据时需要的工作量最小化，并希望系统具有可扩展性，以支持未来的技术、应用和项目。从前文简要讨论中可以看出，Hadoop 完全符合这些要求。

防止数据水坑的扩散

随着大数据的热潮，有许多供应商和系统集成商在市场上向企业推广即时价值。这些人经常承诺快速投资回报（ROI），提供基于云的解决方案。对于许多商业团队来说，他们的项目在 IT 工作队列中停滞不前，他们厌倦了为优先级和关注而战，或者发现他们的 IT 团队缺乏完成他们要求的技能，这可能看起来像是梦想成真。几周或几个月后，他们得到了多年来一直要求 IT 部门完成的项目。

许多这些项目开始并产生快速胜利，导致其他团队进行类似的项目。很快，许多业务组都有了自己的“影子 IT”和自己的小 Hadoop 集群（有时被称为数据水坑），无论是在本地还是云中。这些单一用途的集群通常很小，并且是使用系统集成商（SIs）或企业开发人员熟悉的任何技术构建的，并且加载了可能或可能不严格来源的数据。

开源技术的不幸现实是，它仍然不够稳定，也不够标准化，以支持这种大规模扩散。一旦系统集成商（SIs）离开，第一个主要技术挑战出现——作业无法运行，库需要升级，技术不再兼容——这些数据水坑最终被遗弃或者被交还给 IT 部门。此外，由于数据水坑造成了信息孤岛，难以重新利用其中的数据以及在该数据上进行的工作的结果。

为了防止这种情况发生，许多企业更喜欢提前做好准备，建立一个集中的数据湖。然后，当业务团队决定他们需要 Hadoop 时，计算资源和项目所需的数据已经在数据湖中准备好了。通过提供预装数据的托管计算资源，同时通过自助服务赋予用户自主权，企业数据湖为企业提供了两全其美的最佳选择：支持难以维护的组件（通过 Hadoop 平台和数据供应），并免除在开展项目前等待 IT 的困扰。

虽然这是一个合理的防御策略，有时也是必要的，但要充分利用大数据所能提供的一切，它应该与下一节中描述的策略之一相结合。

利用大数据的优势

在本节中，我们将涵盖数据湖采用的一些最流行的场景。对于那些业务领导推动大数据广泛采用的公司来说，数据湖通常由 IT 部门建立，以防止数据小水坑（使用不同技术构建的小型独立集群，通常是由不再参与项目的系统集成商建立）的泛滥。

对于试图引入大数据的公司，有几种流行的方法：

• 首先将一些现有功能转移到 Hadoop，然后添加更多数据并扩展到数据湖。

• 从数据科学计划开始，展示出色的投资回报率，然后将其扩展为完整的数据湖。

• 从头开始建立数据湖作为治理的中心点。

哪一种适合你？这取决于公司在大数据采用过程中的阶段、你的角色以及我们将在本节中研究的许多其他考虑因素。

以数据科学为先导

确定一个影响公司业务前景的高能见度数据科学计划是一个非常吸引人的策略。数据科学是将高级分析和机器学习应用于数据的通用术语。通常，作为战略必要性起步的数据仓库最终支持报告和运营分析。因此，虽然数据仓库仍然对运行业务至关重要，但它们大多被视为必要的开销，而不是战略性投资。因此，它们没有得到尊重、认可或资金优先级。许多数据仓库和分析团队将数据科学视为能够显著影响业务和业务前景，重新成为战略重要性的一种方式。

将数据科学引入组织的最实际方法是找到一个高度可见的问题：

• 定义清晰且理解透彻

• 可以展示快速、可衡量的好处

• 可通过机器学习或高级分析解决

• 需要团队能够轻松获取的数据

• 如果不应用数据科学技术，将会非常困难或耗时很长

虽然寻找这样的项目可能看起来令人生畏，但大多数组织通常能够识别出许多知名的、高能见度的问题，可以快速展示好处，满足前两个要求。

对于第三个要求，通常可以通过两种方式识别出一个好的候选项目：通过搜索行业网站和出版物，了解其他公司如何使用机器学习解决类似问题，或者通过聘请经验丰富的顾问，他们可以推荐哪些问题适合机器学习或高级分析。一旦选择了一个或多个候选项目，并且确定了需要训练模型或应用其他机器学习技术的数据，就可以从获取的便利性角度审查数据集。这通常取决于数据的所有者，了解数据的人员的访问权限，以及获取数据的技术挑战。

不同行业常见的数据科学驱动项目的一些示例包括：

金融服务

治理、风险管理和合规（GRC），包括投资组合风险分析和确保符合众多法规（巴塞尔 3 号、了解你的客户、反洗钱等）；欺诈检测；分支位置优化；自动化交易

医疗保健

治理和合规，医学研究，患者护理分析，物联网医疗设备，可穿戴设备，远程医疗

制药

基因组研究，过程制造优化

制造业

收集物联网设备信息，质量控制，预防性维护，工业 4.0

教育

招生，学生成功

零售

价格优化，购买建议，购买倾向

广告科技

自动出价，交易所

一旦确定了问题，大多数组织会投资于一个小型的 Hadoop 集群，无论是在本地还是在云端（取决于数据的敏感性）。他们会引入数据科学顾问，经过流程，迅速产生显示数据湖价值的结果。

通常会执行两到三个这样的项目，然后利用它们的成功来证明数据湖的必要性。这有时被称为“施乐帕克”模型。施乐成立了加州帕洛阿尔托研究中心（PARC）来研究“未来的办公室”于 1970 年。1971 年，一位 PARC 研究员制造了第一台激光打印机，这成为施乐业务的主要支柱多年。但尽管 PARC 发明了许多其他改变行业的技术，没有一种技术像激光打印机那样成功地被施乐在如此大规模上成功商业化。将数据科学实验与 PARC 进行比较的重点在于突出数据科学的结果本质上是不可预测的。例如，一个长期而复杂的项目可能会产生一个稳定的预测模型，其成功预测率很高，或者模型可能只会产生轻微的改善（例如，如果模型成功率为 60%，比随机选择结果的成功率高出 10%）。基本上，在一些低 hanging-fruit 项目上的初步成功并不能保证许多其他数据科学项目的大规模成功。

这种为未来投资的方法听起来不错。构建一个大型数据湖，加载数据，并宣布胜利，这种方法可能非常诱人。不幸的是，我曾经与许多公司交谈过，它们正是按照这种模式进行的：它们进行了一些数据科学试点项目，很快就取得了惊人的成果。它们利用这些试点项目来确保获得数百万美元的数据湖预算，建立了大型集群，加载了几百万吉字节的数据，但现在却在努力增加使用率或展示额外的价值。

如果选择走分析路线，请考虑以下几点建议，这是许多 IT 和数据科学领导者与我分享的：

• 保持一个非常有前景的数据科学项目流水线，当您继续建设数据湖时，您将能够执行这些项目，以展示更多的价值。理想情况下，确保您可以在每个季度展示一个有价值的洞察，直到数据湖建设完成。

• 尽快将数据湖从最初的数据科学用例扩展到更广泛的用途，比如将其他工作负载移入湖中，从 ETL 到治理再到简单的 BI 和报告工作。

• 不要试图一下子解决所有问题。继续建设集群并添加数据源，同时继续展示更多的价值。

• 专注于让更多部门、团队和项目使用数据湖。

总之，数据科学是一种非常有吸引力的方式来利用数据湖。它通常会影响顶线，通过商业洞察的价值创造 ROI，并提高数据的价值意识以及数据团队提供的服务的知名度。建立成功的数据湖的关键在于确保团队能够持续生产这样有价值的洞察，直到数据湖多样化到更多用例，并为广泛的团队和项目创造可持续的价值。

策略 1：卸载现有功能

大数据技术最引人注目的好处之一是其成本，可以比类似性能和容量的关系数据仓库低 10 倍或更多。由于数据仓库的大小只会增加，并且 IT 预算通常包括扩展的成本，因此将一些处理从数据仓库卸载而不是扩展数据仓库非常具有吸引力。这种方法的优势在于不需要业务赞助，因为成本通常完全由 IT 预算承担，并且因为项目的成功主要依赖于 IT：卸载应对业务用户来说是透明的。

将 ETL（提取、转换、加载）的T部分卸载到大数据系统中是最常见的处理任务。

Teradata 是大型大规模并行数据仓库的主要提供商。多年来，Teradata 一直倡导将数据仓库的加载过程视为 ELT（提取和加载数据到 Teradata 的数据仓库，然后使用 Teradata 强大的多节点引擎进行转换）。这种策略被广泛采用，因为一般的 ETL 工具无法有效处理需要转换的大量数据。另一方面，大数据系统可以轻松处理这些数据量，并且具有非常高的成本效益。因此，Teradata 现在主张在大数据框架（特别是 Hadoop）中进行转换，然后将数据加载到 Teradata 的数据仓库以执行查询和分析。

另一种常见的做法是将非表格数据的处理移至 Hadoop。许多现代数据来源，从网页日志到 Twitter 供稿，都不是表格化的。与关系数据的固定列和行不同，它们具有复杂的数据结构和各种记录。这些类型的数据可以在 Hadoop 中以其原生格式进行非常高效的处理，而不需要转换为关系格式并上传到数据仓库以供关系查询处理。

第三类常被转移到大数据平台的处理是实时或流式处理。像 Spark 这样的新技术允许在内存中进行多节点大规模并行处理数据，而 Kafka 则是一种消息队列系统，使得对数据进行实时分析、复杂事件处理（CEP）和仪表板非常有吸引力。

最后，大数据解决方案可以以比传统技术低得多的成本扩展现有项目。我曾与一家公司交流，他们将一些复杂的欺诈检测处理移至 Hadoop。Hadoop 能够以与关系数据库相同的计算资源成本，处理 10 倍更多的数据，速度也快 10 倍，从而创建数量级更准确的模型和检测。

移动到数据湖的好处的一个例子涉及一家大型设备制造商，其设备每天将其日志发送到工厂（这些称为“呼叫家庭日志”）。制造商过去会处理日志，并仅将 2%的数据存储在关系数据库中，用于预测建模。模型预测设备何时会失败，何时需要维护等等。每当日志格式或内容发生变化，或分析师需要其他数据用于其预测模型时，开发人员必须更改处理逻辑，分析师必须等待几个月以收集足够的数据才能运行新的分析。使用 Hadoop，这家公司能够以远低于之前仅存储 2%数据成本的价格存储所有日志文件。由于分析师现在可以访问所有数据，无论多久以前的数据，他们可以快速为内部数据质量倡议以及面向客户的数据部署新的分析。

当 IT 团队将这种自动化处理转移到大数据框架并积累大量数据集时，他们面临将这些数据提供给数据科学家和分析师的压力。要从自动化处理转向数据湖，他们通常需要经历以下步骤：

• 添加未被自动作业处理的数据，创建一个全面的数据湖。

• 为非程序员提供数据访问权限，使他们能够创建数据可视化、报告、仪表板和 SQL 查询。

• 为了促进分析师的采用，提供全面的可搜索目录。

• 自动化管理数据访问、敏感数据处理、数据质量和数据生命周期管理的策略。

• 通过设置优先执行和资源管理方案，确保自动作业的服务级别协议（SLAs）不受分析师工作的影响。

策略 2：为新项目建立数据湖

不是将现有功能卸载到大数据平台，一些公司使用它来支持新的运营项目，例如数据科学、高级分析、处理来自物联网设备的机器数据和日志，或者社交媒体客户分析。这些项目通常由数据科学团队或业务线团队推动，并经常作为数据小湖开始，即小型、单一目的的大数据环境。随着越来越多的用例被添加，它们最终演变成成熟的数据湖。

在许多方面，从新的运营项目开始的路径与为现有项目卸载过程类似。新项目的优势在于它为公司创造了新的显著价值。缺点是它需要额外的预算。此外，即使与数据湖无关，项目失败也可能影响企业对大数据技术的看法，并对其采用产生负面影响。

策略 3：建立中央治理点

随着越来越多的政府和行业法规以及愈加严格的执法，治理正在成为许多企业的主要关注点。治理旨在为用户提供符合政府和公司法规的安全管理数据访问。它通常包括对敏感和个人数据、数据质量、数据生命周期、元数据和数据传承的管理。(第六章 将对此主题进行更详细的讨论。) 由于治理确保企业遵守政府和公司法规，而这些法规适用于企业中的所有系统，因此治理要求企业实施和维护一致的政策。不幸的是，对于大多数企业来说，跨使用不同技术的异构系统，并由不同团队管理且具有不同优先级的系统实施和维护一致的治理政策是一个严峻的问题。

数据治理专业人士有时认为大数据和 Hadoop 是一个遥远的、未来的问题。他们认为他们首先必须为传统系统实施数据治理政策，然后再解决新技术的问题。虽然这种方法并非没有优点，但它忽略了使用 Hadoop 作为成本效益平台为企业提供集中治理和合规性的机会。

传统上，治理要求说服负责传统系统的团队投入有限的人力资源来改装其系统，以符合治理政策，并且将昂贵的计算资源用于执行与这些政策相关的规则、检查和审计。通常，告诉负责传统系统的团队将其数据导入 Hadoop，以便一套标准的工具可以实施一致的治理政策，会更为简单和经济高效。这种方法具有以下优点：

• 数据可以通过一套标准的数据质量技术和统一的数据质量规则进行概述和处理。

• 标准的数据安全工具可以检测和处理敏感数据。

• 保留和 eDiscovery 功能可以在各系统中以统一的方式实现。

• 合规报告可以针对单一统一系统进行开发。

此外，基于文件的大数据系统如 Hadoop，非常适合 双模态 IT 的理念，该方法建议创建不同区域，具有不同程度的治理。通过为原始数据和干净数据保持分开的区域，数据湖支持同一群集中的各种治理程度。

对您来说哪种方式是正确的？

这些方法中的任何一种都可以导致成功的数据湖。你应该选择哪一种？通常取决于你的角色、预算以及你能招募的盟友。通常情况下，使用你控制的预算来启动一个数据湖是最容易的。然而，无论从哪里开始，要让数据湖起飞并保持可持续性，你都需要一个计划，说服企业中的分析师开始在他们的项目中使用它。

如果你是 IT 高管或者大数据的倡导者，图 4-2 中的决策树应该帮助你制定数据湖战略。

在高层次上，需要采取的步骤如下：

1. 确定是否有任何数据水坑（即业务团队是否在他们自己的 Hadoop 集群上使用？）。

   1. 如果有的话，是否有任何项目愿意转移到集中式集群？

      1. 如果是这样，使用项目成本来为集中式集群辩护。

      2. 如果没有，为了避免数据水坑的泛滥，理由充足地建设一个数据湖。可以使用先前的泛滥（例如数据集市，报告数据库）作为例子。如果你无法获得批准，那就等着水坑出问题吧——时间不会太长。

   2. 如果没有数据水坑，是否有团队正在寻求大数据和/或数据科学？如果没有，你能说服他们赞助吗？

2. 找到低 hanging fruit。尝试识别低风险、高可见性的项目。

3. 尝试为每个团队安排多个项目和多个团队，以最大化成功的机会。

4. 沿着数据科学/分析的路线走：

   1. 如果没有团队准备赞助一个大数据项目，是否有数据治理倡议？如果有，试图提出并获得单一治理点路线的批准。

   2. 否则，审查顶级项目，并识别任何需要大规模并行计算和大数据集，并且使用 Hadoop 更具成本效益的项目。

5. 最后，找到现有的工作负载进行卸载。

图 4-2. 数据湖策略决策树

结论

有很多方法可以实现数据湖。虽然每种情况都不同，但成功的部署通常会分享几个特征：明确和有计划的计划，招募热情的早期采用者，并展示即时价值。

第五章：从数据池/大数据仓库到数据湖

尽管三十多年前引入时，数据仓库被设想为提供企业数据的历史存储的手段，使其可用于各种新的分析，但大多数数据仓库最终成为仅用于最关键分析的生产级数据存储库。这些数据仓库大多数无法处理它们所包含的大量和多样化的数据。像 Teradata 这样的一些高端系统能够提供令人钦佩的可伸缩性，但成本非常高昂。大量时间和精力花费在调整数据仓库系统的性能上。因此，任何变更——无论是新查询还是模式变更——都必须经过详尽的架构审查和漫长的批准和测试过程。加载数据仓库的 ETL 作业同样精心设计和调优，任何新数据都需要更改这些作业，并进行类似复杂的审查和测试流程。这种做法阻碍了即席查询，并且抑制了模式变更，导致数据仓库缺乏灵活性。

数据湖试图通过引入极限可扩展性、灵活性、未来保障和最终用户自服务，来实现企业数据存储库的原始承诺。在本章中，我们将更详细地探讨数据池——使用大数据技术实施的数据仓库，并解释这些池（或涵盖它们的数据湖）如何提供组织目前使用传统数据仓库的功能。

数据湖是企业数据的理想存储库，因为它们以适当的方式托管不同类型的数据，可以被同一大规模并行可互操作系统内的不同处理系统用于不同目的。我们将讨论向数据仓库难以或不可能添加的数据的添加、将数据湖与数据源集成以及将数据湖中的数据与其他系统消耗的问题。

数据仓库的基本功能

由于许多数据湖旨在补充甚至取代数据仓库，并且数据仓库通常是企业中最容易、最大、最好的数据源，因此了解它们以特定方式执行任务的原因以及数据湖如何受到这些限制，以及在大数据技术中可以使用什么技术来解决这些挑战非常重要。

数据仓库的最初愿景是为未来使用托管（或存储）所有历史数据。随着概念的正式化，数据仓库变成了高度管理的系统，具有精心控制的模式和耗时的变更过程。现代数据仓库通常专注于支持来自多个来源的大量历史数据的分析。为了实现这一目标，数据架构师需要确保：

• 数据被组织以促进高性能分析。通常通过创建星型模式的维度建模来实现。此外，由于成本和性能的影响，数据仓库通常无法保留完整的历史数据，必须聚合或存档旧数据。

• 多个系统的数据可以以一致的方式进行分析。这是通过使用包括符合尺寸、协调和规范化等技术，将来自不同系统的数据集成为一致表示来实现的。

• 以确保历史分析准确性的方式管理变更。通常使用称为慢变维的技术实现，详细描述在第二章中。

• 确保数据干净和一致。这是通过使用数据质量工具和技术来实现的，也在第二章中讨论过。

正如前几章所述，ETL（抽取、转换、加载）过程用于将数据从源系统转换为可加载到数据仓库中的形式。这种转换可以在数据仓库外部或内部完成。外部解决方案利用多种已有几十年历史的 ETL 工具。内部解决方案将原始源数据加载到数据仓库中，并使用由数据仓库执行的 SQL 脚本应用转换，这种技术称为 ELT（抽取、加载[到目标数据仓库]、转换）。在两种情况下，数据质量工具经常与 ETL 工具集成，并作为过程的一部分执行。

由于基于大数据技术的数据池或湖具有高度可扩展性和成本效益，因此它可以轻松克服数据仓库的性能和数据量限制。因此，良好的性能不需要像大多数数据仓库那样进行维度建模或汇总旧数据。然而，关于历史分析，许多数据仓库的挑战仍然适用。这些挑战包括：

• 为分析建模数据

• 将来自不同系统的数据集成到一个公共表示中

• 管理变更而不丢失数据的历史记录

数据池或数据湖是存储未来使用并进行大规模分析的理想场所，但其使用像 Hadoop 这样的大数据技术也使其成为转换大量数据的好地方。数据池通常通过执行创建数据仓库模式所需的转换（称为 ETL 卸载）而开始生命周期。它们通过为分析提供原始和转换后的数据仓库数据，最终扩展以包括来自原始数据仓库中不含的外部或内部源数据，并发展成为完整的数据湖。

在我们研究数据池如何处理上述挑战之前，让我们再次从传统数据仓库的背景下看看这些问题。

用于分析的维度建模

正如我们在第二章中看到的，当关系数据库用于支持操作系统和企业资源管理（ERM）以及客户关系管理（CRM）等应用时，数据通常存储在高度规范化的数据模型中。操作系统倾向于进行许多小的读写操作。这部分活动是规范化数据模型的原因之一，它试图创建具有最小冗余和最小字段数的表。除了使更新和读取非常快外，规范化还消除了数据不一致的风险。

相比之下，大多数数据仓库倾向于使用去规范化的数据模型，每个表包含尽可能多的相关属性。这使得可以通过一次数据遍历处理分析应用程序所需的所有信息。此外，数据仓库通常从许多来源和应用程序接收数据，每个来源都有其自己的模式，这些不同来源的数据必须转换为单一的通用模式。

这个主题在第二章中有详细论述，但作为简短的复习，数据仓库常用的一种流行数据模型是星型模式，包含代表被分析实体的维度表（例如客户、时间、产品）和代表涉及这些维度的活动的一个或多个事实表（例如已下订单）。

难点在于数据的来源通常以不同的方式表示相同的信息：例如，一个可能将每个地址拆分为多个字段（如街道、城市和州），而另一个则将地址存储在单个字段中。类似地，一些系统可能保留出生日期，而其他系统则为每位客户存储年龄。在这种情况下，需要将数据转换为数据仓库使用的格式。例如，所有地址字段可能需要连接起来，或者可以根据出生日期计算一个人的当前年龄。如果所有来源系统的数据都保留在相同的维度表中，并采用相同的目标格式，这些表就称为符合的表。

整合来自不同来源的数据

大多数现代 ETL 工具是大约二十年前作为数据仓库运动的一部分开发的，旨在将来自不同操作系统的数据，其具有不同模式和表示，转换为单一的通用模式。因此，ETL 工具解决的第一个挑战是将来自操作系统偏好的规范化模式的记录转换为数据仓库偏好的去规范化模式，正如前一节所述。

第二个挑战是将来自许多不同操作应用程序的数据转换为单一的公共模式和表示法——这是在该部分提到的“符合”数据。我们在第二章中看到了一个例子，展示了如何使用 ETL 作业将操作系统对客户数据的表示转换为数据仓库期望的客户维度表的表示（参见图 2-7）。

数据仓库通常包含来自许多不同来源和应用程序的数据，每个都有自己的模式，并且来自所有这些来源的数据必须以不同的方式标准化和转换为数据仓库的首选模式，使用每个源系统的不同 ETL 过程。这导致必须维护和版本化的 ETL 脚本数量迅速增加。

保留历史数据的慢变维度

数据仓库中的大部分维度数据都是相当静态的（客户数据、零售或地理位置数据等）。然而，随着时间的推移，这些数据可能会发生变化，为了准确的数据分析，有必要跟踪这些变化。为了在考虑历史数据时表示维度变化，已经开发出了一种特殊的结构，称为慢变维度。这确保在数据某些方面发生变化（婚姻或工作状态、地址等）时，正确的状态被考虑进分析中。关于数据仓库中慢变维度的详细使用已在第二章中描述。

数据仓库作为历史存储库的局限性

遗留系统和数据仓库，因为存储和处理成本高昂，企业被迫将历史数据保留在比最近数据更粗粒度的级别上。例如，数据仓库可能保留过去三年的单个交易，过去七年的每日总数，以及超过七年的数据的月度总数。这引发了一系列问题：

• 数据聚合会丢失很多有用的细节，从而限制了可以进行的分析类型。

• 大多数历史分析必须以粗粒度进行（在我们的例子中，可能是每日或每月的级别，这取决于分析是否超过七年的时间）。

• 编写考虑不同粒度级别的报告和查询是复杂且容易出错的。

• 管理这个系统并将数据移动到各种粒度级别会增加处理和管理开销。

大多数高级分析应用程序可以从拥有更多历史数据中受益。即使是简单的分析和历史趋势，在给定更多历史数据时，都能给出更完整的图像，无论是在持续时间还是属性数量上。

像 Hadoop 这样的可扩展和成本效益的存储和执行系统允许企业以最精细的粒度存储和分析其历史数据，从而提高分析结果的丰富性和准确性。

例如，欺诈检测算法依赖于分析大量的交易来识别欺诈模式。一项广为人知的案例研究描述了 Visa 如何开始使用 Hadoop 进行欺诈检测，并从使用单一模型分析 40 个属性的客户交易的 2%转变为使用 18 个模型分析 500 个属性的所有交易，从而使公司能够识别数十亿美元的欺诈交易。

转向数据池

现在我们已经讨论了在传统数据仓库中工作的挑战，我们可以探讨如何通过数据池或数据仓库和数据池的组合来解决这些问题。在本节中，我们将讨论为有效摄入和处理数据组织数据的替代方法，以及如何保留历史记录（传统上使用维度表实现）。

在数据池中保留历史记录

让我们首先检查如何在数据池中使用分区保留历史记录，以及这种方法在跟踪缓慢变化的维度方面的局限性。接下来讨论一种新方法，即使用快照来解决这个问题。

在数据池中，随着数据的摄取，通常会存储在多个文件或分区中。每个摄取批次通常加载到一个单独的文件夹中。所有文件夹中的所有文件都被视为单个“逻辑”文件或表。Hive，作为 Hadoop 数据最流行的 SQL 接口，有一个称为 分区表 的特殊结构来处理这些文件。分区表允许 Hive 根据分区结构智能优化查询。

图 5-1 展示了用于每日加载交易数据的典型分区模式。一个 transactions 目录包含所有的交易。文件按年份组织（例如，/transactions/Year=2016），在每年内按月份组织（例如，/transactions/Year=2016/Month=3 包含了所有 2016 年 3 月的交易），在每月内按日份组织（例如，/transactions/Year=2016/Month=3/Day=2 包含了 2016 年 3 月 2 日的所有交易）。由于 Hadoop 进行大量并行处理，为了避免对单个文件的竞争，它会在 /transactions/Year=2016/Month=3/Day=2 目录生成多个文件。这些文件会合并成一个当天的交易文件。

图 5-1. Hive 中分区表的目录结构

在 Hive 中，用户会创建一个单独的表（比如，all_transactions），关联到transactions文件夹，并指定分区键（Year、Month、Day）。这个all_transactions表会包含transactions文件夹下所有文件中的数据。例如，SQL 语句select * from all_transactions会返回表中的所有行，实际上是返回transactions文件夹下每个子文件夹中每个文件的每一条记录，从目录树中最旧的文件开始，比如/transactions/Year=2014/Month=1/Day=1/99312312311333.json，到最新的，比如/transactions/Year=2016/Month=3/Day=2/722121344412221.json。

此外，Field``=``Value的命名约定（例如，Year=2016）允许 Hive 智能地将每个查询定向到可能包含所需数据的文件。例如，一个 SQL 查询select * from all_transactions where Year = 2016 and Month = 3 and Day=2会仅读取/transactions/Year=2016/Month=3/Day=2文件夹中的数据文件，而不是读取所有文件夹中的所有文件，然后再过滤出 2016 年 3 月 2 日的交易记录。

在数据池中实现逐渐变化的维度

现在，我们必须处理维度或参考数据，比如客户的婚姻状况或其他生活变化。如果我们从使用逐渐变化维度的数据仓库加载维度表，我们可以将更改记录—新客户和经历状态变化的客户—加载到单独的文件或附加到包含所有客户数据的单个文件中，因为所有处理客户状态变化的工作都已经完成。

然而，如果我们直接从操作系统加载数据，我们需要一种识别变化的方法。数据仓库使用的技术，创建逐渐变化的维度，会使数据池中的摄入和分析变得复杂。每次读取可能不仅向主数据表中添加记录，还向维度数据中添加记录。更糟糕的是，在后续的分析中，读取必须将一个表中的时间数据与另一个表中的正确记录进行关联。

去规范化属性以保留状态

另一种选择是将数据去规范化，并将所有重要属性添加到包含交易数据的文件中。例如，当我们从操作系统加载交易时，我们会在交易时添加有关客户人口统计、婚姻状况等信息。这样可以避免昂贵和复杂的连接操作。为了节省空间和处理能力，我们可以优化，仅在状态信息重要时添加属性—换句话说，我们可以仅添加数据仓库中逐渐变化的维度所需的字段。

这种方法的主要缺点是，将这些属性包含在与交易数据一起的数据集中，使它们可以与该特定数据集中的数据一起使用，但不能与其他数据一起使用。例如，我们可能有一个用于退货的单独数据集，一个用于保修的单独数据集等。要应用此技术，我们必须将所有客户属性添加到每个数据集中，从而增加存储和处理成本，并增加数据接收过程的复杂性。当引入新的客户属性或更改现有属性的使用时，我们还必须记住更新所有这些数据集。

使用快照保留状态

另一种选择是每天摄取最新版本的数据。为支持这一点，我们将有一个维度数据的目录树，但每天的文件夹不是数据集的一部分（一个分区），而是数据集的完整版本或快照。换句话说，在图 5-2 中的/customers/Year=2016/Month=3/Day=2文件夹将包含文件，这些文件连接后将得到 2016 年 3 月 2 日客户数据集的版本。

图 5-2. 维度表的分区文件夹

要获得客户记录的适当表示，我们必须将每个transactions记录与同一日期的customers记录连接起来。例如，如果我们为我们的transactions和customers数据集创建了 Hive 表，我们将使用 SQL 查询在客户 ID 和交易日期上进行连接（例如，all_transactions.customer_id = customers.customer_id and transactions.Year = customers.Year and transactions.Month = customers.Month and transactions.Day = customers.Day）以获取交易时客户状态。

查看所有数据的最简单方法是创建一个包含文件夹中所有文件的 Hive 表。但是，如果由于某种原因无法使用 Hive 或类似工具，则必须编写自定义代码，将transactions数据集的每个分区与customers数据集的相应快照相关联，以确保我们在交易时考虑的是客户数据的正确状态。

尽管这是一种昂贵的跟踪变化的方式，因为我们必须每天存储完整的客户数据，但它比创建缓慢变化的维度具有几个优点。首先，摄取是直接的，可以使用像 Sqoop 这样的简单工具。其次，快照保留了客户的所有属性的历史记录（而缓慢变化的维度仅跟踪一些属性）。此外，这种方法不要求我们在重要属性更改时每次分配一个新的客户关键字，这使得进行某些与客户相关的分析更加容易，比如随时间推移了解我们实际有多少真实客户。快照方法的最后一个优势是，如果某个时刻存储变得过于昂贵，那么可以将这个快照树转换为仅捕获缓慢变化维度的数据集。

将数据池扩展为数据湖——加载不在数据仓库中的数据

如今企业中的大多数数据都被丢弃，因为尚未知道其业务用例。没有明确的业务价值，就没有预算来支付数据保留的成本；而且在没有明确的用例的情况下，也不清楚创建什么模式来存储数据，或者如何转换或清洗数据。数据湖范式使得能够廉价地保留这些数据，并利用 Hadoop MapReduce 或 Spark 的可伸缩计算模型进行高效处理。

原始数据

正如我们之前讨论的，数据仓库仅保留干净、标准化的数据。不幸的是，很多重要信息在标准化过程中丢失了。问题包括：

数据广度

典型情况下，操作系统比数据仓库具有更多的属性。只有最关键和最常见的属性才会最终出现在数据仓库中。这样做的主要原因是为了减少存储和处理所有属性的成本，以及与加载任何内容到数据仓库相关的管理、ETL 开发和其他成本。

利用数据湖的可伸缩性和成本效益，可以存储和处理更多的信息。而且通过无摩擦的摄取（新数据加载时不经过任何处理），可以消除直到需要使用这些数据时才进行的 ETL 开发成本。

原始或原始数据

在数据仓库中，所有数据都被视为相同，并转换为单一格式。例如，一些系统可能指示薪水未知的字段使用NULL值或非法值如-1，但由于许多数据库无法对NULL字段执行聚合操作，并且-1不是合法的薪水，这些值可能会在 ETL 过程中或作为单独的数据清洗步骤中被替换为默认值，例如0。数据科学家们更倾向于能区分那些真的没有收入和那些收入未知的人——比如，他们可以将未知收入替换为该人群的平均收入，以创建更精确的模型。（这种变化被称为数据插值，是常规的分析活动。）

数据湖通常同时保留原始数据和处理后的数据，为分析人员提供选择。

非表格格式

大量的大数据（例如，社交媒体数据如 Twitter feeds）不是以表格格式存在，而是以文档形式（例如 JSON 或 XML）、列格式（例如 Parquet）、日志文件（例如 Apache 日志格式）或许多其他专用表示形式存在。因此，它不能轻易转换为关系型数据仓库模式。

因为数据湖通常是使用 Hadoop 等大数据技术构建的，它可以轻松容纳非表格格式。事实上，这些格式很受欢迎，并且在 Hive、Spark 和许多其他大数据项目中处理得很好。

外部数据

外部数据在数十年来一直是一个价值数十亿美元的行业。从尼尔森评级到 Equifax、TransUnion 和 Experian 信用报告，从晨星评级到邓白氏商业信息到彭博和道琼斯的金融交易，企业多年来一直在购买和利用外部数据。最近，数据来源和数据提供者的范围扩展到包括 Twitter 和 Facebook 等社交媒体公司，以及通过Data.gov和其他门户网站提供的免费政府数据。

企业面临外部数据的重大挑战，包括：

数据质量

质量问题涵盖了从不正确和缺失的数据到不同供应商提供的冲突数据。数据质量仍然是将外部数据整合到决策过程中的主要障碍。

许可成本

数据成本高昂。更糟糕的是，在许多企业中，同一数据被不同的部门多次购买，因为没有简单的方法共享数据集或知道公司是否已经购买了特定的数据集。

知识产权

数据提供商向数据提供订阅，许多要求客户在停止订阅时从其系统中删除所有数据。通常这不仅包括原始购买的数据集，还包括使用该数据生成的任何数据集。为了实现这一点，企业需要知道数据的位置以及数据的使用方式。

如 图 5-3 所示，两个不同团队可以购买相同的外部数据集，向供应商支付两次费用。每个团队都以不同的方式解决质量问题，并且生成的数据用于各种数据集和报告中，这导致生态系统中存在冲突的信息。更糟糕的是，谱系信息通常丢失，因此企业无法找到数据使用的所有实例，或者追溯数据回到原始数据集。

图 5-3. 两个不同团队购买和使用相同外部数据集

Hadoop 数据湖可以成为一个集中加载外部数据、解决质量问题、管理原始和清洁版本访问权限以及跟踪数据使用情况的中心位置。一个简单的方法是创建一个文件夹层次结构来存放外部数据，例如 /Data/External/<vendor_name>/<data_set_name>。因此，例如，如果公司从 CreditSafe 购买信用评级数据，可以将这些数据放置在 /Data/External/CreditSafe/CreditRatings 中。可以使用额外的文件夹来捕获更多细节。例如，2016 年的英国数据可以放在 /Data/External/CreditSafe/CreditRatings/UK/2016 中。如果组织中的任何人需要 2016 年英国的信用评级，他们在购买数据集之前就会知道去哪里找，如 图 5-4 所示。

图 5-4. 统一地存放外部数据以避免重复购买

这种方法的一个缺点是，不同供应商可能提供相似的信息——因此，寻找特定年份的英国信用评级的分析师需要检查每个供应商的文件夹，看看他们需要的数据是否已经可用。然而，如果我们改为按主题组织数据（例如 /Data/External/CreditRatings/UK/2016/CreditSafe），我们会遇到其他挑战。供应商的数据集并不总是与预定义的主题很好地对齐，并且可能包含额外的属性。例如，CreditRatings 数据集可能还包含人口统计数据。如果另一位分析师想要从 CreditSafe 购买人口统计数据，公司可能最终会支付两次这笔数据费用。即使有人注意到公司已经有了这些数据，它们也必须存储在两个分区中。

另外，数据所有者（为组织购买数据的部门）可能需要其他信息，如供应商 ID 或名称，以唯一标识数据集，但这些信息很难在一个固定的文件夹层次结构中捕获。

一个更加优雅和高效的方法是创建一个目录，用于捕捉外部数据集的多个方面，通过属性、标签和描述。例如，目录中的所有数据集都可以具有共同的属性，如供应商和所属部门，以及每个数据集特有的属性，如国家和年份。这样，数据集可以物理上存放在组织希望存放它们的任何地方，但仍然可以通过它们的属性找到它们。此外，因为目录通常捕捉数据集的所有属性或字段，分析师们可以很容易地找到相关的数据集，无论他们想要用它们做什么目的。

物联网（IoT）和其他流数据

数据湖特别适用于社交媒体和网络日志中的人类互动数据。这些数据通常远远超过典型的商业交易数据，无论是在数量还是复杂性上。数据湖对于来自数字物联网设备的自动数据尤为吸引人。因为机器可以比人类更快地产生数据，机器生成的数据预计将超过人类生成的数据，并且预计将成为未来的主要数据来源。从计算设备到飞机、医疗设备和电梯等大多数复杂机器都会生成在出现问题时发送回工厂的日志文件。越来越多地，这些数据被实时流回用于自动监控。这些数据用于监控和解决问题，以及使机器更智能化。从自动驾驶汽车到自动温控，智能机器越来越多地使用数据和分析来自我管理其操作。

尽管实时监控是实时执行的，但在没有与历史数据进行比较之前，很难解释实时行为。例如，要识别意外或异常行为，我们首先必须建立正常行为的基线，这需要分析历史数据并将其与我们实时观察到的情况进行比较。如果发生故障，将需要立即处理。此外，导致故障的行为——有时是在许多天、月甚至年内——应该被分析以寻找线索，目的是理解、检测和预防将来的这类故障。由于数据湖是保存这些历史记录的理想场所，已经开发了许多方法和架构来结合实时数据处理和历史分析。

在以下文章中，大数据先锋迈克尔·豪森布拉斯讨论了实时数据湖的一些最佳实践。

实时数据湖

迈克尔·豪森布拉斯是一位长期致力于大数据的前瞻者和实践者，他于 2008 年首次接触 Hadoop 和其他大数据技术。目前，迈克尔在 Mesosphere 负责 DevOps 关系。他是 Mesos 和 Drill 的 Apache 贡献者，曾是 MapR 在 EMEA 的首席数据工程师。

传统上，数据湖与静态数据相关联。无论数据本身是机器生成的（例如日志文件）还是手动生成的数据集（例如电子表格），基本思想是引入自助数据探索方法，使业务相关的数据集在整个组织中可用。

越来越多地需要考虑流数据源，无论是在移动设备、受限设备（如传感器）还是简单的人类在线交互（例如嵌入式客户支持聊天）的情况下：在所有这些情况下，数据通常应该在到达时进行处理。这与数据集静态地表现为转储并以批处理方式处理的想法形成鲜明对比。问题在于，如何构建这样的实时数据湖（暂时用此术语）？构建它们的指导性架构考虑因素是什么，以便即时获取可操作的洞察力？

在过去几年中，提出了几种主要的架构，允许同时处理静态和运动数据，实现大规模处理。值得注意的是，Nathan Marz 提出了 Lambda 架构的术语，用于描述一种通用的、可扩展的、容错的数据处理架构，基于他在 BackType 和 Twitter 上分布式数据处理系统的经验。Lambda 架构旨在满足对硬件故障和人为错误具有容忍性，并能为需要低延迟读取和更新的广泛工作负载和用例提供服务的系统需求。它结合了跨越所有（历史）事实的批处理层和用于实时数据的速度层。您可以在http://lambda-architecture.net了解更多相关信息。

另一个相关且相关的架构是Kappa 架构，由杰伊·克雷普斯于 2014 年引入。其核心是分布式日志，比 Lambda 架构更为简单。用于实现实时数据湖的其他架构变体可以在马丁·克莱普曼的优秀著作《设计数据密集型应用》（O’Reilly）中找到。

无论选择何种架构，最终您都需要为实施部分选择具体的技术。在这里，我将它们分为三类，您可能最终会至少选择每类中的一种技术：

• 数据存储：HDFS、HBase、Cassandra、Kafka

• 处理引擎：Spark、Flink、Beam

• 交互：Zeppelin/Spark notebook、Tableau/Datameer

最后但同样重要，在数据湖场景中，来源追溯至关重要。能够了解数据集（或数据流）的来源及其内容，并访问其他相关元数据，对于数据科学家正确选择和解释数据，以及提供结果的可信度测量至关重要。

实时数据湖已成功应用于多个领域，包括金融行业（从诈骗检测到奖励计划）、电信和零售。大多数组织从一个小而专注的应用程序开始，从结果中学习，并继续将这些应用程序特定的数据集扩展为跨不同部门和应用程序的数据湖，为组织提供既能在技术和人员用户方面扩展的数据基础设施。技术方面的可扩展性由数据基础设施的属性满足，包括在商品硬件上扩展的能力以及处理和存储系统的固有分布特性。然而，人员方面可能会更具挑战性。首先，缺乏元数据可能会将数据湖变成数据沼泽。此外，数据科学家、数据工程师和开发人员之间的顺畅互动值得特别关注。类似于DevOps 哲学，需要建立分享和共同责任的文化。

Lambda 架构

让我们更详细地看看 Michael Hausenblas 描述的 Lambda 架构。它结合了相同数据的实时和批处理处理，如图 5-5 所示。

图 5-5. Lambda 架构

传入的实时数据流存储在主数据批处理层中，并在速度层的内存缓存中保留。来自主数据集的数据随后被索引并通过批处理视图提供，而速度层中的实时数据则通过实时视图公开。

批处理和实时视图可以独立或合并查询，以回答任何历史或实时问题。这种架构非常适合于 Hadoop 数据湖，其中 HDFS 用于存储主数据集，Spark 或 Storm 形成速度层，HBase 可以作为服务层，而 Hive 创建可以查询的视图。

要了解更多关于 Lambda 架构的信息，请参阅《大数据：可扩展实时数据系统的原理与最佳实践》（Nathan Marz 和 James Warren 著，Manning 出版社）。

数据转换

在使用运营数据进行分析时，由于多种原因进行转换可能会很有用：

协调

不同来源的数据被转换成共同的格式或架构。这要求数据架构师理解并仔细映射每个来源系统的每个属性到这个共同的架构中。由于需要协调数据的工作量很大，实际上，大多数分析架构只包含很小一部分属性；大多数属性都被丢弃了。

实体解析和对账

来自不同来源的同一实体的不同实例（例如客户）需要被识别为指向同一个实例。例如，同一客户的姓名和地址在不同系统中可能略有不同，必须被识别和匹配。一旦一个实体被解析并且所有实例被分组在一起，任何冲突必须被解决（例如，不同来源可能为同一客户有不同的地址，冲突解决涉及决定保留哪个地址）。

性能优化

在某些系统中，例如关系数据库，一些架构可以促进更快的分析查询。星形架构，正如本章早些时候提到的，是一种常见的优化方案。

幸运的是，在数据湖中，由于只有在读取数据时强加模式（并且不像写入数据时那样强制执行，如第三章中描述的那样），操作数据可以按原样从各种来源摄入，并根据需要进行调和以供分析使用。我们不再丢弃我们现在无法调和的属性，而是将它们保留在数据湖中，直到我们需要它们并且可以证明我们可以进行这项工作为止。

实体解析可以采取相同的方法。与其费力费钱地协调来自不同系统的所有实体并解决所有属性的冲突，我们只解决我们项目所需的实体，并且仅考虑我们关心的属性的冲突。然后我们可以根据项目最合适的方式来解决它们。例如，通常实体解析可能集中于查找客户的当前地址。但是，如果我们正在为旧金山 49 人橄榄球队的促销活动确定目标客户，那么拥有客户的所有过去地址将是一个巨大的优势。我们的冲突解决将集中于确定一个人是否曾经住在旧金山，而不是试图弄清他们当前的地址。

最后，由于 Hadoop 是如此强大的转换引擎，并且可以在分析期间高效执行需要重大转换的大规模查询，因此出于性能原因，我们将不再频繁地将数据转换为适合分析的架构。

然而，有趣的是，Hadoop 经常被用于执行转换以供应其他系统，比如数据仓库。正如前面所述，这个将运营数据转换为数据仓库所需的分析模式的过程是一种 ETL 卸载的形式。运营数据被按原样摄取到 Hadoop 中，然后转换和加载到数据仓库中。一个实用的方法是将所有或大部分运营数据摄取到数据湖中，而不仅仅是数据仓库需要的数据。然后可以使用其中的一部分数据加载数据仓库，而所有数据都可以用于数据湖的分析和数据科学。此外，如果这些数据稍后需要添加到数据仓库中，它已经存在于数据湖中。

图 5-6 到 5-9 说明了纯 ETL 卸载向更通用的数据湖的扩展。我们从 图 5-6 中所示的传统数据仓库（DW）设计开始，其中使用 ETL 工具从运营系统中提取数据，将其转换为数据仓库模式，并将其加载到数据仓库中。

图 5-6. 传统 ETL 过程

多年来，高端数据库供应商鼓励他们的客户使用他们的数据库引擎进行转换（在 第二章 中讨论的 ELT 模型以及 图 5-7 中显示的），而不是交给外部的 ETL 工具来做。这些供应商认为，只有像他们这样高度可伸缩的系统才能处理数据仓库的容量和复杂性。

图 5-7. ELT 过程

在 ETL 卸载中，使用 MapReduce 或 Spark 构建的基于 Hadoop 的 ETL 作业或现有项目之一（如 Hive、Pig 或 Sqoop）取代了 ETL 工具或数据仓库在 ELT 中的工作，如 图 5-8 所示。运营数据被摄入 Hadoop 中，然后按所需的模式转换并加载到数据仓库中。

图 5-8. 使用 Hadoop 进行 ETL 卸载

此时，Hadoop 包含用于加载数据仓库的原始源数据，格式与原来相同。如果我们也添加其余的运营数据，那么我们就开始了一个包含着原始（原始）数据的着陆区的数据湖，以及包含着清洁和转换数据的经过策划或金牌区，如 图 5-9 所示。

图 5-9. 一个 Hadoop ETL 卸载项目，包含原始、清洁和转换数据

目标系统

数据湖中的数据可以被多种目标系统消费。这些系统通常是数据仓库、专业分析数据库和数据集市，但信息的使用者也可以是诸如 ERP 或 CRM 以及实时应用程序的运营应用，甚至是希望为其模型获取原始数据的数据科学家。

我们将检查以下目标系统的消耗范式：

• 数据仓库

• 运营数据存储（ODSs）

• 实时应用程序和数据产品

数据仓库

我们在前一节中已经讨论了 ETL 卸载。由湖中运行的卸载 ETL 作业生成的数据通常通过创建文件进行加载，这些文件可以使用本地数据库实用程序进行批量加载，或者创建简单的 ETL 作业，只加载数据而不进行任何转换。

运营数据存储

运营数据存储用于 consoli、清洗和规范数据。它解决了 ELT 方法的一个缺点，即 ELT 作业干扰和影响分析作业的性能。通过将所有处理移动到独立的 ODS 中，企业可以保护分析查询免受由 ELT 作业减速的影响。虽然数据湖可以用来向 ODS 提供处理过的数据，但实际上它是 ODS 的一个非常有吸引力的替代品，并且提供的数据还可以保留在数据湖中，供分析使用。在许多方面，将 Hadoop 或其他大数据平台用作 ODS 是 ETL 卸载的自然延伸。在这种配置中，更多的功能，如数据质量和主数据管理，被卸载到 Hadoop，结果被分发到其他以前从 ODS 获取数据的数据系统。

实时应用程序和数据产品

实时应用程序处理传入的数据流。存在各种行业特定的用例，用于处理实时信息，从自动库存补充到健康监控。数据产品是数据科学家创建的统计模型的生产部署。数据产品可以实时处理数据或批处理处理数据。

我们可以将实时应用程序和数据产品的输出大致归类为几类，如图 5-10 所示：

仪表盘

这些显示系统的当前状态。股票行情、实时选举结果以及机场到达和离开显示是实时仪表板的示例。随着实时事件的处理，状态会持续更新。

自动化操作

在处理事件时，根据特定条件，这些系统会自动响应。这也被称为复杂事件处理（CEP），可以控制从工厂操作到库存管理、自动补货、运输物流和气候控制的各种情况。这种类型的数据产品通常用于执行自动股票交易或广告拍卖竞标，其中可以在几秒钟内进行数百万次竞标。

警报和通知

这些系统是人力密集型流程（需要员工不断监控仪表板）和编写复杂自动程序的替代方案，用于处理任何可能的条件。许多实时系统通过自动化增强人类智能，指定通知条件，并在触发这些条件时向人类用户发送通知。这些条件可以从简单的条件（例如，当温度达到某个点时，在控制面板上弹出警告）到非常复杂的条件（例如，当网站流量超过这一天和这一年这个时间段正常流量的 20%时，向管理员发送电子邮件）。

数据集

数据产品经常执行生成数据集的批量操作，例如通过进行客户分群生成电子邮件营销活动的客户列表，或生成估算房价的报告。

图 5-10. 数据湖处理结果

结论

如本章所述，数据湖可以作为数据仓库的吸引替代方案，并可以包含一些现有的遗留系统和流程，如 ETL 和 ODS。然而，数据湖真正的力量和令人惊叹的价值在于，当其用于解决企业中出现的不同需求时，如高级分析、临时分析和业务用户自助服务，这些内容将在后续章节中涵盖。这段旅程并不简单，但数据湖的处理能力、集中和共享数据与处理的好处，以及大数据的经济效益都是非常引人注目的，使其非常值得。

第六章：为自助服务进行优化

数据的力量只有在决策者能够基于数据采取行动时才能实现。过去，业务用户必须等待专家准备数据和运行分析。这有效地阻止了许多有价值的查询进行，并经常导致延迟、错误和误解。

我曾与一位来自领先医学研究医院的医生交谈过，他利用了一周的假期学习了 SQL 课程。他解释说，他对特定的医疗治疗方案的效力感到担忧，但在没有证明变更安全的情况下，他无法更改方案。他花了一年的时间试图向 IT 解释他想要的内容——等待几周以接收数据集，意识到它们不是他要找的，请求更多数据，再等待，然后投入更多时间，最终发现这些数据也不是他需要的。最终，他对此感到非常沮丧，于是决定学习 SQL 课程，以便自己探索数据。在应用了他新获得的知识的两周内，他能够找到所需的数据，以改善治疗方案。这只是展示自助服务价值以及分析师能够取得的惊人突破的众多故事之一。

本章深入探讨了一个组织如何重新考虑其收集、标记和共享数据的方式，以实现赋予业务用户所需的自助服务模型。我们将探讨诸如帮助用户在数据湖中找到有用数据、建立数据正确性和价值的信任以及帮助用户进行自己的分析等问题。如果没有建立对数据的这种信任，业务分析师将不愿意使用现有数据进行决策，或者最终做出错误的决策。

自助服务的开端

过去的经验法则是数据仓库的第一组需求总是错误的——这是众所周知的数据仓库 1.0 问题。为了开始通向一个正常运作的数据仓库的旅程，IT 必须建立第一代架构，以及相应的报告。这为用户提供了一个具体的东西，以弄清他们真正需要什么，从而使 IT 能够生成“真正”的需求。除了少数几个高级用户外，大多数分析师没有直接处理数据的技能或工具。

IT 给用户带来的长时间响应，像我之前故事中的那位医生一样，源于对数据日益增长的兴趣和请求的数量。我们目睹了应用程序生成的数据量和从外部提供者获取的数据量的激增，以及业务用户希望能够在几乎实时的速度下利用这些数据的期望的同时增加。这两者同时增加的数据量和用户期望使得 IT 难以跟上步伐。

然而，新一代的分析师、主题专家（SME）和决策者比以往任何一代都更懂技术和计算机，因为他们在数字时代成长，并且大多数人在高中或大学课程中接触过编程。这一代用户更希望“自助服务”地访问数据；他们想要自己找到、理解和使用数据。此外，云技术使得业务用户能够绕过 IT 部门，自行提供运行分析所需的基础设施。

在本章中，我们将对比旧的方法和新的自助服务方法。在旧方法中，IT 部门为业务分析师提供分析服务，他们为业务用户执行分析。而现在，业务用户希望能够自行进行分析，避免不必要的复杂性，我将称执行分析的人为分析师——这可能包括任何人，从拥有正式分析师职称的人员，到自行进行分析的业务用户，再到进行高级分析的数据科学家。

虽然以前的 ETL 版本的数据建模和商业智能（BI）工具是为程序员和架构师设计的，新一代工具则专为高级用户直接访问而设计。过去，专家大多数工作是：

• 数据建模师为数据仓库设计了模式。

• ETL 开发人员创建了 ETL 作业，从源应用程序中提取数据，转换数据，并将其加载到数据仓库中。

• 数据质量分析师创建了验证作业来检查数据的正确性。

• BI 开发人员创建报告和在线分析处理（OLAP）立方体，用户可以对其进行切片和切块。

• 元数据架构师创建了业务术语词汇表，试图捕捉各种数据元素的含义，并创建了元数据存储库，试图跟踪企业中的数据。

分析师唯一可以执行的分析是通过语义层，例如 Business Objects Universes，允许最终用户使用高级预构建结构（如客户和订单）来组合数据，同时隐藏了实际数据操作的复杂性。例如，用户可以将客户和订单的业务对象添加到报告中，并能够查看每个客户的订单。虽然非常便利，但这种方法受制于 IT 工作人员创建的任何业务对象。任何变更都需要多人审核和批准，有时需要数月时间。

自助服务数据探索和可视化工具（如 Tableau、Power BI 和 Qlik）已颠覆了这种脆弱的情况。分析师现在使用自助服务数据准备工具（如 Excel、Trifacta 和 Paxata）直接将数据转换为所需的形式。

此外，自助服务目录工具（如 Waterline Data 和 IBM Watson Catalog）现在允许分析师自行注释、查找和理解数据集，无需从 IT 请求。

图 6-1 展示了在自助服务分析环境中，分析师依赖 IT 的程度以及对 IT 的负荷显著减少的情况。今天可用的自助服务工具几乎都是以分析师为目标用户开发的，并且通常不需要 IT 参与部署和使用（其中一个例外是跨越 IT 和业务的目录工具，通常由 IT 管理但由分析师使用）。然而，底层数据基础设施仍然完全掌握在 IT 手中，这保持了数据的稳定性。

图 6-1. 通过自助服务分析减轻 IT 负担并支持分析师

业务分析师们

不幸的是，今天大多数企业并不真正支持自助服务模型，因为数据仓库并未设计用于处理大量的临时查询和分析。正如我们之前讨论的那样，它们都精心调整以支持关键生产报告和分析。允许数百甚至数千用户发布随机且有时形式不完整的查询将干扰这些功能。此外，分析通常需要将数据仓库中的数据与其他数据集结合，但向数据仓库添加任何内容都是一个昂贵且漫长的过程，需要大量的设计工作、架构和安全批准以及 ETL 开发。

因此，在许多企业中，数据湖的主要目的之一是创建一个能够实现自助服务的环境。要理解自助服务，我们需要审视典型业务分析师的工作流程（图 6-2）。

图 6-2. 业务分析师的工作流程

如同我们在第一章中看到的那样，分析师首先必须找到并理解所需的数据。接下来的步骤是准备数据，即以可用的形式和格式获取它。然后，数据需要准备进行分析。这可能涉及合并、过滤、聚合、修复数据质量问题等等。一旦数据形状正确，分析师可以使用数据发现和可视化工具分析它。

我们将在此处详细查看此工作流程的前三个步骤，以及识别数据中建立信任的重要问题。

找到并理解数据——企业文档化

分析师希望使用他们熟悉的业务术语来搜索数据（例如，“我需要包括年度支出、年龄和位置在内的客户人口统计数据”），而数据集和字段通常通过晦涩的技术名称公开。这使得分析师在寻找和理解数据方面面临巨大挑战。为了弥合这一差距，许多企业正在投资于数据目录，将业务术语或标签与数据集及其字段关联起来，使分析师能够快速使用这些标签找到数据集，并通过查看与每个字段关联的标签来理解这些数据集。通常，多个数据集包含分析师需要的数据，因此下一步是选择使用哪一个。在做出选择时，分析师通常会考虑数据的完整性、准确性和可信度（我们将在下一节考虑建立对数据的信任问题）。

尽管目录对于为业务分析师提供自助服务至关重要，但建立和维护它们也具有挑战性。这是因为在大多数企业中，关于数据在何处、哪些数据集用于什么目的以及数据意味着什么的知识都锁在人们的脑中——这通常被称为“部落知识”。

没有目录的情况下，为了找到用于特定问题的数据集，分析师必须四处打听，直到找到可以指导他们的人员——如果他们幸运的话，可能是一个主题专家——帮助他们找到正确的数据。尽管如此，找到 SME（主题专家）可能很困难，所以分析师可能会遇到告诉他们使用了类似问题的数据集的人，然后在不真正了解它们是如何处理或它们来自何处的情况下使用该数据集。

这有点像用你的项目来玩俄罗斯轮盘赌——这就像询问周围是否有人知道可能了解你右侧疼痛的医生，然后遇到有人说他们右侧有疼痛并服用了特定的药物，然后你服用了他们的药物。不仅可能他们的药物不适合你，而且你不知道这是什么、它来自哪里，或者它有多老。即使找到了一个声称知道你疼痛情况的医生，你也不知道这个医生是否有资格来诊断它。不用说，无论是应用于身体还是数据处理，这都是一个非常痛苦（玩笑意味），耗时且容易出错的过程。

在这个 Google、Yelp 和 Wikipedia 时代，我们有一个优势，那就是习惯通过众包来获取知识。企业也已经开始将类似的方法应用于分析师从头脑中获取数据的众包部落知识，这样他们头脑中的信息可以被记录在词汇表和元数据存储库中。然而，这些努力是耗时的，并且遇到两个障碍。首先，只有最重要的数据得到了记录——通常称为关键数据元素（CDEs）。这些通常包括在主数据列表中找到的描述字段，例如客户和产品属性，以及核心交易字段，例如订单 ID、日期和金额。其次，即使对于关键数据元素，存储库也很快变得过时，因为数据集、业务流程和规则的变化以及技术的进步。

克服这些挑战的最佳实践是：

• 将所有部落知识进行众包，并向所有人提供

• 自动标注数据集

十年前，分析通常由专门的员工执行，他们将所有时间都花在与数据打交道，因此关于数据的知识集中在分析和数据架构团队中。在今天的企业中，决策需要的人员都会进行分析。再加上数据的激增，这使得更难以找到了解数据的专业人员。SME 通常不是全职工作或正式角色。一些企业已经开发了正式的数据管理框架，在这些框架中，人们被分配全职或更常见的兼职责任来管理数据，即确保其被适当使用，符合政府和内部规定，并保持高质量水平。然而，大多数 SME 甚至大多数官方数据管理者并没有得到帮助其他团队的报酬，但仍然期望完成他们的主要工作。SME 经常对这种角色感到不满，并不喜欢一遍又一遍地向不同的团队解释同样的材料。分析师已经知道通过午餐或其他激励手段贿赂 SMEs 以换取他们的时间和知识。但在这样的午餐结束时，分析师可能只得到了他们所需知识的一部分，并且如果幸运的话，可能已经得到了指向其他 SME 的线索。这导致了更昂贵的午餐！

由于企业开始认识到中小企业（SMEs）及其知识的价值，它们正在尝试各种激励众包的方法。一些最佳实践包括：

• 尽可能简化和高效化 SMEs 记录知识的过程。通常，通过创建术语表或术语分类体系来实现这一目标，并让 SMEs 使用这些术语标记数据集，而不是为每个字段撰写详细的描述。

• 进一步通过“民间分类法”（folksonomy）提升标签的效果，允许 SMEs 使用他们熟悉的术语作为标签，而不是强迫他们学习强加的分类体系（无论是自行开发的还是行业标准，如金融服务的 FIBO）。例如，美国分析师可能寻找“first name”和“last name”，而欧洲分析师则寻找“given name”和“family name”。虽然这些只是简单的同义词，有时术语还具有额外的内涵和语义。例如，一个企业可能认为“due date”和“default date”是相同的，而另一个企业可能有一个“宽限期”，因此“default date”就是“due date plus grace period”。不同地理位置、企业、功能和收购所引入的多样性和复杂性令人震惊。

• 鼓励 SMEs 分享他们的知识，通过公开认可他们的工作，从游戏化和徽章到项目简单的认可，表明他们已经帮助过的项目。

• 方便查找该询问哪些数据集的人。这不仅帮助分析师找到正确的联系人，还鼓励 SMEs 记录他们的数据集，从而避免每次都需要向新用户解释。例如，当 Google 实施了可搜索的目录，用户可以找到每个数据集的 SMEs 时，他们发现经常使用的数据集很快得到了记录，因为 SMEs 厌倦了回答问题。

• 通过让与 SMEs 交谈的分析师轻松记录他们学到的东西作为标签和注释，以便将来保留并避免再次打扰 SMEs，使知识迅速传播并得到制度化，这可能是最有效的技术。

尽管众包 SMEs 的知识是迈向自助服务的重要一步，但企业中的数据量庞大，手动记录所有内容是不现实的。因此，通常只有少数几个广为人知且经常使用的数据集得到充分记录，而大多数数据则保持在黑暗之中。这也导致了新数据集的问题，可能不会立即得到记录，因此分析师可能无法找到这些数据。

这个问题的答案是自动化。新工具有效地结合了众包和自动化，进行“自动化数据发现”——基于 SMEs 和分析师提供的标签对数据集进行自动标记和注释。这些工具利用人工智能（AI）和机器学习识别和自动标记黑暗数据集中的元素，以便分析师可以找到并使用它们。Waterline Data 的智能数据目录和 IBM 的 Watson 数据目录就是这种方法的良好示例。目录在第八章中有更详细的探讨，见 ch08.xhtml#cataloging_the_data_lake。

建立信任

一旦分析师找到相关的数据集，下一个问题是数据是否可信。虽然分析师有时可以访问干净、可信、经过策划的数据集，但更多情况下他们必须独立判断是否可以信任这些数据。信任通常基于三个支柱：

• 数据质量—数据集的完整性和清洁度如何

• Lineage（又称来源）—数据的来源

• 管理—谁创建了数据集，以及为什么创建

数据质量

数据质量是一个广泛而复杂的主题。在实践中，质量可以定义为数据符合政策的程度，这些政策可以从简单（例如，客户姓名字段不应为空）到复杂（例如，根据购买地点正确计算销售税）。最常见的数据质量规则包括：

完整性

该字段不为空。

数据类型

该字段为正确类型（例如，年龄是一个数字）。

范围

该字段位于指定范围内（例如，年龄在 0 至 125 之间）。

格式

该字段具有特定格式（例如，美国邮政编码由五位数字、九位数字或五位数字后跟连字符和四位数字组成）。

基数

该字段具有特定数量的唯一值。（例如，如果一个美国州名字段有超过 50 个唯一值，我们就知道有问题。我们可能还不知道每个值是否都是合法的州名，但如果我们已经有了每个合法的州名的表示，检查基数就足以进行健全检查，以捕捉任何非法名称，因为它们会将值的数量推高到 50 以上。）

选择性

该字段的值是唯一的（例如，客户 ID 在客户列表中应是唯一的）。

参照完整性

该字段的值位于参考值集中。（例如，所有客户状态代码都是合法的，订单列表中的每个客户 ID 都指向客户列表中的一个客户。对于某些值，如州名，我们可能可以通过基数检查来进行检查，但客户状态代码可能会对我们如何对待客户、收取费用等方面产生重大影响，因此在确保每个客户具有合法状态代码时，检查每个值非常重要。）

检查数据质量的最常见方法称为数据概要分析。这种方法涉及读取每个字段中的数据并计算指标，例如空字段数（完整性）、唯一值数（基数）、唯一值百分比（选择性），以及检查数据类型、范围和格式，并执行参照完整性检查。

除了基本数据概要分析外，还可以定义自定义规则来验证数据的特定方面。概要分析的优点在于可以自动和普遍地对所有字段进行，然后由考虑是否使用数据集来确定质量水平的分析员进行审查。另一方面，自定义规则必须手动设计、实施并应用于相关数据集。

血统（来源）

虽然数据质量检查告诉分析员数据的好坏程度，但数据血统告诉他们数据的来源。例如，来自 CRM 系统的客户数据比来自专门数据市场的客户列表更可靠，因为前者是客户数据的记录系统，而后者可能是某个地理区域或人口统计的客户子集，并可能包含修改或过时的客户数据。

在一些行业中，如金融服务业，数据血统作为法规合规的一部分是必需的。例如，巴塞尔银行监督委员会的规则 239 要求金融服务公司向审计员展示用于财务报告的数据的血统。因此，如果黄金区的数据用于财务报告，有必要记录其血统并保持更新。

表示数据血统存在许多挑战，特别是系统标识和转换逻辑方面。由于数据经过多个系统和工具，很难确定不同工具是在指同一系统还是不同系统。此外，由于不同工具以不同方式表达它们的转换——有些可视化，有些使用编程语言，有些使用查询语言或脚本——因此很难以统一的方式表示所有已执行的转换。

首先看看标识。想象一下，一个 Hadoop 文件是使用名为 Sqoop 的开源 Hadoop 实用程序创建的，该实用程序使用 Java 数据库连接（JDBC）执行关系数据库查询，并将结果加载到文件中。然而，另一个 Hadoop 文件是通过读取相同数据库中同一表的数据创建的，使用的是一个使用开放数据库连接（ODBC）接口的 ETL 工具。也许没有程序化的方法能够识别这两个文件都是从同一个数据库中提取的。此外，因为 Sqoop 可能执行一个自由格式的查询，可能无法识别 Sqoop 最终读取的是与 ETL 工具相同的表。

ETL 工具的一个卖点是，如果所有转换都由单个工具执行，那么该工具解决了标识问题，并且可以使用该 ETL 工具本地使用的任何表示来轻松表示技术血统。然而，如果您的企业像大多数企业一样使用多个 ETL 工具，则必须解决标识问题以及表示问题。有许多表示血统的方法，具体取决于目标受众。例如，业务分析师更喜欢描述使用业务术语和简单解释生成数据的业务级血统。大多数技术用户更喜欢显示用于生成目标数据集的具体代码或该代码的严格等效图形表示的技术血统。

技术血统具有挑战性，因为数据集可能通过多个步骤使用各种程序、编程语言、脚本和工具生成。需要考虑技术血统的两个方面：粒度和转换表示。

您可能会遇到两种粒度级别：

数据集级别的粒度

各种数据集之间的血统关系通常被捕获和表示为有向图。换句话说，获取或转换数据的每个步骤都显示为一个节点或框，箭头显示数据通过这些节点的单向流动。经常，用于生成数据集的程序也被表示为图上的节点，而不是详细的代码片段。

字段级别的粒度

每个字段的血统都被捕获并表示为一个有向图，通常不同节点表示不同的变换。有时，这种血统级别与数据集级别合并为单一图，用户可以在界面上从数据集级别钻取到特定目标数据集的字段级别。

还有两种可能看到的转换表示：

规范化表示

所有变换都被转换为一个共同的表示。这很困难，因为数据集可能使用各种过程和声明性语言生成，因此翻译可能复杂（甚至不可能）。

原始表示

所有变换都以原始语言或脚本呈现。这也是有挑战性的，因为可能使用复杂软件生成数据集，仅从逻辑上提取生成数据集时使用的代码可能非常困难。

让我们举个例子。假设我们有两个 Hadoop 文件：一个从数据仓库下载，包含完整的客户列表及其地址；另一个来自名为Data.gov的公共网站，提供每个邮政编码的平均收入。

下载文件后，我们基于文件所在目录创建了两个 Hive 表——Cust和IncomebyZip——以提供关系（SQL）接口。然后，我们执行 SQL 查询，从Cust表中选择加利福尼亚客户，并与IncomebyZip表进行连接，生成最终表CalCustRelIncome，该表根据他们家庭收入与其邮政编码平均收入的比较对每位客户进行评级。

这个流程的业务血统将看起来像图 6-3。它会跳过所有中间步骤和细节，并提供英语（或其他语言）的描述作为标注，记录每个主要步骤的完成情况。当然，用口头方式描述业务级别的问题是，必须有人编写它们，而且更具挑战性的是，在代码发生变化时进行维护。另一方面，这些描述可能是向业务分析师解释数据集生成方式的唯一实用方式。

图 6-3. 业务级血统

更技术性的数据集表示在图 6-4 中有所体现。它给出了主要步骤的相对高层视图以及数据来源。但是，它并不提供操作的详细信息。例如，如果我们没有将目标表称为CalCustRelIncome，则无法从数据集级血统推断出只选择了Cust表中的加利福尼亚客户。

图 6-4. 数据集级技术血统

有时可以向此谱系添加更多细节，例如指向显示 Sqoop 查询的 Sqoop 节点或显示 Hive 查询的 Hive 节点，如图 6-5 所示。

图 6-5. 添加数据集级转换节点的详细信息

现在让我们看看如何将这个单一的 Hive 查询以图形方式表示为字段级别的谱系，使用规范化的图形表示，如图 6-6 所示。

图 6-6. 字段级技术谱系

在图 6-6 中，使用虚线蓝线表示字段级别的操作，使用实线深红线表示数据集操作。如果一个字段只是从源复制到目标，则用虚线蓝线表示从源字段到目标字段。如果涉及操作，则用蓝色椭圆表示，并使用虚线蓝线表示操作的输入和输出。集合操作的输入和输出（在红色椭圆中）通过实线红线表示在操作和特定数据集之间。单个 Hive SQL 查询表示为三个步骤或节点：

过滤节点

对Cust Hive 表应用过滤器，仅选择加利福尼亚客户。

连接节点

将第一个操作的结果与IncomebyZip Hive 表合并，根据其邮政编码为每个客户添加AverageIncome。

函数节点

提取将进入CalCustRelIncome Hive 表的字段，并通过将客户的收入除以平均收入来计算每个客户的IncomeRatio。由于计算是作为查询的一部分直接进行的，所以该函数没有名称，并由执行所需计算的代码表示。

要生成此图表，谱系系统必须能够解析和理解 Hive SQL，并将其分解为单独的操作。这是一项相当复杂的工作，特别是因为用户可能选择编写 Java MapReduce 程序或 Pig 脚本，或使用其他一些难以或无法规范化表示的选项，而不是使用 SQL 等声明性语言。

管理

信任有很强的社会层面。分析师依赖口口相传来找到可信赖的 SME。就像一些博客作者、YouTuber 和行业专家通过建立可信度和庞大的追随者群体脱颖而出一样，现代数据湖中某些用户的注释和策划可能比其他人更可信。这些受信任的用户可能有数据的组织责任，他们可能是官方的数据管理者，或者是广受认可和尊重的专家。即使在拥有成熟治理结构和官方指定数据管理者的组织中，有些数据管理者可能比其他人更具知识，有时分析师可以比官方的数据管理者更了解和掌握洞察力，尤其是关于他们创建或经常使用的数据集。为了解决专业知识的分散和非官方特性，一些企业正在转向像 TripAdvisor 和 Yelp 这样的消费者网站使用的范例，通过允许用户评价信息是否有帮助和准确来识别可信的评论者。

配置

一旦确定了正确的数据集，分析师需要将其提供供使用，或者“配置”它。配置有两个方面：获取使用数据的权限和获取访问数据的物理访问权限。

数据湖面临的一个重大挑战是决定将访问权限授予哪些分析师访问哪些数据。在某些行业中，让每个人都能访问所有数据是完全可以接受的，并解决了第一个问题。然而，大多数行业处理大量敏感数据。数据集可能包含个人可识别信息（PII）、财务信息如信用卡和账户号码，以及业务敏感信息如订单大小和折扣。

传统的访问控制方法为每个用户创建一个账户，并可能将用户添加到一个或多个组中，并为每个数据集或字段指定特定用户和组的访问权限。例如，所有美国市场分析师可能会访问美国销售数据，但不会访问欧盟销售数据。当在美国新雇佣了一个市场分析师时，他们将被添加到美国市场分析师组，并获得访问美国销售数据的权限。如果他们转到不同的团队或加入不同的项目，他们的权限和组成员资格将需要重新审查。当接收到新的数据集时，安全团队和数据管理者必须找出谁应该访问它。这种方法存在许多问题：

• 这非常耗时。大公司可能一直在雇佣人员或在项目之间调动人员。通常是一位成本高且责任重大的人需要找出应该让谁访问什么内容。

• 存在大量历史包袱，因为转移到另一个项目的人可能在一段时间内仍然对旧团队负责。分析师有时会因为访问已经与其工作无关且不应访问的数据而拥有访问权限。

• 有很多数据，有时很难正确判断谁应该访问哪些数据。

理想情况下，分析员应该能够请求访问他们需要的数据。但是，如果他们无法在没有访问权限的情况下找到数据，我们就陷入了一个进退两难的境地。

这种解决方案是一种更灵活的访问控制方法，一些企业开始采用。它们创建元数据目录，使分析员能够找到任何数据集而无需访问它。一旦确定了正确的数据集，分析员请求访问它们，数据管理员或数据所有者决定是否授予访问权限，持续多久，以及数据的哪些部分。一旦访问期限到期，可以自动撤销访问权限或请求延期。

这种方法有很多优势：

• 在有人请求此数据集之前，无需进行检测和保护数据集内的敏感数据。

• 分析员可以在数据湖中找到任何数据，包括新加入的数据集，而无需访问它。

• 数据管理者和所有者不必投入时间来确定谁应该访问哪些数据，除非真正需要进行项目。

• 访问请求可能需要理由，创建请求者和数据集的审计轨迹。

• 可以授权访问数据集的部分内容，并限定特定的时间段。

• 始终清楚哪些数据集正在使用，因此数据质量和治理工作可以集中在这些数据集上。例如，ETL 作业只能更新当前正在使用的数据集，敏感数据去识别和数据质量规则可能仅应用于这些数据集。

我们将在第八章中更详细地讨论目录，并在第九章中深入探讨访问控制和供应。

为分析准备数据

虽然一些数据可以直接使用，但更多时候需要一些准备工作。准备工作可能只是选择适当的数据子集，或者可能涉及复杂的清洗和转换过程，将数据转换为正确的形式。最常见的数据准备工具是 Microsoft Excel。不幸的是，Excel 有显著的限制，使其难以处理大数据湖文件。幸运的是，新公司如 Alteryx、Datameer、Paxata 和 Trifacta，以及更成熟的数据集成供应商如 Informatica 和 Talend，已经推出了更好的可扩展工具。甚至一些数据可视化供应商，如 Tableau 和 Qlik，也正在将常见的数据准备功能整合到其工具中。Excel 也在进化中，微软正在为在 Azure 中运行的 Excel 开发 Hadoop 接口。

由于传统的数据仓库设计用于执行相对狭窄和预定义类型的分析，它们依赖于由 IT 开发的经过充分测试和优化的 ETL 作业，用于将数据转换为单一的公共模式并加载它。任何数据质量问题都会以同样的方式为每个人解决，并且所有数据都会转换为一组公共的度量和表示。所有分析师都不得不使用这种一刀切的方法。

现代的自助服务分析，尤其是数据科学，更加灵活和探索性。分析师可以利用数据仓库中更多可用的数据，通常会寻找原始或原始数据进行处理，以适应其特定的需求和用例。

创建“合适用途”的数据对于 IT 部门来说几乎是不可能的任务。幸运的是，一组称为数据准备或数据整理工具变得流行起来，使分析师能够轻松将原始数据转换为适合分析的格式，而无需深入的技术技能。这些数据准备工具为分析师提供了类似电子表格的视觉界面。Bertrand Cariou 的以下文章描述了数据整理的不同用例，并描述了现代数据准备工具之一 Trifacta 如何提供复杂的机器学习接口，尝试基于用户的数据选择自动推荐操作。

数据湖中的数据整理

Bertrand Cariou 是 Trifacta 的高级合作伙伴营销总监。在 Informatica 以及其他一些美国和欧洲公司，Bertrand 专注于使数据可访问和可用。

“数据整理”一词通常用于描述商业专业人士（如业务分析师、数据分析师和数据科学家）在准备数据以供分析之前所做的初步准备工作。数据整理因此可以成为本书其他地方描述的“自助服务”的一部分。然而，我们也看到越来越多的数据整理由数据工程师完成，以促进他们的工作并改善与业务用户的协作。无论谁执行这项任务，数据整理都是将多样化的数据从其原始格式转换为结构化和可消费的格式，供业务智能、统计建模工具和机器学习使用，或者向业务应用提供数据。通过我的公司提供的机器学习驱动的新工具，例如Trifacta，大大简化了数据准备的工作，通过提供建议和与用户互动来加速和自动化数据整理，以满足他们特定的数据驱动需求。

将数据准备置于 Hadoop 环境中

数据准备位于数据存储和处理层（如 Hadoop、Spark 和其他数据计算引擎）以及后续过程中使用的可视化或统计应用程序之间。

如图 Figure 6-7，数据整理发生在分析工作流的各个环节中：

探索性准备

数据湖中的数据整理通常发生在区域内或在区域之间移动时。用户可以访问原始和精炼数据，将其组合和结构化，用于他们的探索工作，或者定义他们想要自动化并定期运行的新转换规则。

数据准备也可用于轻量级摄取，将外部数据源（如电子表格和关系数据）引入数据湖中已有的数据，以进行探索和清洗。

消费

在生产区域进行整理通常是将数据传递到商业洞察层。这可以通过基于 SQL 的 BI 工具完成，或者通过导出数据到文件格式（例如 CSV、JSON 或 Tableau 数据提取格式）以供包括 Tableau、SAS 或 R 在内的分析工具进一步使用。

运营化

除了数据转换的实际工作外，数据准备工具还在运营化层内使用，团队可以定期安排数据准备作业并控制其执行。

图 6-7. Trifacta 生态系统

解决方案内的所有数据访问、转换和交互都已记录，并提供给数据治理工具，因此管理员可以了解数据的来源。

数据准备常见用例

数据准备工具的使用可分类为三种主要场景（具有变体），可能通过由业务团队或 IT 团队组织的自动化受益。以下是数据整理的三个常见用例及相应的 Trifacta 客户示例摘要。

应用场景：自助式分析或业务应用的自动化

对于这类倡议，业务团队管理分析流程，从初始数据摄取到最终数据消耗，包括数据准备。通常，他们的最终目标是为了合规目的或聚合不同数据而创建“主报告”。在这些倡议中，IT 组织负责设置数据湖和数据摄取，以便业务团队可以处理自己的数据需求，并安排数据准备任务，无需 IT 参与。

客户示例

PepsiCo 需要优化其零售销售预测，这涉及将零售商销售点（POS）数据与内部交易信息相结合。对于 PepsiCo 来说，主要挑战来自于每个零售商提供的不同格式，通过自动生成的报告或电子邮件附件提供。通过 Trifacta，业务分析团队承担了将零售商数据引入 PepsiCo 数据湖的责任，可以探索和定义数据转换方式，并可以根据需求执行作业或通过常规调度以向下游应用程序或流程提供可消费的结果。Trifacta 从用户的互动中学习，提供即时反馈，以更好地指导他们在规模上构建、丰富和验证数据。

用例：IT 运营准备

在这种情况下，数据专家——通常是数据分析师或数据工程师——自行设计准备工作，然后测试、验证并按规模运行规则，以产生期望的结果。在最终用户创建操作工作流后，IT 团队通常会将其集成到企业工作负载中。

客户案例

一家大型欧洲银行需要从其网站提取聊天日志以改进客户服务，以及分析产品和服务需求。该银行使用 Trifacta 将这些复杂的格式转换为更广泛的客户 360 计划中的离散属性，该计划还包含其他数据渠道。在这种情况下，团队提供了他们创建的数据整理规则，以便 IT 能够一致地组合各种数据流。

用例：探索性分析和机器学习

正如其名称所示，探索性分析利用数据探索业务的各个方面，并使用临时数据准备工具探索数据，调查使用案例，找到相关的第三方数据，验证假设，在数据中发现模式，或生成数据集供数据科学家建模。

客户案例

一家成熟的营销分析提供商聚合并检验客户数据，为其客户提供分析输出，从而帮助客户衡量、预测和优化营销工作的影响。每个客户具有不同的数据来源和格式。Trifacta 帮助加快客户数据的发现和转换过程，以创建结构化和干净的数据集。例如，Trifacta 使用机器学习自动发现数据，在熟悉的网格界面中结构化数据，识别可能无效的数据，并建议最佳的清洁和转换数据的方法。

分析和可视化

现在有很多出色的自助数据可视化和分析工具。Tableau 和 Qlik 已经存在多年，还有许多较小的供应商，如 Arcadia Data 和 AtScale，专门为大数据环境提供高质量、易于使用的功能。Donald Farmer 的以下文章讨论了商业智能中的自助服务趋势。

自助式商业智能的新世界

Donald Farmer 是 Qlik 公司创新与设计副总裁。他在数据战略方面的工作已有近 30 年，国际上发表了大量关于高级分析和创新战略的著作和演讲。

在过去几年里，业务用户与 IT 的关系发生了显著变化。这种变化的起因与 iPhone、iPad 以及被称为 Bring Your Own Device（自带设备）的现象有关。BYOD，通常缩写为这样，是对用户现在比 IT 能提供的更好的技术和更快的升级有了战略性响应或战术性调整的认识。这一新现实在数据分析领域也有所体现。与设备自带的现象有明显的类似之处，业务分析师已经接受了自助式商业智能。在自助服务中，用户可以构建自己的解决方案，甚至可以选择自己的工具，“无论是否得到 IT 的许可”，正如分析公司 Gartner 所指出的。

过去，IT 部门必须为企业提供报告基础设施、仪表板和分析。只有 IT 团队能够部署所需的昂贵存储和计算能力。只有 IT 了解从数据中提取和 consolidaing 数据或构建分析模型涉及的技术问题。非常重要的是，只有 IT 能够保护数据和相关分析，确保正确的人拥有正确的洞察力。商业智能的工作流程遵循经典的生命周期模型：IT 收集需求，构建解决方案，将其部署到生产环境，并开始下一轮需求收集。

事实上，这种由 IT 主导的模型始终存在着一个“黑暗面”。随着开发人员为了越来越敏捷的业务而奋力推进生命周期，财务和营销部门的分析师简单地使用 Excel 作为一个足够好的工具。他们经常从报告中导出数据进行进一步分析，有时他们也能访问源数据。Excel 是有效的，但不强大。它的安全性缺失，再加上业务用户的习惯，导致组织内部产生了较差的分析甚至是机密数据。

自助式 BI 工具不仅将这种黑暗面带入了光明中，而且将其带入了企业分析的主流。从 2000 年代中期开始，随着 64 位计算成为常态，诸如 QlikView、Tableau 和 Microsoft 的 PowerPivot 等应用程序为任何业务用户提供了强大的分析能力。这些工具将 ETL 生命周期和数据模型构建集成到一个简单的环境中。它们使用优雅的可视化方式使用户能够轻松有效地发现模式并传达见解。通过使用内存存储和压缩，相同的工具可以将数据容量和计算能力带到桌面，这些功能曾经只能在精心管理的服务器房间中获得。正如俗话所说，拥有这种力量也带来了巨大的责任，但设计良好的自助式应用程序也可以帮助解决这个问题。

这种业务用户权力的转变带来了许多变化，特别是在分析工作流程和 IT 角色方面。

新的分析工作流程

如前所述，用于分析应用程序和报告的工作流程曾经是经典应用生命周期的一种变体：需求、设计、部署和新需求。然而，自助服务使得业务分析师了解自己的需求并开发自己的解决方案，因此这个过程可能显得有些零散。需求随时可能发生变化。例如，前端设计的微调（例如向图表添加新元素）可能会改变数据提取过程。分析师可能会部署并分享一个半成品解决方案以便推动进展。

与其将这种敏捷、临时的过程视为生命周期，我认为将其描绘为一个供应链更为有用，其中数据作为原材料流经多个流程，每个步骤都增加了价值。供应链的巨大优势在于，有时可以为了效率而合并步骤。例如，将食物从农场送到餐桌时，批发商不仅可以转售，还可以洗涤和部分准备一些蔬菜。同样，供应链的每个步骤可以简单地是操作性的（从农场到市场的运输），也可以在进行时增加价值，例如按大小或质量等级进行分类。

在业务分析供应链中，数据作为原材料，业务用户可以从任何可用的地方获取数据。自助服务工具通常提供简单的向导、脚本或视觉环境，用于查看、连接、 consoli data 或清理数据。通常这个阶段被称为数据混合——或者更有诗意地称为数据梳理。然而，与传统的 ETL 过程不同，传统的 ETL 过程在任何分析工作之前从源中加载数据仓库模型，混合和梳理可以在分析过程之前、过程中或（使用分析应用程序作为源）甚至之后发生。

对于使用自助工具的业务分析师来说，混合数据是一种分析过程。当他们在可视化中看到初步结果时，他们会随着工作对数据有更好的理解。然后，他们修改他们的脚本或数据向导，以便以不同的方式查看数据，或者启用更好的可视化。这里有一个重要的区别。在传统的数据仓库生命周期中，ETL 填充了一个模型，然后驱动分析。该模型可以是星型模式或需要专业设计和工程技能的复杂 OLAP 模型。在自助供应链中，模型仍然存在，但用户可能甚至没有意识到它。通常情况下，业务分析师不是一个有意识的建模者。

当业务分析师与数据湖一起工作时，这种新方法的灵活性尤为重要。在传统模型中，通过复杂的关系源和昂贵的存储，数据经常通过非常复杂的过程进行转换，以使其以对存储和查询都有效的形式呈现。例如，ETL 和 OLAP 需要相当的技能。

另一方面，数据湖可以轻松存储大量数据。有了按需模式的灵活性，就没有必要在单个数据仓库中建模所有情况。只要能向业务分析师呈现有效的语义（他们永远不应被要求编写 MapReduce！）和合理的性能，他们就可以使用数据湖和自助工具。

从“门卫”到“店主”

在这一点上，我们应该考虑 IT 的角色。重要的是要说，IT 可能仍然会提供至关重要的情报。企业数据仓库仍将在我们身边，用于年度财务报告、税务分析和人力资源。IT 在未来几年仍然需要他们的 OLAP 和 ETL 技能。他们也需要 MapReduce 技能！

当然，IT 在分析供应链中扮演着重要角色。至少，IT 必须通过强大的网络、存储和数据源来“保持灯火通明”，使这一过程成为可能。然而，它的角色远不止如此。

正如我们所见，过去，IT 团队提供了整个分析生命周期，因为他们是唯一能够提供的人。此外，他们保证系统安全，并根据需要和许可提供“数据访问”。IT 部门非常认真地承担起这个“门卫”的角色，他们可能会这样做，以至于商业分析师经常对他们对重要数据的有限访问感到沮丧。

对 IT 门卫的这种挫折导致了专业紧张，并频繁地导致正是控制措施本意避免的未管理数据共享的“黑暗面”。电子表格失控了，因为这是分析师留给他们的唯一工具，而 IT 无法封锁它们。

随着自助服务的到来，我们需要一种新的方法。IT 团队必须从“门卫”转变为“店主”。

一个守门人关心的是如何阻止错误的人进入。而一个店主则邀请合适的人进入，准备、展示和供应商店的商品，鼓励其适当的使用。在 IT 术语中，数据供应团队可以构建供业务用户自服务的数据源和模型。与其打开大门让用户访问源系统，一个有效的团队可以为用户提供经过清理、合并甚至匿名化处理的数据，以便进行有效的分析和良好的治理。IT 不需要为特定用例准备每个数据源：业务分析师使用他们的工具在数据供应链上为自己提供这些解决方案。

自助服务的治理

在这种供应链模型中，IT 团队充当店主的角色，他们在安全和数据治理方面仍然发挥着重要作用。他们可以采取的最重要措施之一是为用户提供设计良好的自助服务工具。

一个设计良好、企业级的自助应用不仅为业务用户提供强大而简单的工具，还必须具备强大的服务器架构，可以部署在云端或本地，为 IT 部门提供必要的洞察力和监督权，以管理系统的使用。

IT 的监督工作包括管理部署、用户权限、服务器性能和扩展能力。一个设计良好的应用程序所提供的洞察力包括了解分析师使用的数据源、他们与谁分享他们的应用程序和可视化内容，以及数据的准备和刷新方式。

请记住，IT 仍然提供关键的分析服务，比如财务报告。他们仍然是内部核心的守门人。但是，商业分析的许多工作可以通过更轻松的方式处理——仍然安全、受控——采用新的供应方法，不仅更具敏捷性，而且更易于与业务其他部门合作。

结论

如果利用数据做出更好的决策是现代企业成功的关键，那么依赖于 IT 构建的僵化分析和数据仓库的旧实践是跟不上的。利用数据做出更好的决策的唯一实际方法是使分析师能够自行进行分析，而无需在每个项目中都涉及 IT（从而使 IT 成为瓶颈并减慢事务进展）。正如您在本章中看到的那样，从数据可视化工具到数据准备工具和数据目录等新一代分析和数据基础设施工具已经出现，使分析师能够在不涉及 IT 的情况下处理数据。可以将提供搜索、溯源和信任的方法构建到数据湖中，供所有用户使用。

第七章：设计数据湖

有许多方法可以组织数据湖中的数据。在本章中，我们将从如何将数据湖组织为区域开始。然后，我们将比较和对比本地和云数据湖。最后，我们将讨论虚拟数据湖，它在提供与物理数据湖等效功能的同时，最小化资源使用和维护数据湖的开销。

组织数据湖

一旦建立了数据湖，分析师需要一种方法来查找和理解其包含的数据。考虑到大多数企业中数据种类的广泛多样性（我与一家大型零售商交谈时得知，其数据湖中有超过 30,000 个数据源，并且每个源可能提供数百甚至数千个表），这是一项艰巨的任务。即使分析师找到了正确的数据集，他们也需要知道是否可以信任数据。最后，为了使用户能够自由地在湖中漫游，必须识别和保护敏感数据，以免意外泄露。所有这些任务都属于数据治理的范畴。

在数据仓库化的旧时代，数据治理是由大型数据监护人、数据架构师和数据工程师团队实施的。变更必须经过仔细审查和批准。数据质量、数据访问、敏感数据管理以及数据治理的其他方面都经过深思熟虑和管理。但在自助服务时代，这种方法无法扩展。事实上，数据科学的探索性和敏捷性与传统数据治理的自上而下、谨慎的风格存在冲突。

针对数据使用速度的加快，企业已经开始应用双模数据治理的概念，由Gartner定义如下：“双模是管理两种分离但一致的工作风格的实践：一种专注于可预测性，另一种专注于探索。”为了支持这种双模式方法，数据湖通常被划分为多个区域，具有不同程度的治理。在本节中，我们将介绍将数据湖组织为区域的最佳实践，帮助用户了解数据的治理级别，并保护敏感数据。

图 7-1 反映了一个非常普遍的数据湖集群架构。来自外部源的数据首先加载到原始或着陆区域，其中以反映其来源（例如时间和来源）的文件夹进行归档，而不进行进一步处理。然后，根据需要，这些数据被复制到金区域，进行清洗、筛选和聚合；工作区域，用户运行其项目的地方；或敏感区域，保护应保护的数据保存在加密卷中。

图 7-1。数据湖划分为工作空间或区域的示例

不同的数据湖用户通常使用专用区域，如 图 7-2 所示。

图 7-2. 不同的用户使用不同的区域

着陆区或原始区

着陆区，有时也称为 原始 或 暂存 区，用于存放原始摄入的数据。 IT 团队通常创建命名约定，以识别数据的来源。例如，所有摄入的原始数据通常保存在单个文件夹中（例如，/Landing）。在该文件夹中，通常会按来源创建子文件夹（例如，/Landing/EDW 或 /Landing/Twitter），在这些子文件夹中，还会按表或其他分组创建另一个文件夹（例如，/Landing/EDW/Customer_dimension 或 /Landing/Twitter/Mybrand1）。

如果表周期性反映，可以为每次加载新数据创建一个分区（例如，/Landing/EDW/Customer_dimension/20190101.csv 或 /Landing/Twitter/Mybrand1/20190101.json 表示 2019 年 1 月 1 日加载的数据）。为了避免非常大的文件夹，可以创建更复杂的文件夹树，例如，每年和每月创建一个文件夹，并将该月的分区作为文件（例如，/Landing/EDW/Customer_dimension/2019/01/20190101.csv 或 /Landing/Twitter/Mybrand1/2019/01/20190101.json）。 图 7-3 展示了典型的文件夹层次结构。

图 7-3. 将原始或着陆数据摄入到文件夹和文件中

通常，只有高度技术的开发人员、数据工程师和数据科学家可以访问着陆区。一般来说，着陆区的用户必须有充分的理由进行自己的数据处理和处理。

分析师通常需要更干净的数据，并使用来自下一个 金区 描述的数据。

金区

黄金区域经常反映着着陆区域，但包含清洁、丰富和其他处理过的原始数据的版本。有时这个区域也被称为prod，表示其中的数据已经可以投入生产，或者称为cleansed，表示数据已经通过数据质量工具和/或策划流程进行了清理，如第二章所述。为生产使用准备数据通常类似于创建数据仓库的 ETL 作业——数据被和谐化并标准化为符合维度或主列表，例如主客户或产品列表。操作可能涉及将名字的姓、名和中间名转换为一个字段；将千克转换为磅；将本地代码转换为通用代码；联接和聚合数据集；或者进行更复杂的清洁工作，如地址验证、从其他来源填补缺失信息、解决从不同数据源加载的冲突信息、检测和替换非法值等。这通常使用自定义脚本或专业的数据准备、数据质量或 ETL 工具完成。事务数据也经常进行清洁和汇总；例如，个别交易可以聚合为每日总数。然而，与数据仓库不同的是，可能存在许多相同数据的版本，供不同的分析模型使用，需要不同的处理方法。像着陆区域一样，黄金区域通常采用每个源的文件夹系统（例如/Gold/EDW或/Gold/Twitter），这些顶级文件夹包含每个表格或其他分组的文件夹（例如/Gold/EDW/Customer_dimension或/Gold/Twitter/Mybrand1）。

如果有汇总或派生文件，则这些文件也会放在子文件夹中（例如/Gold/EDW/Daily_Sales_By_Customer或/Gold/Twitter/BrandTwitterSummary）。

然后，这些文件夹可能会按日期进一步细分，类似于着陆区域。图 7-4 展示了创建黄金区域库的一些处理过程。

图 7-4. 将黄金或 prod 数据组织成文件夹和文件

这通常是最受欢迎的区域。大多数非开发人员局限于此区域。开发人员和数据科学家也更喜欢使用清洁数据，以避免额外工作，除非有强制性理由要求他们自行清洁。

为了使黄金区域更易访问，IT 工作人员通常使用 Hive、Impala、Drill 或其他十几种系统为黄金区域中的每个文件创建 SQL 视图。类似 SQL 的访问使得黄金区域成为大多数报告和 BI 分析的自然起点，因为即使不熟悉 SQL 的分析师也通常可以使用带有 Hive 或其他 SQL 接口的标准 BI 工具。

黄金区通常由 IT 部门而不是用户自己管理，并且文档化得最好，可以通过目录结构和命名约定或通过 HCatalog（围绕 Hive Metastore 开发的数据字典，正在越来越多地被其他项目使用）来实现。

数据通常直接从黄金区读取，但如果需要进行更改，则会复制到工作区以进行修改。如果生成的数据集需要与更广泛的受众共享或用于产品化的持续运营，则会将其复制回黄金区，并开发生产强度流程以保持其更新。

工作区

大部分分析工作发生在工作区，也称为dev或projects区。该区域通常结构化以反映企业的组织结构。通常由开发人员、数据科学家和数据工程师管理，尽管分析师经常使用它来为其项目执行自服务数据准备。

工作区通常按项目和用户文件夹进行组织，如下所示：

• 顶层文件夹通常每个项目有一个文件夹（例如，/Projects/Customer_Churn），然后包含子文件夹以反映项目的详细信息。

• 用户文件夹通常位于某个公共目录中，每个用户有一个文件夹（例如，/Users/fjones112），为每个用户提供私人空间。

这些个人用户和项目文件夹包含工作的中间和最终结果。这通常是数据湖中文档化最少的部分。不幸的是，这也经常是最大的部分，因为数据科学项目具有探索性质，并经常需要大量的实验。典型的数据科学项目可能在找到良好模型或放弃方法之前创建数百个实验文件。

敏感区

有时会创建敏感区，用于保存包含特别重要需要保护免受未经授权查看者查看的数据文件，无论是因为法规要求还是业务需求。通常，只有数据管理员和其他授权人员可以访问敏感区的数据。例如，HR 人员可能访问员工数据，财务员工可能访问财务数据等。通常通过基于标签的策略和 Active Directory 组合完成此操作（我们将在接下来的两章中更详细地讨论访问管理）。

敏感区可以包含明确加密的数据或利用透明加密，详细描述在第九章中。关于组织敏感区的最佳实践有几种方法：

• 在敏感区域的每个敏感文件都有加密副本，黄金区域有带有删除或加密的敏感字段的明文副本。尽管删除数据可能会影响到连接不同数据集的能力——例如，如果Tax_ID是员工和受扶养人之间的连接键，仅仅删除它将使这两个数据集无法连接——但存在不同的加密技术可以保护数据同时保持可连接性。请参阅第九章获取更多信息。

• 仅在明确需要的情况下临时提供对加密文件的访问权限。

• 如果需要对分析使用敏感数据，则可以应用下面讨论的去识别过程对数据进行匿名化。

去识别

去识别是用类似虚构数据替换实际敏感数据的过程，以保持原始数据的属性。例如，可以将女性西班牙裔的名字替换为不同的女性西班牙裔名字，以保护个体的身份，但仍允许数据科学家从名称中推断缺失的性别和族裔信息如果有必要的话。

类似地，如果需要进行地理分析，则地址可以被替换为实际地址周围一定距离内的随机有效地址。有时会变得复杂，因为某些地区人口密集，因此可以通过在实际地址周围约 10 英里内使用任何地址来实现匿名化，而其他地区人口稀少，10 英里半径内可能只有少数人居住。为了解决这个问题，引入了“队列”概念，通过地理接近或地理类型（取决于正在进行的分析类型——例如，农田 vs. 郊区 vs. 国家公园），在队列所涵盖的整个区域内随机分配地址。

数据去识别的一个困难部分是保持一致性。通常需要用相同的值替换所有文件中的同一值，以便在处理的一部分中可以进行连接（例如，可以识别多个文件中的同一客户）。这增加了复杂性，因为系统必须维护真实值到随机生成值的映射。数据去识别也很脆弱，因为一个可能被身份解析系统轻松处理的单字母拼写错误可能会导致去识别系统生成完全不同的两个值。最后，它也很脆弱，因为如果入侵者可以访问去识别软件，他们可以通过它运行一系列常见姓名，得到所有文件的值映射表。

另一个考虑因素是对于某些类型的文件来说，识别敏感数据可能非常困难。例如，电子健康记录（EHR）是一个可能包含多达 60,000 个元素的 XML 文件。查找潜在的敏感元素并重新生成文件以屏蔽或去识别它们是非常困难的。在这种情况下，公司通常发现只需在敏感区域保持加密值更容易。

多个数据湖

企业建设数据湖有多种原因。一些起初是由业务部门或项目团队创建的单项目数据小池，逐渐发展成为数据湖。一些开始作为 IT 的 ETL 卸载项目，并在途中吸引了额外的用户和分析用例。另一些则由 IT 和分析团队共同设计，从一开始就作为集中式数据湖。还有一些是由业务团队在云端创建的影子 IT，他们不想等待正式的 IT 团队。

不管它们的起源如何，大多数企业最终都会拥有多个数据湖。因此问题变成了，应该将这些合并为一个，还是保持分开？与大多数事物一样，这两种方法都有利弊。

保持数据湖分开的优势

分开数据湖的原因是历史和组织上的，而不是技术上的。典型的原因包括：

法规限制

在受管制的行业和个人数据方面，法规限制通常禁止来自不同来源或地理位置的数据合并或混合。例如，欧盟有非常严格的数据隐私指导方针，每个国家的实施方式都有所不同。医疗机构通常也有非常严格的数据共享指导方针。

组织障碍

有时在数据共享方面存在组织障碍，主要围绕预算和控制。在战斗激烈的业务部门之间进行共同数据湖的融资，并决定共同的技术和标准可能是一个无法逾越的挑战，因为他们的目标和需求差异很大。

可预测性

将用于高价值生产负载的数据湖与用于诸如数据科学实验等临时探索用途的数据湖分开可以帮助确保前者的性能和响应时间可预测。

合并数据湖的优势

如果您不受前一节提到的法规或业务要求的限制，应该尝试将您的组织限制在一个单一的大型数据湖中。这样做的几个原因是：

优化资源使用

如果不是两个拥有 100 个节点的数据湖，而是创建一个拥有 200 个节点的数据湖，你可能会得到更好的响应时间。例如，如果原始数据湖每个都运行了一个需要在 100 个节点上花费 10 分钟的作业，理论上你可能可以在 200 个节点上每个作业运行 5 分钟。实际上，集群通常会使用节点子集执行多个作业，因此对于高度利用的集群，平均性能可能会保持差不多不变，因为现在将有两倍多的作业竞争两倍多的节点。然而，你将获得能够将所有 200 个节点投入到关键和时间敏感作业中的能力。如果不同的湖泊具有不同的、不重叠的使用模式（例如，一个在美国工作时间最繁忙，而另一个在印度工作时间繁忙），或者使用是零散的，那么通过合并这两个湖泊，你可能会获得相当多的性能优势。

行政和运营成本

当一个湖泊增长两倍时，通常不需要一个两倍大的团队来管理它。当然，同一个团队可以管理多个湖泊，但如果湖泊存在于组织和控制问题的情况下，每个组织往往会为其自己的团队提供员工，以便控制其自身的命运。这种重复会增加成本。

减少数据冗余

由于这两个湖泊都属于同一企业，很可能两个湖泊中包含大量冗余数据。通过合并湖泊，可以消除这种情况并减少存储的数据量。数据冗余也意味着摄取的冗余，即相同的数据从同一源头提取和摄入多次，因此通过整合，可以减轻源头和网络的负载。

重复使用

合并湖泊将使企业更容易重用一个项目完成的工作于其他项目中。这包括脚本、代码、模型、数据集、分析结果，以及任何可以在数据湖中生成的内容。

企业项目

一些团队在企业范围内工作，可能需要来自不同组织的数据。这些项目将极大地受益于拥有一个单一的集中式数据湖，而不是需要从多个湖泊合并数据。

云数据湖

在过去的十年里，云计算一直在不可阻挡地向前推进。许多新应用现在采用托管软件即服务（SaaS）模型交付。像亚马逊、微软和谷歌这样的顶级云供应商正以令人难以置信的速度增长（亚马逊现在从其云服务获得的收入比零售销售更多），而其他供应商也在积极尝试进入这一领域。在云计算周围所有这些激动人心的事情中，自然会问是否它也是数据湖的一个好选择。实际上，它是一个很好的选择。

基于云的数据湖提供了许多优势。其中之一是有人负责设置和维护基础设施，因此您不必为企业雇佣专门的专家。计算基础设施由他人管理并保持更新。尽管支持水平和成本各不相同，您可以查看选项并根据您和您的 IT 团队需要的帮助程度做出选择——如果发现选择的计划不完全适合，可以在不雇佣或解雇任何人的情况下进行更改。

云计算的最重要优势之一是根据需求提供新资源，包括计算和存储资源——您可以在需要时创建和使用所需的计算能力。这被称为弹性计算。此外，云提供商还提供不同价格和性能特征的各种存储类型，并根据需要无缝地在不同存储类别之间移动数据。为了帮助您理解这些技术对数据湖的优势，让我们将本地数据湖与基于云的数据湖进行比较。

在本地数据湖中，存储和计算能力均由节点数量固定并受其支配，如图 7-5 所示。

图 7-5. 本地固定大小的 Hadoop 集群

虽然有灵活的解耦存储和计算资源的方式，但是在可以利用的计算能力上有硬性边界，并且存储数据的成本可能很高，尤其是如果数据被复制一两次用于容错。

让我们将其与今天最流行的云平台之一——亚马逊网络服务(Amazon Web Services, AWS)构建的数据湖进行比较。在其众多服务中，亚马逊提供了简单存储服务(Simple Storage Service, S3)的可扩展对象存储、带有弹性计算云(Elastic Compute Cloud, EC2)的可扩展计算资源以及能够在分配的资源上执行作业的弹性 MapReduce(EMR)（见图 7-6）。

图 7-6. 亚马逊弹性云数据湖的提供

与本地数据湖不同，基于云的数据湖提供了几乎无限且非常便宜的 S3 存储。考虑到您正在保存可能暂时不会使用或可能永远不会使用的数据，存储成本非常重要。此外，计算资源不受集群节点数量的限制。

使用 EC2，您可以启动任意规模的集群来运行您的作业，并仅按实际使用时间付费。例如，假设您建立了一个 100 节点的本地集群来运行某个作业大约 2 小时。如果这个作业每天运行一次，而集群的其余负载较小，这些节点将会闲置长达每天 22 小时。使用 EC2，您可以动态地启动一个 100 节点的集群，运行 2 小时，然后关闭它，这样您只需支付运行时长的费用。

然而——更令人兴奋的是——以相同的价格，您还可以启动一个 1,000 节点的集群，并仅用 12 分钟完成这个作业（假设它按比例扩展）。这就是弹性计算的美妙之处，所有主要云供应商都支持这一功能。您可以根据需要创建和支付所需的计算资源，因此可以动态创建巨型集群来执行最具挑战性的作业，而无需永久支付这些资源。

尽管云数据湖具有诸多优势，但也存在云数据湖可能不是最佳解决方案的情况：

• 不是所有数据都可以出于法规原因放在云中。

• 将数据上传到基于云的数据湖可能是一个挑战。公司通常会将磁盘或磁带发送给其公共云供应商，以本地加载其初始数据，并随后使用网络进行增量上传。

• 云数据湖容易受到网络中断和互联网供应商故障的影响。因此，在需要百分之百可用性的情况下，如医院的医疗设备或工厂的工业控制，云数据湖可能过于冒险。诚然，大多数用于分析的历史数据可能不需要如此高的服务级别协议，但某些数据湖支持实时数据流，并可用于实时和历史分析。

• 对于需要大量数据和持续计算资源的项目来说，成本可能是禁忌的。云成本对于需要某些计算节点数量的短暂使用情况来说更为有利，可以在不需要时缩减规模。虽然大多数数据湖使用案例只需要这种弹性支持，但如果您的计算需求更为持续，云可能不是最佳选择。

虚拟数据湖

一个越来越流行的方法是创建一个虚拟数据湖。换句话说，不要维护多个数据湖或将它们合并为一个集中的数据湖，为什么不将它们呈现给用户作为一个单一的数据湖，同时分别管理其架构细节呢？实现这一目标有两种主要方式：使用数据联邦和使用企业目录。

数据联邦

数据联合至少存在了 20 年。IBM 的 DataJoiner 产品于 1990 年代初引入，创建了一个“虚拟”数据库，其表实际上是多个数据库中物理表的视图。DataJoiner 的用户会针对这些虚拟表发出 SQL 查询，DataJoiner 将其翻译为针对不同数据库执行的查询，并将结果组合并呈现给用户，正如 图 7-7 所示。¹

图 7-7. 虚拟数据库示例

DataJoiner 最终演变为 IBM InfoSphere Federation Server，并受到 Denodo、Tibco Composite、Informatica 等产品的竞争。这些产品的现代版本支持 RESTful APIs，并且可以与应用程序、文件系统以及数据库进行交互。然而，这些产品的核心都是设计为创建一个虚拟数据库，该数据库在底层可以从不同的系统中提取数据，并使其看起来像是单个表格。

将这项技术应用于数据湖面临着几个重大挑战。最大的挑战是必须手动配置每个虚拟表，并将其映射到物理数据集，无论是文件还是表格。在通过无摩擦摄入加载数百万文件的数据湖中，这简直是不切实际的。然后是传统的分布式连接问题：从不同物理系统组合或连接大数据集需要非常复杂的查询优化以及大量的内存和计算能力。最后是模式维护问题：当模式发生变化时，虚拟表也必须进行更新。由于模式仅在读取数据时应用（所谓的“模式读取”），用户可能不知道模式已经更改，直到他们的查询失败。即使如此，问题可能并不明确，可能是由模式更改、数据问题、人为错误或这些因素的任何组合引起的。

大数据虚拟化

正如数据湖作为应对数据量和数据种类急剧增长的一种方式出现一样，大数据虚拟化将大数据的模式读取、模块化和未来证明原则应用到数据虚拟化的新方法中，以应对企业中庞大的数据量和多样化数据的挑战。这种新方法的核心是一个虚拟文件系统，将物理数据源表示为虚拟文件夹，将物理数据集表示为虚拟数据集。这种方法与数据湖中的分期区域的组织方式类似，如本章前面描述的那样。这种虚拟化允许数据保留在其原始数据源中，同时向其他业务用户公开。

由于这样的虚拟文件系统可能非常庞大，并且潜在地包含数百万个数据集，因此需要一个搜索机制来查找和导航这些数据集。这个角色通常由数据目录扮演，它展示了企业中包括数据湖在内的所有数据。通过这种方法，目录中只包含元数据（描述数据的信息），因此用户可以快速找到他们需要的数据集。一旦找到数据集，可以通过将其复制到用户的项目区域或授予用户在原地访问权限的方式进行供应。Figure 7-8 展示了这一过程。

图 7-8. 虚拟数据湖

因为 Figure 7-8 中的两个表都已复制到同一物理系统中，因此连接是本地的，更容易实现且执行速度更快。供应可以涉及一个批准流程，用户请求在一段时间内访问并指定业务理由。请求经过数据所有者审查和批准，然后数据被复制过去。最后，数据的副本由 ETL 工具、客户脚本或连接到关系数据库的开源工具（如 Sqoop）保持更新，执行用户指定的 SQL 查询，并创建包含查询结果的 HDFS 文件。

因为目录是在数据湖中查找和提供数据的主要接口，它为构建虚拟数据湖提供了非常优雅的解决方案。当用户查找数据集时，它们实际上并不关心数据的物理位置——它看起来都一样，并且可以以完全相同的方式找到。智能供应系统可以提供支持，所以如果用户想要在工具中使用数据集，它可以在原地提供（即直接在工具中打开），而如果需要将其与其他数据集连接或修改，则可以透明地复制到物理数据湖中并在那里访问。

消除冗余

一个物理数据湖的两个挑战是完整性和冗余。如图 7-9 所示，只有当企业中的所有数据加载到数据湖中时，才能保证完整性。然而，这导致了大量的冗余，因为所有数据现在至少存储在两个地方。虽然有人可能会认为传统上数据仓库包含与操作系统相同的数据，但那种情况有不同的要求，因为数据通常在加载到数据仓库之前会进行转换。它会改变以符合一个通用模式，去正规化，并与其他系统的数据合并。因此，虽然数据更多或更少是相同的，但它们结构非常不同，用途也不同。另一方面，在数据湖中，如果我们实现无摩擦的摄入，登陆区域的数据通常是源数据的精确副本，完全是冗余的。我们最终会保留多个完全相同的数据副本，不管有没有人在使用它，并继续支付维护这些副本的代价。

图 7-9. 数据湖带来的挑战

虚拟数据湖有助于缓解这个问题，因为只有在需要为特定项目时才将数据带入数据湖中。换句话说，数据湖中只有一份数据副本（在原始源中），除非有人需要在数据湖中处理它。一旦项目结束，并且不再需要这些数据，可以安全地将其删除以节省存储空间，或者至少停止更新副本，直到有人需要，并且再次更新它（图 7-10）。采用这种模型，大部分经常使用的数据将会在数据湖中并得到积极维护，只有很少使用或从未使用过的数据才不会在数据湖中。第一次加载非常大的文件或在长时间不使用后更新它们可能会有一定的延迟，但这种折衷是不必支付计算和存储资源来处理所有不使用的数据。

图 7-10. 虚拟湖对一致性和冗余的影响

不幸的是，冗余并没有止步于数据湖。过去 15 年来，数据汇集点和其他项目特定的数据库如雨后春笋般涌现。一个典型的数据相关项目从为数据库服务器提供服务开始，从其他系统加载数据，稍作修改，然后通过加载最新数据保持数据更新。一些企业拥有成千上万甚至数百万这样的数据库。例如，我曾与一家有 5000 名员工和 13000 个数据库的小银行合作过。所有这些数据库都需要花费，包括硬件和软件成本、管理成本、备份成本等等。更糟糕的是，随着时间的推移，这些最初相同的数据库的部分内容不可避免地会有所分歧，无论是由于人为错误、ETL 逻辑差异、作业或系统故障还是其他因素。因此，许多公司花费时间争论为什么财务、销售和营销对同一关键指标有不同的数字，以及应该使用或信任谁的数字（剧透警告——通常是财务赢得最后胜利）。

许多企业已经着手进行合理化的旅程，试图合并几乎相同的数据库，淘汰不必要的数据库，并使分歧的数据库趋同；企业目录是这一旅程的第一步。通过记录数据存放在何处、来源及使用者，目录可以帮助识别冗余和未使用的数据。

一些可以通过目录识别的常见模式包括：

• 两个几乎相同的数据汇集点，具有少量附加测量和属性。可以通过将两者的唯一测量和属性添加到组合数据汇集点中，将它们合并为一个单一的数据汇集点，从而减少存储和管理成本。此外，现在每个数据汇集点的用户都可以访问以前在另一个数据汇集点中的所有字段。

• 曾用于报告的数据库，但目前仅作为另一个数据库的暂存数据库。它可以完全被淘汰，并且可以直接从上游系统填充它所填充的数据库。

• 完全未使用的数据库正在生成没有人使用的报告和仪表板。这可以简单地被淘汰。

结论

虽然数据湖架构有许多选择，但许多企业开始意识到云的弹性和虚拟数据湖的效率的吸引力。接下来，我们将探讨数据目录如何帮助企业创建数据湖，并将其扩展为虚拟数据湖。

¹ 更多详细信息可在 Piyush Gupta 和 E. T. Lin 撰写的论文"DataJoiner: A Practical Approach to Multi-database Access"中找到。

第八章：数据湖的分类

数据湖往往具有一些特征，使得它们难以，如果不是不可能的话，进行导航。它们包含大量的数据集。字段名称通常是神秘的，并且某些类型的数据集（例如从在线评论收集的分隔文件和非结构化数据）可能根本没有标题行。即使是标记良好的数据集，其名称也可能不一致，并且具有不同的命名约定。几乎不可能猜测不同文件中可能称为何种属性的名称，因此也就不可能找到这些属性的所有实例。

因此，数据需要在湖中摄入或创建新数据集时进行记录，或者经过广泛的手动检查，这两种选择对于大数据系统中典型的规模和多样性都不可扩展或可管理。

数据目录通过使用一致的业务术语对字段和数据集进行标记，并提供一种类似购物的界面来解决这个问题，允许用户通过描述他们所寻找的内容（使用他们习惯的业务术语）来查找数据集，并通过使用业务术语的标签和描述来理解这些数据集中的数据。在本章中，我们将探讨数据目录的许多用途，并快速查看今天市场上的一些数据目录产品。

数据组织

虽然在 第七章 中描述的目录结构和命名约定可以帮助分析师导航大数据集群，但这还不够。以下是它们的不足之处：

• 没有搜索功能。分析师必须浏览到正确的目录，这在他们知道自己想要什么时候是有效的，但当他们仅仅在探索可能的成千上万的来源/文件夹时，这是不切实际的。

• Hadoop 实用工具像 Hue 允许用户查看文件的初始小片段，但这可能不足以理解大文件内部的内容。为了决定一个文件是否适合他们的项目，分析师可能需要更清楚地了解其包含的内容。例如，是否有纽约的数据？有多少条推文？订单金额是多少？如果分析师正在寻找诸如年龄之类的客户人口统计数据，仅仅预览文件的几行并看到一些年龄数据，并不能告诉他们这些数据是否适用于足够数量的客户。

• 分析师还需要能够确定文件的来源。并非所有数据都可以信任。有些可能来自于失败的数据科学实验，有些可能来自于系统存在显著不一致性的数据，而另一些数据则来自于经过精心策划和信任的来源。文件位于着陆区、黄金区还是工作区？根据分析师的需求，原始数据或经过清洗的数据可能都可以使用。如果数据存储在某人的工作文件夹中，分析师可能需要仔细研究文件描述或与文件或项目所有者交流。同样重要的是了解数据的处理过程。有些属性可能已经经过策划并按照分析师的需求进行了处理，而其他属性可能需要不同的处理方式，并且需要从原始文件中获取。

解决这些缺点的方法与每个图书馆的组织和目录化方式一样，企业需要组织和目录化它们的数据集。

多年来，为分析而寻找合适的输入数据一直是一个未解决的问题（我在这个领域已经工作了超过 30 年）。在本节的其余部分，我们将探讨使用元数据注释和描述数据的不同方法，以增强可查性，并看看词汇表、分类法和本体论如何用于描述、组织和搜索数据集。

接下来，在下一节中，我们将考虑自动化如何帮助。考虑到数据湖中文件的数量庞大，并且通常会存在许多年来人们无视或绕过旨在记录和跟踪数据的流程和程序的情况，目录化过程必须尽可能自动化，并且无论使用何种工具，都必须使分析师能够轻松地记录笔记并使用有意义的业务术语标记字段和数据集。

技术元数据

为了帮助描述数据集，我们转向元数据或关于数据的数据。例如，在关系数据库中，表定义指定了元数据，包括表名、列名、描述、数据类型、长度等等。然后，表行中的实际值被视为数据。不幸的是，数据与元数据之间的界限很模糊。考虑以下示例（表 8-1），一个名为Sales的表，其中包含不同年份产品 ID 的季度和月度销售数据（以百万计）。

表 8-1. 销售表

ProdID	Year	Q1	Q2	Q3	Q4	Jan	Feb	Mar	…
X11899	2010	5	4.5	6	9	1.1	1.9	2.2	…
F22122	2010	1.2	3.5	11	1.3	.2	.3	.6	…
X11899	2011	6	6	6.5	7	4.5	2	.5	…
…	…	…	…	…	…	…	…	…	…

在这个例子中，字段名 ProdID、Year、Q1、Q2、Q3、Q4、Jan、Feb 等都是元数据，而实际的产品 ID（X11899、F22122）、年份（2010、2011）和销售金额是数据。如果分析师正在寻找产品的季度销售数据，通过查看元数据，他们可以知道应该能在这个表中找到它。同样，如果他们正在寻找月度销售数据，他们也知道可以在表中找到相关信息。

但是，我们可以设计与下文显示的相同的表格（表 8-2）。

表 8-2. 具有更复杂元数据的销售表

ProductID	Year	Period	SalesAmount
X11899	2010	Q1	5
X11899	2010	Q2	4.5
F22122	2010	Q3	11
X11899	2011	Q1	6
X11899	2010	一月	1.1
X11899	2010	二月	1.9
X11899	2010	三月	2.2
…	…	…	…

而不是为每个期间单独列出一个列，我们现在为每个期间列出一行。Period 列指定我们正在查看的期间是季度（Q1..Q4）还是月份（Jan..Dec）。尽管两个表包含完全相同的信息且可以互换使用，但在这个例子中，季度编号和月份是数据，而不是元数据。

当然，实际生活比这个简化的例子要复杂得多。就像字段名称可以晦涩或误导一样，数据也可以如此。例如，在实际生活中，第二个表更可能使用代码，并且可能看起来像表 8-3。

表 8-3. 具有更复杂数据的销售表

ProductID	Year	Period_Type	Period	SalesAmount
X11899	2010	Q	1	5
X11899	2010	Q	2	4.5
F22122	2010	Q	3	11
X11899	2011	Q	1	6
X11899	2010	M	1	1.1
X11899	2010	M	2	1.9
X11899	2010	M	3	2.2
…	…	…	…	…

这里，Period_Type为 M 表示“月”，相关的 Period 值为 2 表示二月，而 Period_Type为 Q 表示“季度”，相关的 Period 值为 2 表示年度的第二季度。对该表进行分析不会显示月份名称，尽管一位聪明的分析师可能能从元数据中推断（看到 Period_Type 是 M 或 Q，以及 M 的数量是 Q 的三倍）他们正在查看的是月度和季度销售数据。

正如这个例子所说明的，数据和元数据之间没有明确的界限，根据架构设计，相同的信息可以作为数据或元数据进行捕捉。仅依赖元数据无法告知后者表包含哪些种类的期间，寻找月度销售数据的分析师不会知道这个表是否会对他们有帮助，直到查看数据并看到期间包含月份为止。

数据分析

由于研究每个表格以理解其包含的内容显著减慢了找到正确表格的过程，分析常被用来弥合数据与元数据之间的差距。例如，如果分析人员无需查看数据就能知道Period字段包含Q1..Q4和Jan..Dec的值，他们会立即意识到该表格中可能包含季度和月度销售数据。分析会分析每一列的数据，帮助我们更全面地理解数据及其质量，正如我们在第六章中讨论的那样。除了最频繁的值及其计数外，它还计算：

基数

每个字段中有多少个唯一值。例如，如果两个表格是等价的，则ProductID和Year列的基数应该在两个表格中相同。

选择性

每个字段值的唯一性。这是通过将字段的基数除以行数来计算的。选择性为 1 或 100%意味着该列中的每个值都是唯一的。

密度

每列中有多少个NULL（或缺失值）。密度为 1 或 100%意味着没有NULL，而 0%的密度意味着该字段只包含NULL（即为空）。

范围、均值和标准差

对于数值字段，计算最小值和最大值，以及均值和标准差。

格式频率

一些数据具有非常独特的格式——例如，美国邮政编码要么是五位数字，要么是九位数字，或者是五位数字后跟一个短划线和四位数字。格式可以帮助识别字段中所包含数据的类型。

通过分析获取的统计信息，以及其他元数据（如字段、表格和文件的名称），被称为技术元数据。虽然这有助于我们理解数据的性质，但并不能解决可发现性的问题。事实上，更加糟糕的是，技术元数据通常是简称或者晦涩难懂——例如，就像表格 8-1 中的列被称为Q1和Q2，而不是First_Quarter和Second_Quarter，Year列可能仅仅被称为Y；分析人员因此很难搜索到它，因为Y可能代表Yield、Yes、Year或者其他任何东西。

分析层次数据

分析数据时，表格数据的分析结果非常直观——统计数据针对每一列进行汇总，涵盖所有行，但是对于像 JSON 或 XML 文件这样的层次数据则更加复杂。

尽管格式可能不同，但在概念上，JSON 文件与表格文件表示相同的数据。例如，订单可以被表示为关系数据库中一组表，或者一组通过所谓的主键-外键关系相互关联的表格文件。在图 8-1 中，有四个表用于存储订单、客户和产品的信息。主键-外键关系用线条连接主键字段和外键字段表示，一对多的关系用 1:N 表示，这意味着例如在Customers表中的每个CustomerID可能在Orders表中有多个相同CustomerID的订单。

图 8-1. 实体关系图

相同的信息可能以 JSON 格式呈现，其中层次结构表示关系数据库中由主键和外键表达的关系。与四个不同的表不同，单个 JSON 文件将捕获所有属性和关系。以下片段捕获了订单的所有信息。请注意，不需要CustomerID和ProductID来关联订单、客户和产品。客户信息嵌入在Order记录中，产品信息嵌入在OrderLine中，依此类推：

{"Order"
  {
    "OrderID" : "123R1",
    "Customer" {
      "Name" : "Acme Foods", "Address" : "20 Main St, Booville, MD",
      "Contact" : "Zeke Gan", ...
    }
    "OrderLine" {
      "LineNumber" : "1",
      "Product" {
        "Model" : "XR1900E", "Weight": "20",
        "Description" : "The XR1900E is the latest ...", ...
      }
    "Quantity" : 1,
    ...
  }
}

由于两种情况中的信息实际上是相同的，通常会使用一种称为剪切的简单过程来从分层文件中提取字段。例如，可以使用其完整分层名称Order.Customer.Name来提取客户名称。此名称是一个 XPATH 表达式（XPATH 是用于访问 XML 文档特定部分的查询语言）；剪切基本上为分层文件中的每个唯一 XPATH 表达式创建一个唯一字段。

剪切的一个问题是所谓的“有损性”——在将数据转换为表格格式时会丢失信息。例如，如果一个订单有两个客户和三个订单行项目，没有简单的方法可以保留这些信息。我们是将三个订单行项目归属于第一个客户，还是每个客户都归属于各自的订单行项目？我们是将一些归属于一个客户，一些归属于另一个客户吗？这里没有简单或通用的正确答案。

大多数分析工具，如 Informatica 和 IBM 的工具，要求分层文件在进行分析之前必须明确地被剪切或转换为表格格式，而像 Trifacta、Paxata 或 Waterline Data 这样针对非关系型大数据环境开发的现代工具可以原生地非损失地分析分层数据，或者至少会自动地对分层数据进行剪切。

业务元数据

为了帮助分析师找到数据，我们转向业务元数据，即关于数据的业务级描述。这些可以采用多种形式。

术语表、分类学和本体论

业务元数据通常包含在词汇表、分类法和本体论中。业务词汇表是业务术语及其定义的高度形式化（通常是分层次）列表。一些业务词汇表是分类法，一些是本体论，还有一些只是没有太多语义严谨的分组结构。关于分类法和本体论的区别，有许多激烈的讨论。我的目标在于给你介绍这两者的风格，而不是支持任何一方。有了这个理念，你可以将分类法视为对象的层次结构，其中子类是父类的子类。这也被称为是-一个（读作“izah”）关系。图 8-2 展示了我们大多数人在生物课上学习的生物分类法。

图 8-2. 生物分类学

本体论通常比分类法更为复杂，并支持对象之间的任意关系。例如，除了是-一个关系之外，还包括对象和属性之间的有-一个关系（例如，汽车有引擎）。作为另一个关系的例子，驾驶员驾驶汽车。图 8-3 展示了可能与汽车相关的本体论片段，其中汽车有轮子和引擎，并且是车辆的子类。

图 8-3. 车辆本体论的一部分

行业本体论

已为不同行业开发了许多标准本体论。ACORD 是一个保险行业组织，拥有超过 8,000 个成员组织，帮助保险公司以标准方式交换数据。为了描述正在交换的数据，ACORD 开发了一个业务词汇表，描述了其表单中的每个元素，涵盖了保险业务的许多方面。另一个例子是由两个受尊敬的行业组织——对象管理组织（OMG）和企业数据委员会（EDM）开发的 金融业务本体论（FIBO）。

公司也可以制定自己的标准。我在 IBM 工作时，我们开发了许多行业模型，其中包括特定行业本体论和相应的分析数据模型。

民间分类法

行业标准本体论的挑战在于，虽然它们非常适合上下文搜索，但通常非常复杂，有成千上万个术语，难以跟踪所有元素。此外，采用标准本体论需要对业务团队进行大量的培训，以使用标准术语。

民间分类法 是一种非常不严格的结构，试图代表员工对其数据的看法。民间分类法不会培训分析师使用严格的定义，而是收集当前术语，将它们组织成连贯的层次结构，并将其用作业务元数据。

另一个挑战是不同的群体可能对相同的事物有不同的名称。例如，市场营销可能将一个字段称为prospect name，销售可能称之为opportunity name，而支持可能称之为customer name。一些系统可能将这些分别表示为专门用于前景、机会和客户的三个不同数据集，而其他系统则可能将它们合并在一个单一的数据集中，并通过标志指示这是何种类型的联系。

为了避免混淆，不同的群体可以使用不同的民间分类法来使用他们习惯的术语搜索相同的数据。在 Waterline Data，我们选择通过创建不同领域的标签或术语来支持这一点，将一些领域专门用于特定群体，并在多个群体之间共享其他领域。

标记

一旦我们有了词汇表、分类法、民间分类法或本体论，为了使用它们来查找数据集，我们必须为这些数据集分配适当的术语和概念。这个过程被称为标记，它包括将业务术语与包含这些术语表示的字段或数据集相关联。例如，我们早期在技术元数据的示例中的Period字段可能会被标记为Number_of_Quarter和Month这两个反映其内容的业务术语。分析师们可以通过搜索“month”、“quarter”或“quarter number”来找到它。这个标记过程对于构建目录至关重要。

然而，要能够标记数据集，分析师或数据监护人必须了解它。由于在任何大型企业中没有一个人甚至一个团队知道并理解每一个数据集，这项工作必须在企业众多的数据监护人、数据分析师和其他主题专家之间进行众包。

许多公司，如 Google、Facebook 和 LinkedIn，都有目录，数据监护人和分析师可以手动标记数据集。还有来自公司如 Alation、Informatica 和 Waterline Data 的产品支持这种标记，并允许数据的使用者评分数据集、添加评论等。

我们在第六章中探讨了通过众包部落知识的想法，并将在本章后面看一些可用于编目的产品。

自动编目

尽管手动打标签和众包是必要的，但通常这些过程并不足够，并且耗时太长。企业可能拥有数百万个数据集，其中包含数亿个字段，即使每个字段在几分钟内就能打标签（实际上，有时这需要几小时的调查和讨论），我们仍然需要数亿分钟，或数千人年的工作！显然，这是不切实际的。通过与 Google、LinkedIn 和其他组织的团队讨论，我了解到，仅依赖手动流程最终只会给最受欢迎的数据集打标签，导致大量数据集“黑暗”。

如第六章所述，这个问题的解决方案是自动化。新工具利用 AI 和机器学习来识别和自动标记和注释暗数据集中的元素（基于 SME 和分析师提供的标签），以便分析师可以找到并使用这些数据集。Waterline Data 的智能数据目录和 Alation 可能是这种方法的最佳例子。Alation 试图从字段名称中推断字段的含义，并自动解释各种字段名缩写，而 Waterline Data 则根据字段名称（如果有的话）、字段内容和字段上下文自动为字段打标签，因此它尝试为甚至缺少标题（字段名称）的文件打标签。

我们将以 Waterline Data 为例，说明自动目录编制。该工具可以在 Hadoop 集群和关系型数据库中进行爬取，并对每个字段进行指纹识别（指纹是字段属性的集合，包括名称、内容和特征）。然后在分析人员处理不同文件和表格时，允许他们为字段打标签。你可以将其想象成创建“通缉”海报。

Waterline Data 的 AI 驱动分类引擎称为亚里士多德，然后利用这些指纹以及字段上下文自动为未打标签的字段分配标签。上下文是由同一数据集中的其他标签决定的。例如，如果一个数字字段包含从 000 到 999 的三位数，如果它旁边有一个信用卡号码，它很可能是信用卡验证代码；但如果它位于一个所有其他标签都涉及医疗程序属性的表中，则具有完全相同数据的字段很不可能是信用卡验证代码。

最后，分析人员可以接受或拒绝这些推断的标签，如图 8-4 所示，从而训练 Waterline Data 的 AI 引擎。

图 8-4. 自动标记，由人类分析师批准

该过程极大地减少了手动打标签数据集的需求，因此一旦数据集被编目，新数据集就能被找到。

逻辑数据管理

虽然标签是分析师使用熟悉的业务术语查找数据的好方法，但它们也提供了企业数据的一致“逻辑”视图。数据监护人员和分析师现在可以创建一致的政策，适用于所有数据资产，而无需跟踪不同数据集和系统中不同字段的称呼。从数据保护到数据质量，现代数据管理工具正在采用基于标签的政策作为自动化的方式，这些政策在传统上是手动、易错、劳动密集且脆弱的技术，导致数据项目进展缓慢并阻碍了自助服务。

敏感数据管理和访问控制

数据治理团队的一个重要关注点是如何管理敏感数据。有许多行业特定和国家特定的法规来管理和保护个人或敏感信息，比如欧洲的 GDPR、美国的 HIPAA 以及国际上的 PCI。此外，公司通常也会维护自己的内部“机密”信息清单，这些信息必须受到保护。我们将受监管合规性和访问限制的任何数据称为敏感数据。为了管理敏感数据，企业必须首先对其进行目录化（即找出存储位置），然后通过限制访问或对数据进行掩码来保护它。

传统上，安全管理员必须手动保护每个字段。例如，如果数据库中有一个表，其中包含社会安全号码（SSN）的列，管理员必须找出这一点，并手动创建一个规则，仅允许授权用户访问该字段。如果由于某种原因用户开始将 SSN 放入不同的字段（比如Notes字段），直到有人注意到并创建新的规则来保护它，那个字段就会保持不受保护。相反，像 Apache Ranger 和 Cloudera Sentry 这样的现代安全系统依赖于所谓的基于标签的安全。这些系统不是为特定数据集和字段定义数据访问和数据掩码策略，而是为特定标签定义策略，然后将这些策略应用于具有这些标签的任何数据集或字段。（有关管理访问的详细讨论，请参阅第九章。）

自动化和手动审核

如果没有自动化的敏感数据管理方法，新收集到数据湖的数据集无法在经过人工审查并确定其是否包含敏感信息之前释放供使用。为推动此过程，一些公司尝试创建“隔离区”，新数据集全部进入并留在那里，直到经过人工审查并获得一般使用的认可。尽管隔离区方法合乎逻辑，但这些公司报告称在处理隔离数据集时出现了显著的积压。这是因为该过程耗时且容易出错——这种问题通常由于没有预算进行这类工作而恶化，因为大多数数据集并未立即用于任何项目。不幸的是，这种忽视导致了恶性循环。由于隔离区中的文件对任何人都不可访问，因此它们不可查找，分析师也无法影响策划的顺序。

使用自动敏感数据检测可以实现更加优雅的解决方案。隔离区域的数据集可以通过目录软件自动扫描，并自动标记其包含的敏感数据类型。基于标签的安全性可以应用于自动限制对这些文件的访问或者去标识化敏感数据。

作为额外的预防措施，可以根据需求手动审查数据集，而不是自动提供数据集。这种系统应用自动标记，并将数据集的元数据添加到目录中以便找到数据集。一旦分析师找到想要使用的数据集，该数据集就会经过手动策划以验证标签的正确性，并对任何敏感数据进行去标识化。通过这种方式，虽然所有数据集都是可查找和可用的，但数据监护团队有限的资源会花费在有用的文件和资助项目上。

最后，随着数据集的提供，可以遵守数据主权法律和其他法规。例如，如果英国的分析师要求访问德国数据，而不是将数据传输到英国，他们可能会被允许访问当地的德国数据湖。

数据质量

数据质量是本书的其他章节中涵盖的广泛主题。在本章中，我们将重点讨论使用目录捕获和传达有关数据质量的信息。目录在这方面带来的一些重要创新包括能够应用基于标签的数据质量规则，并测量数据集的注释质量和策划质量。

基于标签的数据质量规则

较简单的编目技术会为每个物理字段在每个物理表或文件中硬编码数据质量和敏感度规则。更现代化的编目系统，特别是具有自动标记功能的编目系统，允许数据质量专家和数据监护人员定义和应用特定标签的数据质量规则。其核心思想是定义规则，然后将这些规则应用到任何带有该标签的字段上。例如，如果我们为Age创建数据质量规则，规定其应该是 0 到 125 之间的数字，我们可以将其应用于任何带有Age标签的字段，并计算不符合 0 到 125 之间数字的行数。然后，可以将质量得分捕获为不符合质量规则的行数的百分比。在 图 8-5 中，五行中只有三行符合数据质量规则，因此质量水平为 60%。

图 8-5. 数据质量水平

下面的部分涵盖了衡量数据质量的其他方式。

注释质量

注释质量是指数据集的注释比例。例如，如果每个字段都有一个标签，则注释质量为 100%；如果只有一半的字段有标签，则为 50%，依此类推。注意，注释质量可以同时考虑手动和自动建议的标签。除了标签，还可以包括数据集是否有描述、是否有血统（导入的、手动指定的或自动建议的）、以及是否填充了必需的属性（如主权）。

修订质量

修订质量是指有多少标签已被人工批准或修订。最终关注的是可信度，手动修订的数据集通常比自动注释的数据集更可信。

与注释质量不同的是，修订质量不会将自动建议的标签视为“有效”，除非数据监护人员或其他授权用户已经批准。修订质量还可以反映数据集是否有描述和血统（导入的、手动指定的或自动建议的），以及如果血统是自动建议的，则是否已由管理员批准。

数据集质量

数据集质量可以总结另外三种质量类型：基于标签的数据质量、注释质量和修订质量。再次强调的是可信度问题；关键在于将所有测量结果融合为一个具有实际意义的单一值。这方面没有最佳实践或公式。方法范围从仅考虑修订标签的质量到试图反映数据质量的每个方面。

例如，如果我们仅考虑策划标签的质量，如果每个字段都有一个质量水平为 100%的策划标签，那么数据集的质量水平可以说是 100%。如果只有一半的字段有策划标签，并且这些字段的平均质量为 80%，那么数据集的质量水平为 40%，依此类推。

然而，即使数据集具有完美形式的字段和相应的标签，如果我们不知道它来自哪里，我们真的可以信任它吗？如果答案是否定的，那么我们如何在单一的衡量中归一化数据的质量和血统的质量？这是一个困难的问题，大多数公司选择（采取了简单的方法）简单地使用不同的属性来反映数据质量或可信度的不同方面。事实上，这是我推荐的解决方案：聚合所有字段的基于标签的质量，以生成数据集级别的一个值，并保持注释和策划质量分开。不要试图提出一个可以反映所有三个因素的公式。

关联不同的数据

数据科学工作的一个挑战是，它通常需要数据科学家和数据工程师将以前从未组合过的数据组合起来。然后找到数据的挑战不仅是找到包含所需数据的数据集，还要能够判断这些数据集是否可以组合。这有两个方面：

• 这些数据集能够连接吗？换句话说，有没有一种方法可以正确地将一个数据集中的数据与另一个数据集中的数据相关联？例如，假设一位数据科学家找到了一个包含个人人口统计信息（包括姓名）的好数据集，但是希望将其与人们的收入相关联。搜索收入数据可能会返回多个数据集，但其中哪些可以与人口统计数据相关联？如果任何一个收入数据集包含姓名和地址信息，那将是一个很好的开始。如果没有一个数据集包含该数据，但其中一些包含社会安全号码（SSNs），则数据科学家随后可以搜索一个既包含 SSNs 又包含姓名和地址的数据集，并使用该数据集将收入和人口统计数据集连接在一起。

• 连接能产生有意义的结果吗？即使前面的数据科学家找到了一些可以连接的数据集，如果这些数据集包含非重叠的数据怎么办？例如，如果它们分别包含美国客户的人口统计信息和欧盟客户的收入信息，即使它们都包含姓名和地址，重叠部分将非常少。

为了有用，目录应该帮助用户找到相关的数据并估计组合它的有用性。有几种方法可以实现这一点：

字段名称

在许多设计良好的系统中，假定具有相同名称的字段包含相同的数据，因此分析人员经常在需要连接的表中寻找具有相同名称的列。然而，在较大的系统中，这通常并非如此，并且依赖字段名称可能会导致在具有不同命名约定的不同系统之间产生错误结果。此外，如果没有实际运行连接，也无法确定连接的有用性。

主键和外键

在关系型数据库中，表通过键相关联。这些称为主键-外键（PKFK）或引用完整性关系。举例来说，假设你有一个包含客户信息的表。这个表将有一个主键来唯一标识每个客户，而所有其他表将使用这个键引用该客户。其他表中引用客户表主键的列称为外键。PKFK 关系通常在实体关系（ER）图中捕获，使用如 Erwin Data Modeler（ERwin）或 IDERA 的 ER/Studio 等数据建模工具创建。尽管大多数生产系统避免这些约束因为它们引入的开销，但 PKFK 关系通常也被声明为关系型数据库中的引用完整性约束。PKFK 关系是确保连接返回良好结果的一种好方法。不幸的是，这些关系通常仅在单个系统内可用，并且不能帮助关联跨系统的数据。

使用情况

可以从数据使用中获取有用的连接，例如通过查看现有的连接数据的工件，如数据库视图、ETL 作业和报表。它们还可以通过扫描数据库 SQL 日志来推断哪些查询用于连接数据。尽管这些工件通常通过名称和描述提供某些连接的上下文，并且通常保证连接将生成有用的结果，但 SQL 查询可能不会提供有关为何连接数据以及连接是否成功的信息。

标签

最困难的连接通常是从未进行过的连接，特别是跨不同系统和不同数据格式的连接。目录可以通过帮助用户识别具有相同标签的数据集来极大地帮助这一努力。有时可以通过分析获取的技术元数据来估计连接的有用性，或者可能需要实际执行连接并分析结果。

建立血统

目录需要回答的一个关键问题是分析员是否可以信任数据，而知道数据来源是其中的一个重要部分。这被称为数据的血统或来源（有关血统的详细讨论可见第六章）。目录的一个工作是显示数据资产的血统，并填补血统缺失的地方。

大多数 BI 工具（如 Tableau 和 Qlik）都会捕获指示可视化和报告创建方式的血统信息。同样，大多数 ETL 工具（如 Informatica、IBM InfoSphere 和 Talend）在移动和转换数据时会自动捕获血统信息。然而，许多高级分析是通过 R 和 Python 脚本完成的，许多数据转换和移动是通过 FTP、Pig 或 Python 编写的脚本以及开源 Hadoop 工具（如 Sqoop 和 Flume）完成的。这些工具不会捕获或暴露数据的血统信息。由于只有追溯到源头时血统信息才有用，因此填补这些空白至关重要。一些工具尝试通过抓取系统日志（Cloudera Navigator）、对开源系统进行仪器化以报告血统（Apache Atlas）、要求用户为他们编写的每个作业手动提供血统信息（Apache Falcon），或者通过检查文件内容（IBM InfoSphere Discovery 和 Waterline Data）或 SQL 日志（Manta 和 Alation）来推断血统信息来填补缺失的血统信息。

如你所见，确实没有一种单一的方式可以获得所有的血统信息，但目录负责从可能的地方导入这些信息并将其全部串联起来。 "串联" 指的是连接不同的血统段的过程。例如，一张表可能已经通过 Informatica 的 ETL 工具从 Oracle 数据仓库中摄取到 Parquet 格式的数据湖文件中，然后与通过 Python 脚本从 Twitter 源生成的 JSON 文件进行连接，以创建一个新的 Hive 表，然后被数据准备工具用来创建一个 CSV 文件，最终被加载到数据集市中的表中，再由 BI 工具生成报告。为了全面了解报告中数据的来源，所有这些步骤都需要连接或串联起来。如果任何一步缺失，分析员将无法将报告追溯到原始来源——Oracle 数据仓库和 Twitter 源。

如这个假设性例子所示，数据经常会经过多种工具的多次变更。另一个问题是，即使有源流信息，它通常是用生成数据的工具的语言表达的——而不是所有分析师都精通所有工具。为了能够解释数据经历了什么，分析师需要将步骤以业务术语记录下来。这被称为业务源流。不幸的是，今天大多数企业并没有一个地方来捕捉和跟踪业务源流。每个作业和步骤可能会有记录，但通常是在工具内部完成（例如，作为脚本的注释），或者在开发者的笔记本、Excel 文件或维基中完成。目录提供了一个吸引人的场所来集合这样的源流文档，并且使其对数据的使用者可用。

数据供应

一旦确认了正确的数据集或数据集合，用户就希望在其他工具中使用它们。为了支持这一点，目录通常提供数据供应选项。数据供应可能就像使用特定工具打开数据集那样简单——例如，如果分析师找到包含销售信息的数据集，他们可能希望在他们喜爱的 BI 工具中打开它以可视化和分析数据。同样地，如果数据科学家或数据工程师发现了一个有趣的原始数据集，他们可能希望在他们喜爱的数据准备工具中打开它。这类似于使用 Mac Finder 或 Microsoft Explorer 查找文件，右键单击文件，然后弹出“打开方式”菜单，列出可以用于该文件的所有程序。由于有多种工具可以用于数据，你应该确保供应能力是可扩展的，并且可以配置为用户可能希望使用的任何工具。

另一个供应操作涉及获取数据访问权。使用数据目录的一个巨大优势是，它使得数据可以被发现，而无需用户直接访问。这意味着当用户找到他们需要的数据时，他们必须在使用之前请求访问权限。访问请求可能只需发送电子邮件给数据所有者，请求将用户添加到访问控制组，以便他们可以直接访问数据；或者可能会复杂到创建一个工单，并启动一个长期的批准工作流程，将数据导入数据湖中。访问管理和摄取将在第九章中详细讨论。

构建目录的工具

几家供应商提供数据目录工具，包括 Waterline Smart Data Catalog、Informatica Enterprise Data Catalog、Alation、IBM Watson Knowledge Catalog、AWS Glue 和 Apache Atlas（由 Hortonworks 及其合作伙伴开发）。在选择供应商时，应考虑几个重要的能力：

• 本地大数据处理以实现性能和可伸缩性

• 自动化数据发现和分类

• 与其他企业元数据存储库和单平台目录的集成

• 用户友好性

第一个考虑因素是是否支持本地大数据处理工具，如 Hadoop 或 Spark。数据湖是企业中最大的数据系统，需要大型节点集群的组合能力来处理和目录其包含的数据。Hadoop 的整个关键不仅在于提供一个成本效益的数据存储场所（多年来我们一直有这样的场所），还在于提供一个成本效益的数据处理场所。试图在不利用 Hadoop 处理能力的情况下目录 Hadoop 规模的数据是行不通的。虽然一些可用工具是专为 Hadoop 设计的，比如 Alation 和 Collibra 等，但另一些工具如 Cloudera Navigator 或 AWS Glue 则是为关系数据库设计的，要求数据加载到 RDBMS 中或者有专有引擎在 Hadoop 之外运行，不能扩展以处理数据湖规模。

另一个问题是数据湖中数据的范围和复杂性使得人类无法手动对所有数据进行分类或标记业务元数据。因此，需要采用自动化方法来完成此分类。虽然所有提到的工具都允许分析师以某种方式标记数据，但像 Waterline Data 这样的一些工具提供了一个自动发现引擎，从分析师标记中学习，并自动分类其他数据集。

当然，Hadoop 数据湖只是企业数据生态系统的一部分，因此必须与其余的治理基础设施集成。许多企业可能已经在大量元数据投资，需要将其整合到新的数据湖中。有几种工具提供企业数据存储库。虽然 Hadoop 可能是处理 Hadoop 内部数据和其他来源数据的最可扩展和成本效益最高的平台，但像 Cloudera Navigator 或 AWS Glue 这样的单平台解决方案具有限制性，并且不能满足企业需求。

最后，许多元数据解决方案是为 IT 和治理专家设计的。为了被广泛采用，库存解决方案必须直观且可供非技术分析师使用，通常无需太多培训，如果有的话。面向业务分析师的用户界面有助于提供一个清晰的视图，显示业务术语和描述，而不是填入大量技术细节。对于某些用户来说，技术细节当然是必要的，并且应该易于访问，但不应该强加给业务用户。一些目录通过具有不同基于角色的视图来实现此目标，而其他则提供业务视图，并提供了一种让技术用户深入查看技术细节的方式。

工具比较

表 8-4 总结了一些数据目录产品的功能。基本上有三组工具：

• 企业目录工具试图对企业中所有数据进行目录化。

• 单平台目录工具专注于特定平台。

• 传统/关系型的编目工具不提供本地的大数据支持。这些工具不能在 Hadoop 或其他大数据环境中本地运行，并且需要关系接口（如 Hive）来有意义地编目大数据。它们有时被放置在数据池中（一个构建在大数据平台上的数据仓库，如第五章中所述），但不能支持以本地 Hadoop 文件格式存储大量原始数据的数据湖。

Table 8-4. 目录工具比较

	大数据支持	标记	企业	面向业务分析师的用户界面
企业
Waterline Data	本地	自动化	Y	Y
Informatica Enterprise Data Catalog	本地	手动	Y	Y
单一平台
Cloudera Navigator	本地	手动
Apache Atlas	本地	手动
AWS Glue	本地	手动
IBM Watson Catalog	本地	自动化		Y
传统/关系型
Alation	仅 Hive	手动	Y	Y
Collibra	仅 Hive	手动	Y	Y

数据海洋

如果目录提供位置透明度，那么我们是否甚至需要数据湖呢？为什么不将所有数据编目并提供在所谓的“数据海洋”中？一些企业正在着手进行这样雄心勃勃的项目，但这些项目的范围和复杂性非常惊人，可能需要数年的专注努力。然而，这种替代方案非常吸引人，可以避免频繁移动和复制数据，因此一些早期采用者愿意踏上这个旅程。此外，当前的监管环境要求数据透明性，规定数据隐私，并规定数据的适当使用，这是强制企业在数据编目中创建单一的可见性、治理和审计点的强大动力。监管合规和数据海洋的努力是协同的，并且经常手牵手工作。

结论

数据目录是数据湖和企业数据生态系统的一个组成部分。随着数据呈指数级增长并且数据使用渗透到业务的各个方面，有一种自动化编目数据的方式并使用户能够找到、理解和信任数据，这是通向数据驱动决策的必要第一步。

第九章：管理数据访问

本章描述了向分析师提供数据湖中数据访问的挑战，并提出了几种最佳实践。数据湖在几个方面与传统数据存储不同：

载入

数据集、用户和变更的数量非常庞大。

无摩擦地摄取

因为数据湖将数据存储以备将来尚未确定的分析使用，通常在摄取数据时不进行或仅进行最少的处理。

加密

通常存在政府或内部法规要求保护敏感或个人信息，但这些数据又需要用于分析。

工作的探索性质

很多数据科学工作无法被 IT 员工预料到。数据科学家通常不知道在庞大而多样化的数据存储中有什么可用的内容。这为传统方法创建了一个进退两难的局面：如果分析师找不到他们无权访问的数据，他们就无法请求访问权限。

最简单的访问模式是为所有分析师提供对所有数据的访问权限。不幸的是，如果数据受到政府法规的约束（例如包含个人可识别信息或信用卡信息的情况），或者被版权保护并限制访问（例如因特定或有限用途而从外部来源购买或获取的数据），或者被公司认为是竞争或其他原因敏感和关键的信息，这是无法做到的。大多数公司都有他们认为敏感的数据——从商业机密到客户列表再到工程设计和财务信息。因此，除了一组主要处理公共数据、研究数据和非敏感内部数据的有限项目外，通常不可能向所有人提供对数据湖中所有数据的完全访问权限。

授权或访问控制

授权是管理数据访问的常见方式。它涉及明确地分配权限，以执行特定的操作（如读取或更新）和特定的数据资产（如文件和表），给特定的分析师。为了简化这一过程，安全管理员通常创建角色（权限集合）并将这些角色分配给分析师群体。

大多数遗留系统提供其自身的内部授权机制。由于越来越多的公司选择在云中使用更多的应用程序而不是使用单一供应商提供的单一集成应用程序，单点登录（SSO）系统变得非常流行。通过单点登录，用户只需登录一次，他们的凭据就能被所有应用程序和系统支持。

不幸的是，这种方法存在几个挑战。特别是：

• 预测数据分析师在项目中所需的数据是非常困难的。

• 除非分析师能访问数据，否则他们无法确定他们是否需要这些数据。

• 维护授权可能需要高昂的成本，这些成本可能分摊在多个时间段和活动中：

  • 每当新员工入职时，安全管理员需要提供适当的授权。

  • 当员工更改角色或项目时，安全管理员需要提供新的权限并撤销旧的权限。

  • 当出现新的数据集时，安全管理员需要确定所有可能需要访问该数据集的用户。

  • 当分析师需要一个包含敏感数据的数据集时，需要创建一个相应的数据集的版本，以删除或去标识化敏感数据。

挑战如此巨大，以至于一些企业不得不监控访问日志，以确保分析师只能访问适当的数据。不幸的是，这种方法只能在事后发现问题，无法防止人员有意使用错误的数据，也无法帮助他们意外地避免使用错误的数据。想要更加积极主动的企业采取各种方法来应对这些挑战，包括：

• 使用基于标签的数据访问策略

• 通过删除、加密或用生成的随机数据替换来去标识化敏感数据，并向所有人授予对这些去标识化数据集的访问权限。

• 通过创建一个仅包含元数据的目录来实现自助访问管理，分析师可以从数据集所有者或安全管理员那里找到所有可用的数据集，然后请求访问相关的数据集。

我们将在接下来的章节中探讨这些不同的访问控制方法。

基于标签的数据访问策略

传统的访问控制是基于物理文件和文件夹的。例如，Hadoop 文件系统（HDFS）支持典型的 Linux 访问控制列表（ACLs）。"设置文件访问控制列表"（-setfacl）命令允许管理员或文件所有者指定哪些用户和用户组可以对特定文件或文件夹进行什么样的访问。例如，如果一个文件包含工资信息，管理员可以使用以下命令使人力资源（HR）部门的用户能够阅读它：

hdfs dfs -setfacl -m group:human_resources:r-- /salaries.csv

这条命令基本上表示任何human_resources组中的用户都可以读取salaries.csv文件。

当然，如果一个数据湖包含数百万个文件，手动为每个文件设置权限显然是不太实际的。因此，管理员通常会设置文件夹，并为所有文件夹或文件夹树中的所有文件授予访问权限。例如，他们可以创建一个hr_sensitive文件夹，并允许hr组中的任何用户读取该文件夹中的任何文件。通常这种方法是足够的，但它也带来一些重大挑战，包括：

• 需要支持反映组织实际情况的复杂权限方案

• 需要确定和设置每个文件的权限

• 需要检测和处理模式变更

大型企业中的组织实际情况通常非常复杂。例如，如果我们决定，与其给予所有 HR 用户查看 hr_sensitive 文件夹中所有数据的权限，我们希望只有来自特定部门的 HR 用户可以查看该部门的数据，那么我们需要创建多个子文件夹——每个部门一个（例如 human_resources/engineering、human_resources/sales 等），并为每个部门创建一个单独的组（例如 hr_engineering、hr_sales 等）。

所有进入数据湖的新文件都必须进行检查，以确定谁应该访问它。一种方法是将所有新数据隔离，直到数据管理者或安全分析师能够审核它，例如将其保存在单独的文件夹中——一个检疫区，如 图 9-1 所示。有时，公司可能会采取捷径，假设例如来自 HR 应用的任何数据只能由 HR 访问。但总的来说，对于数以百万计的文件，手动完成这项任务是不可能的。然而，公司不能冒险将数据对所有人开放，直到有人确定其内容及其应访问者。

图 9-1. 检疫区的手动审核

虽然这在摄入数据方面有一些可行性，尤其是如果很少添加新类型的数据到集合中，但这对于在数据湖中创建的数据并不实际。如果必须将数据湖中创建的任何新文件隔离，直到有人手动检查并确定访问控制策略，那么数据湖中的工作将会完全停滞。

在某些 Hadoop 发行版中实施的一个更加优雅的解决方案是基于标签的安全性。例如，Cloudera Navigator 和 Apache Ranger（作为 Hortonworks Hadoop 发行版的一部分提供）支持基于标签的策略。使用这些工具，安全管理员可以设置使用标签的策略，而不是为每个文件和文件夹单独指定 ACL。虽然你仍然需要一个检疫区，分析员可以简单地给文件和文件夹打上标签，而不是为每一个手动创建 ACL，如 图 9-2 所示。

图 9-2. 基于标签策略的检疫过程

这些标签可以在本地目录工具（如 Cloudera Navigator 和 Apache Atlas）中设置，并且会被策略访问控制工具（如 Apache Ranger）自动捕捉。例如，Hortonworks Ranger 教程 展示了如何为任何标记为 PII（个人身份信息）的文件设置策略，无论其位于何处。

基于标签的访问控制策略方法还解决了反映复杂组织现实的挑战，因为你不再试图在文件夹结构中反映它。相反，文件和文件夹可以随意存放，策略可以任意复杂，并依赖于多个标签。例如，要根据部门来细化访问控制策略，你只需为文件添加包含部门名称（工程、销售等）的标签，并为每个标签组合（例如，人力资源和工程、人力资源和销售）创建单独的策略。你无需创建新文件夹、移动数据，或重写依赖于旧文件夹结构的应用程序。

标签提供了一种强大的管理和组织数据的方式。事实上，使用标签，你甚至不需要一个单独的隔离区域。相反，新接收的文件可以在摄取过程中标记为“隔离”，并且可以创建策略来限制除数据监护人外的任何人访问这些文件。数据监护人随后可以审核这些文件，使用适当的敏感数据标签进行标记，最后移除隔离标签，正如在图 9-3 中所示。

图 9-3. 使用标签隔离文件

虽然基于标签的安全性解决了围绕数据的组织挑战并加快了手动审核流程，但标签与数据湖的前提存在直接冲突。在数据湖中，数据存储在未来未确定的情况下，并通过无摩擦摄入加载，而无需任何处理。无摩擦摄入使数据加载快速，并对源系统施加最小的压力，但也使得很难弄清楚你刚刚接收到了什么样的数据，以及它是否敏感，无论是传统意义上还是公司特定意义上。

此外，分析人员可能会因为大量的新数据而感到不知所措，并且失去及时处理隔离项目的能力。检测敏感数据是一项具有挑战性的任务。分析人员如何确切地知道一个百万行文件中的某些行（也许成千上万！）没有包含社会安全号码或其他敏感标识符，而这些行刚好存储在一个名为Notes的字段中？查看前几百行可能不会显示任何内容——事实上，有些列可能完全为空——而对整个数据集进行大规模查询将需要时间，并且可能需要脚本编写或开发专门的工具。

即使分析员能够编写和运行检测敏感数据所需的脚本，模式和数据变化仍然是一个额外的挑战。如果新文件进来，分析员没有在其中找到任何敏感信息，那么后续对该文件的更改（新的分区）可能会包含额外的字段，这些字段确实包含敏感数据，或者这些数据可能被添加到最初不敏感的字段中。

处理敏感数据和访问控制管理的唯一实际解决方案是自动化。像 Informatica、Waterline Data 和 Dataguise 这样的工具会扫描所有新文件——新摄取的文件、之前摄取文件的新分区以及在数据湖中创建的新文件——并自动检测敏感数据并标记文件，如图 9-4 所示。然后将这些标记导出到本地目录工具，如 Apache Atlas，以用于执行基于标记的策略。

图 9-4. 自动标记敏感数据

去识别敏感数据

一旦识别出敏感数据，就可以限制对其的访问。不幸的是，这意味着这些数据无法用于分析。相反，企业通常会加密敏感数据，并允许所有人访问加密的数据集。可以应用不同形式的加密，包括：

• 透明加密

• 显式加密

• 去识别

为了描述这些内容，我们假设有一个数据集——简单起见，我们假设它是表格的——其中包含医疗保健提供者的一些患者信息（参见图 9-5）。

图 9-5. 患者信息数据集的示例

透明加密（例如 Cloudera Navigator 提供的）会在写入时自动对数据进行磁盘加密，并在读取时自动解密，如图 9-6 所示。这是为了防止有人访问或复制原始磁盘卷，并一字节一字节地读取以重建数据文件，从而避开所有访问控制。

图 9-6. 透明加密

然而，透明加密无法阻止具有文件读取权限的分析员查看敏感数据。出于这个原因，企业通常部署显式加密，并单独加密每个值，如图 9-7 所示。尽管这看起来很简单——有许多开源加密功能可用，并且提供加密的各种工具，如 Dataguise、Informatica、IBM、Privitar、Vormetric 等——但它使敏感数据完全无法使用，正如图中所示。

这给试图使用数据集的数据科学家带来了真正的问题。正如在第一章中提到的，我采访的一位数据科学家告诉我，在他的公司，除非能证明属性不敏感，否则数据湖中的所有数据都会被加密。这位数据科学家对这种做法并不赞同。他反问道：“如果我找不到或查看属性，我如何能证明它不是敏感的？”

图 9-7. 明确的加密使数据无法使用。

即使只加密真正敏感的属性，这些属性通常编码着数据科学家用来推导模型变量的重要信息。例如，在一个数据集中包含人名但性别信息缺失的情况下，通常可以通过名字推断出性别。有时还可以通过名字的首尾字母推断出种族。如果名字被加密，就无法推导出这些信息。同样，虽然加密地址信息是必要的，但它阻止了地理分析。为了在保护个人隐私的同时实现这些分析，开发了一类称为“去识别”或“匿名化”的技术。这些技术用随机生成的值替换敏感信息，保留原始数据值的重要特征。例如，一个民族名字可以用反映相同种族的随机名字替换，地址可以用 10 英里范围内的其他有效地址替换，如图 9-8 所示。

图 9-8. 数据去识别

同样，包括 Dataguise、Privitar、IBM InfoSphere Optim 和 Informatica 在内的多个工具提供这些功能。

虽然在许多情况下，去识别或加密敏感数据是有效的解决方案，但有时分析师需要访问真实数据。此外，即使没有敏感数据，大多数企业也将数据访问分隔化，并仅按需提供。由于数据科学本质上是探索性的，很难预测分析师需要哪些数据。即使是简单的分析也需要理解可用数据和获取访问权限。作为非常高维护、严密管理权限与无需管理的自由访问之间的折中，公司正在转向自服务访问管理。

数据主权与法规合规性

为了遵守区域、国家和行业的数据保护法规，需要收集更多关于数据集的信息，并存储在其元数据中。例如，为了遵守数据主权法，重要的是要知道数据集来自哪个国家，更重要的是，它包含哪个国家公民的数据。而不是为每个物理数据集硬编码政策，可以制定策略，例如，指定德国数据不能在欧盟之外复制。

数据谱系，在 第六章 中详细讨论，还可以用于追踪数据源的原始国家。Figure 9-9 说明了这种工作原理。对于每个数据集，我们创建一个Provenance属性，用于记录数据集的来源。例如，对于源自美国的数据集，此属性将设置为USA。如果通过合并多个其他数据集创建数据集，则将每个数据来源的来源添加到Provenance属性中。因此，如果从美国的 CRM 系统和德国的 ERP 系统加载数据到英国的数据仓库，然后再加载到法国的数据湖中，最终数据集的Provenance属性将包含USA、Germany、UK和France的值。然后，策略可以指定，如果Provenance属性包含Germany，则将适用某些规则。

Figure 9-9. 追溯来源

类似地，第八章中描述的“技术元数据”中的分析可以用来确定数据集中任何地址的来源。考虑到图表 9-10 和 9-11 中的表格。第一个是一个Customers表，包含客户的姓名和地址，而第二个表格包含了在Country字段中具有特定值的Customers表中的行数，这是通过分析确定的。

Figure 9-10. 分配具有国家来源的属性

Figure 9-11. 每个国家的行数统计

然后可以创建并填充一个Referenced Countries属性（最好是通过程序自动填充），填充的值来自Country列的分析结果。并且可以制定一个策略，例如，如果数据集具有Referenced Countries属性并且其中包含Germany作为条目，则应适用特定规则。这种方法可以遵守像德国和中国等国家的数据主权法，禁止将其公民的数据移出该国。

除了对数据来源的关注之外，许多法规还规定特定数据集的使用限制。例如，GDPR 规定客户数据只能用于收集它的业务目的，任何额外的使用需要明确的客户同意。所有这些信息都需要被捕捉和存储在某个地方，以便在授予数据访问权限时进行考虑，而数据目录则是存储和管理这些信息的理想地点。

自助访问管理

尽管积极和自动保护敏感数据是合理的，并且通常是政府法规要求的，但访问控制通常超出敏感数据，需要考虑在组织中谁应该访问什么数据。例如，许多公司不会将客户为其产品支付的价格与销售团队和管理层以外的人员分享，也不会与项目团队外的人员分享即将推出的产品的工程设计等。正如我们所见，管理这种访问可以在创建新文件时积极进行，也可以在用户添加到数据湖、更改项目或更改职责时按需进行，使用自助访问管理。

数据湖的前提是保留未来尚未确定用途的数据。显而易见的问题是，在未来谁需要访问哪些数据以及为什么会变得非常困难。另一方面，如果分析师们无法访问数据并且不知道其存在，他们将永远无法找到并使用它。自助访问管理与数据目录结合解决了这个问题，使所有数据都能被找到。这个系统通过在某人实际需要数据进行项目时移交访问控制和数据屏蔽决策来解决这个问题。该系统提供了几个独特的特点和好处：

• 分析师可以探索（搜索和浏览）可能提供给他们的所有数据集的元数据。

• 分析师可以向数据集所有者申请访问权限。

• 数据集的所有者决定谁可以访问它，以何种方式以及多长时间。

• 所有请求、理由和权限都会被跟踪以供安全审计目的。

图 9-12 到图 9-15 展示了一个自助访问管理和数据提供系统。具体步骤如下：

1. 数据所有者将数据资产发布到目录（图 9-12）。此时，分析师们能够找到数据，但无权读取或更改。

   

   图 9-12. 发布数据

2. 数据分析师在目录中找到数据集（图 9-13）。由于分析师无权访问数据，因此必须在元数据上进行搜索。这也是为什么拥有良好的元数据和业务级描述非常重要，正如前一章所述。

   

   Figure 9-13. 分析师找到数据

3. 分析师从数据所有者那里请求访问（Figure 9-14）。分析师可以使用目录查找数据，但无法访问它；他们必须向数据所有者请求许可才能使用。这样，数据所有者完全控制谁使用数据以及原因。

   

   Figure 9-14. 分析师请求访问

4. 数据所有者批准了请求（Figure 9-15）。

   

   Figure 9-15. 访问请求已批准

5. 数据集被提供（供应）给分析师（Figure 9-16）。这可以通过多种方式完成，从给分析师访问源系统到将数据复制到分析师的个人工作区域。该过程还可能包括脱敏步骤以掩盖敏感数据。关键在于，仅在请求数据集并且确实有业务理由时才执行这项工作。

   

   Figure 9-16. 请求的数据集被提供给数据湖，并提供给数据分析师

采用这种方法有很多优势。正如我为这本书采访的一位大型企业的 IT 高管所解释的那样：

人们害怕分享数据，除非他们能确保它被适当地使用。通过让他们决定谁可以使用数据以及如何使用，我们创造了一个他们感到安全分享数据的环境。在我们实施这种自助服务方法之前，获取数据需要数月的上下管理层的谈判。每个人总是尽可能地要求一切，以确保他们不必再经历谈判的痛苦和延迟。这让数据所有者对请求者真正的需求感到不信任，并迫使他们实施严格的审查流程，请求者必须提供非常详细的需求和理由，导致更多的工作和更多的延迟。在这样的环境中几乎不可能探索数据。

通过自助访问管理，请求者可以在甚至发出访问请求之前就研究目录中的数据集，并找出他们需要的内容，因此请求减少了很多，即使在进行请求时，由于分析师已经在目录中进行了相当广泛的探索并找到了适合目的的数据，请求的数据量也大大减少。最后，由于访问请求相当自动化，额外的请求也是快速和简单的。

简而言之，这种自助服务流程让数据所有者控制谁使用他们的数据，并使分析师能够探索数据集并快速获取访问权限。此外，通过为特定时间段授予数据访问权限，这种方法消除了管理所有可能数据集权限所需的维护工作，以及项目结束后分析师可能保留的遗留访问权限，以防万一他们可能需要。采用自助服务方法，他们可以简单地提交另一个请求，以快速恢复访问权限。

一旦获得授权，可以以多种方式向分析师提供对数据的物理访问，具体取决于数据集的性质和项目的需求。授予访问权限的一种流行方式是为数据集创建外部 Hive 表。外部 Hive 表不复制或更改数据集，并且可以通过可忽略的计算成本（因为它们只是元数据定义）进行创建或删除。然后向分析师授予访问外部 Hive 表的权限。

对于某些项目，分析师可能希望复制文件或创建自己的 Hive 表（例如，使用告知 Hive 解析和解释数据的不同输入格式）。在这种情况下，他们可以获得数据集的副本或被授予对数据集本身的读取访问权限。

配置数据

上一节介绍了自助数据访问的好处，并概述了数据配置的概述。数据配置是构建数据湖的重要部分，并值得进行更深入的讨论。如图 9-17 所示，它包括四个步骤。

图 9-17. 数据配置步骤

第一步是由想要访问数据集的分析师完成。请求通常描述：

• 需要哪些数据（哪个数据集以及是整个数据集还是部分数据集）

• 谁需要访问权限（需要访问数据的用户或组列表）

• 项目（所需数据的项目）

• 访问数据的业务理由（为何需要数据）

• 数据需要多长时间（访问权限撤销后的时间段）

• 如何配置它（用户是否应该在原地获取数据，或者是否应将其复制到指定的数据库或数据湖）

如果数据将被复制，请求还应明确说明：

• 数据应放在何处

• 是否应该是私有副本还是可以共享的

• 是否应该是一次性快照还是应该保持更新

• 访问权限到期后是否应保持更新或删除

通常通过像 ServiceNow 或 Jira 这样的标准案例跟踪系统或使用像 Pegasystems 或 Eccentex 这样的 BPM/工作流/案例管理系统进行申请。跟踪系统将请求路由到数据所有者或管理者。在某些情况下，可能会实施自动批准规则——例如，如果请求者属于某个特定组，可以自动批准审批。如果需要将数据复制到其他地方，则目标系统的管理员可能需要签署该请求。

逻辑可能会变得更复杂。例如，如果请求者在源数据处有访问权限，但希望将其复制到其他地方，则只有目标管理员可能需要批准该请求。相反，如果请求者请求共享副本，并且数据已经存在于目标系统中，则只有源数据管理者可能需要批准，因为目标系统不会使用额外的存储空间。

跟踪系统还提供了单一访问点和审计功能，因此公司可以记录谁使用了什么，以及出于什么目的。这不仅是良好的数据安全卫生习惯，而且通常是像 GDPR 这样的外部法规要求。

由于数据是从其他地方复制过来的，所以大部分时间请求的数据不会被修改，而是用来创建一个新的数据集。因此，共享这些数据给多个请求者非常有吸引力。数据被复制到一个预定义的位置（通常是在着陆区或原始区），只要有任何未处理的请求者，就会保持更新。

让我们通过一个分配场景来进行工作。想象一下，我们有一个数据仓库，其中有一个名为Customers的表，如图 9-18 所示，是一个小矩形。名为 Fred 的用户请求从 6 月 1 日到 8 月 5 日通过数据湖中的共享副本访问该表。

图 9-18. 用户请求访问数据仓库中的数据集

假设请求被批准，表将在 6 月 1 日如图 9-19 所示的暂存区标准路径中被复制。表中的所有数据将被复制到一个目录，其名称与复制时的日期相匹配。

图 9-19. 数据集已分配到数据湖

第二天，仅复制自初始副本以来发生的更改到新目录。其名称将反映那一天（在本例中是 6 月 2 日），如图 9-20 所示。

图 9-20. 数据湖已从数据仓库中更新为最新更改

这将持续到请求在 2018 年 8 月 5 日到期。

现在想象一下，另一个用户曼迪从 6 月 15 日到 7 月 15 日请求相同的表格，如图 9-21 所示。

图 9-21。另一个用户请求相同的数据集。

如果她的请求得到批准，在 6 月 15 日，曼迪将获得对/Landing/DW/Customers的访问——一个Customers表的共享副本，如图 9-22 所示。曼迪将继续在 7 月 14 日之前保持访问权限。

图 9-22。两个用户将使用同一个预设表的副本。

在 7 月 15 日，曼迪的访问将到期，弗雷德将再次成为这个数据集的唯一用户，如图 9-23 所示。

图 9-23。第二个用户的访问权过期后，再次只有一个用户可以访问数据集。

弗雷德将继续使用这个数据集直到 8 月 4 日，数据集将继续更新，如图 9-24 所示。

图 9-24。只要还有任何用户使用它，数据集将继续更新。

然后，在 8 月 5 日，弗雷德的访问权将到期，这个数据集将没有用户。更新将停止，直到有新用户请求它，如图 9-25 所示，或者系统可能以较少频率（比如每月）继续更新它。

图 9-25。当没有更多用户使用数据集时，更新将停止。

如果一个新用户请求这个表格，它将更新到 8 月 5 日（更新停止时）和访问请求日期之间添加的任何数据——例如，8 月 15 日的情况。这样，8 月 15 日的文件夹将包含 8 月 5 日到 15 日之间所有的更新，如图 9-26 所示。

图 9-26。一旦有新用户使用它，数据集将被更新。

有时，将每天的批处理数据保存在以该日期命名的单独文件夹中是有益的。这有助于工具如 Hive（Hadoop 上的 SQL）决定针对哪些分区执行查询。在这种情况下，数据仍然可以在 8 月 15 日全部加载，但每天的变更会在单独的分区中创建，例如图 9-27 所示。尽管所有变更都是在 8 月 15 日提取的，每天的变更（例如基于更改时间戳）都存储在单独的文件夹中—8 月 6 日的变更存放在20180806文件夹中，8 月 7 日的变更存放在20180807文件夹中，依此类推。

图 9-27. 每天的更新可以保存在单独的分区中

结论

访问控制是数据湖中最关键的方面之一，必须做好。通过结合自动化、按需自助授权技术和积极的敏感数据管理，您的组织可以有效和高效地管理对庞大且快速变化的数据集的访问。

第十章：行业特定视角

本章包含来自各行业数据专家的关于数据湖实施的一系列文章。其中一篇文章由于作者未能获得披露其从属关系的许可而匿名发布，其他文章则完全归属于作者。虽然本书的其余部分侧重于通过与从业者的多次讨论获得的最佳实践和成功数据湖的特征，但本章侧重于行业特定内容。每篇文章由不同的行业专家撰写，并回答以下一些或所有问题：

为什么？

这些文章概述了推动不同行业采用大数据湖的主要倡议。

为什么现在？

什么改变了以实现这些解决方案？Hadoop、大数据、数据科学或数据湖如何改变了方程式？

接下来会发生什么？

作者认为行业在采用大数据和分析方面的未来如何？数据将如何改变他们的行业？

首先，你将听到负责 FICO 高级分析和在伯克利教授数据科学的 Jari Koister 的发言。Jari 的文章着重于提升业务成果。接下来是 Simeon Schwartz 的文章，专注于在 Schwab 和其他大型金融服务组织中利用大数据进行治理和合规性。

接下来，你将听到一位大型保险公司的大数据负责人的发言，然后是由 Brett Goldstein 撰写的关于智能城市的文章，他曾领导芝加哥市和芝加哥警察局的分析工作。

最后，你将听到旧金山大学的首席信息官 Opinder Bawa 的发言，他曾担任加州大学旧金山分校医学院和波士顿市医院首席信息官，在医学研究中运用分析。

还有许多其他例子和故事可以分享，但我觉得这些内容已经较为全面地展示了可能的情况。

金融服务中的大数据

Jari Koister目前担任 FICO 决策管理套件（DMS）的副总裁，这是一个面向金融及其他行业的多种分析和优化驱动解决方案的平台。Jari 领导产品战略、规划、执行和研究；他还负责先进分析和人工智能研究，并将其整合到 DMS 中。旨在提供能够使 FICO 及其客户的解决方案成功且竞争力不断增强的能力。此前，Jari 曾在 Salesforce.com、Twitter 和 Oracle 领导产品和工程团队，还曾在 Ericsson 和 HP Laboratories 领导研究团队。Jari 在瑞典皇家理工学院获得分布式系统博士学位，并担任加州大学伯克利分校数据科学项目的教授。

消费者、数字化和数据正在改变我们所知的金融业

一波颠覆正在冲击金融和银行业。消费者期望新的互动方式，数字银行正在颠覆许多子领域，面临更多欺诈风险暴露，也承受着在传统市场之外扩展业务的压力……变革的列表还在继续。同时，风险管理正成为金融机构日益关注的核心和战略性领域，并且出于保护消费者免受不慎决策和暴露的原因，监管水平也在增加。

消费者的期望在前所未有的情况下变得更多样化、选择更多，而且他们的声音也比以往更清晰。他们比过去更加信息化，并且更信任他们的同龄人。消费者可以更容易地找到并获得新产品，例如信用卡。他们通过多个渠道与银行进行互动，并且无论使用哪个渠道，他们都期望广泛的功能和及时的答复。他们周游世界，并期望他们的银行跟上并支持他们，而不是设置障碍。他们了解情况并比较产品和服务。像千禧一代和所谓的“未开发银行”等客户细分并不依附于大银行，而是开放于新的选择。

与此同时，银行正在数字化。用户期望能够在大部分业务中在线完成，而无需进入实体分支机构。话虽如此，他们期望使用数字媒体的响应速度能够与直接与银行服务人员工作相匹配或超越。他们希望能够在线申请信用和交易股票，存款支票，并且提取或转移资金。顾客希望体验简单而没有摩擦的服务，否则他们会把业务带到其他地方去。数字化还改变了银行的营销方式和与消费者的联系方式。数字营销和口碑变得更加关键，而实体分支的角色则相对较小。

新的用户期望和数字银行的浪潮要求银行重新思考如何提供服务。这也迫使他们重新思考如何减少开销并消除消费者互动中的摩擦。这些变化也使银行面临更多欺诈的机会，这既因服务的性质，也因这些服务如何向客户提供。例如，在线贷款批准需要新的客户识别方式。需要视网膜扫描、在线指纹或图像来确保在线贷款接收者确实是他们声称的人。

访问银行服务，甚至它们的提供，也受到新技术的影响，例如移动支付、区块链以及像印度这样快速发展国家的国家倡议。印度旨在减少欺诈的倡议包括称为Aadhaar 卡的普遍国家身份证和用于构建金融服务的 IndiaStack API。

新的和扩展的数据集允许更高效地分析市场和客户的特征和需求。这种分析使银行能够在保持自身风险水平低的同时，为消费者提供更具吸引力的提案。

竞争新业务还促使金融服务向先前未服务的消费者和人口群体提出提案。然而，他们可能缺少传统上认为必要的背景数据来吸引客户。在历史上，那些没有提供“正确”数据的人，比如计算信用评分的数据，通常会被认为是不可接受的信贷或贷款风险。有了新的数据来源和新的预测模型，银行可以计算出新的评分，从而使他们能够向这些客户提供可接受风险和盈利的提案。

这些例子说明了为什么风险分析对金融机构日益重要和战略性。它们对于管理与投资组合管理、信用风险、货币风险、运营风险等相关的风险至关重要。金融机构通过使用新的风险评估模型和新的数据来源更积极地管理风险。通过创建新模型，他们可以增加收入、降低成本、减少风险并提高效率。

银行和金融领域的这一新时代需要更广泛和更好的数据来源，并由大数据和分析时代的新数据来源推动。它推动数据孤岛的打破和数据访问在组织内部的民主化。数据湖的概念在这一进化过程中起着核心作用，数据湖的价值与组织将数据和洞察力转化为更好决策的能力密切相关。

拯救银行

上述变化带来了对传统银行的许多威胁，但也为新兴者和颠覆者带来了机会。数字银行业务既有外部影响，也有内部影响，正如 图 10-1 所示。

图 10-1. 数字文化的两面

外部因素要求消费者体验进行 drast 的更改。客户生命周期的所有方面都必须越来越以客户为中心，包括客户获取、入职和保留。银行必须保持对外部因素的开放态度，设计并执行灵活的策略，以迅速适应技术和客户需求的变化。

这些外部因素反过来驱动了内部需求。改变银行的外部视图需要一个依赖于强大、可扩展架构和复杂技术的数据智能创新文化。这需要更敏捷和适应性的方法来开发概念、产品和服务。随着市场的变化，银行必须变化，新产品必须在几个月或几个季度内推出，而不是几年内。

随着与客户的互动变化，分行的角色也发生变化。在极端情况下，分行因客户使用数字设备进行互动而变得过时，例如通过其手机摄像头扫描存款支票。在其他模式中，分行仍然对营销、支持和高端服务（如私人银行）非常重要。

当然，数据在启用内部因素并最终导致外部因素变化中起着至关重要的作用。数据湖是实现许多所需变化的机制，因此数据湖可以极大地影响银行的业务战略。

通过自动化流程并利用数据为客户确定最佳优惠，数字银行可以将运营成本降低一个数量级，与传统银行相比。这种显著的成本降低可以使机构能够以盈利的方式向传统上利润较少的客户推出新产品，并提高客户满意度。它们还可以将较低的成本转化为现有客户的新利益，有助于保留这些客户。另一种方法是将新的更加细致的风险模型应用于投资，以获取健康的利润。无论采用哪种策略，数据在识别、评估和实施这些产品中发挥着重要作用。

数据湖策略的广度可以有所不同。它可以仅限于少数核心数据集，并逐渐增长，也可以从一开始就涉及广泛的数据集成。一些金融机构可能在方法上更为保守，而另一些则包含能够获取的所有数据。有些可能以更谨慎、分阶段和慎重的方式引入变化，而另一些则大胆地颠覆组织运作方式。不同步伐和策略的原因可能从快速改变文化的困难到希望在利用新机会的同时保护当前核心业务。一些金融机构，例如桑坦德银行及其全资在线 Openbank 子公司，对其现有业务采取渐进的方法，但通过新成立的部门实施颠覆性方法。

图 10-2 展示了数字转型的各个阶段。

图 10-2. 数字战略和执行成熟度

与此同时，欺诈案件数量和复杂程度都在增加。尽管由于技术进步如芯片卡的普及，一般交易欺诈有所减少，但其他类型的欺诈正在上升。随着在线商务的普及，身份欺诈也在增长。随着新的资金转移方式的推出，反洗钱运动也受到了更多关注。新型欺诈案件以快速的速度不断涌现，这要求我们迅速开发新的欺诈检测和预防方法。更多的数据和新技术需要在这些方法的开发中加以利用。

同时，欺诈检测需要对消费者更加友好。在识别信用卡或身份欺诈时出现的误报对良好的客户体验极为不利。谁愿意因为信用卡被拒绝而无法支付刚刚在外国享用的餐点呢？同样地，数字银行因怀疑身份欺诈而拒绝客户进行操作可能会导致非常不好的公众舆论。

数据的使用存在着不当使用的风险，可能是有意或完全无意的，因为数据中的错误或失误。如 GDPR 等新法规旨在保护消费者。尽管金融机构希望利用手头的数据优化产品并做出自动化决策，但他们也需要遵守这些新法规。

核心问题在于，向数字银行的转变导致了新类型的服务的出现，对提供金融服务的银行或任何机构来说，这既是威胁也是机遇。数据对于高效地创建和管理金融产品的各个方面至关重要，包括数字营销、风险分析、产品风险优化、高效的支付收款以及欺诈检测。

新数据带来的新机会

新数据的可用性使银行能够创建更加符合客户需求和风险管理角度的新产品。基于这些数据推动的复杂解决方案权衡多个属性，如风险、客户需求、盈利能力和市场份额。这是一种双赢，因为消费者可以获得有价值的服务，而银行也拥有新的收入来源。

通过采用新的身份识别和欺诈处理方式，银行可以提供数字化的贷款和信用申请方式，提高了速度和客户满意度。客户可以在不需要访问分行的情况下完成在线申请。符合正确财务标准的申请通常在几分钟内得到批准，资金也经常可以即时存入账户。

信用评分是确定消费者是否会偿还其债务的首选方法。历史上，信用评分计算需要支付历史记录、未偿债务清单、最近信用查询历史等信息。银行工作人员会彻底分析结果，以确定风险和盈利水平。对于消费者具有特定信用分数（如 550 或 710）的风险已经被充分理解。但现在，银行希望将评分应用于缺乏传统信用评分足够数据的更广泛人群。这被称为“金融包容性问题”，不仅是发展中国家的问题；在美国也存在。正如图 10-3 所示，美国 3.25 亿人口中有 5500 万人无法评分，面临被认为不可银行化的障碍。他们最终为基本的日常金融服务（如兑现支票或使用信用购买大件消费品）支付过高的费用。

图 10-3. 可银行化人口分类

在印度等其他国家，无法使用传统方法评估信用价值的人口比例甚至更大。美国的比例大约为 17%。在印度，大约有 19%，即 2.5 亿人口无法评分。印度的另一个大部分人口，约 7 亿人，也被视为非信用申请者。前面提到的阿达尔（Aadhaar）旨在使更大一部分人口参与金融系统。为了能够向这些大规模人群提供信贷，银行正在考虑使用额外的数据来源，如账单支付数据，以及社交网络、手机数据、零售购买、教育和公共记录等非金融数据，来确定信用价值。这些计算需要综合和分析多种数据来源，最终通过消费者交付机制来实现数据分析结果的操作化。在收集、集中存储和使用这些各种数据中，还存在重大的隐私问题。

更多且更多样化的数据使分析师能够显著改进这些风险模型。总的来说，许多改进和策略取决于许多数据源的可用性和使用情况，其中一些可能是新的，而其他则是以前未使用或未充分使用的。数据湖在允许扩展用于向全球更广泛人群提供金融服务的数据的任何架构中都是重要组成部分。

风险分析的一些主要好处包括：¹

• 通过引入风险差异化的优惠和有针对性的活动，提高利息收入。这些措施通常可以增加 5-15%的收入。

• 降低销售和运营成本，因为从风险和政策的角度来看，预筛选更加高效。这可能会增加生产力 15–50%。

• 通过风险聚类和早期预警系统减少风险。这些系统通常会减少贷款损失 10–30%。

• 通过模型的更好校准和精细化来提高资本效率。这通常会减少风险加权资产 10–15%。

金融机构希望更多地了解客户在他们提供的所有服务以及更广泛领域中的活动。他们希望像行业观察者所称的360 度客户视图（图 10-4）。这可能包括财务交易、财务状况、购买、电子邮件、支持电话、社交媒体发布以及任何其他被跟踪的互动。通过更全面地了解客户活动，公司可以提供更好的营销、更好的服务和更好的客户体验。这种视图自然涉及多个数据源，并要求银行和金融机构打破当前存在的数据孤岛。数据湖是实现这种数据共享的技术基础，同时有效管理数据并遵守适用的法规。

图 10-4. 客户 360 度视图

然而，这些服务可能容易受到新类型的申请欺诈的攻击。数据和算法的可用性使银行能够部署利用人脸识别、指纹甚至语音识别的欺诈技术。如果没有新的反欺诈措施，欺诈水平可能会抵消这些服务所带来的收入。

利用数据湖的关键流程

我已经概述了银行和金融服务在节省成本和应对新机遇方面的一些关键方向、机会和风险。这两者背后有一些共同主题。它们都依赖于数据的可用性和复杂使用，以及金融机构传统上未曾使用的数据来源。尽管银行在高效利用各个数据孤岛的数据方面表现出色，但现在它们需要将数据整合起来，利用多个数据源高效地实现他们的目标。许多银行实际上正在创建数据湖，或者至少在通过创建大量数据池的道路上向数据湖迈进。

许多金融机构拥有大量孤立的数据源。合并这些孤立部门是一项艰巨的任务，可能需要大量投资却没有相应的好处。金融行业非常熟悉“决策”概念。决策决定了客户的结果，如信用额度增加、贷款批准和收款行动。决策通常对收入和风险产生重大影响。但它们可以通过 A/B 测试、跟踪和治理进行优化。挑战在于通过处理数据湖中的分散数据来高效地做出决策。

银行对此采取了许多不同的方法。一些明确创建数据湖，目的是处理数据问题的复杂性。其他人则有机地发展数据水坑，打算在以后某个时刻将其组织成一个湖。最后，有些人认识到他们需要数据，但可能没有明确的战略来从孤立的数据集合转变为对底线产生影响的更好决策。

我建议有三个主要组成部分可以将数据湖从无法使用的状态转变为可进行决策的状态。这个提议并不具有革命性，而是从一组无组织、常常理解不清楚的数据转变为被编目、整合和准备好供数据科学、数据处理，最终实现操作决策的状态。数据科学和数据处理有助于在迭代循环中准备数据以供决策使用。关键在于编目和决策开发的整合，使数据易于访问、识别、检测和追溯。

第 10-5 图 强调了这种数据湖解决方案的中心架构。显然，组织需要从所有正在使用的众多数据源中摄取和检索数据。我认为成功准备数据以支持决策的三个必要组成部分是数据清单和编目、实体解析和模糊匹配，以及分析和建模。

第 10-5 图。数字银行中分析和决策的数据湖支撑

数据清单和编目

这第一步确定数据，自动发现架构，匹配字段，确定和追踪血统等。它提供了数据湖中创建的所有数据的概述。它还帮助组织和理解数据，以便可以有效地发现和处理。

在从数据湖中提取价值的重要步骤之一是连接不同的数据源。然而，并不是所有数据集都有一个共同的键可以进行连接。相反，很可能没有这样的键，我们需要找到其他方法来解析实体（在所有数据源中识别相同的实体，例如同一客户）。这就是下一个流程的任务：实体解析和模糊匹配。

实体解析和模糊匹配

让我们考虑一个没有共同数据记录键的三个数据源的示例。每个数据源记录了一些用户行为。一个可能是网站活动，另一个是电子邮件活动，第三个是销售点交易。用户可能在每个数据源中使用不同的身份标识方式。他们甚至可能有不同的地址或拼写错误的地址，使用昵称或故意混淆的名称，提供不同的电子邮件地址等等。

图 10-6 描述了这些数据来源作为三个分开的事件时间轴，这些事件可能在某些时刻导致购买。我们的目标是通过识别哪些事件属于同一消费者，即使数据不同、不完整或错误，来创建一个合并的时间轴。这个合并的时间轴将使我们能够创建更精确的预测模型，因为我们有更多相关的数据可以帮助改进模型。

图 10-6。从不同多渠道数据到 360 度视图

实体解析和模糊匹配可以在数据来源之间执行这种映射。我认为这种映射对于从数据湖中提取价值至关重要。

分析和建模

一个强大的分析工作台，具备数据整理、探索结构化和非结构化数据、在大数据集上查询以及机器学习的能力，当然是充分利用数据湖的关键组成部分。最终，直到将数据洞察转化为银行客户的运营决策之前，您才能真正提取出实际价值。建模和实施决策的架构超出了本文的范围，但在这里概述的基础是金融机构为运营决策做好准备的一种方式。

金融服务中数据湖的附加值

西蒙·施瓦茨是 OMS 全国保险的数据与分析总监，前查尔斯·施瓦布分布式数据服务的管理董事，他在关系型、半结构化（NoSQL）和大数据产品领域支持数据和数据库技术。在加入施瓦布之前，西蒙曾担任 Centerpost Communication 的运营副总裁，并开展数据管理解决方案咨询业务。

金融行业可以通过数据湖在多种方式上改善其服务和收益，同时应对当前时代的诸多挑战。合规性、营销和效率都可以通过数据湖迈向新的台阶。

合规性是受益于数据湖自动化和标准化的最显而易见的领域。金融服务领域的公司根据监管要求和产品、业务线数量频繁和定期进行审计。合规性和风险管理需要大规模的企业范围内努力。需要一个跨越所有现有技术的企业数据资产的虚拟数据湖来支持这些倡议。

合规性的一个相关示例是访问验明和认证，这是一个常见的流程，用于记录系统和数据不存在未经授权的访问，并跟踪所有现有和变更的访问授权。为确保所有访问确实经过授权，并且公司具有这些授权的验证记录，相关方必须审查和签署每一种凭据类型、技术和供应商提供的每一片现有托管数据，定期进行这些签署（验明过程）。每个应用程序供应商可能针对其产品提供专门的点解决方案，平台供应商可能针对多应用程序提供技术平台堆栈背后的解决方案，因此单一的企业范围方法需要对所有信息进行统一视图——基本上是提供一致方法来收集和比较服务器、数据资产类型和访问级别信息的虚拟数据湖。尽管这是一项庞大的工作，但许多因素正在增加其可行性，其中包括：

• 廉价的计算能力。

• 通过虚拟化、仪器化和自动化，现代基础设施的部署速度和便利性。

• 软件开发速度的巨大提升。

一旦数据湖技术就位，并结合现代分析的进步，金融服务行业将获得许多其他好处。这些好处包括能够快速创建、使用和管理基于企业信息的快速洞察解决方案。数据湖还能更好地跟踪信息使用情况，例如资源利用监督和技术资产管理。

在营销方面，数据湖可能会从包含有关客户及其与公司产品互动的重要见解（内部和外部）中受益，以理解和影响客户行为。例如，在网站上，营销可以衡量客户进行交易的时间、原因和位置（在网站和页面上），他们可以追踪交易前的活动、点击次数、中断交易的百分比、客户在做出决策点前走过的路径、浏览器内的活动等。另一个例子可能是完成新账户申请：可以调查潜在客户中止申请的地点、原因和时间长短，以及他们何时以及以何种速率退出流程。这可以帮助公司改善申请体验，增加收入，并减少在获取可能因账户创建过程中流失的潜在客户所需的直接成本。技术体验的一个例子涉及决定何时“超时”客户：等待时间过长可能会影响安全性，而超时时间过短可能会强迫用户重新登录，从而产生糟糕的用户体验。通过对网站进行仪器化和分析用户行为，公司可以使用数据而非猜测来回答这些及其他问题，允许体验定制化，看到结果，并对运营结果和客户满意度产生重大影响。

简而言之，随着企业变得越来越被仪器化、跟踪和测量，数据湖正在使得在业务、IT 和合规性方面实现更高效率和效果成为可能。

保险业中的数据湖

下一篇文章的作者是一家主要保险公司的大数据远见者。他们分享了他们的观点，但未能透露其从属关系。

任何保险组织的基础核心是对风险的评估。分析和核保原则是在向客户签发保单和确保流动性以履行理赔时基于对风险的评估。这种评估对于保险政策请求者同样有益。如果个人能更好地评估其风险暴露，他们就能在需要的保障类型上做出正确的决策。

对于保险公司，效率通常是指根据个人的财务背景建议适当的保额和可负担的保费，并及时签发保单的能力。我没有提到客户服务，因为我认为它是任何企业的支柱：无论是销售咖啡还是寿险保单，如果客户对您提供的服务不满意，您就无法在今天竞争激烈的营销环境中生存下去。

数十年来，核保过程由于数字化格式中缺乏有价值的多样化数据点以及缺乏廉价的分析平台而发展缓慢。在过去五年中，随着大数据技术在廉价商品硬件上的出现，这种情况发生了显著变化。一些行业参与者正好奇地探索使用先进的预测建模技术重新编写核保规则的新方法，这些技术具备分析大量不同数据元素的能力。这一最新技术组合有助于提高效率、降低成本、为理赔管理提供更好的框架，并检测欺诈行为。这些技术通过向消费者提供个性化产品来推动产品创新。

另一项正在追赶并被用作战略变革载体的革命性技术是物联网（IoT），一些保险公司正在采纳并看到其价值。大数据分析快速采纳的一个关键因素是它与连接设备的直接联系，收集数据点并将其转化为可操作的分析信息。

例如，物联网可以使保险提供商及被保人在健康领域受益。通过监测个人的健康、生命体征和整体健康状况，设备可以满足个人对健康相关指标的需求，同时为保险公司提供宝贵的数据，以更好地分析发病率和死亡率。这为开发针对各种风险类别的创新产品提供了机会，这些产品在过去可能不在考虑范围之内。

尽管这些发展令人兴奋，但我个人认为技术对行业的影响并非是灾难性的；相反，它总是产生涟漪效应。再次以健康为例。在数字化医疗和生物测定记录上，美国政府投入了数十亿美元的补贴。像精准医学计划这样的项目旨在建立一个统一的全球平台，公共和私营公司可以安全高效地共享客户的医疗记录。在不久的将来，这本身将有助于弥合消费者、医疗行业和保险公司之间的鸿沟。更广泛的影响将是为无保险和超出探索风险类别的人引入产品和服务。

这里的可能性无限，看到这种综合数据集为整个城市、社区、州、国家，甚至整个大陆提供的趋势将会是令人惊叹的，所有这些都是为了关注人类福祉。

智慧城市

布雷特·戈尔德斯坦是 Ekistic Ventures 的联合创始人兼管理合伙人，这是一群致力于解决城市问题的人，他们正在培育一系列颠覆性公司，为关键的城市问题提供新解决方案。他曾担任芝加哥市的首席数据官（CDO）和首席信息官（CIO），之前是一名警察，并在芝加哥警察局担任分析主管。2013 年，布雷特策划并编辑了《超越透明度：开放数据与市民创新的未来》（Code for America 出版），这是一部关于开放数据潜力的选集，旨在重塑居民与政府之间的关系。除了在 Ekistic Ventures 的工作外，布雷特还担任芝加哥大学城市科学的高级研究员和特别顾问。他为全球各地的政府、大学和主要公司提供建议，指导如何利用数据更好地理解城市生态系统。

多年来，我们一直听说大数据有潜力引领“智慧城市”的时代，其中技术帮助提高生活质量、减少犯罪并优化支出和资源。然而，建设智慧城市的第一步需要我们将数据汇集到数据湖中，并为预测分析优化这些信息。

作为芝加哥市的首席数据官（CDO），后来是首席信息官（CIO），我推动了将数据从成千上万的数据孤岛中“解放”出来，并整合到一个数据湖中的工作。传统上，数据被备份到磁带上，并最终被删除。通过使用支持灵活模式架构的廉价大数据技术——特别是我们的情况下，是 MongoDB 数据存储——城市能够轻松地从所有不同的系统中加载原始数据。然后，它扫描数据集以获取地理空间信息并创建位置索引。目标是了解数据位置，并记录元数据，以便在适当的项目出现时可以使用数据。

将来自不同系统的数据加载到一个系统中带来了各种挑战，从获取数据访问权限到映射不同的坐标系统。大多数城市问题是超地方性的，因此创建位置索引非常关键，使数据湖能够回答诸如：

• 警车在哪里？

• 在一个社区中有哪些坑洞？

• 一个问题建筑的确切位置是什么？

虽然知道事物的位置至关重要，但数据湖还可以用于预测分析，例如预测哪些地方最有可能发生骚乱，哪些垃圾箱需要维修，以及街道多久会出现坑洞。芝加哥数据湖取得最大胜利的时刻是在其被用来为北约行动创建情境感知平台 WindyGrid 时——这是芝加哥历史上最重要的事件之一。

城市面临的问题并不新鲜，但在当前的大数据技术世代之前，实际解决方案难以得到。Excel 是一个很好的工具，但无法扩展以处理实时流向今天智能城市的海量信息。关系系统可以扩展到足够的规模，但从不同系统中结合和协调数据过于困难和昂贵。有了提供廉价存储和灵活架构的大数据技术，现在可以跨多个不同系统、多种不同格式结合数据，并投资于提取、协调和清理仅针对特定项目所需的部分。大数据的可扩展性使得可以实施数十亿 GPS 事件的物联网项目，而能够以经济的方式存储和处理大量数据对于预算紧张的城市来说是一个重大进展。例如，能够重复使用旧机器并利用不同硬件廉价构建 Hadoop 集群是一个重要的节省成本的进步。

当我们仍在解决数据存储和管理问题的同时，我们开始从被动的反应式分析和响应转向积极的预测性分析和响应。预防性维护就是一个例子：我们可以在路面出现坑洼之前修复道路，而不是等到坑洼形成后再进行修复。随着传感器数据的快速涌入——关于当地气候、空气污染、服务交付等等——智能城市正在变成现实，并且有效地利用这些数据需要超地域的数据和决策方法。通过从更智能的数据架构开始，特别是数据湖，我们可以进一步进行复杂的分析和机器学习。

同时，城市必须尊重透明度和可解释性，避免黑箱算法的诱惑。重要的是不仅仅信任数据驱动的结果，而是理解它们背后的原因。只有这样，我们才能进入真正智能城市的时代。

医疗大数据

Opinder Bawa 是旧金山大学（USF）的信息技术和首席信息官，负责机构范围内的技术部署和创新。之前，他曾担任加州大学旧金山分校（UCSF）的首席技术官，以及 UCSF 医学院的首席信息官。在这些角色中，他在研究、教育和患者护理的创新技术解决方案规划和交付中发挥了领导作用。Opinder 还曾担任波士顿医学中心的首席技术官和 SCO 集团的高级副总裁，领导其全球软件产品线和客户服务。他在纽约市立大学获得了计算机科学学士学位，并在凤凰城大学获得了工商管理硕士学位。

任何行业的转型过程通常需要 30 至 50 年才能完成，生命科学行业也不例外。每一个转型时期都由催化剂启动。2010 年《患者保护和平价医疗法案》是生命科学行业最近一次转型的催化剂。正如过去半个世纪多次证明的那样，技术将继续作为促使行业转型的核心，我们国家的医疗保健系统也将如此。

当今和未来医疗保健中可能是最重要的一个方面是识别有前景的新疗法、验证治疗方案以及为不太有前途的药物尽快终止开发决策的临床试验。随着生命科学行业接近这一变革的第二个十年，并审视即将到来的格局，明显的是，成功进行未来临床试验及其结果将需要颠覆行业或大幅提高其供应链效率的技术，涉及从识别和招募（及留住）患者到数据收集、核心分析和早期干预潜在对象的各个领域。

尖端数据分析解决方案使生命科学公司能够自动化临床试验供应链的最关键部分，从而以前难以想象的方式实现重要结果。数据分析能够创建精密调校的引擎，推动患者产生的数据的收集、整理、分析和报告。

将数据收集和分析置于这种变革体验的核心并不过分。如果你回顾一下 USF 的 William Bosl 博士的工作，他能够在仅三个月大的婴儿中识别出自闭症，或者研究如何在实时情况下识别足球场上的球员脑震荡，你将能够一窥数据和分析改变世界的潜力。由 UCSF 的 Jeff Olgin 博士领导的另一项研究反映了这一潜力，该研究旨在通过招募史上前所未有的 10 万患者，使用最先进的技术进行数据和分析，显著改进著名的 Framingham 心脏研究。

随着生命科学行业进入当前技术转型的第二阶段，力求增长和成功的领先临床试验公司将进一步接纳数据分析行业领袖提供的临床试验供应链解决方案。这些解决方案将开始聚焦于高效临床试验带来的早期干预，最终改变整体医疗保健实践方式。

¹ 另见 Rajdeep Dash 等人的《风险分析进入高峰期》，McKinsey & Company，2017 年 6 月。