企業大資料平台的重要性

不論你願不願意承認，大資料時代已經來臨了。大資料潮流引領的技術變革正在悄無聲息地改變着各行各業。雖說「大資料」是近些年才火熱起來的詞彙，但可以說「大資料」其實一直存在，隻是由于技術的局限性使得人們在很長的一段時間裡沒有辦法能夠使用全量資料。但是随着技術的發展與革新，現在人們可以使用大資料技術來處理海量的資料了，這使得很多之前隻能停留在理論研究層面的算法和思想現在能夠付諸行動，比如現在很火爆的深度學習。與此同時，大資料技術這一新興的工具也讓人們擁有了一種新的思維模式，即大資料思維。

大資料思維注重全量樣本資料而不是局部資料，注重相關性而不是因果關系。通過分析和挖掘資料将其轉化為知識，再由知識提煉成智慧以擷取洞察。大資料思維在很多行業都有用武之地，比如在銀行行業，基于大資料的風險控制體系就是一個很好的例子。通過大資料技術重構的機器學習算法不僅可以在全量樣本資料上進行訓練，還能引入更多的次元參與學習，進而建構一個比傳統技術更高效、更準确的信用征信評分體系。同樣，在電商行業也有很多大資料應用的例子。比如電商企業通過對手中大量的使用者行為資料進行分析挖掘，可以得知使用者的喜好并繪制出完善的使用者畫像。這使得電商企業能夠更加了解自己的客戶，進而對他們進行精準營銷和相關商品推薦。

類似的例子數不勝數，這些案例的背後大資料技術功不可沒。作為這個時代的參與者，我們的企業理應做好充足向大資料領域轉型的技術準備，以免在這個時代落伍。

在這個轉型的過程中最為重要的環節之一便是技術平台的建設。

一、缺乏統一大資料平台的問題

大資料思維需要依托大資料技術的支撐才能得以實作，是以隐藏在背後的支撐平台非常重要。正所謂下層基礎決定上層建築，沒有一個牢固的地基是建不成摩天大樓的。我們不妨設想一下作為一個投身于大資料領域的企業，如果沒有一個統一的大資料平台會出現什麼問題。

資源浪費

通常在一個企業的内部會有多個不同的技術團隊和業務團隊。如果每個團隊都搭建一套自己的大資料叢集，那麼寶貴的伺服器資源就這樣被随意地分割成了若幹個小塊，沒有辦法使出合力，伺服器資源的整體使用率也無法得到保證。這種做法無疑是對企業資源的一種浪費。

其次大資料叢集涉及的技術繁雜，其搭建和運維也是需要學習和營運成本的。這種重複的建設費時費力且沒有意義，隻會造成無謂的資源浪費。

資料孤島

如果企業内部存在多個分散的小叢集，那麼首先各種業務資料從實體上便會被孤立地存儲于各自的小叢集之中，我們就沒有辦法對資料進行全量的整合使用，資料便失去了關聯的能力，大資料技術使用全量資料進行分析的優勢也喪失了。

其次，在這種情況下也很難實作對業務資料進行統一的模型定義與存儲，一些相同的資料被不同的部門賦予了不同的含義，同一份資料就這樣以不同的模型定義重複地存儲到了多個叢集之中，不僅造成了不必要的存儲資源浪費，造成不同部門之間溝通成本增加。

服務孤島

企業内部各自為政的小叢集的首要任務是支撐團隊或項目組自身的業務場景來滿足自身的需求，是以在實作功能的時候不會以面向服務的思維來抽象提煉服務，很可能都沒有可以暴露出來供小叢集外部使用的服務。退一步講就算這些小叢集有提供出來的服務，那麼它們也缺乏統一的頂層設計，在做服務設計的時候沒有統一的規則，導緻提供的服務參差不齊，其通路入口也很有可能不統一。同時這些服務被分散在不同的叢集之中，應用程式不能跨越多個叢集使用所有的服務。

安全存疑

企業内部各項目組或團隊自身維護的小叢集通常都是隻為支撐自身業務而實作的，不會同時面對多個使用者。企業通過一些行政管理手段可以在一定程度上保障叢集的安全。但是當團隊人員擴充、叢集規模擴大或是大資料叢集的服務同時面向多個技術團隊和業務部門的時候，很多問題就會顯露出來。首當其沖的便是需要面對多使用者的問題，叢集不再隻有一個使用者，而是需要面對多個不同的使用者。這就自然而然地引出一系列需要切實面對和解決的問題，比如使用者的管理、使用者的通路控制、服務的安全控制和資料的授權等。小叢集通常都處于「裸奔狀态」，基本沒有什麼安全防護的能力。叢集安全涉及方方面面，是一個非常複雜的系統工程，不是輕易能夠實作的。

缺乏可維護性和可擴充性

大資料領域的技術發展日新月異，其本身正處于一個高速的發展期，我們的叢集服務會時不時需要進行更新以獲得新的能力，或是需要安裝更新檔以修複 Bug。在這種情況下對多個小叢集進行維護就會變得非常麻煩。同時當某個小叢集性能達到瓶頸的時候也沒有辦法很容易地做到橫向擴容。

缺乏可複制性

各自為政的小叢集缺乏統一的技術路線，導緻大資料叢集的運維工作會缺乏可複制性。因為一個部門或者團隊與其他部門使用的技術元件可能完全不一樣，這樣一個叢集的安裝、維護和調試等經驗就沒有辦法快速複制和推廣到其他團隊或部門。同時在大資料應用研發方面也會存在同樣的問題，正常來講當我們做過的項目越多，從項目中獲得的經驗也就越多，我們能從這個過程中提煉、抽象和總結一些經驗、規則或是開發架構來幫助我們加速今後的應用研發。但是技術路線的不統一很可能導緻這些先驗經驗喪失後續的指導意義。

二、 建構統一大資料平台的優勢

如果我們能夠化零為整，在企業内部從宏觀、整體的角度設計和實作一個統一的大資料平台，引入單一叢集、單一存儲、統一服務和統一安全的架構思想就能較好地解決上述的種種問題。

資源共享

使用單一叢集架構，可以實作通過一個大叢集來整合所有可用的伺服器資源，通過一個大叢集對外提供所有的能力。這樣将所有伺服器資源進行統一整合之後，能夠更加合理地規劃和使用整個叢集的資源，并且能夠實作細粒度的資源排程機制，進而使其整體的資源使用率更加高效。同時叢集的存儲能力和計算能力也能夠突破小叢集的極限。

不僅如此，因為隻使用了一個大叢集，是以我們現在隻需要部署和維護一個叢集，不需要重複投入人力資源進行叢集的學習和維護。

資料共享

使用單一存儲架構，可以實作将企業内部的所有資料集中存儲在一個叢集之内，友善進行各種業務資料的整合使用。這樣我們便能夠結合業務實際場景對資料進行關聯使用，進而充分利用大資料技術全量資料分析的優勢。同時，在這種單一存儲架構之下，各種業務資料也可以進行統一的定義和存儲，自然的也就不會存在資料重複存儲和溝通成本增長的問題了。

服務共享

通過統一服務架構，我們可以站在宏觀服務化設計的角度來考慮問題，可将一套統一服務設計規則應用到所有的服務實作之上，同時也能統一服務的通路入口與通路規則。

除此之外，因為所有的服務是由一個統一的大叢集提供的，這便意味着這些服務不存在孤島問題，可以進行整合使用。

安全保障

通過統一安全架構，可以從平台層面出發，設計并實作一套整體的安全保證方案。在單一叢集架構的基礎之上，可以實作細粒度的資源隔離；在單一存儲架構的基礎之上可以實作細粒度的資料授權；在單一服務架構的基礎之上可以實作細粒度的通路控制；如此等等。

統一規則

由于統一的大叢集實作了技術路線的統一，這使得我們在後續應用開發的過程中有很多施展拳腳的空間。比如我們可以通過在大資料應用的開發過程中得到的一些經驗總結，将這些經驗整理為方法論和模型，再基于這些理論和模型實作一套大資料平台開發的 SDK。最終通過這套 SDK，可以很友善地将這些經驗快速複制推廣到整個企業内部。

易于使用

在開發一款大資料産品或者業務的時候，我們應當将主要的精力放在業務的梳理和實作之上，而不應該過多地關注平台底層細節，如叢集服務的安裝、維護和監控等。

比較理想的方式是直接将應用建構在一個大資料平台之上，通過面向平台服務的方式進行應用開發，或是借助平台工具直接以互動的方式進行資料分析。通過平台服務和工具的形式暴露平台能力，屏蔽平台底層細節。應用開發者直接使用平台服務接口進行應用開發，資料科學家、資料分析人員直接使用平台提供的工具進行互動式資料查詢與分析。