• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 15, comments - 10, trackbacks - 0, articles - 0

            跨機房的hadoop集群

            Posted on 2013-10-27 23:28 whspecial 閱讀(5263) 評論(0)  編輯 收藏 引用 所屬分類: hadoop

            這是來自于阿里技術嘉年華的一個分享,因為在百度也考慮過類似的事情,所以聽得比較有感悟,這里把相關內容整理一下。

            首先尊重版權,還是把原鏈接和作者貼上:

            http://adc.alibabatech.org/carnival/history/schedule/2013/detail/main/286?video=0

            來自于阿里吳威工程師的分享

             

            首先需要說明一點,跨機房hadoop可能應用場景并不是很多,國內像BAT這種巨頭也許需要,但是大部分的中小公司也許并不需要這個,也許這是個屠龍之技,呵呵。

            把這個問題分三段來講,第一段是問題出現的背景,第二段是解決該問題的難點,第三段是最終的解決方案。

            (一) 背景:

            先要看下為什么需要做一個跨機房的大集群?

            大集群的優點在于數據管理和授權容易(這個問題在一個多部門的大公司還是很重要的);跨部門的使用數據容易,無需重復拉取數據。

            在集群達到一定規模時,單機房(機房內的容量是有限的)已經無法滿足集群的需求了,要想一勞永逸的解決問題,需要建設一個跨機房的hadoop集群。

            (二)技術挑戰:

            2.1 NameNode的性能問題:

                     在管理一個巨大的hadoop集群時,由于原始的Namenode是單節點,因此會成為一個性能瓶頸,遇到的性能問題主要包括兩方面:存儲容量問題(存儲元數據)和計算壓力(處理rpc請求,修改內存樹時候需要全局鎖)問題。

                     其中存儲容量問題可以依賴內存的垂直擴展來解決,但是計算壓力卻很難通過提升硬件來解決(因為目前廠商的主要發展方向是多核,而非提高主頻)

            2.2機房之間的網絡限制:

                     機房之間的網絡永遠是個硬件條件的限制,跨機房的網絡傳輸帶來了數據延時和帶寬限制:

            1, 延時一般是在10ms之內,而hadoop上大部分運行的是離線作業,基本可接受

            2, 帶寬限制的問題比較大,因為單機房內的點對點帶寬一般是在1Gbps,而機房之間的帶寬確在20Mbps左右,非常有限。

            2.3資源組之間的管理

                     每個部門可以看做一個資源組,它們可能會互相使用對方的數據,因此如何規劃計算和存儲的位置就很重要,否則會在多個機房之間出現大量的數據拷貝。

            (三)解決方案:

            先看下整個跨集群hadoop的架構圖:


             

            重點介紹里面三點,也就是和上面三個問題相對應的:

            1, 可以看到這里畫出了兩個NNnamenode),它們實際上還是屬于一個hadoop集群,這是業界里的一個解決方案:HDFS Fedaration,它為了解決元數據節點性能問題;

            2, 可以看到這里有一個cross node節點,它是用來在兩個機房之間同步數據的,它的設計考慮到了機房間的網絡限制;

            3, 最后是groupAgroupB,這是為了解決數據產出方和使用方關系來用的。

            3.1 Federation

            Federation相關資料見:

            http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/Federation.html#HDFS_Federation


            為了水平擴展Namenodefederation使用了多個互相獨立的namenode。它們之間互相不需要通信,每個datenode需要向全部namenode注冊并發送信息。

            BlockPool是屬于一個namenodeblock集合,每個blockpool之間也是互相獨立的。

                     federation里,有一個需要關注的問題,就是多個namenode的地址如何對用戶進行透明?它采用的解決方案是目錄樹掛載的方案(社區有個viewFS,應該就是為了解決這個問題):熟悉linux或者nfs的朋友應該都知道mount這個概念,目錄樹掛載就是這個意思。

            不過使用目錄樹掛載也存在著一個問題,就是各個子目錄下的存儲資源需要人為的介入管理,不能出現嚴重的不均。

            3.2 crossNode

                     機房間的網絡限制要求不能出現大規模、長時間的數據拷貝,需要一個專門管理機房間數據拷貝的進程,叫做crossNode。它是獨立部署的一個節點,和元數據節點是分離的。

                     它能提供的功能概括來說主要包括以下三點:

            a) 根據預置的跨機房文件,進行數據拷貝

            b) 處理實時的數據拷貝請求

            c) 進行跨機房的數據流量控制

            如何得知跨機房文件列表?

                     由于離線任務基本都是定時觸發的,可以根據對歷史作業的分析來形成一個跨機房文件列表

            3.3   資源組之間的管理

            各個資源組之間存在數據的依賴,我們希望通過資源組管理,能實現大部分任務在本機房內產出數據,只有少量跨機房產出數據;大部分任務讀取本機房的數據副本,只有少量跨機房讀取數據。

            為了標識資源組之間的數據依賴性,定義一個資源組之間的距離概念:一個資源組訪問另一個資源組的數據量越多,則兩者的距離越近,應該將距離接近的資源組放在同一個機房內。

            為了讓計算和產出盡可能地靠近,使用一個MRProxy,對于不同類型的任務做不同處理:

            a)            離線計算:跨機房列表中的數據正在傳輸中(DC1->DC2),DC2上的 Job 被暫停調度,等待傳輸完畢

            b)            Ad-hoc查詢:DC2上的 Job 需要讀DC1上的數據,Job暫停調度,通知 CrossNode,數據傳輸完畢后繼續調度

            c)             特殊情況:跨機房數據 JoinDC1大表,DC2小表,Job 調度到DC1上,跨機房直接讀取DC2數據,無需等待

             

            由于是根據視頻和ppt整理,并沒有代碼或者文檔,所以可能有些地方的理解有偏差,歡迎來提意見~

            精品久久人人做人人爽综合| avtt天堂网久久精品| 精品一久久香蕉国产线看播放| 午夜不卡888久久| 久久影视综合亚洲| 久久久久亚洲精品天堂| 国产无套内射久久久国产| 国内精品久久久久影院亚洲| 99国产精品久久久久久久成人热| 国产激情久久久久影院| 中文无码久久精品| 久久久99精品一区二区| 久久久久久亚洲Av无码精品专口| www亚洲欲色成人久久精品| 精品久久人人爽天天玩人人妻| 亚洲国产精品一区二区久久| 久久精品国产亚洲AV香蕉| 久久国产精品免费一区二区三区| 亚洲欧美伊人久久综合一区二区| 久久国产V一级毛多内射| 国产一级持黄大片99久久| 久久人人爽人人人人片av| 色婷婷久久久SWAG精品| 99热热久久这里只有精品68| 久久精品国产99久久无毒不卡| 久久久久久久久久久久久久| 人妻丰满?V无码久久不卡| 久久亚洲中文字幕精品一区四| 亚洲国产精品久久66| 久久免费高清视频| 久久96国产精品久久久| 久久久久成人精品无码中文字幕 | 国产ww久久久久久久久久| 色婷婷综合久久久中文字幕| 无码人妻久久一区二区三区免费丨| 亚洲?V乱码久久精品蜜桃 | 久久精品成人一区二区三区| 91精品日韩人妻无码久久不卡| 91精品国产91久久久久久青草| 久久国产精品久久久| 国产精品永久久久久久久久久 |