之前的文章講到了商業(yè)智能BI對(duì)數(shù)據(jù)的同步處理機(jī)制主要是采用T+1的方式，這部分?jǐn)?shù)據(jù)我們一般把它們叫做離線數(shù)據(jù)，這些數(shù)據(jù)來(lái)自于各個(gè)業(yè)務(wù)系統(tǒng)。從業(yè)務(wù)系統(tǒng)批量抽取過(guò)來(lái)的數(shù)據(jù)要經(jīng)過(guò)一系列的清洗、轉(zhuǎn)換計(jì)算，才能進(jìn)入商業(yè)智能BI數(shù)倉(cāng)，并在最后達(dá)到分析展現(xiàn)，這個(gè)過(guò)程是有時(shí)間周期的，存在一個(gè)時(shí)間窗口，所以是非實(shí)時(shí)的。

商業(yè)智能BI的實(shí)時(shí)要求

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

?

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

商業(yè)智能BI離線數(shù)據(jù)處理

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

?

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

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

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

商業(yè)智能BI實(shí)時(shí)數(shù)據(jù)處理

我們之前也研究過(guò)很多不同的框架，比如早期的Lambda架構(gòu)，通過(guò)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ù)倉(cāng)庫(kù)去處理非實(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)做簡(jiǎn)化，去掉了離線批處理部分，就是Kappa架構(gòu)，數(shù)據(jù)以流的方式被采集，就只關(guān)心流式計(jì)算。因?yàn)楝F(xiàn)在的Kafaka是可以支持?jǐn)?shù)據(jù)持久化的，可以保存更長(zhǎng)時(shí)間的歷史數(shù)據(jù)，代替了Lambda架構(gòu)中離線批處理的部分。但對(duì)于歷史數(shù)據(jù)吞吐能力就會(huì)有所限制，只能通過(guò)增加計(jì)算資源來(lái)解決。包括數(shù)據(jù)的容錯(cuò)性，對(duì)有些場(chǎng)景也并不非常適合Kappa架構(gòu)。

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

商業(yè)智能BI業(yè)務(wù)場(chǎng)景需求

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

?

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

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

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

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

?

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

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

并且像上面提到的這些過(guò)程，投入不會(huì)小，特別是后期的運(yùn)維投入，數(shù)據(jù)出一點(diǎn)問(wèn)題就是大問(wèn)題，到底是哪個(gè)環(huán)節(jié)出的問(wèn)題？網(wǎng)絡(luò)延遲的問(wèn)題，吞吐量處理能力的問(wèn)題還是資源計(jì)算窗口不足的問(wèn)題，有得折騰了。

商業(yè)智能BI實(shí)時(shí)數(shù)據(jù)處理總結(jié)

不管是離線數(shù)據(jù)還是實(shí)時(shí)數(shù)據(jù)采用什么樣的架構(gòu)都是為了解決特定業(yè)務(wù)場(chǎng)景下的問(wèn)題，什么時(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)品不行、能力不行。造子彈跟造原子彈都是造彈，但畢竟還不一樣。

那也有同學(xué)問(wèn)了，有沒(méi)有什么比較經(jīng)濟(jì)的成本，就想用造子彈的成本來(lái)感受一下原子彈的威力。就幾個(gè)核心的指標(biāo)，做成準(zhǔn)實(shí)時(shí)的，比如10秒鐘、半分鐘刷新、刷新行不行？點(diǎn)贊關(guān)注收藏，之后會(huì)通過(guò)系列文章繼續(xù)解析。