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

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

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

    敏捷、分布式、ALM過程自動化、企業應用架構
    posts - 14, comments - 0, trackbacks - 0, articles - 1
      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

    2012年5月22日

    Hadoop實施已經有快一個月了,對Hadoop的概念理解、使用,Linux與shell腳本,甚至mysql都有了更多的理解。


    項目背景:用于互聯網信息收集后的關鍵詞匹配與內容提取。

    主要系統架構分為互聯網爬蟲、分析、業務應用三塊:

    簡單架構描述

    由于我在當中的角色主要負責分析架構的搭建,所以其他兩塊都畫得簡單,下面也不會過多的描述。


    Hadoop理解:提到Hadoop都想到的是云、分布式計算,在一段時間的實施之后有了一些具體的理解。

    Hadoop的優勢:

    針對性能指標,當業務數據量總量或增速上升到一定級別,依靠關系型數據庫一定無法支持。對于非關系型數據庫,包括Nosql和Solr一類存儲方式,稍顯復雜,對于機器集群性能要求偏高(相對于文件系統)。從數據使用模式上來講,目前海量數據的常常是不包含復雜邏輯的簡單統計整理(比如上述系統中的關鍵詞匹配)。這時候文件系統的優勢反而比較明顯(結構簡單,邏輯簡單)。

    如上述系統的應用場景是怎么樣的呢,在一個強大的爬蟲系統之下,每個小時的數據增量在G到10G的級別,需要搜索所有的文件,獲取關鍵字的匹配,并且對匹配內容進行摘要。很類似我們windows里面的搜索功能,需要解決的就是如何在這樣增幅的文件系統之下,如何滿足業務系統的需求。

    分析系統有什么要求呢?

    能夠建立集群,分布式的保存數據文件內容(統一控制,可配置)。

    有一定的保護機制,保證數據或節點丟失不會影響系統使用。

    如果有一個任務腳本執行框架機制就好了(用于并行計算)。

    能夠進行節點間的數據均衡。

    能夠簡單的查看所有的狀態與日志(web客戶端)

    可能主要是這些了。若自己實現,確實是個復雜而龐大的工程,現在我們有了Hadoop。


    系統物理架構:

    我們使用了一臺服務器,利用虛擬化,安裝了7套64x位的CentOS。一個Namenode,6個Datanode,復制數設置為3。每個系統分配到一個cpu,2G內存,Datanode掛載了500G的存儲空間。

    理想的Hadoop的搭建環境,參照《Best Practices for Selecting Apache Hadoop Hardware》(http://hortonworks.com/blog/best-practices-for-selecting-apache-hadoop-hardware/)一文,以及一些其他的文章。

    CPU:最好是雙CPU,8核左右。不用太高了。

    內存:推薦48G,但是4G應該就可以運行Hadoop了。

    硬盤:7200轉的SATA硬盤即可,Hadoop很占空間,所以盡量加。

    網絡:內部的數據交換要求非常高,內網最好是千兆網卡,帶寬為1GB。

    理想與現實,有錢與沒錢,呵呵。


    系統軟件架構:

    Hadoop:版本使用的是1.0.3,再下來就是2了,為了盡量簡化應用,所以不考慮2的新特性。對Hadoop沒有做太多的設置,基本基于默認。70為Namenode,71-76為Datanode。

    JDK:1.6.0_33 (64x)


    系統實施過程:

    HDFS部分:

    爬蟲抓取數據,整理后存放在50文件服務器,70以外部掛載的形式讀取。網頁文件比較小,假如直接寫入Hadoop對Namenode負載過大,所以入庫前合并,將每小時網頁整合成為一個文件寫入HDFS,由于區分類別,所以每小時基本寫入10個文件左右,總量在5-8G,耗時在40-50分鐘。(這個過程中,由于爬蟲的IO過于頻繁,導致文件讀取困難,所以做了定時任務,每小時啟動一次,將需要處理的文件先拷貝到臨時區域,合并入庫之后再刪除。此處應該是受到單核cpu的限制,所有操作均是串行,包括拷貝(cp)和合并入庫(java),所以Namenode嚴重建議配置稍高。)

    此處沒有太多問題。

    MapReduce部分:

    寫入完成后,進行分析工作,MapReduce。此處的工作過程為:數據庫定時生成關鍵詞列表文件。Job執行時會讀取列表文件,匹配指定范圍內的HDFS文件(過去一小時),匹配出對應的表達式與HTML,Map過程結束。在Reduce階段,會將Map的所有數據入數據庫(Mysql)。

    此處出現過一些問題,記錄下來。

    1. Reduce階段需要加載Mysql的第三方驅動包。我在三個環境測試過(公司、家里、發布環境),使用 -libjars 一定可以,有的地方不需要也可以。不明確,懷疑與HADOOP_HOME環境變量有關。

    2. MR過程中使用log4j打印日志,在Hadoop臨時目錄(如果你沒有配置dfs.name.dir,dfs.data.dir,mapred.local.dir.mapred.system.dir等目錄,這些都會在hadoop.tmp.dir當中,我就偷懶都沒配置)mapred文件夾中查看一下。

    整個過程實際上還是比較簡單的,基本編碼量就在Job的部分,但是一個Java文件就夠了。在目前初級階段應該還是比較好用的。現在還沒有測試Job的執行效率。完成后會繼續記錄下來。有什么問題可以提出。我想到什么也會在本文繼續更新。

    posted @ 2012-08-08 20:21 一酌散千憂 閱讀(585) | 評論 (0)編輯 收藏

    硬件資源:

    三臺CentOS5.6虛擬機(Vmware

    本機 windows7 64x

     

    基本資源配置:

    三臺虛擬機均是克隆自同一個鏡像

    已經安裝了Java環境(jdk1.6.0_25

    Hadoop路徑在/usr/hadoop/hadoop-0.20.205.0

     

    操作步驟:

    1、機器名稱規范

    ip分別為128129130,將128設置為master,其他設置為slave

    修改

    /etc/sysconfig/network

    /etc/hosts

    兩處配置,名稱分別為hadoop-master\hadoop-slave01\hadoop-slave02

    注意:此處名稱最好不用使用下劃線,有可能引發namenode的啟動異常。

     

    2、修改Hadoop配置 

    master節點的conf中修改masterslave文件,分別為機器的ip地址

     

    修改master節點的conf中:

    core-site.xml

    <property>

    <name>fs.default.name</name>

    <value>hdfs://ip-master:9000</value>

    </property>

     

    mapred-site.xml

    <property>

    <name>mapred.job.tracker</name>                                   

    <value>master:9001</value>                                

    </property>

     

    hdfs-site.xm

    <property>

    <name>dfs.replication</name>

    <value>2</value>

    </property>

    注意此處的端口號均為默認。

     

     

    3、建立m-s之間的ssh連接

    首先masterslave機器都需要進行ssh信任文件生成,執行如下命令:

    $ ssh-keygen -t rsa

    中間需要輸入的地方直接回車,接受缺省值即可

     

    由于使用root用戶登錄,所以密鑰文件生成在 /root/.ssh/文件夾下,存有一對密鑰id_dsaid_dsa.pub

    此處id_dsa(私鑰)必須為其他用戶不可讀,所以文件屬性應當是600

     

    master機器執行:

    id_dsa.pub(公鑰)復制為 authorized_keys

    $ cp id_dsa.pub authorized_keys

    如果是多臺機器需要,無密碼登陸,則各自機器產生公鑰追加到authorized_keys即可.

     

    使用scp協議覆蓋slave端的密鑰文件夾,使得slave機器信任來自master的連接:

    $ scp /root/.ssh/* ip-slave:/root/.ssh

     

     

    4、啟動服務 

    建議將$HADOOP_HOME/bin下的所有文件給與執行權限:

    $ chmod 777 bin

     

    master作為namenod需要執行如下腳本:

    $HADOOP_HOME/bin/hadoop namenode –format

     

    完成后執行 $HADOOP_HOME/bin/start-all.sh

     

    5、問題檢查

    Hadoop根目錄下的logs文件中,檢查各個服務日志的啟動情況

     

     

    6、其他情況說明:

    Q: $HADOOP_HOME is deprecated

    A: 基本不會產生任何影響。由于腳本啟動時設置了該環境變量,就會提示用戶原有環境變量失效。可以取消環境變量設置,或者直接去bin/hadoop中找到這句話,去掉即可

     

    Q: 無效的選項 -jvm / Unrecognized option: -jvm

    A: 在使用root用戶登錄時 bin/hadoop 腳本就會進行判斷,加上-jvm參數。此處是為了進入jsvchttp://commons.apache.org/daemon/jsvc.html),此處并不確定是否bug,也不再進行詳細的追溯,解決方法就是進入 bin/hadoop 腳本中 找到 jvm 參數并去掉。

     

     

     

     

     

     

     

    posted @ 2012-07-04 07:38 一酌散千憂 閱讀(588) | 評論 (0)編輯 收藏

    公司里有同事時常抱怨,項目的用戶體驗太差,常常挨領導的罵。大家都認為是在用戶體驗的設計方面,公司人員的能力和經驗都不足引起的。發牢騷的時候也會說,如果公司能夠請得起“淘寶”的UI設計師,咱們的系統肯定會更上一層樓。我之前也一直認為如此,即我們的設計是影響項目體驗的重要原因。最近被領導調動去協助一個項目,產生了一些不一樣的體會。

    項目背景,一個新的產品,小型項目,純開發人員3-4人,2名熟練開發人員,1名新手,偶爾會有協助人員。沒有技術經理,項目經理身負多個項目,對項目進度關心不足,部門經理會協助進行工作和進度管理。可以看到管理還是比較混亂。

    由于項目進度太慢,領導要求從我這邊調一個熟練人員協助開發。我也基本了解他們的項目狀況,為了不讓我的人進去抓瞎,我就和他一起去了解項目情況。

    項目狀況比較糟糕,介入項目時已經開發了一段時間,保留的文檔只有兩份,一副數據庫說明,一份非常粗略的需求說明,而且還與開發進度不同步,就是沒有維護。

    我了解了一下項目目前的難度,開發人員和我反映一個是人員熟練程度的問題,二是需求變更的問題。我整體了解了一下項目目前的需求和設計,以及進度。就挑了一個模塊詢問他們的變更情況,這個模塊是一個關鍵詞匹配功能。結果是領導看了他們的頁面之后,嫌信息量太少,就要求提供一些更細化的數據展示。開發人員問我有什么意見,我就簡單講了一下頁面大概怎么構建。其中有一個點,是用于變更數據范圍,即查詢的表變更,我一開始覺得使用下拉框就可以,產生了一些意見。有人建議分為不同子模塊,或者tab頁,或者分為多塊并列展示。我想了想,就給他們講了我認為幾種方案的優點缺點及適用范圍。

     

    1.       多塊并行展示:

    多個不同范圍的數據在同一頁面中分為不同區域以相同形式展示。原因是由于多塊數據之間有一定的關聯因果關系,或值得對比。適用范圍:如購物網站中的多個物品比較。

    2.       Tab頁:

    同一個頁面的多個tab頁,表示多個tab頁中的數據可能在一定的領域概念之下有一定的關聯,但關聯度不強。因為tab頁更重要的是強調一個同步工作的狀態,即A tab頁查看一定信息,會打開B tab頁查看其他信息,中途還會切回A tab頁。適用范圍:如郵箱中,收件箱和草稿箱。

    3.       下拉框

    下拉框作為查詢條件的一部分,常用于有著常規或固定的可選擇內容中(如性別,月份),更多是以過濾的形態出現,即下拉框更適合針對某表的某個字段過濾,如果針對的是數據范圍或是對用戶需要直觀了解的重要業務條件則不太合適。適用范圍:如在考試成績中使用下拉框過濾“男女”或“及格不及格”。

    4.       單選框

    單選框與下拉框的作用范圍相似,但是不同之處在于將被選項全部展示,目的在于能夠讓用戶清楚的了解當前數據顯示的實際范圍或條件,以及備選的其他范圍或條件。更適用于選項與實際業務及當前展示數據關系重要,不同選項可能會引發用戶的不同行為。適用范圍:如銀行系統顯示了當前用戶下綁定多個帳號時,使用單選框。

     

    經過上述討論,我們仔細分析了這個模塊中用戶的實際需求,以及可能后續操作,最終選擇的單選框的方案。

    目前還沒有后續,但是我想我們基于用戶真是需求的挖掘和后續操作的認真分析,會讓我們在與領導進行需求討論的時候有更加充分合理的依據。

    回來之后我又看了看淘寶的搜索頁面,比如就搜索“鞋子”來講,將品牌這欄設置為單選和下拉將是完全不同的效果,而確定方案的理由則是對于用戶的需求和實際行為的深入研究。這個應該是需求分析和調研的結果。將搜索條件以tag的形式標注于頁面上,并且可以直接點擊X按鈕進行刪除,我覺得更加可以傾向為用戶體驗。滿足并充分考慮了用戶實際需求的是好的需求分析,能夠簡化并引導用戶行為的是好的用戶體驗。

    當我們面臨的系統感覺非常難用的時候,往往這時候并非是用戶體驗差,我們應該檢討的是我們對用戶需求有沒有好好挖掘,做出來的是不是用戶想要、用戶能用的系統。

    posted @ 2012-05-22 05:02 一酌散千憂 閱讀(265) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: 永久久久免费浮力影院| 国产亚洲日韩一区二区三区| 亚洲激情视频在线观看| 三上悠亚电影全集免费| 久久久精品免费视频| 国产精品免费观看久久| 亚洲第一页在线视频| 久热中文字幕在线精品免费| 亚洲jjzzjjzz在线观看| 成熟女人牲交片免费观看视频| 亚洲乱码国产乱码精品精| 拍拍拍无挡视频免费观看1000| 日本免费电影一区| 国产亚洲精品AAAA片APP| 91精品导航在线网址免费| 久久亚洲色一区二区三区| 亚洲精品久久无码av片俺去也| 久草免费手机视频| 亚洲麻豆精品果冻传媒| 国产又黄又爽又大的免费视频| 亚洲毛片αv无线播放一区| 在线观看免费亚洲| 亚洲国产成人精品无码久久久久久综合 | 在线观看免费人成视频| 久久亚洲AV午夜福利精品一区| 国产精品亚洲精品久久精品| 亚洲国产精品日韩专区AV| 亚洲免费观看视频| 亚洲妇女熟BBW| 亚洲?v女人的天堂在线观看| 亚洲国产成人精品无码区二本 | 少妇太爽了在线观看免费视频 | 亚洲国产成人超福利久久精品| 久久免费福利视频| 亚洲综合一区国产精品| 成年人视频在线观看免费| 一级毛片大全免费播放| 亚洲视频国产精品| 免费一级毛片在线播放| 最近免费2019中文字幕大全| 久久无码av亚洲精品色午夜|