大家好，我是卷皮BI團隊負責人柴楹，今天在這里給大家分享一下卷皮的BI和大數(shù)據(jù)的一些東西。

BI&大數(shù)據(jù)是什么？

首先我們來聊一下BI和大數(shù)據(jù)。BI和大數(shù)據(jù)到底有什么關(guān)系和不同。

BI主要有三方面的技術(shù)，包括 DW，OLAP，DM 。目標就是提高企業(yè)經(jīng)營和決策的質(zhì)量和效率。

數(shù)據(jù)倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合，用于支持管理和決策。 OLAP: On-Line Analytical Processing 使分析人員、管理人員能夠從多種角度對從原始數(shù)據(jù)中轉(zhuǎn)化出來的、能夠真正為用戶所理解的、并真實反映數(shù)據(jù)維特性的信息，進行快速、一致、交互地訪問，從而獲得對數(shù)據(jù)的更深入了解的一類軟件技術(shù)。 (OLAP委員會的定義)。 Data Mining 是通過數(shù)學模型發(fā)現(xiàn)隱藏的、潛在的規(guī)律，以輔助決策。 

傳統(tǒng)BI和數(shù)據(jù)倉庫大約是98-99年從國外進入中國，經(jīng)過十幾年的發(fā)展，更多的是做企業(yè)級的數(shù)據(jù)中心，主要應用在電信業(yè)和銀行業(yè)，需求更多的是做報表和進行一些分析等等。傳統(tǒng)的BI主要想實現(xiàn)從宏觀到微觀、從廣度到深度、從定量到定性各種層次的決策分析。

大數(shù)據(jù)是什么？通俗的講，就是體量特別大的數(shù)據(jù)集，這個數(shù)據(jù)集大到無法用傳統(tǒng)的數(shù)據(jù)庫工具或者分析工具進行處理。大數(shù)據(jù)主要有三個特點：

第一，數(shù)據(jù)體量巨大。從TB級別，躍升到PB級別。

第二，數(shù)據(jù)類型繁多，例如網(wǎng)絡日志、視頻、圖片、地理位置信息等等各種結(jié)構(gòu)化非結(jié)構(gòu)化的數(shù)據(jù)。

第三，處理速度快。1秒定律。最后這一點也是和傳統(tǒng)的數(shù)據(jù)挖掘技術(shù)有著本質(zhì)的不同。

一般的大數(shù)據(jù)平臺都有幾個過程： 數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)處理和數(shù)據(jù)展現(xiàn)，當然處理的數(shù)據(jù)也提供做分析和挖掘 。

大數(shù)據(jù)在08年的時候還沒有很多人提及，但是隨著互聯(lián)網(wǎng)的快速發(fā)展，技術(shù)的變革，大數(shù)據(jù)越來越流行，現(xiàn)在也是逢技術(shù)論壇，必談大數(shù)據(jù)。

大數(shù)據(jù)同傳統(tǒng)BI比較，多了一個專門的數(shù)據(jù)采集階段，主要是因為數(shù)據(jù)種類多，數(shù)量大，從結(jié)構(gòu)化的數(shù)據(jù)到非結(jié)構(gòu)化的數(shù)據(jù)。但是其存儲、處理及可視化的思想等都和傳統(tǒng)BI如出一轍。

總結(jié)一下，大數(shù)據(jù)是從BI中發(fā)展來的，但現(xiàn)在BI也借助著互聯(lián)網(wǎng)和大數(shù)據(jù)的快速發(fā)展，有了第二春，因為無論數(shù)據(jù)方面，還是技術(shù)方面，大數(shù)據(jù)都給BI提供了翔實的基礎(chǔ)。

以上是拋磚引玉的給大家介紹一下BI和大數(shù)據(jù)，具體的我就不展開了，有興趣的同學可以自己去多了解一下。下面我來介紹一下我們卷皮的BI體系。

卷皮的BI

首先介紹一下我們卷皮BI的數(shù)據(jù)體系，分為四層：

第一層是基礎(chǔ)平臺層，包括BI所有的數(shù)據(jù)的接入，加工等等；

第二層是數(shù)據(jù)服務層，主要給業(yè)務部門提供報表和OLAP分析系統(tǒng)、給分析師提供自助取數(shù)平臺等等；

第三層是智慧運營層，主要是把數(shù)據(jù)以數(shù)據(jù)產(chǎn)品的方式滲透到業(yè)務部門的日常工作中，例如精細化的運營，針對不同的區(qū)域或者人群進行不同的運營策略；

第四層是決策支持。當然決策支持可以說是在數(shù)據(jù)服務層和智慧運營層都在做，因為也是以數(shù)據(jù)支撐每一個具體的業(yè)務決策。但是這里講的第四層的決策更多是以重大決策為主。舉個例子：公司選擇區(qū)域擴張策略，或者倉庫選址，還有新業(yè)務模式探索等等方向性的決策。

目前我們BI團隊處于第三層階段，正在推進各項智慧運營數(shù)據(jù)產(chǎn)品的建設。

接下來介紹一下我們卷皮BI的 架構(gòu)體系 。我們主要有五大基礎(chǔ)平臺：

一、數(shù)據(jù)采集同步平臺：負責接入所有的數(shù)據(jù)源，用戶行為的數(shù)據(jù)是通過埋點直接生產(chǎn)到kafka，數(shù)據(jù)庫之間的抽取用的阿里開源的datax，實時庫的同步用也是阿里開源的otter，然后競品數(shù)據(jù)是用爬蟲平臺采集來的。

二、實時計算平臺：我們直接上的Spark Streaming，它直接去消費kafka中的數(shù)據(jù)。雖然Spark Streaming不是真正的流計算，而是高頻率的批處理，沒有storm的實時性好，但是目前秒級的延遲我們還是接受的，因為Scala語言開發(fā)起來更加簡潔，而且Spark后續(xù)可以支撐更多，例如我們的挖掘就直接用的SparkR。其中還涉及一些內(nèi)存計算我們用的是memcached和redis，實時數(shù)據(jù)計算的數(shù)據(jù)一般直接存儲到hbase或者es里面，便于更快的檢索。

三、離線計算平臺：主要用的hadoop平臺，Mysql里面有極少量的存儲過程，當前DW全部都在HDFS上，Mysql更多存儲的是為報表展示的數(shù)據(jù)集市類的表。

四、數(shù)據(jù)服務平臺：主要是對外的平臺，報表系統(tǒng)，即席查詢，OLAP分析系統(tǒng)，數(shù)據(jù)分析和挖掘等，然后BI也會給公司其他業(yè)務研發(fā)團隊提供各種數(shù)據(jù)支撐，統(tǒng)一都是走BI自己搭建的數(shù)據(jù)服務層。

五、運維監(jiān)控平臺：調(diào)度系統(tǒng)用的阿里開源的Zeus，然后針對我們自己的需求進行很多二次開發(fā)；日志收集分析用的ELK；監(jiān)控平臺負責BI這邊所有的硬件軟件還有數(shù)據(jù)質(zhì)量等等監(jiān)控；當然這里還要做BI的元數(shù)據(jù)管理。

這五大技術(shù)平臺是BI的物質(zhì)基礎(chǔ)，基于這些物質(zhì)基礎(chǔ)，才能繼續(xù)產(chǎn)出我們的上層建筑：數(shù)據(jù)產(chǎn)品。

我們BI的產(chǎn)品體系主要有兩條線，也就是兩只腳走路。

先說一下數(shù)據(jù)服務線的數(shù)據(jù)產(chǎn)品，這部分產(chǎn)品主要是支撐公司內(nèi)所有的數(shù)據(jù)需求，滿足不同層次的人看數(shù)據(jù)的需要。因為這個也是BI的基礎(chǔ)，基本的數(shù)據(jù)服務你滿足，后面業(yè)務部門才能配合一起做其他智慧運營的數(shù)據(jù)產(chǎn)品。智慧運營線主要想將數(shù)據(jù)滲透到公司業(yè)務部門人員工作的每一個環(huán)節(jié)中，輔助業(yè)務部門人員能夠更加好的做好運營工作。具體的應用有精準化營銷系統(tǒng)、個性化的推薦系統(tǒng)、鷹眼的反欺詐系統(tǒng)和智能選品系統(tǒng)等。

以上就是我們卷皮BI的數(shù)據(jù)、架構(gòu)和產(chǎn)品的體系。

卷皮的三個數(shù)據(jù)產(chǎn)品

第一是 用戶畫像 。卷皮是電商平臺，我們必須要充分的了解我們的用戶，所以卷皮BI也基于自有的用戶消費數(shù)據(jù)、行為數(shù)據(jù)，進行相應的算法模型去挖掘用戶的特征，給用戶打上各種標簽。當然也接入一些外部的數(shù)據(jù)來驗證我們的標簽。目前的用戶標簽,主要分為四個方面：自然屬性，興趣偏好，消費特征，生命周期。

然后基于用戶畫像，我們團隊的精準化小組，就在做以下三個方面的事情：

1. 精準的營銷：通過精準的push提升用戶到達率；針對不同群體用戶做專題活動；對于瀕危用戶進行挽留等等。
2. 個性化的推薦：業(yè)內(nèi)所說的千人千面，每個人專屬的商品的排序；其他的推薦場景，例如猜你喜歡和熱門推薦。但是對于第一次來的用戶，沒有任何行為信息，更多以熱門推薦為主。目前我們也在做基于用戶實時的瀏覽行為，進行實時的商品推薦。
3. 精準的服務：對于不同會員的等級進行差異化的服務，例如信用好的用戶如果選擇退貨，那么我們可以先退錢后收貨，但是對于信用等級不夠高的用戶，那么我們會收到貨以后再退錢等；優(yōu)化客服的服務，對于接入的客戶，更加了解客戶的信息，便于提高服務質(zhì)量。

第二個，就是我們的 鷹眼系統(tǒng) ，也就是反欺詐系統(tǒng)。目前定位是主要是實時的甄別異常訂單。鷹眼系統(tǒng)主要做兩方面的事情，識別壞人和識別壞事。目前我們的鷹眼系統(tǒng)一共有4個子系統(tǒng)：鷹眼馬甲系統(tǒng)、鷹眼售后系統(tǒng)、鷹眼訂單甄別、鷹眼誠信系統(tǒng)。

鷹眼系統(tǒng)的核心模塊是BRMS(業(yè)務規(guī)則管理系統(tǒng))，基于規(guī)則引擎(Drools)。工作人員可通過Web UI制定規(guī)則，形成規(guī)則庫，每個規(guī)則都有個閾值。實時的數(shù)據(jù)結(jié)合數(shù)據(jù)集市的歷史數(shù)據(jù)，在規(guī)則引擎里面進行判斷，如果超出的規(guī)則的閾值，則進行相應的操作，如告警，轉(zhuǎn)人工審核等。

鷹眼的WebUI是我們自己開發(fā)的界面，便于我們的業(yè)務運營人員，基于一些現(xiàn)有的指標來配置規(guī)則，調(diào)整閾值。JP-drools是在drools 我們在外面封裝了一層，主要是為了做到分布式部署、歷史庫共享和規(guī)則的熱部署。

最后這個產(chǎn)品是 OLAP分析系統(tǒng) ，圖片是一個截圖，左邊這邊有維度和度量，通過拖拽到中間的行或者列進行生成相應的表格，右邊可以把表格的數(shù)據(jù)變成各種圖形。業(yè)內(nèi)這種類型的分析工具其實比較多，例如Microstrategy，Tableau等。但這些都是商業(yè)的，我們更多還是基于開源來做。

我們主要用了如下幾個 開源的項目 ：

Saiku提供了一個多維分析的用戶操作界面，可以通過簡單拖拉拽的方式迅速生成報表，它的主要工作是根據(jù)事先配置好的schema，將用戶的操作轉(zhuǎn)化成MDX語句提供給Mondrian引擎執(zhí)行。

Mondrian是一個OLAP分析的引擎，主要工作是根據(jù)事先配置好的schema，將輸入的多維分析語句 MDX (Multidimensional Expressions )翻譯成目標數(shù)據(jù)庫／數(shù)據(jù)引擎的執(zhí)行語言（比如SQL）。

Presto是一個分布式SQL查詢引擎， 它被設計為用來專門進行高速、實時的數(shù)據(jù)分析。它支持標準的ANSI SQL，包括復雜查詢、聚合（aggregation）、連接（join）和窗口函數(shù)（window functions)。

當前這個架構(gòu)是我們第三個版本的架構(gòu)。

第一個版本我們是直接用的Mondrian+Mysql，但是我們發(fā)現(xiàn)Mondrian的界面太丑了，所以在第二版加入了Saiku。但是隨著業(yè)務數(shù)據(jù)量的增加，Mysql的查詢性能很快就到瓶頸了，所以在第三個版本用Presto替代了Mysql。

在這套架構(gòu)里面Saiku提供了界面的支持，Mondrain提供了schema到MDX的轉(zhuǎn)換，并構(gòu)建SQL語句，向Prestodb查詢數(shù)據(jù)，Prestodb執(zhí)行查詢?nèi)蝿?，返回其結(jié)果，Saiku顯示結(jié)果，輸出報表。整個OLAP系統(tǒng)我們需要關(guān)注Saiku的二次開發(fā)，Mondrain schema.xml生成及其讀取數(shù)據(jù)和維表方面的優(yōu)化。

但是當前這個架構(gòu)目前也逐漸遇到瓶頸，對于像具體到每一個用戶成單路徑的數(shù)據(jù)的分析時候查詢還是需要比較久的時間，所以我們現(xiàn)在依然在調(diào)整，希望把kylin加入進來。

kylin是apache軟件基金會的頂級項目，一個開源的分布式多維分析工具。Kylin通過預計算所有合理的維度組合下各個指標的值并把計算結(jié)果存儲到HBASE中的方式，大大提高分布式多維分析的查詢效率。Kylin接收sql查詢語句作為輸入，以查詢結(jié)果作為輸出。對于可以離線分析的業(yè)務數(shù)據(jù)，可以用kylin的框架，而對于實時分析的業(yè)務數(shù)據(jù)還是可以用來Presto支持。

以上就是我們卷皮BI的一些經(jīng)驗的分享。最后送給大家一句話： 數(shù)據(jù)本身不是最終價值，帶有分析的數(shù)據(jù)，滲透到業(yè)務中，影響到?jīng)Q策才產(chǎn)生價值 。

Q&A

Q1：查詢HBase中的數(shù)據(jù)有沒有用什么SQL引擎呢？有的話用的是什么SQL查詢引擎？

A1：我們沒有用什么SQL引擎，我們主要是靠row-key的設計。

Q2：hadoop平臺的部署是通過？ ambari這些嗎？

A2：我們使用cloudera的版本的。

Q3：老師好，能否大概講解一下怎么根據(jù)用戶畫像做推薦，這里面用到什么技術(shù)點。

A3：主要還是數(shù)據(jù)挖掘的算法，有聚類，協(xié)同過濾，商品相似度之類的算法，不過針對不同的業(yè)務場景使用的算法不一樣。技術(shù)上，我們是用的sparkR。

Q4：我們現(xiàn)在olap目前正在使用apache kylin,saiku和kykin結(jié)合怎么樣，有過調(diào)研沒？

A4：Saiku直接+kylin我們還沒有用過，不過應該是OK的，因為saiku主要是界面展現(xiàn)。

Q5：BI挖掘的用戶畫像和鷹眼系統(tǒng)，有什么離線指標來評價相關(guān)的數(shù)據(jù)質(zhì)量？

A5：類似用戶畫像的性別，主要看兩個方面，覆蓋率和準確率，覆蓋率提升了，也許準確率就會下降，后續(xù)我們可以持續(xù)跟蹤用戶的行為，或者進行一些實際的回訪，來驗證并優(yōu)化我們的數(shù)據(jù)模型。鷹眼更多的是基于規(guī)則引擎做的。

Q6：數(shù)據(jù)meta管理是怎么做的？

A6：業(yè)務上我們對所有的數(shù)據(jù)指標口徑進行統(tǒng)一，所有展示數(shù)據(jù)的地方都是一致的，然后對于變更等等流程都有一定的管理。

來源：InfoQ