BI系統 包 含的功能模組

資料採集、資料處理、資料應用、資料管理、業務報表、實時監控、許可權管理

開發端：不同解決方案可以有不同系統管理員、DTS包密碼保護、報表密碼保護瀏覽端：NT使用者認證、BI使用者認證資料安全：選單/報表授權：在選單管理中進行設定，可控制哪些使用者可以看到哪些選單/報表。行授權：A部門經理只能看到A部門的資料。列授權：助理只能看到銷量，看不到利潤。匯出功能控制：可針對不同使用者關閉匯出到EXCEL的功能。

在本文，作者描繪了一個理想的資料BI系統應該長成的樣子。你是這樣的麼？enjoy~

在日常工作中，無論是to C還是to B的產品汪，都需要面臨一個問題，那就是在業務發展到一定規模的時候，由於林林總總的原因，譬如出於安全性考慮，亦或是業務場景愈加複雜等等，市面上的第三方資料分析平臺或者自家的平臺已經無法滿足業務發展的需求，這時候，就要著手搭建一個強力的BI工具，以適應高速發展的業務。

而一個好用的工具，將會解放生產力，極大的提高工作效率。加持了這個增益buff的運營和分析師們，將會如虎添翼，向你展示什麼叫地表最強戰鬥力。

就算沒有KPI的壓力，那試想下，運營小姐姐因為你一手設計的出色BI系統而驚喜時，作為產(dan)品(shen)汪的你，是不是有機會……咳~

在進行產品設計前，先花點篇幅來講講資料在從產生到消亡（歸檔）的生命週期中需要經歷哪些階段吧。

資料採集

資料來源分兩塊，一塊是內部資料，一塊是外部資料。對於to B的業務，內部資料多為業務資料，譬如零售業的供應鏈倉儲以及GMV的細分資料等，金融業的交易流水和風控模型(風控模型也包含了使用者行為資料)等，對於to C的業務或產品，除了基礎的流量資料、業務資料外還會有使用者行為資料等。這類內部資料的獲取較為基礎，常規的CS/BS的介面資料互動即可完成資料採集，對於C端產品，比較重要的是使用者行為資料的採集，這裡就需要做好資料埋點的工作，細化到每個事件的節點。

關於這類日誌的採集，只要在需求的範圍內，採集地越詳細越好，這樣可以精準的定位問題，是技術支援、運營策略，還是產品設計上的問題。在一些web類應用中也見到過每次拖動或點選就記錄行為並回傳給伺服器的，這類高頻的傳輸方式能夠保障資料的完整性，但在高併發時會對伺服器造成一定的壓力，產品汪可在需求評審會上提出此類需求和顧慮，提前讓研發團隊瞭解到這種業務場景，並出具應對的方案，下文講述資料處理時會順帶概述一些技術的方案。

內部資料都是自家的，只要許可權允許，那就可以進行增刪改查的操作，但外部的資料大多不公開，需要購買，有些甚至無處購買，且外部資料的結構不一，在進行資料歸類的時候可能會造成一些困擾。對於那些能買的到的資料，往往需要進行資料清洗。

2015年號稱網際網路消費金融的元年，相關產業蓬勃發展。銀行系、電商巨頭以及一些傳統企業陸續進軍這個市場，這些巨頭們手裡掌握這充足的資料，足已支撐起一個較為全面合理的風控系統。但對於那些新入局的網際網路團隊，就沒這麼充足的資料來源去搭建其風控系統，這時候，這些團隊就需要從市場上‘專業’從事大資料服務的公司手頭購買資料。然而，這些都是經過二道販子，三道販子甚至不知道幾手了的資料了，每一層中間商為了盈利，往資料裡面兌水，一些互金巨頭為了干擾市場，也會對其中的資料進行加工並借殼售賣，到了這些使用資料的團隊手裡時，這些充斥著垃圾的資料能有效利用的可能不到一成。而清洗這些資料，需要花費的成本將無限大。一個使用者風控模型的迭代修正，至少需要走完一個消費-還貸的週期，這中間需要的時間成本不是一般的團隊所能接受的。

對於那些買不到，但又可見的前端資料，就可以通過爬蟲的方式進行採集。爬蟲的歷史比較悠久，自第一個搜尋引擎誕生已經過去了近三十年，而最早出現的爬蟲卻沒有明確的說法，唯一可以知道的是自主機web時代開始的。而發展到現在，爬蟲技術及其社群已經枝繁葉茂了，從近幾年流行的python到最好的語言php，以及C語言系都可以拿來寫爬蟲。一般爬蟲的原理都是構造請求，向目標伺服器請求相關內容。資料本身就是一個相對敏感的點，有些數值類的資料往往是一個公司的命脈，為了遏制爬蟲來採集資料，公司一般會設計不同的機制來反爬蟲。譬如常規的伺服器判斷請求頭部的UA和Referer，對cookie和驗證碼的驗證，對IP訪問次數的限制，通過對CDN標識的判別。還有一些前端的限制的方法，比如用JS動態載入資料以及一些能加大解析頁面難度的做法。

比較成熟的就是一些前後端結合的方法，比如前文所講的使用者行為記錄，再通過使用者模型演算法找出爬蟲的特徵，從而進行封殺。對於爬蟲，大多數網站還是比較寬容的，或者說，沒有一個萬全之策來分辨真實使用者和爬蟲，因為誤傷率一直是個繞不過去的坎。關於如何應對反爬蟲機制，感興趣的觀眾老爺可以繞道去攜程技術中心的公眾號看看，作為各類爬蟲教程的目標網站，攜程對Anti-Crawler這個課題還是有些心得的。

資料處理

一般來說，涉及的資料的儲存處理，不在產品崗的只能範圍內。但是產品汪麼需要明確資料呼叫的需求，以便DB開發設計合理的技術架構。按照資料所在的生命週期，或者資料被呼叫的頻率，可以將其分為四個等級，活躍資料、休眠資料、沉默資料和歸檔資料。這裡拿電商的訂單週期作為範本解釋。

• 活躍資料：這裡的活躍資料一般指的是需求確定需要長期儲存的資料。不包括那些儲存在快取裡，在短時間會過期的資料。使用者確認提交訂單後，一直到確認收貨，這個期間的訂單的資料會以高頻率被訪問，使用者、商家、平臺、物流等多方角色需要檢視這條資料，以確保這個訂單完成。

• 休眠資料：休眠資料被訪問的頻率一般。訂單走完正常的週期，已經超過退換貨的期限時，可能因為保修，統計分析等情況任會被呼叫。

• 沉默資料：這類資料被訪問的頻率相對較低，在常規處理和儲存後，已經將需要長期呼叫的內容儲存到其它資料庫表中作為活躍資料使用，此時源資料將進入沉默階段，一般只在週期性的統計時會被呼叫。在分析季度商品銷售情況時，需要翻出這筆訂單來詳細的分析。

• 歸檔資料：歸檔資料指的是已經被處理提取重要內容的源資料，為了資料完整性，對源資料進行歸檔處理，歸檔的意義不光是指備份資料，資料需要在生命週期的各個階段做好備份工作。歸檔的另一個意義是壓縮資料結構，保障核心資料能夠被快速響應。

在日常工作中，資料的等級界限也許不會這麼明確，具體還得看需求的情況。

資料應用

講完了資料的產生到歸檔，相信觀眾老爺心中對這個BI資料系統的搭建已經有一個整體的規劃了，下面筆者將描述在筆者心中，一個理想的資料BI系統，應該是長成什麼樣子的？

圖：產品架構

後臺的在進行有關資料的操作時，都可以選擇進行GUI和SQL的操作。下文的所有功能只描述GUI狀態下的使用，不描述SQL狀態下的使用。保留SQL功能的原因有以下幾點，就像Bash會比GUI介面發生意外的概率小很多一樣，純SQL操作比GUI操作來的穩定，而且資料開發更樂意去使用SQL。這種保險設計可以在產品迭代的過程中，實現一些因為不常用而缺失的功能。

下面按照操作流程，講講各模組的功能。

資料管理

在生產環境中，業務資料，流量資料或著其他資料的元資料已經產生，儲存在資料庫，這部分資料稱之為「資料來源」，這個功能的頁面稱之為「資料來源管理」，整個後臺對資料來源的唯一的許可權只有讀取(select)，不然誤操作造成損失，這口鍋真不好分，直觀的看，好像是操作者的失誤，再深一步講，是技術規範的缺失，但追究到底，還是產品設計的缺陷，所以，許可權切記控制到只讀。使用者(運營，資料分析師，資料工程師皆稱為使用者)可以讀取資料來源庫表中的元資料，並存儲到資料庫，這部分被提煉過的資料稱之為「資料集」。許多資料需要每日定時或者按照其它週期進行處理，譬如那些避開伺服器併發的時段的資料統計，這種資料的錯峰處理大多放在凌晨或者其他服務空閒的時段，為了節省使用者的精力和防止疏漏，這種週期性的點控式的任務就顯得很有意義，但是單個任務沒法滿足對複雜資料的處理需求，借用MySQL的事件排程器(Scheduler)和觸發器(Trigger)的設計理念，將這些任務連線在一起，讓它們按照指定條件依次執行，從而實現按照序列處理資料結構和資料內容的任務環。資料集操作生成的庫表的增刪改查許可權控制在初始化時，預設只開放給使用者自己，若有需求，後期可以在許可權管理中配置。

業務報表

在完成了對資料的處理後，資料還只是純粹的單一結構的內容，乾巴巴的資料難以直觀地觀察，所以資料視覺化這一功能必不可少。市面上優秀的開源前端框架有很多，這裡推薦兩款——AntV和Echarts。這兩塊框架能夠滿足絕大多數業務場景，尤其推薦Echarts，給某度開源如此良心之作打call，Echarts中gallery社群的作品堪稱驚豔，如果這個框架能將效能再繼續優化下去，那就是做資料視覺化的不二之選。關於AntV的話，友商都說Ant Design可能是開創了UI元件庫的先河，元件的視覺、互動設計和前端的融合可謂是相當讓人佩服。在實現上使用了較為先進的框架，主要還是React實現，好在今年八月，Angular版本的總算髮布了。不過框架歸框架，研發同學選擇技術方案是他們的權利，產品汪在進行後臺設計時可以參考AntV，這樣可以讓你少走很多彎路。業務報表設計功能可以達到高度自定義，可以對業務報表的選單、頁面佈局進行設計。在進行圖表設計時可以選擇豐富圖表型別，從常規的折線圖、柱狀圖和餅圖等到不同領域常用的圖表，譬如K線圖，漏斗圖，關係圖等。然後再給圖表填充資料，按照規則給圖表入參，與此同時對該表報的展示物件進行使用者選擇。這種高度自由的操作方式，看似會增加研發的週期和成本，但這種設計實際上將會解放研發同學。在後期產品迭代成型後，使用者自主使用資料生成報表，而不是常規進行需求-開發的週期，從而讓研發同學將更多精力放在核心技術上而不是業務上。所以綜上所述，這種設計不光是功能上的設計，而且還是一種成本轉移的設計。

實時監控

該模組分兩個主要功能，一個是概覽功能，一個是異常預警。概覽頁面就是業務報表的Dashboard，唯一的差別就是這裡的資料多為實時資料，所以不贅述，如果希望這個門面能好看點，那就單獨拿出來，作為一個獨立的功能需求進行設計開發。關於異常預警模組，很多時候名不副實，預警意義在於預測當某個數值達到臨界點時進行報警操作，但這種預警機制的演算法可能會複雜，難以制定產品需求邏輯。所以在實際設計中，警報觸發的條件可以配置多個，按照執行週期輪詢，觸發時進行簡訊或者郵件等推送操作，和資料來源管理一樣要注意的是庫表名稱的日期變數和事件環的設定。

許可權管理

在講整個產品設計中，一直在強調許可權的管理，不是筆者話多，這個關係到資料安全的問題還是得注意下的。資料庫的許可權控制應當從伺服器、資料庫到特定表，關於控制到特定的列甚至儲存過程，雖然MySQL有這個功能，但好像常規的許可權真的沒必要控制到這麼精細。當然，對於資料結構和資料內容的增刪改查許可權還是有必要做許可權控制的。最後，加上基本的操作日誌的展示，用以查錯問責皆可。

講到這裡筆者也就將整個產品設計的思路敘述完成了，觀眾老爺可能會覺得沒有圖解，過於抽象不好理解。但其實，筆者是故意沒放圖例的，因為擔心放了原型後，會誤導讀者進行雷同的產品設計，故而只敘述核心功能，不做視覺和互動上的表現。如有哪裡看不懂的或有歧義的可以向筆者公眾號提問，筆者會抽時間回覆的。

企業在業務早期用第三方的平臺服務是高性價比的選擇，但也要考慮到後期資料遷移的問題。第三方平臺為了最大化平臺的價值，不可避免的設計通用的產品結構和服務體系，以相容更多業務場景，但這樣一來就不能適配企業一些特殊的業務需求。最重要的是，自家的資料的一系列操作都在別人家的伺服器上執行，這個資料安全的問題是塊心病。今年年中時，作為菜鳥物流的創始成員之一的順豐，受到菜鳥集團的一波突襲，這已然不是站隊的問題了，從IaaS到SaaS，一大撂資料的處理和傳輸都是經過別人家的基礎設施，在資訊主權這個問題上，一旦發生了糾紛，那處理起來一個頭兩個大。前陣子開完的人大常會上，新修訂了反不正當競爭法，也許有希望改善這個問題。畢竟對於企業而言，還是希望將更多的精力投入到業務經營上，而不是進行一些糟心的商戰。不過好在市場上已經有越來越多的資料服務供應商已經可以提供私有化部署，加上個性化的功能設計在一定程度上可以解決企業的業務需求。