大數據多維分析平臺的實踐

大數據多維分析平臺的實踐前端

1、  大數據多維分析平臺搭建的初心mysql

隨着公司業務量的增加,基於傳統關係型數據庫搭建的各類報表查詢分析系統,性能降低明顯。同時因爲大數據平臺的的日趨完善,實時的核心業務數據逐步進入大數據平臺。數據進入了大數據平臺,相伴而來的是各類業務需求,這裏主要聚焦在如何高效穩定的基於大數據平臺的數據進行查詢。經過分析,咱們面臨的挑戰以下:sql

  • 億級別表下任意維度和時間跨度的高效的統計查詢
  • 業務分析的維度愈來愈多,是否能夠提供一個靈活的多維度組合查詢的工具,而不是針對不一樣的維度組合開發不一樣的報表

      基於以上目標,開始搭建大數據的多維分析平臺。數據庫

2、  多維分析平臺技術選型apache

  搭建多維分析平臺,首先面臨的是技術選型,基於咱們對開源框架的使用經驗和實際狀況,咱們主要看業界主流的公司是如何使用應對的,在技術選型上會進行必定的比較,但不會投入比較大的資源進行驗證,主張快速的迭代,效果的評估。多維分析平臺技術選型主要面臨是OLAP引擎和前端UI的選型。緩存

  咱們先來看一下OLAP的基本概念和分類。安全

OLAP 翻譯成中文叫聯機分析處理,OLTP 叫聯機事務處理。OLTP 它的核心是事務,實際上就是咱們常見的數據庫。咱們業務數據庫就是面向於事務。它的併發量會比較高,可是操做的數據量會比較小。它是實時更新的。數據庫的設計會按照 3NF 範式,更高的話可能會按照 BC 範式之類的來作。而 OLAP 的核心是分析,面向應用是分析決策,須要分析的數據級會很是大,可能 TB,甚至 PB 都會有。它的數據更新會稍微慢一些,它的設計通常是反範式的,由於面向分析。常見的是雪花模型和星型模型。數據結構

 OLAP的引擎目前主要分爲3類架構

第一種叫 ROLAP,叫關係型 OLAP,它的特色就是它是基於關係性模型,計算的時候,根據原始數據去作聚合運算。常見的實現,小數據量能夠利用 MySQL、SqlServer 這種傳統數據庫,而大數據量能夠利用 Spark SQL、Tidb、ES 這些項目。併發

第二種類型叫 MOLAP,叫多維 OLAP,它的特色就是它會基於一個預約義的模型,我須要知道,要根據什麼維度,要去算哪些指標,我提早就把這些結果弄好,存儲在引擎上。細節數據和聚合後的數據保存在cube中,以空間換時間,查詢效率高。

實際上咱們的不少業務也是基於此思想去作的,好比咱們會在ES裏面按照電站、客戶等維度進行聚合,知足平常的T+1查詢需求,只不過這個地方每一個聚合維度須要在ES裏面作一個表,並增長上覆雜的ETL處理.符合這個理念在業界用的比較多的爲Kylin. 而且基於Kylin 有完整的一套開源產品KMS。涵蓋了多維分析的前端UI及多維分析數據庫。

第三種叫 HOLAP(Hybrid OLAP),叫混合 OLAP,特色是數據保留在關係型數據庫的事實表中,可是聚合後的數據保存在cube中,聚合時須要比ROLAP高,但低於MOLAP。

綜合分析,技術選型上主要考慮第ROLAP和MOLAP。關於OLAP的分類已經通過了不少年的發展,市場上相關的產品也有不少,可是大數據下基於開源組件應該如何搞?

在大數據時代,有了分佈式計算和分佈式存儲,對於億級別表的任意時間跨度多維度組合的查詢,是否是能夠直接查詢,不用再預聚合。按照這個思路,查找了一些方案,沒有很明顯的技術傾向,咱們想嘗試了在Spark sql、tidb、es 上直接基於原始數據進行計算,效果不是很理想,這個按照理論,若是查詢要想達到比較好的結果,可能集羣規模須要加大很多。同時咱們對別了大數據的MOLAP的產品,發現了KMS框架,最大的特色是同時提供了前端展示、以及數據庫.而且目前業界主流互聯網公司也都在用.通過對比權衡,決定先期基於KMS框架搭建多維分析平臺.

3、  KMS框架介紹

  • 總體介紹

KMS = Kylin + Mondrian + Saiku 是一個簡單的三層架構,Git上已經有一個整合Kylin,Mondrian以及Saiku的項目。

Kylin: kylin是apache軟件基金會的頂級項目,一個開源的分佈式多維分析工具。經過預計算全部合理的維度組合下各個指標的值並把計算結果存儲到HBASE中的方式,大大提升分佈式多維分析的查詢效率。Kylin接收sql查詢語句做爲輸入,以查詢結果做爲輸出。經過預計算的方式,將在hive中可能須要幾分鐘的查詢響應時間降低到毫秒級

Mondrian:Mondrian是一個OLAP分析的引擎,主要工做是根據事先配置好的schema,將輸入的多維分析語句MDX(Multidimensional Expressions )翻譯成目標數據庫/數據引擎的執行語言(好比SQL)

Saiku: Saiku提供了一個多維分析的用戶操做界面,能夠經過簡單拖拉拽的方式迅速生成報表。Saiku的主要工做是根據事先配置好的schema,將用戶的操做轉化成MDX語句提供給Mondrian引擎執行

              其中Mondrian和Saiku已是很是成熟的框架,這裏咱們簡單看下Kylin的架構.

  • Kylin

Apache Kylin™是一個開源的分佈式分析引擎,提供Hadoop/Spark之上的SQL查詢接口及多維分析(OLAP)能力以支持超大規模數據,最初由eBay Inc. 開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。

 

 

Apache kylin 能提供低延遲(sub-second latency)的祕訣就是預計算,即針對一個星型拓撲結構的數據立方體,預計算多個維度組合的度量,而後將結果保存在 hbase 中,對外暴露 JDBC、ODBC、Rest API 的查詢接口,便可實現實時查詢。主要的使用包含3個步驟

l   經過Kylin提供的UI界面定義多維分析模型和Cube

l   對定義好的cube進行預計算,並將計算的結果存儲到hbase中

l   查詢時經過kylin引擎將查詢的sql引擎翻譯成hbase的scan等進行數據的查詢

 更多關於kylin的案例、原理、調優 你們能夠參考kylin的官方網站和社區,並能夠經過社區郵件進行問題交流.

4、  多維分析平臺的架構及應用狀況

  • 業務規劃

多維分析報表的建立,除了工具自己以外,對系統數據的處理和設計也是很是之重要,基於目前的使用,主要考慮如下幾個問題

²  多維報表的建立規劃過程須要有一套數據分層劃分模型,造成方法論、體系,以便指導業務人員進行報表的定義

²  新的業務需求提出時,是基於現有報表增長維度仍是增長一個新的報表

²  多個報表因爲業務需求,有重複的維度,重複的維度如何保證數據的一致性

基於以上咱們將數據和維度進行了層次劃分,業務處理過程採用逐層彙總的方式,進行數據彙總,最後經過saiku進行查詢展示.數據分層結構以下:

日誌數據:主要包含充電過程當中的分鐘報文數據、智能運維的分鐘報文數據,數據主要存在HBase、ES、TIDB

明細數據:主要包含各類不一樣的業務訂單數據。數據主要存儲在sqlserver、ES。

聚合數據:聚合數據爲按照不一樣的業務維度進行聚合的數據.好比 :按照電站、結算帳戶等歸集的充電數據。數據主要存儲在ES、Kylin.

公共維度:主要爲系統共用的基礎數據,好比電站、集控、終端數據。數據公用。

  • 部署架構

     

基於kylin 的設計架構,咱們充分利用現有的hbase集羣和計算集羣,搭建了基於KMS的多維分析平臺,這裏重點介紹一下咱們的架構部署狀況.先看一下部署架構.

 

目前進入kylin的數據主要來自於sqlserver和kafka,經過kettle、flume等工具將數據抽取到離線計算集羣hive數據庫。

數據抽取到hive數據庫以後,經過統一的調度工具調用Kylin的cube的build API,按照業務需求對以前定義好的cube進行預計算,計算好的結果存儲到hbase集羣

考慮到kylinbuild時佔用資源較多,集羣部署時,將kylin的build節點和查詢節點進行了分離。目前build節點爲一臺,查詢節點爲2臺。Hbase集羣目前和線上的業務公用.

前端展現saiku是個成熟的多維分析展示工具,對接的數據源有不少種,社區開源版本主要提供了kylin、mysql的支持。在適應性上能夠直接和kylin和tidb進行聯通使用。因爲kylin 查詢節點部署了2臺,爲了充分使用saiku的緩存,在saiku端開發了基於用戶的負載均衡。同時考慮到咱們目前使用的集羣,經過自定義開發實現了與ES集羣的連通性.

  • 應用狀況

目前經過kylin定義的cube有20幾個,最大的cube存儲已經超過2T.基於saiku定義的報表目前主要用於公司的運營、運維、充電安全相關的查詢。其中最大的查詢維度已經接近100個.系統應用截圖以下

 

 

  • 解決的問題

²  爲了保證saiku的HA同時充分利用saiku的緩存,開發了基於用戶的負載均衡框架

²  爲了方便經過手機進行多維分析報表的簡單修改,對saiku框架進行了修改,適配了手機

²  對saiku的元數據增長了緩存,提升了查詢速度

²  修改了saiku對大小寫的配置,適配kylin數據庫

²  參考kylin官方的案例和性能調優針對構建和查詢過程進行優化

5、  總結及問題

  • 目前存在的問題

²  多維分析集羣查詢對hbase的查詢內存消耗較大,查詢內存會引發gc,從而影響hbase的其餘讀寫服務

²  數據結構發生變化,歷史數據須要從新刷,運維成本比較高

²  歷史數據發生變化,須要常常進行歷史數據的刷新

²  非聚合組的維度進行查詢,部分查詢較慢

²  Saiku前端的靈活性和數據庫能力的矛盾

  • 下一步的方向

²  提高運維效率,在某些表上進行es的應用,提高報表的實時性,創建起不一樣等級的數據表不一樣的數據庫的區分原則

²  針對數據的平常刷新,開發簡單的運維工具

相關文章
相關標籤/搜索