數(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)權限表進行控制

1. 編寫自定義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é)議