報表系統的雄心

這周有朋自遠方來，聊了對報表工具的看法，因此專門寫篇文章來談談報表系統的未來。

筆者知道不可能有十全十美的報表系統，畢竟任何一個行業和企業受自身客觀環境的限制，但表哥嘛，總要有點理想和追求，就好比到一定年紀會自問，我的人生追求到底是啥?表哥到了一定階段也同樣，我的終極目標是什么?

首先合適的就是最好的。

脫離了業務驅動的任何IT系統，沒有價值，因此，從客戶需求出發，打造出適合某個細分市場的報表系統，就是最好的報表系統。

現在報表工具市場百花齊放，自有存在的道理，所謂的大數據報表引擎，在相當長的時間內，對于很多企業來講，是沒有必要的，大炮打蚊子，那也是極其浪費的事情。

同時，大數據讓客戶的數據意識漸起，因此，即使針對的是小數據的報表工具，也能趕上一波紅利。

但有一點是值得注意的，由于技術上沒有特別的差異性，大家互抄也很容易，因此，客戶服務能力就至關重要了，你賣的不僅是產品，更多賣的是服務。

接下來，我們切入正題。

任何代表趨勢性的發明和系統，都來自最前沿的應用領域，報表系統最核心的是對于數據的處理和展現，因此，以大數據應用為核心，或者擁有海量大數據的企業，其對于報表系統的訴求和應用，應能代表這個技術的發展方向，互聯網企業可以向BAT看齊，傳統企業可以向運營商看齊，比如中國移動曾經打造了世界最大規模的數據倉庫系統，在那個時候，引領了數據倉庫建設的潮流。

那么，如何打造極致的報表系統?

首先，極致報表系統的打造，不是一個工具或系統就能單方面解決的，客戶自身對于報表的認識和投入是至關重要的。

為什么?

因為報表系統能力不僅取決定于工具能力，也依賴企業的數據管理能力，而數據管理能力在各個企業的情況不同，同樣的工具在不同的企業應用那也是千差萬別，好馬也要配好鞍。

數據管理能力除了數據質量，最重要的是數據標準化能力。

一個企業的報表成千上萬，運維開發團隊疲于奔命，這是有問題的，說明它的數據管理能力還未到達一定的水平，當然，這也是大多企業的常態。

產生這個問題的一個根本原因是標準化能力不足，報表由指標組成，一個企業的基本指標非常有限，但指標的組合可以無窮無盡，因此，報表可以無窮無盡，這是禍根。

大多數企業做不了報表標準化的事情，有兩個根本原因：

一是IT報表團隊本身的問題，BI領域一直有一個挑戰，就是到底是以滿足業務人員需求為主還是致力于打造一個平臺，更致命的是，BI人員所謂的滿足需求并不是在完成一個功能，而是價值也許只有幾天的一段取數代碼，其是無法實現很好的傳承的。

但打造一個平臺是何其艱難，因為這里的平臺不僅僅指功能，不是搞個自助配置工具就算是了，還包括數據平臺，你可以叫作數據中臺，核心就是要打造一層標準化的數據層，對于報表來講，就是指標。

有種技術叫SOA，其對于IT系統是何其重要，但報表系統卻很少有類似的堅持的東西。

指標化當然很難，筆者這里不談具體的實現方式，只是提醒每個企業的BI團隊引領者應該思考這個問題，要相信企業大多數報表是可以指標化的，抓大放小搞定80%，就成功了，的確有部分報表難以指標化，比如有狀態的指標，但這個很少且無關大局。

二是IT報表團隊與業務人員的博弈，業務人員屁股決定腦袋很正常，但無論報表做的多急，要的多快，報表團隊還是要注意控制節奏，因為大多數企業，業務人員提報表需求沒有成本，決定了讓業務人員自發減少需求是無解的，到了一定階段，你做的再快，也無法帶來滿意度的提升。

報表團隊總要預留些余糧和人力，規劃一下自身的藍圖，研究下更高效的支撐方式，一個IT部門，大多時候，報表規劃建設一筆帶過，買個工具唄，更不會關注到標準化這種事情，你不提，誰都不會提。

報表標準化也不可能讓業務人員提出來，只有自力更生了，而且，即使你提出來了，業務人員還可能不理解。

報表團隊深陷事務型工作而難以抽身，很大程度反映了其視野的局限性，習慣用人力的投入解決一個無解的問題，報表管理者是需要反思的，我們總說表哥是老實人需要做老實事，但規劃上絕不能含糊，大數據時代，數據創新恰恰應該放到報表團隊的核心位置。

在說理想的報表工具前，筆者特意提了企業的環境，是為了說明，任何有牛逼報表產品的合作伙伴，在推廣的時候，需要找到好的客戶，有時產品營銷失敗不是你的錯，而任何一個企業，在買報表工具前，首先要知道，工具僅僅是手段，不是買了就萬事大吉了，你還需要在業務和技術上做些投入和努力，否則，可能也發揮不了工具的價值。

其次，速度是極致報表系統的一個基本要求。

筆者早幾年接觸到淘寶的數據魔方的時候，是非常驚訝的，它海量的數據、極致的速度，多維的展現，是多么的完美，后來到網上找了很多相關資料，才知道這個產品在數據處理上做了大量的定制改造，才使得它有這個表現。

那么能否有一個更加通用的報表后臺引擎，在降低對于數據定制化處理要求的同時，提供極速的前臺多維查詢展現?

雖然我們用HBASE實現了指標庫，后臺指標數據幾百億，但其對于數據的定制要求太高，在很多場景難以適用，而且，似乎沒有好的成熟前臺能夠適配，自己全套定制做也不大可能。

傳統的報表工具引擎側重展現，但對于后臺數據大多時候僅僅起到一個接入的作用，它的設計理念，可以認為是以重前臺，輕后臺的方式，盡可能覆蓋更多的后臺數據的形式去滿足市場需求，但帶來的問題是，后臺數據深度支撐能力太弱了，因此無法滿足海量多維度數據的快速查詢要求。

對于擁有海量數據的企業，需求已經在改變，有時，寧愿自己做報表，也不再愿意采購報表工具產品，這是有其原因的。

筆者已經知道當前市場上有不少新型的OLAP產品，諸如Kylin等產品的企業也在崛起，筆者沒用過，無法做出評價，但這個的確代表了方向。

所以說速度越來越重要，還因為當前有一種趨勢，分析型和清單級報表需要融合成一體，也就是說，從指標可以下鉆到清單，這可以幫助實現分析執行一體化，而以前清單往往靠取數臨時實現，造成了兩者的不一致，降低了異動核查的效率。

比如運營商其實有兩套報表，一套叫生產報表，一套叫經分報表，前者以滿足一線生產為主，后者以滿足管理者分析需要為主，以前很難有一種報表工具能同時支撐這兩種數據查看模式。

海量，快速，多維，這應是未來報表引擎的要求吧。

再次，開放性是極致報表系統的一個根本訴求。

其實，所謂開放和封閉是相對的，如果你的封閉體驗和性能做到了極致，客戶可以犧牲一定的靈活性來適應你的產品。

現在諸如數據庫一體機大行其道，因為好用嘛，暫時也沒有好的替代品。

但是，在報表產品上，封閉可能成為不了趨勢，筆者以前談過，越是面向前端的產品，用戶對于靈活性的訴求會劇烈增長，直到抵消產品封閉帶來的價值。

報表工具有前端展現和后臺數據引擎兩個基本模塊，假如你有強勁的后臺數據引擎，就需要考慮，前端的展現是否可以開放接口，能否提供一套API?要知道，再牛逼的前臺展現搞不過EXCEL，也搞不過PPT的組裝，更搞不過各個企業復雜的業務管理、機制和流程要求，比如，報表展現要打個水印怎么辦? 加入一段安全控制代碼行不行?

當然，不僅僅是前臺開放，后臺也需要，比如報表數據的刷新，觸發方式多種多樣，總要有些定制化能力，提供更多的可配置性和開放性。

再次，適配性是極致報表系統的一個現實要求。

各類報表產品顯然對于企業系統環境是有要求的，但不要為了極致性能而忽視現狀和通用性，比如SPARK2.0剛剛推出，就不要說產品只支持2.0，假如是基于hadoop的，則需要盡可能兼容大多數版本。

一般來說，假如只是為了打造一個更快的報表系統，企業不會去改變它現有的技術架構體系，畢竟報表始終是IT的下游系統。報表系統更應該考慮的是如何盡可能的適應當前大多數企業的現狀，與時俱進吧。

在大數據時代，產品的競爭力，很大程度是取決于你版本的更新速度，因為客戶的需求變化很快，技術更迭也很快，必須要適配的足夠快，已經有太多牛逼的公司由于緩慢的產品更迭速度而備受客戶詬病，一旦口碑做壞了，就一去不復返了，報表工具不是一種容易硬捆綁的產品，而且這個圈子并不大。

再次，談談報表前臺吧。

當前，很多報表產品都已經有拖拉鉆取的功能，但建議的一個設計原則是，能簡單就盡量簡單點吧，一個報表產品前臺，不要提供太多的選擇，最好還能分一下用戶層級。

大多企業一線人員，是報表的主要使用者，根本不會拖拉鉆取，它如一個嬰兒，報表是喂給它的，只要看得清楚，速度快就行了，不要奢望它會用到你哪怕30%的功能，給個搜素、收藏夾、導出功能就足夠了，以前OLAP產品所以用不好，就在于使用門檻太高，很多使用人員，甚至不知道啥叫維度，啥叫指標，你讓他拖什么?

高級的定制功能，設計步驟也要點到為止，配一張報表，最多是三步，選擇后臺表，選擇指標和維度，報表設計(比如多表頭啥的)，生成報表，當然還有調度啥的，就不細談了。

滿足大多數人的需求，忽略部分高級用戶的訴求，這應是一個設計原則吧，我記得以前做報表總是強調多表頭啥的，但真實情況是有幾個人真會用，而且馬上審美疲勞，還不如拉到EXCEL里面搞搞更漂亮。

不過，話說回來，各個企業的情況不同，筆者這個判斷肯定是有失偏頗的，且自己離開報表制作很多年了，權當參考吧。

最后，還是要提提報表企業的雄心吧。