【案例】數據量猛增，BI分析效率過低怎麼破？

近日，Apache Kylin Innovation Meetup 在上海成功舉辦，有近200位小夥伴來到了現場。這次會議特別邀請到了金融、互聯網等行業的技術夥伴分享了 Kylin 在行業中的實操應用 。今天將首先與你們分享演講嘉賓王穎卓，中國銀聯數據服務團隊負責人的主講內容。您將瞭解到，金融機構基於傳統架構的BI分析業務遇到了哪些挑戰，以及這些問題如何隨着 Kylin 的引入被逐一攻破。

「 Kylin 的引入給咱們帶來了切實的好處， 如今整個報表分析的數據準備時間，從過去的8小時減小到2小時。」

——王穎卓， 中國銀聯數據服務團隊負責人，Kylin用戶

金融機構在BI分析中遇到了哪些挑戰？

首先簡單介紹一下咱們公司數據倉庫的背景，2008年公司開始建數據倉庫，2009年上線。這個數據倉庫運轉到如今已經有10個年頭，採用的是比較傳統標準的架構，數據倉庫主體用的是IBM DB2。

在 BI這塊咱們引入了 Cognos 做爲總的 BI 工具，當時，整個金融界都比較流行 Cognos。在這 10年內，包括 Cognos 等一些其餘商業版的多維分析工具，確實給企業分析帶來了很大的便利。時過境遷，如今到了大數據年代，數據量愈來愈大， Cognos 面臨了一些挑戰， 咱們數據量的增加， 10年間漲了10倍；在最近兩三年，咱們的業務量又更加迅猛地增加，這對數據分析的挑戰是巨大的。

Cognos 從整個功能、架構上來說， 都是基於單機版的，效率很低；所以咱們在 Cognos 的基礎上研發了一些工具，包括調度、Cube 刷新，Cube 訪問等等，這其中申請的專利就有好幾個。這些工具核心仍是基於單機的運轉，因此說在構建上它的擴展性很差，一個體現是，刷 Cube 的時間愈來愈長。

例如一些每日刷新的 Cube，業務分析用戶須要基於這些日 Cube 要出當日報表， 可是鑑於如今的數據量和處理能力，很難在他們預期的時間內達到要求，咱們技術團隊的壓力很大，作了不少工做，想了各類各樣的辦法在調優，可是收效仍然低於預期。

以上是咱們用 Cognos 碰到的一些挑戰，正是由於這個緣由，咱們在2015年在一個技術分享活動上，咱們和 Apache Kylin 第一次觸電。

Apache Kylin的性能和價值

在下圖能夠看到，Kylin 各方面的性能和 Cognos 相比有了大幅的提升，這些數據都是實際中的一些例子。從使用資源來說，大數據平臺的資源仍是比較富裕的，Kylin 整個架構比較強調讀寫分離，目前咱們在 Kylin 上投了20多臺機器進行 Cube 的構建和查詢。

首先看一下查詢，96%的查詢在10秒以內返回；除非是很是大、複雜的條件可能要到20秒左右。 而之前咱們的 Cognos 從打開到展現，拖拉拽創建一個基本的報表要接近一分鐘，Kylin 對用戶的體驗和感覺的提高是很是巨大的。

從整個構建性能上來說， Kylin 相比於 Cognos 也有巨大的提高。由於 Cognos 是單機，沒有辦法利用分佈式集羣資源，必須是一個比較獨立的 Cognos 在跑，天天跑8個小時以上。Kylin 的構建是在整個大數據平臺之上，跟其餘的批量計算共享集羣資源，這個時候基本上是兩個小時左右，就能夠把整個 Cube 構建出來。

膨脹率是一個關鍵點，在測試環境上，效果不是很好，有10倍以上的膨脹。當時我有點猶豫，問題出在什麼地方？後來跟 Kylin 團隊有一個深刻的交流，發現是模擬的測試數據的特徵和實際特徵有出入。他們建議咱們用較爲真實的數據在測試一下，獲得的結果表現要好一些，膨脹率大概是3倍。並且3倍仍是由於後面會講的高基維的引入引起了這點。

從膨脹率上來說，有幾點能夠跟你們分享，一個是在測試環境作測試的時候，當時是由於模擬的一些數據的分佈狀況跟實際不是徹底一致，引起了大量的膨脹率。另一個 Kylin 的模型上確實是有必定的講究，經過一些模型優化，咱們確實有效地把 Kylin 的膨脹率控制在3倍之內。

從總體上來說，經過對 Kylin 這個產品的引入，對咱們帶來的好處是很是多的。

1. 如今整個的報表，之前8小時 Cube 如今2小時就能夠出來，給咱們的小夥伴的指標是天天早上9點鐘以前，要把昨天全部的數據作完，用戶可以訪問到，這個指標如今基本上徹底可以達到。
   
2. 從訪問來說，基本上96%在10秒以內，徹底出乎用戶的意料，用戶進來談笑之間數據就能夠出來。
   
3. 一些高基維的引入，進一步下降了咱們開發壓力、維護壓力。

企業如何落地 Kylin

做爲一個傳統企業，引入 Apache Kylin 這樣的開源軟件，該怎麼樣引入？ 這個是從我我的的角度給你們作一個分享，不必定徹底對， 你們能夠一塊兒思考和討論。對於金融機構來講，去引入開源軟件，追求的其實就是核心的四個字：自主可控。其次有三個方面的因素須要考慮。

• 用戶體驗
  

引入 Kylin 很是大的一點緣由，咱們能夠把整個 Cognos 分析報表架在 Apache Kylin 上， 用戶仍舊可在 Cognos 上進行拖拉拽，後臺使用 Kylin 進行查詢，用戶習慣獲得了100%原汁原味的保留 。咱們服務的是用戶，因此用戶的體驗、感覺是很是關鍵的。

• 社區支持
  

原來用 IBM Cognos 的售後服務很是好，問題提出後，他們響應會很是快，郵件的方式或者是回訪，他們會收集一堆的生產上的狀況，一堆的報表。可是，問題仍是沒發徹底解決。傳統的商業產品，每每會面臨這樣的狀況：態度很是好，但碰到一些具體問題快速解決的效率不高，另外一方面用戶間相互交流的途徑較少，相互啓發式的最優實踐經驗分享不夠。

一個很是 Open 的開源軟件，其實對於咱們這樣傳統的金融機構來講，可謂是一個美好的毒藥。雖然都是開源的，社區也很是活躍，可是若是沒有足夠的開發人員、技術人員在裏面的話，玩不轉的。像如今大數據的社區很是活躍，多少企業在這個社區裏有很好的主導權呢？從這個角度來說，Kylin 這個社區對咱們的幫助很大。這個社區很開放，同時 Kyligence 公司在這個社區裏也起着一個很重要的主導權。咱們提出的問題，社區裏的朋友會跟咱們作交流，Kyligence 公司也會以一個主要的代碼貢獻者的身份，提出很好的建議和意見 。

• 組件化
  

Kylin愈來愈龐大，它能夠是一個完整的產品，能夠把它拿回來做爲一個BI去用。咱們在選 Kylin 的時候，更多的是看重它的組件化的特質。若是熟悉 Kylin 的應該知道，它既是一個產品也是一個計算組件，也有能夠是一個存儲組件。

咱們沒有把Kylin當成一個完整的產品，而是把它當作一個組件。過去咱們講「Intel inside」，在構建咱們本身的BI產品的時候，我有時候也說，」Kylin inside」，咱們看一下，什麼叫作」Kylin inside」。

企業內部的大數據圍繞着給用戶服務，作BI，和數據提取的體系架構。這一圈基本上是自營的一些組件、安全、任務執行、資源控制，任務監控、訪問控制；底層是很是熟悉的一系列的大數據套件包括 MapReduce、Spark、Impala、HBase，包括 EDW，因此整個外圍的一圈給包在一塊兒，做爲一個統一的解決方案提供給用戶，用戶能夠經過各類方式去訪問數據、使用數據作本身的分析。

因此說 Kylin inside，包括咱們自營的 Tornado 數據加工服務，中間的 Kylin 做爲一個比較核心的組件，是數據分析的支撐；同時還包括 Lightning 實時數據服務產品。

從這個角度來說，咱們並非說簡單的把Kylin當一個產品引入而是做爲一個組件的形式賦能到咱們產品上。

企業基於Kylin定製化BI開發

前面介紹一下爲何從 Cognos 移到 Kylin 上來，在這個過程當中，咱們重點考量的是哪些點。接下來，我會向你們介紹，針對 Kylin 的外圍，咱們作了哪些事情。

咱們基於 Kylin 商業版本 Kyligence Enterprise 作了一些二次開發，咱們選擇企業版更看重的是商業服務。圍繞着Kylin，咱們作了兩方面的事情。最開始作數據時，基本上是以 Cognos 的方式在跑報表、數據。用戶反饋，Cognos 太難了， 表結構不合理 。所以咱們推出了多維分析，經過拖拉拽方式就能作。拖拉拽幾年，用戶就又開始抱怨了，每天拖拉拽，開發效率過低。咱們有熟悉 Cognos 的人員，有作數據分析的人員，咱們遇到的新問題是， 能不能開放一些 Cognos 的接口給分析人員去使用？基於這樣的狀況，咱們兩個都作。

在多維分析之上，咱們開發了一些工具，第一個簡單的拖拉拽， 這個是仿照 Cognos 作的。後面有單個模型去建立多個分析。若是對這邊有了解的話，用它作報表的話，Report打開來，須要同時打開多個Report，裏面去搭載多個模型，按照如今的性能，一個模型下載下來，至少要半分鐘，有的甚至是1分鐘，因此說這個時候，不管對機器的影響，仍是電腦自己，至關於電腦開多個瀏覽窗口，對電腦的壓力都仍是有的。因此說作了一個事情，單個模型，建立多個分析，包括用戶自定義維度、參數和SQL之間的轉換，在這邊都作了一些開發 。

用戶每每會說：我會寫SQL，可是不懂大家的模型。對這種狀況，咱們作了一個相似於SDK的工具，提示元數據，把表名、字段名彈出來，用戶寫SQL，而後驗證SQL等；怎樣的SQL才能跑，是有本身的一些邏輯在裏面的，包括自定義一些UDF，有些時候直接把UDF傳下去，可能傳到 Kylin 裏面，也有可能傳到 Spark SQL 裏面。有種狀況也是，經過原生接口或者是SQL接口，或者是其餘接口，把數據取過來在內存裏，作二次處理加工，最終再給用戶展示。像咱們這個SQL，不只基於Kylin，也會基於 Spark SQL或者是 Impala 去執行。

怎麼能讓咱們的多維分析相對比較平緩？或者說怎麼讓那些比較熟悉，或者是更加接受報表的用戶，可以接受拖拉拽的這種形式？

咱們會在上面加自定義集，去自定義不少業務的場景，好比，對於咱們來說，從業務上來講，定義公司不一樣的業務線， 從數據層面來說，是有多個維度，甚至是維度裏面不一樣位置的組合，去來表明這些業務場景和業務含義。那麼這個時候若是從報表上來看，就是反應了公司不一樣業務條線的各種數據報表。

今天和你們分享了咱們爲何開始使用Kylin，Kylin帶給咱們的價值，以及圍繞着Kylin咱們作了哪些開發集成工做，但願對你們有所幫助；社區裏有面臨相同問題、挑戰的夥伴也能夠跟咱們進一步交流 。

Q&A

Q： 在使用Kylin，無論是企業版仍是商業版的過程當中，有朋友碰到報表常常變換的狀況，好比說已經構建好的Cube，結果卻發現指標須要變化，或者是維度須要增長，這個時候大家是怎麼處理的？

A： 若是說真要變化，整個模型要重構，這個是沒辦法的。第一，基於多年Cognos的積累，咱們整個模型相對成熟 。第二，Kylin自己的能力值得承認，咱們儘量的會把更多的一些數據、維度放在模型裏，例如把全部商戶代碼全構建進去，幾百萬、上千萬的商戶數據放在一塊兒，怎麼查、改，都逃脫不了這個範圍，因此後面作了自定義數據集等 。因此有了kylin之後， 咱們對這些業務需求就更加有信心， 可以幫助業務人員解決，儘量的把咱們能想象到的場景放進去，只要Kylin能承擔得了性能上的壓力，咱們都儘可能作在裏面去，經過二次自定義的方式，去知足用戶自定義的場景。

Q：總共有多少數據量交給Kylin處理了？

A： 如今咱們一天全部的交易有好幾億，咱們還有季度的、年度的，全部的東西都會用Kylin去作。咱們用Kylin去支撐幾年的明細交易查詢，總的數據量有幾千億了。 怎麼樣用Kylin支撐幾千億級的數據查詢，咱們如今是用Hive跑，幾百萬個出來跑40多個小時，整個集羣所有被吃滿，因此如今這也是咱們面臨的挑戰，咱們也在和Kyligence公司討論，千億級的數據怎麼樣經過Kylin的方式去作，咱們計劃在半個小時看看能不能跑出來，他們跟咱們說很輕鬆，目前還在測試之中。

Q：前面展現的報表工具是自研的嗎？

A：咱們有一個5人團隊，基於Kylin而後設計出來這麼一個報表工具。

Q：Kylin作的工做主要是對Hive查詢的優化工做？

A：Kylin是先把Hive元數據庫拉入構建成底層的存儲引擎，還有本身存儲的格式。跟Cognos的機制比較像，元數據自己是放在數據庫裏面，或者是放在Hive裏面，去訪問數據庫，而後把數據生成物理上的Cube文件，對Cognos來說，是一些二級文件，對於Kylin來說，兩種都支持，開源社區版的話是基於HBase，把數據塞在HBase裏面。可是整個數據結構，跟你本身原始的數據結構是不同的，是Kylin數據接口。可是那個膨脹率你看一下，確實有點高，看你的數據量是否能接受這個膨脹率。

Q：膨脹率具體指的是什麼？

A：好比說你如今有100個G的數據，這個是元數據，一條一條原始數據。可是多維分析是不少個維度的交叉和組合。那麼每個維度都有可能做爲你的訪問，這個時候，理論上從數據模型上來說，爲了提升性能，要把每一種組合都計算出來，並且存下來。這個時候面臨的組合的量，就不是幾百億或者是怎麼樣，那麼它的存儲相對來說確定比原始要大，可是大多少？開源社區用HBase去作的，商業版的話，有本身的存儲引擎，並且還有一個加強的減支的功能，去判斷哪些交叉維度是有效，哪些沒有效，因此說在這上面作了一個處理。其實說白了，我以爲能量守恆，目的仍是空間和時間，只是空間、時間能節約多少的問題。

Q：若是使用 Tableau 軟件，Kylin是做爲 Tableau 的一種數據源嗎？

A：對，可讓 Tableau 把 SQL 發給 Kylin，Kylin作數據計算，結果給到 Tableau。

點擊查看完整視頻

點擊獲取講師PPT

聯繫咱們：

郵箱：info@kyligence.io