大数据时代：传统BI还能走多远

从事BI多年，经历了经营分析系统的大建设，大发展时期，也有幸处在大数据与传统BI系统的交替之际，因此特别来谈谈，传统BI还能走多远？

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

1、资源申请-从月到日，不可同日耳语

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

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

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

大数据系统在资源粒度、申请速度、资源动态扩展等各个方面都完爆传统BI，在业务快速部署上具有无法比拟的优势，为业务创新奠定了很好的基础。如果你做过DB2的项目集成啥的，每一次都涉及规划、划盘、分区、安装等等，就知道啥叫等待。

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

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

我想大多数企业，BI的数据分析现在周期基本还是天，笔者做了10年BI，记得企业很长一段时间，是以月为单位ETL数据的，当然，从业务的角度讲，够用即可，有人会问，数据的周期减少到小时、分钟、秒以致实时，到底有多大现实意义?但真的业务上不需要更短周期的分析吗?是因为大家BI分析的套路习惯使然还是能力不够使然?

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

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

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

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

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

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

3、计算性能-性价比是王道，更迭速度比想象的快

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

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

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

4、报表系统-审美疲劳不可避免，个性化是趋势

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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