不會搭建大數據平臺，我被老闆優化了...

「

隨着業務的飛速發展，信息化做爲業務的支撐，各個企業都創建了本身的信息化系統。

圖片來自 Pexels

在業務增漲過程當中，每一個企業不知不覺積累積累了一些數據。不管數據是可能是少，企業都但願讓「數聽說話」，經過對數據的採集、存儲、分析、計算最終提供對業務有價值信息。

此時，大數據平臺的搭建就是企業面臨的問題，搭建大數據平臺有哪些思路？怎麼樣的搭建路徑可讓企業少走彎路？什麼樣的架構是業內標準？經過什麼手段來分析和展現已有的數據？

或許這些問題會縈繞在您的心頭，那麼今天就一塊兒來看看如何解答它們吧。

大數據平臺的搭建思路

實際上作任何事情都要有目標，而後根據這個目標根據自身的條件和外部的狀況制定一個思路，這個思路也能夠理解爲實現目標的路徑。那麼大數據的平臺搭建也不例外。

腳本工具化

在數據收集，存儲、分析的初期，一般來講程序員都是根據業務需求，經過一些腳原本完成數據收集，分析的工做。

表面上是完成了一些數據操做的功能，同時也知足了用戶的需求，可是在編寫腳本的時候，都是「頭疼醫頭腳疼醫腳」，只是針對具體的數據問題提出解決方法。

沒有一個統一的解決方案，針對一些基礎通用的功能也沒有作抽象和提取，致使腳本維護的成本增長，後期服用的成本也會增高，有重複造輪子的嫌疑，效率不高。

所以，咱們會講這些腳本組件包裝成一個個工具，用命令行或者 UI 界面的方式提供給客戶。

這樣一來，腳本的經驗獲得了總結和提煉，整個工具考慮得會比組件更加周到，效率有所提升。

工具服務化

有了工具能夠知足一些數據上的需求，可是因爲工具運行在本地沒法發揮公用的特性。

爲了讓工具被更加普遍的使用，因而將其以服務的方式發佈的雲端，此時業務人員能夠在有網絡的地方訪問到大數據工具，從而實現計算和分析工做，打破了地域的限制。

服務平臺化

既然有了服務上雲，那麼將這些服務作一些聚合的操做，讓相關聯的服務互相溝通產生「化學反應」，從而給用戶帶來更大的價值。

同時能夠將多個數據源都接入到平臺中，利用這些服務提供給客戶更高的價值。

此時，數據源，服務，客戶需求都是不一樣的，那麼經過平臺進行整合，從而顯示出更大的威力。

如今流行的 SAAS 系統就是一個很好的例子，採用多租用戶的方式，整合資源提供優質的數據服務。

平臺產品化

既然產生了一個大數據的平臺，整合了數據、服務、需求（客戶）各個方面的資源。

若是繼續發展就須要針對不一樣的用戶需求創建不一樣的業務場景，因爲行業不一樣、企業內部和市場環境不一樣，大數據的應用場景也千差萬別。

此時若是還提供統一的數據服務恐怕就不合時宜了，那麼此時須要針對行業以及細分領域進行業務服務的客製化。

針對一些行業底層的業務進行抽象和拆分，給用戶更多的客製化空間，針對不一樣的行業和使用場景退出不一樣的大數據產品，給到用戶。

圖 1：大數據平臺指導方針

從腳本到工具，服務、平臺、產品的轉化不只是大數據平臺發展的進程和步驟，一樣也是不一樣規模企業進行大數據平臺搭建的準繩。

爲何這麼說呢？技術始終是爲業務服務的，大數據平臺平臺也是如此，只要讓數據產生對企業有正向推進力就是正確的方向。

在最開始的時候，就能夠經過腳本的方式進行實驗和試錯，積累數據分析抽取的經驗，從而獲得一些對業務有價值的數據信息。

後面經過不斷迭代和試錯，將這些經驗從腳本→工具→服務→平臺→產品進行轉換。

這樣以終爲始，即減小了開發走的彎路，也提升了效率，最重要的是作出來的東西是有價值的，老闆的投入看得見。

每一個企業也能夠根據自身狀況選擇對應的切入點，不用作大而全的大數據平臺，作適合本身的就好。

大數據平臺的建設路徑

說了創建大數據平臺的基本思路之後，咱們知道針對不一樣的企業業務規模以及不一樣的發展階段，能夠選擇適合自身的大數據平臺建設思路。

那麼這裏就說說如何創建大數據平臺，怎樣的建設路徑可以幫助咱們落地大數據平臺，這裏分兩個方面討論。

針對業務場景的建設方式

正如上面提到的以終爲始的思路，針對企業面對的具體業務場景創建大數據平臺，讓數據針對具體的業務發揮做用，是最可以體現數據價值的。

例如：企業須要作拉新的線下活動，假設此次拉新 1 萬人。針對的羣體是學校的學生，那麼須要多少花多長時間，在多少個學校，擺出多少個展位才能達到效果。這些均可以經過企業系統中現有的數據進行分析，獲得結果。

所以這種方式的優勢是 :

• 和具體業務結合緊密，業務邏輯能夠根據企業業務情況進行定製，從而最大限度匹配需求。

• 技術開發人員與業務人員的交互效果和業務複雜度可控，甚至是無縫對接，基本屏蔽與業務無關的內容，確保易用性。業務人員定義的需求，使用者就是業務人員自己。 

• 專業對口，不考慮平臺通用性問題，也不用考慮與其餘平臺、應用的對接。總體平臺用時短，成型快，效果明顯。

這種方式的缺點是:

• 僅限於固定的業務場景拓展性差，對整個行業和系統缺少統籌考慮。

• 可能會作重複建設的工做，從長遠來看開發效率不高。 

通用組件的建設方式

「通用」顧名思義，將大數據平臺中通用的功能抽離出來，一般這些功能和具體的業務實現無關。

不管什麼業務場景都會用到的，例如：數據收集、數據導入、數據計算、數據搜索、數據展現等。

讓後在這些基礎功能/模塊的基礎上進行業務功能的封裝，其目的很明確，爲了更長遠的業務發展作準備。

此類建設方式不只關注當前業務的落地，更關係之後不一樣業務場景，不一樣行業的平臺擴展。

這種方式的優勢是 :

• 通用功能做爲大數據平臺的基礎，能夠針對不一樣業務場景進行拓展。

• 同功能避免重複造輪子，將技術功能和業務需求進行解耦。

• 對於架構設計考慮會更多，對行業的理解會更深，對使用場景的考慮會更多。

這種方式的缺點是：

• 架構設計難度大，考慮因素多，開發週期長。

• 架構中模塊關係負載，開發複雜度高。

• 對業務的抽象能力有要求，須要一個或者多個行業的豐富經驗，業務理解成本較高。

上面兩種基於業務和通用組件的建設方式各有利弊。在企業進行搭建大數據平臺的時候，須要根據自身的狀況進行抉擇。

若是是大數據剛剛起步的企業建議使用前一種方式，邊作邊摸索，邊總結邊重構，最終過分到第二種方式。

若是說企業在大數據平臺技術和業務上都有了深厚的積累，則能夠考慮從更高的視角，切入第二種方式。

大數據平臺的實現架構

說了大數據平臺的思路和實現路徑之後，再來從技術架構的角度來看看如何落地。

有的企業會借鑑其餘企業的成功案例，有的企業會根據自身狀況進行摸索。筆者在這裏給出的建議是依託方法論，結合企業實際狀況，參照行業經典案例進行構建。提及來有點虛，來看看具體的架構實現。

Lambda 架構

Lambda 架構（Lambda Architecture）是由 Twitter 工程師南森·馬茨（Nathan Marz）提出的大數據處理架構。

這一架構的提出基於馬茨在 BackType 和 Twitter 上的分佈式數據處理系統的經驗。

圖 2：Lambda 架構示意圖

如圖 2 所示，Lambda 共分爲三層，分別是批處理層（Batch Layer），速度處理層（Speed Layer），以及服務層（Serving Layer）。

下面來看看他們分別有什麼做用：

• 批處理層（Batch Layer），存儲管理主數據集和預先批處理計算好的視圖。這部分數據對及時性要求不高，會採起批處理的方式同步到主庫中，一般以定時任務的形式存在。

• 速度處理層（Speed Layer），會處理實時數據。因爲對數據及時性的要求，這部分數據會經過內存計算出結果，立刻提供給使用者，同時對於數據的準確性要求也不高。

  會經過批處理層入庫之後針對部分數據進行校驗，一般以 Storm 之類的應用的形式出現。

• 服務層（Serving Layer），數據進入到平臺之後，會進行存儲、同步、計算、分析等過程。可是，最終都是須要提供給用戶使用的。因爲用戶使用的方式和業務試圖的差別性，須要有一個服務對其進行權衡。

  服務層就應運而生了，它主要負責以服務的方式將數據提供給終端客戶，其形式有報表、儀表盤、API 接口等等。

若是說 Lambda 架構是方法論的話，那麼每一個企業會根據其創建本身的大數據平臺，從架構方面來看，都大同小異。

圖 3：大數據平臺技術架構

如圖 3 所示大數據平臺由上到下，可分爲：

• 數據採集

• 數據處理

• 數據輸出與展現

①數據採集

這裏包括從多個源頭收集數據信息，例如：瀏覽器、移動設備、服務器日誌文件。

再將這些信息數據和日誌等同步到大數據系統中，注意同步的過程須要考慮數據源和數據結構的差別。

同步會使用 Sqoop，日誌同步能夠選擇 Flume，行爲數據採集通過格式化轉換後經過 Kafka 等消息隊列進行傳遞。

這些數據在解決了數據源和數據異構之後，還須要進行數據清洗，特別是日誌和爬蟲數據，須要提取對業務有意義的數據進行存儲。

②數據處理

同步的數據存儲在 HDFS 之類的分佈式數據庫中。能夠經過 MapReduce、Hive、Spark 等計算任務讀取 HDFS 上的數據進行計算，再將計算結果寫入 HDFS 或者其餘庫。

這裏會根據數據的及時性分爲離線計算和實時計算，恰好和 Lambda 中的批量處理和速度處理相對應。

好比針對用戶的購物行爲進行關聯性數據挖掘，這時候數據量大、邏輯複雜，須要較長的運行時間，這類計算可使用離線計算來處理。

另外對處理時間敏感的計算，好比雙 11 每秒產生的訂單數，爲了及時地展現和監控，會採用流式計算。

一般用 Storm、Spark Steaming 等流式計算引擎完成，能夠在秒級甚至毫秒級內完成處理。

③數據輸出與展現

有了採集和處理就必定會面對輸出和展現。通常來講經過應用程序直接訪問數據庫來完成數據展現。

因爲對於業務、市場、管理的複雜性，對外須要展現客戶、競爭對手、產品的信息；對內須要根據操做層、管理層、決策層進行數據的聚合和彙總。對數據輸出和展現有必定要求。後面咱們會針對這部分進行展開說明。

因爲經過上面三個部分須要寫做完成採集、同步、存儲、計算、展現的工做，所以須要任務調度管理系統對其進行協調調用。

大數據平臺驅動業務運營

前面咱們說了如何在企業中落地大數據平臺，其中提到了以終爲始的概念，大數據平臺最終仍是須要爲業務運營系統提供正向推力的。有了大數據平臺就須要用好它，從中挖掘出更多的商業價值。

一般的狀況是這樣的，根據公司戰略目標以及公司目前的能力和外部的威脅和機會，公司會定義一個戰略思路。

這個是公司發展的綱領，圍繞這個戰略綱領業務部門和運營部門對其進行分析和拆分，生成業務需求，而後從這個業務須要推到出須要哪些關鍵要素（節點）。

再來看這些關鍵要素須要哪些數據爲其進行決策和支撐。最後，將這些要素變成業務需求提交給產品團隊進行分析，而後交由大數據技術團隊完成對應的功能。

圖 4：大數據平臺驅動業務運營

從思考過程來看是現有業務再纔有大數據平臺的功能，可是從執行層面來看。

爲了實現業務的功能業務人員是先要到大數據平臺上面獲取對應的信息，再才能實現業務決策和行爲。

例如上面提到的拉新的例子，業務人員爲了達到拉新 1 萬人的目的，會先到大數據平臺搜索。

針對產品的受衆，偏好、價格、溝通方式、市場、促銷等方面的問題，獲取對他們有價值的信息，例如：在哪些學校、針對什麼年級的學生、開闢多少展位完成此次活動。

所以在執行過程當中是大數據自己的價值在驅動業務前行的。思考和行動在方向上正好相反。

數據可視化平臺的實踐

既然要對企業的主要業務進行驅動和推進的做用，那麼就不得不提到大數據平臺的可視化以及展現功能了。

做爲可視化的大數據平臺須要從如下幾個方面進行實踐：

①用戶管理與權限

平臺的創建是爲用戶服務的，首先要標定服務的用戶。因爲用戶的多樣性，有的是企業內部客戶，有的是合做夥伴，還有終端用戶。

所以須要考慮：

• 用戶的權限和角色管理。

• 業務分組功能，針對業務分類、子分類對用戶進行劃分。

• 根據數據功能進行不一樣的安全等級管理，包括流程管理。

• 支持對原數據的檢索和瀏覽。

②多樣化的產品功能

因爲使用者的不一樣，致使面向的業務場景也會有所不一樣。那麼針對不一樣的業務場景就要展現不一樣的數據輸出：

• 提供多種圖表、報表功能。

• 針對圖表、報表提供自定義字段、過濾器功能。

• 增長組織視圖和我的視圖從不一樣角度審視數據。

③對其餘系統的集成功能

即使大數據平臺已經整合了企業級別的各類數據，擁有多種數據源，可是依舊存在短板。

若是針對其餘業務系統或者生產系統進行整合，經過功能、數據集成，讓數據產生關聯便會產生更大的能量：

• 集成企業、上下游、供應鏈 ERP 系統。

• 與行業數據、國家經濟指標進行結合。

• 與通用的郵件、通知、效率系統進行集成。

總結

從大數據平臺搭建思路做爲切入點，經過腳本、工具、服務、平臺、產品幾個遞進的階段，描述了企業在不一樣的發展階段能夠採起不一樣的思路。

若是說有了思路，那麼在執行的有兩種方式：業務場景和通用組件來進行。

落地到大數據平臺架構的時候，利用 Lambda 架構的方法論，進行數據採集、處理、展現。大數據平臺是爲業務創造價值，反過來經過平臺也能夠驅動業務的發展。

經過數據庫可視化平臺的實踐，讓業務人員經過多樣的數據功能和大數據平臺產生連接，最終產生商業價值。