本节书摘来自异步社区《数据分析变革：大数据时代精准决策之道》一书中的第2章，第2.3节，作者【美】Bill Franks（比尔•弗兰克斯），更多章节内容可以访问云栖社区“异步社区”公众号查看
2.3 纵观全局看待大数据
大数据是如何适应现状的？为什么说大数据具有特殊性？大数据以后发展方向是什么？这些问题都很常见，大多数企业都会碰到。就像所有新鲜事物一样，关于大数据究竟能干哪些事情，肯定也会出现混淆和不一致的地方。本节探讨的正是那些必须理解的主题和概念，这样我们才能纵观全局，全面地思考大数据。把大数据放到正确的背景下思考，这样在使用大数据做运营型分析时，会更容易达成目标。
2.3.1 与其说是大数据，还不如说是差异化数据
正如本章先前所述，大数据让人兴奋的原因之一是它包含了新的信息。但是，许多人都认为造成大数据挑战更多的原因只是大数据的体量巨大。数据体量其实并不是让许多大数据源与众不同的原因。关于大数据，通常最有挑战性的是不同的数据类型和不同格式的数据，我们能从中发现它所蕴涵的一些新信息，因此需要不同的分析方法。
以往，我们在商业环境中收集的用于分析的数据多是事务性的、描述性的、结构非常好的。这意味着，这些信息可以清晰识别，方便阅读。例如，电子表格中Sales列的数值以美元表示。企业里结构较差的数据，譬如书面文档或图片，往往无法用于分析。大数据技术出现以后，企业碰到了新的数据类型和格式，与传统数据源相比，它们当中很多都缺乏结构性。例如，传感器吐出的信息格式是很特殊的，GPS数据描述的则是人和物在空间中的位置信息，人或企业之间的关系强度往往也是重要数据。从数据格式和数据分析方法看，这些数据的类型完全不同。我们将会在第7章中讨论各类分析。
“差异性”其实比“数据之大”更有挑战性
大数据中的“大”得到的关注度最多，但往往大数据的“差异性”才是真正具有挑战性的。新的数据源多种多样，新的格式也富于变化，同时，信息类型也是新的。弄清楚如何从数据中提取出我们所需要的数据类型往往要比弄清楚该如何扩展分析流程投入的精力更多。
分析社交网络，评估人与人之间发生关系的数量与强度，需要完全不同的销售预测方法。大数据的“差异性”其实比“大数据量”带来的挑战要更大。为什么说它的挑战性更大呢？下面我们来看一个例子。
比方说，某家企业要首次启动做文本分析。他们要分析几千封电子邮件，准备好文本分析工具，配置好这些工具，定义好企业将会应用的文本分析逻辑。处理1万封邮件，与处理1千万封邮件和1亿封邮件，刚开始构造文本分析流程的时间和投入其实是差不多的。随着处理邮件数量的增长，应用逻辑必须要具有一定的可扩展性。因为文本是一种完全不同的数据类型，所以我们肯定要做一些准备工作，即使对于少量文本数据来说也是如此。
当然，在我们执行定好的数据分析流程时，1万封电子邮件的处理速度肯定要比1亿封邮件快得多。数据量增加需要流程具备可扩展性，但底层数据分析逻辑还是相同的。弄清楚如何处理大数据之间的差异性是我们需要迈出的第一步。如果我们能够处理差异性，我们就可以进而弄明白如何在不同尺度上处理数据的差异性。
2.3.2 大数据必须具有多维可扩展性
关于大数据带来的挑战，越来越多的关注放在了问题规模本身。尤其是，以往我们关注的是数据量和数据处理的规模。但是，如图2-3和图2-4所示，如果要在整个企业层面上实现分析，特别是当我们要实现运营型分析的时候，我们还需要在其他维度上也具备扩展能力。
首先，在用户数和用户多样性上要有扩展能力，因为用户既有存取底层数据的需求，又需要访问构筑于其上的分析流程所产生的结果。在任意时间，数以万计的员工都能看到不同的原始数据视图以及分析结果。企业平台必须对用户友好，可以兼容多种工具及应用。
扩展性不只在于存储和处理能力
在讨论大数据扩展性挑战时，我们更多关注的是存储和处理能力的可扩展性。有些关键维度必须具备扩展性，但往往会被忽视，其中就有用户数、并发度、负载管理以及安全性等。如果系统在这些维度上缺乏扩展能力，那么企业就不会获得运营型分析的成功。
其次，另一个可扩展性的关键需求是并发度。并发指的是在相同时间内能够访问给定信息集的用户或应用数。企业级并发还意味着数据虽然会不断变化，但用户接收到的答案却能保持一致。随着并发度的提升，如果系统缺乏工程化实践能够应对相应的处理请求，风险就会逐渐加大。如果大型企业要构造自己的运营型分析流程，就必须有一个环境，让各种不同的用户和应用可以同时存取和运用相同的信息。
再次，负载管理工具也要有可扩展能力。在架构上面的安全层上，不同用户类型会提交各种不同的分析请求，必须有软件可以对负载实施管理。平衡并发请求本身就不是一项简单的任务，我们很容易忘记这方面的可扩展性。我们构造的系统既要能有效地管理很小的战术请求，同时还要能管理非常大的战略请求，这是非常困难的。
最后，安全协议也要有可扩展性。企业必须能锁定数据，按需进行访问控制。用户只允许看到授权自己可以看到的数据段。大型企业在构建平台时，必须要以一种健壮的方式把安全性构筑其中。
所有这些可扩展的维度——数据量、处理能力、用户数、并发度、负载管理及安全性，从一开始时都是互有依赖的，只有都做到，运营型分析才能成功实施。只关心存储能力可扩展性和处理能力可扩展性的企业注定会失败。
2.3.3 实现大数据价值的最大化
我曾见过的最常见错误类型之一是，企业虽然很努力地要把大数据融入现有的分析流程当中，但他们却认为大数据是一个完全独立的特殊问题。许多公司都成立了内部机构，负责处理大数据，而且只处理大数据。[11]事实上，有些企业会远去硅谷设立办公室，开展自己的大数据业务。这其实是在自找麻烦，因为最重要的是，大数据只是总体数据和分析策略的一方面而已。我们的策略应该是唯一的、内聚的，可以同时处理所有的数据，无论是大是小，如图2-5和图2-6所示。
下面我们看一个相似情形，它说明了为什么缺乏单一数据和分析策略就会有问题。电子商务时代到来时，许多零售商没有想清楚电子商务只是零售策略的另一面而已。相反，许多零售商对待电子商务的态度就好像它是全新的一样。于是，许多零售商都成立了独立部门来应对这些电商活动。有时候，该部门还会有一个独立的法务实体。这些独立实体都有自己的供应链流程、自己的产品体系、自己的定价策略等。
现在，让我们快进到今天的状态。同样还是这些零售商，他们渴望拥有自己的唯一业务视图。他们想让自己的电子商务和其他店面不仅在统一视图之下，而且还想跨渠道提供无缝的客户体验。在体系与系统完全不兼容的场合，零售商是花了很多年投入了很多资金才完全接受这些内容的。
制定整体的数据及分析策略
我们必须使大数据成为数据与分析整体策略的另一个组成部分。如果做不到这一点，就会面对零售商所面对的同一类问题，刚开始的时候不会把电子商务看作是零售策略的另一方面。
10～15年前零售商清楚地认识到电子商务会带来新的挑战，但他们其实还应该认识到电子商务应该与他们的整体零售策略是相契合的。电子商务要以某种方式与核心业务进行整合，刚开始的时候，花的时间要多一些，但长期来看，节省的时间和资金会大得多。
一定要确保我们的企业不会在大数据上犯相同的错误。前面多花一些时间，这样才能想清楚大数据如何才能与数据分析整体策略相匹配。这是非常重要的，因为数据源本身不会提供最优价值。把多种数据源合在一起，是实现价值最大化的唯一方法。例如，我们需要把销售数据、网页浏览数据、人口属性数据以及更多的数据组合起来，这样才能充分理解客户。
企业如果在建立独立的大数据系统和流程时没有先行考虑数据整合需求，在后端产生期望价值就会困难得多。公司的工作目标是创设整合分析环境，让大家可以在任何时间在任意类型和数据量的数据基础上执行任意类型的分析。我们将会在本书中更细致地探讨如何让这一点变为现实。对于那些希望从大数据中获得深入营销价值的读者，推荐阅读我的同事Lisa Arthur所撰写的《大数据营销：如何让营销更具吸引力》一书。[12]
2.3.4 回到未来
大数据现在热炒的概念之一是，非关系型工具集并非是以关系数据库为基础的，这是一个全新的世界，根本不需要用SQL作为主要的接口。SQL即结构化查询语言，它已经被称为“商业语言”很多年了。其实，就算应用的话，非关系型工具集也不会只使用SQL语言。非关系运动背后的基本前提是SQL虽然在许多公司里是唯一的商业语言，但肯定还需要其他类型的语言。毕竟，商业环境为什么就不能是多语言的呢？其实本应如此，而且应该一如既往地如此下去。
下面我们来直面炒作中的致命缺陷。事实上，非关系型分析并非新概念。在我开始分析生涯时，在商业界，关系数据库还不存在。当然SQL也是不存在的。因此，我们所做的只是基于非关系型方法来生成分析结果。至于我，我通常愿意使用SAS工具。对于我这样的人来说，SQL就像街区上新来的孩子一样。过上一段时间后，我们这些专业分析人员都注意到SQL是一种比较好的方式，可以用来处理某些类别的问题。当然，肯定还有某些处理要求专业分析人员在SQL环境之外执行。
大数据带来的真正改变之一是，企业重新发现了在SQL环境之外展开处理的价值。碰巧在大数据源的条件下做出非关系型的选择要比在传统数据源下更有意义。许多公司其实做过头了，要把所有处理规则都往SQL上扔。这其实是个错误，企业肯定还要把其他选项加入到这个行列当中。对于我们来讲，只需记得非关系型方案一直可用就可以了。21世纪头十年，并非没有非关系型处理的需求。只是说公司朝SQL这个方向走得太远而已。可以想象，未来SQL肯定还是主流的数据分析方法，而非关系型分析关注的则是特殊需求。
大数据，大转变
预言SQL将亡的声音延续了很多年，非关系型平台在争着抢着实现SQL接口。尽管这是巨大的转变，但它也反映了业务需求的现实。
如果可以，企业应该赞同使用非关系型工具集，但不能简简单单地就认为这么做会否定他们身边的SQL需求。我们很容易滑向另一个极端，今天就有许多人在冒险那么干。这么多年来，很多人都曾经做出过SQL将亡的预言。在思想观念发生巨大转变之时，在Hadoop等大量非关系平台上支持类SQL功能，也是一场声势浩大的运动。我们要再次回到未来。在第5章和第6章中，我们要大谈这个趋势，以及该如何利用合适的处理手段。
2.3.5 大数据正在经历成熟度曲线
很多人都曾经跟我讲过，大数据压得他们喘不过气来。太多新的数据源和太多新的事情要处理，许多企业根本弄不清究竟该如何开始和如何处理。千万不要沮丧，大数据正在经历的是与其他任何新的数据源完全相同的成熟度曲线。[13]现实状况是，新数据源首次可用之时，肯定是充满挑战的。我们往往不能明确如何才能最好地使用新数据，要从数据中创建哪些指标，发现哪些数据质量问题，以及诸如此类的问题。但是，经过一段时间以后，对于数据源的处理就会变成标准化流程。
许多年前，当我第一次分析POS数据时，我的团队和我都弄不清如何才能用好数据来分析客户行为，并得到较完美的业务结论。我们更想不清楚，如何才能使数据分析运营化。我们有许多理论和想法，但究竟可不可行本身是没有得到验证的。当然，我们没有把数据的输入、准备和分析过程标准化。一段时间过后，对POS数据的定期分析会让所有这些层面都实现标准化。今天，我们都认为POS数据处理起来很简单，可以应用到各种各样的问题上。
不要气馁
首次分析新数据源的时候，总是让人恐惧。一段时间过后，我们的理解就会逐渐成熟，数据用起来也开始得心应手。大数据也会出现相同的成熟过程。但大数据的情况好像要更糟一些，因为我们同时要处理太多的数据源。
面对每个新的数据源，企业会经历与图2-7所示大致相同的过程。大数据的根本不同在于，以往企业每隔几年才会面对一个全新的独立数据源，但在大数据时代，企业会同时面对多种新的数据源。
如今，专业分析人员的职责变成了要同时分析社交媒体的互动数据、客服会话数据、网站行为数据、传感器数据等内容。我们必须要在一套分析流程中同时使用这些数据。这样，我们会有同时经历成熟度曲线的多个数据源被同时应用。对于单一数据源而言，这种情形带来的挑战更大。更糟糕的是，如前所述，我们要考虑的不只是如何处理每个数据源，还要考虑如何把它们关联起来。
我们既不能忽视新数据处理的内在困难，也不能一上来就被它们吓倒。成功的道路上肯定布满荆棘。数据融合与分析方法必然会在很大程度上实现标准化，而现在一切都很好。我们要做的是转向处理下一个新的数据源，而这也正是大数据领域将要发生的和正在发生的事情。
2.3.6 大数据是全球现象
关于大数据，最后一个值得讨论的趋势是，对于大数据的认知和成熟度，如何在全球形成一致性。[14]在采纳曲线和成熟度曲线上，有些企业走得很靠前，有些企业走得靠后。说起来，我还去过几大洲，找过银行、保险公司、零售商和政府机构。我感到每个地球人都在思考几乎相同的问题。海关、法规虽然说肯定受本地市场因素的影响，但它们描述的基本业务问题却是高度一致的。同时，多数人会认为，其他行业以及世界其他地方的发展都要比自己的企业好，然而现实状况往往并非如此。
数学、统计学、分析和数据既没有以某种语言沟通交流，也不隶属于某种文化现象；相反，它们从本质上就是全球化的。中国的趋势图与西班牙的趋势图看起来一模一样，传递的信息也很相近。印度算平均值的方法与德国肯定是相同的。日本的交易记录与巴西的交易记录也有相同的信息。除了极少数情形，宣传大数据在某国某个行业独树一帜，所言定然不实。
你的企业可能并非那么落后
对于大数据，全球的公司目前所面临的问题都非常类似。不管哪儿的企业，它们的感受往往都一样，自己处在其他行业之后，在自己的行业里也靠后，与全球其他区域相比也靠后。既然每个人都认为其他人是先进分子，许多时候，差距其实比想象中要小得多。
形成同行业人脉关系，这事儿全球都差不多，社交媒体让一切变得简单了。其他企业面临的问题可能与我们的企业完全相同。但是，我们自己企业的数据分析肯定不可能与直接竞争对手之间展开有价值的讨论话题。不过，我们肯定能与地球另一面没有竞争威胁的人们进行对话。信息与经验教训的分享，企业都能获益良多。
不管我们的企业正在经历着大数据带来的何种阵痛，我们完全可以相信，其他企业其实也在经历着类似的痛苦。过上一段时间，就会出现针对这些痛点的解决方案，而这些方案也会迅速传遍大江南北。在运营型分析中融合大数据变得越来越容易，越来越常见。我们肯定算不得是世界上第一次解决某些问题的企业，但我们不能守株待兔，直到问题能够充分解决，我们才会往下走。在这一点上，我们要付出的努力无非是往前追、往前赶而已。跟随策略肯定不是我们的致胜法宝。
