云計(jì)算存儲(chǔ)技術(shù)分析_第1頁(yè)
云計(jì)算存儲(chǔ)技術(shù)分析_第2頁(yè)
云計(jì)算存儲(chǔ)技術(shù)分析_第3頁(yè)
云計(jì)算存儲(chǔ)技術(shù)分析_第4頁(yè)
云計(jì)算存儲(chǔ)技術(shù)分析_第5頁(yè)
已閱讀5頁(yè),還剩4頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、云計(jì)算存儲(chǔ)技術(shù)分析摘要隨著網(wǎng)絡(luò)應(yīng)用業(yè)務(wù)量的不斷增長(zhǎng) , 云存儲(chǔ)技術(shù)作為云計(jì)算系統(tǒng)的重要應(yīng)用之 一,也得到了更多的關(guān)注。對(duì)云存儲(chǔ)技術(shù)的研究實(shí)質(zhì)上是研究分布式存儲(chǔ)技術(shù)。 不同于傳統(tǒng)的存儲(chǔ)體系 , 云計(jì)算存儲(chǔ)技術(shù)需要解決更多的數(shù)據(jù)以及運(yùn)算的負(fù)載, 需要保證更好的數(shù)據(jù)可用性以及數(shù)據(jù)一致性, 需要提供更快的系統(tǒng)響應(yīng)時(shí)間。 針 對(duì)這些需求, 各大公司都開(kāi)發(fā)出可以很好的解決方案, 本文主要針對(duì)主流的云存 儲(chǔ)系統(tǒng)( Google File System 、 Amazon Dynamo 等)進(jìn)行分析,主要分析其在 冗余備份、動(dòng)態(tài)擴(kuò)展、負(fù)載均衡等方面的解決策略。關(guān)鍵詞 :云存儲(chǔ), 冗余備份,動(dòng)態(tài)擴(kuò)展,負(fù)載均衡Ab

2、stractAs with the rapid growth of web application, cloud storage is getting more and more attention. In fact, research on cloud storage is essentially research on distributed storage technology. Distinguished from conventional storage system, distributed storage technology needs to better support en

3、ormous amount of data and computing workload, guarantee better data availability and integrity, and provide shorter system response time. To meet those requirements, lots of giant companies have come up with great solutions, this article mainly analyses mainstream cloud storage system, such as Googl

4、e File System, AmazonDynamoetc. And the main focus is on strategy for redundant backup, dynamic extension, workload balance.Keywords : cloud storage, redundant backup, dynamic extension, workload balance1 云計(jì)算與云存儲(chǔ)簡(jiǎn)介近年來(lái),云計(jì)算無(wú)疑是最熱門的技術(shù)話題之一,越來(lái)越多的 IT 企業(yè)推出了 自己的云計(jì)算產(chǎn)品, 它的商業(yè)價(jià)值被給予了巨大的肯定, 被認(rèn)定是未來(lái)發(fā)展的必 然趨勢(shì)之一。那么什么是云

5、計(jì)算呢?目前,對(duì)于云計(jì)算的認(rèn)識(shí)還在不斷地發(fā)展變化,并沒(méi) 有一個(gè)統(tǒng)一的定義。號(hào)稱“網(wǎng)格之父”的 Ian Foster 是這樣定義云計(jì)算的: “云 計(jì)算是由規(guī)模經(jīng)濟(jì)拖動(dòng), 為互聯(lián)網(wǎng)上的外部用戶提供一組抽象的、 虛擬化的、 動(dòng) 態(tài)可擴(kuò)展的、 可管理的計(jì)算資源能力、 存儲(chǔ)能力、 平臺(tái)和服務(wù)的一種大規(guī)模分布 式計(jì)算的聚合體”。1 從概念上看,云計(jì)算實(shí)質(zhì)上是一種分布式計(jì)算,云計(jì)算的 核心思想, 是將大量用網(wǎng)絡(luò)連接的計(jì)算資源統(tǒng)一管理和調(diào)度, 構(gòu)成一個(gè)計(jì)算資源 池向用戶按需服務(wù),提供資源的網(wǎng)絡(luò)被稱為“云” 。當(dāng)云計(jì)算系統(tǒng)需要運(yùn)算和處理大量數(shù)據(jù)的存儲(chǔ)和管理時(shí), 云計(jì)算系統(tǒng)中就需 要配置大量的存儲(chǔ)設(shè)備,高性能的云

6、存儲(chǔ)也就成為了實(shí)現(xiàn)云計(jì)算服務(wù)的基本條 件。云存儲(chǔ)是指通過(guò)集群應(yīng)用、 網(wǎng)格技術(shù)或分布式系統(tǒng)等功能, 將網(wǎng)絡(luò)中大量不 同類型的存儲(chǔ)設(shè)備通過(guò)應(yīng)用軟件集合起來(lái)協(xié)同工作, 共同對(duì)外提供數(shù)據(jù)存儲(chǔ)和業(yè) 務(wù)訪問(wèn)功能。 事實(shí)上,幾乎在所有的基于云計(jì)算服務(wù)的應(yīng)用中都需要高性能的云 存儲(chǔ)來(lái)滿足數(shù)據(jù)處理的需求。2. 云計(jì)算存儲(chǔ)技術(shù)從云計(jì)算和云存儲(chǔ)的概念中可以看出, 云存儲(chǔ)實(shí)質(zhì)上是一種分布式存儲(chǔ), 因 此對(duì)于云計(jì)算存儲(chǔ)技術(shù)的研究的核心在于對(duì)分布式存儲(chǔ)技術(shù)的研究。 由于云存儲(chǔ) 底層設(shè)備的軟硬件環(huán)境各不相同, 且所處的網(wǎng)絡(luò)也是一個(gè)多變的環(huán)境, 因此云計(jì) 算的存儲(chǔ)技術(shù)除了需要解決基本的海量數(shù)據(jù)的存儲(chǔ)與獲取之外, 還需要解決負(fù)

7、載 均衡、提高容錯(cuò)性、動(dòng)態(tài)擴(kuò)展等許多傳統(tǒng)存儲(chǔ)系統(tǒng)沒(méi)有遇到過(guò)的挑戰(zhàn)。針對(duì)上面提到的幾點(diǎn)挑戰(zhàn),本文將對(duì)現(xiàn)有的技術(shù)進(jìn)行介紹、分析及對(duì)比。2.1 提高容錯(cuò)性分布式存儲(chǔ)系統(tǒng)(如 Amazon Dy name和GFS都是應(yīng)用在實(shí)際服務(wù)器上的系 統(tǒng),每一次出錯(cuò)都會(huì)帶來(lái)巨大的損失, 然而由于分布式系統(tǒng)的運(yùn)行環(huán)境決定了其 需要面對(duì)巨大的壓力。據(jù)Google說(shuō),其每1000臺(tái)服務(wù)器的集群中,平均每天壞 掉一臺(tái)機(jī)器,因此容錯(cuò)性是分布式存儲(chǔ)系統(tǒng)在設(shè)計(jì)時(shí)就必須優(yōu)先考慮的問(wèn)題。 2 為了提供較高的容錯(cuò)性, 常用的方法主要是冗余存放。 具體的做法就是將同一份 數(shù)據(jù)復(fù)制為多份(具體的數(shù)量是根據(jù)不同的應(yīng)用場(chǎng)景決定) ,同時(shí)存儲(chǔ)

8、在多個(gè)節(jié) 點(diǎn)上,這樣就可以在某一節(jié)點(diǎn)出現(xiàn)故障(臨時(shí)故障或永久性故障)時(shí),存儲(chǔ)在其 他節(jié)點(diǎn)上的數(shù)據(jù)備份可以繼續(xù)提供服務(wù)。由之前所述平均每 1000臺(tái)服務(wù)器每天 會(huì)有一臺(tái)故障, 那么其實(shí)只需要將同一份數(shù)據(jù)保存在三臺(tái)服務(wù)器上, 那樣在同一 天三臺(tái)機(jī)器同時(shí)出錯(cuò)的概率就降低為 10-9 ,幾乎可以視作完全安全了。所以 Amazon Dynam和Google File System 都采用了這個(gè)策略。在提供了較高的數(shù) 據(jù)可用性的同時(shí), 冗余存放還能帶來(lái)分流數(shù)據(jù)請(qǐng)求, 降低服務(wù)器平均負(fù)載壓力的 好處。同一份數(shù)據(jù)存儲(chǔ)在多處地理位置不同、 網(wǎng)絡(luò)情況不同的服務(wù)器中, 對(duì)于處 于正常服務(wù)狀態(tài)的數(shù)據(jù)節(jié)點(diǎn)來(lái)說(shuō), 用戶在

9、對(duì)數(shù)據(jù)進(jìn)行讀取操作時(shí), 距離用戶較近 并且網(wǎng)絡(luò)狀況較好的服務(wù)器節(jié)點(diǎn)可以提供更多的服務(wù), 同時(shí)其他節(jié)點(diǎn)可以同時(shí)提 供數(shù)據(jù)傳輸,降低了各自的負(fù)載壓力,提高了用戶獲取數(shù)據(jù)的速度。下面對(duì)AmazonDynamo和Google File System在提高容錯(cuò)性方面的策略(主 要是冗余存放)進(jìn)行具體的分析和比較。2.1.1 Amazon Dynamo 冗余存放策略策略定義了 N,W,R三個(gè)參數(shù),其中N代表系統(tǒng)中每條記錄的副本數(shù), W弋表 每次記錄成功寫操作需要寫入的副本數(shù),R代表每次記錄讀請(qǐng)求最少需要讀取的 副本數(shù)。只要 W+R>N就可以保證數(shù)據(jù)的一致性,因?yàn)?W+R>N寸讀寫總會(huì)有交集 必

10、定最少有 W R- N個(gè)讀請(qǐng)求會(huì)落到被寫的副本上,所以必然會(huì)讀到“最后” 被更新的副本數(shù)據(jù)。至于誰(shuí) “最后”的判斷需采用時(shí)間戳或時(shí)鐘向量等技術(shù)完 成,有邏輯關(guān)系先后由時(shí)鐘向量判斷,否則簡(jiǎn)單的用時(shí)間戳先后判斷。這種做法相比我們最樸素的想法我們直觀的想法一定認(rèn)為如果系統(tǒng)要 求記錄冗余 N 份,那么每次就寫入 N 份,而在讀請(qǐng)求時(shí)讀取任意一份可用記錄 即可要更安全,也更靈活。說(shuō)其更安全是指數(shù)據(jù)一致性更能被保證:比如說(shuō)客戶寫入一條記錄,該記錄 有三個(gè)副本在三個(gè)不同點(diǎn)上, 但是其中一個(gè)點(diǎn)臨時(shí)故障了, 因此記錄沒(méi)有被寫入 或更新。那么在對(duì)該記錄再讀取時(shí),如果取兩點(diǎn)( R=2 )則必然會(huì)讀取到最少一 個(gè)正確

11、的值(臨時(shí)故障點(diǎn)有可能在讀是恢復(fù), 那么讀出的值則不存在或者不是最 新的;若臨時(shí)故障點(diǎn)還未恢復(fù),則讀請(qǐng)求無(wú)法訪問(wèn)其上副本) 。而使用我們傳統(tǒng) 方法可能讀到發(fā)生臨時(shí)故障的那點(diǎn), 此刻就有可能讀出現(xiàn)錯(cuò)誤記錄 (舊的或者不 存在),因此可以看到加大 W,R 可提高系統(tǒng)安全性;說(shuō)其更靈活則是指可通過(guò)配 置 N,W,R 這幾個(gè)參數(shù)以滿足包括訪問(wèn)方式、速度和數(shù)據(jù)安全等迥異需求的各種 場(chǎng)景:比如對(duì)于寫多讀少的操作,可將 W 配低, R 配高;對(duì)于寫少讀多的操作, 則可將 W 配高, R 配低。Dy namO對(duì)于臨時(shí)故障的處理方式是:找到一臺(tái)可用機(jī)器,將數(shù)據(jù)暫時(shí)寫到其 上的臨時(shí)表中, 待臨時(shí)故障恢復(fù)后, 臨時(shí)

12、表中的數(shù)據(jù)會(huì)自動(dòng)寫回原目的地。 這樣 做得目的是達(dá)到永遠(yuǎn)可寫, 即使該云中只有一臺(tái)機(jī)器可用, 那么寫請(qǐng)求的數(shù)據(jù)就 不會(huì)丟失。2.1.2 Google File System 冗余存放策略該策略主要通過(guò)GFS來(lái)實(shí)現(xiàn)數(shù)據(jù)的冗余存儲(chǔ)。GFS將整個(gè)系統(tǒng)的節(jié)點(diǎn)分為三 種:Master、ChunkServer和Client。GFS中的文件被分成大小固定的數(shù)據(jù)塊, 并由 Master 節(jié)點(diǎn)在創(chuàng)建時(shí)分配一個(gè) 64 位全局唯一的數(shù)據(jù)塊句柄。數(shù)據(jù)塊被ChunkServer 以普通 Linux 文件的形式存儲(chǔ)在磁盤中。為了保證數(shù)據(jù)的可用性, 數(shù)據(jù)塊默認(rèn)保存三份。Master節(jié)點(diǎn)中則維護(hù)著系統(tǒng)的元數(shù)據(jù)(文件及數(shù)據(jù)塊名

13、字節(jié)點(diǎn)、GFS文件到數(shù)據(jù)塊之間的映射和數(shù)據(jù)塊位置信息等),同時(shí)也負(fù)責(zé)GFS的全局控制(數(shù)據(jù)塊 租約管理、垃圾數(shù)據(jù)塊回收、數(shù)據(jù)塊復(fù)制等)。Master節(jié)點(diǎn)定期與ChunkServer 通過(guò)心跳的方式交換信息,獲得節(jié)點(diǎn)的活動(dòng)狀態(tài)。Client是GFS提供給應(yīng)用程序的訪問(wèn)接口,它是一組專用接口,不遵守POSIX 規(guī)范,以庫(kù)文件的形式提供。Client訪問(wèn)GFS時(shí),首先訪問(wèn)Master節(jié)點(diǎn),獲取 與之進(jìn)行交互的ChunkServer信息,然后直接訪問(wèn)這些 ChunkServer,完成數(shù)據(jù) 存取工作。需要注意的是,GFS中的客戶端不緩存文件數(shù)據(jù),只緩存Master中獲取的元 數(shù)據(jù),這是由GFS的應(yīng)用特點(diǎn)

14、決定的。GFS最主要的應(yīng)用有兩個(gè):MapReduce與 Bigtable。對(duì)于Map Reduce GFS客戶端使用方式為順序讀寫,沒(méi)有緩存文件數(shù) 據(jù)的必要;而 Bigtable 作為云表格系統(tǒng),內(nèi)部實(shí)現(xiàn)了一套緩存機(jī)制。另外,如 何維護(hù)客戶端緩存與實(shí)際數(shù)據(jù)之間的一致性是一個(gè)極其復(fù)雜的問(wèn)題。2.2 動(dòng)態(tài)擴(kuò)展分布式存儲(chǔ)系統(tǒng)的另外一項(xiàng)重要特性就是動(dòng)態(tài)擴(kuò)展, 所謂動(dòng)態(tài)擴(kuò)展就是在不 改變當(dāng)前分布式存儲(chǔ)系統(tǒng)的運(yùn)行狀態(tài)下實(shí)現(xiàn)系統(tǒng)的升級(jí)和維護(hù), 主要是針對(duì)節(jié)點(diǎn) 的增加和刪除。3本小節(jié)將分析GFS的動(dòng)態(tài)擴(kuò)展機(jī)制。GFS主要采用了 Master節(jié)點(diǎn)通過(guò)心跳的方式和ChunkServer交換信息,從而 獲得節(jié)點(diǎn)的狀

15、態(tài)信息。在 Master 服務(wù)器啟動(dòng)的時(shí)候,或者新的 ChunkServer 加 入到集群中時(shí), Master 節(jié)點(diǎn)會(huì)向各個(gè) ChunkServer 輪詢它們所存儲(chǔ)的數(shù)據(jù)塊的 信息,通過(guò)這樣的方式來(lái)支持動(dòng)態(tài)節(jié)點(diǎn)加入。master 對(duì)每個(gè) chunkserver 維護(hù)一個(gè) hb_sequence ,表示 master 最近給 chunkserver 發(fā)送心跳的時(shí)間點(diǎn) ( 單位為秒 ) , master 會(huì)把這個(gè)值寫入向 chunkserver發(fā)送的心跳請(qǐng)求中;同時(shí)維護(hù)一個(gè) hb_res_sequenee,表示最后收 到 chunkserver 心 跳 請(qǐng) 求 的 時(shí) 間 點(diǎn) , chunkser

16、ver 的 心 跳 請(qǐng) 求 中 包 含 hb_res_sequence , 每 次 收 到 chunkserver 的 心 跳 請(qǐng) 求 更 新 該 值 。 如 果 hb_sequence-hb_res_sequence 大于某個(gè)給定的值, 則認(rèn)為該 chunkserver 已經(jīng)下線在 ChunkServer 端 , 當(dāng) 其 收 到 Master 的 心 跳 之 后 得 到 本 次 請(qǐng) 求 的 hb_sequenee,然后 ChunkServer 更新全局的 g_hb_sequenee, 同時(shí)向 Master 發(fā) 起心跳請(qǐng)求,請(qǐng)求中包含 hb_sequence。 同時(shí) ChunkServer 存

17、在一個(gè)定時(shí)器線 程定期檢查本地時(shí)間和 g_hb_sequenee 的差值, 如果發(fā)現(xiàn)長(zhǎng)時(shí)間沒(méi)有收到 Master 的心跳請(qǐng)求, ChunkServer 就殺死自己, 因?yàn)樗J(rèn)為在這么長(zhǎng)的時(shí)間內(nèi) 沒(méi)有收到 Master 的心跳,那么 Master 肯定已經(jīng)認(rèn)為自己死掉了, 所以就把自 己殺死。2.3 負(fù)載均衡隨著現(xiàn)有網(wǎng)絡(luò)各種業(yè)務(wù)量的不斷增多,訪問(wèn)量和數(shù)據(jù)流量的快速增長(zhǎng),其處 理能力和計(jì)算強(qiáng)度也相應(yīng)地增大, 使得單一的服務(wù)器設(shè)備根本無(wú)法承擔(dān)。 負(fù)載均 衡(Load Bala nee)就是通過(guò)在分布式的系統(tǒng)上,將負(fù)載分配到多個(gè)操作節(jié)點(diǎn)上 運(yùn)行,并在每個(gè)節(jié)點(diǎn)的負(fù)載處理完成之后, 將結(jié)果匯總并返回給用戶

18、。 通過(guò)負(fù)載 均衡,分布式系統(tǒng)的負(fù)載承受能力得到了大幅度提升。 這樣做的另外一個(gè)好處是, 大量并發(fā)訪問(wèn)被分?jǐn)偟蕉鄠€(gè)節(jié)點(diǎn)處理可以大大降低用戶等待的時(shí)間。 分布式存儲(chǔ) 系統(tǒng)在負(fù)載均衡方面都有著自己的核心技術(shù),本節(jié)主要介紹Hadoop和GFS的負(fù)載均衡機(jī)制。2.3.1 Hadoop 中的負(fù)載均衡在hadoop的HDFS中設(shè)計(jì)有自動(dòng)負(fù)載工具來(lái)進(jìn)行負(fù)載均衡。其 中, ReplieationTargetChooser 類專門負(fù)責(zé)為新生成的數(shù)據(jù)塊尋找存儲(chǔ)節(jié)點(diǎn),即主 要管理新數(shù)據(jù)塊的備份數(shù)量、申請(qǐng)的客戶端地址及已經(jīng)注冊(cè)的數(shù)據(jù)服務(wù)器位置, 其算法基本思路是只考慮靜態(tài)位置信息, 優(yōu)先照顧寫入者的速度, 讓多份備份

19、分 配到不同的節(jié)點(diǎn)中去。 4Balaneer 類則負(fù)責(zé)動(dòng)態(tài)負(fù)載的調(diào)整和均衡,是 Tool 類的派生類,以可配置 的獨(dú)立進(jìn)程的形式運(yùn)行。 它運(yùn)行有 NamenodeProtoeol 和 ClientProtoeol 兩 個(gè) 協(xié)議,與主控服務(wù)器進(jìn)行通信, 獲取各個(gè)數(shù)據(jù)服務(wù)器的負(fù)載狀況, 從而進(jìn)行調(diào)整, 即將一個(gè)數(shù)據(jù)塊從一個(gè)服務(wù)器遷移到另一臺(tái)服務(wù)器中。 5Balaneer 向目標(biāo)數(shù)據(jù)服 務(wù)器發(fā)送DataTransferProtocoLOPREPLACEBLOCK?肖息,隨后該服務(wù)器會(huì)寫入Balancer該數(shù)據(jù)塊,寫入成功之后原服務(wù)器會(huì)將該數(shù)據(jù)塊刪除??梢酝ㄟ^(guò)配置 的負(fù)載差距閾值, Balancer

20、會(huì)根據(jù)配置來(lái)平衡負(fù)載。232 GFS中的負(fù)載均衡在GFS中,負(fù)載均衡是在數(shù)據(jù)塊的創(chuàng)建和重新復(fù)制之后進(jìn)行的。首先Master 服務(wù)器創(chuàng)建一個(gè)數(shù)據(jù)塊, 決策把初始的空副本放在那里主要有幾個(gè)因素。 首先副 本應(yīng)盡量放置在平均硬盤使用率低于平均值的ChunkServer 上,以便平衡ChunkServer 之間的硬盤使用率, 其次應(yīng)該盡量限制 ChunkServer 上的近期創(chuàng)建 操作數(shù),因?yàn)殡m然創(chuàng)建本身是廉價(jià)的, 但是它會(huì)緊跟這沉重的寫操作, 因?yàn)閷懭?者需要寫的時(shí)候才會(huì)進(jìn)行創(chuàng)建, 而在我們的 "追加一次或多次 "的工作負(fù)載下塊一 旦被成功寫入就會(huì)變?yōu)橹蛔x。第三應(yīng)該盡量將數(shù)據(jù)庫(kù)分

21、散在不同的節(jié)點(diǎn)中。一旦數(shù)據(jù)塊的可用副本數(shù)少于用戶指定的數(shù)目, 服務(wù)器就會(huì)重新復(fù)制它。 這 種情況的產(chǎn)生主要原因有: 某個(gè) ChunkServer 上的副本損壞、 磁盤故障導(dǎo)致不可 用或者用戶提高了副本數(shù)目的配置。 需要被重新復(fù)制的數(shù)據(jù)塊會(huì)基于幾個(gè)因素排 序,一是數(shù)據(jù)塊離它的副本數(shù)量目標(biāo)的差距, 差距越大的數(shù)據(jù)塊優(yōu)先級(jí)越高, 二 是,活著的文件的優(yōu)先級(jí)會(huì)高于近期刪除的文件塊, 最后, 為了失效對(duì)正在運(yùn)行 的應(yīng)用程序的影響,我們提高阻塞客戶機(jī)流程的塊的優(yōu)先級(jí)。 Master 節(jié)點(diǎn)會(huì)選 擇優(yōu)先級(jí)最高的塊,然后通知其他ChunkServer直接從源數(shù)據(jù)塊拷貝到本地來(lái)實(shí) 現(xiàn)數(shù)據(jù)塊的復(fù)制。在創(chuàng)建和重新復(fù)制之后, Master 節(jié)點(diǎn)會(huì)周期性對(duì)副本進(jìn)行負(fù)載均衡,它先 檢查當(dāng)前副本的分布情況,然后移動(dòng)副本來(lái)均衡負(fù)載和磁盤的剩余空間。另外, Master 節(jié)點(diǎn)必須選擇哪些現(xiàn)有的副本要被移走。一般來(lái)說(shuō),它移動(dòng)那些剩余空 間低于平均值的塊服務(wù)器上面的副本,這樣就可以平衡硬盤使用率。3. 總結(jié)云存儲(chǔ)系統(tǒng)隨著云計(jì)算的蓬勃發(fā)展,越來(lái)越多的得到應(yīng)用,常見(jiàn)的云存儲(chǔ)系 統(tǒng)(主要是GFS Hadoop Dynamc等)在處理分布式數(shù)據(jù)存儲(chǔ)的時(shí)候都有著各自 的優(yōu)點(diǎn)缺點(diǎn),現(xiàn)在各個(gè)公司也都在基于開(kāi)源或者商用的代碼并針對(duì)自身的需求進(jìn) 行開(kāi)發(fā)。相信隨著

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論