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

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

文章圖片

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

文章圖片

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

文章圖片


之前的文章講到了商業智能BI對數據的同步處理機制主要是采用T+1的方式 , 這部分數據我們一般把它們叫做離線數據 , 這些數據來自于各個業務系統 。 從業務系統批量抽取過來的數據要經過一系列的清洗、轉換計算 , 才能進入商業智能BI數倉 , 并在最后達到分析展現 , 這個過程是有時間周期的 , 存在一個時間窗口 , 所以是非實時的 。
商業智能BI的實時要求通常在商業智能BI項目里面 , 大部分的分析指標、數據是不要求做到實時的 , 特別是像企業的經營管理分析、財務分析等等 。 這些數據在商業智能BI項目中的準確性要求遠遠大于時效性 , 所以此類數據隔天看基本上是足以滿足企業大部分的業務分析場景的 。

但在商業智能BI項目里面也有一些例外 , 比如像實時預警類的、監控類的一些數據指標 , 對這種數據的實時性要求就會比較高一些 , 數據延遲時間不能太長 , 要求達到秒級、分鐘級以內 , 這類數據就需要進行商業智能BI實時處理 。 這兩種不同形態的數據處理方式是不一樣的 。
商業智能BI離線數據處理在以往的商業智能BI項目中 , 離線數據量不大的時候 , 比如TB級別以下 , 傳統的數據倉庫ETL架構大部分場景都可以滿足 。 數據量大的時候比如TB、PB級別或以上的數據處理 , 底層就可以采用Hadoop分布式系統框架 , 通過集群的方式進行高速運算和存儲 。 最底層的HDFS分布式文件系統存儲數據 , MapReduce分布式計算框架對數據進行計算處理 。

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數據 。

實時數據指標的計算主要是進入到流式計算平臺 , 像Storm、Flink或者SparkStreaming;非實時的、大批量的數據就進入到批數據離線計算平臺 , 就是前面提到的Hadoop、Mapreduce、Hive 數據倉庫去處理非實時性的T+1的指標 。 這樣的一種架構兼顧了小批量的實時性數據和大批量的非實時性數據處理 , 但運維成本很高 , 因為是兩套分布式系統 , 維護的工作量很大 。
把Lambda架構做簡化 , 去掉了離線批處理部分 , 就是Kappa架構 , 數據以流的方式被采集 , 就只關心流式計算 。 因為現在的Kafaka是可以支持數據持久化的 , 可以保存更長時間的歷史數據 , 代替了Lambda架構中離線批處理的部分 。 但對于歷史數據吞吐能力就會有所限制 , 只能通過增加計算資源來解決 。 包括數據的容錯性 , 對有些場景也并不非常適合Kappa架構 。

相關經驗推薦