实时商业智能BI（二）：合理的ETL架构设计实现准实时商业智能BI

今天来讲下利用 ETL 架构设计和调整来实现 商业智能BI 某些指标的准实时处理和展现。比如一小时更新一次，或者几分钟，一分钟，甚至几秒，也是可以的。

商业智能BI数据仓库ETL架构

一般的 商业智能BI 数据仓库 ETL 架构是这么来设计的，分成四个 ETL 包、或者五个 ETL 包，每个包就是数据仓库的一个分层的 ETL 合集。

商业智能BI数据仓库 - 派可数据商业智能BI可视化分析平台

第一个包是 ODS 或者 Staging 层，里面包含了所有的从业务系统数据源抽取源表到 ODS 层的ETL 处理过程。

第二个包要优先处理所有的维度 Dimension Table。

第三个包就开始处理标准的事实层 Fact Tables。

第四个包处理Data Mart 数据集市层。

第五个包处理OLAP CUBE 等等。

这几个包是由严格的依赖关系顺序的，是串行的。也就是说第一个包没有处理完，第二个包是不能执行的；第二个包没有执行完，第三个包也是不会启动的。

我上面讲到的 商业智能BI 数据仓库 ETL架构是非常标准的分层架构设计，这五个包通常会放到比如Windows定时任务JOB里面去做定时调度，比如每天晚上执行一次。

商业智能BI数据仓库ETL架构问题

但这里面就有这么个问题，某些指标想做准实时就不能按照上面的商业智能BI数据仓库ETL架构来设计，就需要把这几个指标单独拎出来，把这几个指标的上下游依赖的ODS层、维度层、事实层的指标单独打包来处理，然后在JOB里面单独做定时调度。一个指标一个JOB，十个指标就是十个JOB。这样这些指标的执行就不依赖于原有的整体ETL架构，可以单独跑，这是第一个点。

数据可视化 - 派可数据商业智能BI可视化分析平台

第二个点就是，这个JOB定时执行的任务时间间隔要大于这个JOB的执行最长时间。比如这个JOB一般执行一分钟，那设置商业智能BI定时调度的时间间隔最好就是两分钟或以上。什么意思呢，这个指标整个流程还没有计算完，下个定时任务启动了，上次执行正好把数据写入完成了，这次任务就把数据给清空了，这样就乱套了。

所以，针对这个问题要额外进行一些商业智能BI数据仓库ETL日志框架的开发和改造，让每次ETL执行时去检查一下日志，上次没有执行完成这次就先不启动，等待上次执行完毕之后再启动就不会出现冲突了。

商业智能BI数据仓库ETL架构改造

这些我们之前在一些大型的项目上并行跑上百个包就是通过对商业智能BI数据仓库ETL框架的改造来完成数据指标的准实时实现，当然这个商业智能BI准实时要取决于指标自身的计算时间周期和过程。

所以，我们会大量的使用增量抽取，包括对商业智能BI中数据表索引、查询性能的优化。

数据可视化大屏 - 派可数据商业智能BI可视化分析平台

以往是串行的从下往上执行每个包，一个包的调度等到之前的包的调度执行完毕再执行。现在相当于把需要做实时或者准实时的商业智能BI指标从原来的包中分离出来单独的来维护组成一个新的串行，这种商业智能BI数据仓库ETL架构的设计方式跟以往传统的数据仓库ETL架构就有很大的区别了。

我们现在在我们自己商业智能BI产品的ETL调度就是按指标为线性的方式来实现的，每个指标可以独立的进行抽取调度，并且全部都是配置化的。这种商业智能BI中ETL调度的方式也是为实时性数据仓库、实时性商业智能BI打下了基础。

那如果要实现完全的商业智能BI实时性分析，而不是基于个别指标的准实时分析，又大概是一个什么样的过程呢，下次分享。