第4章
企業大數據自主實施思路

當前，新一代信息技術與傳統企業的深度融合（互聯網+），正在引發影響深遠的產業變革，形成新的生產方式、產業形態、商業模式和經濟增長點。各行各業都在加大科技創新力度，基于云計算、大數據、人工智能、物聯網、智能設備的互聯網技術正在引領制造方式變革；個性化定制、供應鏈優化、財務預測、營銷管控、庫存優化、用戶全生命周期管理、智能客服、電子商務等正在重塑產業價值鏈體系。

當企業決定實施大數據戰略時，應該如何開始？本章將圍繞企業大數據在自主實施之前如何規劃進行講解，包括規劃原則、目標藍圖、建設目標、組織規劃、技術方案、人才規劃、投入產出評估、數據風險管理幾個方面。

4.1 制定規劃原則

在企業級大數據應用系統設計規劃過程時，為確保系統的建設成功與可持續發展，在系統的建設與技術方案設計時我們遵循如下的原則：

4.1.1 價值性

公司在做大數據規劃之前需要弄清楚一些問題：到底有多少數據？數據都是什么類型？數據分布在哪些環境？數據質量到底如何？這些數據都能干什么？數據價值如何提取？很多企業中的業務部門想針對一些數據進行分析時，卻不知道能拿到什么數據，這直接導致了無法準確描述數據價值預期的問題。所以企業開始設計大數據系統實施方案之前，應首先由數據部門牽頭，對企業現有業務系統的數據情況進行全方位的梳理，了解各系統的運行情況和各系統之間的關系，完善各個系統的數據字典，并結合數據字典對原有系統中的數據質量進行評估，形成系統數據質量提升方案。

對數據價值性的評估是建立大數據平臺的前提和原始動力，如果一家企業自身業務系統數據不夠完善且數據質量低，說明數據價值度也低，首先要做的工作是完善業務系統數據規范，提升數據質量，這樣才能在大數據系統實施后真正做到數據價值最大化。

4.1.2 實時性

在傳統的數據挖掘統計中，不管是數據標簽還是數據模型，一般都是通過數據庫或傳統建模工具定時執行生成的，這種處理方式有幾個弊端：

?只有當事件發生一段時間之后，通過數據報表才能看到，數據延遲性較大；

?發現問題時再去補救已經為時已晚，需要花費大量的時間和資源去做數據和業務的回滾；

?在數據倉庫創建的過程中，它必然要根據業務系統數據的更新而進行迭代，實現數據完整無誤的增量更新，是傳統數據倉庫建立時最大的技術難點；

?數據倉庫在與業務系統對接后，更需要有效地保障業務系統實時讀取和操作相關數據的能力。

所以，為了實現數據實時錄入、海量數據實時計算、生成動態實時標簽、數據實時提取投入應用等關鍵節點，需要在大數據平臺設計時系統地解決這些問題。如果在大數據平臺建設之后仍無法解決，那么大數據平臺就淪為一個升級版的“傳統數據倉庫”，系統價值就會大打折扣。

4.1.3 高效性

當企業中的業務數據系統使用了一段時間后，通常會由于跨多平臺和異構數據環境、海量數據的復雜計算、延伸業務模型的優化修正以及重復計算任務的冗余而導致大數據平臺效率的低下。

另外，數據平臺上線后，隨著業務量的增加，原有的計算資源將面臨嚴峻考驗。如何根據計算任務的重要級別進行資源分配，使重要任務優先運行；如何解決傳統ETL和數據挖掘模型少則幾個小時，多則幾天的運行效率；如何協調開發和調試階段資源的分配都是需要解決的問題。

以上問題都是對大數據平臺高效性的考驗，如何最大程度保障平臺執行效率、數據高效的整合能力、數據模型的計算能力、資源分配能力等，都是在平臺設計和實施時必須要考慮到的。

4.1.4 安全性

大數據平臺安全是由系統類、功能類、數據類、資源類四個層面組成的。一般情況下，系統類、功能類、數據類安全是業務相關的，需要具體問題具體處理。而資源類相對來說比較獨立，在服務端體現為ETL、算法及服務器的運行權限，在客戶端則體現為數據模型的使用權限。如何將權限分配給用戶，不同的大數據集群擁有不同的授權模型，授權模型和組織機構模型有很大的關聯性。考慮到企業大數據的共有特性，在整個規劃中，我們需要從下面四個層次來了解大數據平臺的系統安全：

（1）系統類

在客戶端，系統類安全涉及訪問IP段的限制、登錄時間段的限制、連接數的限制、特定時間段內登錄次數的限制等，為用戶提供和其權限相關的用戶界面，僅出現和其權限相符的菜單、操作按鈕；在服務端，則對URL程序資源和業務服務類方法的調用進行訪問控制，是大數據平臺的第一道防護大門。

（2）功能類

功能類安全會對程序流程產生影響，例如用戶在操作業務記錄時，是否需要審核，上傳數據文件不能超過指定大小，操作按鈕可控制的功能范圍等。這些安全限制已經不是對入口的限制，而是對大數據平臺操作流程的限制，這在一定程度上會影響平臺的運行。

（3）數據類

數據安全包括兩個層次，其一是字段級數據安全，即用戶可以訪問大數據平臺的哪些庫、表、字段；其二是行級數據安全，即用戶可以訪問字段下的哪條數據。一般以用戶所在角色或組為條件進行權限分配。

（4）資源類

從硬件和軟件上對大數據平臺的執行任務進行控制，用戶通過客戶端提交數據執行任務時，大數據平臺根據用戶的級別、任務的重要程度，自動為任務排序并分配CPU、內存等計算資源，以便更好地利用有限的平臺計算資源發揮更大的作用，集群的容量大小直接影響到任務運行的效率。

以上四個層次的安全，按粒度從粗到細的排序是：系統類、功能類、數據類和資源類安全。

4.1.5 延展性

在大數據平臺設計的過程中，為了最大限度地增強平臺的價值，最大限度地吻合各業務部門的需求，充分考慮平臺今后的硬件擴展、功能擴展、應用擴展、集成擴展等多層面的延伸，整個實施過程也應該始終貫徹面向數據價值，圍繞平臺應用，依靠業務部門，注重實效的方針。保證平臺的延展性可以提高穩定性且可靠度高，滿足用戶需求不斷發展的要求，便于應用程序的升級及擴展，減少應用系統再開發（二次開發、定制）的工作量從而降低成本。一般地，我們可以從以下幾個方面考慮：

（1）組件化結構

采用全組件化結構設計，每個組件都被獨立地實現，并通過標準接口聯系在一起。每個功能組件在功能上獨立，同時可根據用戶需求靈活配置、組合，實現平滑升級擴容。功能實體可使業務和開發人員根據具體使用要求增加或減少系統應用模塊。

（2）標準化接口

采用標準統一的接口設計，所有功能實體間的數據交換以及對其他模塊的數據引用都通過標準接口完成，使多個組件對接時在開放性、穩定性、擴展性與集成性上有著很好的適配空間。

（3）開放的功能包

平臺除了組件化結構設計與標準化接口設計以支撐開放體系結構外，為了方便用戶個性應用的開發，還應該考慮封裝平臺及其組件所需的二次開發應用工具包，使其他技術團隊對平臺進行二次開發時能夠更好地復用。

4.1.6 全局性

大型企業尤其是集團性企業通常具有非常多的業務群，要建立一套既能滿足整體需求，又能適應各個子體的大數據系統，需要企業做好頂層設計。

頂層設計涉及大數據項目的各個方面，具體如下所示：

?平臺整體技術架構。整體設計大數據平臺從底層到應用層的技術架構，包括數據源與數據接入、數據清理與提升、數據存儲與檢索、數據學習與挖掘、應用模型封裝、服務層搭建等。

?物理和虛擬部署架構。大型企業內部的數據環境往往涵蓋物理設備與虛擬化設備，針對性的大數據部署架構也可能產生基于不同環境的對接。

?軟硬件資源評估。對大數據平臺搭建涉及的需求以及開發所需要的各種資源需要整體規劃，避免資源冗余和浪費。

?整體組件和功能組成。對于大數據系統內部不同功能之間存在的技術、組件高效率復用，盡量實現功能和組件間的松耦合關系。對于外部其他系統之間的兼容性也需要納入大數據系統設計之中，外部系統可能包括數據系統（例如報表展示系統、數據采集系統、虛擬化產品等），也可能包括業務應用系統（例如推薦系統、調度系統、庫存管理系統等）。

?平臺公有云、私有云和混合云設計。對于大數據平臺的實現可能包括公有云、私有云以及混合云三種場景，不同的實現場景都應該有相應的解決方案。最終的終端應用場景會在企業內部或外部，以產品化界面或功能服務或API等形式展現，因此這也意味著在設計之初需要考慮多種服務場景支持的可能性。

?數據綜合治理方案。從整體層面對數據進行全生命周期管理，包括數據標準化、元數據管理、數據安全防護、數據隱私與脫敏、數據質量評估與提升等。

?應用整合與細分應用場景。所有的上層應用都應該在規劃階段做好，與之對應的底層或中間層的功能實現才能針對性的開發，進而可以避免需求改變導致之前的系統被整體推倒或重新設計開發架構的風險。

?平臺可維護性與升級策略。對于大數據平臺建設完成之后的可維護性包括硬件可方便擴展、軟件可自動化部署、不間斷的升級及補丁修復、集群整體監控與界面化管理、服務的高持續性和可用性、平臺高執行效率、低成本維護和升級方案等。

?項目實施前后的培訓和內部推廣。對于大數據系統的實現需要企業內外部各個部門和公司的支持，因此對于內部的大數據價值、應用等方案的引導和推廣非常重要。尤其是當大數據系統完成并交付之后，直接落地應用的是一線的各個部門，因此針對各個部門的整體培訓、指導甚至制度約束等工作必不可少。