<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 28, comments - 37, trackbacks - 0, articles - 0

    2011年11月21日


    淘寶招聘hadoop工程師若干, 面向在校生(2014年畢業(yè)),工作地點(diǎn):杭州或北京

    Hadoop研發(fā)工程師
    職位描述
    您將負(fù)責(zé):
    1.預(yù)研、開發(fā)、測(cè)試hdfs/mapreduce/hive/hbase的功能、性能和擴(kuò)展;
    2.對(duì)有助于提升集群處理能力/高可用性/高擴(kuò)展性的各種解決方案進(jìn)行跟蹤和落地;
    3.解決海量數(shù)據(jù)不斷增長面臨的挑戰(zhàn),解決業(yè)務(wù)需求。

    您需要具備:
    1、熟練運(yùn)用java語言;
    2、熟悉jvm運(yùn)行機(jī)制、熟悉linux;
    3、至少熟悉hadoop、hbase、hive等軟件之一;

     

    有意者請(qǐng)發(fā)送郵件到 yuling.sh@taobao.com 

    posted @ 2013-09-15 18:21 俞靈 閱讀(957) | 評(píng)論 (1)編輯 收藏


    mapreduce,一個(gè)jobmap個(gè)數(shù), 每個(gè)map處理的數(shù)據(jù)量是如何決定的呢? 另外每個(gè)map又是如何讀取輸入文件的內(nèi)容呢? 用戶是否可以自己決定輸入方式, 決定map個(gè)數(shù)呢? 這篇文章將詳細(xì)講述hadoop中各種InputFormat的功能和如何編寫自定義的InputFormat.

     

    簡(jiǎn)介: mapreduce作業(yè)會(huì)根據(jù)輸入目錄產(chǎn)生多個(gè)map任務(wù), 通過多個(gè)map任務(wù)并行執(zhí)行來提高作業(yè)運(yùn)行速度, 但如果map數(shù)量過少, 并行量低, 作業(yè)執(zhí)行慢, 如果map數(shù)過多, 資源有限, 也會(huì)增加調(diào)度開銷. 因此, 根據(jù)輸入產(chǎn)生合理的map數(shù), 為每個(gè)map分配合適的數(shù)據(jù)量, 能有效的提升資源利用率, 并使作業(yè)運(yùn)行速度加快.

        mapreduce, 每個(gè)作業(yè)都會(huì)通過 InputFormat來決定map數(shù)量. InputFormat是一個(gè)接口, 提供兩個(gè)方法:

    InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;

    RecordReader<K, V> getRecordReader(InputSplit split,

                                         JobConf job,

                                         Reporter reporter) throws IOException;

        其中getSplits方法會(huì)根據(jù)輸入目錄產(chǎn)生InputSplit數(shù)組, 每個(gè)InputSplit會(huì)相應(yīng)產(chǎn)生一個(gè)map任務(wù), map的輸入定義在InputSplit. getRecordReader方法返回一個(gè)RecordReader對(duì)象, RecordReader決定了map任務(wù)如何讀取輸入數(shù)據(jù), 例如一行一行的讀取還是一個(gè)字節(jié)一個(gè)字節(jié)的讀取, 等等.

        下圖是InputFormat的實(shí)現(xiàn)類:

           (暫時(shí)無法上傳)

        這理詳細(xì)介紹FileInputFormatCombineFileInputFormat, 其它不常用,有興趣的可以自己查看hadoop源碼.


     

    FileInputFormat(舊接口org.apache.hadoop.mapred)

     

    mapreduce默認(rèn)使用TextInputFormatTextInputFormat沒有實(shí)現(xiàn)自己的getSplits方法,繼承于FileInputFormat, 因此使用了FileInputFormat的.

    org.apache.hadoop.mapred.FileInputFormatgetSplits流程:

    兩個(gè)配置

    mapred.min.split.size        (一個(gè)map最小輸入長度),

    mapred.map.tasks                (推薦map數(shù)量)

    如何決定每個(gè)map輸入長度呢? 首先獲取輸入目錄下所有文件的長度和, 除以mapred.map.tasks得到一個(gè)推薦長度goalSize, 然后通過式子: Math.max(minSize, Math.min(goalSize, blockSize))決定map輸入長度. 這里的minSizemapred.min.split.size, blockSize為相應(yīng)文件的block長度. 這式子能保證一個(gè)map的輸入至少大于mapred.min.split.size, 對(duì)于推薦的map長度,只有它的長度小于blockSize且大于mapred.min.split.size才會(huì)有效果. 由于mapred.min.split.size默認(rèn)長度為1, 因此通常情況下只要小于blockSize就有效果,否則使用blockSize做為map輸入長度.

    因此, 如果想增加map數(shù), 可以把mapred.min.split.size調(diào)小(其實(shí)默認(rèn)值即可), 另外還需要把mapred.map.tasks設(shè)置大.

    如果需要減少map數(shù),可以把mapred.min.split.size調(diào)大, 另外把mapred.map.tasks調(diào)小.

    這里要特別指出的是FileInputFormat會(huì)讓每個(gè)輸入文件至少產(chǎn)生一個(gè)map任務(wù), 因此如果你的輸入目錄下有許多文件, 而每個(gè)文件都很小, 例如幾十kb, 那么每個(gè)文件都產(chǎn)生一個(gè)map會(huì)增加調(diào)度開銷. 作業(yè)變慢.

    那么如何防止這種問題呢? CombineFileInputFormat能有效的減少map數(shù)量.


    FileInputFormat(新接口org.apache.hadoop.mapreduce.lib.input)

    Hadoop 0.20開始定義了一套新的mapreduce編程接口, 使用新的FileInputFormat, 它與舊接口下的FileInputFormat主要區(qū)別在于, 它不再使用mapred.map.tasks, 而使用mapred.max.split.size參數(shù)代替goalSize, 通過Math.max(minSize, Math.min(maxSize, blockSize))決定map輸入長度, 一個(gè)map的輸入要大于minSize,小于

    Math.min(maxSize, blockSize).

        若需增加map數(shù),可以把mapred.min.split.size調(diào)小,mapred.max.split.size調(diào)大. 若需減少map數(shù), 可以把mapred.min.split.size調(diào)大, 并把mapred.max.split.size調(diào)小.


    CombineFileInputFormat

    顧名思義, CombineFileInputFormat的作用是把許多文件合并作為一個(gè)map的輸入.

    在它之前,可以使用MultiFileInputFormat,不過其功能太簡(jiǎn)單, 以文件為單位,一個(gè)文件至多分給一個(gè)map處理, 如果某個(gè)目錄下有許多小文件, 另外還有一個(gè)超大文件, 處理大文件的map會(huì)嚴(yán)重偏慢.

    CombineFileInputFormat是一個(gè)被推薦使用的InputFormat. 它有三個(gè)配置:

    mapred.min.split.size.per.node 一個(gè)節(jié)點(diǎn)上split的至少的大小

    mapred.min.split.size.per.rack   一個(gè)交換機(jī)下split至少的大小

    mapred.max.split.size             一個(gè)split最大的大小

    它的主要思路是把輸入目錄下的大文件分成多個(gè)map的輸入, 并合并小文件, 做為一個(gè)map的輸入. 具體的原理是下述三步:

    1.根據(jù)輸入目錄下的每個(gè)文件,如果其長度超過mapred.max.split.size,block為單位分成多個(gè)split(一個(gè)split是一個(gè)map的輸入),每個(gè)split的長度都大于mapred.max.split.size, 因?yàn)橐?/span>block為單位, 因此也會(huì)大于blockSize, 此文件剩下的長度如果大于mapred.min.split.size.per.node, 則生成一個(gè)split, 否則先暫時(shí)保留.

    2. 現(xiàn)在剩下的都是一些長度效短的碎片,把每個(gè)rack下碎片合并, 只要長度超過mapred.max.split.size就合并成一個(gè)split, 最后如果剩下的碎片比mapred.min.split.size.per.rack, 就合并成一個(gè)split, 否則暫時(shí)保留.

    3. 把不同rack下的碎片合并, 只要長度超過mapred.max.split.size就合并成一個(gè)split, 剩下的碎片無論長度, 合并成一個(gè)split.

    舉例: mapred.max.split.size=1000

         mapred.min.split.size.per.node=300

          mapred.min.split.size.per.rack=100

    輸入目錄下五個(gè)文件,rack1下三個(gè)文件,長度為2050,1499,10, rack2下兩個(gè)文件,長度為1010,80. 另外blockSize500.

    經(jīng)過第一步, 生成五個(gè)split: 1000,1000,1000,499,1000. 剩下的碎片為rack1:50,10; rack210:80

    由于兩個(gè)rack下的碎片和都不超過100, 所以經(jīng)過第二步, split和碎片都沒有變化.

    第三步,合并四個(gè)碎片成一個(gè)split, 長度為150.

     

    如果要減少map數(shù)量, 可以調(diào)大mapred.max.split.size, 否則調(diào)小即可.

    其特點(diǎn)是: 一個(gè)塊至多作為一個(gè)map的輸入,一個(gè)文件可能有多個(gè)塊,一個(gè)文件可能因?yàn)閴K多分給做為不同map的輸入, 一個(gè)map可能處理多個(gè)塊,可能處理多個(gè)文件。


    編寫自己的InputFormat

     

        待續(xù)


     

    posted @ 2012-07-03 22:17 俞靈 閱讀(16460) | 評(píng)論 (2)編輯 收藏

    Yarn做為hadoop下一代集群資源管理和調(diào)度平臺(tái), 其上能支持多種計(jì)算框架, 本文就簡(jiǎn)要介紹一下這些計(jì)算框架.


    1.       MapReduce

    首先是大家熟悉的mapreduce, MR2之前, hadoop包括HDFSmapreduce, 做為hadoop上唯一的分布式計(jì)算框架, 其優(yōu)點(diǎn)是用戶可以很方便的編寫分布式計(jì)算程序, 并支持許多的應(yīng)用, hive, mahout, pig. 但是其缺點(diǎn)是無法充分利用集群資源, 不支持DAG, 迭代式計(jì)算等. 為了解決這些問題, yahoo提出了Yarn (next generation mapreduce), 一個(gè)分布式集群集群資源管理和調(diào)度平臺(tái). 這樣除了mapreduce, 還可以支持各種計(jì)算框架.

    2.       Spark

    Spark是一種與mapreduce相似的開源計(jì)算框架, 不同之處在于Spark在某些工作負(fù)載方面表現(xiàn)更優(yōu), 因?yàn)樗褂昧藘?nèi)存分布式數(shù)據(jù)集, 另外除了提供交互式查詢外, 它還可以優(yōu)化迭代工作負(fù)載.

    3.       Apache HAMA

    Apache Hama 是一個(gè)運(yùn)行在HDFS上的BSP(Bulk Synchronous Parallel大容量同步并行) 計(jì)算框架, 主要針對(duì)大規(guī)模科學(xué)計(jì)算,如矩陣, 圖像, 網(wǎng)絡(luò)算法等.當(dāng)前它有一下功能:

    • 作業(yè)提交和管理接口
    • 單節(jié)點(diǎn)上運(yùn)行多個(gè)任務(wù)
    • 輸入/輸出格式化
    • 備份恢復(fù)
    • 支持通過Apache Whirr運(yùn)行在云端
    • 支持與Yarn一起運(yùn)行

    4.       Apache Giraph

    圖像處理平臺(tái)上運(yùn)行這大型算法(page rank, shared connections, personalization-based popularity )已經(jīng)很流行, Giraph采用BSP模型(bulk-synchronous parallel model),可用于等迭代類算法。

    5.       Open MPI

    這是一個(gè)高性能計(jì)算函數(shù)庫,通常在HPCHigh Performance Computing)中采用,與MapReduce相比,其性能更高,用戶可控性更強(qiáng),但編程復(fù)雜,容錯(cuò)性差,可以說,各有所長,在實(shí)際應(yīng)用中,針對(duì)不同 該應(yīng)用會(huì)采用MPI或者MapReduce

    6.       Apache HBase

    HBase是一個(gè)hadoop數(shù)據(jù)庫, 其特點(diǎn)是分布式,可擴(kuò)展的,存儲(chǔ)大數(shù)據(jù)。當(dāng)有需要隨機(jī),實(shí)時(shí)讀寫的大數(shù)據(jù)時(shí), 使用HBase很適合.

    本文參考:

    http://wiki.apache.org/hadoop/PoweredByYarn
    http://www.oschina.net/p/open+mpi

    http://incubator.apache.org/hama/
    http://incubator.apache.org/giraph/

    http://hbase.apache.org/

    posted @ 2012-06-03 11:43 俞靈 閱讀(3655) | 評(píng)論 (0)編輯 收藏

    轉(zhuǎn)載
    http://fujun.sinaapp.com/2011/11/02/68.html

    第一步,打開終端,看看你的顯卡Ubuntu能認(rèn)出多少顯示分辨率設(shè)置,輸入命令

    wufujun@wufujun-VirtualBox:~$ xrandr

    系統(tǒng)給出的結(jié)果

    Screen 0: minimum 64 x 64, current 1024 x 768, maximum 32000 x 32000
    VBOX0 connected 1024×768+0+0 0mm x 0mm
    1024×768 60.0 + 60.0
    1600×1200 60.0
    1440×1050 60.0
    1280×960 60.0
    800×600 60.0
    640×480 60.0

    這里可以看到,沒有16:9的的分辨率設(shè)置

    第二步,用cvt命令測(cè)試1368×768是否可用

    wufujun@wufujun-VirtualBox:~$ cvt 1368 768

    顯示結(jié)果如下
    # 1368×768 59.88 Hz (CVT) hsync: 47.79 kHz; pclk: 85.86 MHz
    Modeline “1368x768_60.00″ 85.25 1368 1440 1576 1784 768 771 781 798 -hsync +vsync

    從這個(gè)結(jié)果里可以到,16:9的分辨率是可以用的

    第三步 輸入

    wufujun@wufujun-VirtualBox:~$ sudo xrandr --newmode "1368x768" 85.86 1368 1440 1576 1784 768 771 781 798 -hsync +vsync

    建立新的分辨率模式1368×768,把剛才cvt得到的數(shù)據(jù)寫進(jìn)參數(shù)

    第四步 繼續(xù)輸入

    sudo xrandr --addmode VBOX0 "1368x768"

    給當(dāng)前顯示器VBOX0增加1368×768分辨率設(shè)置

    做完以上操作后,可以在”顯示“設(shè)置里面看到顯示的分辨率列表中多了一個(gè) 1368×768(16:9)的選項(xiàng)。選中這個(gè)選項(xiàng),點(diǎn)擊應(yīng)用,完美的寬屏顯示回來了!

    經(jīng)過測(cè)試,上面的方法做完以后,每次注銷后就又變回了4:3的比例,而且會(huì)有的報(bào)錯(cuò),沒辦法,按上面的修改完畢后,還要再修改一下/etc/X11/xorg.conf這個(gè)文件,這個(gè)配置文件在現(xiàn)在的版里已經(jīng)取消了,所以需要我們新建一個(gè)


    $ sudo gedit /etc/X11/xorg.conf

    編輯內(nèi)容為:

    Section "Device"
    Identifier "Configured Video Device"
    EndSection

    Section "Monitor"
    Identifier "Configured Monitor"
    Modeline "1368x768_60.00" 85.86 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync
    EndSection

    Section "Screen"
    Identifier "Default Screen"
    Monitor "Configured Monitor"
    Device "Configured Video Device"
    SubSection "Display"
    Modes "1368x768@60"
    EndSubSection
    EndSection

    其中 Modeline “1368x768_60.00″ 85.86 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync 就是用$ cvt 1368 768得到的值。也可以用$ gtf 1368 768 60命令來得到這個(gè)Modeline的值,這個(gè)命令中,1368 768是分辨率 60為刷新率,用這個(gè)命令得到的值可能會(huì)更為準(zhǔn)確一些。

    SubSection "Display"
    Modes "1368x768@60"
    EndSubSection

    這段是設(shè)置默認(rèn)顯示最佳分辨率。

    注意這段文件中的一些規(guī)則

    Section “Device”區(qū)塊中,Identifier指定了顯卡的唯一名稱,這個(gè)名稱可以隨便取,但一定要與Section “Screen”區(qū)塊中的device選項(xiàng)中的名稱相同。在Section “Monitor”區(qū)塊中,Identifier指定了顯示器的唯一名稱,這個(gè)名稱可以隨便取,但一定要與Section “Screen”區(qū)塊中的Monitor選項(xiàng)中所指定的名稱相同。Section “Screen”區(qū)塊中的Identifier選項(xiàng),指定了這個(gè)顯卡與顯示器相結(jié)合的唯一名稱。這個(gè)名稱也可以隨便取的。這個(gè)名稱需要與Section “ServerLayout” 區(qū)塊中的名稱相同。這個(gè)Section “ServerLayout” 區(qū)塊我們一般不必編寫

    posted @ 2012-05-24 14:46 俞靈 閱讀(2882) | 評(píng)論 (0)編輯 收藏

         摘要:      最近這些天學(xué)習(xí)了classLoader的原理, 原因是因?yàn)榉?wù)器上的一個(gè)java進(jìn)程啟動(dòng)時(shí)加載兩個(gè)不同版本的jar包, 含有相同名字的類, 而且服務(wù)端的jar包排在前面, 我上傳的jar包排在后面, 于是每次都使用服務(wù)端的jar包, 我的jar包便無法生效, 因此希望修改classLader, 讓它按相反的順序加載jar包.  ...  閱讀全文

    posted @ 2012-05-20 19:43 俞靈 閱讀(5658) | 評(píng)論 (1)編輯 收藏

         摘要: High Availability for the HDFS Namenode Sanjay Radia, Suresh Srinivas Yahoo! Inc  (本文為namdnoe HA的設(shè)計(jì)文檔翻譯) 1.       問題闡述 有許多方法可以改善HDFS Namednoe(NN)的可用性,包括減少啟動(dòng)時(shí)間,更...  閱讀全文

    posted @ 2012-03-24 21:38 俞靈 閱讀(3205) | 評(píng)論 (2)編輯 收藏

    本文轉(zhuǎn)自:
    http://blog.csdn.net/zhouysh/article/details/304767

    JAVA代碼編寫的30條建議
    (1) 類名首字母應(yīng)該大寫。字段、方法以及對(duì)象(句柄)的首字母應(yīng)小寫。對(duì)于所有標(biāo)識(shí)符,其中包含的所有單詞都應(yīng)緊靠在一起,而且大寫中間單詞的首字母。例如:
    ThisIsAClassName
    thisIsMethodOrFieldName
    若在定義中出現(xiàn)了常數(shù)初始化字符,則大寫static final基本類型標(biāo)識(shí)符中的所有字母。這樣便可標(biāo)志出它們屬于編譯期的常數(shù)。
    Java包(Package)屬于一種特殊情況:它們?nèi)际切懽帜福幢阒虚g的單詞亦是如此。對(duì)于域名擴(kuò)展名稱,如com,org,net或者edu等,全部都應(yīng)小寫(這也是Java 1.1和Java 1.2的區(qū)別之一)。

    (2) 為了常規(guī)用途而創(chuàng)建一個(gè)類時(shí),請(qǐng)采取"經(jīng)典形式",并包含對(duì)下述元素的定義:

    equals()
    hashCode()
    toString()
    clone()(implement Cloneable)
    implement Serializable

    (3) 對(duì)于自己創(chuàng)建的每一個(gè)類,都考慮置入一個(gè)main(),其中包含了用于測(cè)試那個(gè)類的代碼。為使用一個(gè)項(xiàng)目中的類,我們沒必要?jiǎng)h除測(cè)試代碼。若進(jìn)行了任何形式的改動(dòng),可方便地返回測(cè)試。這些代碼也可作為如何使用類的一個(gè)示例使用。

    (4) 應(yīng)將方法設(shè)計(jì)成簡(jiǎn)要的、功能性單元,用它描述和實(shí)現(xiàn)一個(gè)不連續(xù)的類接口部分。理想情況下,方法應(yīng)簡(jiǎn)明扼要。若長度很大,可考慮通過某種方式將其分割成較短的幾個(gè)方法。這樣做也便于類內(nèi)代碼的重復(fù)使用(有些時(shí)候,方法必須非常大,但它們?nèi)詰?yīng)只做同樣的一件事情)。

    (5) 設(shè)計(jì)一個(gè)類時(shí),請(qǐng)?jiān)O(shè)身處地為客戶程序員考慮一下(類的使用方法應(yīng)該是非常明確的)。然后,再設(shè)身處地為管理代碼的人考慮一下(預(yù)計(jì)有可能進(jìn)行哪些形式的修改,想想用什么方法可把它們變得更簡(jiǎn)單)。
    (6) 使類盡可能短小精悍,而且只解決一個(gè)特定的問題。下面是對(duì)類設(shè)計(jì)的一些建議:
    ■一個(gè)復(fù)雜的開關(guān)語句:考慮采用"多形"機(jī)制
    ■數(shù)量眾多的方法涉及到類型差別極大的操作:考慮用幾個(gè)類來分別實(shí)現(xiàn)
    ■許多成員變量在特征上有很大的差別:考慮使用幾個(gè)類

    (7) 讓一切東西都盡可能地"私有"--private。可使庫的某一部分"公共化"(一個(gè)方法、類或者一個(gè)字段等等),就永遠(yuǎn)不能把它拿出。若強(qiáng)行拿出,就可 能破壞其他人現(xiàn)有的代碼,使他們不得不重新編寫和設(shè)計(jì)。若只公布自己必須公布的,就可放心大膽地改變其他任何東西。在多線程環(huán)境中,隱私是特別重要的一個(gè) 因素--只有private字段才能在非同步使用的情況下受到保護(hù)。

    (8) 謹(jǐn)惕"巨大對(duì)象綜合癥"。對(duì)一些習(xí)慣于順序編程思維、且初涉OOP領(lǐng)域的新手,往往喜歡先寫一個(gè)順序執(zhí)行的程序,再把它嵌入一個(gè)或兩個(gè)巨大的對(duì)象里。根據(jù)編程原理,對(duì)象表達(dá)的應(yīng)該是應(yīng)用程序的概念,而非應(yīng)用程序本身。

    (9) 若不得已進(jìn)行一些不太雅觀的編程,至少應(yīng)該把那些代碼置于一個(gè)類的內(nèi)部。

    (10) 任何時(shí)候只要發(fā)現(xiàn)類與類之間結(jié)合得非常緊密,就需要考慮是否采用內(nèi)部類,從而改善編碼及維護(hù)工作(參見第14章14.1.2小節(jié)的"用內(nèi)部類改進(jìn)代碼")。

    (11) 盡可能細(xì)致地加上注釋,并用javadoc注釋文檔語法生成自己的程序文檔。

    (12) 避免使用"魔術(shù)數(shù)字",這些數(shù)字很難與代碼很好地配合。如以后需要修改它,無疑會(huì)成為一場(chǎng)噩夢(mèng),因?yàn)楦静恢?100"到底是指"數(shù)組大小"還是"其他 全然不同的東西"。所以,我們應(yīng)創(chuàng)建一個(gè)常數(shù),并為其使用具有說服力的描述性名稱,并在整個(gè)程序中都采用常數(shù)標(biāo)識(shí)符。這樣可使程序更易理解以及更易維護(hù)。

    (13) 涉及構(gòu)建器和異常的時(shí)候,通常希望重新丟棄在構(gòu)建器中捕獲的任何異常--如果它造成了那個(gè)對(duì)象的創(chuàng)建失敗。這樣一來,調(diào)用者就不會(huì)以為那個(gè)對(duì)象已正確地創(chuàng)建,從而盲目地繼續(xù)。

    (14) 當(dāng)客戶程序員用完對(duì)象以后,若你的類要求進(jìn)行任何清除工作,可考慮將清除代碼置于一個(gè)良好定義的方法里,采用類似于cleanup()這樣的名字,明確表 明自己的用途。除此以外,可在類內(nèi)放置一個(gè)boolean(布爾)標(biāo)記,指出對(duì)象是否已被清除。在類的finalize()方法里,請(qǐng)確定對(duì)象已被清除, 并已丟棄了從RuntimeException繼承的一個(gè)類(如果還沒有的話),從而指出一個(gè)編程錯(cuò)誤。在采取象這樣的方案之前,請(qǐng)確定 finalize()能夠在自己的系統(tǒng)中工作(可能需要調(diào)用System.runFinalizersOnExit(true),從而確保這一行為)。

    (15) 在一個(gè)特定的作用域內(nèi),若一個(gè)對(duì)象必須清除(非由垃圾收集機(jī)制處理),請(qǐng)采用下述方法:初始化對(duì)象;若成功,則立即進(jìn)入一個(gè)含有finally從句的try塊,開始清除工作。

    (16) 若在初始化過程中需要覆蓋(取消)finalize(),請(qǐng)記住調(diào)用super.finalize()(若Object屬于我們的直接超類,則無此必 要)。在對(duì)finalize()進(jìn)行覆蓋的過程中,對(duì)super.finalize()的調(diào)用應(yīng)屬于最后一個(gè)行動(dòng),而不應(yīng)是第一個(gè)行動(dòng),這樣可確保在需要 基礎(chǔ)類組件的時(shí)候它們依然有效。

    (17) 創(chuàng)建大小固定的對(duì)象集合時(shí),請(qǐng)將它們傳輸至一個(gè)數(shù)組(若準(zhǔn)備從一個(gè)方法里返回這個(gè)集合,更應(yīng)如此操作)。這樣一來,我們就可享受到數(shù)組在編譯期進(jìn)行類型檢查的好處。此外,為使用它們,數(shù)組的接收者也許并不需要將對(duì)象"造型"到數(shù)組里。

    (18) 盡量使用interfaces,不要使用abstract類。若已知某樣?xùn)|西準(zhǔn)備成為一個(gè)基礎(chǔ)類,那么第一個(gè)選擇應(yīng)是將其變成一個(gè)interface(接 口)。只有在不得不使用方法定義或者成員變量的時(shí)候,才需要將其變成一個(gè)abstract(抽象)類。接口主要描述了客戶希望做什么事情,而一個(gè)類則致力 于(或允許)具體的實(shí)施細(xì)節(jié)。

    (19) 在構(gòu)建器內(nèi)部,只進(jìn)行那些將對(duì)象設(shè)為正確狀態(tài)所需的工作。盡可能地避免調(diào)用其他方法,因?yàn)槟切┓椒赡鼙黄渌烁采w或取消,從而在構(gòu)建過程中產(chǎn)生不可預(yù)知的結(jié)果(參見第7章的詳細(xì)說明)。

    (20) 對(duì)象不應(yīng)只是簡(jiǎn)單地容納一些數(shù)據(jù);它們的行為也應(yīng)得到良好的定義。

    (21) 在現(xiàn)成類的基礎(chǔ)上創(chuàng)建新類時(shí),請(qǐng)首先選擇"新建"或"創(chuàng)作"。只有自己的設(shè)計(jì)要求必須繼承時(shí),才應(yīng)考慮這方面的問題。若在本來允許新建的場(chǎng)合使用了繼承,則整個(gè)設(shè)計(jì)會(huì)變得沒有必要地復(fù)雜。

    (22) 用繼承及方法覆蓋來表示行為間的差異,而用字段表示狀態(tài)間的區(qū)別。一個(gè)非常極端的例子是通過對(duì)不同類的繼承來表示顏色,這是絕對(duì)應(yīng)該避免的:應(yīng)直接使用一個(gè)"顏色"字段。

    (23) 為避免編程時(shí)遇到麻煩,請(qǐng)保證在自己類路徑指到的任何地方,每個(gè)名字都僅對(duì)應(yīng)一個(gè)類。否則,編譯器可能先找到同名的另一個(gè)類,并報(bào)告出錯(cuò)消息。若懷疑自己碰到了類路徑問題,請(qǐng)?jiān)囋囋陬惵窂降拿恳粋€(gè)起點(diǎn),搜索一下同名的.class文件。

    (24) 在Java 1.1 AWT中使用事件"適配器"時(shí),特別容易碰到一個(gè)陷阱。若覆蓋了某個(gè)適配器方法,同時(shí)拼寫方法沒有特別講究,最后的結(jié)果就是新添加一個(gè)方法,而不是覆蓋現(xiàn) 成方法。然而,由于這樣做是完全合法的,所以不會(huì)從編譯器或運(yùn)行期系統(tǒng)獲得任何出錯(cuò)提示--只不過代碼的工作就變得不正常了。

    (25) 用合理的設(shè)計(jì)方案消除"偽功能"。也就是說,假若只需要?jiǎng)?chuàng)建類的一個(gè)對(duì)象,就不要提前限制自己使用應(yīng)用程序,并加上一條"只生成其中一個(gè)"注釋。請(qǐng)考慮將 其封裝成一個(gè)"獨(dú)生子"的形式。若在主程序里有大量散亂的代碼,用于創(chuàng)建自己的對(duì)象,請(qǐng)考慮采納一種創(chuàng)造性的方案,將些代碼封裝起來。

    (26) 警惕"分析癱瘓"。請(qǐng)記住,無論如何都要提前了解整個(gè)項(xiàng)目的狀況,再去考察其中的細(xì)節(jié)。由于把握了全局,可快速認(rèn)識(shí)自己未知的一些因素,防止在考察細(xì)節(jié)的時(shí)候陷入"死邏輯"中。

    (27) 警惕"過早優(yōu)化"。首先讓它運(yùn)行起來,再考慮變得更快--但只有在自己必須這樣做、而且經(jīng)證實(shí)在某部分代碼中的確存在一個(gè)性能瓶頸的時(shí)候,才應(yīng)進(jìn)行優(yōu)化。 除非用專門的工具分析瓶頸,否則很有可能是在浪費(fèi)自己的時(shí)間。性能提升的隱含代價(jià)是自己的代碼變得難于理解,而且難于維護(hù)。

    (28) 請(qǐng)記住,閱讀代碼的時(shí)間比寫代碼的時(shí)間多得多。思路清晰的設(shè)計(jì)可獲得易于理解的程序,但注釋、細(xì)致的解釋以及一些示例往往具有不可估量的價(jià)值。無論對(duì)你自 己,還是對(duì)后來的人,它們都是相當(dāng)重要的。如對(duì)此仍有懷疑,那么請(qǐng)?jiān)囅胱约涸噲D從聯(lián)機(jī)Java文檔里找出有用信息時(shí)碰到的挫折,這樣或許能將你說服。

    (29) 如認(rèn)為自己已進(jìn)行了良好的分析、設(shè)計(jì)或者實(shí)施,那么請(qǐng)稍微更換一下思維角度。試試邀請(qǐng)一些外來人士--并不一定是專家,但可以是來自本公司其他部門的人。 請(qǐng)他們用完全新鮮的眼光考察你的工作,看看是否能找出你一度熟視無睹的問題。采取這種方式,往往能在最適合修改的階段找出一些關(guān)鍵性的問題,避免產(chǎn)品發(fā)行 后再解決問題而造成的金錢及精力方面的損失。

    (30) 良好的設(shè)計(jì)能帶來最大的回報(bào)。簡(jiǎn)言之,對(duì)于一個(gè)特定的問題,通常會(huì)花較長的時(shí)間才能找到一種最恰當(dāng)?shù)慕鉀Q方案。但一旦找到了正確的方法,以后的工作就輕松 多了,再也不用經(jīng)歷數(shù)小時(shí)、數(shù)天或者數(shù)月的痛苦掙扎。我們的努力工作會(huì)帶來最大的回報(bào)(甚至無可估量)。而且由于自己傾注了大量心血,最終獲得一個(gè)出色的 設(shè)計(jì)方案,成功的快感也是令人心動(dòng)的。堅(jiān)持抵制草草完工的誘惑--那樣做往往得不償失

    posted @ 2011-11-28 14:34 俞靈 閱讀(590) | 評(píng)論 (0)編輯 收藏

    本文轉(zhuǎn)自it186云計(jì)算頻道,原文地址:cloud.it168.com

    在互聯(lián)網(wǎng)這個(gè)領(lǐng)域一直有這樣的說法:“如果老二無法戰(zhàn)勝老大,那么就把老大賴以生存的東西開源吧”。當(dāng)年Yahoo!與Google還是處在 強(qiáng)烈競(jìng)爭(zhēng)關(guān)系時(shí)候,招聘了Doug(Hadoop創(chuàng)始人),把Google老大賴以生存的DFS與Map-Reduce開源了,開始了Hadoop的童年 時(shí)期。差不多在2008年的時(shí)候,Hadoop才算逐漸成熟。

    從初創(chuàng)到現(xiàn)在,Hadoop經(jīng)過了至少7年的積累,現(xiàn)在的Hadoop不僅是當(dāng)年的老二Yahoo的專用產(chǎn)品了,從Hadoop長長的用戶名單中, 可以看到Facebook、Linkedin、Amazon,可以看到EMC、eBay、Twitter、IBM、Microsoft,、Apple、 HP…國內(nèi)的公司有淘寶、百度等等。

    本文將對(duì)Hadoop七年(2004-2011)的發(fā)展歷程進(jìn) 行梳理。讀完本文后,將不難看出,Hadoop的發(fā)展基本上經(jīng)歷了這樣一個(gè)過程:從一個(gè)開源的Apache基金會(huì)項(xiàng)目,隨著越來越多的用戶的加入,不斷地 使用、貢獻(xiàn)和完善,形成一個(gè)強(qiáng)大的生態(tài)系統(tǒng),從2009年開始,隨著云計(jì)算和大數(shù)據(jù)的發(fā)展,Hadoop作為海量數(shù)據(jù)分析的最佳解決方案,開始受到許多 IT廠商的關(guān)注,從而出現(xiàn)了許多Hadoop的商業(yè)版以及支持Hadoop的產(chǎn)品,包括軟件和硬件。

    • 2004年,Google發(fā)表論文,向全世界介紹了MapReduce。
    • 2005年初,為了支持Nutch搜索引擎項(xiàng)目,Nutch的開發(fā)者基于Google發(fā)布的MapReduce報(bào)告,在Nutch上開發(fā)了一個(gè)可工作的MapReduce應(yīng)用。
    • 2005年年中,所有主要的Nutch算法被移植到使用MapReduce和NDFS(Nutch Distributed File System )來運(yùn)行。
    • 2006年1月,Doug Cutting加入雅虎,Yahoo!提供一個(gè)專門的團(tuán)隊(duì)和資源將Hadoop發(fā)展成一個(gè)可在網(wǎng)絡(luò)上運(yùn)行的系統(tǒng)。
    • 2006年2月,Apache Hadoop項(xiàng)目正式啟動(dòng)以支持MapReduce和HDFS的獨(dú)立發(fā)展。
    • 2007年,百度開始使用Hadoop做離線處理,目前差不多80%的Hadoop集群用作日志處理。
    • 2007年,中國移動(dòng)開始在“大云”研究中使用Hadoop技術(shù),規(guī)模超過1000臺(tái)。
    • 2008年,淘寶開始投入研究基于Hadoop的系統(tǒng)——云梯,并將其用于處理電子商務(wù)相關(guān)數(shù)據(jù)。云梯1的總?cè)萘看蟾艦?.3PB,包含了1100臺(tái)機(jī)器,每天處理約18000道作業(yè),掃描500TB數(shù)據(jù)。
    • 2008年1月,Hadoop成為Apache頂級(jí)項(xiàng)目。
    • 2008年2月,Yahoo!宣布其搜索引擎產(chǎn)品部署在一個(gè)擁有1萬個(gè)內(nèi)核的Hadoop集群上。
    • 2008年7月,Hadoop打破1TB數(shù)據(jù)排序基準(zhǔn)測(cè)試記錄。Yahoo!的一個(gè)Hadoop集群用209秒完成1TB數(shù)據(jù)的排序 ,比上一年的紀(jì)錄保持者保持的297秒快了將近90秒。
    • 2009 年 3 月,Cloudera推出CDH(Cloudera’s Distribution including Apache Hadoop)平臺(tái),完全由開放源碼軟件組成,目前已經(jīng)進(jìn)入第3版。
    • 2009年5月,Yahoo的團(tuán)隊(duì)使用Hadoop對(duì)1 TB的數(shù)據(jù)進(jìn)行排序只花了62秒時(shí)間。
    • 2009年7月 ,Hadoop Core項(xiàng)目更名為Hadoop Common;
    • 2009年7月 ,MapReduce 和 Hadoop Distributed File System (HDFS) 成為Hadoop項(xiàng)目的獨(dú)立子項(xiàng)目。
    • 2009年7月 ,Avro 和 Chukwa 成為Hadoop新的子項(xiàng)目。
    • 2010年5月 ,Avro脫離Hadoop項(xiàng)目,成為Apache頂級(jí)項(xiàng)目。
    • 2010年5月 ,HBase脫離Hadoop項(xiàng)目,成為Apache頂級(jí)項(xiàng)目。
    • 2010年5月,IBM提供了基于Hadoop 的大數(shù)據(jù)分析軟件——InfoSphere BigInsights,包括基礎(chǔ)版和企業(yè)版。
    • 2010年9月,Hive( Facebook) 脫離Hadoop,成為Apache頂級(jí)項(xiàng)目。
    • 2010年9月,Pig脫離Hadoop,成為Apache頂級(jí)項(xiàng)目。
    • 2011年1月,ZooKeeper 脫離Hadoop,成為Apache頂級(jí)項(xiàng)目。
    • 2011年3月,Apache Hadoop獲得Media Guardian Innovation Awards 。
    • 2011年3月, Platform Computing 宣布在它的Symphony軟件中支持Hadoop MapReduce API。
    • 2011年5月,Mapr Technologies公司推出分布式文件系統(tǒng)和MapReduce引擎——MapR Distribution for Apache Hadoop。
    • 2011年5月,HCatalog 1.0發(fā)布。該項(xiàng)目由Hortonworks 在2010年3月份提出,HCatalog主要用于解決數(shù)據(jù)存儲(chǔ)、元數(shù)據(jù)的問題,主要解決HDFS的瓶頸,它提供了一個(gè)地方來存儲(chǔ)數(shù)據(jù)的狀態(tài)信息,這使得 數(shù)據(jù)清理和歸檔工具可以很容易的進(jìn)行處理。
    • 2011年4月,SGI( Silicon Graphics International )基于SGI Rackable和CloudRack服務(wù)器產(chǎn)品線提供Hadoop優(yōu)化的解決方案。
    • 2011年5月,EMC為客戶推出一種新的基于開源Hadoop解決方案的數(shù)據(jù)中心設(shè)備——GreenPlum HD,以助其滿足客戶日益增長的數(shù)據(jù)分析需求并加快利用開源數(shù)據(jù)分析軟件。Greenplum是EMC在2010年7月收購的一家開源數(shù)據(jù)倉庫公司。
    • 2011年5月,在收購了Engenio之后, NetApp推出與Hadoop應(yīng)用結(jié)合的產(chǎn)品E5400存儲(chǔ)系統(tǒng)。
    • 2011年6月,Calxeda公司(之前公司的名字是Smooth-Stone)發(fā)起了“開拓者行動(dòng)”,一個(gè)由10家軟件公司組成的團(tuán)隊(duì)將為基于Calxeda即將推出的ARM系統(tǒng)上芯片設(shè)計(jì)的服務(wù)器提供支持。并為Hadoop提供低功耗服務(wù)器技術(shù)。
    • 2011年6月,數(shù)據(jù)集成供應(yīng)商Informatica發(fā)布了其旗艦產(chǎn)品,產(chǎn)品設(shè)計(jì)初衷是處理當(dāng)今事務(wù)和社會(huì)媒體所產(chǎn)生的海量數(shù)據(jù),同時(shí)支持Hadoop。
    • 2011年7月,Yahoo!和硅谷風(fēng)險(xiǎn)投資公司 Benchmark Capital創(chuàng)建了Hortonworks 公司,旨在讓Hadoop更加魯棒(可靠),并讓企業(yè)用戶更容易安裝、管理和使用Hadoop。
    • 2011年8月,Cloudera公布了一項(xiàng)有益于合作伙伴生態(tài)系統(tǒng)的計(jì)劃——創(chuàng)建一個(gè)生態(tài)系統(tǒng),以便硬件供應(yīng)商、軟件供應(yīng)商以及系統(tǒng)集成商可以一起探索如何使用Hadoop更好的洞察數(shù)據(jù)。
    • 2011年8月,Dell與Cloudera聯(lián)合推出Hadoop解決方案——Cloudera Enterprise。Cloudera Enterprise基于Dell PowerEdge C2100機(jī)架服務(wù)器以及Dell PowerConnect 6248以太網(wǎng)交換機(jī)

    在梳理的過程中,筆者發(fā)現(xiàn)了上圖,它很好地展現(xiàn)了Hadoop生態(tài)系統(tǒng)是如何在使用中一步一步成長起來的。

    posted @ 2011-11-21 09:04 俞靈 閱讀(500) | 評(píng)論 (0)編輯 收藏

    主站蜘蛛池模板: 亚洲视频免费一区| 免费观看美女裸体网站| 亚洲国产精品线观看不卡| 成人免费观看一区二区| 国产精品亚洲专一区二区三区| 亚洲人成无码www久久久| 8888四色奇米在线观看免费看| 亚洲码和欧洲码一码二码三码 | 大学生a级毛片免费观看| 免费看一级高潮毛片| 久久精品亚洲一区二区 | 亚洲国产精品国自产电影| 夫妻免费无码V看片| 三年片免费高清版| 亚洲中文无码永久免| 亚洲国产成人片在线观看无码 | 精品国产一区二区三区免费| 国产成人精品亚洲日本在线| 国产亚洲一区区二区在线| 日本zzzzwww大片免费| yellow免费网站| 亚洲an日韩专区在线| 亚洲精品乱码久久久久久久久久久久| 日韩毛片免费无码无毒视频观看| 岛国岛国免费V片在线观看 | 国产精品免费αv视频| 亚洲中文字幕无码久久| 情人伊人久久综合亚洲| 免费在线观看日韩| AA免费观看的1000部电影| 色播在线永久免费视频网站| 亚洲av无码专区在线电影天堂| 亚洲黄色免费观看| 国产AV无码专区亚洲AV手机麻豆| 午夜网站免费版在线观看| 最近中文字幕无免费| 99在线热播精品免费99热| 老司机午夜性生免费福利| 天堂亚洲国产中文在线| 亚洲无砖砖区免费| 久久久久亚洲精品天堂|