mapreduce數(shù)據(jù)分析(參考版)
2025-05-17 14:22本頁面
【正文】 估計在 1000個節(jié)點(diǎn)上，性能也差不多。 Vertica和 DBMSX的下面部分代表執(zhí)行UDF/分析和加載數(shù)據(jù)到表中的時間，上面部分是執(zhí)行真正查詢的時間。 Vertica性能比較好。 25 UDF的聚集任務(wù) UDF Aggregation Task ? 任務(wù)是計算數(shù)據(jù)集中每個文檔的 inlink，這個任務(wù)經(jīng)常作為 PageRank計算的一個組件。實驗中使用表 UserVisits 1月 15日至 22日， 2021年，約 配。 24 聯(lián)合任務(wù) Join Task ? 加入任務(wù)包括兩個子任務(wù)來進(jìn)行兩組數(shù)據(jù)的復(fù)雜計算。 23 ? Aggregation task ? 要求每個系統(tǒng)計算在 UserVisits表中生成每個源 IP總收益數(shù)（ 20GB/節(jié)點(diǎn)）。結(jié)果如下， 隨著數(shù)據(jù)量增大， Hadoop影響最大。 22 ? ? 選擇任務(wù)是輕量級過濾器在 Rinkings 表 (1G/節(jié)點(diǎn) )中尋找 pageURLs。 ? 由于加載 UserVisits與 Ranking數(shù)據(jù)集是相似的，只提供數(shù)據(jù)集較大的 UserVisits的加載。 21 分析任務(wù) ? 為了探索處理更復(fù)雜的應(yīng)用，開發(fā)四個關(guān)于 HTML文檔處理的任務(wù)。下半段是執(zhí)行任務(wù)時間。 20 ? ? 三個系統(tǒng)的性能結(jié)果如下。 19 ? ? 加載 535M/node和 1T/node如下圖，對于 DBMSX，下半段是執(zhí)行加載命令時間，上半段是重組過程。 18 MR任務(wù) The original MR task ? 第一個基準(zhǔn)任務(wù)是文獻(xiàn) 【 8】 中的 Grep task 作者認(rèn)為具有代表性的大數(shù)據(jù)集 MR程序，這個任務(wù)是在 100位記錄的數(shù)據(jù)集尋找三個特征模式，每個記錄中在前十位中包含一個唯一的鍵，后 90位是隨機(jī)的值。還測量了每個系統(tǒng)加載數(shù)據(jù)的時間。 17 ? ? 三個系統(tǒng)都部署在 100臺機(jī)子的集群，每個節(jié)點(diǎn) CPU intel core 2 操作系統(tǒng) 64位 red hat enterprise linux 5 內(nèi)存 4G 硬盤 2個250GSATAI. 交換機(jī) 128Gbps 50個節(jié)點(diǎn)一臺交換機(jī)。數(shù)據(jù)以行的格式存儲，每個表哈希分到各個節(jié)點(diǎn)，然后根據(jù)不同的屬性排序和索引。 16 Benchmark environment ? ? Hadoop Java 默認(rèn)配置，除了數(shù)據(jù)塊大小改為 256M，JVM heap size 1024M（每個節(jié)點(diǎn) ），每個節(jié)點(diǎn)上運(yùn)行 2個 map實例和 1個 reduce實例。另外四個任務(wù)是更復(fù)雜的分析工作負(fù)載。 15 4 基準(zhǔn)的性能 Performance benchmarks ? 使用包含 5個任務(wù)的基準(zhǔn)來比較 MR和并行數(shù)據(jù)庫系統(tǒng)的性能。如果一個節(jié)點(diǎn)失敗，MR調(diào)度器會在另外一個節(jié)點(diǎn)上重啟這個任務(wù)。雖然沒有 MR完全的一般性，但數(shù)據(jù)庫管理系統(tǒng)現(xiàn)在提供的支持用戶自定義函數(shù)，存儲過程，在 SQL中聚合等，也提高了靈活性。 ? ? 由于 SQL表達(dá)能力不足，新的應(yīng)用程序框架開始扭轉(zhuǎn)這種局面，通過利用新的編程語言功能來實現(xiàn)對象 關(guān)
畢業(yè)設(shè)計相關(guān)推薦
鄂ICP備17016276號-1