【51CTO.com原創(chuàng)稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運維技術峰會在北京召開。此次峰會圍繞人工智能、大數(shù)據(jù)、物聯(lián)網(wǎng)、區(qū)塊鏈等12大核心熱點，匯聚海內(nèi)外60位一線專家，是一場高端的技術盛宴，也是***IT技術人才學習和人脈拓展不容錯過的平臺。

　　在19日下午“高并發(fā)與實時處理”分會場，51信用卡大數(shù)據(jù)架構師劉建輝帶來了《大數(shù)據(jù)應用產(chǎn)品進階之道》的主題演講，針對常規(guī)大數(shù)據(jù)架構、大數(shù)據(jù)用戶需求、數(shù)據(jù)產(chǎn)品建設等大眾關心的話題展開了闡述。會后，51CTO記者根據(jù)劉建輝在WOT2018全球軟件與運維技術峰會的演講內(nèi)容進行了整理。

[[233473]]

　　常見的大數(shù)據(jù)架構

　　劉建輝指出，其實每一家公司的大數(shù)據(jù)架構都差不多，基本上分為采集、存儲、調(diào)度、計算、數(shù)據(jù)展示這五個層次。

　　想讓大數(shù)據(jù)為己所用，就必須先了解大數(shù)據(jù)到底是什么。有人認為大數(shù)據(jù)是參與底層的平臺開發(fā)，有人認為就是參與業(yè)務開發(fā)的工具，劉建輝曾經(jīng)認為大數(shù)據(jù)就是寫幾行架構代碼，無非是基于Spark(專為大規(guī)模數(shù)據(jù)處理而設計的快速通用的計算引擎)寫代碼，還是Flink(針對流數(shù)據(jù)和批數(shù)據(jù)的分布式處理引擎)寫代碼，似乎沒有什么本質(zhì)區(qū)別。事實證明這些觀點其實都不全面，想了解大數(shù)據(jù)是什么，可以通過大數(shù)據(jù)“發(fā)現(xiàn)問題”和“解決問題”來定義。

　　在公司內(nèi)部，與大數(shù)據(jù)密切相關的人員有三類人員，一是數(shù)據(jù)分析人員(數(shù)據(jù)倉庫、BI)，二是算法策略人員，三是運營人員、增長團隊、產(chǎn)品開發(fā)人員、設計人員。尤其是在數(shù)字化轉(zhuǎn)型過程中的企業(yè)產(chǎn)品開發(fā)人員，可能在利用大數(shù)據(jù)方面的經(jīng)驗欠缺，多是基于傳統(tǒng)模式來進行產(chǎn)品設計，大數(shù)據(jù)對他們的幫助非常大，完全可以從數(shù)據(jù)的角度幫助產(chǎn)品人員做決策，效果更好。

　　那么人們對大數(shù)據(jù)分析的需求是什么呢?劉建輝歸納為三點，一是即時查詢，技術人員想了解某個結果，只要將其寫入MySQL(關系型數(shù)據(jù)庫管理系統(tǒng))，立刻就能看到結果，得到即刻滿足。二是任務調(diào)度，技術人員希望每天在固定時間節(jié)點能夠產(chǎn)出一個數(shù)據(jù)報表。三是報表產(chǎn)出，快速可靠。

　　了解了大數(shù)據(jù)的實際需求之后，該如何選擇適合自己的大數(shù)據(jù)產(chǎn)品及解決方案呢?劉建輝給出三點建議：首先牢記一點，可執(zhí)行的方案勝過明天的***方案;其次產(chǎn)品要始終滿足用戶業(yè)務場景需求，***一點，確保產(chǎn)品的易用、穩(wěn)定、可靠。

　　原來大數(shù)據(jù)算法有這么多門道!

　　在演講現(xiàn)場，劉建輝還分享了51信用卡在大數(shù)據(jù)實踐中遇到的問題，重點講解了大數(shù)據(jù)的算法策略。

　　他表示，51信用卡公司缺少一個統(tǒng)一的模型訓練和模型發(fā)布平臺。在這方面，大型公司做的比較好，由于他們長期的積累，算法和工程的配合程度已經(jīng)相對完善。而對中小型公司而言，每位技術人員用的算法模型五花八門，評估指標也“百花齊放”。這樣的做法其實有很大的弊端，對于任何一家公司而言，其業(yè)務的評估指標應該是統(tǒng)一的，應當建立一套統(tǒng)一的模型的訓練和模型發(fā)布平臺。

　　線上變量和離線變量不一致也是一個問題。目前大部分的模型訓練都是離線計算。計算完成了之后，再把離線變量轉(zhuǎn)成在線變量，通過在線的方式實時地調(diào)用在線的模型。在這個過程中，有的技術人員會忽略一點，那就是算法也是有有效性的，可能當時一個非常好的算法，一個月后就失效了。原因就在于業(yè)務發(fā)生了變化，核心在于當前端改版后，產(chǎn)品目標人群面貌發(fā)生了變化，之前所有線上變量在一個月前完全沒有問題，但下個月就失效了。這個現(xiàn)象對于金融公司而言會造成很可怕的損失。

　　另外一個問題就是模型上線后的監(jiān)控告警問題。技術團隊希望能夠提前知道模型變量與穩(wěn)定性的全部情況，可以提前評估算法模型對現(xiàn)有業(yè)務的支持情況，而不是等到兩個月以后，發(fā)現(xiàn)已經(jīng)造成損失，才想到原來是模型變量失效了。

　　劉建輝還給出了一個比較合理的算法開發(fā)流程，包括五步驟：從特征挖掘到模型訓練，再到實時變量開發(fā)、模型上線，***進行模型監(jiān)控評估。在整個過程中，51信用卡遇到了各種挑戰(zhàn)，他作為“過來人”分享了他的經(jīng)驗：

　　***點，在線變量和離線變量依賴的數(shù)據(jù)源必須一致。有的算法人員表示自己挖掘到一些新特征，可以把反欺詐的***率提升好幾個百分點，但實際上線效果并不好，原因就在于離線依賴的數(shù)據(jù)源跟在線依賴的數(shù)據(jù)源完全不一樣。

　　第二點，在線變量盡可能也采用SQL的方式，避免邏輯錯誤。劉建輝表示，在數(shù)據(jù)量不是特別大的情況下，適當?shù)某杀鹃_銷比可能引起的問題、帶來的損失更值得，所以他建議大家通過SQL的方式采取在線和離線一樣的解決方式去解決問題。

　　第三點，監(jiān)控支持從Hive數(shù)據(jù)源獲取自定義指標。在業(yè)務運營過程中，運營團隊會做運營推廣，產(chǎn)品會重新改版，最終業(yè)務指標出現(xiàn)問題并不一定是由算法帶來的。但算法團隊要解決的問題就是一定要實時地知道業(yè)務發(fā)生了哪些變化，把監(jiān)控指標做的更完備，盡早地去進行分析。

　　第四點，模型評估函數(shù)、監(jiān)控指標要統(tǒng)一。

　　如何利用大數(shù)據(jù)去引導業(yè)務?

　　演講***，劉建輝還重點談到了大數(shù)據(jù)如何幫助產(chǎn)品做運營。

　　對于大多數(shù)企業(yè)而言，運營流程比較類似，都是由獲客、注冊、轉(zhuǎn)化、收入、傳播這幾個步驟組成。那該如何提升渠道的轉(zhuǎn)化率呢?有兩種解決方案，一種是通過產(chǎn)品的設計，增加核心功能。第二個是做合適的運營活動，例如新手注冊送紅包等。

　　當轉(zhuǎn)化率降低時，人們還可以通過大數(shù)據(jù)進行分析，制定更有效的運營策略。首先繪制出整個產(chǎn)品的用戶地圖，看看新版是否滿足用戶需求;然后利用埋點數(shù)據(jù)總結出產(chǎn)品路徑的漏斗轉(zhuǎn)化率，通過轉(zhuǎn)化率進行分析找到問題的源頭，是產(chǎn)品設計問題導致用戶流失，還是前端有bug導致客戶信息無法保存，抑或是H5頁面出現(xiàn)了問題。當分析結果出來之后，可以更有針對性地進行精準人群運營活動推廣。

　　以上內(nèi)容是51CTO記者根據(jù)51信用卡大數(shù)據(jù)架構師劉建輝在WOT2018全球軟件與運維技術峰會的采訪內(nèi)容整理，更多關于WOT的內(nèi)容請關注51cto.com。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】