深入理解h集群和網(wǎng)絡(luò)_第1頁
深入理解h集群和網(wǎng)絡(luò)_第2頁
深入理解h集群和網(wǎng)絡(luò)_第3頁
深入理解h集群和網(wǎng)絡(luò)_第4頁
深入理解h集群和網(wǎng)絡(luò)_第5頁
已閱讀5頁,還剩12頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

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

文檔簡介

1、深入理解 Hadoop 集群和網(wǎng)絡(luò)云計算和 Hadoop 中網(wǎng)絡(luò)是討論得相對比較少的領(lǐng)域。本文原文由 Dell 企業(yè)技術(shù)Brad Hedlund 撰寫,他曾在思科工作多年,專長是數(shù)據(jù)中心、云網(wǎng)絡(luò)等。文章素材基于作者的研究、實驗和 Cloudera 的培訓(xùn)資料。Linux 公社(LinuxIDC.com)于 2006 年 9 月 25 日并開通,Linux 現(xiàn)在已經(jīng)成為一種廣受關(guān)注和支持的一種操作系統(tǒng),IDC是互聯(lián)網(wǎng)數(shù)據(jù)中心, LinuxIDC 就是關(guān)于 Linux 的數(shù)據(jù)中心。Linux 公社是專業(yè)的 Linux 系統(tǒng)門戶,實時發(fā)布最新 Linux 資訊,包括 Linux、Ubuntu、Fed

2、ora、RedHat、Linux、Linux 教程、Linux 認(rèn)證、SUSE Linux、Android、Oracle、Hadoop、CentOS 等技術(shù)。本文將著重于討論 Hadoop 集群的體系結(jié)構(gòu)和方法,及它如何與網(wǎng)絡(luò)和服務(wù)器基礎(chǔ)設(shè)施的關(guān)系。最開始我們先學(xué)習(xí)一下 Hadoop 集群運(yùn)作的基礎(chǔ)原理。Hadoop 里的服務(wù)器Hadoop 主要的任務(wù)部署分為 3 個部分,分別是:Client,主節(jié)點和從節(jié)點。主節(jié)點主要負(fù)責(zé) Hadoop 兩個關(guān)鍵功能模塊 HDFS、MapReduce 的監(jiān)督。當(dāng) Job Tracker 使用 Map Reduce 進(jìn)行和調(diào)度數(shù)據(jù)的并行處理時,名稱節(jié)點則負(fù)責(zé)

3、HDFS 監(jiān)視和調(diào)度。從節(jié)點負(fù)責(zé)了運(yùn)行的絕大部分,擔(dān)當(dāng)所有數(shù)據(jù)儲存和指令計算的苦差。每個從節(jié)點既扮演者數(shù)據(jù)節(jié)點的又沖當(dāng)與他們主節(jié)點通信的守護(hù)進(jìn)程。守護(hù)進(jìn)程隸屬于 Job Tracker,數(shù)據(jù)節(jié)點在歸屬于名稱節(jié)點。Client集合了 Hadoop 上所有的集群設(shè)置,但既不包括主節(jié)點也不包括從節(jié)點。取而代之的是客戶端的作用是把數(shù)據(jù)加載到集群中,遞交給 Map Reduce 數(shù)據(jù)處理工作的描述,并在工作結(jié)束后取回或者查看結(jié)果。在小的集群中(大約 40 個節(jié)點)可能會面對單物理設(shè)備處理多任務(wù),比如同時 Job Tracker 和名稱節(jié)點。作為大集群的中間件,一般情況下都是用的服務(wù)器去處理單個任務(wù)。在真

4、正的集群中是沒有虛擬服務(wù)器和管理層的存在的,這樣就沒有了多余的性能損耗。Hadoop 在 Linux 系統(tǒng)上運(yùn)行的最好,直接操作底層硬件設(shè)施。這就說明 Hadoop 實際上是直接在虛擬機(jī)上工作。這樣在花費(fèi)、易學(xué)性和速度上有著無與倫比的優(yōu)勢。Hadoop 集群上面是一個典型 Hadoop 集群的構(gòu)造。一系列機(jī)架通過大量的機(jī)架轉(zhuǎn)換與機(jī)架式服務(wù)器(不是刀片服務(wù)器)連接起來,通常會用 1GB 或者 2GB 的寬帶來支撐連接。10GB 的帶寬雖然不常見,但是卻能顯著的提高 CPU和磁盤驅(qū)動器的密集性。上一層的機(jī)架轉(zhuǎn)換會以相同的帶寬同時連接著許多機(jī)架,形成集群。大量擁有自身磁盤儲存器、CPU 及 DRAM

5、 的服務(wù)器將成為從節(jié)點。同樣有些將成為主節(jié)點,這些擁有少量磁盤儲存器的卻有著更快的 CPU 及更大的 DRAM。下面我們來看一下應(yīng)用程序是怎樣的吧:adoop 的工作流程在計算機(jī)行業(yè)競爭如此激烈的情況下,究竟什么是 Hadoop 的生存之道?它又切實的解決了什么問題?簡而言之,商業(yè)及都存在大量的數(shù)據(jù)需要被快速的分析和處理。把這些大塊的數(shù)據(jù)切開,然后分給大量的計算機(jī),讓計算機(jī)并行的處理這些數(shù)據(jù) 這就是 Hadoop能做的。下面這個簡單的例子里,有一個龐大的數(shù)據(jù)文件(給部門的電子郵件)??焖俚慕厝∠隆癛efund”在郵件中出現(xiàn)的次數(shù)。這是個簡單的字?jǐn)?shù)統(tǒng)計練習(xí)。Client 將把數(shù)據(jù)加載到集群中(F

6、ile.txt),提交數(shù)據(jù)分析工作的描述(word cout),集群將會把結(jié)果儲存到一個新的文件中(Results.txt),然后 Client 就會讀結(jié)果文檔。向 HDFS 里寫入 FileHadoop 集群在沒有注入數(shù)據(jù)之前是不起作用的,所以我們先從加載龐大的 File.txt 到集群中開始。首要的目標(biāo)當(dāng)然是數(shù)據(jù)快速的并行處理。為了實現(xiàn)這個目標(biāo),我們需要竟可能多的同時工作。最后,Client 將把數(shù)據(jù)分成更小的模塊,然后分到不同的上貫穿整個集群。模塊分的越小,做數(shù)據(jù)并行處理的就越多。同時這些還可能出故障,所以為了避免數(shù)據(jù)丟失就需要單個數(shù)據(jù)同時在不同的上處理。所以每塊數(shù)據(jù)都會在集群上被重復(fù)的

7、加載。Hadoop 的默認(rèn)設(shè)置是每塊數(shù)據(jù)重復(fù)加載 3 次。這個可以通過hdfs-site.xml 文件中的 dfs.replication 參數(shù)來設(shè)置。Client 把 File.txt 文件分成 3 塊。Cient 會和名稱節(jié)點達(dá)成協(xié)議(通常是 TCP 9000 協(xié)議)然后得到將要拷貝數(shù)據(jù)的 3 個數(shù)據(jù)節(jié)點列表。然后 Client 將會把每塊數(shù)據(jù)直接寫入數(shù)據(jù)節(jié)點中(通常是 TCP 50010 協(xié)議)。收到數(shù)據(jù)的數(shù)據(jù)節(jié)點將會把數(shù)據(jù)到其他數(shù)據(jù)節(jié)點中,循環(huán)只到所有數(shù)據(jù)節(jié)點都完成拷貝為止。名稱節(jié)點只負(fù)責(zé)提供數(shù)據(jù)的位置和數(shù)據(jù)在族群中的去處(文件系統(tǒng)元數(shù)據(jù))。Hadoop 的 Rack Awarenes

8、sHadoop 還擁有“Rack Awareness”的理念。作為 Hadoop 的管理員,你可以在集群中自行的定義從節(jié)點的機(jī)架數(shù)量。但是為什么這樣做會給你帶來麻煩呢?兩個關(guān)鍵的是:數(shù)據(jù)損失預(yù)防及網(wǎng)絡(luò)性能。別忘了,為了防止數(shù)據(jù)丟失,每塊數(shù)據(jù)都會拷貝在多個上。假如同一塊數(shù)據(jù)的多個拷貝都在同一個機(jī)架上,而恰巧的是這個機(jī)架出現(xiàn)了故障,那么這帶來的絕對是一團(tuán)糟。為了這樣的事情發(fā)生,則必須有人知道數(shù)據(jù)節(jié)點的位置,并根據(jù)實際情況在集群中作出明智的位置分配。這個人就是名稱節(jié)點。假使通個機(jī)架中兩臺對比不同機(jī)架的兩臺會有的帶寬更低的延時。大部分情況下這是真實存在的。機(jī)架轉(zhuǎn)換的上行帶寬一般都低于其下行帶寬。此外,

9、機(jī)架內(nèi)的通信的延時一般都低于跨機(jī)架的(也不是全部)。那么假如 Hadoop 能實現(xiàn)“Rack Awareness”的理念,那么在集群性能上無疑會有著顯著的提升!是的,它真的做到了!太棒了,對不對?但是掃興的事情發(fā)生了,首次使用你必須手動的去定義它。不斷的優(yōu)化,保持信息的準(zhǔn)確。假如機(jī)架轉(zhuǎn)換能夠自動的給名稱節(jié)點提供它的數(shù)據(jù)節(jié)點列表,這樣又完美了?或者反過來,數(shù)據(jù)節(jié)點可以自行的告知名稱節(jié)點他們所連接的機(jī)架轉(zhuǎn)換,這樣也的話也同樣完美。在括補(bǔ)結(jié)構(gòu)中網(wǎng)絡(luò)中,假如能知道名稱節(jié)點可以通過 OpenFlow器到節(jié)點的位置,那無疑是更加令人興奮的。準(zhǔn)備 HDFS 寫入現(xiàn)在 Client 已經(jīng)把 File.txt

10、分塊并做好了向集群中加載的準(zhǔn)備,下面先從 Block A 開始。Client 向名稱節(jié)點發(fā)出寫 File.txt 的請求,從名稱節(jié)點處獲得通行證,然后得到每塊數(shù)據(jù)目標(biāo)數(shù)據(jù)節(jié)點的列表。名稱節(jié)點使用的 Rack Awareness 數(shù)據(jù)來改變數(shù)據(jù)節(jié)點提供列表。規(guī)則就是對于每塊數(shù)據(jù) 3 份拷貝,總有兩份存在同一個機(jī)架上,另外一份則必須放到另一個機(jī)架上。所以給 Client 的列表都必須遵從這個規(guī)則。在 Client 將 File.txt 的“Block A”部分寫入集群之前,Client 還期待知道所有的目標(biāo)數(shù)據(jù)節(jié)點是否已準(zhǔn)備就緒。它將取出列表中給 Block A 準(zhǔn)備的第一個數(shù)據(jù)節(jié)點,打開 TCP

11、 50010 協(xié)議,并告訴數(shù)據(jù)節(jié)點,注意!準(zhǔn)備好接收 1 塊數(shù)據(jù),這里還有一份列表包括了數(shù)據(jù)節(jié)點 5 和數(shù)據(jù)節(jié)點 6,確保他們同樣已準(zhǔn)備就緒。然后再由 1 傳達(dá)到 5,接著 5 傳達(dá)到 6。數(shù)據(jù)節(jié)點將從同樣的 TCP 通道中響應(yīng)上一級令,只到 Client 收到原始數(shù)據(jù)節(jié)點 1的的“就緒”。只到此刻,Client 才真正的準(zhǔn)備在集群中加載數(shù)據(jù)塊。HDFS 載入通道當(dāng)數(shù)據(jù)塊寫入集群后,3 個(當(dāng)然數(shù)據(jù)節(jié)點個數(shù)參照上文的設(shè)置)數(shù)據(jù)節(jié)點將打開一個同步通道。這就意味著,當(dāng)一個數(shù)據(jù)節(jié)點接收到數(shù)據(jù)后,它同時將在通道中給下一個數(shù)據(jù)節(jié)點送上一份拷貝。這里同樣是一個借助 Rack Awareness 數(shù)據(jù)提升集

12、群性能的例子。注意到?jīng)]有,第二個和第三個數(shù)據(jù)節(jié)點在同一個機(jī)架中,這樣他們之間的傳輸就獲得了高帶寬和低延時。只到這個數(shù)據(jù)塊被的寫入 3 個節(jié)點中,下一個就才會開始。HDFS 通道載入當(dāng) 3 個節(jié)點都的接收到數(shù)據(jù)塊后,他們將給名稱節(jié)點個“Block Received”報告。并向通道返回“Success”消息,然后關(guān)閉TCP 回話。Client 收到接收的消息后會報告給名稱節(jié)點數(shù)據(jù)已接收。名稱節(jié)點將會更新它元數(shù)據(jù)中的節(jié)點位置信息。Client將會開啟下一個數(shù)據(jù)塊的處理通道,只到所有的數(shù)據(jù)塊都寫入數(shù)據(jù)節(jié)點。Hadoop 會使用大量的網(wǎng)絡(luò)帶寬和。代表性的處理一些 TB 級別的文件。使用 Hadoop 的

13、默認(rèn)配置,每個文件都會被三份。也就是 1TB 的文件將耗費(fèi) 3TB 的網(wǎng)絡(luò)傳輸及 3TB 的磁盤空間。Client 寫入跨度集群每個塊的管道完成后的文件被寫入到集群。如預(yù)期的文件被散布在整個集群的,每臺有一個相對較小的部分?jǐn)?shù)據(jù)。個文件的塊數(shù)越多,的的數(shù)據(jù)有可能。的 CPU和磁盤驅(qū)動器,意味著數(shù)據(jù)能得到的并行處理能力和更快的結(jié)果。這是建造大型的、寬的集群的背后的,為了數(shù)據(jù)處理、更快。當(dāng)數(shù)增加和集群增寬時,我們的網(wǎng)絡(luò)需要進(jìn)行適當(dāng)?shù)臄U(kuò)展。擴(kuò)展集群的另法是深入。就是在你的擴(kuò)展個磁盤驅(qū)動器和的 CPU,而不是增加的數(shù)量。在擴(kuò)展深度上,你把的注意力集中在用較少的來滿足的網(wǎng)絡(luò) I/O 需求上。在這個模型中,

14、你的 Hadoop 集群如何過渡到萬兆以太網(wǎng)節(jié)點成為一個重要的考慮因素。名稱節(jié)點名稱節(jié)點包含所有集群的文件系統(tǒng)元數(shù)據(jù)和監(jiān)督健康狀況的數(shù)據(jù)節(jié)點以及協(xié)調(diào)對數(shù)據(jù)的。這個名字節(jié)點是 HDFS 的器。它本身不擁有任何集群數(shù)據(jù)。這個名稱節(jié)點只知道塊一個文件,并在這些塊位于集群中。數(shù)據(jù)節(jié)點每 3 秒通過 TCP 信號交換向名稱節(jié)點檢測信號,使用相同的端定義名稱節(jié)點守護(hù)進(jìn)程,通常 TCP 9000。每 10 個檢測信號作為一個塊報告,那里的數(shù)據(jù)節(jié)點告知它的所有塊的名稱節(jié)點。塊報告名稱節(jié)點構(gòu)建它的元數(shù)據(jù)和確保第三塊副本存在不同的機(jī)架上存在于不同的節(jié)點上。名稱節(jié)點是 Hadoop 分布式文件系統(tǒng)(HDFS)的一個

15、關(guān)鍵組件。沒有它,客戶端將無法從 HDFS 寫入或文件,它就不可能去調(diào)度和執(zhí)行 Map Reduce 工作。正因為如此,電源、熱插拔風(fēng)扇、冗余網(wǎng)卡連接等等來裝備名稱節(jié)點和配置高度冗余的企業(yè)級服務(wù)器使一個不錯的想法。重新副本如果名稱節(jié)點停止從一個數(shù)據(jù)節(jié)點接收檢測信號,假定它已經(jīng),任何數(shù)據(jù)必須也消失了?;趬K從節(jié)點接受到報告,這個名稱節(jié)點知道哪個副本連同節(jié)點塊,并可決定重新這些塊到其他數(shù)據(jù)節(jié)點。它還將參考機(jī)架感知數(shù)據(jù),以保持在一個機(jī)架內(nèi)的兩個副本??紤]一下這個場景,整個機(jī)架的服務(wù)器網(wǎng)絡(luò)脫落,也許是因為一個機(jī)架交換機(jī)故障或電源故障。這個名稱節(jié)點將開始指示集群中的其余節(jié)點重新該機(jī)架中丟失的所有數(shù)據(jù)塊。

16、如果在那個機(jī)架中的每個服務(wù)器有 12TB 的數(shù)據(jù),這可能是數(shù)百個 TB 的數(shù)據(jù)需要開始穿越網(wǎng)絡(luò)。名稱節(jié)點Hadoop 服務(wù)器被稱為名稱節(jié)點。一個常見的誤解是,這個為名稱節(jié)點提供了一個高可用性的備份,這并非如此。名稱節(jié)點偶爾連接到名字節(jié)點,并獲取一個副本的名字節(jié)點內(nèi)存中的元數(shù)據(jù)和文件用于元數(shù)據(jù)。名稱節(jié)點在一個新的文件集中結(jié)合這些信息,并將其遞送回名稱節(jié)點,同時自身保留一份復(fù)本。如果名稱節(jié)點,名稱節(jié)點保留的文件可用于恢復(fù)名稱節(jié)點。從 HDFS 客戶端當(dāng)客戶想要從 HDFS一個文件,它再一次咨詢名稱節(jié)點,并要求提供文件塊的位置??蛻魪拿總€塊列表選擇一個數(shù)據(jù)節(jié)點和用 TCP 的 50010 端口一個塊

17、。直到前塊完成,它才會進(jìn)入下一個塊。從 HDFS 中數(shù)據(jù)節(jié)點有些情況下,一個數(shù)據(jù)節(jié)點守護(hù)進(jìn)程本身需要從 HDFS 中數(shù)據(jù)塊。一種這樣的情況是數(shù)據(jù)節(jié)點被要求處理本地沒有的數(shù)據(jù),因此它必須從網(wǎng)絡(luò)上的另一個數(shù)據(jù)節(jié)點檢索數(shù)據(jù),在它開始處理之前。另一個重要的例子是這個名稱節(jié)點的 Rack Awareness 認(rèn)知提供了最佳的網(wǎng)絡(luò)行為。當(dāng)數(shù)據(jù)節(jié)點詢問數(shù)據(jù)塊里名稱節(jié)點的位置時,名稱節(jié)點將檢查是否在同一機(jī)架中的另一種數(shù)據(jù)節(jié)點有數(shù)據(jù)。如果是這樣,這個名稱節(jié)點從檢索數(shù)據(jù)里提供了機(jī)架上的位置。該流程不需要遍歷兩個以上的交換機(jī)和擁擠的找到另一個機(jī)架中的數(shù)據(jù)。在機(jī)架上檢索的數(shù)據(jù)更快,數(shù)據(jù)處理就可以開始的更早,,工作完成

18、得更快。Map Task現(xiàn)在 file.txt 在集群中蔓延,我有機(jī)會提供極其快速和高效的并行處理的數(shù)據(jù)。包含 Hadoop 的并行處理框架被稱為 MapReduce,模型中命名之后的兩個步驟是 Map 和 Reduce。第一步是 Map 過程。這就是我們同時要求我們的他們本地的數(shù)據(jù)塊上來運(yùn)行一個計算。在這種情況下,我們要求我們的對“Refund”這個詞在 File.txt 的數(shù)據(jù)塊中出現(xiàn)的次數(shù)進(jìn)行計數(shù)。開始此過程,客戶端提交 Map Reduce 作業(yè)的 Job Tracker,詢問“多少次在 File.txt 中出現(xiàn) Refund”(意譯 Java 代碼)。Job Tracker名稱節(jié)點了

19、解哪些數(shù)據(jù)節(jié)點有 File.txt 塊。Job Tracker 提供了這些節(jié)點上運(yùn)行的 Task Tracker 與 Java 代碼需要在他們的本地數(shù)據(jù)上執(zhí)行的 Map 計算。這個 Task Tracker 啟動一個 Map 任務(wù)和監(jiān)視任務(wù)進(jìn)展。這 Task Tracker 提供了檢測信號并向Job Tracker 返回任務(wù)狀態(tài)。每個 Map 任務(wù)完成后,每個節(jié)點在其臨時本地中其本地計算的結(jié)果。這被稱作“中間數(shù)據(jù)”。 下一步將通過網(wǎng)絡(luò)傳輸此中間數(shù)據(jù)到 Reduce 任務(wù)最終計算節(jié)點上運(yùn)行。Map Task 非本地雖然 Job Tracker 總是試圖選擇與當(dāng)?shù)財?shù)據(jù)做 Map task 的節(jié)點,

20、但它可能并不總是能夠這樣做。其中一個可能是因為所有的節(jié)點與本地數(shù)據(jù),已經(jīng)有太多的其他任務(wù)運(yùn)行,并且不能接受了。在這種情況下, Job Tracker 將查閱名稱節(jié)點的 Rack Awareness 知識,可推薦同一機(jī)架中的其他節(jié)點的名稱節(jié)點。作業(yè)將把這個任務(wù)交給同一機(jī)架中的一個節(jié)點,節(jié)點去尋找的數(shù)據(jù)時,它需要的名稱節(jié)點將指示其機(jī)架中的另一個節(jié)點來獲取數(shù)據(jù)。Reduce Task 從 Map Tasks 計算接收到的數(shù)據(jù)第二階段的 Map Reduce 框架稱為 Reduce。上的 Map 任務(wù)已經(jīng)完成了和生成它們的中間數(shù)據(jù)?,F(xiàn)在我們需要收集所有的這些中間數(shù)據(jù),組合并提純以便進(jìn)一步處理,這樣我們

21、會有一個最終結(jié)果。Job Tracker 在集群中的任何一個節(jié)點上開始一個 Reduce 任務(wù),并指示 Reduce 任務(wù)從所有已完成的 Map 任務(wù)中獲取中間數(shù)據(jù)。Map 任務(wù)可能幾乎同時應(yīng)對 Reducer,導(dǎo)致讓你一下子有大量的節(jié)點TCP 數(shù)據(jù)到一個節(jié)點。這種流量狀況通常被稱為“Incast”或者“fan-in”。對于網(wǎng)絡(luò)處理大量的 incast 條件,其重要的網(wǎng)絡(luò)交換機(jī)擁有精心設(shè)計的內(nèi)部流量管理能力,以及足夠的緩沖區(qū)(不太大也不能太?。?。Reducer 任務(wù)現(xiàn)在已經(jīng)從 Map 任務(wù)里收集了所有的中間數(shù)據(jù),可以開始最后的計算階段。在本例中,我們只需添加出現(xiàn)“Refund”這個詞的總數(shù),并

22、將結(jié)果寫入到一個名為 Results 的 txt 文件里。這個名為 Results 的 txt 文件,被寫入到 HDFS 以下我們已經(jīng)涵蓋的進(jìn)程中,把文件分成塊,流水線這些塊等。當(dāng)完成時,客戶機(jī)可以從 HDFS 和被認(rèn)為是完整的工作里Results.txt。我們簡單的字?jǐn)?shù)統(tǒng)計工作并導(dǎo)致大量的中間數(shù)據(jù)在網(wǎng)絡(luò)上傳輸。然而,其他工作可能會產(chǎn)生大量的中間數(shù)據(jù),比如對 TB 級數(shù)據(jù)進(jìn)行排序。如果你是一個勤奮的網(wǎng)絡(luò)管理員,你將了解關(guān)于 Map Reduce 和你的集群將運(yùn)行的作業(yè)類型,以及作業(yè)類型如何影響你的網(wǎng)絡(luò)流量。如果你是一個 Hadoop 網(wǎng)絡(luò)明星,你甚至能夠提出更好的代碼來解決 Map Reduce 任務(wù),以優(yōu)化網(wǎng)絡(luò)的性能,從而加快工作完工時間。不平衡的 Hadoop 集群Hadoop 可以為你的組織提供一個真正的,它讓你身邊的數(shù)據(jù)開發(fā)出了很多之前未

溫馨提示

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

評論

0/150

提交評論