2013年12月1日 星期日
浮雲雅築: [研究] Hadoop 1.2.1 安裝 (CentOS 6.4 x64)
浮雲雅築: [研究] Hadoop 1.2.1 安裝 (CentOS 6.4 x64): [研究] Hadoop 1.2.1 安裝 (CentOS 6.4 x64) 2013-07-27 Hadoop 是個架設雲端的系統，它參考Google Filesystem，以Java開發，提供HDFS與MapReduce API。 The Apache Hadoop...
3秒處理1PB資料！Google Dremel打敗Hadoop引領「巨量資料處理」趨勢
By CADE METZ | 11 七月 2013
Photo: Chapendra/ Flickr
如果全球巨量資料（Big Data）相關處理技術的研發是一場競賽，Google精益求精，持續保持領先。一如業內人士所熟知，臉書（Facebook）與雅虎（Yahoo）皆用以分析大量網路資料的「Hadoop」架構軟體平台，必需歸功Google先後在2003年末、2004年發表的「Google File System」、「MapReduce」兩份技術研究報告。
Dremel首度現身
8年後，當眾人仍熱衷使用Hadoop於各式資料分析工作，Google又以新技術自我超越，取代不夠完美的「Google File System」與「MapReduce」，並於2009年針對大型網路營運基礎架構發表三份研究報告，分別有關Google網路搜尋引擎的索引製作軟體平台「Caffeine」、可繪製大量網路資訊彼此對應關係的圖表資料庫「Pregel」，以及備受矚目的「Dremel」。
矽谷新創公司Cloudera執行長歐森（Mike Olson），便在不久前的一場座談會中指出，Google再度揭示巨量資料處理的未來走向，「想知道大型、高效能資料處理基礎架構的新面貌，不妨閱讀Google發表的研究報告。」
專精資料中心規模軟體平台的加州大學柏克萊分校資訊工程教授福克斯（Armando Fox），也十分驚豔於Dremel的優越，「以前若有人向我描述Dremel的功能，我絕對會認為那只能存在於想像。」
兼顧資料處理「量」與「速度」，功能空前
Dremel是一種資訊分析的方式，可以橫跨數千部伺服器，查詢大量資料，例如查詢網路文件、一批電子書的個別作者、某個特定主題的作者列表，甚至是記錄無數垃圾訊息的資料，類似數十年來運用於分析傳統資料庫的「結構式查詢語言」（SQL）技術。
Hadoop也有類似SQL的工具「Pig and Hive」，但耗時較長；向平台提出查詢需求後，需要幾分鐘至幾小時，才會得到結果。
同類的工具已經不少，Google必然同中求異，否則就不必大費周章研發Dremel了；以極短時間處理極龐大的資料量，即是Dremel最空前的突破。
Google在報告中明確指出，「過去MapReduce需要分多次查詢的資料，Dremel可同時處理，並大幅縮短運算時間」，Google基礎架構資深副總裁霍澤說，查詢一拍位元組（Petabyte，PB）、也就是相當十億位元組（Gigabyte，GB）百萬倍的資料量，大概只需要3秒鐘，Dremel完全是為立即查詢設計，「Dremel操作容易，適合處理臨時或定期查詢，直接在指令列輸入查詢項目就行了，不需要任何程式設計技巧。」
福克斯說，這是前所未有見的功能，他說，包括Hadoop在內的現行巨量資料處理工具，都有速度與準確度不及傳統資料分析或「商業智慧」工具的缺點，但Dremel卻成功克服障礙。
「許多人都曾使用巨量資料系統，但規模、速度都無法與Dremel相提並論；一直以來，『資料量』與『速度』總是顧此失彼，Dremel終於找到兼顧兩者的方法。」
承接Google成果，軟體人員還要加把勁
自2006年起，Google的數千名員工已經開始使用Dremel來分析橫跨數十部至數千部不等的伺服器巨量資料，包括服務軟體的故障報告、資料中心的表現等。
面對巨量資料的大趨勢，Cloudera執行長歐森認為，程式人員還需要加快後續開發的速度。
儘管Hadoop已經是相當成功的軟體，它讓打造平台科技基礎的Google稱霸網路世界，也帶來龐大商機，預估至2016年將可創造8.13億美元的軟體收益，以Hadoop運用為主要業務的公司如Cloudea，直接蒙受其利。
不過，歐森還是認為，自家公司與業界程式設計人員的開發速度實在太慢，現在面對新的Dremel，又出現類似現象。
2010年，Google發表Dremel研究報告，但軟體業界幾乎毫無反應。一群以色列工程師目前正著手建置叫做「OpenDremel」的複製品，其中一位開發人員古茲曼（David Gruzman）就說，程式編寫的時程先前停滯了一陣子，最近才又重新開始。
華盛頓大學粒子物理學特聘教授、Cloudant公司首席科學家米勒（Mike Miller），對於創投竟然尚未投資新創公司著手研究Dremel逆向工程，也大感意外。Cloudant已自發投入處理Google多年來面臨的資料問題。
無論業界反應如何，Google的開放態度倒是很一致，提供的Dremel相關雲端服務不勝枚舉。即使非Google工程師，也能透過「Google應用程式引擎」使用Google的基礎架構，來製作、經營、儲存整套應用程式；或透過Dremel，使用應用程式「BigQuery」，將資料上傳至Google，即時存取虛擬伺服器，進行查詢。
世界或許落後Google，但Google正迎向世界。
中華電信用Hadoop技術分析通話明細
| 中華電信利用自行開發的Hadoop大資料運算平臺，找出非結構化資料中的結構性，精簡資料後再置於資料倉儲運算，節省儲存空間 | ||
| 面對資料快速成長以及非結構性資料的增加，中華電信資訊處第四科科長楊秀一表示，中華電信近來利用Hadoop雲端運算技術自行開發了一個專門用來分析非結構化資料的巨量資料（Big Data）運算平臺，嘗試在資料進到資料倉儲系統之前，先進行資料的分析與處理以減少資料倉儲的資料量。 近年來行動語音市場趨於飽和，為了掌握用戶特性進行客製化行銷，一份資料要進行分析，就會被多次複製，因此即使用戶增加趨緩，但中華電信擁有的資料量仍快速暴增。 中華電信用來分析的資料模型最早於10多年前已有雛形，但當初主要用於行動語音分析。一直到2009年，他們完整導入Teradata的電信業邏輯資料模型cLDM 9.0版，整合更多電信服務的用戶資料。楊秀一表示，當初導入該模型的目的主要是為了整合行動語音、固網、數據的資料，進行以人為中心的分析模式。在導入之前，中華電信的資料模型是以設備為中心，因為不同設備的記錄資料儲存在不同的資料庫，無法進行整合性的分析。 舉例來說，同一個顧客在中華電信申辦了行動電話、家用電話以及固網服務，過去沒有整合前，中華電信只能分析單一設備的使用行為，而無法全面性分析單一顧客在不同設備上的使用狀況。 中華電信解決了資料整合分析的問題後，出現了另一個難題，就是蒐集的資料數量越來越多。比如說近年使用者大量利用行動裝置上網，這些上網行為，如網頁瀏覽、登入都會產生一些可分析的資料。於是，中華電信面臨了大量資料需要分析的挑戰。 楊秀一表示，目前中華電信每個月保留的資料記錄約為3～4TB的資料量，若要分析這些原始資料，過程中系統要處理的資料量還要再增加2倍以上，但中華電信現有資料倉儲設備僅能保存6～9個月的通話明細資料量，其餘就必須移到2線設備儲存，也讓資料分散不易整體分析。 精簡資料就先從結構化非結構化資料開始
楊秀一認為，分析非結構化資料最大的挑戰是沒有便宜的儲存方法，資料倉儲的容量價格高，大量資料的處理成本昂貴，所以必須先將非結構化的資料轉化成真正有分析價值的結構化資料，減少必須儲存在資料倉儲中的資料，建立分析平臺就能夠擴充儲存能量。 所以，中華電信運用了開源雲端運算技術Hadoop技術來建置大資料運算平臺，主要分析的非結構性資料為通話明細與網頁點擊率分析。藉由這個平臺可以儲存資料，並且找到資料的關聯性後，再由資料庫進行分析。 楊秀一表示，通話明細或是網頁點擊率雖不一定是非結構化資料，但是這些資料的結構是變動的，只要能夠找出固定特徵，就能夠放進可對應的資料庫欄位進行分析。 舉例來說，同樣打一通5分鐘的電話，每一通經過的基地臺數量與路徑完全不同，導致每一筆資料的長度並不一樣。因此，在處理資料時，先訂出可讓資料長度相同的規則，就能將相同長度的資料放在同一個欄位，進行結構化的分析。 楊秀一表示，將資料在進入資料倉儲之前就先放進另一個平臺分析，而不是將所有資料放進資料庫後，再將資料取出分析，可以減少一次資料庫的I/O負擔。 中華電信建置的大資料運算平臺目前仍在測試階段，楊秀一表示，未來希望透過該平臺精簡資料量，讓線上保存的資料增至12～27個月的通話明細，達到擴充容量的目的。文⊙辜雅蕾 資料來源 |
2013年11月30日 星期六
訂閱：
文章 (Atom)