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

从事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作不到的。

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

DB二、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还能走多远？提了八点，对于处于不一样阶段的人，可能也有不一样的理解，固然仅为一家之言，但愿有所启示。

更多大数据与分析相关行业资讯、解决方案、案例、教程等请点击查看>>>