驾驭大数据
内容提要
本
书提供了处理大数据和在企业中培养创新和探索文化所需的工具、流程和方法，描绘了一个易于实施的行动计划，以帮助企业发现新的商业机会，实现新的业务流程，并做出更明智的决策。
本书重点介绍了如何驾驭大数据浪潮，并详细地介绍了什么是大数据，大数据为什么重要，以及如何应用大数据。本书还从具体实用的角度，介绍了用于分析和操作大数据的工具、技术和方法；以及从人才和企业文化的角度，介绍了如何使分析专家、分析团队以及所需的分析原则更加高效，如何通过分析创新中心使得分析更加具有创造力，以及如何改变分析文化。
本书适合对数据处理、数据挖掘、数据分析感兴趣的技术人员和决策者阅读。
前言
你
收到一封邮件，邮件中提供了一套个人电脑的报价。而你几个小时前刚刚在这家零售商的网站上搜索过电脑的信息，似乎它们已经读出了你的想法……当你驱车前往这家商店购买这套个人电脑时，你路过了一家咖啡店，你看到了这家咖啡店的一条折扣信息。你获知由于你刚来到这片区域，你可以在未来20分钟内享受10%的折扣……
在你享用咖啡的时候，你收到了一家制造商关于某产品的道歉，而你昨天刚刚在你的Facebook主页和这家公司的网站上抱怨了它们的产品……
最后，当你回到家之后，你又收到了一条关于购买你最喜欢的在线视频游戏升级装备的信息。有了这些装备，你才能顺利通过某些曾经苦苦挣扎的关卡……
听起来很疯狂吗？难道这些事情只有在很远的未来才发生吗？不，这些场景都是我们今天可能见到的！大数据、高级分析、大数据分析，似乎今天你已经逃脱不了这些术语了。无论在哪里，你都会听到人们在讨论大数据和高级分析，看到关于它们的文章或是宣传推销它们。好了，现在你也可以将这本书加入关于它们的讨论中了。
什么是真实的，什么是炒作？这些关注可能会使你怀疑大数据分析是一种炒作，而非真实的东西。尽管在过去的几年曾经有不少被炒作的概念，然而就分析能力和处理海量数据而言，我们确实处在一个转型的年代。如果你肯花一些时间来理清并过滤掉那些有时被媒体过分炒作的部分，你会发现大数据背后有一些非常真实和强大的东西。随着时间的推移，大数据分析会使企业和消费者都获益，而收益带来的兴奋和期待又会继续引发更多的炒作。
大数据是下一波新数据源的浪潮，并会驱动分析在商业、政府及教育界的下一次革新。这些革新将有可能快速改变企业审视它们自身业务的方式。大数据分析可以促成更加明智的决策，在某些情况下，促成这些决策的方式将明显不同于今天。它带来的很多洞察在今天看起来都像是在做梦。你会看到，征服大数据的需求和一直以来征服新数据源的需求在很大程度上是一致的。然而，大数据的额外规模必须使用新的工具、技术、方法和流程。传统的分析方法已经不再适用于新的环境，我们有必要使用高级分析将商业界带入更高的层次。这就是这本书要讲的内容。
“驾驭大数据”并不只是本书的书名，而是下一个十年中，决定哪些商业活动将振兴，而哪些商业活动将消亡的决定性因素。准备主动接受大数据，企业可以通过驾驭大数据浪潮而取得成功，而不是遭受大数据浪潮连绵不断的冲击。你需要了解些什么？你如何为征服大数据做准备？你如何从大数据中获得振奋人心的分析结果？坐下来，找一个舒服的姿势，准备好发现大数据的秘密！
读者对象
这些年来有无数关于高级分析的书籍问世，最近也开始有关于大数据的书籍出现。本书是从一个与其他书籍不同的角度来看大数据的，主要帮助读者理解什么是大数据，如何通过分析来利用大数据，以及在如今的大数据环境中，如何处理世界范围内的高级分析生态系统的创新和变革。大部分读者都将发现这本书有价值且充满趣味。无论你是分析专家，还是使用分析结果的企业家，或者只是对大数据和高级分析感兴趣的人，这本书都有适合你阅读的内容。
本书并不会深入介绍所涉及主题的技术细节。本书的技术高度刚刚能够让读者从高层次来理解其所讨论的概念。本书的目的是使读者可以理解，并开始运用这些概念，以及帮助他们认识在哪些方面还需要更加深入的研究。这本书更像是一本手册而非教科书，完全可以被非技术人员理解和掌握。同时，那些对这些主题已经有深入了解的读者，也可以从本书的一些讨论中获得一些技术方面更深层次的启示。
内容提要
本书由四部分组成，每一部分都从一个方面来介绍如何驾驭大数据浪潮。第一部分将介绍什么是大数据，大数据为什么重要，以及如何应用大数据。第二部分集中介绍那些能够用于分析和操作大数据的工具、技术和方法。第三部分介绍如何使分析专家、分析团队以及所需的分析原则更加高效。第四部分将前三部分结合在一起，重点介绍了如何通过分析创新中心使得分析更加有创造力，以及如何改变分析文化。以下是关于各章节所涉及内容的详细提纲。
第一部分 大数据的兴起
第一部分重点介绍了什么是大数据，大数据为什么重要，以及分析大数据可以带来什么好处。本部分覆盖了10种类型的大数据源，以及如何利用这些资源来帮助企业提高其业务水平。如果读者拿起这本书时，还不知道什么是大数据，以及大数据的应用有多么广泛，那么第一部分会帮助你了解这部分内容。
第1章 什么是大数据，大数据为什么重要
本章首先介绍了大数据的背景知识，以及大数据到底是关于什么的。然后给出了一些企业如何利用大数据的案例。如果读者想要帮助自己的企业驾驭大数据浪潮，那么请首先理解本章所讲的内容。
第2章 网络数据：原始的大数据
如今，或许应用最为广泛并为人们所熟知的大数据源是从网站上收集来的详细数据。用户浏览互联网所产生的日志信息，是等待分析和挖掘的信息宝库。不同行业的企业都将从它们网站上收集到的详细用户信息整合到它们的企业业务分析中。本章将探索这些数据是如何增强和改变一系列业务决策的。
第3章 典型大数据源及其价值
在本章中，我们将从高层次来探索9种大数据源。其目的是介绍每种数据源，并讨论每种数据源在商业中的应用和启示。一些本质相同的技术应用在不同的行业中，以产生多种大数据源，这个趋势已经越来越明显。另外，不同的行业可以利用一些相同的大数据源，大数据并非只能用于某些狭窄的领域。
第二部分 驾驭大数据：技术、流程以及方法
第二部分将集中介绍用于驾驭大数据的技术、流程以及方法。这些年取得的重大进展增加了这3个方面的可扩展性。企业不能继续依赖外部的方法和专家来保持它们在大数据世界中的竞争力。本书的这一部分将是技术性最强的一部分，但仍然可以被绝大多数的读者所理解和接受。读完这些章节后，读者将熟悉他们今后进入大数据分析领域时可能遇到的一系列概念。
第4章 分析可扩展性的演进
在每一个时期，数据的高速增长使得当时最具可扩展性的工具也只能疲于应付。在大数据出现之前，传统的高级分析方法已经到达了它们的瓶颈。如今，传统的方法已经不再适用。本章将讨论分析和数据环境的融合、海量并行处理（MPP）体系、云、网格计算，以及MapReduce技术。这些技术增强了可扩展性，并且在大数据分析中扮演着重要角色。
第5章 分析流程的演进
为了更好地利用被极大增强的可扩展性，分析流程也需要进行升级。本章将首先概述如何利用分析沙箱为分析专家提供一个可扩展的环境，从而建立高级分析流程。然后，我们将介绍企业分析数据库如何帮助在创建分析数据时，获得更高的一致性并减小风险，同时提高分析专家的生产效率。本章最后将探讨如何使用嵌入式评分过程将高级分析流程部署和转移到用户端和应用端。
第6章 分析工具和方法的演进
本章将介绍一些高级分析方法演进的过程，以及这些改进将如何继续改变分析专家完成工作和处理大数据的方式。讨论的主题将包括可视化图形界面、单点分析解决方案、开源工具，以及数据可视化工具的演进。本章也讲述了分析专家将如何改变他们建模的方法，以便更好地利用可用资源。讨论的主题包括组合模型、简易模型以及文本分析。
第三部分 驾驭大数据：人和方法
第三部分重点讨论驾驭大数据的人和他们所属的团队，以及确保他们能够提供优质分析的方法。如何提供优质的分析，包括大数据分析，其关键因素是找到合适的人来掌舵，并且他们能够遵循正确的分析原则。读完这3章后，读者将了解优质分析、优秀的分析专家和分析团队的特质。
第7章 如何提供优质分析
计算统计结果、撰写报告、使用建模算法仅仅是实现优质分析众多步骤中的几步。本章首先阐述了一些定义，然后讨论了一系列关于如何创建优质分析的主题。大数据给企业带来了从未处理过的复杂数据组合，将本章讨论的原则牢记在心对驾驭大数据非常关键。
第8章 如何成为优秀的分析专家
数学、统计学以及编程方面的能力是必要的，但对于一个优秀的分析专家来说，仅仅具备这些技能还不够。优秀的分析专家还需要具备大多数人通常不会首先具备的特质。这些特质包括承诺、创造力、商业头脑、演讲能力与沟通技巧以及直觉。本章将探讨在寻找一个优秀的分析专家时，这些特质为什么非常重要且不能被忽视。
第9章 如何打造优秀的分析团队
企业如何打造一个高级分析团队，并使其发挥最优效果？把他们放在企业的什么位置最合适？这些团队如何运转？谁来创建高级分析？本章将讨论建立一个优秀的分析团队时必须考虑的一些常见挑战和原则。
第四部分 整合：分析文化
第四部分将介绍一些著名的基本原则，企业想利用高级分析和大数据进行成功创新必须遵循这些原则。尽管这些原则也被广泛地应用于其他领域，但我们的焦点和视角是这些原则将要如何应用于当前企业环境的高级分析中。读者可能已经比较熟悉所涉及的这些概念，但是对于如何将它们应用到高级分析和大数据中，也许还是很陌生的。
第10章 促进分析创新
本章从回顾一些成功创新背后的基本原则开始，然后通过分析创新中心的概念，将它们应用到大数据和高级分析中。我们的目标是能够让读者清楚地理解如何在企业中更好地促进分析创新，并驾驭大数据。
第11章 营造创新和探索的文化氛围
本章将介绍如何营造创新和探索的文化氛围作为本书的结尾。本章的文字有趣而轻松，并给如何营造出有利于促进创新分析的文化氛围留出了一些思考空间。这些涉及的原则被广泛地讨论，并被大家熟知。但是，这些原则仍然值得回顾，并且需要思考企业如何将这些确立的原则应用到大数据和高级分析中。
目录
第一部分 大数据的兴起
第1章 什么是大数据，大数据为什么重要 3
1.1 什么是大数据 3
1.2 大数据中的“大”和“数据”哪个更重要 5
1.3 大数据有何不同 6
1.4 大数据为何是数量更多的、相同类型的传统数据 8
1.5 大数据的风险 9
1.6 你为什么需要驾驭大数据 11
1.7 大数据的结构 12
1.8 探索大数据 14
1.9 很多大数据其实并不重要 15
1.10 有效过滤大数据 17
1.11 将大数据和传统数据混合 18
1.12 对大数据标准的需求 19
1.13 今天的大数据将不再是明天的大数据 20
1.14 本章小结 22
第2章 网络数据：原始的大数据 25
2.1 网络数据概观 26
2.1.1 你遗漏了什么 27
2.1.2 想象各种可能性 28
2.1.3 一个全新的信息来源 28
2.1.4 应当收集什么数据 29
2.1.5 关于隐私 30
2.2 网络数据揭示了什么 31
2.2.1 购物行为 31
2.2.2 顾客的购买路径和偏好 32
2.2.3 研究行为 33
2.2.4 反馈行为 34
2.3 行动中的网络数据 35
2.3.1 最优的推荐商品 35
2.3.2 流失模型 37
2.3.3 响应模型 38
2.3.4 顾客分类 39
2.3.5 评估广告效果 40
2.4 本章小结 41
第3章 典型大数据源及其价值 43
3.1 汽车保险业：车载信息服务数据的价值 44
3.2 多个行业：文本数据的价值 46
3.3 多个行业：时间数据与位置数据的价值 49
3.4 零售制造业：RFID数据的价值 52
3.5 电力行业：智能电网数据的价值 55
3.6 博彩业：筹码跟踪数据的价值 57
3.7 工业发动机和设备：传感器数据的价值 59
3.8 视频游戏：遥测数据的价值 61
3.9 电信业与其他行业：社交网络数据的价值 63
3.10 本章小结 66
第二部分 驾驭大数据：技术、流程以及方法
第4章 分析可扩展性的演进 71
4.1 分析可扩展性的历史 71
4.2 分析与数据环境的关联性 73
4.3 海量并行处理系统 77
4.3.1 使用MPP系统进行数据准备与评分 79
4.3.2 使用MPP系统进行数据准备与评分小结 84
4.4 云计算 85
4.4.1 公有云 86
4.4.2 私有云 89
4.4.3 云计算小结 90
4.5 网格计算 91
4.6 MapReduce 92
4.6.1 MapReduce工作原理 93
4.6.2 MapReduce优缺点 96
4.6.3 MapReduce小结 97
4.7 这不是一个单选题 98
4.8 本章小结 99
第5章 分析流程的演进 101
5.1 分析沙箱 102
5.1.1 分析沙箱：定义与范围 102
5.1.2 分析沙箱的好处 103
5.1.3 内部分析沙箱 104
5.1.4 外部分析沙箱 105
5.1.5 混合式分析沙箱 107
5.1.6 不要仅仅使用数据，而要丰富数据 108
5.1.7 系统负载管理和容量规划 109
5.2 什么是分析数据集 111
5.2.1 两种分析数据集 111
5.2.2 传统的分析数据集 112
5.3 企业分析数据集 114
5.3.1 什么时候创建企业分析数据集 115
5.3.2 企业分析数据集里有什么 116
5.3.3 逻辑结构与物理结构 117
5.3.4 更新企业分析数据集 118
5.3.5 汇总表还是概要视图 118
5.3.6 分享财富 120
5.4 嵌入式评分 120
5.4.1 嵌入式评分集成 122
5.4.2 模型与评分管理 123
5.5 本章小结 125
第6章 分析工具与方法的演进 127
6.1 分析方法的演进 127
6.1.1 组合建模 128
6.1.2 简易模型 129
6.1.3 文本分析 132
6.1.4 跟上分析方法的发展脚步 134
6.2 分析工具的演进 135
6.2.1 图形化用户界面的崛起 135
6.2.2 单点解决方案的兴起 137
6.2.3 开源的历史 138
6.2.4 数据可视化的历史 140
6.3 本章小结 145
第三部分 驾驭大数据：人和方法
第7章 如何提供优质分析 149
7.1 分析与报表 149
7.1.1 报表 150
7.1.2 分析 152
7.2 分析的G.R.E.A.T原则 153
7.2.1 导向性（Guided） 154
7.2.2 相关性（Relevant） 154
7.2.3 可解释性（Explainable） 154
7.2.4 可行性（Actionable） 154
7.2.5 及时性（Timely） 154
7.3 核心分析方法与高级分析方法 155
7.4 坚持你的分析 156
7.5 正确地分析问题 157
7.6 统计显著性与业务重要程度 159
7.6.1 统计显著性 159
7.6.2 业务重要程度 162
7.7 样本VS全体 162
7.8 业务推断与统计计算 165
7.9 本章小结 166
第8章 如何成为优秀的分析专家 169
8.1 哪些人是分析专家 169
8.2 对分析专家常见的误解 170
8.3 每一位优秀的分析专家都是独特的 171
8.3.1 教育 171
8.3.2 行业经验 172
8.3.3 当心“人力资源清单” 173
8.4 优秀分析专家身上经常被低估的特质 174
8.4.1 承诺 174
8.4.2 创造力 174
8.4.3 商业头脑 177
8.4.4 演讲能力与沟通技巧 180
8.4.5 直觉 183
8.5 分析认证有意义吗，还是干扰视听的噪音 185
8.6 本章小结 186
第9章 如何打造优秀的分析团队 189
9.1 各个行业并非生而平等 189
9.2 行动起来 191
9.3 人才紧缩 192
9.4 团队组织结构 193
9.4.1 分布式组织结构 194
9.4.2 集中式组织结构 195
9.4.3 混合式组织结构 196
9.5 持续更新团队技能 197
9.5.1 矩阵式方法 197
9.5.2 管理人员不能眼高手低 199
9.6 应该由谁来做高级分析工作 199
9.6.1 前后矛盾的地方 200
9.6.2 如何帮助刚刚从事分析工作的新手茁壮成长 202
9.7 IT人员和分析专家为何相处不好 203
9.8 本章小结 205
第四部分 整合：分析文化
第10章 促进分析创新 209
10.1 商业需要更多创新 210
10.2 传统的方法阻碍了创新 211
10.3 定义分析创新 212
10.4 在创新分析中使用迭代方法 213
10.5 考虑换个角度 214
10.6 你是否为建立分析创新中心做好了准备 216
10.6.1 组件1：技术平台 216
10.6.2 组件2：第三方的产品和服务 217
10.6.3 组件3：承诺和支持 217
10.6.4 组件4：强大的团队 218
10.6.5 组件5：创新委员会 218
10.6.6 分析创新中心的指导原则 219
10.6.7 分析创新中心的工作范围 219
10.6.8 处理失败 221
10.7 本章小结 223
第11章 营造创新和探索的文化氛围 225
11.1 做好准备 225
11.1.1 Crocs和Jibbitz的传说 226
11.1.2 推动创新 227
11.2 关键原则概述 228
11.2.1 原则1：打破思维定势 228
11.2.2 原则2：形成连锁反应 231
11.2.3 原则3：统一行动目标 234
11.3 本章小结 239
结论：再敢想一些 241
分析可扩展性的演进
不
言而喻，大数据的世界需要更高层次的可扩展性。随着公司处理的数据量持续增长，原有的数据处理方法已经无法应对现有的数据量。那些没有更新技术以提供更高层次的可扩展性的企业，将无法应对大数据带来的数据处理压力。幸运的是，在大数据处理、分析与应用的不同层面中，有很多技术可供使用。其中有些技术还非常新，而大数据领域的公司也需要与时俱进。
这一章会讨论能够帮助我们驾驭大数据的几种重要技术：分析与数据环境的关联性、海量并行处理架构（Massively Parallel Processing，MPP）、云计算、网格计算以及MapReduce。
开始讲述具体内容以前，请记住本书的定位并不是一本技术书籍。这一章，以及随后的第5章与第6章，将会是技术性内容最多的章节，但是所有的技术内容都将局限在概念层面，以确保技术背景不深的读者也可以轻松地理解。为了达到这个目标，本书对某些技术细节进行了一定程度的简化处理。如果读者想了解更多的技术细节，可以阅读专注于技术本身的其他书籍。
4.1 分析可扩展性的历史
在20世纪初期，进行数据分析是一件非常非常困难的事情。如果要进行某些深入分析，例如，建立预测模型，则需要完全依靠人们手工进行各种统计运算。举个例子，为了构建一个线性回归模型，人们不得不手工计算矩阵并进行矩阵的转置运算，连矩阵参数估计的计算也需要手工进行。当时人们已经拥有了一些基础的计算辅助工具，但绝大部分计算过程还是需要依靠手工来完成。在那个时代，获得分析所需的数据是很困难的事情，但是使用这些数据更加困难。那个时代人们几乎没有任何形式的可扩展分析能力。
计算尺的出现让情况稍有好转，20世纪70年代出现的计算器使更大数据量的计算变得更容易了一些，但是那个时候的计算器可以处理的数据规模仍然十分有限。20世纪80年代进入主流市场的计算机，真正地把人们从繁琐的手工计算中彻底解脱了出来。然而，20世纪80年代之前出现的计算机只有极少数人可以接触到，而且这些计算机都极为昂贵，操作也相当困难。
几十年过去了，现在人们处理的数据已经远远超过了手工处理时代的数据规模。随着数据规模的快速增长，计算机处理数据的能力也在不断增强，人们已经不再需要进行手工计算了，但海量数据仍然给计算机与数据存储带来了巨大的挑战。
随着数据处理与分析技术的飞速发展，人们可以处理的数据规模也变得越来越大得“可怕”。十几年前，只有超大型企业或某些预算充足的政府部门才可以处理TB量级的数据。在2000年，只有那些最领先的公司才拥有TB量级的数据库，而今天只需要100美元就可以为你的个人计算机买一个1TB的硬盘。到了2012年，很多小型企业内部数据库的数据规模都超过了1TB，某些领先公司的数据库已经达到了PB量级的规模。仅仅过了十来年，数据规模就至少扩大了1 000倍！
此外，随着新的大数据源的出现，数据规模将达到一个新的量级。有些大数据的数据源在仅仅几天或几周，甚至是几个小时内，就可以生成TB或PB量级的数据，数据处理的极限又将面临一次新的挑战。历史上人们驾驭了那些当时看起来很“可怕”的数据，随着时间的推移，这次大数据带来的海量数据也终将被再次驾驭。
在这个时代，一个刚走进大学的一年级新生，他的计算机可能就拥有好几个PB的数据，他会在一些存储了Exabyte甚至是Zettabyte数据的系统上工作，他们希望这个系统能在几秒或者几分钟内给出计算结果，而不是几小时或几天。表4-1列出了目前人们使用的数据规模计量单位，以及随着数据规模扩大而新出现的计量单位。在历史上，第一个探索并成功突破数据极限的人获得了丰厚的回报，未来也一定会这样。
表4-1 数据规模的衡量单位
1 024个单位的…… ……等于1个单位的 注释
KM（Kilobyte） MB 一张音乐CD光盘拥有600MB数据
MB（Megabyte） GB 1GB可以存储的数据量，等于书架上叠起来大概9米多高的书籍
GB（Gigabyte） TB 10TB可以存储美国国会图书馆的全部信息
TB（Terabyte） PB 1PB可以存储的文本，如果打印出来可以装满2000万个4门的书柜
PB（Petabyte） EB 5EB的信息量等于全人类曾经说过的全部词语
EB（Exabyte） ZB 使用现在最快的宽带，下载1Zettabyte的信息需要至少110亿年
ZB（Zettabyte） YB（Yottabyte） 互联网的全部信息量加起来大概是1Yottabyte
4.2 分析与数据环境的关联性
在过去，分析专家在进行分析时把所需的所有数据导入一个独立的分析环境中，这常常是不可避免的。分析专家需要的数据大都不在一个地方，而分析专家使用的分析工具通常也无法直接对这些数据集进行分析，唯一可行的选择就是把数据汇集到一个独立的分析环境中，然后再进行各种分析。分析专家最常做的工作是各种高级分析，包括数据挖掘、预测模型和其他的一些复杂技术，我们会在第7章讨论这些内容。
数据分析师早期做的事情与数据仓库有着有趣的相似性。当人们仔细思考数据分析与数据仓库，常常会惊讶于这两者竟然如此相似。分析师一直在处理各种不同的数据集，这些分析师定义的数据集与数据库里的表并没有本质区别。与数据库里的表一样，分析数据集也有行和列，每一行数据通常代表了某一实体，如一个客户，而不同列则是这个实体的各种信息，如客户名称、消费水平、当前状态等。
分析师一直在把不同数据集“整合”在一起进行分析。猜猜看？数据库里也有一个完全一样的操作，即库内数据表的“连接”。“整合”与“连接”都需要把两个或者更多的数据集或库内数据表进行关联，即把某个数据集或表的某些行数据与另一个数据集或表的某些行数据连接在一起。例如，某一个数据集或表里有客户的人口统计类信息，另外一个数据集或表里有客户的消费支出，把这两个数据集或表关联起来，我们将同时获得每个客户的人口统计与消费支出信息。
另外，分析师还经常做一项叫做“数据准备”的工作。在这项工作中，分析师抽取不同数据源的数据，把这些数据汇集在一起，然后建立分析所需的各种变量。在数据仓库中，我们把这个过程叫做“提取（Extract），转换（Transform）和加载（Load）”，简称为ETL过程。从本质上讲，在数据集市和数据仓库还没有被发明前，分析师们就一直在开发个性化的数据集市或数据仓库了！区别在于，分析师是根据自己的使用需要为不同项目进行开发，而数据集市和数据仓库通常遵循一个标准化的开发过程，并开放给很多人 使用。
20年以前，大多数分析师都在主机系统上进行分析。主机系统里的数据都存储在类似大圆盘的磁带库上。为了让自己的工作能在截止日期前顺利完成，我还记得曾经给主机系统的管理员打电话，请求他们早点加载我的磁带库数据。随着时代的变迁，一个重大的变革出现了，那就是关系型数据库。
关系型数据库管理系统（Relational Database Management System，RDBMS）很快就流行了起来，并且显著增强了数据扩展性和适应性。关系型数据库已经成为了管理数据的事实标准，使用大型主机进行分析在今天已经极为罕见。因此，现在绝大部分用于分析的数据都存储于关系型数据库内。关系型数据库无处不在，但也存在例外情况，如基于MapReduce技术的非结构化数据处理平台。我们将在随后“MapReduce”这一节进行详细阐述。
集中化的企业级数据仓库已经成为了一种趋势，而这种趋势给数据分析，特别是复杂的高级分析带来了巨大的影响。数据仓库把企业内的数据集中到一个地方，分析师们再也不用为了某一项分析把数据挪来挪去进行整合了，数据仓库里的数据已经被整合好了，分析师可以直接进行分析。这些技术开辟了一个新的分析世界，让分析具有了更大的可扩展性与更多的可能性。
最开始，数据库都是为了某一个特定目的或团队构建的，企业里通常存在许多不同的关系型数据库。这些单一目的的数据库通常被称为“数据集市（Data Mart）”。当许多企业还在忙着使用数据集市时，一些领先的公司看到了把不同数据集市的数据集中到一个大系统中的价值，这个大系统叫做企业级数据仓库（Enterprise Data Warehouse，EDW）。
企业级数据仓库的目标是把企业所有重要的数据都集中到一个中央数据库中，从而创建对于事实唯一版本的描述。数据仓库把不同数据进行交叉关联，让不同业务主题与数据领域的关联分析与报表成为可能。财务数据与市场数据完全割裂的时代一去不复返了。
让事情变得更有趣的是，一旦所有的数据都在一起了，分析时就再也不用从不同的数据源抽取数据了。越来越多的分析都可以直接使用数据仓库内部的数据完成。图4-1和图4-2清晰地说明了这两种不同的工作方式。
在传统的分析架构中，主要的数据处理工作都发生在分析环境中，
这个分析环境甚至可能是一台个人电脑！
图4-1 传统的分析架构
在企业级数据仓库环境中，大部分数据源都已经被整合在一起了。如果企业级数据库存在部分数据缺失，那么将从数据仓库中抽取出来的90%～95%的数据与外部5%～10%的数据进行整合分析是完全没有意义的。正确的做法是把外部5%～10%的数据导入数据仓库内，然后在数据仓库内进行分析。换句话说，在数据所处的地方进行分析，而不是把数据拿到分析的地方去，这就是库内分析的理念。
在库内分析的环境中，数据处理一直在数据库内完成，而这也是进行数据整合的地方。
用户的个人电脑只是提交分析指令，而不进行复杂运算。
图4-2 现代的库内分析架构
既然可以在数据所在的地方进行分析，为什么还要耗费大量的时间、人力和金钱把数据抽取到分析的地方呢？这就是库内分析的简洁原则，并将为扩展性带来实质性的飞跃。在大数据时代，不使用库内分析技术，将使驾驭大数据变得前所未有的困难。
在20世纪90年代，Teradata公司是第一家推行库内分析的公司。到了今天，几乎所有的数据库厂商都接受了这个概念。企业级数据仓库，以及数据集市的扩展性和灵活性已经足以支持库内分析过程。库内分析对于大规模并行处理系统更加重要，我们将在随后进行讨论。关键的概念是，就像前面提到的，要在数据所在的地方进行分析，而不是把数据拿到分析的地方去。让数据库做它最适合做的事情，就是管理数据。
今天的大学生可能已经不太了解主机系统，也很难想象在磁带驱动器上进行分析。也许过不了多久，他们将会不理解为什么分析环境与数据环境曾经是彼此独立的，也将无法区分数据分析环境与存储环境。这两者将融为一体不分彼此，因为它本来就该是这样的。
4.3 海量并行处理系统
海量并行处理（Massively Parallel Processing，MPP）数据库系统已经出现几十年了。不同供应商的系统架构可能存在差异，但对于存储并分析海量数据来说，MPP是最成熟、经过验证的、使用最广泛的处理机制。MPP到底是什么？它有什么特别之处？
一个MPP数据库会把数据切分成不同的独立数据块，由独立存储与CPU资源进行管理。在概念上，这有点像把一些数据导入您家里多台电脑构成的网络中。MPP打破了数据被仅拥有一个CPU单元和磁盘的中央服务器进行管理的限制。MPP系统中的数据被切分导入一系列的服务器中，存储于不同CPU单元管理的不同磁盘里。图4-3说明了MPP的原理。
MPP架构的数据库系统将数据分散在拥有独立磁盘和CPU的独立
数据块中，而非一台过载的服务器。
图4-3 海量并行处理系统的数据存储
为什么MPP架构有如此巨大的威力？想象一下，您正在一条六车道的高速公路上开车，假如六车道变成一车道，即使只发生在某一小段距离内，这都会带来可怕的交通拥堵。如果从出发地到目的地始终都是六车道，那么交通会顺畅得多。虽然在某些时刻比如高峰期，拥堵仍然不可避免，但也不会持续很长时间，这让公路状况变好了很多。在非MPP架构的数据库中，即使不是全过程，在某些处理环节，也会出现六车道变成一车道的情况。在车流不多的情况下，一车道也没问题，一旦出现大的车流量就会出现问题。这就是MPP架构处理海量数据时无与伦比的优势，它开放了更多车道让车辆快速通过。
让我们来看一个数据库的例子。假如有一张1T的数据表，一个传统的数据库在同一时间只能查询一行。如果是一个拥有10个处理单元的MPP系统，它可以把这个1T的数据表切分成10份，每份100GB数据，并分配给不同的处理单元。这意味着在同一时间可以同时查询10份100GB的数据。如果需要更强大的分析能力和更快的分析速度，只要增加更多的处理单元，系统能力就会得到提高。
一个海量并行处理架构（MPP）的数据库，会把数据分配给不同的CPU单元和不同的磁盘空间。逻辑上，这类似于拥有几十台甚至几百台个人电脑，每台电脑存储一部分数据。在执行查询时，用不同处理单元同时执行的许多小型查询替代了一个单一的大型查询，查询速度自然就快了很多。
在这个数据库的例子中，如果这个系统升级到了20个处理单元，那么就不是同时进行10次100GB的查询，而是同时进行20次50GB的查询，这相当于100%的性能提升。当查询要求不同数据单元的数据进行信息交互时，事情会更复杂一些，但是MPP系统在设计时就已经考虑到了这一点，因此可以非常快速地处理这种情况，如图4-4所示。
MPP系统会制造一定程度的数据冗余，同一份数据可以同时存储在不同的地方，这样做的好处是，一旦出现系统故障，数据恢复会非常简单。MPP系统里的资源管理工具会管理这些CPU和磁盘空间，查询优化器会对执行的查询任务进行优化，这都使得整个系统变得更容易管理，计算效率也更高。对这些内容更深度层次的讨论不在本书的范围内。
MPP系统把一个复杂的任务分解成很多小任务，让不同CPU单元和不同磁盘
同时执行，而不是执行一个针对所有数据的单一任务。
图4-4 传统查询与MPP查询的比较
4.3.1 使用MPP系统进行数据准备与评分
MPP能够给复杂分析带来巨大提升的原因是，复杂分析的主要困难都发生在数据处理阶段。在数据处理阶段，人们要对数据进行大量的连接与汇总，生成新的衍生数据并对数据进行各种转换。在这个过程中，来自不同数据源的各种数据实现了整合。连接在前面的章节已经介绍过了，而汇总则意味着把多条记录转换成一条记录，从而获得更全面的信息。例如，抽取客户的多条交易记录，计算客户的总体销售量与单次平均销售量。生成衍生指标与数据转换则包含一系列的复杂操作过程，如计算客户每次交易的各类占比，或使用log或平方根等数学函数以获得新的分析指标。
这些数据处理任务的逻辑通常来说并不复杂，这正是关系型数据库，以及结构化查询语言（Structured Query Language，SQL）适合执行的任务。对大多数分析而言，今天的SQL，即使不能支持所有也可以支持绝大部分的数据处理工作。SQL的使用正是库内处理理念在MPP系统的具体表现。分析师再也不需要把数据从数据库中抽取出来并通过分析工具进行处理，相反地，他们可以简单地通过撰写并提交SQL脚本，就可以把这些复杂的数据处理工作交给数据库执行。
仅仅在10年前，SQL还存在一些缺陷，难以支持高级分析需要的某些复杂计算。但现在，SQL已经强大了许多。事实上，SQL的一些限制条件已经不存在了，例如，SQL在处理某一行数据时不能了解其他行数据。现在已经出现了一些叫“窗口式汇集（Windowed Aggregates）”的SQL函数，它们可以在处理某一行数据的同时，对其他区域的数据进行查询。通过这些SQL函数，查询某一个交易是客户的第一次还是最后一次交易就很轻松了，这使得数据处理过程也发生了变化。某些高级分析工具为数据准备过程提供的处理过程，完全可以使用SQL的这些函数来实现。
在SQL拥有这个强大功能之前，为了进行必要的数据处理，人们不得不把数据从数据库中抽取出来。幸运的是，随着SQL的发展，已经不再需要这样做了。数据处理过程中的绝大部分操作都可以通过SQL在数据库内实现。最近也出现了一些新的整合处理方式，我们将会在后面进行讨论。
在过去的这些年，SQL已经强大了很多，现在它可以胜任几乎所有的数据处理任务。分析专家可以使用SQL或者其他分析工具把数据处理过程提交给数据库执行，从而显著扩大了分析人员可以处理的数据规模，而这对于大数据格外重要。
作为库内处理理念的发展趋势，分析工具的很多厂商已经开始在分析软件中内置把分析流程提交给数据库执行的功能。在这些工具里，这些分析流程都已经开发好了，但是这些软件现在发现，如果可以连接到MPP数据库引擎，软件就可以把处理复杂任务的指令提交给数据库，让数据库来执行处理任务，而无需抽取大量数据。
分析工具将分析流程内置到数据库中的演进过程意味着，分析专家现在可以自由地选择他们感到顺手的、具有高度可扩展性的分析环境。与此同时，分析应用仍然在将更多的功能和特性集成到MPP数据库中，这将进一步增加库内分析的影响力。
库内处理也被广泛的用于各种评分模型。通常，我们会使用抽样数据来建立模型，但使用这个模型来进行评分，则需要针对全部数据。例如，通过部分抽样的客户数据建立了一个客户购买倾向的评分模型，到了应用这个模型时，则需要对所有客户进行评分，这样才能挑选出得分最高的客户来进行营销。把所有数据从数据库中抽取出来进行评分的传统做法，即使不是完全不可行，也是不实用的，因为抽取全部数据进行处理会耗费大量的时间。
让我们看一个更细节的例子。假如某一个零售商已经建立了一个倾向模型，来评估哪些客户更有可能参加某一次促销活动。这个模型通常是建立在抽样的客户数据上，可能只覆盖了几百名或者几千名客户。模型会使用对比的方法，分析历史上曾经参加过类似活动的客户与没有参加过类似活动的客户，进而建立一个评分的算法，计算出每个客户参加本次促销活动的概率。
在构建这个模型时，从数据库中抽取数据进行外部处理，这是可行的，因为这是一次性的行为，而且只涉及到部分抽样客户。当使用这个模型时，评分算法要对零售商的所有客户进行打分，这样才能精确识别那些最有可能响应促销活动的客户，这可能会涉及成千上万的客户。此外，这个评分过程通常还需要定期执行。在这种情况下，由于涉及所有的客户数据，把数据从数据库中抽取出来可能导致系统崩溃，而库内分析则可以避免这种现象的出现。
今天在数据准备与评估模型过程中，把处理过程提交给数据库执行的方法至少有4种：（1）直接提交SQL；（2）自定义函数（UDF）；（3）嵌入式过程；（4）预测建模标记语言（PMML），接下来我们将逐个进行阐述。
1．直接提交SQL
SQL是MPP系统的母语，在各种要求与场景下都有很高的执行效率。在前面我们讨论过，SQL特别适合进行各种典型的数据操作，如关联、转换、整合等。很多核心的数据处理任务都可以通过编写SQL脚本来直接实现，用户也可以使用各种分析软件，让软件自动生成SQL脚本并提交给数据库执行。常用的分析模型与算法，其评分逻辑都不是很复杂，可以很容易地转换成SQL，如线性回归模型、逻辑回归模型、决策树模型等。分析工具可以帮助用户从这些分析模型中抽取出数据处理逻辑与过程，并将其转换为SQL。或者，有些时候，模型完成后用户也可以选择自己编写SQL。但不管是哪种情况，数据准备或评分过程都是全部通过SQL完成的。
2．自定义函数（UDF）
自定义函数（User-Defined Function，UDF）是关系型数据库的一个相关的新特性。UDF的处理能力大大超越了普通的SQL。UDF可以让用户自定义一些可以重复使用的数据处理逻辑，并像SQL自带函数一样自由地使用。
例如，要查询客户的销售总额，分析专家可能会写这样的SQL：
“Select Customer, Sum(sales) …”
如果要查询客户某一项属性的评分，使用UDF的SQL可能会是这样：
“Select Customer, Attrition_Score…”
在这个SQL语句里，“Attrition_Score”是一个已经被部署在关系型数据库内的自定义函数。这个函数可以在任何时候被使用，其内部包含比纯SQL更复杂的处理逻辑。
UDF通常使用C++或Java等编程语言进行开发。使用这些编程语言，使得编程语言的某些特性嵌入了SQL中，这让SQL获得了一些新的功能，而这些功能通过SQL往往是无法实现的。UDF的一个缺陷是，不少分析专家并不了解如何使用这些编程语言开发UDF，但幸运的是，很多分析工具都已经提供了自动生成这些函数的功能。这些分析工具可以帮助分析师生成合适的UDF，并将它部署在数据库里，分析师可以直接使用这些自定义函数。
3．嵌入式过程
嵌入式过程（Embedded Process）是另一种把处理任务提交给数据库执行的方法。嵌入式过程的集成程度要比刚才提到的自定义函数高得多。自定义函数是编写一段程序，并将其部署在数据库内，让其他的SQL语句能够随意地调用它。对使用者来说，这个分析函数与其他分析工具提供的原始代码没有什么不同，都可以在数据库中并发地调用。区别在于，分析工具提供的原始代码通常不得不转换为数据库语言，以提高在数据库内的处理效率。
对于嵌入式过程，情况就完全不一样了。嵌入式过程是将分析工具的处理引擎直接运行在数据库中。嵌入式过程具备在数据库内直接运行程序的能力。嵌入式过程充分利用了那些已经被部署在数据库内的分析程序。当需要运行某一段分析程序时，为了利用数据库的并行处理能力，嵌入式过程会把分析程序运行在数据库的每一个处理单元上。嵌入式过程不需要转换脚本语言，只需要修改很少的内部代码，但部署嵌入式过程会比较困难。各个分析软件与数据库供应商们已经开始广泛地研究并应用嵌入式过程。在不久的将来，嵌入式过程将成为一种可选的处理方法。
4．预测建模标记语言（PMML）
预测建模标记语言（Predictive Modeling Markup Language，PMML），可以把模型结果从一个分析工具导入另外一个工具中。从概念上讲，PMML包集成了预测模型进行准确预测所必需的各种信息，与模型无关的信息则不包含在内。一个PMML包的内部信息通常包括模型类型、变量名称、变量格式以及必要的参数值。 分析师可以使用任何兼容PMML的分析工具开发分析模型，当模型开发完成后，如果要把这个模型部署到另外一个兼容PMML的工具内，那么分析师只需把PMML文件直接导入新的工具，新工具内的评分模型就可以使用了。
PMML有一个不那么明显的缺点。要使用PMML在新的工具和环境下部署分析模型，前提条件是这个新环境内的变量名称和数据格式，必须和开发模型的原始环境中相应的名称和格式完全保持一致。例如，开发某一个模型时，某一个输入变量叫做“SumOfSales”，代表客户在某一段时间内的消费总额，格式是数值类型。那么，使用PMML在新的环境下部署这个模型时，就要确保在新的环境下也有“SumOfSales”这个变量，并且名称、含义、格式都完全相同。这意味着人们不得不在新系统里再次创建这个变量。
最初，很多分析专家认为，在开发模型时使用PMML，意味着他们不需要去考虑库内处理的问题。他们认为，使用分析工具开发好了模型，利用PMML就可以轻松地把模型部署到关系型数据库内了。这种想法是错误的，PMML要求不同环境下的数据变量完全一致，但事实上这不太可能出现。因此，在利用PMML部署模型前，如果分析师在数据库之外对数据进行了一些处理和转换，那么这些操作必须在数据库内完整地重复执行一遍。PMML并不负责任何数据准备的工作，它只是把同样的算法直接应用于最终数据，而PMML假定这些数据都已经被处理过了。
PMML的确强化了在数据库内进行数据准备的必要性与好处。如果分析工具在数据库外部进行了任何形式的数据处理，这些过程必须在数据库内重复执行一遍，以确保PMML能正常工作。为什么要在2个环境中重复地执行数据处理过程呢？还是直接在数据库里执行吧。
PMML确实强化了库内处理的必要性。为了确保PMML高效地工作，建模所需的输入数据必须提前准备好。这些数据不能有任何变化，分析算法必须能够直接使用。只有这样，PMML生成的模型评分代码才能立刻开始工作，否则就需要在部署环境下进行数据的重新组织与二次处理。
新版的PMML已经开始具备部分特定的数据处理能力，但要彻底弥补我们提到的这个缺陷，PMML还有很长的路要走，这也限制了PMML的应用范围。
4.3.2 使用MPP系统进行数据准备与评分小结
海量并行处理平台（MPP）是当代数据分析架构中价值很高且越来越重要的一种方法。今天，大部分大型企业都已经建立了企业级的数据仓库，对企业内大量的重要数据进行集中管理，而小型企业则通常选择建立各种数据集市。越来越多的数据处理过程将在数据仓库内进行，这种趋势将会长期地持续下去。
任何希望提高自身分析能力的公司，都必须了解并使用MPP。在数据规模持续增长的今天，为了进行某项分析，除非完全不可避免，我们都不应该把数据从仓库中抽取出来。使用MPP可以给企业带来分析可扩展性的额外提升，扩大可分析数据的广度与规模。不管是传统数据、大数据还是这两类数据的混合体，均可以使用这种处理方法。
在我们结束这一小节前，还要讨论最后一个主题。当企业级数据仓库已经成为分析环境的核心主题时，许多MPP系统供应商也开始提供比数据仓库性能略低的“一体机平台”系统。这些一体机平台系统是为某一些特定目的而设计的，例如，高级分析团队希望对海量数据进行复杂的处理。区别在于，企业级数据仓库能支持许多不同类型的数据管理工作，而这些一体机平台只能支持某一种或特定的几种数据管理工作。
高级分析也是分析系统承担的一项工作，而且是很重要的一项工作。当计划使用企业级数据仓库支持高级分析时，要确保数据仓库也能同时完成其承担的其他工作，如报表或查询等，通常所有这些工作都在数据仓库中同时进行。如果数据仓库实现不了，可以考虑部署独立的一体机平台系统。这些独立的一体机平台系统的价格是可以接受的，并且遵循与MPP架构一样的设计原则。
4.4 云计算
最近云计算的概念得到了越来越多的关注。就像很多的其他热门技术一样，云计算也曾被大肆地炒作。在详细论述前，我们必须先定义什么是云计算，它是如何帮助高级分析与大数据分析的。跟所有的新技术一样，云计算也存在不少互相冲突的定义，我们会讨论其中的两种定义，作为进一步论述的基础。第一种定义是麦肯锡公司在2009年的某一份报告中提出的。 这篇报告认为云环境有以下3个最重要的特征。
1．企业无需进行基础设施建设，没有固定资本的支出，有的只是运营成本。这些运营成本是根据使用量付费的，并没有合同对这些运营成本的金额进行限制或要求。
2．系统能力可以在很短的时间内显著地扩大或缩小。而传统的IT托管服务提供商存在系统扩展性的限制，无法做到这一点。这也是云计算与传统托管服务的区别。
3．云计算的底层硬件可以在地理意义上的任何地方。这些硬件设施对于最终用户来说是抽象的、透明的。而且，这些硬件的租用模式是多样化的，某一硬件设备可以在同一时间被不同公司的不同用户使用。
只有同时满足这3个条件，才能将其称之为真正的云计算。对用户而言，底层硬件是未知的、变化的，可以根据需求弹性地调整系统能力，还可以按用户的使用量进行计费。
云计算彻底地解决了资源的约束问题。用户在需要的时候可以获得任何想要的系统资源。当然，他们要为此付费，但他们只为自己的使用付费。系统管理人员对资源的争夺再也不存在了。当你要求云计算跳起来，它不会和你争论是否应该跳，而是直接问你，“你要我跳多高？”
另外一个定义来自于美国国家标准技术研究所（National Institute of Standards and Technology，NIST），这是美国政府商务部的一个分支机构。它列出了云环境的5个必要特性。
1．按需的自助服务。
2．高速网络接入。
3．资源池。
4．快速的系统弹性。
5．可以衡量的服务。
同时满足这5个特性的才是云计算。很容易就能发现，麦肯锡的定义与NIST的定义有很多相似之处。你可以在NIST的网站获取更多云计算领域的相关信息。
任何事情都有好的一面和坏的一面，有强项与弱项，有优点与缺点，云计算也一样。一个组织要了解足够多的信息以做出正确的选择。毋庸置疑，未来在高级分析领域，云计算将得到越来越广泛的应用，开发类的工作更是如此。但随后我们也将看到，对于生产性的工作，云计算的应用方式还不是非常清晰。我们将讨论2种不同类型的云：（1）公有云；（2）私有云。
4.4.1 公有云
公有云已经获得了相当多的宣传与关注。对公有云的用户来说，他们将自己的数据上传至外部的某一云计算系统中，获得系统所分配的资源以进行数据处理工作，最后系统会根据用户的使用量向他们收取相应的费用。
这种模式很显然有许多优点。
网络接入是必要的，用户只为他们的使用而付费。
用户不再需要去构建一个能满足其最大资源需求的系统，然后承担大部分时间系统资源闲置的风险。
如果有突发性的任务处理需求，在公有云环境下，用户可以很快地得到新的系统资源，用户只需要为这些新资源付费即可。
系统部署通常来说很快。只要可以连接到公有云环境，用户上传了自己的数据，立刻就可以开始分析工作。
根据公有云的定义，数据是保存在企业内部防火墙之外的系统中，这让不同区域之间的数据共享变得相当简单，任何人都可以被授予登录系统并使用这些数据的权限。
同时，公有云也存在一些缺陷。
通常来说，公有云不会提供性能方面的承诺。根据公有云的定义，在同一时间可以有很多人对同一份数据或资源发起一系列的大型查询。当然，您也可以购买一台只供您自己使用的云服务器。
这会带来性能方面巨大的不确定性。一旦提交了一项处理任务，系统能在多长时间内完成是不确定的。历史的经验可以作为判断依据，但并不能保证这一次会一样。
对数据安全性的担忧一直存在。虽然很多人可能认为这种担心没有必要，因为这只具有理论上的可能性，但人们对数据安全性的认识本身就是一个大问题。
如果被广泛地使用，公有云可以变得非常昂贵，因为它会对每一个用户的所有使用行为进行收费。效率不高的“坏”查询可能会耗费大量的系统资源，而现在这些“坏”查询在你自己的系统里也会出现，但不会带来任何直接的实际成本，而在公有云环境下，你却可能因此被收取一大笔费用。
如果需要对数据进行持续跟踪，并对数据的保存地域有明确的要求，那么就无法使用公有云。在公有云环境下，你甚至无法确定数据是不是还全部保存在本国范围内。
通过上面的分析，你认为公有云适合哪些场景？哪些场景不适合使用公有云？
云计算的硬件资源是弹性的，这意味着在任何时间都可以很容易地增加新的硬件资源。这也意味着可以很容易地在某一台服务器上增加更多的CPU、存储与内存，然后获得更多的计算能力。在任何时候，你也可以直接使用10台或更多的服务器，只要你为此付费。请注意，这种扩展性与MPP系统的扩展性是不同的。公有云的大部分服务器是各自独立运行的，MPP则是一个单一的大系统。如果一个企业有许多中小型的处理过程和任务，云计算将可以发挥巨大的作用。然而，假如有一些超大型任务，且每个任务都超过了单个云计算服务器的处理极限，这时云计算就没什么用了。虽然MPP软件可以在云内运行，但云环境下的底层硬件设备是不确定的，可能随时发生变化，这对MPP软件的处理性能有非常不利的影响。
也许，对公有云来说，最适合的使用方式是纯粹的研发类工作。在这种情况下，系统性能的不确定性变得没那么重要。如果一个分析专家想对某些新的数据进行实验性地探索研究，希望发现这些数据的价值，公有云则是一个非常好的选择。分析专家可以把大部分的时间放在分析、探索等工作上，而不需要考虑性能的问题。只有在准备进行分析流程的部署时，系统性能才会变成一个关键问题。对于那些不是非常重要的分析流程，甚至某些流程的部署工作，公有云都是一个可行的长期选择。
当数据安全是一个大问题时，公有云也将麻烦重重。有必要为公有云应用好的安全协议和工具，并保证公有云环境的高度安全性。唯一不在你控制范围的是，云服务提供商企业中的员工。如果他们是某种程度上的小偷或者黑客，他们将会对使用公有云的企业造成损害。这样的事情发生的概率极低，但是安全漏洞造成的公众抗议将更加严重，尤其是造成安全漏洞的是云服务提供商企业的员工而不是使用该服务的企业的员工时。将敏感的数据放到云上需要制定一个强大的安全计划，否则，永远不要这么做！
如果分析专家只考虑自己一个人，那么使用公有云确实要比购买一套专用设备便宜得多。但涉及大型企业，情况可能会发生变化。一旦许多不同的人和部门都开始使用云，也许人们很快就会发现，他们为公有云的每次使用支付了更多的钱，远远超过了建立一个自己的专有系统。
关于公有云还有另外一个常常被忽视的有趣现象。如果只有小部分任务需要被执行，使用公有云确实要比购买一个专有系统便宜。但在某些时候，使用公有云也可以比拥有一个专有的内部系统昂贵。一旦企业有大量的用户开始使用公有云，且他们都按照每次的使用量进行计费，那么购买一个企业自用系统反而会便宜得多。比节约成本更重要的是，公司可以对这些内部系统进行全面地管理控制，进而提升这个系统的性能。
随着时间推移，也许某一天，公有云可以以某一个合适的价格为企业级的关键任务功能提供服务。但在今天，那些提供更高等级性能保证的云计算供应商，它们会为这些更高品质的服务向用户收取比基本云服务昂贵很多的费用。此外，不管是事实还是一相情愿，云计算确实有可能满足某些安全性的要求。但在这些变成现实之前，大部分企业使用公有云的范围，只可能集中在研发类的工作上。
4.4.2 私有云
私有云拥有与公有云完全相同的特征。唯一的区别是，私有云是某一企业拥有的，且通常部署在企业的防火墙内部。私有云提供与公有云完全一样的服务，但是服务对象仅限于企业的内部人员和团队。图4-5说明了公有云与私有云的区别。
图4-5 公有云与私有云的比较
部署在企业内部的私有云有一个巨大的优势，就是企业拥有对这个系统的全部控制能力，包括数据与系统的安全。数据是无法跳出企业防火墙的，所以企业完全没有必要去担心数据到底在什么地方。私有云的数据安全性与其他的企业内部系统是完全一样的。
私有云的一个缺陷是，当你为用户提供服务前，你必须购买并拥有一整套的云计算设备，这在短期内可能会给公司的成本支出带来不利的影响。与公有云相比，公司在第一年花费的钱可能一下子增长了很多，但是随后的那些年，假如公司的大部分任务都在云内进行，私有云的成本反而会比较低。长期来看，如果有大量的用户持续使用云环境提供的服务，私有云的成本会比公有云低得多。
长期来看，如果有大量用户，私有云的成本会比公有云低得多。然而，由于需要启动资金与建设成本，实施私有云在短期内可能会给企业带来更高的费用支出。随着时间推移，这种情况就会逆转过来。
在概念上，私有云与我们将在第5章中讨论的分析沙箱没有很大的差异。两者的主要区别在于，一个真正的私有云会为用户提供充分的自助服务功能，而分析沙箱则要求系统具有更强的管理能力。这两个概念的确有些相近，在某些使用方面甚至是相同的。对于支持高级分析，可以说两者或多或少是在做同一件事情。其中一个区别是，如果使用私有云，并完全遵循云的规则与定义，系统负载会持续动态地发生变化，这可能会给系统管理带来不小的麻烦，用户可能不得不互相争夺资源。而在分析沙箱的环境中，当需要资源时，系统可以为团队分配一些确定的系统资源。系统资源确定的对立面是，如果你想得到额外的新资源，分析沙箱的用户要付出比私有云用户更多的努力。
4.4.3 云
