學習總結 - swift介面卡 為 Hadoop 的儲存層增加對 OpenStack Swift 的支援
雖然文件內所涉及的版本有點舊，但內容很精彩，值得推薦
背景
在 Hadoop 中有一個抽象檔案系統的概念，它有多個不同的子類實現，由 DistributedFileSystem 類代表的 HDFS 便是其中之一。在 Hadoop 的 1.x 版本中，HDFS 存在 NameNode 單點故障，並且它是為大檔案的流式資料訪問而設計的，不適合隨機讀寫大量的小檔案。本文將探討通過使用其他的儲存系統，例如 OpenStack Swift 物件儲存，作為 Hadoop 的底層儲存，為 Hadoop 的儲存層增加對 OpenStack Swift 的支援，並給出測試結果，最終達到功能驗證（Functional POC）的目標。值得一提的是，為 Hadoop 增加對 OpenStack Swift 的支援並非要取代 HDFS，而是為使用 Hadoop MapReduce 及其相關的工具直接分析儲存在 Swift 中的資料提供了方便；本文作為一個階段性的嘗試，目前尚未考慮資料區域性性（Data Locality），這部分將作為未來的工作。另外，Hadoop 2.x 提供了高可用 HDFS 的解決辦法，不在本文的討論範圍之內。
本文面向的讀者為對 Hadoop 和 OpenStack Swift 感興趣的軟體開發者和管理員，並假設讀者已經對它們有基本的瞭解。本文使用的 Hadoop 的版本為 1.0.4，OpenStack Swift 的版本為 1.7.4，Swift Java Client API 的版本為 1.8，用於認證的 Swauth 的版本為 1.0.4。
Hadoop 與 OpenStack Swift 物件儲存的整合
設想以下情形，如果已經在 Swift 中儲存了大量資料，但是想要使用 Hadoop 對這些資料進行分析，挖掘出有用的資訊。此時可能的做法是，先將 Swift 叢集中的資料匯出到中間伺服器，再將這些資料匯入到 HDFS 中，才能通過執行 MapReduce 作業來分析這些資料。如果資料量非常大，那麼整個匯入資料的過程會很長，並且要使用更多的儲存空間。
如果能將 Hadoop 和 OpenStack Swift 進行整合，使得 Hadoop 能夠直接訪問 Swift 物件儲存，並能執行 MapReduce 作業來分析儲存在 Swift 中的資料，那麼將提高效率，減少硬體成本。
Hadoop 抽象檔案系統 API
org.apache.hadoop.fs.FileSystem 是 Hadoop 中的一個通用檔案系統的抽象基類，它抽象出了檔案系統對檔案和目錄的各種操作，例如：建立、拷貝、移動、重新命名、刪除檔案和目錄、讀寫檔案、讀寫檔案元資料等基本的檔案系統操作，以及檔案系統的一些其他通用操作。FileSystem 抽象類中的主要方法和含義如表 1 所示。
表 1. FileSystem 抽象類的主要方法和含義
| 方法簽名 | 含義 |
|---|---|
| void initialize(URI, Configuration) | 根據配置檔案對檔案系統進行初始化操作 |
| FSDataInputStream open(Path, int) | 開啟指定路徑的檔案，並得到輸入流 |
| FSDataOutputStream create(Path, FsPermission, boolean, int, short, long, Progressable) | 建立指定路徑的檔案，並得到輸出流 |
| boolean rename(Path, Path) | 重新命名檔案或目錄 |
| boolean delete(Path, boolean) | 刪除檔案或目錄 |
| boolean mkdirs(Path, FsPermission) | 建立目錄 |
| FileStatus getFileStatus(Path) | 獲得檔案或目錄的元資料 |
| FileStatus[] listStatus(Path) | 獲得某個目錄下的所有檔案或目錄的元資料 |
| URI getUri() | 獲得該檔案系統的 URI |
| Path getWorkingDirectory() | 獲得當前工作目錄 |
| void setWorkingDirectory(Path) | 設定當前工作目錄 |
FileSystem 抽象類有多個不同的子類實現，包括：本地檔案系統實現、分散式檔案系統實現、記憶體檔案系統實現、FTP 檔案系統實現、非 Apache 提供的第三方儲存系統實現，以及通過 HTTP 和 HTTPS 協議訪問分散式檔案系統的實現。其中，LocalFileSystem 類代表了進行客戶端校驗和的本地檔案系統，在未對 Hadoop 進行配置時是預設的檔案系統。分散式檔案系統實現是 DistributedFileSystem 類，即 HDFS，用來儲存海量資料，典型的應用是儲存大小超過了單臺機器的磁碟總容量的大資料集。第三方儲存系統實現是由非 Apache 的其他廠商提供的開源實現，如 S3FileSystem 和 NativeS3FileSystem 類，它們是使用 Amazon S3 作為底層儲存的檔案系統實現。
通過閱讀 Hadoop 的檔案系統相關的原始碼和 Javadoc，並藉助於工具，可以分析出 FileSystem 抽象類的各個抽象方法的含義和用法，以及 FileSystem API 中各類之間的繼承、依賴關係。org.apache.hadoop.fs 包中包括了 Hadoop 檔案系統相關的介面和類，如檔案輸入流 FSDataInputStream 類和輸出流 FSDataOutputStream 類，檔案元資料 FileStatus 類，所有的輸入/輸出流類都分別和 FSDataInputStream 類和 FSDataOutputStream 類是組合關係，所有的檔案系統子類實現均繼承自 FileSystem 抽象類。
圖 1. Hadoop FileSystem API 類圖
以 S3FileSystem 為例，它使用的底層儲存系統是 Amazon S3，繼承了 FileSystem 抽象類，是它的一個具體實現，並實現了針對 Amazon S3 的輸入/輸出流。使用者可以在 Hadoop 的配置檔案 core-site.xml 中為 fs.default.name 屬性指定 Amazon S3 儲存系統的 URI，就可以使 Hadoop 得以訪問 Amazon S3，並在其上執行 MapReduce 作業。
Swift 的 Java 客戶端 API
Swift 通過 HTTP 協議對外提供儲存服務，有一個 REST 風格的 API。Swift 本身是用 Python 語言實現的，但是也提供了多種程式語言的客戶端 API，例如：Python、Java、PHP、C#、Ruby 等。這些客戶端 API 都通過發起 HTTP 請求和接收 HTTP 響應來與 Swift 叢集的代理節點進行互動，Swift 客戶端 API 在 REST API 之上提供了更高層次的對容器和物件的操作，使得程式設計師編寫訪問 Swift 的程式變得更為方便。
Swift 的 Java 客戶端 API 名叫 java-cloudfiles，也是一個開源專案。其中的 FilesClient 類提供了對 Swift 物件儲存的各種操作，包括：登入 Swift、建立和刪除 Account、容器、物件，獲得 Account、容器、物件的元資料，以及讀寫物件的方法。其他相關的類包括：FilesContainer、FilesObject、FilesContainerInfo、FilesObjectMetaData 等，它們分別代表 Swift 中的容器和物件以及對應的元資料，如容器包含的物件個數，物件的大小、修改時間等。版本號為 1.8 的 java-cloudfiles 能夠和開源版本的 Swift 相容。Filesclient 類中主要的方法和含義如表 2 所示。
表 2. FilesClient 類中的主要方法和含義
| 方法簽名 | 含義 |
|---|---|
| FilesClient(String, String, String, String, int) | 構造方法，引數包括代理節點的 URL、account、username、password，timeout |
| boolean login() | 登入 Swift |
| void createContainer(String) | 建立容器 |
| boolean deleteContainer(String) | 刪除容器 |
| boolean containerExists (String) | 判斷容器是否存在 |
| boolean storeObject(String, byte[], String, String, Map<String,String>) | 把位元組陣列中的值儲存到物件中，把元資料儲存到擴充套件屬性中 |
| byte[] getObject (String, String) | 從 Swift 獲取物件內容並存入位元組陣列 |
| List<FilesContainer> listContainers() | 列出某個賬戶包含的所有容器 |
| List<FilesObject> listObjects(String) | 列出某個容器包含的所有物件 |
| FilesContainerInfo getContainerInfo (String) | 獲取容器的元資料 |
| FilesObjectMetaData getObjectMetaData (String, String) | 獲取物件的元資料 |
綜上所述，Hadoop FileSystem API 能夠接受新的檔案系統實現的機制，以及能夠用 Java 語言編寫應用程式與 Swift 進行互動操作，這兩點使得擴充套件 Hadoop 抽象檔案系統是可行的。
Swift 介面卡的設計
由上述內容得知，要擴充套件 Hadoop 的抽象檔案系統，需要做以下兩項工作：繼承並實現 FileSystem 抽象類，並在實現類中使用 Swift 的 Java 客戶端 API 以進行各種檔案操作。因此，擴充套件系統的設計應遵循軟體設計模式當中的物件介面卡模式（Adapter Pattern）。物件介面卡模式的作用是進行介面適配，就是將一個類的介面轉換成客戶程式希望的另一個介面，使得原本由於介面不相容而不能一起工作的那些類可以一起工作。
在擴充套件系統中，Swift 介面卡呼叫 Swift 的 Java 客戶端 API，實現了對 Swift 物件儲存的操作，Hadoop MapReduce API 呼叫 Hadoop FileSystem API，對於 MapReduce 來說，底層的 HDFS 和 Swift 都是透明的。與 HDFS 相比，Swift 介面卡所在的 API 層次結構如圖 2 所示。
圖 2. API 層次結構圖
Swift 介面卡的詳細設計如下：SwiftAdapter 是一個介面卡類，FilesClient 是一個被適配類，SwiftAdapter 類繼承了 FileSystem 抽象類，它和 FilesClient 類是組合關係，包含了 FilesClient 類的一個引用。其中，FilesClient 類是 Swift 的 Java 客戶端 API 中的一個類。Swift 輸入/輸出流如下：SwiftInputStream 是針對 Swift 的輸入流，SwiftByteArrayInputStream 是一個包含位元組陣列快取的輸入流，SwiftInputStream 包含了 SwiftByteArrayInputStream 的一個引用，SwiftOutputStream 是針對 Swift 的輸出流，它們繼承了相應的檔案系統輸入/輸出流基類或介面，輸入流具有 seek 等功能，輸出流具有 flush 等功能。Swift 介面卡中的類圖如圖 3 所示，Swift 介面卡中類的詳細關係如表 3 所示。
圖 3. Swift 介面卡類圖
表 3. Swift 介面卡中類的詳細關係
| 類名 | 父介面/父類 | 依賴類 |
|---|---|---|
| SwiftAdapter | FileSystem | FilesClient, SwiftInputStream, SwiftOutputStream 等 |
| SwiftInputStream | FSInputStream | FilesClient, SwiftByteArrayInputStream |
| SwiftByteArrayInputStream | ByteArrayInputStream, Seekable | |
| SwiftByteOutputStream | ByteArrayOutputStream | FilesClient |
| SwiftFileStatus（SwiftAdapter 的內部類） | FileStatus |
Swift 介面卡的實現
實現細節
在與 Swift 進行互動之前需要首先登入 Swift，因此要使用 Swift 中預先建立的某個賬戶、使用者名稱和密碼，實現的細節如下。
呼叫 Swift 的 Java 客戶端 API，實現針對 Swift 的輸入/輸出流。
在 Hadoop 中，所有的輸入流類都需要繼承並實現 FSInputStream 抽象類，重點是實現 read 方法和 seek 方法。read 方法從輸入流中讀取下一個位元組，是輸入流類最基本的方法，seek 方法設定輸入流的讀取位置，如果使用一個位元組陣列作為緩衝則能實現隨機定位到某一位元組。SwiftByteArrayInputStream 類繼承了 ByteArrayInputStream 類和 Seekable 介面，它使用了一個位元組陣列作為緩衝。SwiftInputStream 類繼承 FSInputStream 抽象類，幷包含 SwiftByteArrayInputStream 類的一個引用，它呼叫 Swift 的 Java 客戶端 API，將 Swift 中的物件讀入到位元組陣列的緩衝。通過這樣的實現，針對 Swift 的輸入流類 SwiftInputStream 就具有了 read 和 seek 這些輸入流的基本操作。
在 Hadoop 中，輸出流類只需要是 OutputStream 抽象類的子類即可，重點是實現 write 方法和 flush 方法，它可以選擇是否實現 Syncable 介面的 sync 方法，sync 方法使得緩衝的資料與底層儲存裝置同步。write 方法向輸出流中寫入一個位元組，是輸出流類最基本的方法。SwiftOutputStream 類繼承了 OutputStream 抽象類的子類 ByteArrayOutputStream，在 flush 方法中呼叫 Swift 的 Java 客戶端 API，將緩衝中的所有位元組儲存到 Swift 中的物件。通過這樣的實現，針對 Swift 的輸出流類 SwiftOutputStream 就具有了 write 和 flush 這些輸出流的基本操作。
呼叫 Swift 的 Java 客戶端 API，實現 SwiftAdapter 的各種檔案操作。
實現的操作包括：開啟檔案並返回輸入流，建立檔案並返回輸出流，刪除路徑，判斷路徑是否存在，獲得路徑的元資料，獲得檔案系統的 URI，獲得工作目錄，建立目錄等等。目錄對應 Swift 中的容器，檔案對應 Swift 中的物件。在實現的過程中，有幾個問題需要進行特殊處理。
首先，由於在 Swift 物件儲存中，名稱空間是扁平的，沒有目錄層次結構，所以在路徑上需要進行特殊處理，具體的做法是允許檔名稱包含斜槓（/）。在一般的 POSIX 相容的檔案系統中，斜槓不能作為檔名的一部分，屬於非法字元，而在 Swift 中是允許的。通過這種方式，可以實現虛擬的目錄層次結構。此時，根路徑作為容器的名稱，根目錄之後的整個路徑都作為物件的名稱。
其次，由於 Swift 物件儲存不是一個真正的檔案系統，與一般的檔案系統不同，不包含使用者、使用者組以及其他使用者的可讀、可寫、可執行的許可權資訊，所以在許可權上需要進行特殊處理，具體的做法是將這些許可權資訊儲存在物件的擴充套件屬性中。FilesClient 類的 storeObject 方法有一個 java.util.Map 型別的引數，可以把使用者、使用者組以及其他使用者的許可權資訊作為 java.util.Map 物件中的元素，以代表權限型別的字串作為鍵，以許可權對應的數字作為值，例如使用者、使用者組以及其他使用者的許可權資訊分別為<"Acl-User", "6">、<"Acl-Group", "4">、<"Acl-Others", "4">。把包含許可權資訊的 java.util.Map 物件作為引數傳遞給 storeObject 方法，就可以將許可權資訊儲存到擴充套件屬性中了。
SwiftAdapter 類中介面轉換的對應關係如表 4 所示，分別列出了 SwiftAdapter 類與 FilesClient 類的方法之間的對應關係。
表 4. SwiftAdapter 類中介面轉換的對應關係
| SwiftAdapter 類的方法 | FilesClient 類被轉換的方法 |
|---|---|
| initialize | 呼叫 FilesClient 類的構造方法，初始化 FilesClient 類的例項 |
| open | getObject 返回的位元組陣列作為 SwiftInputStream 中的緩衝儲存 |
| create | storeObject 將 SwiftOutputStream 中緩衝儲存中的位元組儲存到 Swift 的物件中 |
| append | 不支援此操作 |
| rename | deleteObject, storeObject |
| delete | 目錄對應 deleteObject 和 deleteContainer，檔案對應 deleteObject |
| mkdirs | createContainer，storeObject |
| getFileStatus | 目錄對應 getContainerInfo, 檔案對應 getObjectMetaData |
| initialize | 呼叫 FilesClient 類的構造方法，初始化 FilesClient 類的例項 |
| open | getObject 返回的位元組陣列作為 SwiftInputStream 中的緩衝儲存 |
| create | storeObject 將 SwiftOutputStream 中緩衝儲存中的位元組儲存到 Swift 的物件中 |
編譯原始碼並打包成 JAR 檔案，再將 JAR 檔案及其依賴的類庫部署到 Hadoop 叢集中所有節點的$HADOOP_PREFIX/share/hadoop/lib 目錄中。
使用 RPM 檔案安裝的 Hadoop 的類庫預設目錄是/usr/share/hadoop/lib。這就像將外掛安裝到 Hadoop 中一樣，沒有對原有軟體進行修改。
修改 Hadoop 叢集中所有節點的配置檔案 core-site.xml，使檔案系統的 URI 指向 Swift 的代理節點，並指定 Swift 中的某個 Account、使用者名稱和密碼。
這些屬性會被 Swift 介面卡讀取。在 Swift 叢集中部署多臺代理節點，還可以使用專門的負載均衡器（Load Balancer）或輪轉 DNS（Round-robin DNS）指向這些代理節點，並在 core-site.xml 中使檔案系統的 URI 指向負載均衡器或輪轉 DNS。配置檔案 core-site.xml 的屬性如表 5 所示。
表 5. 配置檔案 core-site.xml 的屬性
| 屬性 | 值 | 說明 |
|---|---|---|
| fs.default.name | swift://proxy.swiftcluster.net:8080 | proxy.swiftcluster.net 是預先設定的輪轉 DNS 的域名 |
| fs.swift.impl | swift.SwiftAdapter | 完整的類名 |
| fs.swift.account | AUTH_5248434a-4066-407e-b5e3-0bec4fdbfc71 | Swift 中的一個 Account 名稱 |
| fs.swift.username | test:root | Swift 中的一個使用者名稱 |
| fs.swift.password | testing | 上述使用者名稱對應的密碼 |
| fs.swift.auth.url | http://proxy.swiftcluster.net:8080/auth | 認證伺服器的 URL，此處使用 Swauth |
拓撲結構
Hadoop 叢集中部署了 1 臺 JobTracker 節點，以及多臺執行 TaskTracker 的 slave 節點，所有節點均加入了 Swift 介面卡 JAR 檔案及其依賴的類庫。Swift 叢集中部署了多個 Proxy 節點和 Storage 節點，並且部署了 1 臺輪轉 DNS 伺服器，它指向這些 Swift 叢集中的代理節點。整個擴充套件系統的拓撲結構如圖 4 所示。
圖 4. 擴充套件系統拓撲結構圖
流程
在 Swift 介面卡中，以初始化檔案系統例項、開啟檔案並讀取資料、以及建立檔案並寫入資料的操作為例，分別敘述它們的流程，並使用 UML 時序圖展示出來。
Hadoop 的檔案系統客戶端命令列程式對應的是 org.apache.hadoop.fs.FsShell 類。在使用該命令列程式與檔案系統進行互動的時候，Hadoop 首先會根據配置檔案中指定的 scheme 尋找對應的檔案系統實現類，並進行初始化操作。org.apache.hadoop.fs.FileSystem 類有一個靜態內部類 FileSystem.Cache，它使用一個 Java 的 Map 型別快取了檔案系統的例項物件，鍵是檔案系統的 scheme 名稱，例如”hdfs”，值是對應的檔案系統物件例項，例如 DistributedFileSystem 類的例項。在本文的實現中，Swift 介面卡的 scheme 名稱是”swift”，對應的檔案系統類是 swift.SwiftAdapter，並且在配置檔案中設定屬性 fs.swift.impl 為 swift.SwiftAdapter。初始化檔案系統例項的詳細流程如下：如果名稱為”swift”的 scheme 存在於該快取中，則 FileSystem.Cache 直接通過 get 方法返回 swift.SwiftAdapter 的物件例項。否則，FileSystem 類呼叫靜態方法 createFileSystem，接著呼叫 ReflectionUtils 類的 newInstance 方法，最終呼叫 Constructor 類的 newInstance 方法，以反射的方式獲得 Swift 介面卡類的物件例項，最後呼叫 initialize 方法進行必要的初始化操作。初始化檔案系統例項的 UML 時序圖如圖 5 所示。
圖 5. 初始化檔案系統例項的 UML 時序圖
開啟檔案並讀取資料的詳細流程如下：在開啟檔案的時候，客戶程式呼叫 SwiftAdapter 類的 open 方法，SwiftAdapter 物件首先初始化 Swift 輸入流類 SwiftInputStream 的例項，然後 SwiftInputStream 物件會呼叫 FilesClient 物件的 getObject 方法向 Swift 叢集中的代理伺服器發起 HTTP 請求獲取 Swift 中的物件，把資料存入 SwiftByteArrayInputStream 物件內部的位元組陣列緩衝中，之後客戶端程式呼叫 SwiftInputStream 物件的 read 方法讀取緩衝儲存中的位元組，讀取資料的操作完成之後再呼叫 close 方法關閉 Swift 輸入流。開啟檔案並讀取資料的 UML 時序圖如圖 6 所示。
圖 6. 開啟檔案並讀取資料的 UML 時序圖
建立檔案並寫入資料的詳細流程如下：在建立檔案的時候，客戶程式呼叫 SwiftAdapter 類的 create 方法，SwiftAdapter 物件首先初始化 Swift 輸出流類 SwiftOutputStream 的例項，然後客戶程式呼叫 SwiftOutputStream 物件的 write 方法把資料寫入到它內部的位元組陣列緩衝中，直到呼叫它的 flush 方法或 close 方法，SwiftOutputStream 物件才會呼叫 FilesClient 物件的 storeObject 方法，向 Swift 叢集中的代理伺服器發起 HTTP 請求將緩衝儲存中的位元組寫入 Swift 中的物件。建立檔案並寫入資料的 UML 時序圖如圖 7 所示。
圖 7. 建立檔案並寫入資料的 UML 時序圖
未來的工作
通過 Swift 介面卡，將高可用的 Swift 物件儲存作為 Hadoop 的底層儲存系統，使得 Hadoop 在儲存層面具有了高可用性。把 Swift 介面卡部署到已有的 Hadoop 叢集中是簡單快捷的。原本用來分析儲存在 HDFS 中的資料的 MapReduce 應用程式，也無需修改即可分析儲存在 Swift 中的資料。
但是，使用 Swift 介面卡將 Hadoop 與 Swift 物件儲存整合之後，整個系統的缺點是失去了資料區域性性（Data Locality）的優勢。在 HDFS 中，NameNode 節點知道每一個檔案塊儲存在哪一個 DataNode 節點上。因此在執行 MapReduce 作業的過程中，使用者編寫的 MapReduce 應用程式的二進位制檔案會被 MapReduce 框架排程傳送至儘可能離資料最近的節點，最好的情況是在檔案塊所在的 DataNode 節點上的 TaskTracker 程序啟動 Map 任務，此時 Map 任務從本地檔案系統讀取輸入檔案，這樣可以避免大量的資料在 Hadoop 叢集的不同節點之間傳輸，節省了網路頻寬，也能加速 MapReduce 作業在 map 階段的執行速度。
通過 Swift 介面卡，將 Swift 物件儲存作為 Hadoop 的底層儲存系統，對 Hadoop 叢集來說，Swift 是一個外部儲存系統，TaskTracker 和檔案不在同一個節點上，因此在 MapReduce 作業執行的 map 階段，所有的讀取檔案操作都通過網路傳輸資料。Swift 物件儲存對於 Hadoop 叢集來說是一個黑盒，MapReduce 框架無法知道儲存系統的內部細節。
本文的目的是為 Hadoop 的儲存層增加對 OpenStack Swift 的支援，並非要取代 HDFS。作為一個階段性的嘗試，目前並未考慮和解決資料區域性性的問題，這部分將作為未來的工作。
測試結果
Swift 介面卡使得 Swift 物件儲存可以作為 Hadoop 的底層儲存系統，實現的效果包括兩個方面：第一，使用 Hadoop 的檔案系統命令列訪問 Swift 物件儲存。第二，執行 MapReduce 作業分析儲存在 Swift 中的資料。
使用 Hadoop 的檔案系統命令列訪問 Swift 物件儲存
ls 列出某個目錄下的檔案，在實現時未讀取檔案的實際修改時間，因此預設為 1970-1-1。如圖所示。
cat 檢視某個檔案的內容，如圖所示。
mkdir 建立目錄，如建立成功則無提示資訊，否則提示該目錄已存在的資訊，如圖所示。
put 將本地檔案存入 Swift 物件儲存中，如操作成功則無提示資訊，如圖所示。
get 將 Swift 物件儲存中的物件存到本地檔案中，如操作成功則無提示資訊，如圖所示。
rm, rmr 前者刪除檔案，後者級聯刪除目錄，操作不論成功與否都有提示資訊，如圖所示。
du 顯示某個目錄下的目錄和檔案的大小，即位元組長度，如圖所示。
執行 MapReduce 作業分析儲存在 Swift 中的資料
首先在 Hadoop 叢集中提交一個 MapReduce 作業，然後通過如下 URL 訪問 JobTracker 節點的 MapReduce 管理的頁面：http://<jobtracker-ip-address>:50030/jobtracker.jsp，點選具體的作業連結進入檢視執行結果的頁面，從頁面上的檔案 Scheme（swift://）可以看出 Hadoop 已經在 Swift 物件儲存之上執行 MapReduce 作業了，執行結果頁面如圖 8 所示。
圖 8. 在 Swift 物件儲存之上執行 MapReduce 作業示例圖
總結
本文分析了 Hadoop FileSystem API 和 Swift Java client API，以及 Hadoop 與 OpenStack Swift 整合的可行性，介紹了 Swift 介面卡的設計和實現細節，最終將 OpenStack Swift 物件儲存作為 Hadoop 的底層儲存，使得它們能夠協同工作，為 Hadoop 的儲存層增加了對 OpenStack Swift 的支援。
以上內容為轉載
轉：https://www.ibm.com/developerworks/cn/cloud/library/1401_ouyangf_hadoopswift/index.html
Mark 總結 ：目前各種物件儲存應用的介面卡都已經實現了
如 : aws介面卡 有 Hadoop-aws
swift介面卡 有 Hadoop-openstack
如下幾種方案
spark-core ---> Hadoop File system API ---> Hadoop-AWS ---> AWS
spark-core ---> Hadoop File system API ---> Hadoop-AWS ---> swift3 ---> swift(openstack)
spark-core ---> Hadoop File system API ---> Hadoop-OpenStack ---> swift(openstack)