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