详情
本书由知名的计算机科学家Bill Inmon撰写，是一本介绍数据湖的书。本书讲述了如何构建一个有用的数据湖，非常适合数据科学家、数据分析师来参考。通过阅读本书，读者可以解决很多工作当中遇到的大数据问题，并且了解数据湖的使用和架构。
书名：数据湖架构
ISBN：978-7-115-45173-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Bill Inmon
译 吴文磊
责任编辑 陈冀康
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Simplified Chinese translation copyright ©2017 by Posts and Telecommunications Press ALL RIGHTS RESERVED
Data Lake Architecture by Bill Inmon ISBN 9781634621175
Copyright © 2016 by Technics Publications,LLC
本书中文简体版由Technics Publications授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
随着大数据的蓬勃发展，不少机构开始将源源不断的数据流导入到一个叫“数据湖”的设备中去。
本书是“数据仓库”之父撰写的最新著作，是帮助读者认识数据湖架构，并把数据湖打造成公司资产的指导手册。全书共15章，分别涉及数据湖简介、数据池据湖内部结构、数据池及其结构、各种类型的数据池等技术话题，目的在于讲解如何构建有用的数据湖，以便数据科学家和数据分析师能够解决商业挑战并找出新的商业机会。
本书适合数据管理者、学生、系统开发人员、架构师、程序员以及最终用户阅读。
在错误的方向上，我们耗费了数年时间，花费了上百万美元，但是，我们是不是可以省出一点儿时间和金钱用到正确的方向上来呢？
如今，众多公司正在疯狂地建设数据湖泊——一种大数据狂热的副产品。有朝一日，这些公司幡然醒悟，发现他们根本不能从数据湖中攫取出任何有用的东西。即便真的从数据湖中找到了一丁点儿有用的信息，起码也要经历呕心沥血的努力。
他们花费了巨额的资金和大量人年（man years）的努力，却只换回了昂贵的累赘。
终有一天，这些企业会惊觉于他们所建造的不过是一个“单向”的数据湖。数据被引入数据湖，却产生不了任何东西。在这种情况下，数据湖不会比垃圾场好到哪儿去。
这本书就是写给那些想要建造数据湖，并期望能够从中获得价值的机构。数据湖中当然有业务价值，但前提是建造得法。如果你正打算建造一个数据湖，那么你最好把它建造成公司的一项重要资产，而不是累赘。
本书探究了为什么众多公司在从他们的数据湖中获取数据时会面临如此艰难的困境。关于这个重要问题有数种答案。其中一个原因是，数据被不加区别地一股脑地打包丢入数据湖中。第二个原因是数据没有被整合起来。第三个原因是数据是以文本化的形式保存的，而你没办法轻易地分析文本数据。
本书建议要以高层（high level）的视角来组织数据，整合数据，“调校”数据，其目的就是使调整后的数据能够成为用于分析和处理的基石。数据湖当然可以成为公司的良性资产，但前提是在构建数据湖时要足够谨慎，并深谋远虑。
数据湖需要被划分成几个被称为数据池（data pond）部分，它们是：
在创建之后，数据池需要经历调整过程，使数据容易访问，以便进一步加以利用。举例来说，模拟信号数据池需要对数据进行缩减（reduction）和压缩。应用程序数据池需要让数据经历经典的ETL整合。文本数据池则需要对文本进行消歧，以便使文本可以规整成一致的数据库结构，这样，文本所在的语境就可以被识别出来。
一旦数据池中的数据经历过算法的调整，那么该数据池就可以作为基础，为分析和处理流程提供服务。一旦数据湖中的数据被区划成不同的数据池，并且数据在池中经历了调整，那么这些数据池就会成为公司的资产，而不是负累。此外，当数据走完了它在数据池中的生命周期，它就会被移入归档数据池。
这本书是写给管理者、学生、系统开发人员、架构师、程序员以及最终用户的，并希望能成为那些想把数据湖打造成公司资产而非负担的机构的指导手册。
打孔卡（punch card）被发明出来之后，磁带（tape）被发明出来，然后是磁盘存储（disk storage）和数据库管理系统（DBMS），紧跟着的是第4代编程语言（4GL）、“元数据”、软盘和移动计算。技术前进得如此之快，以至于我们甚至来不及记清楚它们的名字。很快，个人电脑和电子表单就会像西装和领带一样随处可见。
在这高速发展的几十年里，公司经历了从没有自动化到高度自动化的转变。但在转变过程中，存储却始终是一项制约因素。长久以来，在面对大量数据的时候，存储不是容量不够就是价格太高。这个瓶颈制约了既有系统的性能，并且对系统未来的可选方案产生了深刻的影响。
随后，大数据技术改变了世界。Hadoop分布式文件系统（HDFS）是大数据技术最好的代表。这个开源软件框架的设计初衷就是解决在分布计算集群中的存储和处理大量数据集的难题。大数据技术有效地解放了存储包括在价格和技术能力上的限制。更为重要的是，在大数据技术的帮助下，一个全新的世界正向我们敞开大门。
简单来说，大数据刷新了我们对数据的认识。激增的数据可以被大数据系统保存并分析，这不仅是一项工业界的革命，更是一次世界性的革命。MB、GB、TB……旧有的数据量单位在这个存储容量被解放了的新世界中已不再适用。图1.1描绘了大数据降临的场景。
图1.1 利用大数据创造无限机遇
随着大数据的蓬勃发展，不少机构开始将源源不断的数据流导入到一个叫做“数据湖”的设备中去。
把数据放进去是小菜一碟儿，然而，想从这浩瀚的知识海洋中拽出点什么有用的东西却极具挑战。一些机构开始向数据科学家们寻求帮助。于是，大量的经费被投入研发，然而，如同这些机构一样，大数据对于数据科学家们而言也是一个全新的领域。尽管投入高昂，但分析上难有突破，而误报和其他错误倒是时有发生。图1.2展示的是大数据催生了用广袤的数据湖泊来筛查数据。
图1.2 在数据湖中置入大数据
图1.3所展现的是在数据湖中，过去商业社会所崇尚的规模产生价值在数据湖中的失效。对于数据湖来说，数据确实在持续增长，却很难用财富堆积出其中的价值。
图1.3 醒来吧，我们没能在数据湖中找到任何东西
业务用户会对数据湖中池化（pooling）的信息感到一筹莫展的原因有很多。核心的问题在于，湖中的数据增长得越多，其分析难度也越大。任何规模可观的数据湖都常常会被人戏谑为“单向湖”，因为数据被不断地推进湖里，但分析报告却始终难产，或者数据被推入湖中之后仅被访问一次。图1.4描绘了“单向”数据湖。
图1.4 数据被推入“单向”数据湖，但什么也产出不了
这是一项昂贵且令人沮丧的悖论（Catch-22）。数据湖成长得越大，就越具有潜在的洞察能力，但对于机构而言，却越无用（useless）。如果没人去使用数据湖中的数据，那么数据湖对机构就毫无意义。然而，为了从数据湖中榨取出有用的信息，机构却在存储和雇佣专业人员上投入了大量资金。
那么问题来了，为什么数据湖会变成“单向”湖，对此，我们又能做些什么呢？大数据和数据湖中确实蕴含着巨大的潜力，但似乎没有人能从他们的投资中获得与其相当的回报。数据湖变成“单向”数据湖有很多原因。但追根溯源，这些问题都指向同一问题，也就是数据在一开始是如何被导入数据湖的：起初的目标就不是对数据做出什么规划。相反，数据湖仅仅被当作一个倾泻数据的垃圾。绝大部分精力都被投入在如何尽可能地从所有数据源头收集数据，而仅有少数工程师和公司思考了如何将数据湖投入未来的使用。图1.5展示的是“单向”数据湖除了当作数据的垃圾场之外，什么也干不了。
图1.5 把数据湖变成一个垃圾场
难道数据湖的归宿就是变成垃圾场吗？有什么办法能够让数据湖变成具有生产力和价值的地方吗？大数据的允诺难道只是各家厂商在风口上养的猪吗（bunch of hype）？确实，数据湖有潜力成为数据分析和处理的基石。然而，只要人们还是单纯地朝数据湖中倾倒数据，而几乎不为未来使用作出规划，那么数据湖就逃不开成为垃圾场的宿命。
如果数据被单纯地倒进数据湖会发生什么呢？让我们来把核心的问题一个一个整理出来。
第一个问题是，有用的数据对于分析师来说会变得难以发现，因为它们被掩藏在堆积如山的不相关信息后面。本来对企业有用的数据就屈指可数。更鉴于数据湖的储量巨大，在千人一面的数据世界里，这又增加了搜寻的难度。换句话说，有用的数据不会自己长脚从如深山一般的数据湖里走出来。
第二个相关的问题是，用来描述数据湖中的数据个体的元数据并没有被捕捉或存放在一个能被访问到的地方。在数据湖内，只有初始数据（raw data）被保留了下来。这让数据分析变得不可捉摸，因为分析师没法知道这些数据是从哪儿来的，也没法知道数据的具体意义是什么。为了让分析结果产生效果，机构需要能访问到准确的元数据信息，这样就能知道在湖中找到的数据的背景信息。
单向数据湖的第三个缺点是数据关系丢失了（或者从没被识别过）。原有的数据源（pool）非常巨大，以致重要的数据关系并没有被导入数据湖中。因为将数据关系导入数据湖被认为是一项太繁琐而难于处理的工作。
对于“单向”数据湖中的数据，这些麻烦仅仅是个开始。事实上，在有效利用数据湖的历程中，还会面临许多技术难题。图1.6展示的是数据湖中数据的一些局限性。
图1.6 在数据湖中用传统方法分析数据变得不可能
因为数据湖中的信息在设计时并没有考虑未来的访问和分析，这导致的后果是，机构很快就会发现这样的数据湖并不能支撑他们的业务，无论它多么庞大。
许多机构早就知道为了支持业务，数据必须以合理、易用，并且易于理解的方式组织起来。但是，由于数据被倾倒进数据湖的时候并没有考虑未来的使用，导致数据湖最终无法为业务注入有效的价值。
一旦数据湖变成了“单向”的数据湖，那么对于业务来说，唯一的优点就成了保存无用数据的廉价设备。而当数据湖仅以存放数据的低端形式出现时，就很难对机构当初的高额投入自圆其说了。
那么接下来，让我们来看一看如何解开这个困局。
数据湖蕴藏着巨大的潜力。从前未尝做过的分析，现在可以用它来进行处理。从政府机构到小企业，数据湖可以识别、分析甚至预测从未被注意到的各种重要的规律（pattern）。
需要做哪些准备工作才能把数据湖变成信息金矿呢？那些建造了各自数据湖的机构还需要思考些什么呢？数据需要经过哪些调整才能为未来所用？
通过谨慎地规划，数据湖确实可以变成信息金矿，那么，是什么让数据湖具备深邃的洞察的能力呢？是4个基础组件：元数据（metadata）、整合图谱（integration mapping）、语境（context）以及元过程（metaprocess）。
元数据（metadata）是数据湖中用来对数据进行描述的数据［与初始数据（raw data）相对］。它是基础的结构化信息，并且与每个数据集都有关联。例如，如果要记录一个网站的访问数、点击量以及参与度的情况，元数据就可以是包含来访设备的IP地址/地理位置信息的数据。典型的元数据的表现形式包括对记录、属性、键值、索引以及不同数据属性间关系的描述。除了以上提到的这些，元数据还有许多其他的表现形式。
元数据被分析师用来解密数据湖中的初始数据。或换言之，元数据是栖居于数据湖中的数据的基本轨迹（basic roadmap）。
若数据湖中只保留了初始数据，那么使用数据的分析师就如同被砍去一条腿。想象一下，要尝试搜索维基百科（Wikipedia），而里面所有的文章却连标题都没有。靠初始数据本身单打独斗，其实并不那么有用。若初始数据都恰当地用元数据打上了标签，并一起保存在数据湖中，那么，你的服务才能称之为有用的服务。
整合图谱（integration map）所描述的是一个应用程序中的数据是如何与另一个应用程序的数据产生关联，以及数据是以什么样的逻辑被组合到一起。尽管元数据如此重要，但它并不是数据湖中唯一的基础部分。考虑到数据湖中大部分的输入数据都是由应用程序产生的，而产生的形式不尽相同。如果你把许多不同的应用程序产生的数据注入数据湖中会发生什么？答案是，你在数据湖中创建了若干互不关联的“数据仓罐”（silo）。
不同的应用程序，通常由不同的编程语言所编写，在各自的数据仓罐中发送数据，无法与其他的仓罐沟通或“交谈”。即使是信息都被保存在同一个数据湖内，每一个仓罐的数据也都无法与其他仓罐的数据相整合，甚至无法被元数据合适地标记。
为了让数据湖中的数据合理，就需要创建一份“整合图谱”（integration map）。整合图谱是数据湖中的数据如何被整合的详细规范。它是解决数据仓罐之间相互隔绝问题的最佳方案。
图2.1表现了由于许多未被整合的应用程序数据被放置在数据湖中，许多数据仓罐就这样被创建出来。这些仓罐使读取数据和解释数据陷入困境。
图2.1 创建仓罐会导致数据的相互隔绝，并阻碍沟通
在数据湖中的另一个复杂的情况是脱离上下文语境的文本数据。假设文本“court”[1]出现，那么这个“court”究竟指的是网球场，还是法庭诉讼，还是男青年追求姑娘所做的努力，还是皇室周围的人们呢？当你单纯地看着“court”这个词，它的意思有可能是以上任意一种，甚至还可能有其他的意思。
脱离了上下文语境的文本是意义不明确的数据。事实上，在一些情况下，在语境不明晰的前提下保存文本是很危险的。如果你想把文本放入数据湖，那么你必须把文本所在的语境也放在其中，或者至少要提供找到文本语境的方法。文本语境对数据湖中的数据来说是一项必要的组成部分，缺乏语境的文本数据是不明晰的，如图2.2所示。
图2.2 缺乏语境的文本数据
元过程（metaprocess）信息是关于数据被如何处理，或者数据湖中的信息将会被如何处理的信息。数据何时产生？数据何处产生？数据产生多少？数据由谁产生？所选数据是如何被置入数据湖的？当进入数据湖后，数据是否被进一步处理过？当数据分析师在数据湖中提取和分析数据时，以上所有这些形式的元过程信息（metaprocessing）都是非常有用的。
最重要的一点是，这些特性需要在刚开始的时候就被抓取。通常，当初始数据被导入数据湖之后再考虑这加入这些基本成分就太迟了。
然而，一旦这些成分被加入了数据湖，那么数据湖就有了成为信息金矿的潜质。图2.3描绘了通过这些粗箭头，数据湖变成了公司的强大并且富有成效的资源。
图2.3 从垃圾场变成信息金矿
把数据湖转化成企业良性资产的另一个重要性在于惠及更多不同的用户群体。
想象一下，数据湖成为公司的一项有用资源所经历的变化。图2.4展示的是尚未改造的数据湖与完成改造的数据湖。
图2.4 从未经改造的数据湖到改造完成的数据湖
如果只有一小拨儿专家才能玩转数据湖里面的数据，那这就说明数据湖还处于数据湖初级阶段。而这一小拨儿专家通常被人们称作数据科学家。数据科学家们具备以下特点：
少，很难找到；
贵，雇佣昂贵；
忙，就是请来了，你也约不到时间。
数据科学家圈子小并没有什么问题。但是小到找到他们都很难就有问题了，而且雇佣成本居高，即便是找到了他们，而且雇佣了他们，但想要约他们的时间也是很困难的，这些特点使得他们成为了传奇。无论管理得有多好，只要数据湖只能被一小拨儿时间紧张、成本高昂的人所操作的时候，数据湖的企业价值就会受限。
现在来想一下，当数据湖被充分地整合，而且数据已具备通用性之后会发生什么。
图2.5表现的是数据湖只能被一小部分数据科学家所使用，与改造后可被大量商业用户所访问之间的差异。
图2.5 改造数据可以增加用户访问的便捷性
经过改造之后，数据湖能发挥价值的对象就会扩展到会计、经理、系统分析师、终端用户、财务团队、销售员工、市场及其他部门。通过整合与调整数据，数据湖还可以扩大服务的用户群体。同时，经过改造后，数据湖在公司中的价值也被极大地提升了。
数据湖的潜力巨大。但如果人们仅仅用来倾倒数据而对数据的使用不加考虑，那么这就会产生把数据湖变成垃圾场的危险。通过4项基础成分的帮助，数据湖可以转化为信息的金矿。
元数据（metadata）。元数据被分析师用来解密在数据湖中发现的初始数据。元数据是栖息在数据湖中的数据的基本轨迹图。
整合图谱（integration mapping）。整合图谱是数据湖中的数据如何被整合的详细规范。它阐述了如何解决仓罐数据的隔绝性问题。
语境（context）。如果你想把文本放入数据湖，那么你必须把文本语境也放置在其中，或者至少要提供找到文本语境的方法。
元过程（metaprocess）。元过程标签是关于数据湖中的数据处理的信息。
[1] court的含义有很多，如法庭、王、献殷勤等。
