跟所有的企業數據一樣，大數據唯有通過應用投射給用戶才有用。對于設計或重新設計大數據應用的架構師來說，一個關鍵問題是究竟是用面向對象架構（SOA）還是RESTful API將大數據組件及服務與應用其他部分連接。從大數據產品要暴露的接口開始，然后在應用這一側定義大數據接口。接下來，考慮安全和治理，最后，無論選擇什么樣的API都要小心地將管理和訪問服務分隔開來。

做大數據應用的一個主要問題是與大數據容器本身進行交換的本質。這一關系包括了傳統的哪一種抽象級別最適合應用的問題，所需的事務及狀態控制以及必要的安全性。

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

大數據應用，什么時候用SOA,什么時候用REST

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

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

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

上下文、狀態及事務性行為

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

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

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

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

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

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