BI?采用 T+1 模式

BI的數(shù)據(jù)倉庫架構(gòu)本身就決定了對(duì)數(shù)據(jù)的實(shí)時(shí)性要求沒有那么高，ETL的過程不可或缺，Extraction 抽取、Transformation 轉(zhuǎn)換、Loading 加載，這三個(gè)環(huán)節(jié)本身就是有時(shí)間損耗的。

?

首先，Extraction抽取，這些業(yè)務(wù)數(shù)據(jù)要使用SQL或者ETL工具從業(yè)務(wù)數(shù)據(jù)庫查詢并通過網(wǎng)絡(luò)傳輸加載到BI數(shù)據(jù)倉庫，視數(shù)據(jù)量的大小這個(gè)查詢和加載會(huì)花費(fèi)一定的時(shí)間，比如五分鐘、十分鐘甚至更長。這只是其中的一個(gè)查詢，所有查詢和加載全部執(zhí)行完短則幾分鐘，長則小時(shí)算很正常。

第二，數(shù)據(jù)加載到BI數(shù)據(jù)倉庫中了，數(shù)據(jù)要被加工處理，比如去重、合并、循環(huán)計(jì)算等等算出各種指標(biāo)放到數(shù)據(jù)倉庫不同的層里面，這個(gè)數(shù)據(jù)處理的過程在BI里是最耗時(shí)間的，幾十分鐘到幾個(gè)小時(shí)。指標(biāo)越多，業(yè)務(wù)邏輯越復(fù)雜，計(jì)算處理花的時(shí)間越長。 這個(gè)就是ETL處理的核心，Transformation 轉(zhuǎn)換。

第三，Transformation 轉(zhuǎn)換處理后的數(shù)據(jù)要寫入到目標(biāo)表比如BI中維度表、事實(shí)表里面，即Loading 加載。

?

ETL是BI數(shù)據(jù)倉庫的數(shù)據(jù)處理關(guān)鍵，其中E是數(shù)據(jù)源頭，T是中間數(shù)據(jù)計(jì)算處理的過程，L是將計(jì)算結(jié)果寫入、加載到目標(biāo)表。

并且很多時(shí)候白天業(yè)務(wù)系統(tǒng)有人可能會(huì)用的比較晚，有些數(shù)據(jù)業(yè)務(wù)部門更新的時(shí)間也比較晚。所以大部分情況下，BI都會(huì)選擇在晚上12點(diǎn)以后執(zhí)行ETL的調(diào)度從業(yè)務(wù)數(shù)據(jù)源將12點(diǎn)以前的所有已更新的數(shù)據(jù)同步過來處理。

所以，通常BI在晚上先把前兩個(gè)階段的事情給處理了，所有的數(shù)據(jù)都抽取、加工、計(jì)算完了，都提前存放在數(shù)據(jù)倉庫里。第二天頁面在刷新的時(shí)候直接訪問的是已經(jīng)計(jì)算好的數(shù)據(jù)倉庫的數(shù)據(jù)，這樣就很快了。

?

BI 數(shù)據(jù)倉庫 ETL 架構(gòu)

一般的 BI 數(shù)據(jù)倉庫 ETL 架構(gòu)是這么來設(shè)計(jì)的，分成四個(gè) ETL 包、或者五個(gè) ETL 包，每個(gè)包就是數(shù)據(jù)倉庫的一個(gè)分層的 ETL 合集。

?

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

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

第三個(gè)包就開始處理標(biāo)準(zhǔn)的事實(shí)層 Fact Tables。

第四個(gè)包處理Data Mart 數(shù)據(jù)集市層。

第五個(gè)包處理OLAP CUBE 等等。

這幾個(gè)包是由嚴(yán)格的依賴關(guān)系順序的，是串行的。也就是說第一個(gè)包沒有處理完，第二個(gè)包是不能執(zhí)行的；第二個(gè)包沒有執(zhí)行完，第三個(gè)包也是不會(huì)啟動(dòng)的。

我上面講到的?BI 數(shù)據(jù)倉庫 ETL架構(gòu)是非常標(biāo)準(zhǔn)的分層架構(gòu)設(shè)計(jì)，這五個(gè)包通常會(huì)放到比如Windows定時(shí)任務(wù)JOB里面去做定時(shí)調(diào)度，比如每天晚上執(zhí)行一次。

BI 數(shù)據(jù)倉庫 ETL 架構(gòu)問題

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

?

第二個(gè)點(diǎn)就是，這個(gè)JOB定時(shí)執(zhí)行的任務(wù)時(shí)間間隔要大于這個(gè)JOB的執(zhí)行最長時(shí)間。比如這個(gè)JOB一般執(zhí)行一分鐘，那設(shè)置BI定時(shí)調(diào)度的時(shí)間間隔最好就是兩分鐘或以上。什么意思呢，這個(gè)指標(biāo)整個(gè)流程還沒有計(jì)算完，下個(gè)定時(shí)任務(wù)啟動(dòng)了，上次執(zhí)行正好把數(shù)據(jù)寫入完成了，這次任務(wù)就把數(shù)據(jù)給清空了，這樣就亂套了。

所以，針對(duì)這個(gè)問題要額外進(jìn)行一些BI數(shù)據(jù)倉庫ETL日志框架的開發(fā)和改造，讓每次ETL執(zhí)行時(shí)去檢查一下日志，上次沒有執(zhí)行完成這次就先不啟動(dòng)，等待上次執(zhí)行完畢之后再啟動(dòng)就不會(huì)出現(xiàn)沖突了。

BI 數(shù)據(jù)倉庫 ETL 架構(gòu)改造

這些我們之前在一些大型的項(xiàng)目上并行跑上百個(gè)包就是通過對(duì)BI數(shù)據(jù)倉庫ETL框架的改造來完成數(shù)據(jù)指標(biāo)的準(zhǔn)實(shí)時(shí)實(shí)現(xiàn)，當(dāng)然這個(gè)BI準(zhǔn)實(shí)時(shí)要取決于指標(biāo)自身的計(jì)算時(shí)間周期和過程。

所以，我們會(huì)大量的使用增量抽取，包括對(duì)BI中數(shù)據(jù)表索引、查詢性能的優(yōu)化。

?

以往是串行的從下往上執(zhí)行每個(gè)包，一個(gè)包的調(diào)度等到之前的包的調(diào)度執(zhí)行完畢再執(zhí)行。現(xiàn)在相當(dāng)于把需要做實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)的BI指標(biāo)從原來的包中分離出來單獨(dú)的來維護(hù)組成一個(gè)新的串行，這種BI數(shù)據(jù)倉庫ETL架構(gòu)的設(shè)計(jì)方式跟以往傳統(tǒng)的數(shù)據(jù)倉庫ETL架構(gòu)就有很大的區(qū)別了。

我們現(xiàn)在在我們自己BI產(chǎn)品的ETL調(diào)度就是按指標(biāo)為線性的方式來實(shí)現(xiàn)的，每個(gè)指標(biāo)可以獨(dú)立的進(jìn)行抽取調(diào)度，并且全部都是配置化的。這種BI中ETL調(diào)度的方式也是為實(shí)時(shí)性數(shù)據(jù)倉庫、實(shí)時(shí)性BI打下了基礎(chǔ)。

BI?的實(shí)時(shí)要求

通常在BI項(xiàng)目里面，大部分的分析指標(biāo)、數(shù)據(jù)是不要求做到實(shí)時(shí)的，特別是像企業(yè)的經(jīng)營管理分析、財(cái)務(wù)分析等等。這些數(shù)據(jù)在BI項(xiàng)目中的準(zhǔn)確性要求遠(yuǎn)遠(yuǎn)大于時(shí)效性，所以此類數(shù)據(jù)隔天看基本上是足以滿足企業(yè)大部分的業(yè)務(wù)分析場景的。

?

但在BI項(xiàng)目里面也有一些例外，比如像實(shí)時(shí)預(yù)警類的、監(jiān)控類的一些數(shù)據(jù)指標(biāo)，對(duì)這種數(shù)據(jù)的實(shí)時(shí)性要求就會(huì)比較高一些，數(shù)據(jù)延遲時(shí)間不能太長，要求達(dá)到秒級(jí)、分鐘級(jí)以內(nèi)，這類數(shù)據(jù)就需要進(jìn)行BI實(shí)時(shí)處理。這兩種不同形態(tài)的數(shù)據(jù)處理方式是不一樣的。

BI?離線數(shù)據(jù)處理

在以往的BI項(xiàng)目中，離線數(shù)據(jù)量不大的時(shí)候，比如TB級(jí)別以下，傳統(tǒng)的數(shù)據(jù)倉庫ETL架構(gòu)大部分場景都可以滿足。數(shù)據(jù)量大的時(shí)候比如TB、PB級(jí)別或以上的數(shù)據(jù)處理，底層就可以采用Hadoop分布式系統(tǒng)框架，通過集群的方式進(jìn)行高速運(yùn)算和存儲(chǔ)。最底層的HDFS分布式文件系統(tǒng)存儲(chǔ)數(shù)據(jù)，MapReduce分布式計(jì)算框架對(duì)數(shù)據(jù)進(jìn)行計(jì)算處理。

?

Hadoop的數(shù)據(jù)倉庫Hive通過HiveSQL就是HSQL轉(zhuǎn)換成MapReduce作業(yè)任務(wù)執(zhí)行數(shù)據(jù)查詢。Hive清洗處理后的結(jié)果如果是面向海量數(shù)據(jù)隨機(jī)查詢的場景還可以存入HBase Hadoop Database中。

HBase 是真正的數(shù)據(jù)庫，NoSQL數(shù)據(jù)庫，目的主要是為了支持和彌補(bǔ)Hadoop對(duì)實(shí)時(shí)數(shù)據(jù)操作的瓶頸。Hive就是一個(gè)殼，但它簡化了Hadoop的復(fù)雜性，不需要學(xué)JAVA就可以通過SQL操作MapReduce去訪問HDFS，即通過SQL語句像操作關(guān)系數(shù)據(jù)庫一樣操作HDFS系統(tǒng)中的目錄和文件。

上面講到的就是傳統(tǒng)的數(shù)據(jù)倉庫模式下的離線數(shù)據(jù)處理和大數(shù)據(jù)架構(gòu)下的離線數(shù)據(jù)處理，那么我們?cè)賮碚f下大數(shù)據(jù)技術(shù)下的實(shí)時(shí)數(shù)據(jù)倉庫的數(shù)據(jù)處理架構(gòu)。

BI 實(shí)時(shí)數(shù)據(jù)處理

我們之前也研究過很多不同的框架，比如早期的Lambda架構(gòu)，通過Kafaka、Flume組件對(duì)底層數(shù)據(jù)源數(shù)據(jù)進(jìn)行收集，然后分兩條線進(jìn)行處理，一條處理實(shí)時(shí)數(shù)據(jù)指標(biāo)，一條處理T+1數(shù)據(jù)。

?

實(shí)時(shí)數(shù)據(jù)指標(biāo)的計(jì)算主要是進(jìn)入到流式計(jì)算平臺(tái)，像Storm、Flink或者SparkStreaming；非實(shí)時(shí)的、大批量的數(shù)據(jù)就進(jìn)入到批數(shù)據(jù)離線計(jì)算平臺(tái)，就是前面提到的Hadoop、Mapreduce、Hive 數(shù)據(jù)倉庫去處理非實(shí)時(shí)性的T+1的指標(biāo)。這樣的一種架構(gòu)兼顧了小批量的實(shí)時(shí)性數(shù)據(jù)和大批量的非實(shí)時(shí)性數(shù)據(jù)處理，但運(yùn)維成本很高，因?yàn)槭莾商追植际较到y(tǒng)，維護(hù)的工作量很大。

把Lambda架構(gòu)做簡化，去掉了離線批處理部分，就是Kappa架構(gòu)，數(shù)據(jù)以流的方式被采集，就只關(guān)心流式計(jì)算。因?yàn)楝F(xiàn)在的Kafaka是可以支持?jǐn)?shù)據(jù)持久化的，可以保存更長時(shí)間的歷史數(shù)據(jù)，代替了Lambda架構(gòu)中離線批處理的部分。但對(duì)于歷史數(shù)據(jù)吞吐能力就會(huì)有所限制，只能通過增加計(jì)算資源來解決。包括數(shù)據(jù)的容錯(cuò)性，對(duì)有些場景也并不非常適合Kappa架構(gòu)。

我們目前在一些項(xiàng)目上采用的數(shù)據(jù)實(shí)時(shí)處理架構(gòu)，比如使用數(shù)據(jù)庫binlog日志，或者其它非關(guān)系型數(shù)據(jù)庫產(chǎn)生的流式數(shù)據(jù)發(fā)送到Kafaka或者Flink-CDC，再通過Flink流處理引擎創(chuàng)建表映射、注冊(cè)表，然后通過Flink引擎提供的FlinkSQL相關(guān)接口實(shí)現(xiàn)數(shù)據(jù)流式處理，最終將變化的數(shù)據(jù)實(shí)時(shí)寫入到BI數(shù)據(jù)倉庫供前端可視化做實(shí)時(shí)展現(xiàn)和分析。

BI?業(yè)務(wù)場景需求

除了我上面提到的一些技術(shù)解決方案之外，大家在網(wǎng)上也可以看到各種各樣的大數(shù)據(jù)實(shí)時(shí)處理框架或者解決方案的介紹。就會(huì)發(fā)現(xiàn)雖然大家都是在講同一件事，但是實(shí)現(xiàn)方式和路徑、采用的技術(shù)框架各不相同，為什么？因?yàn)榫唧w要解決的業(yè)務(wù)場景不一樣。

?

比如有些BI項(xiàng)目可能就不是一個(gè)BI分析需求，就是一個(gè)大屏的實(shí)時(shí)數(shù)據(jù)展現(xiàn)，但用戶一看大屏可視化，就會(huì)認(rèn)為這個(gè)不就是BI嘛，拿BI來做。

但實(shí)際上 ，這樣理解是有問題的，可視化就一定是BI嗎？WEB前端直接開發(fā)行不行，是完全可以的。底層使用Flume+Kafaka+Flink+Redis 架構(gòu)，再找個(gè)前端開發(fā)就可以設(shè)計(jì)大屏的實(shí)時(shí)數(shù)據(jù)刷新了，跟BI有什么關(guān)系，并沒有關(guān)系。

BI的強(qiáng)項(xiàng)不是去做可視化實(shí)時(shí)數(shù)據(jù)展現(xiàn)的，BI的強(qiáng)項(xiàng)是多系統(tǒng)打通、數(shù)據(jù)倉庫建模以及對(duì)歷史數(shù)據(jù)的多維分析、鉆透、關(guān)聯(lián)等分析路徑的實(shí)現(xiàn)。

不同的行業(yè)、不同的分析型項(xiàng)目數(shù)據(jù)源各不相同。業(yè)務(wù)分析場景、數(shù)據(jù)場景眾多，很難用某一種技術(shù)框架解決所有的問題。要考慮兼顧數(shù)據(jù)的時(shí)效性，又要考慮兼顧數(shù)據(jù)的準(zhǔn)確性，還有考慮數(shù)據(jù)量吞吐和處理能力，以及兼顧隨時(shí)變化的業(yè)務(wù)計(jì)算規(guī)則。這么多的場景和要求，很難通過標(biāo)準(zhǔn)化的技術(shù)方案去平衡，只能看具體的業(yè)務(wù)場景再針對(duì)性的提供相應(yīng)的解決辦法。

?

大家就比較容易理解為什么BI分析工具不去提供這種實(shí)時(shí)數(shù)據(jù)的處理能力，因?yàn)檫@種實(shí)時(shí)數(shù)據(jù)處理的場景是非標(biāo)的，很難標(biāo)準(zhǔn)化去適應(yīng)各種復(fù)雜的業(yè)務(wù)場景。

即使BI有這個(gè)能力，也是基于某些特定場景之下的，一定不會(huì)適配所有的場景。所以一般BI都是和這種大數(shù)據(jù)平臺(tái)、實(shí)時(shí)數(shù)據(jù)處理平臺(tái)去搭配使用的，針對(duì)不同的業(yè)務(wù)場景設(shè)計(jì)不同的大數(shù)據(jù)實(shí)時(shí)數(shù)據(jù)處理方案，把數(shù)據(jù)規(guī)范化、標(biāo)準(zhǔn)化、模型化，BI負(fù)責(zé)只對(duì)接到這一層就可以了。

BI?實(shí)時(shí)數(shù)據(jù)處理總結(jié)

不管是離線數(shù)據(jù)還是實(shí)時(shí)數(shù)據(jù)采用什么樣的架構(gòu)都是為了解決特定業(yè)務(wù)場景下的問題，什么時(shí)候采用離線處理、什么時(shí)候采用實(shí)時(shí)處理。除了這些需求的重要性、緊迫度需要評(píng)估外，還需要考慮資源的投入。

?

企業(yè)是用最小的、最經(jīng)濟(jì)的資源達(dá)成既定的業(yè)務(wù)目標(biāo)，而不是為了追求所謂的數(shù)據(jù)實(shí)時(shí)而追求實(shí)時(shí)。做不到實(shí)時(shí)分析，只做離線就是技術(shù)不行、產(chǎn)品不行、能力不行。造子彈跟造原子彈都是造彈，但畢竟還不一樣。

數(shù)據(jù)準(zhǔn)實(shí)時(shí)處理場景

理性一點(diǎn)的朋友就會(huì)說了，幾秒鐘看交易數(shù)據(jù)、交易金額有什么用啊，幾秒鐘能進(jìn)來多少錢啊，根本就沒有必要看。確實(shí)如此，我也認(rèn)為沒有必要。沒有必要的原因可能是因?yàn)檫@個(gè)數(shù)據(jù)不會(huì)有太大的變化，如果變化大比如一秒鐘增加十幾萬，十秒鐘上百萬的交易金額，這個(gè)是不是就很有點(diǎn)意思了？我們正好就有這樣的客戶，幾秒鐘時(shí)間大屏的數(shù)據(jù)刷一下，交易額就增加了幾十萬、有時(shí)上百萬，一年五千個(gè)億往上的交易金額，這個(gè)只是其中某一個(gè)渠道的交易金額。那這個(gè)數(shù)據(jù)就非常有意思了，很刺激，隔一會(huì)那個(gè)牌子就跳一下，再算下變了多少萬了。

?

每次交易金額可能就幾百塊以內(nèi)，所以每秒鐘交易的筆數(shù)累計(jì)下來就非常的多，一年下來幾十億條交易數(shù)據(jù)很正常。如果直接用SQL去查詢，有可能頁面每10秒鐘刷新一次，前一次這個(gè)指標(biāo)的ETL里面的查詢都沒有執(zhí)行完，數(shù)據(jù)還沒有填充到數(shù)據(jù)倉庫表，后面的查詢就又來了。這種實(shí)現(xiàn)方式明顯是有問題的，效率比較低。

數(shù)據(jù)準(zhǔn)實(shí)時(shí)處理思路

那怎么來實(shí)現(xiàn)呢？就跟一層窗戶紙一樣，一捅就破，一講大家就明白了。

多做幾個(gè)ETL，第一個(gè)ETL每天晚上執(zhí)行一次，計(jì)算從今年開始到今天累計(jì)的交易金額，這個(gè)值算出來單獨(dú)存起來。哪怕是全量計(jì)算，也不怕，晚上執(zhí)行，哪怕執(zhí)行一個(gè)小時(shí)我也不怕，肯定能算的完。

?

第二個(gè)ETL每小時(shí)執(zhí)行一次，計(jì)算從今天零點(diǎn)到現(xiàn)在當(dāng)前小時(shí)的交易金額，到這個(gè)階段數(shù)據(jù)查詢的范圍就變小了，又算一個(gè)值存儲(chǔ)起來。

第三個(gè)ETL每分鐘執(zhí)行一次，計(jì)算從當(dāng)前小時(shí)零分到現(xiàn)在這一分鐘計(jì)算的值，存起來放著。

最后一個(gè)ETL每十秒鐘執(zhí)行一次，計(jì)算這一分鐘里交易金額，又算出一個(gè)值更新到一個(gè)表里面。同時(shí)，這個(gè)更新的值和前面三個(gè)ETL算出來的值一加起來，不就是全年累計(jì)的實(shí)時(shí)交易金額嗎？這個(gè)問題就解決掉了。

這個(gè)過程實(shí)際上就是利用時(shí)間日期戳和ETL做了增量抽取更新，以及增量計(jì)算，把整個(gè)數(shù)據(jù)表的聚合匯總砍成一節(jié)一節(jié)的，不同的ETL計(jì)算不同的時(shí)間段的數(shù)據(jù)，這樣整體數(shù)據(jù)量會(huì)比較小。調(diào)度時(shí)間間隔大的ETL，執(zhí)行的數(shù)據(jù)查詢范圍就越大。調(diào)度間隔小，執(zhí)行的數(shù)據(jù)查詢范圍就越小。

?

這種方式大家可以在項(xiàng)目上試一試，是完全可以實(shí)現(xiàn)一些準(zhǔn)實(shí)時(shí)效果的。當(dāng)然，一個(gè)指標(biāo)就用了四個(gè)不同的ETL調(diào)度。十個(gè)指標(biāo)，理論上就需要四十個(gè)。當(dāng)然按天或者按小時(shí)執(zhí)行的指標(biāo)視情況可以放到一個(gè)ETL調(diào)度里，減少一些維護(hù)工作量。但總體上來說指標(biāo)越多，ETL的調(diào)度配置就會(huì)越多，后期維護(hù)成本自然也會(huì)比較高一些。