網上有很多關于銀聯(lián)pos機回訪工作,Apache Kylin 在銀聯(lián)的實踐的知識，也有很多人為大家解答關于銀聯(lián)pos機回訪工作的問題，今天pos機之家(m.afbey.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
銀聯(lián)pos機回訪工作
金融機構在 BI 分析中遇到了哪些挑戰(zhàn)？
首先簡單介紹一下我們公司數(shù)據(jù)倉庫的背景，2008 年公司開始建數(shù)據(jù)倉庫，2009 年上線。這個數(shù)據(jù)倉庫運轉到現(xiàn)在已經有 10 個年頭，采用的是比較傳統(tǒng)標準的架構，數(shù)據(jù)倉庫主體用的是 IBM DB2。
在 BI 這塊我們引入了 Cognos 作為總的 BI 工具，當時，整個金融界都比較流行 Cognos。在這 10 年內，包括 Cognos 等一些其他商業(yè)版的多維分析工具，確實給企業(yè)分析帶來了很大的便利。時過境遷，現(xiàn)在到了大數(shù)據(jù)年代，數(shù)據(jù)量越來越大， Cognos 面臨了一些挑戰(zhàn)， 我們數(shù)據(jù)量的增長， 10 年間漲了 10 倍；在最近兩三年，我們的業(yè)務量又更加迅猛地增長，這對數(shù)據(jù)分析的挑戰(zhàn)是巨大的。
Cognos 從整個功能、架構上來講， 都是基于單機版的，效率很低；因此我們在 Cognos 的基礎上研發(fā)了一些工具，包括調度、Cube 刷新，Cube 訪問等等，這其中申請的專利就有好幾個。這些工具核心還是基于單機的運轉，所以說在構建上它的擴展性不好，一個體現(xiàn)是，刷 Cube 的時間越來越長。
例如一些每日刷新的 Cube，業(yè)務分析用戶需要基于這些日 Cube 要出當日報表， 但是鑒于現(xiàn)在的數(shù)據(jù)量和處理能力，很難在他們預期的時間內達到要求，我們技術團隊的壓力很大，做了很多工作，想了各種各樣的辦法在調優(yōu)，但是收效仍然低于預期。
以上是我們用 Cognos 碰到的一些挑戰(zhàn)，正是因為這個原因，我們在 2015 年在一個技術分享活動上，我們和 Apache Kylin 第一次觸電。
Apache Kylin 的性能和價值
在下圖可以看到，Kylin 各方面的性能和 Cognos 相比有了大幅的提高，這些數(shù)據(jù)都是實際中的一些例子。從使用資源來講，大數(shù)據(jù)平臺的資源還是比較富裕的，Kylin 整個架構比較強調讀寫分離，目前我們在 Kylin 上投了 20 多臺機器進行 Cube 的構建和查詢。
效率提升4倍，Apache Kylin在銀聯(lián)的實踐
首先看一下查詢，96% 的查詢在 10 秒之內返回；除非是非常大、復雜的條件可能要到 20 秒左右。 而以前我們的 Cognos 從打開到展示，拖拉拽建立一個基本的報表要接近一分鐘，Kylin 對用戶的體驗和感受的提升是非常巨大的。
從整個構建性能上來講， Kylin 相比于 Cognos 也有巨大的提升。因為 Cognos 是單機，沒有辦法利用分布式集群資源，必須是一個比較獨立的 Cognos 在跑，每天跑 8 個小時以上。Kylin 的構建是在整個大數(shù)據(jù)平臺之上，跟其他的批量計算共享集群資源，這個時候基本上是兩個小時左右，就可以把整個 Cube 構建出來。
膨脹率是一個關鍵點，在測試環(huán)境上，效果不是很好，有 10 倍以上的膨脹。當時我有點猶豫，問題出在什么地方？后來跟 Kylin 團隊有一個深入的交流，發(fā)現(xiàn)是模擬的測試數(shù)據(jù)的特征和實際特征有出入。他們建議我們用較為真實的數(shù)據(jù)在測試一下，得到的結果表現(xiàn)要好一些，膨脹率大概是 3 倍。而且 3 倍還是因為后面會講的高基維的引入引發(fā)了這點。
從膨脹率上來講，有幾點可以跟大家分享，一個是在測試環(huán)境做測試的時候，當時是因為模擬的一些數(shù)據(jù)的分布情況跟實際不是完全一致，引發(fā)了大量的膨脹率。另外一個 Kylin 的模型上確實是有一定的講究，通過一些模型優(yōu)化，我們確實有效地把 Kylin 的膨脹率控制在 3 倍以內。
從整體上來講，通過對 Kylin 這個產品的引入，對我們帶來的好處是非常多的。
現(xiàn)在整個的報表，以前 8 小時 Cube 現(xiàn)在 2 小時就可以出來，給我們的小伙伴的指標是每天早上 9 點鐘之前，要把昨天所有的數(shù)據(jù)做完，用戶能夠訪問到，這個指標現(xiàn)在基本上完全能夠達到。
從訪問來講，基本上 96% 在 10 秒之內，完全出乎用戶的意料，用戶進來談笑之間數(shù)據(jù)就可以出來。
一些高基維的引入，進一步降低了我們開發(fā)壓力、維護壓力。
企業(yè)如何落地 Kylin
作為一個傳統(tǒng)企業(yè)，引入 Apache Kylin 這樣的開源軟件，該怎么樣引入？ 這個是從我個人的角度給大家做一個分享，不一定完全對， 大家可以一起思考和討論。對于金融機構來說，去引入開源軟件，追求的其實就是核心的四個字：自主可控。其次有三個方面的因素需要考慮。
用戶體驗
引入 Kylin 非常大的一點原因，我們可以把整個 Cognos 分析報表架在 Apache Kylin 上， 用戶仍舊可在 Cognos 上進行拖拉拽，后臺使用 Kylin 進行查詢，用戶習慣得到了 100% 原汁原味的保留 。我們服務的是用戶，所以用戶的體驗、感受是非常關鍵的。
社區(qū)支持
原來用 IBM Cognos 的售后服務非常好，問題提出后，他們響應會非?？?，郵件的方式或者是回訪，他們會收集一堆的生產上的情況，一堆的報表。但是，問題還是沒發(fā)完全解決。傳統(tǒng)的商業(yè)產品，往往會面臨這樣的情況：態(tài)度非常好，但碰到一些具體問題快速解決的效率不高，另一方面用戶間相互交流的途徑較少，相互啟發(fā)式的最優(yōu)實踐經驗分享不夠。
一個非常 Open 的開源軟件，其實對于我們這樣傳統(tǒng)的金融機構來說，可謂是一個美好的毒藥。雖然都是開源的，社區(qū)也非?；钴S，但是如果沒有足夠的開發(fā)人員、技術人員在里面的話，玩不轉的。像現(xiàn)在大數(shù)據(jù)的社區(qū)非?；钴S，多少企業(yè)在這個社區(qū)里有很好的主導權呢？從這個角度來講，Kylin 這個社區(qū)對我們的幫助很大。這個社區(qū)很開放，同時 Kyligence 公司在這個社區(qū)里也起著一個很重要的主導權。我們提出的問題，社區(qū)里的朋友會跟我們做交流，Kyligence 公司也會以一個主要的代碼貢獻者的身份，提出很好的建議和意見。
組件化
Kylin 越來越龐大，它可以是一個完整的產品，可以把它拿回來作為一個 BI 去用。我們在選 Kylin 的時候，更多的是看重它的組件化的特質。如果熟悉 Kylin 的應該知道，它既是一個產品也是一個計算組件，也有可以是一個存儲組件。
我們沒有把 Kylin 當成一個完整的產品，而是把它當做一個組件。過去我們講“Intel inside”，在構建我們自己的 BI 產品的時候，我有時候也說，“Kylin inside”，我們看一下，什么叫做 "Kylin inside"。
企業(yè)內部的大數(shù)據(jù)圍繞著給用戶服務，做 BI，和數(shù)據(jù)提取的體系架構。這一圈基本上是自營的一些組件、安全、任務執(zhí)行、資源控制，任務監(jiān)控、訪問控制；底層是非常熟悉的一系列的大數(shù)據(jù)套件包括 MapReduce、Spark、Impala、HBase，包括 EDW，所以整個外圍的一圈給包在一起，作為一個統(tǒng)一的解決方案提供給用戶，用戶可以通過各種方式去訪問數(shù)據(jù)、使用數(shù)據(jù)做自己的分析。
所以說 Kylin inside，包括我們自營的 Tornado 數(shù)據(jù)加工服務，中間的 Kylin 作為一個比較核心的組件，是數(shù)據(jù)分析的支撐；同時還包括 Lightning 實時數(shù)據(jù)服務產品。
從這個角度來講，我們并不是說簡單的把 Kylin 當一個產品引入而是作為一個組件的形式賦能到我們產品上。
企業(yè)基于 Kylin 定制化 BI 開發(fā)
前面介紹一下為什么從 Cognos 移到 Kylin 上來，在這個過程中，我們重點考量的是哪些點。接下來，我會向大家介紹，針對 Kylin 的外圍，我們做了哪些事情。
我們基于 Kylin 商業(yè)版本 Kyligence Enterprise 做了一些二次開發(fā)，我們選擇企業(yè)版更看重的是商業(yè)服務。圍繞著 Kylin，我們做了兩方面的事情。最開始做數(shù)據(jù)時，基本上是以 Cognos 的方式在跑報表、數(shù)據(jù)。用戶反饋，Cognos 太難了， 表結構不合理 。因此我們推出了多維分析，通過拖拉拽方式就能做。拖拉拽幾年，用戶就又開始抱怨了，天天拖拉拽，開發(fā)效率太低。我們有熟悉 Cognos 的人員，有做數(shù)據(jù)分析的人員，我們遇到的新問題是， 能不能開放一些 Cognos 的接口給分析人員去使用？基于這樣的情況，我們兩個都做。
在多維分析之上，我們開發(fā)了一些工具，第一個簡單的拖拉拽， 這個是仿照 Cognos 做的。后面有單個模型去創(chuàng)建多個分析。如果對這邊有了解的話，用它做報表的話，Report 打開來，需要同時打開多個 Report，里面去搭載多個模型，按照現(xiàn)在的性能，一個模型下載下來，至少要半分鐘，有的甚至是 1 分鐘，所以說這個時候，無論對機器的影響，還是電腦本身，相當于電腦開多個瀏覽窗口，對電腦的壓力都還是有的。所以說做了一個事情，單個模型，創(chuàng)建多個分析，包括用戶自定義維度、參數(shù)和 SQL 之間的轉換，在這邊都做了一些開發(fā) 。
用戶往往會說：我會寫 SQL，但是不懂你們的模型。對這種情況，我們做了一個類似于 SDK 的工具，提示元數(shù)據(jù)，把表名、字段名彈出來，用戶寫 SQL，然后驗證 SQL 等；怎樣的 SQL 才能跑，是有自己的一些邏輯在里面的，包括自定義一些 UDF，有些時候直接把 UDF 傳下去，可能傳到 Kylin 里面，也有可能傳到 Spark SQL 里面。有種情況也是，通過原生接口或者是 SQL 接口，或者是其他接口，把數(shù)據(jù)取過來在內存里，做二次處理加工，最終再給用戶展現(xiàn)。像我們這個 SQL，不僅基于 Kylin，也會基于 Spark SQL 或者是 Impala 去執(zhí)行。
怎么能讓我們的多維分析相對比較平緩？或者說怎么讓那些比較熟悉，或者是更加接受報表的用戶，能夠接受拖拉拽的這種形式？
我們會在上面加自定義集，去自定義很多業(yè)務的場景，比如，對于我們來講，從業(yè)務上來說，定義公司不同的業(yè)務線， 從數(shù)據(jù)層面來講，是有多個維度，甚至是維度里面不同位置的組合，去來代表這些業(yè)務場景和業(yè)務含義。那么這個時候如果從報表上來看，就是反應了公司不同業(yè)務條線的各類數(shù)據(jù)報表。
今天和大家分享了我們?yōu)槭裁撮_始使用 Kylin，Kylin 帶給我們的價值，以及圍繞著 Kylin 我們做了哪些開發(fā)集成工作，希望對大家有所幫助；社區(qū)里有面臨相同問題、挑戰(zhàn)的伙伴也可以跟我們進一步交流 。
Q&A
Q： 在使用 Kylin，不管是企業(yè)版還是商業(yè)版的過程中，有朋友碰到報表經常變換的情況，比如說已經構建好的 Cube，結果卻發(fā)現(xiàn)指標需要變化，或者是維度需要增加，這個時候你們是怎么處理的？
A： 如果說真要變化，整個模型要重構，這個是沒辦法的。第一，基于多年 Cognos 的積累，我們整個模型相對成熟 。第二，Kylin 本身的能力值得認可，我們盡可能的會把更多的一些數(shù)據(jù)、維度放在模型里，例如把所有商戶代碼全構建進去，幾百萬、上千萬的商戶數(shù)據(jù)放在一起，怎么查、改，都逃脫不了這個范圍，所以后面做了自定義數(shù)據(jù)集等 。所以有了 kylin 以后， 我們對這些業(yè)務需求就更加有信心， 能夠幫助業(yè)務人員解決，盡可能的把我們能想象到的場景放進去，只要 Kylin 能承擔得了性能上的壓力，我們都盡量做在里面去，通過二次自定義的方式，去滿足用戶自定義的場景。
Q：總共有多少數(shù)據(jù)量交給 Kylin 處理了？
A： 現(xiàn)在我們一天所有的交易有好幾億，我們還有季度的、年度的，所有的東西都會用 Kylin 去做。我們用 Kylin 去支撐幾年的明細交易查詢，總的數(shù)據(jù)量有幾千億了。 怎么樣用 Kylin 支撐幾千億級的數(shù)據(jù)查詢，我們現(xiàn)在是用 Hive 跑，幾百萬個出來跑 40 多個小時，整個集群全部被吃滿，所以現(xiàn)在這也是我們面臨的挑戰(zhàn)，我們也在和 Kyligence 公司討論，千億級的數(shù)據(jù)怎么樣通過 Kylin 的方式去做，我們計劃在半個小時看看能不能跑出來，他們跟我們說很輕松，目前還在測試之中。
Q：前面展示的報表工具是自研的嗎？
A：我們有一個 5 人團隊，基于 Kylin 然后設計出來這么一個報表工具。
Q：Kylin 做的工作主要是對 Hive 查詢的優(yōu)化工作？
A：Kylin 是先把 Hive 元數(shù)據(jù)庫拉入構建成底層的存儲引擎，還有自己存儲的格式。跟 Cognos 的機制比較像，元數(shù)據(jù)本身是放在數(shù)據(jù)庫里面，或者是放在 Hive 里面，去訪問數(shù)據(jù)庫，然后把數(shù)據(jù)生成物理上的 Cube 文件，對 Cognos 來講，是一些二級文件，對于 Kylin 來講，兩種都支持，開源社區(qū)版的話是基于 HBase，把數(shù)據(jù)塞在 HBase 里面。但是整個數(shù)據(jù)結構，跟你自己原始的數(shù)據(jù)結構是不一樣的，是 Kylin 數(shù)據(jù)接口。但是那個膨脹率你看一下，確實有點高，看你的數(shù)據(jù)量是否能接受這個膨脹率。
Q：膨脹率具體指的是什么？
A：比如說你現(xiàn)在有 100 個 G 的數(shù)據(jù)，這個是元數(shù)據(jù)，一條一條原始數(shù)據(jù)。但是多維分析是很多個維度的交叉和組合。那么每一個維度都有可能作為你的訪問，這個時候，理論上從數(shù)據(jù)模型上來講，為了提高性能，要把每一種組合都計算出來，而且存下來。這個時候面臨的組合的量，就不是幾百億或者是怎么樣，那么它的存儲相對來講肯定比原始要大，但是大多少？開源社區(qū)用 HBase 去做的，商業(yè)版的話，有自己的存儲引擎，而且還有一個增強的剪枝的功能，去判斷哪些交叉維度是有效，哪些沒有效，所以說在這上面做了一個處理。其實說白了，我覺得能量守恒，目的還是空間和時間，只是空間、時間能節(jié)約多少的問題。
Q：如果使用 Tableau 軟件，Kylin 是作為 Tableau 的一種數(shù)據(jù)源嗎？
A：對，可以讓 Tableau 把 SQL 發(fā)給 Kylin，Kylin 做數(shù)據(jù)計算，結果給到 Tableau。
本文作者:王穎卓
以上就是關于銀聯(lián)pos機回訪工作,Apache Kylin 在銀聯(lián)的實踐的知識，后面我們會繼續(xù)為大家整理關于銀聯(lián)pos機回訪工作的知識，希望能夠幫助到大家！
