今天來講下利用?ETL 架構設計和調整來實現?商業(yè)智能BI 某些指標的準實時處理和展現。比如一小時更新一次，或者幾分鐘，一分鐘，甚至幾秒，也是可以的。

商業(yè)智能BI數據倉庫ETL架構

一般的商業(yè)智能BI 數據倉庫 ETL 架構是這么來設計的，分成四個 ETL 包、或者五個 ETL 包，每個包就是數據倉庫的一個分層的 ETL 合集。

第一個包是?ODS 或者 Staging 層，里面包含了所有的從業(yè)務系統(tǒng)數據源抽取源表到 ODS 層的ETL 處理過程。

第二個包要優(yōu)先處理所有的維度?Dimension Table。

第三個包就開始處理標準的事實層?Fact Tables。

第四個包處理Data Mart 數據集市層。

第五個包處理OLAP CUBE 等等。

這幾個包是由嚴格的依賴關系順序的，是串行的。也就是說第一個包沒有處理完，第二個包是不能執(zhí)行的；第二個包沒有執(zhí)行完，第三個包也是不會啟動的。

我上面講到的?商業(yè)智能BI 數據倉庫 ETL架構是非常標準的分層架構設計，這五個包通常會放到比如Windows定時任務JOB里面去做定時調度，比如每天晚上執(zhí)行一次。

商業(yè)智能BI數據倉庫ETL架構問題

但這里面就有這么個問題，某些指標想做準實時就不能按照上面的商業(yè)智能BI數據倉庫ETL架構來設計，就需要把這幾個指標單獨拎出來，把這幾個指標的上下游依賴的ODS層、維度層、事實層的指標單獨打包來處理，然后在JOB里面單獨做定時調度。一個指標一個JOB，十個指標就是十個JOB。這樣這些指標的執(zhí)行就不依賴于原有的整體ETL架構，可以單獨跑，這是第一個點。

第二個點就是，這個JOB定時執(zhí)行的任務時間間隔要大于這個JOB的執(zhí)行最長時間。比如這個JOB一般執(zhí)行一分鐘，那設置商業(yè)智能BI定時調度的時間間隔最好就是兩分鐘或以上。什么意思呢，這個指標整個流程還沒有計算完，下個定時任務啟動了，上次執(zhí)行正好把數據寫入完成了，這次任務就把數據給清空了，這樣就亂套了。

所以，針對這個問題要額外進行一些商業(yè)智能BI數據倉庫ETL日志框架的開發(fā)和改造，讓每次ETL執(zhí)行時去檢查一下日志，上次沒有執(zhí)行完成這次就先不啟動，等待上次執(zhí)行完畢之后再啟動就不會出現沖突了。

商業(yè)智能BI數據倉庫ETL架構改造

這些我們之前在一些大型的項目上并行跑上百個包就是通過對商業(yè)智能BI數據倉庫ETL框架的改造來完成數據指標的準實時實現，當然這個商業(yè)智能BI準實時要取決于指標自身的計算時間周期和過程。

所以，我們會大量的使用增量抽取，包括對商業(yè)智能BI中數據表索引、查詢性能的優(yōu)化。

以往是串行的從下往上執(zhí)行每個包，一個包的調度等到之前的包的調度執(zhí)行完畢再執(zhí)行?，F在相當于把需要做實時或者準實時的。

商業(yè)智能BI指標從原來的包中分離出來單獨的來維護組成一個新的串行，這種商業(yè)智能BI數據倉庫ETL架構的設計方式跟以往傳統(tǒng)的數據倉庫ETL架構就有很大的區(qū)別了。

我們現在在我們自己商業(yè)智能BI產品的ETL調度就是按指標為線性的方式來實現的，每個指標可以獨立的進行抽取調度，并且全部都是配置化的。這種商業(yè)智能BI中ETL調度的方式也是為實時性數據倉庫、實時性商業(yè)智能BI打下了基礎。

那如果要實現完全的商業(yè)智能BI實時性分析，而不是基于個別指標的準實時分析，又大概是一個什么樣的過程呢，下次分享。