實時BI（三）離線資料與實時資料處理的技術實現
之前的文章講到了商業智慧BI對資料的同步處理機制主要是採用T+1的方式，這部分資料我們一般把它們叫做離線資料，這些資料來自於各個業務系統。從業務系統批次抽取過來的資料要經過一系列的清洗、轉換計算，才能進入商業智慧BI數倉，並在最後達到分析展現，這個過程是有時間週期的，存在一個時間視窗，所以是非實時的。
商業智慧BI的實時要求
通常在商業智慧BI專案裡面，大部分的分析指標、資料是不要求做到實時的，特別是像企業的經營管理分析、財務分析等等。這些資料在商業智慧BI專案中的準確性要求遠遠大於時效性，所以此類資料隔天看基本上是足以滿足企業大部分的業務分析場景的。
資料視覺化大屏 - 派可資料商業智慧BI視覺化分析平臺
但在商業智慧BI專案裡面也有一些例外，比如像實時預警類的、監控類的一些資料指標，對這種資料的實時性要求就會比較高一些，資料延遲時間不能太長，要求達到秒級、分鐘級以內，這類資料就需要進行商業智慧BI實時處理。這兩種不同形態的資料處理方式是不一樣的。
商業智慧BI離線資料處理
在以往的商業智慧BI專案中，離線資料量不大的時候，比如TB級別以下，傳統的資料倉庫ETL架構大部分場景都可以滿足。資料量大的時候比如TB、PB級別或以上的資料處理，底層就可以採用Hadoop分散式系統框架，透過叢集的方式進行高速運算和儲存。最底層的HDFS分散式檔案系統儲存資料，MapReduce分散式計算框架對資料進行計算處理。
資料倉庫 - 派可資料商業智慧BI視覺化分析平臺
Hadoop的資料倉庫Hive透過HiveSQL就是HSQL轉換成MapReduce作業任務執行資料查詢。Hive清洗處理後的結果如果是面向海量資料隨機查詢的場景還可以存入HBase Hadoop Database中。
HBase 是真正的資料庫，NoSQL資料庫，目的主要是為了支援和彌補Hadoop對實時資料操作的瓶頸。Hive就是一個殼，但它簡化了Hadoop的複雜性，不需要學JAVA就可以透過SQL操作MapReduce去訪問HDFS，即透過SQL語句像操作關係資料庫一樣操作HDFS系統中的目錄和檔案。
上面講到的就是傳統的資料倉庫模式下的離線資料處理和大資料架構下的離線資料處理，那麼我們再來說下大資料技術下的實時資料倉庫的資料處理架構。
商業智慧BI實時資料處理
我們之前也研究過很多不同的框架，比如早期的Lambda架構，透過Kafaka、Flume元件對底層資料來源資料進行收集，然後分兩條線進行處理，一條處理實時資料指標，一條處理T+1資料。
資料視覺化大屏 - 派可資料商業智慧BI視覺化分析平臺
實時資料指標的計算主要是進入到流式計算平臺，像Storm、Flink或者SparkStreaming；非實時的、大批次的資料就進入到批資料離線計算平臺，就是前面提到的Hadoop、Mapreduce、Hive 資料倉庫去處理非實時性的T+1的指標。這樣的一種架構兼顧了小批次的實時性資料和大批次的非實時性資料處理，但運維成本很高，因為是兩套分散式系統，維護的工作量很大。
把Lambda架構做簡化，去掉了離線批處理部分，就是Kappa架構，資料以流的方式被採集，就只關心流式計算。因為現在的Kafaka是可以支援資料持久化的，可以儲存更長時間的歷史資料，代替了Lambda架構中離線批處理的部分。但對於歷史資料吞吐能力就會有所限制，只能透過增加計算資源來解決。包括資料的容錯性，對有些場景也並不非常適合Kappa架構。
我們目前在一些專案上採用的資料實時處理架構，比如使用資料庫binlog日誌，或者其它非關係型資料庫產生的流式資料傳送到Kafaka或者Flink-CDC，再透過Flink流處理引擎建立表對映、登錄檔，然後透過Flink引擎提供的FlinkSQL相關介面實現資料流式處理，最終將變化的資料實時寫入到BI資料倉庫供前端視覺化做實時展現和分析。
商業智慧BI業務場景需求
除了我上面提到的一些技術解決方案之外，大家在網上也可以看到各種各樣的大資料實時處理框架或者解決方案的介紹。就會發現雖然大家都是在講同一件事，但是實現方式和路徑、採用的技術框架各不相同，為什麼？因為具體要解決的業務場景不一樣。
資料視覺化大屏 - 派可資料商業智慧BI視覺化分析平臺
比如有些商業智慧BI專案可能就不是一個商業智慧BI分析需求，就是一個大屏的實時資料展現，但使用者一看大屏視覺化，就會認為這個不就是商業智慧BI嘛，拿商業智慧BI來做。
但實際上 ，這樣理解是有問題的，視覺化就一定是商業智慧BI嗎？WEB前端直接開發行不行，是完全可以的。底層使用Flume+Kafaka+Flink+Redis 架構，再找個前端開發就可以設計大屏的實時資料重新整理了，跟商業智慧BI有什麼關係，並沒有關係。
商業智慧BI的強項不是去做視覺化實時資料展現的，商業智慧BI的強項是多系統打通、資料倉庫建模以及對歷史資料的多維分析、鑽透、關聯等分析路徑的實現。
所以，不同的行業、不同的分析型專案資料來源各不相同。業務分析場景、資料場景眾多，很難用某一種技術框架解決所有的問題。要考慮兼顧資料的時效性，又要考慮兼顧資料的準確性，還有考慮資料量吞吐和處理能力，以及兼顧隨時變化的業務計算規則。這麼多的場景和要求，很難透過標準化的技術方案去平衡，只能看具體的業務場景再針對性的提供相應的解決辦法。
資料視覺化 - 派可資料商業智慧BI視覺化分析平臺
所以，大家就比較容易理解為什麼商業智慧BI分析工具不去提供這種實時資料的處理能力，因為這種實時資料處理的場景是非標的，很難標準化去適應各種複雜的業務場景。
即使商業智慧BI有這個能力，也是基於某些特定場景之下的，一定不會適配所有的場景。所以一般商業智慧BI都是和這種大資料平臺、實時資料處理平臺去搭配使用的，針對不同的業務場景設計不同的大資料實時資料處理方案，把資料規範化、標準化、模型化，商業智慧BI負責只對接到這一層就可以了。
並且像上面提到的這些過程，投入不會小，特別是後期的運維投入，資料出一點問題就是大問題，到底是哪個環節出的問題？網路延遲的問題，吞吐量處理能力的問題還是資源計算視窗不足的問題，有得折騰了。
商業智慧BI實時資料處理總結
不管是離線資料還是實時資料採用什麼樣的架構都是為了解決特定業務場景下的問題，什麼時候採用離線處理、什麼時候採用實時處理。除了這些需求的重要性、緊迫度需要評估外，還需要考慮資源的投入。
資料視覺化 - 派可資料商業智慧BI視覺化分析平臺
企業是用最小的、最經濟的資源達成既定的業務目標，而不是為了追求所謂的資料實時而追求實時。做不到實時分析，只做離線就是技術不行、產品不行、能力不行。造子彈跟造原子彈都是造彈，但畢竟還不一樣。
那也有同學問了，有沒有什麼比較經濟的成本，就想用造子彈的成本來感受一下原子彈的威力。就幾個核心的指標，做成準實時的，比如10秒鐘、半分鐘重新整理、重新整理行不行？點贊關注收藏，之後會透過系列文章繼續解析。
移動BI_ERP資料分析_自助敏捷BI分析_資料視覺化分析系統-派可資料
派可資料-商業智慧BI_大屏BI視覺化分析平臺_用友BI財務分析_資料中臺
