資料產品是個新興的產品分類，每個人眼裡都有一個自己的資料產品，儘管在絕大部分人的概念中都是一堆報表。在過去的3年裡，我們在使用者需求的推動下一步步構建了網易嚴選資料產品體系，在構建過程中也有一些自己的思考。
網易嚴選資料產品實踐主要分為以下4個階段：“業務有數可看”、“資料質量保障”、“CXO有處看數”、“場景化資料產品”。這4個階段其實並沒有明顯的階段之分，各階段高度重疊，很多時候都同時在推進。接下來，我會從每個階段面臨的需求(問題)，以及我們採用的產品解決方案來詳述我們的實踐之路。
一、業務有數可看
2017年，我剛來嚴選的時候，是嚴選資料產品起步的階段，我們主要面臨事多、人少、工具差的三大問題(應該也是各個資料部門長期面臨的問題)。
“事多”主要是因為業務方多且當時業務資料需求有一波激增。現代商業(特別是線上業務)資料重要性不言而喻，業務需要透過資料來了解業務現狀，發現業務的機會點和風險點。網易嚴選作為品牌電商，業務鏈路特別長，相較於純網際網路業務主要有產品運營部門，品牌電商還有很重的供應鏈、商品、客服等部門，記得當時光二級部門就有30+，每個部門都有資料需求。當時還不斷有電商網際網路大廠的管理層加入嚴選，基於他們在原來公司比較先進的資料監控體系，提了大量資料需求，帶來一波業務資料需求的激增。“人少”是部門初建的常規問題，當時我們資料開發10個不到(還有2個實習生資料產品經理)，跟我們合作的資料分析師應該也就10個左右。當時使用的報表工具有BIEE、excel、自己開發的資料產品(報表集合)，資料開發主要寫MR加工資料，網易猛獁+網易有數儘管也已經引入，但是沒有用正確的姿勢大規模的使用起來。
面對“業務有數可看”的需求，我們透過構建資料倉庫+嚴選有數(敏捷BI平臺)的方案來解決。資料開發工程師在網易猛獁大資料開發平臺使用SQL高效地進行資料開發構建資料倉庫，資料分析師基於資料倉庫在網易猛獁上使用SQL高效地進行分析集市的開發，再使用網易有數透過拖拽和配置的方式快速進行報表開發。經過資料分析師和資料開發工程師的辛勤工作，嚴選有數目前有8w的圖表(加上其他資料產品一共10w+)，工作日PV 6K+，周UV900+，對於一個事業部級別的BI平臺，報表量和訪問量應該算是非常不錯了。那我們是如何做到這樣的規模呢？首先應該感謝資料分析師和資料開發工程師的辛勤開發，開發了大量的報表和資料模型。因為本文主題是資料產品，接下來我主要從資料產品(嚴選有數)的角度展開講下我們方案的優勢。
嚴選有數是網易有數在嚴選的一個私有部署版本，在網易有數的版本上結合數倉做了效能最佳化，在開放協同上也做了一些功能擴充套件。
嚴選有數繼承了網易有數簡單易用的特性，只需要簡單拖拽即可進行視覺化分析，支援分析師快速製作資料報表。PPT式的操作，讓分析師能夠快速進行報表佈局、圖層管理、圖表樣式最佳化，製作出業務人員友好的報表。
由於嚴選有數承載的報表數量大、大資料查詢引擎的併發效能差、業務人員集中在開始上班時間(9點多)併發檢視報表，效能問題一直是影響業務人員高效閱覽報表的主要問題。在效能方面，我們最佳化查詢引擎(Imapla)的同時，透過資料產出驅動的快取極大的提升了效能，支援業務人員快速閱覽報表。最早，嚴選有數採用常規的被動快取，圖表首次訪問落庫查詢(並快取)，後續訪問查詢快取。業務人員上班後(9點多)集中訪問報表，大量圖表首次訪問進行落庫查詢，查詢引擎瞬間就崩了。那時候幾乎每天早上都被嚴選有數群裡使用者對BI平臺崩了的抱怨，搞得焦頭爛額，儘管暫時透過限流排隊，解決崩的問題，但還是大量使用者排隊訪問不了報表。我們的第一次改進，是把被動快取改成定時主動快取，因為報表資料絕大部分是T+1的，當日資料產出後不會變化，所以在每天7點數倉(及分析集市)產出後，集中進行主動快取。改進後70%以上的圖表訪問都能命中快取，秒級影響，極大地提升了使用者的閱覽體驗。隨著圖表數量的快速增加，7點-9點多之間快取的佔比越來越低，平臺的平均效能越來越差，使用者圖表平均訪問時間也不斷增長，每天早上嚴選有數群裡各種使用者抱怨又開始出現。我們再次改進了我們的快取方案，把定時主動快取改成了資料產出驅動的快取。透過監聽數倉表(及分析集市表)產出的訊息，每次有表產出時遍歷依賴該表的所有圖表，如果相應的圖表依賴的表都已經產出就開始進行快取。這樣我們就不用等到7點開始進行主動快取，而是從0點開始只要圖表依賴的表已經產出就開始進行主動快取，這樣從0到9點多，我們就能預先快取大量圖表。我們的圖表快取命中率達到80%以上(最近缺乏人力持續最佳化下跌到70%左右)，命中快取的圖表都秒級響應。
在網易有數的基礎上，我們還增加了一些開放協同的功能點。我們根據業務人員所屬業務域，開放了儘量多的資料許可權(能看到更多資料，才能產生更多分析的想法)。我們開發了維度/指標級搜尋功能，讓業務人員透過搜尋維度/指標名稱，快速從眾多的報表中找到他想要的報表。我們在報表右上角提供了聯絡作者的快速入口，當業務人員閱覽報表時，如有疑問可以快速喚起popo聯絡報表作者。透過一系列開放協同的產品功能，讓業務人員可以看到更多的資料，可以更快速的找到想要的資料報表，可以便捷的聯絡報表作者(分析師)，形成業務人員看更多資料->產生更多資料需求->聯絡分析師提進一步分析需求->分析師開發更多分析報表的分析閉環。
二、資料質量保障
由於資料來源多、資料鏈路長、資料指標口徑複雜等原因，資料質量問題多、保障難度大。從使用者的角度看資料質量主要存在晚、錯、不一致的問題。
“晚”是指報表產出晚，實時資料延遲。由於報表數量大，對應的資料處理任務(數倉、資料集市)也很多，任務的出錯和執行超時都可能導致資料產出晚。18年時，嚴選有數使用者群裡，使用者反映報表晚產出是常態。實時資料延遲主要會在大促時候出現，實時UV、線上人數常常會延時。“錯”主要指資料指標錯誤和使用者標籤錯誤。資料來源裡一條記錄的丟失、一個欄位的錯誤，資料處理任務鏈路上一個處理邏輯的錯誤、任務的延遲都可能導致資料指標、使用者標籤的錯誤。“不一致”主要指同一指標在不同的報表不一致，指標口徑業務理解不一致。因為同一個指標會出現在不同的有數報表以及不同的資料產品中，經常會出現業務在不同的報表裡看到指標不一致的情況。同一個指標名稱在不同的上下文可能有多種口徑，光毛利相關的口徑就有5+個，業務人員對同一個指標的口徑理解可能會不一致。
資料質量保障是一個複雜而系統化的工程，展開講可以寫一本書，本文的主題是資料產品，下面主要從資料產品的角度講下我們的資料質量保障的解決方案。針對資料質量保障需求，我們設計開發了一系列中臺資料產品來保障資料的完整性、準確性和穩定性。
在剛開始構建數倉的時候，我們就形成了預設的規則，所有的業務資料庫、業務日誌都接入數倉，保障了線上化資料的完整性。儘管我們嚴選產技團隊，幾年來加班加點地不斷研發系統，但是嚴選依然有很多業務沒有線上化，進而資料不能透過業務系統、日誌進入數倉。一方面是因為作為品牌電商，業務鏈路長，對應的業務線上化的需求也多，另一方面業務不斷更精細化運營、不斷探索新的業務方向(這樣才網際網路)，進而不斷產生新的業務線上化需求。針對尚未線上化的業務過程，我們開發了資料填報系統，業務透過excel就可以快速把資料匯入數倉。
資料產品經理結合業務需求透過指標管理系統先定義指標(口徑、描述等)，資料開發同學透過數倉設計系統根據指標定義進行數倉模型的設計，網易猛獁大資料開發平臺根據數倉設計系統的模型設計來新建表。透過需求->設計->開發的線上化協同，來保證指標開發的一致性。指標地圖，提供所有核心指標的定義，業務人員可以在指標地圖檢視指標定義，來解決指標口徑理解問題。從資料來源的角度看，業務DB的資料一方面有資料庫scheme的校驗，另一方面應用層也會進行校驗(業務DB的資料是透過應用層程式碼寫入的)，出問題的機率很低。資料填報系統excel匯入的資料，因為在excel裡直接操作資料且操作非常靈活(約束少)，很容易出現匯入的資料有問題。我們首先控制資料填報系統的建表許可權(只有資料開發可以建表)，同時在系統裡提供了大量的校驗規則。業務人員需要匯入資料到數倉時，先聯絡對應的資料開發提資料匯入需求，資料開發根據需求設計表的結構，並配置對應的表級/欄位級的校驗規則。業務人員匯入excel的時候，相應的校驗規則就能提前發現不符合規則的資料，並要求業務人員修改後重新匯入。埋點由於端多、涉及的開發人員多、沒有強scheme約束，也是資料來源問題重災區。埋點管理系統提供了埋點的定義，埋點流程管理和埋點測試。埋點開發人員使用埋點管理系統的單元測試能力，在埋點開發完成後就能進行單元測試，檢查埋點資料是否符合埋點定義。測試人員可以使用埋點管理系統的迴歸測試能力，對核心埋點進行迴歸測試。透過埋點測試，可以保障埋點資料來源的準確性。
由於資料任務量大(1W+任務節點)、大資料平臺本身穩定性相對較差，任務穩定性保障一直是個難題。我們跟杭研共建任務運維中心，提供任務治理、智慧監控報警、任務影響分析等功能保障資料穩定產出。透過任務運維中心，發現高耗時、耗資源風險任務，及時進行任務最佳化。智慧監控報警，在任務出錯、預測基線有破線風險時及時報警給資料開發值班人員，資料開發值班人員自己或組織對應的開發人員，及時進行問題的處理，保障任務的穩定(準時)產出。
三、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也不另外，是我們最成功的資料產品。
四、場景化資料產品
在日常接到的使用者資料需求中，我們發現的一些資料需求場景，相對於作為整個嚴選業務資料監控體系的一部分，作為一個垂直場景的資料解決方案會是一種更好的表達，比如大促、市場投放、使用者體驗等資料需求場景。大促是電商最重要的節日，要渲染大促氛圍，要實時追蹤大促的爆發效果，以進行運營動作的及時調整。市場投放要及時追蹤市場拉新KPI，及時評估渠道ROI來決策放量/停投，要測試/挑選拉新的新品等。網際網路產品都是以使用者為中心，網易更是極度重視使用者體驗，如何量化評估使用者體驗，如何從使用者視角改進業務。
針對電商大促場景化資料需求，我們設計開發了電商資料大屏和客服資料大屏。在17年雙11之前，我們開發了第一版嚴選電商雙11資料大屏。跟業界雙11資料大屏類似，資料大屏透過主動的實時資料呈現，讓業務實時追蹤大促爆發。透過炫酷的視覺樣式和動畫來渲染大促氛圍。在電商雙11大屏上線後，我們客服部門負責人找到我們，希望幫他們在下一次大促前做個客服資料大屏。由於沒找到mock資料的客服資料大屏(下圖的大促資料大屏資料是mock的)，且客服資料大屏上資料太多打碼難度太大，大家根據大促資料大屏自行腦補下UI吧。客服資料大屏包含實時的會話、排隊、坐席資料，還有滿意度、CPD、滿意度報警、超30分鐘會話等排行榜。我們發現電商資料大屏只在雙11、週年慶等極少數電商大促節日的正點時段使用，但是客服資料大屏在我們兩地的客服部門長期放了好幾塊。這種現象讓我想到在房產中介看到的月度榜單牆，客服大屏是一種更實時的視覺化的勞動競賽榜。
針對使用者體驗場景化需求，我們設計開發了諦聽-輿情洞察中心。使用者體驗的難點在於難以定量的衡量和分析。除了復購、退貨量這些間接的量化指標外，我們能收集到的使用者直接的聲音是使用者評論、客服諮詢等非結構化、定性的資料。使用者在嚴選的消費鏈路(訪問->瀏覽->諮詢->...)的每個節點，在嚴選內部都有對應的業務部門/業務環節為使用者提供服務。我們根據業務環節建立輿情的分類體系，透過演算法+規則將輿情分到對應分類中。將歸屬到具體分類的輿情數量求和，就完成了輿情從定性到定量的過程，輿情類別就是輿情分析的維度。因為我們建立了使用者輿情->輿情分類->業務環節(部門)的對映關係，就可以透過分析對應業務部門所屬分類的資料來評估對應部門的使用者體驗，進而可以將對應的負面輿情分發到對應的部門進行改進。質量相關的輿情我們早已完成線上評估->分類->分發->改進的線上化閉環，當前我們也正在推進其他分類的線上化閉環。
針對市場拉新的場景化需求，我們設計開發了刑天-推廣渠道管理系統。整體的思路和邏輯類似，這裡就不展開敘述了。
總結&後記
3年多的不斷建設，經過以上4個階段，我們基本完成了嚴選資料產品體系，並伴隨業務的精細化與創新進行相應的開發與迭代。從使用者(嚴選業務人員)角度看，自上而下是場景化資料產品、敏捷BI平臺和資料管理資料產品(又可以叫中臺資料產品)，分別應對業務場景化資料需求(CXO看數也可以理解為一種場景化資料需求)、大規模的看數需求和高效高質量的資料管理需求。