大数据的演化史

文章来源：

1 大数据时代

1.1 背景

工业革命之后，书籍等以文字为载体的知识大约每十年翻一番；1970年以后，知识大约每三年就翻一番；如今，全球信息总量每两年就翻一番；2010年互联网的数据量，比之前所有年份的总和还要多。
现在，人类每天产生数以PB的数据。在互联网、电子商务、生产制造、交通和物流、金融和保险、医疗卫生、地理信息、政府机构等行业，每天都在创造着大量的数据。大数据正在成为从工业经济向知识经济转变的重要特征，已经成为新时代最关键的生产要素和产品形态。
Google、Yahoo、Facebook等公司正成为这场变革的推动力量，同时新企业也层出不穷。在商业智能（BI）领域，AsterData、Greenplum、Vertica等公司刚刚卓然而生，便被传统IT巨头EMC、IBM、HP等公司各自收入囊中。经过对这些新生公司的大数据技术进行消化和整合之后，传统IT巨头们迅速推出了各自的大数据产品和服务。

1.2 大数据的定义

大数据（Big Data）通常用来形容一个公司创造的大量非结构化和半结构化数据，这些数据在存储到关系型数据库用于分析时会花费过多时间和金钱。大数据分析常和分布式计算或者云计算联系到一起，因为实时的大数据分析通常需要像Map-Reduce、Stream Computing那样的框架来向数十、数百或甚至数千的电脑分配工作。

1.3 大数据的商业价值

IDC 在其关于大数据的报告中，阐述了利用大数据的商业价值：领军企业与其他企业之间最大的显著差别在于新数据类型的引入。那些没有引入新的分析技术和新的数据类型的企业，不太可能成为其行业的领军者。
是的，大数据将使我们及时了解企业的真实信息，提高企业的决策水平。由于对大数据有着完善、随时、实时的分析能力，企业的运营管理水平和市场营销能力将会大大增强，这对现阶段的国内各行业的领军企业尤其重要。

1.4 务实的大数据

关于大数据的资讯铺天盖地而来，让大家看得眼花缭乱。虽然资讯很精彩，我们也看到了大数据背后的价值，但普遍不知道如何下手。
Yonghong认为，在一个企业中，超出现有计算机系统处理能力的数据，就是大数据。作为领军企业，应本着务实的态度，利用较低的成本，通过对大数据进行高速捕获和实时的分析，以获取核心业务和战略决策所需的关键信息，从而提升企业经营管理和战略决策水平，最终创造巨大的商业价值，才是对大数据价值的最好诠释。

2 商业智能的演变

2.1 数据库时代

企业信息化，往往从核心业务数字化、标准化开始。这个阶段从购买电脑开始，接着利用电子表格和财务软件，并逐步进化到数据库时代。在数据库时代，企业内部的信息化工作得到了合理的建设，包括：ERP、CRM、MIS等，这些信息系统比较完善地覆盖了各个领域，并实现了一站式服务和互联互通。作为数据存储的核心产品，各种主流的商业数据库产品（Oracle、DB2、SQL Server、Sybase等等）发挥着重要的作用。
领军企业甚至实现了与上下游厂商和客户在供应链、信息流等方面的整合工作，走在了整个行业的最前沿。

2.2 数据仓库+OLAP时代

在前面我们提到过：大数据正在成为从工业经济向知识经济转变的重要特征，已经成为新时代最关键的生产要素和产品形态。数据库时代之后，随着可用数据的持续积累，各行业的领军企业逐步开始了数据价值的发现之旅，尤其是在电信、金融、保险、互联网等IT建设比较领先的行业，商业智能系统（BI）的建设已然比较完善，并在日常经营和战略决策中发挥着重要的作用。
这一阶段的商业智能系统，一般是以数据仓库+OLAP为主，各种报表展现系统为辅。
数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Making）。数据仓库本身并不生产任何数据，它的数据来源于外部，并且开放给外部应用，因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层：源数据、数据仓库、数据应用。
OLAP就是最常见的一种数据应用。
OLAP以多维度方式分析数据，它提供积存(Roll-up)、下钻(Drill-down)、枢纽分析(pivot)等操作，呈现集成性决策信息的方法。它主要的功能，在于方便大规模数据分析及统计，对决策提供参考和支持。
一般地，传统数据仓库能够存储大数据，但并不提供针对大数据的分析和统计功能，因此，在开发OLAP这种数据应用时，需要用户预先提出的分析及统计的需求，再预先计算好这些主观的分析及统计的结果，才能确保OLAP系统的实时交互能力。
例如，考虑化妆品公司的一个简化的OLAP系统，用户预先提出的分析及统计需求包括如下几个维度和指标：化妆品、销售时间、合计销售数量、合计销售金额。其中：
       化妆品是一个维度，有产品类别、产品名称这两个成员。
       销售时间是一个维度，有年份、月份这三个成员。
       合计销售数量是一个指标。
       合计销售金额也是一个指标。
针对海量数据下，为了确保OLAP系统的实事交互能力，我们就需要预先计算这些可能的分析组合：
       产品类别、年份、合计销售数量、合计销售金额。
       产品类别、年份、月份、合计销售数量、合计销售金额。
       产品类别、产品名称、年份、合计销售数量、合计销售金额。
预先计算这些可能的分析组合也许要花上一个晚上、一整天、甚至几天的时间。

2.3 大数据时代

在数据仓库+OLAP时代，各种传统的数据仓库产品、OLAP产品、数据分析产品等推动了商业智能的进步，在企业的日常经营和战略决策中发挥着重要的作用，给企业创造了巨大的商业价值。迄今为止，它们依然发挥着重要的功能，并在商业智能领域持续进行着市场推广和营销工作。
然而，数据仓库+OLAP这一组合有着其先天的缺陷，它需要用户预先提出的分析及统计的需求，再预先计算好这些主观的分析及统计的结果。
考虑以下可能的变动：
数据的变动，例如更改一条记录，整个OLAP系统需要重新重新构建。
需求的变动，例如追加一个指标，整个OLAP系统同样需要重新构建。
这种牵一发而动全身的商业智能系统，在终端用户眼中也许是一个微小的变化，却可能需要很长的响应周期。然而，行业内企业整体经营管理水平的持续提高，竞争态势不断加剧，这对每个企业尤其是领军企业带来了巨大的挑战。要很好地应对这种挑战，保持行业优势地位，企业对商业智能系统的提出了更高的要求：
缩短开发和维护周期：从数据驱动转化为业务驱动，从传统开发转化为敏捷开发。
数据仓库＋OLAP时代的商业智能系统，要求用户预先提出的分析及统计的需求。以此为基础，展开数据建模工作，进而导入数据，然后再创建Cube。这些工作完成以后，才能开发商业智能应用，这是典型的数据驱动模式。业务驱动的商业智能系统，则直接导入细节数据，不再要求用户预先提出具体的分析及统计需求，也不再有创建Cube的过程，这大大简化了数据层的工作，缩短了数据层的响应周期，整个商业智能系统由数据驱动转化为业务驱动。
在数据仓库＋OLAP时代，一个新的分析需求也许要用一个月的时间去实现，现在只需一周甚至一天。以前建设一个商业智能系统也许需要一年，而如今不到一个月我们就能开发出第一个数据分析应用。
Yonghong认为，逻辑的OLAP将长期存在，而物理的OLAP将逐步消失。
支持实时大数据分析：建设基于MPP架构的商业智能系统，化Scale-Up为Scale-Out。
在数据仓库+OLAP时代，当商业智能系统性能无法满足用户需求，或者数据超出服务器存储能力时，大多数时候企业需要购买更加昂贵的服务器（更好的CPU、更大的内存量等等），我们把这种升级形式称为Scale-Up。进入数据仓库+大数据时代之后，企业的数据量从GB到TB再到PB，越来越大。对企业而言，这些大数据是一座金矿，关键是要能从矿山中挖掘出重大的商业价值。通过建设基于MPP架构的商业智能系统，企业可以用最低的代价、最高的性价比去支撑这个挖掘工作。当数据量或者访问量增加需要相应地升级硬件设备的时候，企业可以通过购买廉价的PC Server甚至PC去横向扩展商业智能系统，我们把这种升级形式称为Scale-Out。
直接导入细节数据的这一数据建模技术，将数据和应用之间的关系从紧耦合改造成松耦合，让大多数分析应用不引起数据层的任何改变；而基于MPP架构的商业智能系统，能够直接对细节数据进行高性能分析。这样一来，用户可以快速开发出数据应用，并随即进行实时分析。
建设随需应变的探索式、自服务商业智能系统。
新的商业智能系统内嵌丰富的数据分析能力。用户访问数据应用的时候，当看到异常或者引起关注的变化时，大家往往希望进行即席的、深入的分析以获取现象背后的深层次原因。探索式商业智能系统认为Reporting、Dashboard等数据应用是商业智能系统的门户、入口而不是终点。在这样的系统中，基于过滤(Filter)、钻取(Drill)、刷取(Brush)、关联(Associate)、变换(Transform)、动态计算（Dynamic Calculation）等等分析技术，用户可以进一步与数据互动(Interactive)。
数据层薄了，业务层就有条件厚实起来。行业领先的企业在良好的分级规划和分级管理下，上至总经理下至一线员工，各级部门都能提出并开发自己的数据分析应用，最终打造出随需应变的自服务商业智能系统。由于大部分数据分析应用由用户或者靠近用户的人员自行开发，开发应用的关联人员减少，整个机构管理更加扁平化，而响应时间却大大缩短，企业的经营管理能力和战略决策水平随之提升。相比传统的商业智能系统，自服务商业智能系统更优化，更有效率。

	传统BI系统	基于MPP DW的BI系统	Yonghong BI系统
对比：驱动模式	数据驱动	先数据驱动，后业务驱动	业务驱动
对比：开发模式	以瀑布开发模式建设BI系统		以敏捷开发模式建设BI系统
对比：交付周期	交付周期长，项目失败率高；不愿意在客户现场做POC(Proof of Concept)	交付周期偏长，项目失败率中；愿意在客户现场做POC(Proof of Concept)	交付周期偏短，项目失败率低；乐意在客户现场做POC(Proof of Concept)
对比:需求变化	难以应对变化，新需求交付周期长；相关模块调整多，交付周期在一个月之内	可以应对变化，新需求交付周期较短；相关模块调整不大，交付周期在一周之内	可以应对变化，新需求交付周期很短；相关模块调整不大，交付周期在一两天之内
对比：自服务BI	很难形成自服务BI系统	能够形成自服务BI系统	能够形成自服务BI系统
对比：展现	非常精美		精美
对比：分析	展现为主，分析为辅		展现只是起点，分析功能强大
对比：成本	产品模块多层次多，许可证费用高	需要分别购买MPP DW软件和BI软件，许可证费用高	一站式平台提供数据集市和BI软件，无需购买MPP数据仓库，费用低
对比：性能	低性能，或者预生成Cube	高性能，无需预生成Cube	高性能，无需预生成Cube
对比:海量数据	要么预先生成Cube支持海量数据，要么采用一体机，费用极高且持续增长	能够处理海量数据，基于数据量收费，随着数据量增长费用持续增长	X86通用平台，以Scale-out扩展模式处理海量数据。基于CPU收费，具有较高性价比
对比:支持	以跨国公司为主，研发团队一般在国外；服务响应慢，几乎不支持功能定制	以跨国公司为主，研发团队一般在国外；服务响应慢，几乎不支持功能定制	本土公司，研发中心在北京；服务响应快，快速支持各种合理的功能定制