作者：[美] Bill Inmon 恩门
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
数据湖架构试读：
前言
在错误的方向上，我们耗费了数年时间，花费了上百万美元，但是，我们是不是可以省出一点儿时间和金钱用到正确的方向上来呢？
如今，众多公司正在疯狂地建设数据湖泊——一种大数据狂热的副产品。有朝一日，这些公司幡然醒悟，发现他们根本不能从数据湖中攫取出任何有用的东西。即便真的从数据湖中找到了一丁点儿有用的信息，起码也要经历呕心沥血的努力。
他们花费了巨额的资金和大量人年（man years）的努力，却只换回了昂贵的累赘。
终有一天，这些企业会惊觉于他们所建造的不过是一个“单向”的数据湖。数据被引入数据湖，却产生不了任何东西。在这种情况下，数据湖不会比垃圾场好到哪儿去。
这本书就是写给那些想要建造数据湖，并期望能够从中获得价值的机构。数据湖中当然有业务价值，但前提是建造得法。如果你正打算建造一个数据湖，那么你最好把它建造成公司的一项重要资产，而不是累赘。
本书探究了为什么众多公司在从他们的数据湖中获取数据时会面临如此艰难的困境。关于这个重要问题有数种答案。其中一个原因是，数据被不加区别地一股脑地打包丢入数据湖中。第二个原因是数据没有被整合起来。第三个原因是数据是以文本化的形式保存的，而你没办法轻易地分析文本数据。
本书建议要以高层（high level）的视角来组织数据，整合数据，“调校”数据，其目的就是使调整后的数据能够成为用于分析和处理的基石。数据湖当然可以成为公司的良性资产，但前提是在构建数据湖时要足够谨慎，并深谋远虑。
数据湖需要被划分成几个被称为数据池（data pond）部分，它们是：● 初始数据池（Raw data pond）；● 模拟信号数据池（Analog data pond）；● 应用程序数据池（Application data pond）；● 文本数据池（Textual data pond）；● 归档数据池（Archival data pond）。
在创建之后，数据池需要经历调整过程，使数据容易访问，以便进一步加以利用。举例来说，模拟信号数据池需要对数据进行缩减（reduction）和压缩。应用程序数据池需要让数据经历经典的ETL整合。文本数据池则需要对文本进行消歧，以便使文本可以规整成一致的数据库结构，这样，文本所在的语境就可以被识别出来。
一旦数据池中的数据经历过算法的调整，那么该数据池就可以作为基础，为分析和处理流程提供服务。一旦数据湖中的数据被区划成不同的数据池，并且数据在池中经历了调整，那么这些数据池就会成为公司的资产，而不是负累。此外，当数据走完了它在数据池中的生命周期，它就会被移入归档数据池。
这本书是写给管理者、学生、系统开发人员、架构师、程序员以及最终用户的，并希望能成为那些想把数据湖打造成公司资产而非负担的机构的指导手册。第1章数据的湖泊
打孔卡（punch card）被发明出来之后，磁带（tape）被发明出来，然后是磁盘存储（disk storage）和数据库管理系统（DBMS），紧跟着的是第4代编程语言（4GL）、“元数据”、软盘和移动计算。技术前进得如此之快，以至于我们甚至来不及记清楚它们的名字。很快，个人电脑和电子表单就会像西装和领带一样随处可见。
在这高速发展的几十年里，公司经历了从没有自动化到高度自动化的转变。但在转变过程中，存储却始终是一项制约因素。长久以来，在面对大量数据的时候，存储不是容量不够就是价格太高。这个瓶颈制约了既有系统的性能，并且对系统未来的可选方案产生了深刻的影响。1.1 大数据来了
随后，大数据技术改变了世界。Hadoop分布式文件系统（HDFS）是大数据技术最好的代表。这个开源软件框架的设计初衷就是解决在分布计算集群中的存储和处理大量数据集的难题。大数据技术有效地解放了存储包括在价格和技术能力上的限制。更为重要的是，在大数据技术的帮助下，一个全新的世界正向我们敞开大门。
简单来说，大数据刷新了我们对数据的认识。激增的数据可以被大数据系统保存并分析，这不仅是一项工业界的革命，更是一次世界性的革命。MB、GB、TB……旧有的数据量单位在这个存储容量被解放了的新世界中已不再适用。图1.1描绘了大数据降临的场景。图1.1 利用大数据创造无限机遇1.2 数据湖来了
随着大数据的蓬勃发展，不少机构开始将源源不断的数据流导入到一个叫做“数据湖”的设备中去。
把数据放进去是小菜一碟儿，然而，想从这浩瀚的知识海洋中拽出点什么有用的东西却极具挑战。一些机构开始向数据科学家们寻求帮助。于是，大量的经费被投入研发，然而，如同这些机构一样，大数据对于数据科学家们而言也是一个全新的领域。尽管投入高昂，但分析上难有突破，而误报和其他错误倒是时有发生。图1.2展示的是大数据催生了用广袤的数据湖泊来筛查数据。图1.2 在数据湖中置入大数据
图1.3所展现的是在数据湖中，过去商业社会所崇尚的规模产生价值在数据湖中的失效。对于数据湖来说，数据确实在持续增长，却很难用财富堆积出其中的价值。图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 在数据湖中用传统方法分析数据变得不可能1.4 小结
因为数据湖中的信息在设计时并没有考虑未来的访问和分析，这导致的后果是，机构很快就会发现这样的数据湖并不能支撑他们的业务，无论它多么庞大。
许多机构早就知道为了支持业务，数据必须以合理、易用，并且易于理解的方式组织起来。但是，由于数据被倾倒进数据湖的时候并没有考虑未来的使用，导致数据湖最终无法为业务注入有效的价值。
一旦数据湖变成了“单向”的数据湖，那么对于业务来说，唯一的优点就成了保存无用数据的廉价设备。而当数据湖仅以存放数据的低端形式出现时，就很难对机构当初的高额投入自圆其说了。
那么接下来，让我们来看一看如何解开这个困局。第2章改造数据湖
数据湖蕴藏着巨大的潜力。从前未尝做过的分析，现在可以用它来进行处理。从政府机构到小企业，数据湖可以识别、分析甚至预测从未被注意到的各种重要的规律（pattern）。
需要做哪些准备工作才能把数据湖变成信息金矿呢？那些建造了各自数据湖的机构还需要思考些什么呢？数据需要经过哪些调整才能为未来所用？
通过谨慎地规划，数据湖确实可以变成信息金矿，那么，是什么让数据湖具备深邃的洞察的能力呢？是4个基础组件：元数据（metadata）、整合图谱（integration mapping）、语境（context）以及元过程（metaprocess）。2.1 元数据
元数据（metadata）是数据湖中用来对数据进行描述的数据［与初始数据（raw data）相对］。它是基础的结构化信息，并且与每个数据集都有关联。例如，如果要记录一个网站的访问数、点击量以及参与度的情况，元数据就可以是包含来访设备的IP地址/地理位置信息的数据。典型的元数据的表现形式包括对记录、属性、键值、索引以及不同数据属性间关系的描述。除了以上提到的这些，元数据还有许多其他的表现形式。
元数据被分析师用来解密数据湖中的初始数据。或换言之，元数据是栖居于数据湖中的数据的基本轨迹（basic roadmap）。
若数据湖中只保留了初始数据，那么使用数据的分析师就如同被砍去一条腿。想象一下，要尝试搜索维基百科（Wikipedia），而里面所有的文章却连标题都没有。靠初始数据本身单打独斗，其实并不那么有用。若初始数据都恰当地用元数据打上了标签，并一起保存在数据湖中，那么，你的服务才能称之为有用的服务。2.2 整合图谱
整合图谱（integration map）所描述的是一个应用程序中的数据是如何与另一个应用程序的数据产生关联，以及数据是以什么样的逻辑被组合到一起。尽管元数据如此重要，但它并不是数据湖中唯一的基础部分。考虑到数据湖中大部分的输入数据都是由应用程序产生的，而产生的形式不尽相同。如果你把许多不同的应用程序产生的数据注入数据湖中会发生什么？答案是，你在数据湖中创建了若干互不关联的“数据仓罐”（silo）。
不同的应用程序，通常由不同的编程语言所编写，在各自的数据仓罐中发送数据，无法与其他的仓罐沟通或“交谈”。即使是信息都被保存在同一个数据湖内，每一个仓罐的数据也都无法与其他仓罐的数据相整合，甚至无法被元数据合适地标记。
为了让数据湖中的数据合理，就需要创建一份“整合图谱”（integration map）。整合图谱是数据湖中的数据如何被整合的详细规范。它是解决数据仓罐之间相互隔绝问题的最佳方案。
图2.1表现了由于许多未被整合的应用程序数据被放置在数据湖中，许多数据仓罐就这样被创建出来。这些仓罐使读取数据和解释数据陷入困境。图2.1 创建仓罐会导致数据的相互隔绝，并阻碍沟通2.3 语境
在数据湖中的另一个复杂的情况是脱离上下文语境的文本数据。[1]假设文本“court”出现，那么这个“court”究竟指的是网球场，还是法庭诉讼，还是男青年追求姑娘所做的努力，还是皇室周围的人们呢？当你单纯地看着“court”这个词，它的意思有可能是以上任意一种，甚至还可能有其他的意思。
脱离了上下文语境的文本是意义不明确的数据。事实上，在一些情况下，在语境不明晰的前提下保存文本是很危险的。如果你想把文本放入数据湖，那么你必须把文本所在的语境也放在其中，或者至少要提供找到文本语境的方法。文本语境对数据湖中的数据来说是一项必要的组成部分，缺乏语境的文本数据是不明晰的，如图2.2所示。图2.2 缺乏语境的文本数据2.4 元过程
元过程（metaprocess）信息是关于数据被如何处理，或者数据湖中的信息将会被如何处理的信息。数据何时产生？数据何处产生？数据产生多少？数据由谁产生？所选数据是如何被置入数据湖的？当进入数据湖后，数据是否被进一步处理过？当数据分析师在数据湖中提取和分析数据时，以上所有这些形式的元过程信息（metaprocessing）都是非常有用的。
最重要的一点是，这些特性需要在刚开始的时候就被抓取。通常，当初始数据被导入数据湖之后再考虑这加入这些基本成分就太迟了。
然而，一旦这些成分被加入了数据湖，那么数据湖就有了成为信息金矿的潜质。图2.3描绘了通过这些粗箭头，数据湖变成了公司的强大并且富有成效的资源。图2.3 从垃圾场变成信息金矿
把数据湖转化成企业良性资产的另一个重要性在于惠及更多不同的用户群体。
想象一下，数据湖成为公司的一项有用资源所经历的变化。图2.4展示的是尚未改造的数据湖与完成改造的数据湖。图2.4 从未经改造的数据湖到改造完成的数据湖2.5 数据科学家
如果只有一小拨儿专家才能玩转数据湖里面的数据，那这就说明数据湖还处于数据湖初级阶段。而这一小拨儿专家通常被人们称作数据科学家。数据科学家们具备以下特点：● 少，很难找到；● 贵，雇佣昂贵；● 忙，就是请来了，你也约不到时间。
数据科学家圈子小并没有什么问题。但是小到找到他们都很难就有问题了，而且雇佣成本居高，即便是找到了他们，而且雇佣了他们，但想要约他们的时间也是很困难的，这些特点使得他们成为了传奇。无论管理得有多好，只要数据湖只能被一小拨儿时间紧张、成本高昂的人所操作的时候，数据湖的企业价值就会受限。2.6 通用性
现在来想一下，当数据湖被充分地整合，而且数据已具备通用性之后会发生什么。
图2.5表现的是数据湖只能被一小部分数据科学家所使用，与改造后可被大量商业用户所访问之间的差异。图2.5 改造数据可以增加用户访问的便捷性
经过改造之后，数据湖能发挥价值的对象就会扩展到会计、经理、系统分析师、终端用户、财务团队、销售员工、市场及其他部门。通过整合与调整数据，数据湖还可以扩大服务的用户群体。同时，经过改造后，数据湖在公司中的价值也被极大地提升了。2.7 小结
数据湖的潜力巨大。但如果人们仅仅用来倾倒数据而对数据的使用不加考虑，那么这就会产生把数据湖变成垃圾场的危险。通过4项基础成分的帮助，数据湖可以转化为信息的金矿。● 元数据（metadata）。元数据被分析师用来解密在数据湖中
发现的初始数据。元数据是栖息在数据湖中的数据的基本轨迹图。● 整合图谱（integration mapping）。整合图谱是数据湖中的
数据如何被整合的详细规范。它阐述了如何解决仓罐数据的隔绝
性问题。● 语境（context）。如果你想把文本放入数据湖，那么你必须
把文本语境也放置在其中，或者至少要提供找到文本语境的方
法。● 元过程（metaprocess）。元过程标签是关于数据湖中的数
据处理的信息。
[1] court的含义有很多，如法庭、王、献殷勤等。第3章数据湖内部
为了更好地理解数据湖如何应对未来的访问和分析，深入数据湖内部看看是有必要的。
尽管在数据湖里能找到各种类型的数据，但这些数据仍然可以被分为3类，如图3.1所示。● 模拟信号数据（analog data）。● 应用程序数据（application data）。● 文本数据（texture data）。图3.1 数据湖数据的分类3.1 模拟信号数据
第一类在数据湖中的数据类型是模拟信号数据。模拟信号数据通常由机器或一些其他的自动设备产生，即便并没有接入互联网，也可以产生数据。这些监测工具可以诊断并记录从核反应堆的运行性能到你的移动电话CPU的使用情况。
大体上，模拟信号数据是巨量而且反复的。大多数模拟信号数据由一长串生成的数字组成。模拟信号设备所产生的大部分记录则是大同小异的监测数据。而通常，最令人感兴趣的是那些微小的异常值（outliners）。
模拟信号数据通常是对一些物理指标（如热量、重量、化学组成、尺寸等）的简单监测。一旦监测值偏离了正常值，则相当于发出了一个信号，督促人们去寻找导致监测值异常的原因。举例来说，异常的监测值可能是因为机器的校准失效，或者某个零件需要调整，等等。但是对于分析师而言，模拟信号数据只能作为一个检查造成监测值浮动原因的信号。
这就是为什么与模拟信号数据相关联的元过程（metaprocess）信息要比模拟信号数据本身重要许多倍的原因。元过程的细节通常包含了测量的时间、地点、速度等更丰富的信息。
通常，模拟信号信息会关联于一些触发器，或直接由其他事件触发，如生产活动。一个组件被生产出来，一个货物被发出，一个盒子被移动，这些都是常见的会触发创建模拟信号记录的活动。模拟信号监测通常是机械化的，不需要人为输入或是额外处理。图3.2展现的是通过一个事件触发了模拟监测数据的创建。图3.2 通过事件触发了模拟信号数据监测
那些伴随着模拟监测过程中捕获初始数据（raw data）的数据被称作“元过程”（metaprocess）数据。针对于目标的不同，元过程模型也会有与之相适应的不同类型，而这种初始输出（指元过程数据）与数据湖是最为相关的。相比于仅仅观察初始数据本身，元过程信息提供了另一种看待模拟信号数据的视角。图3.3描绘的是一些典型的元过程细节。图3.3 相比于仅仅观察初始数据本身，元过程提供了另一种看待模拟信号数据的视角
很多时候，模拟监测数据被保存在日志磁带上。日志磁带是在创建模拟监测数据的事件的时候，一项或多项变量的连续监测记录。它通常是十分详细的，产生的数据之间的间隔非常小。
日志磁带的格式一般都非常复杂。由于其复杂性，通常会使用系统工具来读取和解析日志磁带。在多数情况下，日志磁带会捕获所有发生的事件，而不仅仅是那些感兴趣的事件或产生问题的事件。这样做的自然的结果就是日志磁带会包含极其巨量的信息。图3.4表示的是在普通的日志磁带中的模拟信号数据。图3.4 在日志磁带中保存模拟信号数据3.2 应用程序数据
数据湖中第二类常见的数据类型是应用程序数据。应用程序数据由应用程序或业务处理产生，并发送到数据湖。尽管交易数据十分重要，但在数据湖中应用程序组件中，它却并不是唯一的数据类型。
在数据湖中，应用程序数据的典型类型包括销售数据、支付数据、银行支票数据、生产流程控制数据、出货数据、合同履行数据、库存管理数据、计费数据、账单支付数据、结费数据，等等。当发生任何与业务相关的事项时，这个事项会被应用程序所监测并创建数据。
数据湖的应用程序数据的具体表现形式多种多样。然而，其中最为典型的表现形式就是记录下应用程序的活动状态。这些被记录下来的数据将有可能被塑造为数据库管理（DataBase Management Systems，DBMS）。应用程序数据也常见于重复的一致性结构。图3.5展示的就是这样的结构。图3.5 重复性的同质结构
应用程序数据中这种整齐而均匀的结构大多以记录的形式出现，而不仅仅是一个模拟信号数据点。记录可能还会附带多种属性（attribute）。其中一个或多个属性可以被指定为键（key）。属性中的一个或多个值还可以有独立的索引。图3.6展示了在数据湖中，典型的应用程序数据的键和记录的结构。图3.6 数据湖中的典型的键和记录结构
值得说明的是，应用程序数据的这种结构有可能严格依赖于当数据被导入数据库时的结构。3.3 文本数据
数据湖中第三种常见数据类型是文本数据。文本数据通常会与一个应用程序相关联。然而，文本数据与应用程序数据却有着极大的不同。应用程序数据是以一致的记录格式保存记录，而在文本格式中的数据却并不会依赖于任何形式。
文本数据被称作“非结构化数据”，因为文本可以以任何形式（form）出现。举例来说，当人说话的时候，他们可以聊他们喜欢的任何流行话题。这些交流的内容通常是合乎逻辑的，但许多词句也可以抛开结构。他们可以说谜语和寓言。在这种情况下，他们所使用是另一类语言系统。他们的词句中会包含俚语、粗话，可以是正式的谈话或是一些小圈子里的笑话。所以很自然，例子中的这些文本非常依赖于语境内容，而且既不易查询，也不易于通过自动化手段来处理。
众多企业里典型的文本形式包括呼叫中心的对话、公司合约、电子邮件、保险申诉、销售简报、法庭命令、玩笑、微博、邀请函，等等。数据湖中的文本类型和存量无法计数。然而，为了使文本数据能够被用于分析，必须对文本进行处理。只要文本还维持其初始形式，那么基于文本所做的分析只能浮于表面。为了让文本能够被有效地分析，非结构化文本必须要经过一种被称为“文本消歧”的处理。
请注意，模拟信号数据和应用程序数据几乎不需要进行类似这样的处理，这是因为模拟信号数据和应用程序数据是以同质的形式被采集的，这类数据因而便于被计算机分析。但如果要对文本进行详尽的分析，那么数据就需要从它的非结构化状态经历文本的消歧，从而使它们能够被计算机所处理。
主要有2项重要任务交由文本消歧完成：● 文本从非结构化状态转成可供计算机分析的结构化的一致状
态；● 识别与文本相关的语境。
除了这两项主要功能外，文本消歧还有一些其他有用的功能。在这些消歧任务中最复杂的就是识别文本的语境，以及将文本与语境相互联系起来，见图3.7。图3.7 识别文本语境3.4 另一个视角
在数据湖中，3个主要的数据分类是，模拟信号数据、应用程序数据以及文本数据。但是在数据的类别中仍有一种介于重复性数据与非重复性数据的分类方法。大体来说，模拟信号数据和应用程序数据是具有重复性的，而文本数据则是非重复性的。图3.8展示了数据湖的中重复性数据与非重复性数据的分类的形态。
乍一看这似乎无足轻重，但将数据分为这两类却有着至关重要的作用。
在后面的几个篇章中，我们会去探究重复性数据和非重复性数据的差别，包括业务价值，以及这种分类的重要性。大体上，非重复性数据有着重要的业务价值，而重复性数据中的业务价值则相对较低。因为业务价值的鲜明对比，这两种数据类型形同泾渭（great divide），如图3.9所示。图3.8 重复性数据指的是同样的数据单元反复地出现，而非重复性数据则是在总体上不重复出现相同的数据单元图3.9 重复性数据与非重复性数据之间的巨大差别3.5 小结
规置数据湖有多种方式。其中一种就是把数据分为以下3个类别：● 模拟信号数据；● 应用程序数据；● 文本数据。
另一个重要的分类数据方法是将数据分为重复性数据与非重复性数据，而重复性数据与非重复性数据之间形成的差别被人称为“大分水岭”（great divide）。第4章数据池
为了将不同类型的数据规划成可供分析的结构，有必要在数据湖内创建高级（high level）的数据结构。当数据进入数据湖时，它首先进入的是初始数据池。设置初始数据池的目的是使它充当数据的存放单元（holding cell）。在初始数据池内，几乎没有分析或是其他数据活动。
一旦到了分析阶段，初始数据池内的信息就会基于不同的数据类型，被发送到3个不同的数据池之一。也就是说，模拟信号数据、应用程序数据和文本数据都有专用的数据池（pond）。
而将3种数据结构隔离开是很重要的，因为一旦进入数据池，将会发生大量的处理。需要指出的是，在这些数据池内所进行的数据处理和调整是很不一样的。当调整完成后，池内的数据就可以用来分析了。
当数据在数据池内经历了它的生命周期步入终结，它就会从模拟信号、应用程序或是文本数据池内被移入归档数据池。图4.1展示这种从初始数据池向模拟信号池、应用程序池或是文本池的高层数据流动。图4.1 理解在不同数据池类型下的数据生命周期4.1 数据修整
当数据进入了各种不同类型的数据池，初始数据就会经历修整，以便用于分析。换句话说，如果初始数据没有经过修整，那么它将难以支持业务分析，从而无法产生业务价值。这是因为信息尚不足以用于研究，在一些情况下，未经修整的数据甚至是不可用的。因此，如果要支持业务分析，那么初始数据必须强制接受修整。
但是，对于不同类型的数据池，修整过程是截然不同的。4.2 初始数据池
数据途经的第一站是初始数据池（raw data pond）。初始数据池就是许多机构最开始称之为数据湖的地方。但他们往往仅是将数据扔进数据湖里，却紧接着好奇他们为什么不能对数据作出任何有意义的分析和处理。公平地说，分析处理是可以基于数据湖中的初始数据来完成的。它仅需要一个数据科学家来作些分析。但是数据经过修整之后可以作出更为清晰和高效的数据分析。与此同样重要的是，一旦数据被修整后，那么即使是普通的业务用户也可以进行分析和使用。
一个有趣的架构问题是：一旦初始数据流从初始数据池流入了数据池，那么初始数据池内的那份数据是否还要保留？答案是，不。一旦初始数据从初始数据池流入了模拟信号数据池、应用程序数据池以及文本数据池，最好将源数据（source data）从初始数据池中移除。初始数据已经完成了它的历史使命，而且在初始数据池内作分析处理也是极为罕见的。不然，初始数据池会成为各种混杂数据的“居住地”，见图4.2。图4.2 变成混杂数据的“居所”
初始数据池中的数据应该尽可能快地被传递到所支持的数据池内。对初始数据池的一个质量衡量标准就是它有多小以及它向外传递数据的速度有多快。4.3 模拟信号数据池
模拟信号数据池，很自然地，是储存模拟信号数据的地方。模拟信号数据的修整主要包括数据缩减（data reduction），即将模拟信号数据的数据量减少到可操作、可管理、有意义的数据量，并对池内的数据重新整理。4.4 应用程序数据池
应用程序数据池被一个或多个在运行着的应用程序所占有，而应用程序数据可能是数据湖中“最干净”的数据了，因为它是由应用程序所产生的。所有应用程序数据池内的数据都是具有一致性的结构的，同时包含着与业务运作相关联的数值。但同时，应用程序数据池内的数据也是未经整合（notoriously unintegrated）的数据。不过，如果池内所有的信息都来自单一应用程序，那么数据池内的数据是有可能被整合过的。但是，对于大型企业来说（大多数拥有数据湖的大企业），数据池内的数据很有可能来自多个不同的应用程序。而正是这种多数据源的数据让分析师们头疼不已。4.5 文本数据池
文本数据池是放置非结构化的文本数据的地方。这里的文本可以来自任何地方。池内的文本由于难于进行深度处理，因而恶名昭彰。未经转换的文本仅能做一些表面的分析，为了做深度分析，文本需要经过数据消歧处理。
数据消歧有两个作用：● 文本可以被转换成一致的数据库格式；● 文本的语境可以被识别出来，并将它关联到文本。4.6 将数据直接传入数据池
值得注意的是，数据没有必要一定经过初始数据池，尽管这是常规的做法。如果开发者经验老道，那么直接将数据传入模拟信号、应用程序以及文本数据池也是可行的。然而，大多数的数据之所以会经过初始数据池，仅仅是因为绝大多数的企业在一开始会这么做。图4.3展示了初始数据可以直接被传入模拟信号、应用程序、文本数据池。图4.3 将初始数据传入不同的数据池
在数据生命周期最后的阶段里，数据会从模拟信号、应用程序、文本数据池被传入归档池。4.7 归档数据池
图4.4展示了从各种数据池到归档数据池的数据传递过程。图4.4 可以将数据存入归档数据池
归档数据池设计的目的是保存那些不常用于分析，但在未来某个
试读结束[说明：试读内容隐藏了图片]