產(chǎn)品解決方案:數(shù)據(jù)自助分析平臺
數(shù)據(jù)質(zhì)量是自助分析平臺中不可或缺的一個環(huán)節(jié),如何保證數(shù)據(jù)準確性和及時性大多數(shù)時候都是開發(fā)需要考慮的一個重要問題。
大部分公司選擇Tableau作為可視化分析工具,原因都是基于其優(yōu)秀的交互、快速的可視化分析,相比起傳統(tǒng)的BI系統(tǒng),它的短平快更得互聯(lián)網(wǎng)時代的數(shù)據(jù)分析師青睞。但經(jīng)過一段時間的使用及功能探究,我們發(fā)現(xiàn)tableau其實并不局限于“分析師工具”應用,只要完善了其中的權限功能,tableau大有成為企業(yè)級報表應用的潛力。
一、產(chǎn)品架構(gòu)&流程設計
一開始公司購買的tableau軟件的初衷是服務于運營和數(shù)據(jù)分析人員,因此客戶端賬號的80%都直接分發(fā)給運營部門使用;技術部主要基于tableauserver服務器的穩(wěn)定性、權限管控等方面進行簡單的二次開發(fā),而二次開發(fā)也僅僅只是把報表頁面嵌入到系統(tǒng)當中,通過菜單訪問控制、url傳參等方式實現(xiàn)權限控制。
產(chǎn)品架構(gòu)圖如下:
- 數(shù)據(jù)層主要是大數(shù)據(jù)平臺+部門數(shù)倉,通過大量基礎數(shù)據(jù)落地+數(shù)據(jù)權限隔離,讓業(yè)務部門能夠更高效的獲取基礎數(shù)據(jù)進行分析;
- 邏輯層是tableau+presto,主要是提供報表制作的服務和高性能數(shù)據(jù)引擎;
- 展現(xiàn)層是tableau可視化報表+可視化的檢索頁面,檢索頁面服務于分析師——快速獲取數(shù)據(jù)并進行分析;tableau可視化報表服務于業(yè)務人員——分析師將分析結(jié)果落地到tableau報表中,供運營人員日常分析。
業(yè)務流程如下:
二、權限方案
確定了產(chǎn)品設計方案和流程之后,重點需要攻克的是權限問題。
由于tableau自身比較封閉,幾乎沒有二次開發(fā)的可能,因此在實現(xiàn)行級數(shù)據(jù)權限的過程中完全依賴于Tableau現(xiàn)有功能進行挖掘。
經(jīng)過一段時間的使用研究,我們總結(jié)了幾套在tableau中可用的行級數(shù)據(jù)權限方案。
第一種方案:通過url傳參,將需要控制的權限類型作為參數(shù)帶入可視化報表url參數(shù)中
1. 在嵌入可視化報表的系統(tǒng)中開發(fā)一個小功能,實現(xiàn)報表發(fā)布時傳入指定參數(shù),如:配置網(wǎng)站權限,則參數(shù)會傳入website_id_p=XXX。
2. 報表開發(fā)過程中需要用到事實表中的網(wǎng)站website_id字段,由于用來傳參的字段不能在工作表的篩選器中直接用,傳參和篩選用同一個字段會有沖突,因此會copy一個website_id生成website_id_p的字段用于傳參。
3. 顯示篩選器,并將篩選器設置為“僅相關值”。
4. 發(fā)布到server后就可以在server端試驗數(shù)據(jù)權限是否生效。
以上這種方案實現(xiàn)起來最簡單,也是官方推薦的方案,并且數(shù)據(jù)可以進行正常提取。但是也存在一個很致命的問題:因為是通過url傳參,因此能夠傳入的參數(shù)是受瀏覽器限制的,市面上主流的瀏覽器支持傳入的url長度都不超過3000個字符,比如谷歌瀏覽器。但是業(yè)務現(xiàn)狀是,超過3000字符的權限類型有很多,該方案并不能支撐所有業(yè)務場景。
第二種方案:將用戶ID作為參數(shù)傳到url中,關聯(lián)權限表進行控制
- 編寫自定義SQL創(chuàng)建事實表、權限表(這里舉的例子使用了兩個權限類型,因此創(chuàng)建了兩個權限表1和2),并使用內(nèi)關聯(lián);
2. 創(chuàng)建一個名為user_id的參數(shù),分別在兩個權限表中作為參數(shù)插入(該參數(shù)是作為URL傳用戶ID時進行權限過濾的依據(jù));
3. 利用這個數(shù)據(jù)源開發(fā)可視化報表并發(fā)布;
用戶ID傳參的方案可以完美實現(xiàn)多維度,多數(shù)據(jù)權限類型的可視化報表開發(fā),并且可以與第一種URL傳參的方式共存(如:url中既傳user_id,又傳website_id),基本可以實現(xiàn)業(yè)務部門對于行級數(shù)據(jù)權限控制的所有要求。方案也有缺陷,由于是在數(shù)據(jù)源中就寫入?yún)?shù),因此無法做數(shù)據(jù)提?。ㄌ崛〉慕Y(jié)果為空),可視化報表的查詢效率完全取決于直連數(shù)據(jù)庫的查詢效率。
注:作為運營、數(shù)據(jù)分析師的可視化分析工具,tableau的分析效率高、學習成本低,也是目前市場上大部分數(shù)據(jù)分析師必備的分析工具,因此引入該工具進來之后業(yè)務部門的推廣應用比想象中的要快,這也是當初選擇tableau的主要原因。在解決了行級數(shù)據(jù)權限的問題之后,tableau甚至可以成為企業(yè)級可視化報表應用。
對于數(shù)據(jù)產(chǎn)品經(jīng)理來說,這樣一款優(yōu)秀的第三方工具可以作為公司在數(shù)據(jù)信息化建設過程中的選擇之一,而不一定要重復造輪子。
三、關于自助分析產(chǎn)品體系的其他建議
1. 關于大數(shù)據(jù)量檢索分析的優(yōu)化
在海量數(shù)據(jù)(特別是埋點數(shù)據(jù))的查詢的時候,如果讓用戶使用HUE直接連hive進行查詢,查詢效率往往讓業(yè)務人員崩潰,最終選擇棄用我們的產(chǎn)品。因此,如何讓分析師快速地進行數(shù)據(jù)檢索,從而提高數(shù)據(jù)分析效率是一定要考慮的。
技術人員在進行高性能數(shù)據(jù)庫選型的時候考慮了很多技術方案:Impala、presto、spark等等……這
些技術方案本身并不重要,產(chǎn)品經(jīng)理在這其中的角色是針對整體的產(chǎn)品體系建設提出要求,例如:
1. 高性能數(shù)據(jù)庫在做XXX復雜查詢的時候要控制在多少秒內(nèi);
2. 要支持tableau直連到這個高性能數(shù)據(jù)庫上;
3.? 支持數(shù)據(jù)權限的隔離,最好是能做到行級。
2. 關于數(shù)據(jù)質(zhì)量
數(shù)據(jù)質(zhì)量是自助分析平臺中不可或缺的一個環(huán)節(jié),如何保證數(shù)據(jù)準確性和及時性大多數(shù)時候都是開發(fā)需要考慮的問題,但是在產(chǎn)品設計過程中如何給業(yè)務“承諾”數(shù)據(jù)質(zhì)量也是一個很重要的命題。
我們的自助分析平臺在需求設計中就采用了最簡單粗暴的方式,用部門數(shù)倉跟大數(shù)據(jù)平臺的數(shù)據(jù)條數(shù)進行核對,并增加異常告警。雖然這個方案還有很大的優(yōu)化空間,但減少了部分排查問題的難度、也增加了分析師對數(shù)據(jù)質(zhì)量的信心。
本文由 @LinKiD 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
- 目前還沒評論,等你發(fā)揮!