1. 首頁 > 生活百科 > 科技 > >

平板電腦|實時BI（三）離線數據與實時數據處理的技術實現( 二 )

平板電腦科大訊飛


我們目前在一些項目上采用的數據實時處理架構 ， 比如使用數據庫binlog日志 ， 或者其它非關系型數據庫產生的流式數據發送到Kafaka或者Flink-CDC ， 再通過Flink流處理引擎創建表映射、注冊表 ， 然后通過Flink引擎提供的FlinkSQL相關接口實現數據流式處理 ， 最終將變化的數據實時寫入到BI數據倉庫供前端可視化做實時展現和分析 。
商業智能BI業務場景需求除了我上面提到的一些技術解決方案之外 ， 大家在網上也可以看到各種各樣的大數據實時處理框架或者解決方案的介紹 。 就會發現雖然大家都是在講同一件事 ， 但是實現方式和路徑、采用的技術框架各不相同 ， 為什么？因為具體要解決的業務場景不一樣 。

比如有些商業智能BI項目可能就不是一個商業智能BI分析需求 ， 就是一個大屏的實時數據展現 ， 但用戶一看大屏可視化 ， 就會認為這個不就是商業智能BI嘛 ， 拿商業智能BI來做 。
但實際上， 這樣理解是有問題的 ， 可視化就一定是商業智能BI嗎？WEB前端直接開發行不行 ， 是完全可以的 。 底層使用Flume+Kafaka+Flink+Redis 架構 ， 再找個前端開發就可以設計大屏的實時數據刷新了 ， 跟商業智能BI有什么關系 ， 并沒有關系 。
商業智能BI的強項不是去做可視化實時數據展現的 ， 商業智能BI的強項是多系統打通、數據倉庫建模以及對歷史數據的多維分析、鉆透、關聯等分析路徑的實現 。
所以 ， 不同的行業、不同的分析型項目數據源各不相同 。 業務分析場景、數據場景眾多 ， 很難用某一種技術框架解決所有的問題 。 要考慮兼顧數據的時效性 ， 又要考慮兼顧數據的準確性 ， 還有考慮數據量吞吐和處理能力 ， 以及兼顧隨時變化的業務計算規則 。 這么多的場景和要求 ， 很難通過標準化的技術方案去平衡 ， 只能看具體的業務場景再針對性的提供相應的解決辦法 。

所以 ， 大家就比較容易理解為什么商業智能BI分析工具不去提供這種實時數據的處理能力 ， 因為這種實時數據處理的場景是非標的 ， 很難標準化去適應各種復雜的業務場景 。
即使商業智能BI有這個能力 ， 也是基于某些特定場景之下的 ， 一定不會適配所有的場景 。 所以一般商業智能BI都是和這種大數據平臺、實時數據處理平臺去搭配使用的 ， 針對不同的業務場景設計不同的大數據實時數據處理方案 ， 把數據規范化、標準化、模型化 ， 商業智能BI負責只對接到這一層就可以了 。
并且像上面提到的這些過程 ， 投入不會小 ， 特別是后期的運維投入 ， 數據出一點問題就是大問題 ， 到底是哪個環節出的問題？網絡延遲的問題 ， 吞吐量處理能力的問題還是資源計算窗口不足的問題 ， 有得折騰了 。
商業智能BI實時數據處理總結不管是離線數據還是實時數據采用什么樣的架構都是為了解決特定業務場景下的問題 ， 什么時候采用離線處理、什么時候采用實時處理 。 除了這些需求的重要性、緊迫度需要評估外 ， 還需要考慮資源的投入 。
【平板電腦|實時BI（三）離線數據與實時數據處理的技術實現】
企業是用最小的、最經濟的資源達成既定的業務目標 ， 而不是為了追求所謂的數據實時而追求實時 。 做不到實時分析 ， 只做離線就是技術不行、產品不行、能力不行 。 造子彈跟造原子彈都是造彈 ， 但畢竟還不一樣 。
那也有同學問了 ， 有沒有什么比較經濟的成本 ， 就想用造子彈的成本來感受一下原子彈的威力 。 就幾個核心的指標 ， 做成準實時的 ， 比如10秒鐘、半分鐘刷新、刷新行不行？點贊關注收藏 ， 之后會通過系列文章繼續解析 。

相關經驗推薦