跟所有的企業(yè)數(shù)據(jù)一樣，大數(shù)據(jù)唯有通過應(yīng)用投射給用戶才有用。對于設(shè)計或重新設(shè)計大數(shù)據(jù)應(yīng)用的架構(gòu)師來說，一個關(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)用的一個主要問題是與大數(shù)據(jù)容器本身進行交換的本質(zhì)。這一關(guān)系包括了傳統(tǒng)的哪一種抽象級別最適合應(yīng)用的問題，所需的事務(wù)及狀態(tài)控制以及必要的安全性。

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

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

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

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

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

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

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

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

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

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

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

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