數據產品是個新興的產品分類，每一個人眼裏都有一個本身的數據產品，儘管在絕大部分人的概念中都是一堆報表。在過去的3年裏，咱們在用戶需求的推進下一步步構建了網易嚴選數據產品體系，下文分享咱們在構建過程當中本身的一些思考和總結。
前端
背景web
本文內容來自我在2020產品經理大會上《網易嚴選數據產品實踐與方法論》分享的文字總結，因爲篇幅緣由，只包含了實踐部分。數據產品是個新興的產品分類，每一個人眼裏都有一個本身的數據產品，儘管在絕大部分人的概念中都是一堆報表。在過去的3年裏，咱們在用戶需求的推進下一步步構建了網易嚴選數據產品體系，在構建過程當中也有一些本身的思考。算法
網易嚴選數據產品實踐主要分爲如下4個階段：「業務有數可看」、「數據質量保障」、「CXO有處看數」、「場景化數據產品」。這4個階段其實並無明顯的階段之分，各階段高度重疊，不少時候都同時在推動。接下來，我會從每一個階段面臨的需求(問題)，以及咱們採用的產品解決方案來詳述咱們的實踐之路。數據庫
1、業務有數可看緩存
2017年，我剛來嚴選的時候，是嚴選數據產品起步的階段，咱們主要面臨事多、人少、工具差的三大問題(應該也是各個數據部門長期面臨的問題)。安全
「事多」主要是由於業務方多且當時業務數據需求有一波激增。現代商業(特別是在線業務)數據重要性不言而喻，業務須要經過數據來了解業務現狀，發現業務的機會點和風險點。網易嚴選做爲品牌電商，業務鏈路特別長，相較於純互聯網業務主要有產品運營部門，品牌電商還有很重的供應鏈、商品、客服等部門，記得當時光二級部門就有30+，每一個部門都有數據需求。當時還不斷有電商互聯網大廠的管理層加入嚴選，基於他們在原來公司比較先進的數據監控體系，提了大量數據需求，帶來一波業務數據需求的激增。「人少」是部門初建的常規問題，當時咱們數據開發10個不到(還有2個實習生數據產品經理)，跟咱們合做的數據分析師應該也就10個左右。當時使用的報表工具備BIEE、excel、本身開發的數據產品(報表集合)，數據開發主要寫MR加工數據，網易猛獁+網易有數儘管也已經引入，可是沒有用正確的姿式大規模的使用起來。性能優化
面對「業務有數可看」的需求，咱們經過構建數據倉庫+嚴選有數(敏捷BI平臺)的方案來解決。數據開發工程師在網易猛獁大數據開發平臺使用SQL高效地進行數據開發構建數據倉庫，數據分析師基於數據倉庫在網易猛獁上使用SQL高效地進行分析集市的開發，再使用網易有數經過拖拽和配置的方式快速進行報表開發。通過數據分析師和數據開發工程師的辛勤工做，嚴選有數目前有8w的圖表(加上其餘數據產品一共10w+)，工做日PV 6K+，周UV900+，對於一個事業部級別的BI平臺，報表量和訪問量應該算是很是不錯了。那咱們是如何作到這樣的規模呢？首先應該感謝數據分析師和數據開發工程師的辛勤開發，開發了大量的報表和數據模型。由於本文主題是數據產品，接下來我主要從數據產品(嚴選有數)的角度展開講下咱們方案的優點。微信
嚴選有數是網易有數在嚴選的一個私有部署版本，在網易有數的版本上結合數倉作了性能優化，在開放協同上也作了一些功能擴展。併發
嚴選有數繼承了網易有數簡單易用的特性，只須要簡單拖拽便可進行可視化分析，支持分析師快速製做數據報表。PPT式的操做，讓分析師可以快速進行報表佈局、圖層管理、圖表樣式優化，製做出業務人員友好的報表。app
因爲嚴選有數承載的報表數量大、大數據查詢引擎的併發性能差、業務人員集中在開始上班時間(9點多)併發查看報表，性能問題一直是影響業務人員高效閱覽報表的主要問題。在性能方面，咱們優化查詢引擎(Imapla)的同時，經過數據產出驅動的緩存極大的提高了性能，支持業務人員快速閱覽報表。最先，嚴選有數採用常規的被動緩存，圖表首次訪問落庫查詢(並緩存)，後續訪問查詢緩存。業務人員上班後(9點多)集中訪問報表，大量圖表首次訪問進行落庫查詢，查詢引擎瞬間就崩了。那時候幾乎天天早上都被嚴選有數羣裏用戶對BI平臺崩了的抱怨，搞得焦頭爛額，儘管暫時經過限流排隊，解決崩的問題，但仍是大量用戶排隊訪問不了報表。咱們的第一次改進，是把被動緩存改爲定時主動緩存，由於報表數據絕大部分是T+1的，當日數據產出後不會變化，因此在天天7點數倉(及分析集市)產出後，集中進行主動緩存。改進後70%以上的圖表訪問都能命中緩存，秒級影響，極大地提高了用戶的閱覽體驗。隨着圖表數量的快速增長，7點-9點多之間緩存的佔比愈來愈低，平臺的平均性能愈來愈差，用戶圖表平均訪問時間也不斷增加，天天早上嚴選有數羣裏各類用戶抱怨又開始出現。咱們再次改進了咱們的緩存方案，把定時主動緩存改爲了數據產出驅動的緩存。經過監聽數倉表(及分析集市表)產出的消息，每次有表產出時遍歷依賴該表的全部圖表，若是相應的圖表依賴的表都已經產出就開始進行緩存。這樣咱們就不用等到7點開始進行主動緩存，而是從0點開始只要圖表依賴的表已經產出就開始進行主動緩存，這樣從0到9點多，咱們就能預先緩存大量圖表。咱們的圖表緩存命中率達到80%以上(最近缺少人力持續優化下跌到70%左右)，命中緩存的圖表都秒級響應。
在網易有數的基礎上，咱們還增長了一些開放協同的功能點。咱們根據業務人員所屬業務域，開放了儘可能多的數據權限(能看到更多數據，才能產生更多分析的想法)。咱們開發了維度/指標級搜索功能，讓業務人員經過搜索維度/指標名稱，快速從衆多的報表中找到他想要的報表。咱們在報表右上角提供了聯繫做者的快速入口，當業務人員閱覽報表時，若有疑問能夠快速喚起popo聯繫報表做者。經過一系列開放協同的產品功能，讓業務人員能夠看到更多的數據，能夠更快速的找到想要的數據報表，能夠便捷的聯繫報表做者(分析師)，造成業務人員看更多數據->產生更多數據需求->聯繫分析師提進一步分析需求->分析師開發更多分析報表的分析閉環。
2、數據質量保障
因爲數據源多、數據鏈路長、數據指標口徑複雜等緣由，數據質量問題多、保障難度大。從用戶的角度看數據質量主要存在晚、錯、不一致的問題。
「晚」是指報表產出晚，實時數據延遲。因爲報表數量大，對應的數據處理任務(數倉、數據集市)也不少，任務的出錯和運行超時均可能致使數據產出晚。18年時，嚴選有數用戶羣裏，用戶反映報表晚產出是常態。實時數據延遲主要會在大促時候出現，實時UV、在線人數經常會延時。「錯」主要指數據指標錯誤和用戶標籤錯誤。數據源裏一條記錄的丟失、一個字段的錯誤，數據處理任務鏈路上一個處理邏輯的錯誤、任務的延遲均可能致使數據指標、用戶標籤的錯誤。「不一致」主要指同一指標在不一樣的報表不一致，指標口徑業務理解不一致。由於同一個指標會出如今不一樣的有數報表以及不一樣的數據產品中，常常會出現業務在不一樣的報表裏看到指標不一致的狀況。同一個指標名稱在不一樣的上下文可能有多種口徑，光毛利相關的口徑就有5+個，業務人員對同一個指標的口徑理解可能會不一致。
數據質量保障是一個複雜而系統化的工程，展開講能夠寫一本書，本文的主題是數據產品，下面主要從數據產品的角度講下咱們的數據質量保障的解決方案。針對數據質量保障需求，咱們設計開發了一系列中臺數據產品來保障數據的完整性、準確性和穩定性。
在剛開始構建數倉的時候，咱們就造成了默認的規則，全部的業務數據庫、業務日誌都接入數倉，保障了在線化數據的完整性。儘管咱們嚴選產技團隊，幾年來加班加點地不斷研發系統，可是嚴選依然有不少業務沒有線上化，進而數據不能經過業務系統、日誌進入數倉。一方面是由於做爲品牌電商，業務鏈路長，對應的業務線上化的需求也多，另外一方面業務不斷更精細化運營、不斷探索新的業務方向(這樣才互聯網)，進而不斷產生新的業務線上化需求。針對還沒有線上化的業務過程，咱們開發了數據填報系統，業務經過excel就能夠快速把數據導入數倉。
數據產品經理結合業務需求經過指標管理系統先定義指標(口徑、描述等)，數據開發同窗經過數倉設計系統根據指標定義進行數倉模型的設計，網易猛獁大數據開發平臺根據數倉設計系統的模型設計來新建表。經過需求->設計->開發的在線化協同，來保證指標開發的一致性。指標地圖，提供全部核心指標的定義，業務人員能夠在指標地圖查看指標定義，來解決指標口徑理解問題。從數據源的角度看，業務DB的數據一方面有數據庫scheme的校驗，另外一方面應用層也會進行校驗(業務DB的數據是經過應用層代碼寫入的)，出問題的機率很低。數據填報系統excel導入的數據，由於在excel裏直接操做數據且操做很是靈活(約束少)，很容易出現導入的數據有問題。咱們首先控制數據填報系統的建表權限(只有數據開發能夠建表)，同時在系統裏提供了大量的校驗規則。業務人員須要導入數據到數倉時，先聯繫對應的數據開發提數據導入需求，數據開發根據需求設計表的結構，並配置對應的表級/字段級的校驗規則。業務人員導入excel的時候，相應的校驗規則就能提早發現不符合規則的數據，並要求業務人員修改後從新導入。埋點因爲端多、涉及的開發人員多、沒有強scheme約束，也是數據源問題重災區。埋點管理系統提供了埋點的定義，埋點流程管理和埋點測試。埋點開發人員使用埋點管理系統的單元測試能力，在埋點開發完成後就能進行單元測試，檢查埋點數據是否符合埋點定義。測試人員可使用埋點管理系統的迴歸測試能力，對核心埋點進行迴歸測試。經過埋點測試，能夠保障埋點數據源的準確性。
因爲數據任務量大(1W+任務節點)、大數據平臺自己穩定性相對較差，任務穩定性保障一直是個難題。咱們跟杭研共建任務運維中心，提供任務治理、智能監控報警、任務影響分析等功能保障數據穩定產出。經過任務運維中心，發現高耗時、耗資源風險任務，及時進行任務優化。智能監控報警，在任務出錯、預測基線有破線風險時及時報警給數據開發值班人員，數據開發值班人員本身或組織對應的開發人員，及時進行問題的處理，保障任務的穩定(準時)產出。
3、CXO無處看數
看到「CXO無處看數」，你們可能以爲很奇怪。上文不是說了，在有數上已經制做了大量報表，怎麼CXO會無處看數。由於CXO有不同的場景，進而產生不同的需求。儘管BI平臺（嚴選有數）上有大量報表，CXO依然面臨「難找」、「不能隨時看」的問題。CXO有整個BI平臺的權限，進入平臺後面對海量的報表，難以快速找到想看的數據(CXO的時間又不多)。CXO工做特性須要隨時隨地查看數據。CXO事情特別多，電商CXO尤甚，品牌電商CXO更甚，CXO不是在開會/出差，就是在開會/出差的路上(連我本身如今也差很少)。
針對CXO的看數場景和需求(痛點)，咱們設計開發了VIPApp-移動數據工做臺。VIPApp爲CXO提供了隨時隨地監控KPI以及所見既所得商品、類目、流量數據。下圖中是VIPApp很早期版本的一些UI，由於數據安全的緣由數據部分打了碼。早期VIPApp主要爲CXO及少數中高層服務，如今已經逐漸發展成面向嚴選全員的移動數據工做臺了，承載了整個嚴選KPI體系監控及各業務運營的數據監控體系。VIPApp從技術角度看是以嚴選app爲容器，內嵌了一個wap(數據產品)網站；從用戶角度看依託嚴選app提供了所見既所得的交互入口。用戶能夠長按類目喚起類目數據頁，長按商品喚起商品數據頁，長按流量位置喚起流量數據頁。移動化讓用戶隨時隨地能夠查看數據，所見既所得的入口讓用戶能夠快速找到對應的數據模塊。好的用戶體驗必定會帶來高頻訪問的回報(每一個產品人都應該信仰)，VIPApp也不另外，是咱們最成功的數據產品。
4、場景化數據產品
在平常接到的用戶數據需求中，咱們發現的一些數據需求場景，相對於做爲整個嚴選業務數據監控體系的一部分，做爲一個垂直場景的數據解決方案會是一種更好的表達，好比大促、市場投放、用戶體驗等數據需求場景。大促是電商最重要的節日，要渲染大促氛圍，要實時追蹤大促的爆發效果，以進行運營動做的及時調整。市場投放要及時追蹤市場拉新KPI，及時評估渠道ROI來決策放量/停投，要測試/挑選拉新的新品等。互聯網產品都是以用戶爲中心，網易更是極度重視用戶體驗，如何量化評估用戶體驗，如何從用戶視角改進業務。
針對電商大促場景化數據需求，咱們設計開發了電商數據大屏和客服數據大屏。在17年雙11以前，咱們開發了初版嚴選電商雙11數據大屏。跟業界雙11數據大屏相似，數據大屏經過主動的實時數據呈現，讓業務實時追蹤大促爆發。經過炫酷的視覺樣式和動畫來渲染大促氛圍。在電商雙11大屏上線後，咱們客服部門負責人找到咱們，但願幫他們在下一次大促前作個客服數據大屏。因爲沒找到mock數據的客服數據大屏(下圖的大促數據大屏數據是mock的)，且客服數據大屏上數據太多打碼難度太大，你們根據大促數據大屏自行腦補下UI吧。客服數據大屏包含實時的會話、排隊、坐席數據，還有滿意度、CPD、滿意度報警、超30分鐘會話等排行榜。咱們發現電商數據大屏只在雙十一、週年慶等極少數電商大促節日的正點時段使用，可是客服數據大屏在咱們兩地的客服部門長期放了好幾塊。這種現象讓我想到在房產中介看到的月度榜單牆，客服大屏是一種更實時的可視化的勞動競賽榜。
針對用戶體驗場景化需求，咱們設計開發了諦聽-輿情洞察中心。用戶體驗的難點在於難以定量的衡量和分析。除了復購、退貨量這些間接的量化指標外，咱們能收集到的用戶直接的聲音是用戶評論、客服諮詢等非結構化、定性的數據。用戶在嚴選的消費鏈路(訪問->瀏覽->諮詢->...)的每一個節點，在嚴選內部都有對應的業務部門/業務環節爲用戶提供服務。咱們根據業務環節創建輿情的分類體系，經過算法+規則將輿情分到對應分類中。將歸屬到具體分類的輿情數量求和，就完成了輿情從定性到定量的過程，輿情類別就是輿情分析的維度。由於咱們創建了用戶輿情->輿情分類->業務環節(部門)的映射關係，就能夠經過分析對應業務部門所屬分類的數據來評估對應部門的用戶體驗，進而能夠將對應的負面輿情分發到對應的部門進行改進。質量相關的輿情咱們早已完成線上評估->分類->分發->改進的線上化閉環，當前咱們也正在推動其餘分類的線上化閉環。
針對市場拉新的場景化需求，咱們設計開發了刑天-推廣渠道管理系統。總體的思路和邏輯相似，這裏就不展開敘述了。
總結&後記
3年多的不斷建設，通過以上4個階段，咱們基本完成了嚴選數據產品體系，並伴隨業務的精細化與創新進行相應的開發與迭代。從用戶(嚴選業務人員)角度看，自上而下是場景化數據產品、敏捷BI平臺和數據管理數據產品(又能夠叫中臺數據產品)，分別應對業務場景化數據需求(CXO看數也能夠理解爲一種場景化數據需求)、大規模的看數需求和高效高質量的數據管理需求。
在寫文章的過程當中，我發現文章信息密度仍是很大，包含了不少數據產品和解決方案，難以在一篇文章中所有展開來說。若是你們對數據產品感興趣，想了解具體的產品或解決方案，請在評論區留言，咱們會根據反饋發表對應的解決方案或數據產品的文章。固然我也會視本文的熱度，決定後續是否是把方法論部分再寫一篇文章發表出來。
做者簡介
魏文慶，現任網易嚴選數據技術及產品部總監。2007年浙江大學計算機碩士畢業後入職網易杭州研究院，從事前端開發，後歷任技術主管、技術經理、技術總監。曾負責網易攝影、網易企業郵箱、易信公衆號等產品開發，以及網易前端微專業課程開發。2015年開始內部創業，孵化敏捷BI平臺-網易有數，任網易有數總經理，負責產品研發和商業化。2017年開始負責網易嚴選數據技術及產品部，從0到1搭建網易嚴選數據中臺和數據產品體系。
本文由做者受權嚴選技術團隊發佈
本文分享自微信公衆號 - 嚴選技術產品團隊（YanxuanTechProd）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。