在回答这个标题前,有必要对BW是什么做个简要的说明。
【BW是什么】
在SAP的产品架构里,BW的定位是用来减轻和转移ERP系统在报表统计和数据分析的压力,把ERP宝贵的资源用在业务处理上(比如月结,成本核算),即BW处理OLAP类事务,ERP处理OLTP类事务。不启用BW,则需要由ERP同时处理OLAP和OLTP事务,对ERP系统有三方面负面影响:首先在架构层面,增加了ERP本身的应用复杂度;其次,数据耦合度高,ERP系统的性能直接决定报表数据的性能(你越忙我越慢);最后,由于ERP“身兼多职”,降低了ERP系统处理业务事务的性能。
【构建大数据平台后,BW何去何从】
接下来问题来了,既然BW能做OLAP,大数据平台也可以做OLAP,那能不能统一用大数据平台?这样一来架构简单,二来可以节省运维成本。
这个问题很难给出一个一刀切的结论,现在应用技术环境本就是包容的思路,这也是架构师的价值所在。工具本身没有好坏,只有合适与不合适,需要架构师从实际业务出发进行设计,而不是黑猫白猫非比个好坏出来,能抓老鼠,解决问题就是好猫。如果非要再进一步阐述,那就多啰嗦几句:首先BW是SAP ERP的好兄弟没错,它的初衷是为ERP减负,让ERP做好他的本职工作,但不代表BW只能做ERP的专职小弟,实际上BW是按企业级数据仓库的定位来设计的,它具备高度的体系化能力(平台稳定)和丰富的扩展能力(支持分布式),换句话说,BW具备集成非SAP系统的数据能力,产品架构也没有问题,工具层面是可以作为EDW来用的;其次,如果企业仍然悄悄的按着手上的BW on Oracle版本没有升级的话,那么恭喜你,你的BW licence是算在SAP ERP里的,换句话说可以免费用(这种问题是你不问,SAP绝对不会说的,还会有各种暗示赶紧升级),但代价是没有实时数据获取的能力,这个要企业自己平衡。
言归正传,对于手心手背都是肉的企业CIO或CTO来说,我从如下几个方面给出了一些决策参考:
1,成本方面:当数据涉及SAP簇表或结构时,这类是比较复杂的业务事务,SAP一般会通过事先封装好的一套逻辑(叫做事务代码)来调用相关数据,通过SAP给BW的标准数据源这条康庄大道会比较省事,否则需要摸透SAP的事务代码封装逻辑,整个过程有点像拆盲盒,需要些运气,小批量数据对了不代表大批量数据对,某一期间数据对了不代表所有期间数据都对,每次数据校验都会有surprise,因为业务场景不会一成不变,所以相较直接启用标准数据源,成本有些高,当然,艺高人胆大的高手或预算不缺的不在此列。
2,性能方面:SAP给BW的标准数据源是SAP优化过的数据传输方案,比如IDOC这种非侵入式的数据传输协议,可以保证在大的数据量传输(千万级以上),取数作业不会对SAP系统性能产生负面影响。由于SAP体系的特殊性(有自己的生态),第三方取数工具相较SAP IDOC协议,属于侵入式,会牺牲一部分SAP性能,特别是大数据量的情况下,所以一般第三方工具大批量取数会避开月头月尾月结时期,除非Basis调优和硬件资源足够强,否则有一定数据空窗期。
3,增量作业:由于考虑到不同国家、不同场景的业务配置标准化、通用化,SAP的增量机制设计的非常复杂,如后勤模块的增量机制大多是通过事务条件触发,而不是传统的时间戳,体现在数据表中为没有时间字段或有多个时间字段,这种形式的增量取数,SAP提供给BW的标准数据源可以识别和支持,非SAP体系的数据集成工具难以支持。说实话,一张表里啥时间字段没有,还有更过份搞加密的,我也难以理解SAP的设计人员是怎么考虑的。
4,低代码开发:BW本身来说,它是高度成熟的商业套件(已有30+年历史),也是一个低代码的建模平台,平台内置丰富的函数和可视化配置工具,基本可以在不写SQL或少量SQL的情况下完成数据建模,对比HIVE有点像Windows操作系统和Linux操作系统的区别,开发效率相较开源组件较高。
5,语义分析:我个人一直觉得大数据量多维表格的ad-hoc即席分析和实时计算是个有较高技术门槛的领域。BW自带的即席报表工具Analyzer/Analysis虽然看着丑,但其实有料也很实用,和德国香肠一样朴实无华但管饱能救命。它自带的基于MDX的ad-hoc即席分析引擎非常易于业务人员上手使用(会用Excel的同事培训十多分钟就可以上手),并支持模板互传,模板分享这些核心的功能,以至于有时候业务用户没有意识到自己是在用BW工具,直夸这个Excel真好用。
接到一些同学私信,要求来个总结,那就献个拙,如果企业之前已经应用了BW并部署了一些成功的数据应用,建议可以和大数据平台形成湖仓一体的架构,首先,这样做技术层面不存在障碍,也没有很高的成本,其次,可以节省企业的重构时间,避免花代价把以前做的内容在新平台上再来一次。预算充分的话,可以考虑BW on hadoop的技术方案,这样可以在平台工具层面使两者刀剑合并。
【写在最后】
我一直认为,大数据平台(现在流行叫数据底座,这里吐个槽,最近有不少营销人才进了IT领域,五花八门的各种包装,也不管用户是不是已经满眼小星星,逮到就一通暴击加连杀的疯狂输出),它不应是一个狭义的某某技术平台的概念,而是一个包括数据治理、AI等方面的多元体系,这个体系应该是丰富、开放和物尽其用的,而不是单体科技树,最后形成新的自我封闭。
好了,唠叨完了,继续开会。