【51CTO.com原創(chuàng)稿件】隨著業(yè)務(wù)的飛速發(fā)展，信息化作為業(yè)務(wù)的支撐，各個企業(yè)都建立了自己的信息化系統(tǒng)。

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

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

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

大數(shù)據(jù)平臺的搭建思路

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

腳本工具化

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

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

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

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

這樣一來，腳本的經(jīng)驗得到了總結(jié)和提煉，整個工具考慮得會比組件更加周到，效率有所提高。

工具服務(wù)化

有了工具可以滿足一些數(shù)據(jù)上的需求，但是由于工具運行在本地無法發(fā)揮公用的特性。

為了讓工具被更加廣泛的使用，于是將其以服務(wù)的方式發(fā)布的云端，此時業(yè)務(wù)人員可以在有網(wǎng)絡(luò)的地方訪問到大數(shù)據(jù)工具，從而實現(xiàn)計算和分析工作，打破了地域的限制。

服務(wù)平臺化

既然有了服務(wù)上云，那么將這些服務(wù)做一些聚合的操作，讓相關(guān)聯(lián)的服務(wù)互相溝通產(chǎn)生“化學反應(yīng)”，從而給用戶帶來更大的價值。

同時可以將多個數(shù)據(jù)源都接入到平臺中，利用這些服務(wù)提供給客戶更高的價值。

此時，數(shù)據(jù)源，服務(wù)，客戶需求都是不同的，那么通過平臺進行整合，從而顯示出更大的威力。

現(xiàn)在流行的 SAAS 系統(tǒng)就是一個很好的例子，采用多租用戶的方式，整合資源提供優(yōu)質(zhì)的數(shù)據(jù)服務(wù)。

平臺產(chǎn)品化

既然產(chǎn)生了一個大數(shù)據(jù)的平臺，整合了數(shù)據(jù)、服務(wù)、需求(客戶)各個方面的資源。

如果繼續(xù)發(fā)展就需要針對不同的用戶需求建立不同的業(yè)務(wù)場景，由于行業(yè)不同、企業(yè)內(nèi)部和市場環(huán)境不同，大數(shù)據(jù)的應(yīng)用場景也千差萬別。

此時如果還提供統(tǒng)一的數(shù)據(jù)服務(wù)恐怕就不合時宜了，那么此時需要針對行業(yè)以及細分領(lǐng)域進行業(yè)務(wù)服務(wù)的客制化。

針對一些行業(yè)底層的業(yè)務(wù)進行抽象和拆分，給用戶更多的客制化空間，針對不同的行業(yè)和使用場景退出不同的大數(shù)據(jù)產(chǎn)品，給到用戶。

圖 1：大數(shù)據(jù)平臺指導方針

從腳本到工具，服務(wù)、平臺、產(chǎn)品的轉(zhuǎn)化不僅是大數(shù)據(jù)平臺發(fā)展的進程和步驟，同樣也是不同規(guī)模企業(yè)進行大數(shù)據(jù)平臺搭建的準繩。

為什么這么說呢?技術(shù)始終是為業(yè)務(wù)服務(wù)的，大數(shù)據(jù)平臺平臺也是如此，只要讓數(shù)據(jù)產(chǎn)生對企業(yè)有正向推動力就是正確的方向。

在最開始的時候，就可以通過腳本的方式進行實驗和試錯，積累數(shù)據(jù)分析抽取的經(jīng)驗，從而得到一些對業(yè)務(wù)有價值的數(shù)據(jù)信息。

后面通過不斷迭代和試錯，將這些經(jīng)驗從腳本→工具→服務(wù)→平臺→產(chǎn)品進行轉(zhuǎn)換。

這樣以終為始，即減少了開發(fā)走的彎路，也提高了效率，最重要的是做出來的東西是有價值的，老板的投入看得見。

每個企業(yè)也可以根據(jù)自身情況選擇對應(yīng)的切入點，不用做大而全的大數(shù)據(jù)平臺，做適合自己的就好。

大數(shù)據(jù)平臺的建設(shè)路徑

說了建立大數(shù)據(jù)平臺的基本思路以后，我們知道針對不同的企業(yè)業(yè)務(wù)規(guī)模以及不同的發(fā)展階段，可以選擇適合自身的大數(shù)據(jù)平臺建設(shè)思路。

那么這里就說說如何建立大數(shù)據(jù)平臺，怎樣的建設(shè)路徑能夠幫助我們落地大數(shù)據(jù)平臺，這里分兩個方面討論。

針對業(yè)務(wù)場景的建設(shè)方式

正如上面提到的以終為始的思路，針對企業(yè)面對的具體業(yè)務(wù)場景建立大數(shù)據(jù)平臺，讓數(shù)據(jù)針對具體的業(yè)務(wù)發(fā)揮作用，是最能夠體現(xiàn)數(shù)據(jù)價值的。

例如：企業(yè)需要做拉新的線下活動，假設(shè)這次拉新 1 萬人。針對的群體是學校的學生，那么需要多少花多長時間，在多少個學校，擺出多少個展位才能達到效果。這些都可以通過企業(yè)系統(tǒng)中現(xiàn)有的數(shù)據(jù)進行分析，得到結(jié)果。

因此這種方式的優(yōu)點是 :

• 和具體業(yè)務(wù)結(jié)合緊密，業(yè)務(wù)邏輯可以根據(jù)企業(yè)業(yè)務(wù)狀況進行定制，從而最大限度匹配需求。
• 技術(shù)開發(fā)人員與業(yè)務(wù)人員的交互效果和業(yè)務(wù)復雜度可控，甚至是無縫對接，基本屏蔽與業(yè)務(wù)無關(guān)的內(nèi)容，確保易用性。業(yè)務(wù)人員定義的需求，使用者就是業(yè)務(wù)人員本身。
• 專業(yè)對口，不考慮平臺通用性問題，也不用考慮與其他平臺、應(yīng)用的對接。整體平臺用時短，成型快，效果明顯。

這種方式的缺點是:

• 僅限于固定的業(yè)務(wù)場景拓展性差，對整個行業(yè)和系統(tǒng)缺乏統(tǒng)籌考慮。
• 可能會做重復建設(shè)的工作，從長遠來看開發(fā)效率不高。

通用組件的建設(shè)方式

“通用”顧名思義，將大數(shù)據(jù)平臺中通用的功能抽離出來，通常這些功能和具體的業(yè)務(wù)實現(xiàn)無關(guān)。

無論什么業(yè)務(wù)場景都會用到的，例如：數(shù)據(jù)收集、數(shù)據(jù)導入、數(shù)據(jù)計算、數(shù)據(jù)搜索、數(shù)據(jù)展示等。

讓后在這些基礎(chǔ)功能/模塊的基礎(chǔ)上進行業(yè)務(wù)功能的封裝，其目的很明確，為了更長遠的業(yè)務(wù)發(fā)展做準備。

此類建設(shè)方式不僅關(guān)注當前業(yè)務(wù)的落地，更關(guān)系以后不同業(yè)務(wù)場景，不同行業(yè)的平臺擴展。

這種方式的優(yōu)點是 :

• 通用功能作為大數(shù)據(jù)平臺的基礎(chǔ)，可以針對不同業(yè)務(wù)場景進行拓展。
• 同功能避免重復造輪子，將技術(shù)功能和業(yè)務(wù)需求進行解耦。
• 對于架構(gòu)設(shè)計考慮會更多，對行業(yè)的理解會更深，對使用場景的考慮會更多。

這種方式的缺點是：

• 架構(gòu)設(shè)計難度大，考慮因素多，開發(fā)周期長。
• 架構(gòu)中模塊關(guān)系負載，開發(fā)復雜度高。
• 對業(yè)務(wù)的抽象能力有要求，需要一個或者多個行業(yè)的豐富經(jīng)驗，業(yè)務(wù)理解成本較高。

上面兩種基于業(yè)務(wù)和通用組件的建設(shè)方式各有利弊。在企業(yè)進行搭建大數(shù)據(jù)平臺的時候，需要根據(jù)自身的情況進行抉擇。

如果是大數(shù)據(jù)剛剛起步的企業(yè)建議使用前一種方式，邊做邊摸索，邊總結(jié)邊重構(gòu)，最終過度到第二種方式。

如果說企業(yè)在大數(shù)據(jù)平臺技術(shù)和業(yè)務(wù)上都有了深厚的積累，則可以考慮從更高的視角，切入第二種方式。

大數(shù)據(jù)平臺的實現(xiàn)架構(gòu)

說了大數(shù)據(jù)平臺的思路和實現(xiàn)路徑以后，再來從技術(shù)架構(gòu)的角度來看看如何落地。

有的企業(yè)會借鑒其他企業(yè)的成功案例，有的企業(yè)會根據(jù)自身情況進行摸索。筆者在這里給出的建議是依托方法論，結(jié)合企業(yè)實際情況，參照行業(yè)經(jīng)典案例進行構(gòu)建。說起來有點虛，來看看具體的架構(gòu)實現(xiàn)。

Lambda 架構(gòu)

Lambda 架構(gòu)(Lambda Architecture)是由 Twitter 工程師南森·馬茨(Nathan Marz)提出的大數(shù)據(jù)處理架構(gòu)。

這一架構(gòu)的提出基于馬茨在 BackType 和 Twitter 上的分布式數(shù)據(jù)處理系統(tǒng)的經(jīng)驗。

圖 2：Lambda 架構(gòu)示意圖

如圖 2 所示，Lambda 共分為三層，分別是批處理層(Batch Layer)，速度處理層(Speed Layer)，以及服務(wù)層(Serving Layer)。

下面來看看他們分別有什么作用：

• 批處理層(Batch Layer)，存儲管理主數(shù)據(jù)集和預先批處理計算好的視圖。這部分數(shù)據(jù)對及時性要求不高，會采取批處理的方式同步到主庫中，通常以定時任務(wù)的形式存在。
• 速度處理層(Speed Layer)，會處理實時數(shù)據(jù)。由于對數(shù)據(jù)及時性的要求，這部分數(shù)據(jù)會通過內(nèi)存計算出結(jié)果，馬上提供給使用者，同時對于數(shù)據(jù)的準確性要求也不高。

會通過批處理層入庫以后針對部分數(shù)據(jù)進行校驗，通常以 Storm 之類的應(yīng)用的形式出現(xiàn)。

• 服務(wù)層(Serving Layer)，數(shù)據(jù)進入到平臺以后，會進行存儲、同步、計算、分析等過程。但是，最終都是需要提供給用戶使用的。由于用戶使用的方式和業(yè)務(wù)試圖的差異性，需要有一個服務(wù)對其進行權(quán)衡。

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

如果說 Lambda 架構(gòu)是方法論的話，那么每個企業(yè)會根據(jù)其建立自己的大數(shù)據(jù)平臺，從架構(gòu)方面來看，都大同小異。

 圖 3：大數(shù)據(jù)平臺技術(shù)架構(gòu)

如圖 3 所示大數(shù)據(jù)平臺由上到下，可分為：

• 數(shù)據(jù)采集
• 數(shù)據(jù)處理
• 數(shù)據(jù)輸出與展示

①數(shù)據(jù)采集

這里包括從多個源頭收集數(shù)據(jù)信息，例如：瀏覽器、移動設(shè)備、服務(wù)器日志文件。

再將這些信息數(shù)據(jù)和日志等同步到大數(shù)據(jù)系統(tǒng)中，注意同步的過程需要考慮數(shù)據(jù)源和數(shù)據(jù)結(jié)構(gòu)的差異。

同步會使用 Sqoop，日志同步可以選擇 Flume，行為數(shù)據(jù)采集經(jīng)過格式化轉(zhuǎn)換后通過 Kafka 等消息隊列進行傳遞。

這些數(shù)據(jù)在解決了數(shù)據(jù)源和數(shù)據(jù)異構(gòu)以后，還需要進行數(shù)據(jù)清洗，特別是日志和爬蟲數(shù)據(jù)，需要提取對業(yè)務(wù)有意義的數(shù)據(jù)進行存儲。

②數(shù)據(jù)處理

同步的數(shù)據(jù)存儲在 HDFS 之類的分布式數(shù)據(jù)庫中?？梢酝ㄟ^ MapReduce、Hive、Spark 等計算任務(wù)讀取 HDFS 上的數(shù)據(jù)進行計算，再將計算結(jié)果寫入 HDFS 或者其他庫。

這里會根據(jù)數(shù)據(jù)的及時性分為離線計算和實時計算，剛好和 Lambda 中的批量處理和速度處理相對應(yīng)。

比如針對用戶的購物行為進行關(guān)聯(lián)性數(shù)據(jù)挖掘，這時候數(shù)據(jù)量大、邏輯復雜，需要較長的運行時間，這類計算可以使用離線計算來處理。

另外對處理時間敏感的計算，比如雙 11 每秒產(chǎn)生的訂單數(shù)，為了及時地展示和監(jiān)控，會采用流式計算。

通常用 Storm、Spark Steaming 等流式計算引擎完成，可以在秒級甚至毫秒級內(nèi)完成處理。

③數(shù)據(jù)輸出與展示

有了采集和處理就一定會面對輸出和展示。一般來說通過應(yīng)用程序直接訪問數(shù)據(jù)庫來完成數(shù)據(jù)展示。

由于對于業(yè)務(wù)、市場、管理的復雜性，對外需要展示客戶、競爭對手、產(chǎn)品的信息;對內(nèi)需要根據(jù)操作層、管理層、決策層進行數(shù)據(jù)的聚合和匯總。對數(shù)據(jù)輸出和展示有一定要求。后面我們會針對這部分進行展開說明。

由于通過上面三個部分需要寫作完成采集、同步、存儲、計算、展示的工作，因此需要任務(wù)調(diào)度管理系統(tǒng)對其進行協(xié)調(diào)調(diào)用。

大數(shù)據(jù)平臺驅(qū)動業(yè)務(wù)運營

前面我們說了如何在企業(yè)中落地大數(shù)據(jù)平臺，其中提到了以終為始的概念，大數(shù)據(jù)平臺最終還是需要為業(yè)務(wù)運營系統(tǒng)提供正向推力的。有了大數(shù)據(jù)平臺就需要用好它，從中挖掘出更多的商業(yè)價值。

通常的情況是這樣的，根據(jù)公司戰(zhàn)略目標以及公司目前的能力和外部的威脅和機會，公司會定義一個戰(zhàn)略思路。

這個是公司發(fā)展的綱領(lǐng)，圍繞這個戰(zhàn)略綱領(lǐng)業(yè)務(wù)部門和運營部門對其進行分析和拆分，生成業(yè)務(wù)需求，然后從這個業(yè)務(wù)需要推到出需要哪些關(guān)鍵要素(節(jié)點)。

再來看這些關(guān)鍵要素需要哪些數(shù)據(jù)為其進行決策和支撐。最后，將這些要素變成業(yè)務(wù)需求提交給產(chǎn)品團隊進行分析，然后交由大數(shù)據(jù)技術(shù)團隊完成對應(yīng)的功能。

 圖 4：大數(shù)據(jù)平臺驅(qū)動業(yè)務(wù)運營

從思考過程來看是現(xiàn)有業(yè)務(wù)再才有大數(shù)據(jù)平臺的功能，但是從執(zhí)行層面來看。

為了實現(xiàn)業(yè)務(wù)的功能業(yè)務(wù)人員是先要到大數(shù)據(jù)平臺上面獲取對應(yīng)的信息，再才能實現(xiàn)業(yè)務(wù)決策和行為。

例如上面提到的拉新的例子，業(yè)務(wù)人員為了達到拉新 1 萬人的目的，會先到大數(shù)據(jù)平臺搜索。

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

因此在執(zhí)行過程中是大數(shù)據(jù)本身的價值在驅(qū)動業(yè)務(wù)前行的。思考和行動在方向上正好相反。

數(shù)據(jù)可視化平臺的實踐

既然要對企業(yè)的主要業(yè)務(wù)進行驅(qū)動和推動的作用，那么就不得不提到大數(shù)據(jù)平臺的可視化以及展示功能了。

作為可視化的大數(shù)據(jù)平臺需要從以下幾個方面進行實踐：

①用戶管理與權(quán)限

平臺的建立是為用戶服務(wù)的，首先要標定服務(wù)的用戶。由于用戶的多樣性，有的是企業(yè)內(nèi)部客戶，有的是合作伙伴，還有終端用戶。

因此需要考慮：

• 用戶的權(quán)限和角色管理。
• 業(yè)務(wù)分組功能，針對業(yè)務(wù)分類、子分類對用戶進行劃分。
• 根據(jù)數(shù)據(jù)功能進行不同的安全等級管理，包括流程管理。
• 支持對原數(shù)據(jù)的檢索和瀏覽。

②多樣化的產(chǎn)品功能

由于使用者的不同，導致面向的業(yè)務(wù)場景也會有所不同。那么針對不同的業(yè)務(wù)場景就要展示不同的數(shù)據(jù)輸出：

• 提供多種圖表、報表功能。
• 針對圖表、報表提供自定義字段、過濾器功能。
• 增加組織視圖和個人視圖從不同角度審視數(shù)據(jù)。

③對其他系統(tǒng)的集成功能

即便大數(shù)據(jù)平臺已經(jīng)整合了企業(yè)級別的各種數(shù)據(jù)，擁有多種數(shù)據(jù)源，但是依舊存在短板。

如果針對其他業(yè)務(wù)系統(tǒng)或者生產(chǎn)系統(tǒng)進行整合，通過功能、數(shù)據(jù)集成，讓數(shù)據(jù)產(chǎn)生關(guān)聯(lián)便會產(chǎn)生更大的能量：

• 集成企業(yè)、上下游、供應(yīng)鏈 ERP 系統(tǒng)。
• 與行業(yè)數(shù)據(jù)、國家經(jīng)濟指標進行結(jié)合。
• 與通用的郵件、通知、效率系統(tǒng)進行集成。

總結(jié)

從大數(shù)據(jù)平臺搭建思路作為切入點，通過腳本、工具、服務(wù)、平臺、產(chǎn)品幾個遞進的階段，描述了企業(yè)在不同的發(fā)展階段可以采取不同的思路。

如果說有了思路，那么在執(zhí)行的有兩種方式：業(yè)務(wù)場景和通用組件來進行。

落地到大數(shù)據(jù)平臺架構(gòu)的時候，利用 Lambda 架構(gòu)的方法論，進行數(shù)據(jù)采集、處理、展示。大數(shù)據(jù)平臺是為業(yè)務(wù)創(chuàng)造價值，反過來通過平臺也可以驅(qū)動業(yè)務(wù)的發(fā)展。

通過數(shù)據(jù)庫可視化平臺的實踐，讓業(yè)務(wù)人員通過多樣的數(shù)據(jù)功能和大數(shù)據(jù)平臺產(chǎn)生鏈接，最終產(chǎn)生商業(yè)價值。

作者：崔皓

簡介：十六年開發(fā)和架構(gòu)經(jīng)驗，曾擔任過惠普武漢交付中心技術(shù)專家，需求分析師，項目經(jīng)理，后在創(chuàng)業(yè)公司擔任技術(shù)/產(chǎn)品經(jīng)理。善于學習，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】