【51CTO.com原創稿件】隨著業務的飛速發展，信息化作為業務的支撐，各個企業都建立了自己的信息化系統。

在業務增漲過程中，每個企業不知不覺積累積累了一些數據。無論數據是多是少，企業都希望讓“數據說話”，通過對數據的采集、存儲、分析、計算最終提供對業務有價值信息。

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

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

大數據平臺的搭建思路

實際上做任何事情都要有目標，然后根據這個目標根據自身的條件和外部的情況制定一個思路，這個思路也可以理解為實現目標的路徑。那么大數據的平臺搭建也不例外。

腳本工具化

在數據收集，存儲、分析的初期，通常來說程序員都是根據業務需求，通過一些腳本來完成數據收集，分析的工作。

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

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

因此，我們會講這些腳本組件包裝成一個個工具，用命令行或者 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 架構的方法論，進行數據采集、處理、展示。大數據平臺是為業務創造價值，反過來通過平臺也可以驅動業務的發展。

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

作者：崔皓

簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，后在創業公司擔任技術/產品經理。善于學習，樂于分享。目前專注于技術架構與研發管理。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】