<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

    2013年9月15日


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

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

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

     

    有意者請發送郵件到 yuling.sh@taobao.com 

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

    2012年7月3日


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

     

    簡介: mapreduce作業會根據輸入目錄產生多個map任務, 通過多個map任務并行執行來提高作業運行速度, 但如果map數量過少, 并行量低, 作業執行慢, 如果map數過多, 資源有限, 也會增加調度開銷. 因此, 根據輸入產生合理的map, 為每個map分配合適的數據量, 能有效的提升資源利用率, 并使作業運行速度加快.

        mapreduce, 每個作業都會通過 InputFormat來決定map數量. InputFormat是一個接口, 提供兩個方法:

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

    RecordReader<K, V> getRecordReader(InputSplit split,

                                         JobConf job,

                                         Reporter reporter) throws IOException;

        其中getSplits方法會根據輸入目錄產生InputSplit數組, 每個InputSplit會相應產生一個map任務, map的輸入定義在InputSplit. getRecordReader方法返回一個RecordReader對象, RecordReader決定了map任務如何讀取輸入數據, 例如一行一行的讀取還是一個字節一個字節的讀取, 等等.

        下圖是InputFormat的實現類:

           (暫時無法上傳)

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


     

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

     

    mapreduce默認使用TextInputFormatTextInputFormat沒有實現自己的getSplits方法,繼承于FileInputFormat, 因此使用了FileInputFormat的.

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

    兩個配置

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

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

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

    因此, 如果想增加map, 可以把mapred.min.split.size調小(其實默認值即可), 另外還需要把mapred.map.tasks設置大.

    如果需要減少map,可以把mapred.min.split.size調大, 另外把mapred.map.tasks調小.

    這里要特別指出的是FileInputFormat會讓每個輸入文件至少產生一個map任務, 因此如果你的輸入目錄下有許多文件, 而每個文件都很小, 例如幾十kb, 那么每個文件都產生一個map會增加調度開銷. 作業變慢.

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


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

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

    Math.min(maxSize, blockSize).

        若需增加map,可以把mapred.min.split.size調小,mapred.max.split.size調大. 若需減少map, 可以把mapred.min.split.size調大, 并把mapred.max.split.size調小.


    CombineFileInputFormat

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

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

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

    mapred.min.split.size.per.node 一個節點上split的至少的大小

    mapred.min.split.size.per.rack   一個交換機下split至少的大小

    mapred.max.split.size             一個split最大的大小

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

    1.根據輸入目錄下的每個文件,如果其長度超過mapred.max.split.size,block為單位分成多個split(一個split是一個map的輸入),每個split的長度都大于mapred.max.split.size, 因為以block為單位, 因此也會大于blockSize, 此文件剩下的長度如果大于mapred.min.split.size.per.node, 則生成一個split, 否則先暫時保留.

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

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

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

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

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

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

    經過第一步, 生成五個split: 1000,1000,1000,499,1000. 剩下的碎片為rack1:50,10; rack210:80

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

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

     

    如果要減少map數量, 可以調大mapred.max.split.size, 否則調小即可.

    其特點是: 一個塊至多作為一個map的輸入,一個文件可能有多個塊,一個文件可能因為塊多分給做為不同map的輸入, 一個map可能處理多個塊,可能處理多個文件。


    編寫自己的InputFormat

     

        待續


     

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

    2012年6月3日

    Yarn做為hadoop下一代集群資源管理和調度平臺, 其上能支持多種計算框架, 本文就簡要介紹一下這些計算框架.


    1.       MapReduce

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

    2.       Spark

    Spark是一種與mapreduce相似的開源計算框架, 不同之處在于Spark在某些工作負載方面表現更優, 因為它使用了內存分布式數據集, 另外除了提供交互式查詢外, 它還可以優化迭代工作負載.

    3.       Apache HAMA

    Apache Hama 是一個運行在HDFS上的BSP(Bulk Synchronous Parallel大容量同步并行) 計算框架, 主要針對大規模科學計算,如矩陣, 圖像, 網絡算法等.當前它有一下功能:

    • 作業提交和管理接口
    • 單節點上運行多個任務
    • 輸入/輸出格式化
    • 備份恢復
    • 支持通過Apache Whirr運行在云端
    • 支持與Yarn一起運行

    4.       Apache Giraph

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

    5.       Open MPI

    這是一個高性能計算函數庫,通常在HPCHigh Performance Computing)中采用,與MapReduce相比,其性能更高,用戶可控性更強,但編程復雜,容錯性差,可以說,各有所長,在實際應用中,針對不同 該應用會采用MPI或者MapReduce

    6.       Apache HBase

    HBase是一個hadoop數據庫, 其特點是分布式,可擴展的,存儲大數據。當有需要隨機,實時讀寫的大數據時, 使用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 俞靈 閱讀(3654) | 評論 (0)編輯 收藏

    2012年5月24日

    轉載
    http://fujun.sinaapp.com/2011/11/02/68.html

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

    wufujun@wufujun-VirtualBox:~$ xrandr

    系統給出的結果

    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的的分辨率設置

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

    wufujun@wufujun-VirtualBox:~$ cvt 1368 768

    顯示結果如下
    # 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

    從這個結果里可以到,16:9的分辨率是可以用的

    第三步 輸入

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

    建立新的分辨率模式1368×768,把剛才cvt得到的數據寫進參數

    第四步 繼續輸入

    sudo xrandr --addmode VBOX0 "1368x768"

    給當前顯示器VBOX0增加1368×768分辨率設置

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

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


    $ sudo gedit /etc/X11/xorg.conf

    編輯內容為:

    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命令來得到這個Modeline的值,這個命令中,1368 768是分辨率 60為刷新率,用這個命令得到的值可能會更為準確一些。

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

    這段是設置默認顯示最佳分辨率。

    注意這段文件中的一些規則

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

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

    2012年5月20日

         摘要:      最近這些天學習了classLoader的原理, 原因是因為服務器上的一個java進程啟動時加載兩個不同版本的jar包, 含有相同名字的類, 而且服務端的jar包排在前面, 我上傳的jar包排在后面, 于是每次都使用服務端的jar包, 我的jar包便無法生效, 因此希望修改classLader, 讓它按相反的順序加載jar包.  ...  閱讀全文

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

    2012年3月24日

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

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

    2011年11月28日

    本文轉自:
    http://blog.csdn.net/zhouysh/article/details/304767

    JAVA代碼編寫的30條建議
    (1) 類名首字母應該大寫。字段、方法以及對象(句柄)的首字母應小寫。對于所有標識符,其中包含的所有單詞都應緊靠在一起,而且大寫中間單詞的首字母。例如:
    ThisIsAClassName
    thisIsMethodOrFieldName
    若在定義中出現了常數初始化字符,則大寫static final基本類型標識符中的所有字母。這樣便可標志出它們屬于編譯期的常數。
    Java包(Package)屬于一種特殊情況:它們全都是小寫字母,即便中間的單詞亦是如此。對于域名擴展名稱,如com,org,net或者edu等,全部都應小寫(這也是Java 1.1和Java 1.2的區別之一)。

    (2) 為了常規用途而創建一個類時,請采取"經典形式",并包含對下述元素的定義:

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

    (3) 對于自己創建的每一個類,都考慮置入一個main(),其中包含了用于測試那個類的代碼。為使用一個項目中的類,我們沒必要刪除測試代碼。若進行了任何形式的改動,可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。

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

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

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

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

    (9) 若不得已進行一些不太雅觀的編程,至少應該把那些代碼置于一個類的內部。

    (10) 任何時候只要發現類與類之間結合得非常緊密,就需要考慮是否采用內部類,從而改善編碼及維護工作(參見第14章14.1.2小節的"用內部類改進代碼")。

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

    (12) 避免使用"魔術數字",這些數字很難與代碼很好地配合。如以后需要修改它,無疑會成為一場噩夢,因為根本不知道"100"到底是指"數組大小"還是"其他 全然不同的東西"。所以,我們應創建一個常數,并為其使用具有說服力的描述性名稱,并在整個程序中都采用常數標識符。這樣可使程序更易理解以及更易維護。

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

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

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

    (16) 若在初始化過程中需要覆蓋(取消)finalize(),請記住調用super.finalize()(若Object屬于我們的直接超類,則無此必 要)。在對finalize()進行覆蓋的過程中,對super.finalize()的調用應屬于最后一個行動,而不應是第一個行動,這樣可確保在需要 基礎類組件的時候它們依然有效。

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

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

    (19) 在構建器內部,只進行那些將對象設為正確狀態所需的工作。盡可能地避免調用其他方法,因為那些方法可能被其他人覆蓋或取消,從而在構建過程中產生不可預知的結果(參見第7章的詳細說明)。

    (20) 對象不應只是簡單地容納一些數據;它們的行為也應得到良好的定義。

    (21) 在現成類的基礎上創建新類時,請首先選擇"新建"或"創作"。只有自己的設計要求必須繼承時,才應考慮這方面的問題。若在本來允許新建的場合使用了繼承,則整個設計會變得沒有必要地復雜。

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

    (23) 為避免編程時遇到麻煩,請保證在自己類路徑指到的任何地方,每個名字都僅對應一個類。否則,編譯器可能先找到同名的另一個類,并報告出錯消息。若懷疑自己碰到了類路徑問題,請試試在類路徑的每一個起點,搜索一下同名的.class文件。

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

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

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

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

    (28) 請記住,閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易于理解的程序,但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自 己,還是對后來的人,它們都是相當重要的。如對此仍有懷疑,那么請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折,這樣或許能將你說服。

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

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

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

    2011年11月21日

    本文轉自it186云計算頻道,原文地址:cloud.it168.com

    在互聯網這個領域一直有這樣的說法:“如果老二無法戰勝老大,那么就把老大賴以生存的東西開源吧”。當年Yahoo!與Google還是處在 強烈競爭關系時候,招聘了Doug(Hadoop創始人),把Google老大賴以生存的DFS與Map-Reduce開源了,開始了Hadoop的童年 時期。差不多在2008年的時候,Hadoop才算逐漸成熟。

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

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

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

    在梳理的過程中,筆者發現了上圖,它很好地展現了Hadoop生態系統是如何在使用中一步一步成長起來的。

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

    2011年11月15日

    本文轉自:
    http://linuxtoy.org/archives/bash-shortcuts.html

    生活在 Bash shell 中,熟記以下快捷鍵,將極大的提高你的命令行操作效率。

    編輯命令

    • Ctrl + a :移到命令行首
    • Ctrl + e :移到命令行尾
    • Ctrl + f :按字符前移(右向)
    • Ctrl + b :按字符后移(左向)
    • Alt + f :按單詞前移(右向)
    • Alt + b :按單詞后移(左向)
    • Ctrl + xx:在命令行首和光標之間移動
    • Ctrl + u :從光標處刪除至命令行首
    • Ctrl + k :從光標處刪除至命令行尾
    • Ctrl + w :從光標處刪除至字首
    • Alt + d :從光標處刪除至字尾
    • Ctrl + d :刪除光標處的字符
    • Ctrl + h :刪除光標前的字符
    • Ctrl + y :粘貼至光標后
    • Alt + c :從光標處更改為首字母大寫的單詞
    • Alt + u :從光標處更改為全部大寫的單詞
    • Alt + l :從光標處更改為全部小寫的單詞
    • Ctrl + t :交換光標處和之前的字符
    • Alt + t :交換光標處和之前的單詞
    • Alt + Backspace:與 Ctrl + w 相同類似,分隔符有些差別 [感謝 rezilla 指正]

    重新執行命令

    • Ctrl + r:逆向搜索命令歷史
    • Ctrl + g:從歷史搜索模式退出
    • Ctrl + p:歷史中的上一條命令
    • Ctrl + n:歷史中的下一條命令
    • Alt + .:使用上一條命令的最后一個參數

    控制命令

    • Ctrl + l:清屏
    • Ctrl + o:執行當前命令,并選擇上一條命令
    • Ctrl + s:阻止屏幕輸出
    • Ctrl + q:允許屏幕輸出
    • Ctrl + c:終止命令
    • Ctrl + z:掛起命令

    Bang (!) 命令

    • !!:執行上一條命令
    • !blah:執行最近的以 blah 開頭的命令,如 !ls
    • !blah:p:僅打印輸出,而不執行
    • !$:上一條命令的最后一個參數,與 Alt + . 相同
    • !$:p:打印輸出 !$ 的內容
    • !*:上一條命令的所有參數
    • !*:p:打印輸出 !* 的內容
    • ^blah:刪除上一條命令中的 blah
    • ^blah^foo:將上一條命令中的 blah 替換為 foo
    • ^blah^foo^:將上一條命令中所有的 blah 都替換為 foo

    友情提示

    1. 以上介紹的大多數 Bash 快捷鍵僅當在 emacs 編輯模式時有效,若你將 Bash 配置為 vi 編輯模式,那將遵循 vi 的按鍵綁定。Bash 默認為 emacs 編輯模式。如果你的 Bash 不在 emacs 編輯模式,可通過 set -o emacs 設置。
    2. ^S、^Q、^C、^Z 是由終端設備處理的,可用 stty 命令設置。

    posted @ 2011-11-15 10:04 俞靈 閱讀(593) | 評論 (0)編輯 收藏


    希望大家喜歡,自己留個備份,沒事逛逛!!

    http://www.javaalmanac.com - Java開發者年鑒一書的在線版本. 要想快速查到某種Java技巧的用法及示例代碼, 這是一個不錯的去處.
    http://www.onjava.com - O'Reilly的Java網站. 每周都有新文章.
    http://java.sun.com - 官方的Java開發者網站 - 每周都有新文章發表.
    http://www.developer.com/java - 由Gamelan.com 維護的Java技術文章網站.
    http://www.java.net - Sun公司維護的一個Java社區網站.
    http://www.builder.com - Cnet的Builder.com網站 - 所有的技術文章, 以Java為主.
    http://www.ibm.com/developerworks/java - IBM的Developerworks技術網站; 這是其中的Java技術主頁.
    http://www.javaworld.com - 最早的一個Java站點. 每周更新Java技術文章.
    http://www.devx.com/java - DevX維護的一個Java技術文章網站.
    http://www.fawcette.com/javapro - JavaPro在線雜志網站.
    http://www.sys-con.com/java - Java Developers Journal的在線雜志網站.
    http://www.javadesktop.org - 位于Java.net的一個Java桌面技術社區網站.
    http://www.theserverside.com - 這是一個討論所有Java服務器端技術的網站.
    http://www.jars.com - 提供Java評論服務. 包括各種framework和應用程序.
    http://www.jguru.com - 一個非常棒的采用Q&A形式的Java技術資源社區.
    http://www.javaranch.com - 一個論壇,得到Java問題答案的地方,初學者的好去處。
    http://www.ibiblio.org/javafaq/javafaq.html - comp.lang.java的FAQ站點 - 收集了來自comp.lang.java新聞組的問題和答案的分類目錄.
    http://java.sun.com/docs/books/tutorial/ - 來自SUN公司的官方Java指南 - 對于了解幾乎所有的java技術特性非常有幫助.
    http://www.javablogs.com - 互聯網上最活躍的一個Java Blog網站.
    http://java.about.com/ - 來自About.com的Java新聞和技術文章網站.

    posted @ 2011-11-15 09:45 俞靈 閱讀(594) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: 亚洲桃色AV无码| 亚洲日韩精品A∨片无码加勒比| 日本在线看片免费| 内射干少妇亚洲69XXX| 最近中文字幕免费mv在线视频| 在线观看日本亚洲一区| 亚洲精品综合久久| 91香蕉国产线在线观看免费| 亚洲精品天堂成人片AV在线播放 | 野花高清在线观看免费3中文| 亚洲精品久久无码| 精品亚洲一区二区| 国产成人免费爽爽爽视频| 一级特黄色毛片免费看| 亚洲国产成人久久精品app| mm1313亚洲精品国产| 亚洲精品视频在线观看免费| 国产亚洲美女精品久久久久| 亚洲AV无码成人精品区蜜桃| 国产中文字幕免费| 在线a免费观看最新网站| 色多多A级毛片免费看| 亚洲国产成人91精品| 国产成人综合亚洲亚洲国产第一页| 91在线视频免费播放| 两个人的视频www免费| 亚洲精品天堂成人片AV在线播放 | 精品无码人妻一区二区免费蜜桃| 亚洲欧美自偷自拍另类视| 亚洲尹人九九大色香蕉网站 | 国产亚洲大尺度无码无码专线 | 亚洲精品夜夜夜妓女网| 色播在线永久免费视频| 88av免费观看| 最新久久免费视频| 国产一区二区三区亚洲综合| 亚洲综合中文字幕无线码| 亚洲三级电影网址| 国产成人亚洲精品青草天美| 亚洲AⅤ视频一区二区三区| 国语成本人片免费av无码|