下圖是最新的Gartner BI Magic Quadrant，其中領軍者之一的Tableau表現的異常突出，執行力象限上直接甩開其它產品一條街，前瞻性象限上略微超越了MSBI，懷着無比的好奇心，特意去Tableau官網下載了Desktop試用版體驗一把，從種種細節中能夠感受到濃濃的情懷，產品的確極具人性化，甚至官網的教學視頻都是略帶播音腔的中文語音，但為了客觀分析這款產品的用戶體驗，我沒有跟着視頻去系統學習Tableau，只是淺嘗輒止的拿自己項目中經常要用到的分析案例做些試驗，畢竟不是Tableau開發專家，所以有說的不對的地方還請行家指正。
打開Tableau Desktop客戶端，首先需要連接到數據源，支持的數據源非常全面，這里選擇SQL Server做個ROLAP玩玩，看到
，這不就是工匠情懷的體現嘛 :)
我連接的數據源是本地的AW數據庫，需要指定幾個待分析的表，我拖過去的是DimProduct, DimCustomer, FactInternetSales三張表，因為數據源有完善的主外鍵關系，所以這里也被正確的識別出表關系，另外，為Tableau隨處可見的模糊查詢輸入框點個贊
看一下工作薄左側數據源區域，Tableau並不是按物理表來區分維度和事實，而是默認根據表里的字段類型來做區分，用於聚合匯總的數字類型都被認為是事實度量值，其它類型如文本，日期以及主外鍵關鍵字都被認為是維度，也有一些字段本身既可做度量亦可作維度，例如UnitPrice單價，這時候是可以把UnitPrice從度量區域拖放到維度區域的。吐槽下數據源樹狀菜單沒有找到"折疊全部"的功能，要定位到具體的字段比較麻煩，只能用查找字段的模糊輸入框，還得敲鍵盤（還能更懶點嗎？）。
工作薄中間的內容區域就很像數據透視表了，行上我拖放一個ProductKey, 列上我拖放一個Gender
用Profiler捕捉到執行的查詢腳本如下，就是個簡單的Group By
這時候在Tableau上做個一鍵行轉列
，或者把ProductKey和Gender維度都放在行區域上，觀察到Tabular並沒有去數據源刷新數據，而是客戶端處理完成，也就是說Tableau客戶端緩存了結果集，而Excel客戶端是不會對結果集進行緩存的，所以Excel做類似的交互操作都必須得去數據源刷新數據，除非手動指定延遲布局更新。
Tableau這種做法有利有弊，利在於節省了重復加載數據的開銷，而弊端在於如果數據源數據發生了變化，是無法通知Tableau客戶端進行緩存過期，我做了個試驗，執行下面腳本更新下數據源，然后再Tableau上進行上述的交互操作，發現Tableau客戶端呈現的數據未做相應變更，Profiler也沒有捕捉到任何查詢命令，直到我在行區域再追加了一個維度，才得到正確的數據，Profilter也證實了數據刷新。那么Tableau至少應該有個手動觸發刷新的功能吧，沒找到這個功能。。。難道說只能部署到Tableau Server以后才能在頁面上觸發刷新？
update FactInternetSales set SalesAmount=SalesAmount+1
切換圖表類型，這個在Tableau和Excel上都不會去數據源刷新，excel的圖表的確不如tableau多樣、美觀，但tableau貌似是直接把透視表變成了透視圖，而不像excel能夠同時顯示透視圖表，並且圖表還能互相聯動
對ProductKey添加篩選器，還是得肉眼檢索，或逐個錄入，excel原生功能也是只能如此，而通常BU會希望能一把貼進去一堆sku key（以換行符或逗號間隔），excel可以定制功能來完善這個用戶體驗，詳見XPivot用戶手冊里的Filter功能http://www.cnblogs.com/xpivot/p/4317706.html，Tabular似乎不具備這樣的擴展性
但還是發現一處亮點，按公式指定條件來定義一些復雜邏輯，我假定一個需求是：匯總購買過sku 214或者購買過sku217的會員銷售情況， 注意篩選器務必選擇CustomerKey維度
生成的腳本有點復雜，這是ROLAP難以避免的問題，工具組織出來的SQL就不要指望性能多優越了，甚至這種腳本表達方式都沒多少優化空間，除非in memory rolap，否則應對稍大點的數據量就會非常吃力。建議閱讀下這個腳本，以充分理解rolap的工作原理
注意這里的"匯總購買過sku 214或者購買過sku217的會員銷售情況"這個需求，不等同於sku 214和217的銷售情況，主語不同（前者是分析人，后者是分析sku），分析的結果也完全不同，下圖是后者的篩選器設置以及查詢結果，注意篩選器換成了ProductKey
我們再來定義個需求，匯總購買過sku 214並且購買過sku217的會員銷售情況，腳本和截圖如下，篩選器用的還是CustomerKey，可以看到數據查詢結果和前兩個需求不一樣了
max(iif([ProductKey]=214,1,0))+max(iif([ProductKey]=217,1,0))=2
上面的幾個示例強調的是篩選器的選擇需要格外注意，稍不留神就會用錯，例如同樣的需求，如果在Gender這個篩選器里設置公式，會發現也能順利執行，但數據完全不對
追溯到腳本才發現原來是使用了Gender作為子查詢關聯字段了，BU當然沒有這個能力去查看核對腳本，如果不注意是非常容易犯錯誤的
我又嘗試用Tableau訪問SSAS MOLAP數據源，Tableau對多維數據庫的支持程度不足以實現以上幾個典型的需求分析，可能還是受限於MDX的表達方式，工具難以把可視化設置簡單無誤的翻譯成MDX腳本邏輯，顯然這個難度是遠遠大於翻譯成SQL的（PS: 對SSAS ROLAP的支持程度理論上來說應該會好過MOLAP吧，這個沒做測試）。
由上可見，Tableau的可視化功能足夠強大，至少上面這幾個需求案例在excel里本身是無法實現的，我在excel BI解決方案里也是通過擴展插件功能來實現類似功能，但不像Tableau這種需要編碼的條件組織方式，因為這種編碼方式不但門檻略高，而且很容易用錯，不適合給BU使用。另外，一些用戶體驗細節不如excel，找一個功能相對比較費勁，excel通常會把同樣的功能做成各種快捷入口，以滿足不同操作習慣的用戶，不過話說回來，如果excel后續版本也能支持Tableau這種按公式定義篩選器的功能，還是很讓人歡欣鼓舞的，至少IT角色的BI工作人員會非常喜歡。
這次試用主要是想體驗下篩選器的靈活性，的確有值得稱贊的設計，以后有機會的話再體驗下傳說中強大的計算引擎是怎么個工作原理，會不會是類似PowerPivot的Vertipaq引擎呢？始終認為這類東西就好比傻瓜相機和單反的區別，特定場合的確能夠發揮優勢，但涉及到針對性的調優就很無力，不如RDBMS的調優空間大，數據從RDBMS到MOLAP引擎就已經喪失了很多調優能力，再放到其它引擎能不能有足夠的渠道用於靈活解決性能問題呢？BI產品在做宣傳時，總能聽到誇大其辭的宣稱能夠做到真正的BU-Driven秒出報表，故意忽略幾個前提條件，其一就是得有一個干凈的數據源，事實上絕大多數的業務生產庫都不具備這樣的前提條件，如果BU真的去業務生產庫上做即時查詢，別說秒出了，能夠做到查詢邏輯毫無破綻都是非常困難的事情。至於性能，是否都能做到秒出，取決於硬件和數據源調優，in-memory rolap性能足以媲美molap，如果公司硬通貨缺乏的時候也能補充些軟實力，可以先把rdbms的調優做好，再結合molap，使兩者各擅所長的處理業務問題