2019獨角獸企業重金招聘Python工程師標準>>>

近日，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 這個產品的引入，對我們帶來的好處是非常多的。

現在整個的報表，以前8小時 Cube 現在2小時就可以出來，給我們的小伙伴的指標是每天早上9點鐘之前，要把昨天所有的數據做完，用戶能夠訪問到，這個指標現在基本上完全能夠達到。

從訪問來講，基本上96%在10秒之內，完全出乎用戶的意料，用戶進來談笑之間數據就可以出來。

一些高基維的引入，進一步降低了我們開發壓力、維護壓力。

企業如何落地 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

轉載于:https://my.oschina.net/cicixing/blog/3019193

總結

以上是生活随笔為你收集整理的【案例】数据量猛增，BI分析效率太低怎么破？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。