跟所有的企業(yè)數(shù)據(jù)一樣，大數(shù)據(jù)唯有通過應(yīng)用投射給用戶才有用。對(duì)于設(shè)計(jì)或重新設(shè)計(jì)大數(shù)據(jù)應(yīng)用的架構(gòu)師來說，一個(gè)關(guān)鍵問題是究竟是用面向?qū)ο蠹軜?gòu)（SOA）還是RESTful API將大數(shù)據(jù)組件及服務(wù)與應(yīng)用其他部分連接。從大數(shù)據(jù)產(chǎn)品要暴露的接口開始，然后在應(yīng)用這一側(cè)定義大數(shù)據(jù)接口。接下來，考慮安全和治理，最后，無論選擇什么樣的API都要小心地將管理和訪問服務(wù)分隔開來。

做大數(shù)據(jù)應(yīng)用的一個(gè)主要問題是與大數(shù)據(jù)容器本身進(jìn)行交換的本質(zhì)。這一關(guān)系包括了傳統(tǒng)的哪一種抽象級(jí)別最適合應(yīng)用的問題，所需的事務(wù)及狀態(tài)控制以及必要的安全性。

大數(shù)據(jù)工具往往混合了API,部分RESTful以及部分類似SOA式的API.這種混編會(huì)導(dǎo)致一種混亂的景象，除非大數(shù)據(jù)接口被抽象為服務(wù)或資源，而不是直接暴露給應(yīng)用。這樣的話，只有一個(gè)組件需要做出變化-大數(shù)據(jù)適配器流程-如果大數(shù)據(jù)工具徹底改變了的話。

大數(shù)據(jù)應(yīng)用，什么時(shí)候用SOA,什么時(shí)候用REST

在大數(shù)據(jù)適配器與其他組件之間的接口處，看看大數(shù)據(jù)是如何被用來為選擇API進(jìn)行指導(dǎo)的。SOA適合在向大數(shù)據(jù)容器這樣的東西發(fā)布一組與應(yīng)用綁定的特定能力的情況。這一模型可以是高度抽象的，意味著應(yīng)用使用大數(shù)據(jù)可以與數(shù)據(jù)本身的技術(shù)和可分布性完全隔絕。

應(yīng)用預(yù)期會(huì)在特定分析或規(guī)約流程的結(jié)果方面更多使用大數(shù)據(jù)，在這種情況下SOA是有意義的。如果應(yīng)用需要知道作為資源集的大數(shù)據(jù)的情況，又不想把它抽象化為高層服務(wù)，那么RESTful接口也許會(huì)更合適。

在這種高度上進(jìn)行應(yīng)用審查，至關(guān)重要的一點(diǎn)是不要掉進(jìn)這樣一個(gè)陷阱，即假定大數(shù)據(jù)應(yīng)用應(yīng)該用Apache的WebHDFS這類現(xiàn)有的RESTful API來開發(fā)。通常而言，最好的辦法是將大數(shù)據(jù)流程或設(shè)施與應(yīng)用通過現(xiàn)有的接口連接起來，而不是那些用來直接進(jìn)行文件系統(tǒng)級(jí)操作的。后一種類型的接口會(huì)產(chǎn)生可觀的增量式開發(fā)工作，如果是在這個(gè)層面來寫，要想將應(yīng)用從一個(gè)大數(shù)據(jù)服務(wù)或設(shè)施遷移至另一個(gè)幾乎是不可能的。

上下文、狀態(tài)及事務(wù)性行為

事務(wù)就是工作的上下文，一個(gè)從業(yè)務(wù)角度產(chǎn)生流程步驟的邏輯序列。在確定是SOA還是REST最適合大數(shù)據(jù)應(yīng)用時(shí)，第一個(gè)問題是事務(wù)性工作是否包含在大數(shù)據(jù)組件之內(nèi)，或者大數(shù)據(jù)引用在事務(wù)中是否跨多個(gè)組件傳播。第一種情況下，RESTful接口可輕易部署。而在第二種情況下，要想用REST,就得需要某種事務(wù)狀態(tài)控制的機(jī)制。而SOA這兩種情況都很容易處理。

在進(jìn)行大數(shù)據(jù)的SOA和REST決策時(shí)，安全和治理也是很重要的點(diǎn)。SOA的安全、訪問日志及控制是顯式的，且與用戶目錄和應(yīng)用控制是高度集成在一起的。而REST的安全和訪問控制機(jī)制則可能是在外部應(yīng)用的。這有可能是將大數(shù)據(jù)訪問包裝進(jìn)SOA里面的一個(gè)有力的理由，即便在REST使用是在大數(shù)據(jù)產(chǎn)品級(jí)這種層次上也是如此。如果采用RESTful模型的話，必須明確如何建立起能通過正式治理評(píng)審的大數(shù)據(jù)安全。大多數(shù)用戶會(huì)吸收VPN或SSL級(jí)的安全，但還會(huì)通過網(wǎng)絡(luò)級(jí)的應(yīng)用訪問安全來增強(qiáng)。

最后，小心不要暴露過度。大多數(shù)情況下，大數(shù)據(jù)服務(wù)可分為兩類-實(shí)際的數(shù)據(jù)訪問服務(wù)以及數(shù)據(jù)服務(wù)平臺(tái)管理和控制服務(wù)。所有的現(xiàn)代大數(shù)據(jù)架構(gòu)都支持這兩種，但因?yàn)槠脚_(tái)管理和控制往往被視為是技術(shù)過程而非應(yīng)用過程，其支持往往牽涉到通過簡單的REST接口進(jìn)行低級(jí)的功能訪問。大數(shù)據(jù)管理服務(wù)應(yīng)該盡量少直接暴露給應(yīng)用開發(fā)者或用戶，因?yàn)闀?huì)導(dǎo)致相當(dāng)重大錯(cuò)誤的風(fēng)險(xiǎn)。

在需要平臺(tái)管理工具為大數(shù)據(jù)使用進(jìn)行準(zhǔn)備時(shí)，最好是將這些功能在大數(shù)據(jù)適配器組件內(nèi)實(shí)現(xiàn)，為應(yīng)用開發(fā)者建立一個(gè)更容易的接口來使用，并確保在大數(shù)據(jù)分析開始之前永遠(yuǎn)都先經(jīng)歷必要的平臺(tái)管理步驟。

為架構(gòu)師和大數(shù)據(jù)專家預(yù)留對(duì)平臺(tái)管理API的訪問將是必要的，這樣能讓他們?cè)谌粘５臄?shù)據(jù)倉儲(chǔ)維護(hù)任務(wù)中用到。部分用戶建議對(duì)低級(jí)的平臺(tái)管理API進(jìn)行抽象，這樣的話哪怕是平臺(tái)管理實(shí)踐也能跨多個(gè)實(shí)現(xiàn)應(yīng)用，但經(jīng)驗(yàn)告訴我們，要想在這種層次上建立有用的通用實(shí)踐是很困難的。最好的做法有可能是就讓專家和架構(gòu)師在需要時(shí)采用特定的平臺(tái)管理API就行了。

一旦大數(shù)據(jù)SOA/REST評(píng)審?fù)瓿?，永遠(yuǎn)要記得把這兩種截然不同的API風(fēng)格的結(jié)果與一般政策對(duì)照一下。一種工具被創(chuàng)建出來時(shí)，需要的絕不僅僅是確立的API基線支持，還包括不同的實(shí)踐，要預(yù)料到更高層面的風(fēng)險(xiǎn)。確保在進(jìn)行下去之前對(duì)風(fēng)險(xiǎn)進(jìn)行了評(píng)估。