BI（BusinessIntelligence），即商务智能，它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确的提供报表并提出决策依据，帮助企业做出明智的业务经营决策。

大数据（Big Data），指在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。

不 管定义如何不同，大数据与传统BI是社会发展到不同阶段的产物，大数据对于传统BI，既有继承，也有发展，从"道"的角度讲，BI与大数据区别在于前者更 倾向于决策，对事实描述更多是基于群体共性，帮助决策者掌握宏观统计趋势，适合经营运营指标支撑类问题，大数据则内涵更广，倾向于刻画个体，更多的在于个 性化的决策。

基于这个特点，大数据很容易在生产中形成基于个体的评估和闭环反馈网络，BI则由于偏向宏观而难以在生产中贯彻执行从而产生实际价值，因此，当前的大量的新数据应用领域，实际BI是没有覆盖的，比如RTB广告、智能制造、个性医疗等等。

当 然纯粹从思想的角度讲，两者在概念上是可以实现统一的，都遵循数据-信息-知识-智慧这个脉络，甚至在更高的层次，两者也是可以统一的，比如这个定义： “世界上万事万物都在被数据化，形成一个与现实世界相关联的数据世界，人类可以利用数据化的方式，应对和解决生存和发展问题。”

因此很多人说BI跟大数据没区别，的确是这样，没必要抬高大数据，但由此认为两者价值也差不多，那也有问题，它忽略了“术”的不同，由此造成应用的巨大差别。

举个例子：神经网络理论几十年前就有，为啥直到现在才有深度学习突破性的进展，关键是其“术”的能力提高了，一定程度讲，大规模数据并行处理让这个理论焕发了新生。

理念是一回事，付诸实践是另一回事，因此，我们还是要从“术”的角度来阐述大数据与传统BI的区别，事实上，传统BI，由于其术的限制，已经达到了一定瓶颈。

传统BI厂家喊了多少年的"帮助企业做出明智的业务经营决策"，现在除了一堆报表系统，搞了一些决策树等统计算法，还剩下什么呢？传统企业引入了那么多的BI咨询，写了那么多报告，真正发生过价值的有多少？BI已死也并非空穴来风。

如果搞BI的还在原有的地方转圈圈，不去变革，除了空喊我也是大数据，没有意义，因为数据价值最终还得看落地的能力。

大数据的4V特征大家都懂，大数据在量、维度、速度等方面相对于传统BI的改变的确让数据改造世界的能力发生了质的变化，那么，大数据的“术”于传统BI到底有哪些变化？传统企业需要做哪些改变呢？

超越BI，拓展新的业务边界

大数据不是绣花枕头，它的第一要务就是解决业务问题，大数据一定程度上讲就是用全新的数据技术手段来拓展和优化业务，传统企业需要聚集一拨人来研究这个问题。

如果对外，想清楚新的商业模式，如果对内，想清楚在哪个场景，可以用大数据的手段来提升效率。

当前大数据可以产生价值的地方，从行业的角度看，互联网、制造业、公共服务、医疗保健、金融服务都有广阔前景。

从领域的角度看，广告、营销、风控、供应链都是大数据发挥价值的地方，对于特定企业，比如电信运营商，大数据也可以在网络优化等方面提供新的方法。

大数据应用场景是企业特别需要想清楚的地方，传统BI失败，一定程度讲，是技术推动业务导致的倒挂现象所致，是高估传统BI利用数据的能力所致，比如大量领域用传统BI产生不了生产力，当然也少不了忽悠。

大数据也面临这个重大问题，但应该看到，随着大数据概念的普及，应用领域的大幅延伸，企业的管理和业务人员对于数据的认识有了很大的转变，数据化的思维开始深入人心，对于大数据来说，是一个新的机会。

不业务，无大数据。

颠覆BI，打造大数据技术引擎

这是当前大数据领域最火的地方，很多企业纷纷在建设自己的大数据台，不外乎解决以下问题，以下仅举例。

比如用Hadoop、流处理等技术解决海量的结构化、非结构化数据的ETL问题，用Hadoop、MPP等技术计算海量数据的计算问题，用redis、HBASE等方式解决高效读的问题，用Impala等技术实现在线分析等问题。

本质是基于廉价的机器，采用去中心化，分布式的方式去解决海量结构，非结构化数据的存储、处理和读写的问题。

要理解这个，其实去读懂Google的三篇论文就可以了，分别是关于Google File System、Google Bigtable及Google MapReduce的。

但并不是每个企业都需要打造自己的大数据平台，量力而行吧，可以自研 ，比如BAT，也可以采购，比如传统大企业，也可以租用，比如用阿里云和AWS。

在技术上，传统BI的ETL、数据仓库、OLAP、可视化报表技术，都处于淘汰的边缘，因为它解决不了海量数据（包括结构化与非结构化）的处理问题，其所有的功能都可以被对应的大数据组件所替代，因此不再有发展前途，大多数企业即使没有大数据业务的驱动，但大数据技术的成本优势在那里，不做大数据也倒逼你用大数据技术，是不？

当然传统BI那套，也将长期存在，毕竟大数据的普及和应用是个漫长的过程，传统企业对于大数据技术稳定性的担忧也是个障碍，但企业至少要末雨绸缪了，趋势不可挡啊，大数据技术会越来越成熟。

我记得自己的企业1年前还在用DB2，仅一年的时间，GBASE就把它替换了。我们总是低估了技术革命对于我们自身的影响程度。

重塑BI，升级人员的知识结构

有了业务，也有了技术，再来看看人吧，很多企业在热火朝天的建设大数据平台，但建完之后，却发现仍然是个报表系统，或者仍然是原来的BI，领导一看，会感叹，不就是换了个马甲啊，大数据有啥用？

很多企业，它可以有很多的预算购买很贵的机器和软件，但对于引入人才和培养人才却有点力不从心，买了1个亿的大数据硬件和软件，却希望原来的BI班底就能带来大数据应用的繁荣，那也是差强人意的事情，新品装旧酒，原来班底能搞定公司的报表系统就已经很好了。

为什么传统BI人员搞不定？

大数据需要有人专门研究和探索，传统BI人员时间精力有限，此为其一，不是否定BI人员的能力，只是表达不要奢望BI人员既做个合格的报表哥，又是个大数据创新达人，企业要能做些取舍。

大数据的数据处理，涉及太多新的技术，传统BI只要懂点SQL就可以活的很好了，但现在看看，不同的应用场景需要不同的大数据处理方法了，而且不再有人机交互那么好的客户端了，至少要懂流处理、HADOOP、列式或分布式键值数据库吧，大数据对于BI人员的技能要求其实大幅提高了,此其二。

大数据更强调全量了，原来的BI挖掘人员，搞一些样本在单机上运行个R就很欢乐，但现在不行了，针对5000万用户搞个三度交往圈试试？传统方式在BI时代大都尝试过了，只有更新方法，才能带来新的机会，比如，至少要求建模师会在SPARK上开发算法程序吧，对于用户画像、产品标签化、推荐系统、排序算法都应有所理解，此其三。

人才是大数据的核心要素，没有人的投入，不能奢望有啥产出，需要多点人才的引入和培养，少点大数据的心灵鸡汤，大数据绝对不是大忽悠，如果有所怀疑，就问问你这个企业有多少人是在做大数据研究和实践的。

因此，大数据相对于传统BI，不是简单的PLUS的关系，它涉及了思想、工具和人员深层次的变革，BI人员既不要一提大数据，就嗤之以鼻，认为它是新包装的马甲，其实就那么回事；也不需妄自菲薄，以为搞大数据就那么高大上，它的确是BI大多数思想的传承，传统BI对于数据的处理思想，都可以用于大数据。

顺应大势，更新自己，奋起直追，重装上阵，是BI应有的态度。

看到这里，不少人应该会问：只要能解决问题就成，不用区分大数据和传统BI吧？但所谓的解决问题，到底是指什么？

做数据，逃不过两个字“较真”，可以用一天的时间解决问题，也可以用1秒的时间解决问题？ 两个都叫解决问题。

从事BI十多年，经历了经营分析系统的大建设，大发展时期，也有幸处在大数据与传统BI系统的交替之际，因此还想谈谈，为什么说传统BI没前途。

技术为业务服务，因此这里不谈技术，更多从使用者的角度去阐述原因，理了八个方面，每个方面都是笔者亲历，当然任何穷举法都无法证明绝对正确，但希望能引起思考。

资源申请-从月到日，不可同日而语

自从企业有了大数据MPP、HADOOP、流处理三个资源池，租户生效基本都是所见即所得。公司甚至为了申请方便，搞了资源套餐，我们申请资源叫点套餐，这种资源申请模式为对外灵活开放数据提供了基本保障，在半年时间内，内外部租户已经开出了100多个（以前可能叫数据集市），现在回想起来，如果没有这个能力，公司的对外变现基本不可能。

无论是阿里云还是AWS，都是这个套路，但为什么企业要自己做，因为较大的企业本身内部就是个巨大的市场，有各类的应用要求，从数据、安全、接口、技术等各个方面讲，都不适合放到外部平台。

传统BI的小型机阶段，没有资源池概念，资源申报按硬件台数算，需要提前申请预算，即使硬件到位，集成时间也过于漫长，记得以前为11个地市规划11个数据集市，采用四台570划分12个分区，搞了1个多月，效率不可同日而语。

大数据系统在资源粒度、申请速度、资源动态扩展等各个方面都完爆传统BI，在业务快速部署上具有无法比拟的优势，为业务创新奠定了很好的基础。

如果你做过DB2的项目集成啥的，每一次都涉及规划、划盘、分区、安装等等，就知道啥叫等待。

数据采集-多样性才能创造更多应用场景

传统ETL的基本套路都是从源数据库导出成文本，然后通过客户端工具导入到目的数据库，导出用EXPORT，传输用FTP，导入用IMPORT，当然，同种类型的数据库可能用DBLINK等这种快捷方式，程序中采用ODBC啥的连接数据库来进行操作。很多公司专门开发了一些多库之间互导数据的工具，当然一般企业级的平台不用，可扩展性、灵活性太差。传统ETL的技术非常适应以天或月为分析周期的静态应用要求。

我想大多数企业，BI的数据分析现在周期基本还是天，笔者做了10年BI，记得企业很长一段时间，是以月为单位ETL数据的，当然，从业务的角度讲，够用即可，有人会问，数据的周期减少到小时、分钟、秒以致实时，到底有多大现实意义？

但真的业务上不需要更短周期的分析吗？是因为大家BI分析的套路习惯使然还是能力不够使然？

从取数的角度讲，业务人员永远希望你取得数据越快越及时越好，我们原来只出月报，后来性能上去了，复杂的日报也能出了，日报变成了标配，日报之后呢，实时是否应该成为未来的标配？

从应用的角度讲，企业除了一堆运营指标报表，一般有营销和风控两个角度有数据的现实需求，实时营销显然比静态营销效果更好一点，BAT如果不搞实时营销基本就没法活，实时风控显然比离线风控效果更好有一点，比如反欺诈系统，如果不是实时的监听，如何在诈骗的事中介入？

从趋势的角度讲，如果你认同未来的世界是满足个性化的世界，那么，只有实时的数据才能蕴含更多的信息，才能给你更为个性化的服务，你会想到太多的场景需要实时化采集。

即使你没有以上提的任何需求，但技术和业务永远是互动的，你具备了按小时提供的能力，人家就会创造按小时的业务场景，你具备了实时的提供能力，人家就会创造实时的业务场景。谁是蛋谁是鸡说不清楚，但如果你想服务的更好，就应该在技术层面更前瞻性一点。

但传统BI能支撑吗？传统企业的BI不实时，本质不是没有需求，也许是能力不够所致，我记得以前CRM上线要搞个实时放号指标监控，也是蛮困难的事情，以前出账只有月报啊，现在，没有日报，还能活？ 我记得很多年前第一份日账报表是IT人员自己提的，因为能力到了。 那未来10年呢？

ETL是传统数据仓库中的一个概念，我觉得该升级了，多样化的采集方式是王道，这是大势所趋，有三样东西是最重要的，一个是采集方式的百花齐放，即消息、数据流、爬虫、文件、日志增量都能支持，二是数据的流动不是单向的，不仅仅是E，而且是X，即交换，这样就极大衍生了ETL的内涵，三是数据采集的分布式，可以并行动态扩展，ETL的读写问题能较好解决。这些恰是传统BI做不到的。

计算性能-性价比是王道，更迭速度快

DB2、Teradata在数据仓库领域一直占据着巨大的份额，我们用GBASE+HADOOP花了半年时间把2台P780替换掉了，综合性能可以说是原来的1.5倍，但投资只有几分之一，虽然前期涉及一些调优，对于代码也有更高的要求，但性价比非常高，关键是能够多租户动态扩展，容灾能力也超DB2。记得以前DB2一旦节点出现问题，虽然也能切换，但性能往往下降一半，极大影响业务。

传统数据仓库，对于不同的数据处理方式往往是一视同仁的，但事实上，不同数据处理阶段，对于数据处理的要求存在结构性的不同，一些简单的转化和汇总，在库外方式处理比库内处理合算，但传统BI习惯于把数据全部导入到数据仓库中做，浪费了珍贵的小型机系统资源，性价比很低。因此，当前MPP+HADOOP混搭型数据仓库渐成趋势，HADOOP擅长海量简单的批量处理，MPP擅长数据关联分析，比如eBAY,中国移动等都采用了类似的方案。

从综合的角度讲，DB2等数据仓库当然有它的优势，比如引以为豪的稳定，但这些技术过于依赖国外，感觉运维能力每况愈下，关键问题的解决越来越力不从心，稳定这个词也要打上大大的问号，不知道其他企业感觉如何。

要相信笔者不是打国产GBASE广告，坑很多，但值得拥有。

报表系统-审美疲劳，个性化是趋势

用过很多商业化的报表系统，比如BRIO、BO、BIEE等等，系统都提供了较好的可视化界面，对于轻量级数据的展现也不错，但我觉得这个对于大型企业来讲没有吸引力。

一是可替代性太强，现在开源组件太多了，功能也雷同，为什么要用标准化被捆绑的东西，对于具有一定开发能力的公司，似乎无此必要。

二是开源性太差，企业有大量个性化的要求，比如安全控制等等，但这些产品的开放性较差，很多时候满足不了要求。

三是不灵活，再通用，能做得过EXCEL吗，不要奢望从一个报表系统上能直接摘取一个报表粘贴到一个报告上，总是要二次加工，既然这样，还不如数据直接灌入EXCEL简单。

四是速度太慢，当前的报表已经不是传统BI意义的报表，因为维度和粒度要求很细，结果记录数过亿的也不在少数，比如我们的指标库一年记录是百亿条，传统BI报表根本无法支撑，样子好看是暂时的，业务人员最关注的始终是报表的速度。

当然，对于小企业可能仍然具有一定吸引力，但这个开放的时代，需求和新技术层出不穷，这类标准化的产品能赶上变化吗？如果你希望HBASE跟BIEE结合，怎么办？是等着厂家慢慢推出版本，还是干脆自己干？

多维分析-适应性较差，定制化才是方向

用过一些商业化的多维分析系统，也叫OLAP吧，比如IBM的ESSBASE。OLAP是几十年前老外提出的概念，通过各维度分析快速得到所需的结果，但这个OLAP到底有多大的实用价值？

OLAP产品总是想通过通用化的手段解决一个专业性分析问题，从诞生开始就有硬伤，因为分析变化无常，你是希望自己在后台随心所欲用SQL驰骋江湖还是面对一个呆板的界面进行固定的复杂的多维操作？笔者作为技术人员不喜欢用它，但业务人员也不喜欢用它，操作门槛偏高。

在开放性上，传统OLAP的后台引擎仍然是传统数据库，显然不支持一些海量的大数据系统；打CUBE是个设计活，非常耗时，每次更新数据要重打CUBE，总是让笔者抓狂，不知道现在有啥改进；千万级数据量、10个维度估计也是它的性能极限了吧；最后，以前打的CUBE真的能解决你当前的分析问题？

淘宝的数据魔方一定程度说明了OLAP的发展方向，针对特定的业务问题，提供特定的多维数据解决方案，我们需要提供给用户的是一个在体验、性能、速度上都OK的专业化系统。

业务导向+定制化的后台数据解决方案（比如各类大数据组件）是未来OLAP的方向。

挖掘平台-从样本到全量需全面升级装备

SAS、SPSS都是传统数据挖掘的利器，但他们大部分时候只能在PC上进行抽样分析，显然，大数据的全量分析是其无法承担的，比如社交网络、时间序列等等。

传统数据挖掘平台似乎没有拿得出手的东西，以前IBM DB2有个DATA MINER，后来放弃了，Teradata可以，有自己的算法库，但面对海量数据其计算能力显然也力不从心，跟大数据的SPARK等差了一个档次，我们接触的很多合作伙伴，大多开始将SPARK做为大规模并行算法的标准套件了。

即使如逻辑回归、决策树等传统算法， SPARK显然能基于更多的样本数据甚至全量数据进行训练，比SPSS，SAS仅能在PC上捣鼓要好很多。

传统BI的SAS和SPSS仍然有效，但基于大数据平台的全量算法也应该纳入BI的视野。

数据管理-不与时俱进，就是一个死

数据管理类的系统很难建，因为没有你生产系统也不会死，有了也很难评估价值，且运维的成本过高，一不小心就陷入了到底谁服务谁的问题。

最早接触元数据管理系统是在2006-2007年吧，那个时候搞元数据还是蛮有前瞻性的，搞了很多年，却明白一个道理，如果你把元数据当成一个外挂，这个元数据系统没有成功的可能，搞事后补录这种看似可以的方法，无论制度如何完善，系统解析能力如何强大，也最终会走向源系统和元数据两张皮的现象，失去应有的价值。

只要不解决这个问题，我严重怀疑传统BI元数据管理真正成功的可能。大数据时代，随着数据量、数据类型、技术组件等的不断丰富，搞事后元数据更是不可能的事情。

新时代的数据管理系统长啥样？一提倡生产即管理，也就是说，元数据管理的规则是通过系统化的方式固话在系统生产流程中，我们提倡无文档的数据开发，因为文档就是元数据，所有关于元数据的要求已经梳理成规则并成为数据开发环境的一部分。比如你建个表，在给你可视化开发界面时，关于表的定义已经强制要求在线输入必须的说明，你写的代码也被规则化，以便于元数据自动解析，成为数据质量监控的一部分。

二要能评估数据效益，通过一的手段，数据跟应用可以形成关联，应用的价值可以传导为数据的价值，为数据的价值管理提供标准，做数据最郁闷的是，我创造了一个模型，但不知道这个模型的价值，自己的工作变得可有可无，我也不知道如何开展优化，几十万张表烂在哪里，不敢去清理它们。

三是跨平台管理，这么多的技术组件，比如HADOOP、MPP、流处理等等，你的管理系统要能无缝衔接和透明访问，每新增一类组件，都要能及时接入管理系统，否则，接入一个，该组件上的数据就成为游离之外的数据，数据管理无从谈起。

数据管理，最怕半拉子工程，要系统化，就要做彻底，否则，还不如文档记录算了，没什么多大的区别。

审视定位-BI干BI的事情，各司其职

传统BI，做报表取数的太多，研究平台和算法的太少，重复劳动太多，创造性工作太少，随着业务的发展，BI的人逐渐老去，但系统中留下的东西不多，非常遗憾。

大数据时代到来，这种情况需要改变，该是重新审视自己的定位的时候了，报表取数的确是BI的基础工作，但从事BI的人不应该总是扮演拉磨的驴子的角色，应该是最终掌舵的那个人，我可以拉一会，但我需要研究如何拉得更快，最后让机器来代替我拉，或者让拉磨的工作非常愉快，需要的人可以自己来拉。

BI的人有太多需要创新和学习的东西，如果有太多取数，搞个取数机器人，如果太多报表，搞个指标体系，如果太多需求，搞个自助工具或给个租户环境，诱惑业务人员自己来做，需求永无止境，欲望永不满足，靠人肉填坑，永远填不满的，需要BI人的引导，授人予鱼，不如授人予渔。

传统BI没前途，提了八点，对于处于不同阶段的人，可能也有不同的理解，当然仅为一家之言，希望有所启示。