我们通常讲到商业智能BI数据同步的机制一般是T+1模式。就像炒股里面也是T+1,当天买入的股票,到下个交易日比如明天卖出。所以这个T,有的人理解为Today今天,或者Trade 交易日,都没有问题。
如果像周末、节假日不交易的话,就理解为Trade交易日就好了。对商业智能BI而言,这个T可以理解为Today当天,T+1就是数据每天同步一次,现在看到的数据是头一天的,明天看今天的数据。
所以,商业智能BI对数据的同步是有滞后性的,并非实时的,但这种方式是完全可以满足绝大部分企业的商业智能BI诉求。
商业智能BI的实时性诉求
讲到这我就想起我们以前去过的一家贸易流通的公司,某产品国内总代,业务发展不错。我们在讲到商业智能BI的T+1数据同步机制的时候,对方的CIO和老板就追着这个问题不放。非要做到页面数据完全实时,秒级实时,要搞成像天猫、双11那个大屏一样,问你们能不能做。
这个问题不是很好正面回答,完全实时是非常有难度的,谁都不敢完全保证。因为这个不是业务系统,这个是商业智能BI分析系统,分析系统就是有取数过程的时间损耗和指标计算过程的时间损耗的。所以我们的顾问就没有正面回应,就还在解释商业智能BI是如何实现的。
对方听的可能没有耐心了,就直接打断说你们不要解释这些东西,就回答我们能不能做就行了,我们就要实现这个功能。你们商业智能BI的产品技术要是做不到,就直接说,不要遮遮掩掩。要是能实现,钱不是问题。
现场听的这种感觉其实不是很好,并且特别是说钱不是问题的往往到最后都是钱的问题。出于尊重客户,我们还是答应回去碰下技术实现方案再报价。我们后面了解到这家公司又找了其它几家大数据、商业智能BI公司,包括一家大厂,也是这么提要求的。
由于客户也没有明确的预算,那大家该怎么报就怎么报了,结果报完之后客户反馈太贵了不做了。我们就填报、几个大屏、十来张张报表你们搞的这么贵。是啊,就这么一点东西,你非要搞什么实时、搞大数据架构,还评估软硬件资源,这种就是典型的瞎折腾。
这家公司的CIO也成为了整个公司信息化建设的瓶颈,因为很明显很多基础性的技术性原理没有搞明白,商业智能BI讲解了也还是没有听懂。对于CEO坚持的错误想法也没有进行及时的纠正,对需求和投入没有做出充分的评估,这种沟通对大家双方都是一种严重的时间和精力上的浪费。
为什么商业智能BI采用T+1模式
我来讲下为什么商业智能BI采用T+1模式,它的数据处理过程大概是什么样子的。
商业智能BI的数据仓库架构本身就决定了对数据的实时性要求没有那么高,ETL的过程不可或缺,Extraction 抽取、Transformation 转换、Loading 加载,这三个环节本身就是有时间损耗的。
首先,Extraction抽取,这些业务数据要使用SQL或者ETL工具从业务数据库查询并通过网络传输加载到商业智能BI数据仓库,视数据量的大小这个查询和加载会花费一定的时间,比如五分钟、十分钟甚至更长。这只是其中的一个查询,所有查询和加载全部执行完短则几分钟,长则小时算很正常。
第二,数据加载到商业智能BI数据仓库中了,数据要被加工处理,比如去重、合并、循环计算等等算出各种指标放到数据仓库不同的层里面,这个数据处理的过程在商业智能BI里是最耗时间的,几十分钟到几个小时。指标越多,业务逻辑越复杂,计算处理花的时间越长。 这个就是ETL处理的核心,Transformation 转换。
第三,Transformation 转换处理后的数据要写入到目标表比如商业智能BI中维度表、事实表里面,即Loading 加载。
ETL是商业智能BI数据仓库的数据处理关键,其中E是数据源头,T是中间数据计算处理的过程,L是将计算结果写入、加载到目标表。
大家看看,把这三个阶段的时间加起来,这个时间周期是不是很长,是没有办法实现商业智能BI的实时分析的。
并且很多时候白天业务系统有人可能会用的比较晚,有些数据业务部门更新的时间也比较晚。所以大部分情况下,商业智能BI都会选择在晚上12点以后执行ETL的调度从业务数据源将12点以前的所有已更新的数据同步过来处理。
所以,通常商业智能BI在晚上先把前两个阶段的事情给处理了,所有的数据都抽取、加工、计算完了,都提前存放在数据仓库里。第二天页面在刷新的时候直接访问的是已经计算好的数据仓库的数据,这样就很快了。
如果大家碰到再有人问到商业智能BI数据的实时性的时候,就可以把这个过程讲的对方听一听,正常情况下大家应该还是可以听明白这个过程的。
那有没有什么方式能够实现指标在商业智能BI可视化页面上的实时分析、实时展现呢,或者准实时也可以啊,欢迎关注更新,下篇文章我们再来介绍。