从事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年吧，那个时候搞元数据还是蛮有前瞻性的，搞了很多年，却明白一个道理，如果你把元数据当成一个外挂，这个元数据

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！