大資料測試考題
很多人都在談大資料技術，但客戶在真正啟動大資料專案的時候有哪些技術思考？ 如何來選型大資料平臺？從以下POC考題及案例就可以瞭解客戶對大資料的細粒度需求。看了考題，你能全部做下來嗎？
初步擬定POC測試時間為xxxx, 將分批次安排意向廠商入場進行測試工作。
某銀行總行資訊科技部開發中心
|
單位 |
人員 |
|
銀行資訊科技部 |
大資料應用開發平臺專案成員 |
|
意向廠商 |
POC測試人員 |
各節點安裝服務參見<表1.1.1>
表1.1.1
|
主機名 |
ip |
服務 |
測試軟體及支撐軟體參見<表1.1.2.1>
表1.1.2.1
|
編號 |
軟體名稱 |
版本 |
數量 |
備註 |
|
1 |
||||
|
2 |
測試硬體清單參見<表1.1.2.2>表
|
編號 |
硬體名稱 |
規格型號 |
數量 |
備註 |
|
1 |
||||
|
2 |
||||
|
3 |
服務框架部分包括兩部分驗證，其一是面向開發者，驗證平臺所提供的開發工具及相關的服務是否充分滿足應用開發的需要；其二是在平臺處於執行時狀態下，服務層能否實現架構設計的預期效果。
2.1.1元件功能說明
|
架構層次 |
編號 |
技術元件 |
是否必選 |
|
應用開發層 |
1 |
CLT命令列工具 |
必選 |
|
2 |
管理控制檯 |
可選 |
|
|
3 |
SDK |
必選 |
|
|
4 |
IDE優化 |
可選 |
|
|
5 |
資料上傳下載工具 |
可選 |
|
|
服務層 |
6 |
REST API |
必選 |
|
7 |
資料路由 |
必選 |
|
|
8 |
同步非同步轉換 |
可選 |
|
|
9 |
API介面封裝 |
必選 |
|
|
10 |
業務邏輯容器（UDF/MR） |
可選 |
|
|
安全管理 |
11 |
身份認證 |
必選 |
|
12 |
許可權管理 |
必選 |
|
|
元資料管理 |
13 |
元資料管理 |
必選 |
2.1.2設計能力考察
提交物要求：1、以word形式提供具體的設計方案；
2.1.2.1應用開發層
SDK
SDK是對RESTfulAPI的封裝，提供更高層次的抽象，便於使用者理解和使用平臺的服務。
n 設計要求
1、 SDK的基本框架，包、類的整體結構設計、對於重點類的設計，請舉例一二。
2、 SDK與業界同類產品、系統（CDAP、ODPS SDK）上的差異和相應考慮？
3、 SDK是平臺與業務應用的介面，SDK設計時如何考慮對業務應用的支援？
4、 SDK與REST API如何權衡兩者的關係，設計上考慮的側重點分別是什麼？
CLT命令列工具
CLT是面向開發者的客戶端工具，開發者通過命令列的形式提交各種指令，與平臺進行互動。其支援的指令集包括許可權管理、資源（指令碼\Jar包等）上傳、結構化資料操作等DML、DDL。
命令列工具是開發者最主要的工具，其功能應覆蓋開發過程中的各主要環節，對開發全過程提供完整支援。
n 設計要求
命令列支援範圍、分類、設計思路、實現方案。
管理控制檯
管理控制檯是對CLT的補充，其功能是後者功能集的子集，提供更直觀的圖形化介面，便於非專業開發人員操作。此處的管理控制檯以應用開發者和管理人員為物件，主要服務於開發過程中的管理。提供許可權控制、使用者管理、日誌管理等功能，互動友好，便於非專業開發人員使用。
n 要求
管理控制檯支援的操作是命令列的子集，選擇的策略。管理控制檯本身的作為子系統的架構設計方案。
資料上傳下載工具
在開發過程中使用的命令列工具，簡化測試資料的上傳下載操作。
n 設計要求
介紹相應的設計方案。
IDE優化
基於自主研發平臺整合相應的外掛，支援java程式碼的開發、除錯等。
n 設計要求
與我行Java自主研發平臺充分結合，如何設計以優化開發過程，提升效率。
2.1.2.2服務層
REST API
服務層以統一的RESTful API方式對外提供服務，通過SDK方式進行封裝，進而形成不同的客戶端元件，便於開發人員使用。
REST API作為對外暴露的介面供外部應用呼叫，在平臺的全生命週期內要保證穩定性和向後相容性，需要保證介面的良好設計。API不只是對原生API一對一的封裝，還要兼顧異構元件標準化和API增強的目標（詳見高階架構相應章節描述）。
n 設計要求
1、 整體API層次結構的大致結構和設計思想
2、 對異構元件相容性考慮、API增強考慮
資料路由
基於元資料的管理，根據訪問資料物件的不同，將相應服務路由到不同的計算框架或不同的叢集。
n 設計要求
1、如何保證服務層元資料資訊與各叢集元資料資訊的一致性？
2、如何保證資料路由的高效和高可靠？
3、如何實現資料物件的解析，保證解析高效？
同步非同步轉換
支援同步及非同步排程，非同步排程主要考慮對於延時較長的任務，避免服務阻塞。
n 設計要求
平臺的服務如何針對客戶端呼叫和其他應用呼叫進行封裝？同步、非同步服務的設計原則，非同步排程的實現方式、非同步轉同步封裝的實現方式。
API介面封裝
對內部技術元件API的適配，保證向上提供相對統一的服務API。
n 設計要求
評估API適配設計好壞要關注有哪些方面？是否會帶來效率的損失？
業務邏輯容器（UDF/MR）
使用者可以編寫UDF（自定義）函式及MapReduce程式碼，託管到平臺的相應層次（服務層或計算層），實現一定的業務邏輯。
n 設計要求
1、 在多元件支援UDF的情況下，對UDF的定義方式能否做到與計算元件無關？
2、 在計算層元件不支援的情況下（如Impala），是否有其他方式支援有限的UDF定義？在設計上的關注點是什麼？其侷限性有哪些？
3、 平臺的服務如何針對客戶端呼叫和其他應用呼叫進行封裝？同步、非同步服務的設計原則，非同步排程的實現方式、非同步轉同步封裝的實現方式。
2.1.3實施能力考察
提交物要求：具備落地實施能力的廠商，提交相應的原始碼、目標碼以供驗證；
2.1.3.1應用開發層
應用開發層是對開發過程的支援，因此對該層用例並不以考察最終執行態的各項指標為重點（但將同步結合技術能力的要求進行考察），而是考察在開發環境下相應的工具是否滿足開發者高效、便捷的工作需要，是否能夠支撐完整的工作流程。
建立專案空間、使用者及賦權
“專案空間”對應平臺上的每一個具體應用，同時也是“多租戶”中的“租戶”概念。通過平臺層面的管理功能，建立“專案空間”及相應的“專案管理員”角色，切換至“專案管理員”完成為其他使用者的建立、賦權等操作。
n 考察用例
基於CLT工具建立開發人員賬戶，並賦予相應許可權。
n 相關技術元件
CLT（必選）或管理控制檯（可選）
建立表、載入基礎資料
通過CLT完成資料表建立，該表建立語句應符合通用SQL或HiveQL語法規範。表建立語法應考慮後續使用方式：一、是否要求複雜關聯查詢或單表低延遲查詢等等；二、考慮相應的多叢集、多儲存技術（HDFS/Hbase）的因素。
n 考察用例
1、 使用開發人員賬戶登入CLT，建立資料表Table_A。
2、 使用“資料傳輸工具”或“管理控制檯”將本地測試資料檔案（檔案大小不超過50M）上傳並載入至資料表Table_A中。
3、 使用CLT，通過查詢語句，檢查資料載入正確。
n 相關技術元件：
CLT（必選）、資料上傳下載工具（可選）、管理控制檯（可選）
程式碼開發、編譯、部署及除錯
n 考察用例
1、 基於IDE完成工程的建立、基於SDK完成程式碼開發並在本地完成編譯打包。IDE環境優先考慮與我行JAVA自主研發平臺整合。程式碼部分按照技術能力部分相應場景要求編寫。
2、 通過CLT完成Jar包的上傳和部署。Jar包上傳後作為“專案空間”下的資源，相應許可權在該空間下統一管理。
3、 通過CLT命令啟動相關任務或呼叫方法，完成程式執行除錯。
4、 通過CLT或管理控制檯（可選）查詢相應資料庫表、日誌資訊確認程式執行結果。
n 相關技術元件：
IDE（可選）、SDK（必選）、CLT（必選）、管理控制檯（可選）
資料共享
專案間的資料共享進行統一許可權控制，在未授權的情況下，“專案空間”內的資料檔案及其他資源對其他“專案空間”均不可見，在授權情況下可不同程度（讀、寫等許可權分離）的共享使用。
n 考察用例
1、 通過CLT或管理控制檯（可選）對資料表、資料檔案（非結構化）的訪問許可權進行管理。
2、 其他專案空間下的授權使用者可使用該共享資料，而未授權使用者無法檢視相應資料。
n 相關技術元件：
CLT（必選）、管理控制檯（可選）
2.1.3.2服務層
REST API
n 考察用例
通過瀏覽器或模擬器驗證相關REST API介面。
資料路由
n 用例
1、執行不同的查詢指令，通過日誌跟蹤資料路由過程，通過變更服務層元資料內容檢驗對資料路由的影響。
2、變更叢集的資料檔案或其他資料內容，檢驗服務層元資料是否做到一致性維護。
同步非同步轉換
n 考察用例
模擬外部應用呼叫平臺服務，通過日誌跟蹤及相關管理介面等技術方式驗證同步、非同步執行及轉換情況。
API介面封裝
n 考察用例
無
業務邏輯容器
n 考察用例
將指定Java類部署至平臺，通過模擬器或CLT等方式呼叫相應方法，確認執行程式碼執行正確性。
測試種子資料：本測試章節中的種子資料均取自資料倉庫中的集市，程式碼類表為截止到T日的全量資料，事實類表將根據情況選擇部分資料。出於資訊保安考慮，POC所用測試資料將以固定分隔符（Tab）分隔的每行一條記錄的文字檔案形式提供，檔案內容為脫密的生產資料。資料檔名稱同源表名稱，詳細檔案清單參見附錄一。
|
測試編號 |
|||||||||
|
測試專案 |
結構化資料載入場景 |
||||||||
|
測試目的 |
測試大資料應用開發平臺對存量和增量檔案載入處理能力。監控該平臺載入過程中的資源利用情況。 |
||||||||
|
測試要求 |
1) 載入的檔案為統一提供的測試資料檔案，原始檔格式不能改變。 2) 廠商根據銀行提供的目標表結構，提供相應的目標表建表語句，建立目標表，目標表結構不能改變。 3) 從裝載啟動到裝載結束，不能進行系統引數調整等影響裝載執行過程的行為。 |
||||||||
|
預置條件 |
硬軟體環境搭建完畢，種子資料的資料檔案已生成 |
||||||||
|
測試步驟 |
1、銀行人員將種子資料檔案放到指定檔案目錄，執行匯入指令碼，將資料檔案匯入到資料庫中。 2、記錄資料匯入時間，同時收集CPU和I/O資源消耗等資訊。 3、統計資料庫可用空間大小、每個表的佔用空間大小。 4、檢查每個表的記錄數目，對金額等欄位的正確性進行檢查（各家廠商結果比對）。 |
||||||||
|
預期結果 |
1． 資料檔案全部推送到hfds對應目錄。數量、內容正確。 2． 資料檔案同時備份到介面機規定目錄下。數量、內容正確。 |
||||||||
|
評分依據 |
衡量大資料應用開發平臺對結構化資料處理的正確性、系統處理效率。 |
||||||||
|
測試結果 |
|
|
測試編號 |
|
|
測試專案 |
結構化資料查詢場景 |
|
測試目的 |
測試簡單查詢案例（單表）在不同併發級別下，在各廠商平臺上的執行效率。為確保資料載入的一致性及SQL語句的正確性，需要對查詢結果作正確性檢查。驗證大資料平臺對結構化資料的處理能力和處理效率。 |
|
測試依據 |
|
|
預置條件 |
資料加工測試完成 |
|
測試步驟 |
1、廠商提供執行測試案例TC_01指令碼，規定執行測試時間，遞增併發級別 1、80、160、320、640、1280、1800、3600可逐級往上增加併發，記錄併發sql執行次數； 2、記錄測試案例的時間，CPU和I/O資源消耗情況等等。 3、對正確性進行驗證：資料加工的正確性。 |
|
預期結果 |
能夠正常查看錶中資料，得到正確的資料結果 |
|
評分依據 |
1、衡量大資料應用開發平臺對結構化資料的需求功能實現的設計和實施方面的能力； 2、衡量大資料應用開發平臺對結構化資料的資料需求查詢結果的正確性和查詢效率； |
|
測試結果 |
對於查詢效能測試，測試指標主要是各個SQL案例在不同併發級別下的執行時間和返回結果的正確性。同時還需要收集Cpu消耗比率、I/O讀寫情況（kb/s）等指標作參考。執行時間即查詢請求提交到結果全部返回的全部時間。 |
|
測試編號 |
|
|
測試專案 |
非結構化資料載入場景——小檔案 |
|
測試目的 |
測試大資料應用開發平臺對非結構化資料的載入處理場景。監控載入是否成功以及資源利用情況。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，非結構化資料的資料檔案已生成。非結構化資料為小檔案，幾k到1M之間，包括圖片、音訊、視訊檔案等，資料規模：TB級別。 |
|
測試步驟 |
1、將非結構化資料檔案放到不同的指定檔案目錄，測試在不同的併發級別下執行匯入指令碼，將對應的非結構化資料檔案逐條匯入。 2、記錄不同併發級別下資料匯入時間，同時收集資源消耗等資訊。 3、對錶的元資料資訊及儲存資訊進行檢查，對記錄數目進行比對。 |
|
預期結果 |
1、不同併發級別下資料檔案均可全部寫入，元資料和儲存資訊正確。 2、不同併發級別下資料寫入效率對比。 3、不同併發級別下資源使用情況對比。 |
|
評分依據 |
衡量大資料應用開發平臺對非結構化資料處理的正確性、系統處理效率。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
非結構化資料查詢場景——小檔案 |
|
測試目的 |
對非結構化資料進行單筆高併發查詢進行驗證。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，非結構化資料已寫入。非結構化資料為小檔案，幾k到1M之間，包括圖片、音訊、視訊檔案等。資料規模：TB級別。 |
|
測試步驟 |
1、廠商提供執行指令碼，測試不同的併發級別下單筆記錄的查詢，保證功能完整性和效能要求。 2、記錄不同併發級別下的查詢時間，資源消耗情況等。 3、對查詢資料正確性進行驗證。 |
|
預期結果 |
1、不同併發級別下資料的訪問均正確。 2、不同併發級別下資料查詢效率對比。 3、不同併發級別下資源使用情況對比。 |
|
評分依據 |
1、衡量大資料應用開發平臺對非結構化資料的需求功能實現的設計和實施方面的能力； 2、衡量大資料應用開發平臺對非結構化資料的資料需求查詢結果的正確性和查詢效率； |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
非結構化資料載入場景——大檔案 |
|
測試目的 |
測試大資料應用開發平臺對非結構化資料的載入的處理場景。監控載入是否成功以及資源利用情況。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，非結構化資料的資料檔案已生成。非結構化資料為大檔案，1M以上到幾百M之間，包括圖片、音訊、視訊檔案等。資料規模：TB級別 |
|
測試步驟 |
1、將非結構化資料檔案放到指定檔案目錄下，執行批量匯入指令碼，將對應的非結構化資料檔案匯入（選擇合適的資料儲存格式進行：a、無壓縮無加密方式；b、壓縮方式；c、加密方式三種場景的資料匯入測試）。 2、記錄各種組合情況下的資料匯入時間，壓縮比、佔用空間，同時收集資源消耗等資訊。 3、對元資料資訊及儲存資訊進行掃描檢查，對記錄數目進行比對，對資料正確性做抽查。 |
|
預期結果 |
1、在各種組合情況下資料檔案均可全部匯入，元資料和儲存資訊正確。 2、在各種組合情況下對資料寫入效率，壓縮比、佔用空間進行比對。 3、在各種組合情況下對資源使用情況進行比對。 |
|
評分依據 |
衡量大資料應用開發平臺對非結構化資料處理的正確性、系統處理效率。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
非結構化資料查詢場景——大檔案 |
|
測試目的 |
根據關鍵字對非結構化資料進行單筆查詢。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，非結構化資料已寫入。非結構化資料為大檔案，1M以上到幾百M之間，包括圖片、音訊、視訊檔案等。 |
|
測試步驟 |
1、廠商提供執行指令碼，測試各種組合情況下（a、無壓縮無加密方式；b、壓縮方式；c、加密方式）的單筆查詢，保證功能完整性和效能要求。 2、記錄各種組合情況下的查詢時間，資源消耗情況等。 3、對查詢資料正確性進行驗證。 |
|
預期結果 |
1、在各種組合情況下資料的訪問均正確。 2、在各種組合情況下對資料查詢效率進行比對。 3、在各種組合情況下對資源使用情況進行比對。 |
|
評分依據 |
1、衡量大資料應用開發平臺對非結構化資料的需求功能實現的設計和實施方面的能力； 2、衡量大資料應用開發平臺對非結構化資料的資料需求查詢結果的正確性和查詢效率； |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
半結構化資料載入場景 |
|
測試目的 |
測試大資料應用開發平臺對半結構化資料的載入的處理場景。監控載入是否成功以及資源利用情況。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，半結構化資料的資料檔案已生成。 |
|
測試步驟 |
1、將半結構化資料檔案放到指定檔案目錄下，執行批量匯入指令碼，將對應的半結構化資料檔案匯入到HDFS或HBase中。 2、記錄資料匯入時間，同時收集資源消耗等資訊。 3、對元資料資訊及儲存資訊進行檢查。 |
|
預期結果 |
1、資料檔案均可全部正常匯入到HDFS或HBase中，元資料和儲存資訊正確。 2、對在載入過程中的資源使用情況進行統計。 |
|
評分依據 |
衡量大資料應用開發平臺對半結構化資料處理的正確性、系統處理效率。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
半結構化資料查詢場景 |
|
測試目的 |
對半結構化資料進行計算和查詢 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，半結構化資料已寫入HDFS或HBase中。 |
|
測試步驟 |
1、廠商提供執行指令碼，測試半結構化資料的求和模式（統計某單次出現次數等）、過濾模式（篩選出滿足一定條件的資料等）、資料組織模式（對資料的分組歸類等），保證功能完整性和效能要求。 2、記錄各種計算及查詢模式下的查詢時間，資源消耗情況等。 3、對查詢資料正確性進行驗證。 |
|
預期結果 |
1、在各種計算及查詢模式下資料的查詢結果均正確。 2、對各種計算及查詢模式下資料查詢效率進行分析。 3、對各種計算及查詢模式下資源使用情況進行分析。 |
|
評分依據 |
1、衡量大資料應用開發平臺對半結構化資料的需求功能實現的設計和實施方面的能力； 2、衡量大資料應用開發平臺對半結構化資料的資料需求查詢結果的正確性和查詢效率； |
|
測試結果 |
3.9.1 工具整合——Freequery（可選題）
|
測試編號 |
|
|
測試專案 |
結構化資料查詢介面實現場景——工具整合——Freequery |
|
測試目的 |
測試結構化資料儲存於大資料平臺後，廠商可否支援已有查詢工具使用SQL或類SQL語句進行靈活查詢。 |
|
測試依據 |
|
|
預置條件 |
硬軟體環境搭建完畢，結構化資料已匯入。 |
|
測試步驟 |
1、將廠商提供介面程式（jdbc）新增入freequery產品包 2、在freequery中建立相關資料來源。 3、在freequery中建立查詢。 4、檢視是否返回查詢結果。 |
|
預期結果 |
通過sql或類sql查詢可返回結果。 |
|
評分依據 |
衡量大資料應用開發平臺對查詢工具的整合能力，驗證查詢資料的正確性。 |
|
測試結果 |
3.9.2 工具整合——Tableau9（必選題）
|
測試編號 |
|
|
測試專案 |
工具整合——Tableau9 |
|
測試目的 |
測試能否通過tableau9建立相關資料來源，進行基於hadoop結構化資料儲存的資料視覺化分析。通過Tableau9工具直接驗證hadoop的hive、sparkSQL的連通性，不需要廠商工具整合的開發。 |
|
測試依據 |
Tableau9提供的介面（按技術方案選取）：hive（cloudera\hortonworks\MapR）、spark SQL |
|
預置條件 |
硬軟體環境搭建完畢，結構化資料已寫入。 |
|
測試步驟 |
1、廠商提供配置資訊 2、資料服務人員嘗試訪問結構化資料表 3、完成資料載入並進行簡單分析製圖 |
|
預期結果 |
能夠基於tableau9產品內建介面訪問hadoop平臺內結構化資料表 |
|
評分依據 |
衡量大資料應用開發平臺對查詢工具的整合能力，驗證查詢資料的正確性。 |
|
測試結果 |
4 基礎元件測試——元件功能性部分
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
Loader將本地檔案上傳到HDFS |
|
測試目的 |
檢測Hadoop Loader是否將大資料上傳到HDFS |
|
測試依據 |
|
|
預置條件 |
1. 已部署好大資料平臺系統，配置好Hadoop Loader服務。 2. 大資料平臺和介面機網路正常。 3. 將上游系統的資料下載到loader服務節點的本地目錄下，如/data1/loaddata/ |
|
測試步驟 |
1. Loader配置檔案loadConfig.xml配置上傳的源目錄和目的路徑。 2. 配置檔案Config.properties中的ScanInterval=10 #每隔10秒loader檢查源路徑下資料 3. 等待資料檔案全部推送結束，檢視HDFS對應目錄。 4. 檢視檔案備份目錄。 |
|
預期結果 |
1、 資料檔案全部推送到hfds對應目錄。數量、內容正確。 2、 資料檔案同時備份到介面機規定目錄下。數量、內容正確。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
Hdfs匯入匯出測試 |
|
測試目的 |
測試使用客戶端匯入與匯出hdfs資料。 |
|
測試依據 |
|
|
預置條件 |
1.搭建測試環境，系統執行正常 |
|
測試步驟 |
1． 使用客戶端連線叢集 2． 使用put把資料拷貝至hdfs中 3． 使用get從hdfs中下載資料 |
|
預期結果 |
支援客戶端匯入與匯出hdfs資料。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
Hadoop-loader服務將HDFS檔案匯出到本地 |
|
測試目的 |
匯出HDFS檔案到本地檔案系統 |
|
測試依據 |
|
|
預置條件 |
1．按照測試組網圖搭建測試環境； 2．在測試環境下完成產品初始配置副本數為3； 3．各服務正常。 4．準備HDFS檔案/bank/TINT/111.txt |
|
測試步驟 |
1. 1. Loader配置檔案downloadConfig.xml配置下載的的源目錄和目的路徑。 2. 2. 配置檔案Config.properties中的ScanInterval=10 #每隔10秒 3. 3. loader檢查源路徑下資料 4. 4. 等待資料檔案全部推送結束，檢視本地檔案系統的路徑。 |
|
預期結果 |
HDFS檔案複製至本地檔案系統正常執行。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
HDFS檢視儲存檔案以及儲存資料的大小 |
|
測試目的 |
用於從本地檔案系統上傳檔案到HDFS中 |
|
測試依據 |
|
|
預置條件 |
1．按照測試組網圖搭建測試環境； |
|
測試步驟 |
1．根據已上傳至HDFS檔案系統內的檔案，檢視HDFS的儲存 |
|
預期結果 |
HDFS各節點儲存分佈平衡，儲存正常 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
HDFS檔案讀取 |
|
測試目的 |
該命令用於在終端顯示（標準輸出stdout）檔案中的內容，類似Linux系統中的cat |
|
測試依據 |
|
|
預置條件 |
1．按照測試組網圖搭建測試環境； 2．在測試環境下完成產品初始配置副本數為3； 3．啟動HDFS，mr系統。 |
|
測試步驟 |
1．測試顯示檔案內容命令 格式參考如下 hadoop fs –cat 檔名 |
|
預期結果 |
顯示檔案內容正確 |
|
測試說明 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
Namenode主節點故障測試 |
|
測試目的 |
測試namenode主節點故障下的可用情況 |
|
測試依據 |
|
|
預置條件 |
1.叢集正常執行； |
|
測試步驟 |
1、 向HDFS中持續進行檔案的讀寫操作，模擬背景業務； 2、 背景業務執行過程中，將主NameNode節點的程序通過管理系統停止來模擬故障； 3、觀察背景業務是否中斷，業務是否有損失； 4、觀察是否有主備倒換告警上報 |
|
預期結果 |
Namenode程序能夠自動主備切換。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
Datanode主節點故障測試 |
|
測試目的 |
測試datanode節點故障下的可用情況 |
|
測試依據 |
|
|
預置條件 |
1.叢集正常執行； |
|
測試步驟 |
1、 向HDFS中持續進行檔案的讀寫操作，模擬背景業務； 2、 背景業務執行過程中，將叢集中的一個DataNode節點的程序通過管理系統停止來模擬故障； 3、觀察背景業務是否中斷，業務是否有損失。 |
|
預期結果 |
單個Datanode節點的故障不會影響整個系統提供的服務。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
HDFS備份恢復能力 |
|
測試目的 |
驗證HDFS的備份恢復能力 |
|
測試依據 |
|
|
預置條件 |
1.叢集正常執行； |
|
測試步驟 |
1. 在HDFS中建立目錄/backup/a、/backup/b，分別向兩個目錄中上傳10G資料。同時啟動一個能夠長時間執行HFDS讀寫指令碼，來模擬背景業務； 2. 對目錄/backup/a進行全量備份，觀察備份是否成功，備份成功後將/backup目錄下的a、b目錄同時刪除； 3. 使用備份的資料進行恢復，觀察/backup/a是否恢復成功，內容是否與刪除前的一致，觀察/backup/b是否不會被恢復； 4. 再向/backup/a中追加1G的資料檔案，並執行增量備份； 5. 刪除/backup/a目錄，並使用增量備份內容進行恢復，觀察恢復的內容是否與刪除前的一致； 觀察/backup/a中追加的1G資料檔案是否會被恢復。 |
|
預期結果 |
HDFS具備指定目錄進行備份的能力； HDFS具備線上備份的能力，不影響業務 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
大資料平臺HDFS白名單功能測試 |
|
測試目的 |
驗證大資料平臺HDFS白名單功能測試 |
|
測試依據 |
|
|
預置條件 |
1.系統正常執行； |
|
測試步驟 |
1、開啟HDFS白名單開關； 2、不加入客戶端A在HDFS的白名單中，使用客戶端A訪問HDFS。 將客戶端A加入HDFS的白名單中，使用客戶端A訪問HDFS |
|
預期結果 |
加入白名單的客戶端有許可權訪問叢集； 未加入白名單的客戶端無許可權訪問叢集； |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
HDFS使用者許可權控制 |
|
測試目的 |
驗證HDFS戶許可權控制功能測試 |
|
測試依據 |
|
|
預置條件 |
1.系統正常執行； |
|
測試步驟 |
1、HDFS許可權測試 驗證合法使用者對自己擁有許可權的資料有操作許可權： 驗證合法使用者對自己沒有許可權的資料沒有操作許可權： |
|
預期結果 |
使用者只能夠訪問、操作自己許可權範圍內的資料 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
對叢集的節點線上擴容 |
|
測試目的 |
驗證Hadoop叢集是否具備線上擴容能力 |
|
測試依據 |
|
|
預置條件 |
各叢集正常執行，待擴容的伺服器正常執行 |
|
測試步驟 |
1.在當前節點規模時，提交一個排序的terasort任務（第一次）。 2.選擇待擴容伺服器進行線上擴容，同時向叢集提交一個排序的terasort任務（第二次）。 3.觀察擴容過程對線上應用的影響及耗時 4.觀察擴容完成後叢集的服務狀態 5. 提交一個排序的terasort任務（第三次） |
|
預期結果 |
1、整個擴容過程線上完成，系統已有任務不受影響； 2、操作簡單，具有一鍵擴充套件功能。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
HDFS功能測試 |
|
測試子專案 |
對叢集的節點線上收縮 |
|
測試目的 |
驗證Hadoop叢集是否具備線上收縮能力 |
|
測試依據 |
|
|
預置條件 |
各叢集正常執行，待擴容的伺服器正常執行 |
|
測試步驟 |
1.當前規模時，提交一個排序的terasort任務（第一次），記錄完成時間。 2.選擇1臺伺服器進行線上收縮，同時向叢集提交一個排序的terasort任務（第二次）。 3.觀察收縮過程對線上應用的影響及耗時 4.觀察收縮完成後叢集的服務狀態 5.提交一個排序的terasort任務（第三次），記錄完成時間。 |
|
預期結果 |
1、整個擴容過程線上完成，系統已有任務不受影響； 2、操作簡單，具有一鍵收縮功能。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
Hbase功能測試 |
|
測試子專案 |
Hbase檢視儲存表 |
|
測試目的 |
用於儲存大資料表的能力 |
|
測試依據 |
|
|
預置條件 |
1．按照測試組網圖搭建測試環境； 2．匯入資料表。 |
|
測試步驟 |
1．根據已上傳的Hbase表，檢視habse的儲存表能力 |
|
預期結果 |
Hbase頁面中Table Details中儲存了上傳的Hbase表，儲存正常 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
Hbase功能測試 |
|
測試子專案 |
Hbase檢視資料 |
|
測試目的 |
驗證Hbase功能 |
|
測試依據 |
|
|
預置條件 |
1. 按照測試組網圖搭建測試環境； 2. 啟動HDFS，mr系統。 3. 啟動Hbase |
|
測試步驟 |
1. 登陸Hbase主節點所在伺服器 2. 切換到mr使用者下，執行Hbase shell命令 3. 在shell中輸入：scan '表名稱' Hbase(main):010:0> scan 'table' |
|
預期結果 |
能夠正常查看錶中資料 |
|
測試說明 |
|
測試編號 |
|
|
測試專案 |
Hbase功能測試 |
|
測試子專案 |
Hbase匯入測試 |
|
測試目的 |
測試Hbase能夠根據extimporttsv.input配置項正確匯入資料 |
|
測試依據 |
|
|
預置條件 |
1． 按照測試組網圖搭建測試環境； 2． 在測試環境下完成產品初始配置副本數為3； 3． 啟動HDFS，mr系統。 4． 啟動Hbase |
|
測試步驟 |
1． 準備資料並將資料儲存到HDFS檔案系統中/test； 2． Hbase中建表 3． 新建模板bank.ini，按照建表的實際情況填寫，上傳至HDFS的/test目錄下 模板原型： 4． 使用命令列方式執行匯入：Hbase com.citicbank.Hbase.importer.ExtImportTsv -Dextimporttsv.conf=/test/bank.ini |
|
預期結果 |
Hbase可以正確將路徑extimporttsv.input中的檔案匯入表中。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
Hbase功能測試 |
|
測試子專案 |
Hbase匯出測試 |
|
測試目的 |
測試Hbase能夠根據模板檔案中的Hbase_table正確匯出資料 |
|
測試依據 |
|
|
預置條件 |
1． 按照測試組網圖搭建測試環境； 2． 在測試環境下完成產品初始配置副本數為3； 3． 啟動HDFS，mr系統。 4． 啟動Hbase 5． 準備好Hbase表文件。 |
|
測試步驟 |
1. 通過配置檔案方式設定匯出規則 2. 執行匯出操作 3. 檢查匯出的表資料和生成的報告 |
|
預期結果 |
Hbase能夠正確匯出表資料。 |
|
測試結果 |
|
測試編號 |
|
|
測試專案 |
Hbase功能測試 |
|
測試子專案 |
Hbase檢視資料 |
|
測試目的 |
驗證Hbase功能 |
|
測試依據 |
|
|
預置條件 |
1. 按照測試組網圖搭建測試環境； 2. 啟動HDFS，mr系統。 3. 啟動Hbase |
|
測試步驟 |
1. 登陸Hbase主節點所在伺服 |