<menuitem id="bnags"></menuitem>

    <ins id="bnags"><video id="bnags"></video></ins><mark id="bnags"></mark>
  • <ins id="bnags"></ins>

      <tr id="bnags"><small id="bnags"></small></tr>

    1. 首頁 慕課課程正文

      Hadoop大數據學習:大數據的動機

      hadoop 大數據的動機

      20多年前的計算機革命使得大量的數據正被企業集聚起來。數字傳感器的發展、通信系統的激增,尤其是移動平臺和設備;對系統事件大規模的日志記錄;以及朝著無紙化企業的迅速發展,這些導致企業內部數據資源的大規模集聚。企業對技術的依賴確保了數據將繼續以更快的速度增長。

      摩爾定律稱計算機的性能一直以來都是幾乎每兩年就會比過去翻一番,最初計算資源與數據增長速度保持一致。然而,2005年左右這種計算資源的發展速度開始逐漸減緩。

      計算行業開始尋找其他選擇,即并行處理以提供更經濟的解決方案。如果一臺計算機不能??變得更快,則其目標是用大量計算資源來并行處理同樣的問題。Hadoop是網絡中的多臺計算機運用MapReduce擴展數據處理(單指令的變體,計算技術的多數據[SIMD]類)的概念的實現。

      基于云計算通過供應商如亞馬遜,谷歌和微軟等不斷演變,推動了這一概念的發展,因為我們現在可以租用計算資源來節省購買這些所需的一小部分成本。

      本書是設計意圖是使用Hadoop,一個由Apache軟件基金會主辦,現已擴展并由各供應商,如Cloudera,MapR和Hortonworks支持的項目,來開發和運行軟件的實用指南。本章將從總體上討論大數據尤其是Hadoop的動機。

      Hadoop大數據學習:大數據的動機

      大數據是什么?

      在本書中,大數據的一個數據集定義,指那些單個機器資源無法處理或存儲(在某些情況下)的任何數據集。該定義的前半部分至關重要。它可以在一臺機器上處理幾乎任何規模的數據。即使那些無法在單個機器上存儲的數據可以通過從一個共享存儲器如網絡附加存儲(NAS)介質讀取被導入一臺機器。然而,處理這些數據所需的時間量相對于處理這些數據的可用時間將會多得多。

      思考一個簡單的例子。如果一個企業單位處理任務的平均容量為200 GB,假設我們每秒可以讀大概50 MB。在每秒50 MB的前提下,我們從磁盤順序讀取100 MB數據需要2秒,讀取整個200 GB的數據將花費我們大約1個小時?,F在想象一下,要求該數據在5分鐘內處理完。如果每個任務所需的200 GB能夠均勻分布在100個節點上,且每個節點可以處理其自己的數據(考慮一個簡化用例,如基于一個簡單標準:SALES_YEAR> 2001只選擇一個數據子集),減少執行CPU處理所用的時間,將100個節點的結果集合起來,總處理可在1分鐘內完成。

      這個簡單的例子表明大數據是上下文相關的,且上下文由業務需求提供。

      注意 Jeff Dean博士在一篇文章中討論過并行,你可以在cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf找到。從本地磁盤順序讀取1 MB數據需要2000萬納秒。從一個1 gbps的網絡讀取相同數據需要約2.5億納秒(假設2 KB需要250,000納秒,每2 KB的每個往返需要500,000納秒)。雖然該鏈接有點過時,此后這些數字已經改變,但本章我們將使用這些數字以作說明。而這些數字相對于彼此的比例并沒有太大改變。

      大數據技術背后的關鍵理念

      雖然我們在前面的例子中提出了許多假設,最關鍵的是我們可以非??焖俚靥幚頂祿?,但至于我們可以從永久存儲中讀取數據的速度究竟有多快仍然存在很大的局限性。與讀/寫節點本地永久存儲相比,通過網絡發送數據速度更要慢得多。

      所有大數據方法的一些共同特點如下:

      數據分布在多個節點(網絡I/ O速度<<本地磁盤I/ O速度)。

      應用程序被分配到數據(集群中的節點),而非相反。

      數據盡可能被本地處理到節點上(網絡I/ O速度<<本地磁盤I/ O速度)。

      隨機磁盤I / O被順序磁盤I / O代替(傳輸速率<<磁盤尋道時間)。

      所有大數據模式的目的都是使輸入/輸出(I / O)并行化以提高性能。

      數據在多個節點分布

      根據定義,大數據是不能用一臺機器的資源處理的數據。大數據的一個賣點是商品機的使用。一個典型的商品機有2-4 TB的磁盤。由于大數據是指遠大于它的數據集,數據將會跨多個節點分布。

      注意,將數據跨多個節點分布對于處理數十TB的數據來說不是真的有必要。你會發現大數據系統通常在節點適當的位置上處理數據。因為有大量的節點參與數據處理,必須將數據跨節點分布。因此,一個500GB的數據集也會被分布在多個節點上,即使集群中的一臺機器能夠存儲數據。這種數據分布有兩重目的:

      每個數據塊在不止一個節點上(默認Hadoop的復制因子為3)被復制。這使得系統對故障容錯。如果一個節點發生故障,其他節點具有故障節點上所承載數據的副本。

      為了并行處理,幾個節點參與數據處理。

      因此,10個節點內共享50 GB數據使得全部10個節點能夠處理自己的子數據集,實現5-10倍的性能提升。讀者也許會問為什么不是所有的數據都在網絡文件系統(NFS)上,其中每個節點都可以讀取它的部分。答案是從本地磁盤讀取比從網絡讀取速度更快。大數據系統使本地計算成為可能,因為在一個任務(一個應用程序實例)啟動前應用程序庫被復制到每個數據節點上。我們下一節再討論這個問題。

      應用程序被移動到數據位置

      對于我們這些乘著Java平臺環境浪潮的,三層架構已經滲透我們的觀念。在三層編程模式中,數據通過網絡導入之后在集中式應用程序層被處理。我們過去習慣于數據被分配而應用程序被集中化的概念。

      大數據無法處理這種網絡開銷。移動數TB的數據到應用層將使網絡飽和,導致效率極其低下,可能造成系統故障。在大數據世界中,數據被分布在各個節點上,但應用程序移動到數據。注意該過程并不容易,這很重要。不僅應用程序需要被移動到數據,而且所有的依賴庫也需要被移動到處理節點。如果你的集群上有數百個節點,很容易明白對于維護/調度為什么這會是一個噩夢。因此,大數據系統的設計使你可以集中部署代碼,且底層大數據系統在任務執行之前,將應用程序移動到處理節點。

      數據在某個節點本地處理

      這種數據被節點本地處理的屬性是大數據系統前面兩個屬性的自然結果。所有的大數據編程模型都是基于分散和并行處理的。網絡I / O是比磁盤I / O速度慢很多數量級。因為數據已經被分布到各個節點,應用程序庫被移動到節點,其目標是在適當的位置處理數據。

      雖然一個典型的大數據系統比較傾向于在節點上本地處理數據,但也有例外。大數據系統在盡可能靠近數據的節點上調度任務。從各個章節中你會明白對于某些類型的系統,某些任務需要跨節點提取數據。最起碼,每個節點的結果必須被同化在一個節點上(MapReduce有名的reduce階段或大規模并行編程模型類似的階段)。然而,對于大量用例來說,最終同化階段的數據與在節點本地任務處??理的原始數據相比要少得多。因此網絡開銷的影響通常(但不總是)忽略不計。

      連續讀取優于隨機讀取

      首先,你需要了解數據是如何從磁盤讀取的。磁盤頭需要被定位在數據在磁盤上所處的位置。該過程,需要花費一定時間,被稱為尋道操作。一旦磁盤頭根據需要被定位,數據將被從磁盤順序讀取。這被稱為傳輸操作。尋道時間大約為10毫秒;傳輸速度為(每1 MB)20毫秒的量級。這意味著如果我們從磁盤不同的1 MB部分讀取100 MB將花費我們10(尋道時間)* 100(seeks)= 1秒,再加20(每1MB的傳輸速率)* 100 = 2秒。讀取100 MB總共需要3秒。然而,如果我們從磁盤順序讀取100 MB,這將花費我們10(seek time)* 1(seek)= 10毫秒+ 20 * 100 = 2秒,總共2.01秒。

      注意,我們從2009年開始一直使用以Jeff Dean博士的演講為基礎的數字。無可否認的是,該數字已經改變;事實上,他們自那時起已經改進了。然而,數字之間的相對比例沒有改變,因此為保持一致性我們將繼續使用。

      大多數面向吞吐量的大數據編程模型利用了此功能。數據被從磁盤順次掃描并在內存中過濾。這與更傾向于隨機讀取的典型的關系數據庫管理系統(RDBMS)模型形成鮮明對比。

      一個示例

      假設你想獲取2000年按國家排序的總銷售數據,且該銷售數據隨機分布在多個節點。用大數據技術來實現這一目的可歸納為以下步驟:

      1.每個節點讀取全部銷售數據并過濾出不屬于2000年的銷售數據。數據隨機分布在所有節點并從磁盤上順序讀取。過濾發生在內存,而不是磁盤上,以避免尋道時間成本。

      2.每個國家一被發現,每個節點進程開始為其創建組,并增加給定國家區的銷售數額。(應用程序存在于所有節點上,且數據被本地處理到一個節點。)

      3.當所有節點都已完成了從磁盤清理銷售數據并且按國家編號計算總銷售額的過程后,他們發送其各自的編號到一個指定節點(我們稱之為接收節點assembler node),這個節點是在過程一開始所有節點一致同意的。

      4.指定的接收節點匯聚了每個節點按國家編號所有的總銷售額,并為每個狀態增加從各節點接收到的值。

      5.接收節點按狀態為最終數字排序,并提供結果。

      這一過程展示了大數據系統的典型特點:集中于使吞吐量最大化(單位時間內完成多少任務)勝于延遲(一個請求被響應的速度有多快,其中一個關鍵方面在于被評判的是哪個事務系統,因為我們希望響應速度盡可能快)。

      大數據編程模型

      你將會遇到的大數據編程模型的主要類型如下:

      ?大規模并行處理(MPP)數據庫系統(Massively parallel processing (MPP) database system):EMC的Greenplum和IBM的Netezza就是該系統的例子。

      ?內存中數據庫系統(In-memory database systems):例子包括Oracle Exalytics和SAP HANA。

      ?MapReduce系統(MapReduce systems):這些系統包括Hadoop,它是所有大數據系統中最通用的。

      ?批量同步并行(BSP)系統(Bulk synchronous parallel (BSP) systems):例子包括Apache HAMA和Apache Giraph。

      大規模并行處理(MPP)數據庫系統

      MPP系統的核心是基于包含在一列或一組列中的值采用某種形式的分割數據。例如,前面例子中計算按國家排序的 2000年的銷售額,我們可以按國家對數據進行分區,所以某些節點會包含某些國家的數據。這種分區方法使得每個節點來計算2000年的總銷售額。

      該系統的限制是顯而易見的。你需要在設計時確定數據如何分割。選擇的分割標準常常受底層用例驅動。因此,它不適合于臨時查詢。某些查詢??能夠以極快的速度執行,因為他們能利用數據是如何在節點間拆分的。其他查詢執行速度很慢,因為數據不是以它被訪問以執行查詢時一致的方式分布,導致所需的數據被通過網絡傳輸到各節點。

      為了解決這一限制,這些系統通常多次存儲數據,按不同的標準拆分。根據查詢,選擇適當的數據集。

      以下是MPP編程模型符合前面所定義的大數據系統屬性的方式(思考銷售額按國家排序的例子):

      數據按國家被拆分到不同節點上。

      每個節點包含所有用來處理其數據子集必要的應用程序庫。

      每個節點本地讀取數據到自身。當你運用不考慮數據是如何分布的查詢時例外;在這種情況下,每一個任務需要通過網絡從其它節點提取其自己的數據。

      對于每個任務,數據按順序讀取。所有的銷售數據都是共同定位并從磁盤提前。在內存中運用過濾(year =2000)。

      內存數據庫系統

      從操作的角度來看,內存數據庫系統與MPP系統相同。實現的不同之處在于,每個節點都有大量內存,且大部分數據被預加載到內存中。SAP HANA按照這一原則運行。其他系統,如Oracle Exalytics,使用專門的硬件以確保多臺主機被安置在一個單一設備上。內存數據庫本質上就像一個帶SQL接口的內存MPP數據庫。

      內存數據庫商業實現的主要缺點之一是,存在大量硬件和軟件鎖定。此外,由于該系統使用專有和專用硬件,通常價格昂貴。內存數據庫嘗試使用商品硬件可以快速增加集群的容量。舉個例子,一個具有25GB RAM的商用服務器。試圖承載1 TB 的in-memory數據庫需要40多個主機(考慮到需要在服務器上執行的其他活動)。 1 TB并不算太大,并且我們已經是一個多達40節點的集群。

      下面介紹內存數據庫的編程模型是如何滿足我們前面定義的大數據系統的屬性:

      在前面的示例中數據被按國家拆分。每個節點將數據加載到內存中。

      每個節點包含所有處理其子集必要的應用程序庫。

      每個節點本地讀取數據到其節點上。當你運用不考慮數據是如何分布的查詢時例外;在這種情況下,每一個任務需要從其它節點提取其自己的數據。

      由于數據緩存在內存中,只有當數據首次被讀入內存中時,連續數據讀取屬性才適用。

      MapReduce系統

      MapReduce是本書所依據的范例。它是四種方法中迄今為止最通用的。MapReduce的Hadoop實現的一些重要特征有以下幾方面:

      它使用商業規模硬件。注意商業規模并不意味著筆記本或臺式機。節點仍是企業規模,但它們使用最普通的組件。

      數據并不需要基于任何預定義的標準在不同節點間進行分區。

      用戶只需要定義兩個單獨進程:map 和reduce。

      本書中我們將廣泛討論MapReduce。在一個非常高的級別,MapReduce系統需要用戶定義一個map 進程和一個reduce進程。當Hadoop被用于實現MapReduce,數據通常分布在64 MB-128 MB的塊中,且每個塊被復制兩次(Hadoop中默認復制因子為3)。在計算2000年的銷售額并按國家排序的例子中,整個銷售數據作為塊(大小為64 MB-128 MB)被加載到Hadoop分布式文件系統中(HDFS)。當MapReduce進程啟動時,系統首先將所有應用程序庫(包括用戶定義的map和reduce進程)傳輸到每個節點。

      每個節點都會調度map任務從包含銷售數據文件中掃描塊。每個Mapper(各個節點上的)將讀取塊的記錄,并篩選出2000年的記錄。然后每個Mapper輸出一個包含鍵/值對的記錄。如果銷售記錄是2000年的,則Key代表國家,value代表給定記錄中的銷售數量。

      最后,可配置數量的Reducer接收來自每個Mapper的鍵/值對。鍵將被分配給特定的Reducer,以確保給定鍵是被一個且唯一一個Reducer接收的。然后每個Reducer對所有接收到的鍵/值對的銷售值數量進行合計。Reducer接收的數據格式是鍵(狀態)和該鍵(2000年的銷售記錄)的值列表。輸出被寫回到HDFS??蛻舳藢⑵鋸腍DFS讀出后,按國家對結果進行排序。最后一步可委托給Reducer,因為Reducer按排序順序接收分配給它的鍵。但在該例中,我們需要將Reducer的數量限制為一個來實現這一點。由于Mappers 和Reducers之間的通信產生網絡I / O,可能會導致瓶頸出現。本書后面我們將會詳細討論這個問題。

      這就是MapReduce編程模型是如何滿足前面定義的大數據系統的屬性的:

      數據被拆分到HDFS的大塊中。由于HDFS是分布式文件系統,數據塊以冗余的方式分布在所有節點上。

      應用程序庫,包括map 和reduce應用程序代碼,被傳播到所有任務節點上。

      每個節點本地讀取數據到其節點上。所有節點上的Mapper被啟動,并本地讀取數據塊到自身(大多數情況下,任務和磁盤塊之間的映射由scheduler負責,其可分配遠程塊到map任務以保持所有節點均工作)。

      對于大塊上的每個任務,數據在同一時間被順序讀?。▔K的大小通常為64 MB-128 MB)

      MapReduce范例的重要限制之一是,它不適合于迭代算法。絕大多數數據科學算法本質上都是迭代的,并最終收斂于一個解決方案。當被應用于這種算法時,MapReduce范例要求每個迭代作為單獨的MapReduce任務運行,且每次迭代常常使用由它的前一迭代產生的數據。但因為每個MapReduce任務從永久存儲中讀取新鮮數據,迭代需要將其結果存儲在永久存儲中以供下一次迭代使用。該過程產生不必要的I/ O,并對整體的吞吐量有顯著影響。這一限制被系統的BSP類解決了,接下來將會介紹。

      海量同步并行(BSP)系統

      系統的BSP類的運行方式與MapReduce方法非常類似。然而,MapReduce任務在其處理周期結束時終止,這點BSP不一樣,BSP系統由一個屏障(barrier)上同步的進程列表(等同于map進程)組成,將數據發送到主節點,交換相關信息。一旦迭代完成,主節點將指示每個處理節點恢復下一次迭代。

      在一個屏障上同步是并行編程中的一個常用概念。當許多線程負責執行各自的任務時使用,但在繼續進行之前需要達成一個檢查點。在決定有關計算的其余部分是繼續進行還是中止之前(并行或者按順序),所有線程需要完成一個達到某一點的任務時需要這種模式?,F實世界進程中總是使用同步屏蔽。例如,在一輛車到來之前,拼車的同伴經常在指定地點碰面。整個進程的速度僅僅和到達屏障的最后一個人(或線程)一樣快。

      BSP執行方法允許每個類似map進程緩存其先前迭代的數據,顯著提高了整個進程的吞吐量。在本書的數據科學章節我們將會討論BSP系統。它們與迭代算法相關。

      大數據和事務性系統

      在大數據背景下了解事務的概念是如何演變的非常重要。該討論與NoSQL數據庫相關。Hadoop擁有HBase作為其NoSQL數據存儲?;蛘?,你可以使用云中可用的Cassandra或NoSQL系統,如Amazon Dynamo。

      雖然大多數RDBMS用戶對數據庫中的ACID屬性充滿期待,這些屬性是有代價的。當底層數據庫在高峰期需要處理每秒百萬次的事務時,遵守最純粹形式的ACID特性是極具挑戰性的。

      注意 ACID是atomicity, consistency, isolation, 和durability的縮寫。詳細討論可參考以下鏈接:http://en.wikipedia.org/wiki/ACID。

      有些讓步是必須的,且這些讓步背后的動機隱含在所謂的CAP定理中(也稱為Brewer’s theorem)。 CAP是下列詞的縮寫:

      一致性: 所有節點始終看到相同的數據副本。

      可用性:保證每個請求在合理和明確的時間間隔內接收有關成功和失敗的響應。

      部分容忍:盡管部分失敗,系統繼續運行。

      該定理還證明,在任何系統中,前述特征中只有兩個可以實現,并不是所有?,F在,我們一起來看看不同類型的系統:

      ?一致和可用:一個帶ACID屬性的RDBMS就是一致和可用系統的一個例子。它不是分區容錯;如果RDBMS出現故障,用戶無法訪問數據。

      ?一致和部分容忍: 一個集群RDBMS就屬于這種系統。分布式事務確保所有用戶總是看到相同的數據(一致性),數據的分布特性確保盡管節點損失,該系統仍然可用。然而由于分布式事務,當二階段確認被發布,系統將在持續時間內不可用。這限制了可被系統所支持的并發事務的數量,反過來又限制了系統的可用性。

      ?可用性和部分容忍:被列為“最終一致性”的系統類型就屬于這一類??紤]一個非常受歡迎的電子商務網站,如Amazon.com。假設你正在瀏覽產品目錄,并注意到某個物品有兩件可供出售。根據購買流程的性質,你明白在你注意到有一定數量的物品可供購買和發出購買請求之間,可能有人會搶先購買了此物品。因此始終顯示最新值幾乎不可能,因為庫存在不斷變化。庫存的變化將傳播到服務于用戶的所有節點上。當該傳播發生時,為了提供庫存的最新值而阻止用戶瀏覽庫存將限制該網站的可用性,導致銷售遭受損失。因此,我們犧牲一致性換取可用性,分區容錯允許多個節點顯示相同的數據(盡管可能只有很短的時間內每個用戶能夠看到不同的數據,這取決于服務于他們的節點)。

      開發大數據系統時,這些決策是非常關鍵的。作為本書主要議題的MapReduce只是大數據生態系統的一個組成部分。它通常存在于其他產品如HBase的背景下,其中本節所討論的權衡取舍對于開發一個好的解決方案至關重要。

      我們的規模能有多大?

      本章前面例子中我們作了幾個假設。例如,我們忽略了CPU時間。對于大量的業務問題,計算復雜性并不是最重要的。然而,隨著計算能力的增長,從實現的角度來看,各域變得更為實用。一個例子是使用復雜的Bayesia統計技術的數據挖掘。這些問題計算起來確實代價很大。對于這些問題,我們需要增加節點的數目來進行處理,或運用其他替代方法。

      注意 大數據計算中使用的范例,如MapReduce,也已經被擴展到其他并行計算方法。例如,通用圖形處理器(GPGPU)計算實現了對于計算密集型問題的大規模并行。

      我們還忽略了網絡I / O成本。使用50個計算節點來處理數據還需要使用一個分布式文件系統以及從集群中的50個節點中收集數據的通信成本。在所有的大數據解決方案中,I / O成本占據主導地位。這些成本引入了計算過程中的順序依賴。

      一個計算密集型例子

      考慮用50個節點處理200 GB的數據,其中每個節點處理位于本地磁盤上4 GB的數據。每個節點需要80秒來讀數據(以每秒50 MB的速率)。無論我們計算地多快,也不能在80秒內完成。假設該進程的結果是一個大小為200 MB的總數據集,且每個節點生成該結果中的4 MB,通過1 Gbps的(每數據包1 MB)網絡傳輸到單個節點上用于顯示。這將需要大約3毫秒(每1 MB需要250微秒來通過網絡傳送,且每個數據包將數據傳送到目的地節點的網絡延遲假定為500微秒(基于先前引用的Jeff Dean博士的談話)。忽略計算成本,總處理時間不可能少于40.003秒。

      現在,假設我們有4000個節點,每個節點神奇般地從本地磁盤讀取其500 MB的數據,并生成0.1 MB的結果集。注意,如果數據以50 MB的塊被讀取我們的速度不能超過1秒。這轉化為約4000倍的最大程度的性能提升。換言之,對于某一類問題,如果它需要4000小時來完成處理,我們就不可能比用1個小時做得更好,無論在該問題上投入多少個節點。 4000倍可能聽起來很多,但至于我們可以達到多快的速度,有一個上限。在該簡化例子中,我們做了很多簡化系統的假設。我們還假設在應用程序邏輯中不存在順序依賴,這通常是一個錯誤假設。一旦我們增加了這些成本,最大性能增益可能大幅下降。

      順序依賴,是所有并行計算算法的克星,它限制了性能提升的程度。該限制眾所周知,并被記錄為Amdhal定律。

      Amdhal定律

      正如光速定義著我們在宇宙中旅行速度的理論極限,Amdhal定律定義著我們通過增加更多節點到集群可以實現的性能提升的極限。

      注意 有關amdhal’s Law的完整討論,參見http://en.wikipedia.org/wiki/Amdahl’s_law。

      總而言之,定律指出如果一個給定解決方案可與比例P(其中P的取值范圍為0 ?1 )完全并行,對于無限數量節點(說明集群上很多節點的一種方式),我們能獲得的最大性能提升為1 /( 1 -P)。因此,如果我們有1 %的執行無法做出,可以獲得的并行最佳提升為100倍。所有的程序都有一定的順序依賴,磁盤I / O和網絡I / O將增加更多。無論我們使用什么方法,對于能夠實現多大提升還是有限制的。

      大數據的業務用例

      大數據和Hadoop在商業世界中有多個應用程序。人們通常認為大數據的三大屬性為:

      容量

      速度

      種類

      容量是指所處理數據的大小。如果你的組織每晚需要在2小時內提取、加載和轉換2 TB的數據,你將面臨容量問題。

      速度是指大數據到達的速度。企業如Facebook和Twitter,都遇到了速度問題。他們每秒都會獲得大量必須立即處理的微小消息,發布到社交媒體網站,傳播到相關用戶(家人,朋友和追隨者),生成事件等等。

      種類是指越來越多的需要被處理的格式。企業搜索系統在組織中已經司空見慣。開源軟件,如Apache Solr,使得搜索系統無處不在。大多數非結構化數據并不獨立,具有與它相關聯的大量結構化數據。例如,思考一個簡單的文檔,如電子郵件。電子郵件擁有大量與它相關的元數據,例如包括:發件人,收信人,收信人指令,發送/接收時間,有關發件人/收信人的組織信息(如發送時的標題),等等。

      這些信息中有一些甚至是動態的。例如,如果你要分析好幾年的電子郵件(法律實踐領域有幾個關于這方面的用例),電子郵件首次發送時知道發件人或收信人的頭銜非常重要。動態主數據的這一特征是很常見的,并產生一些有趣的挑戰。

      大數據可幫助解決日常問題,如通過使用商品軟件和硬件大規模的提取、轉換、加載(ETL)事項。尤其是開源Hadoop,它在商用服務器上運行,并且可通過增加更多節點來擴展,使得ETL(或ELT,如它在大數據領域通常被稱作的那樣)以商業成本執行得更快。

      一些圍繞Hadoop和HDFS的開源產品已經發展到支持速度和各種用例。新數據格式已經發展到能夠管理圍繞大規模數據處理的I / O性能。本書將討論這些發展背后的動機以及針對他們的適當的用例。

      Storm(從Twitter發展而來)和Apache Flume(專門針對大規模的日志分析)發展來處理速度因素。選擇使用哪個軟件取決于該進程需要離“實時”有多近。Storm對于解決需要“更加實時”處理的問題比Flume有用。

      關鍵信息是:大數據是一個各種產品協同工作以解決非常復雜的業務問題的生態系統。Hadoop往往是這些解決方案的核心。了解Hadoop使你能夠深入理解如何使用大數據生態系統中的其他新產品。

      小結:

      現在大數據已經成為主流,而其背后的兩個主要驅動因素是開源Hadoop軟件和云計算的出現。這兩種發展使得人們大規模地采用大數據方法以較低的成本處理業務問題。Hadoop是所有大數據解決方案的基石。雖然其他編程模型,如MPP和BSP,也紛紛涌現以處理非常具體的問題,但當要處理的數據規模達到TB級規模時,它們都以某種或其他形式依賴于Hadoop。深入理解Hadoop使得其他編程模型的用戶使用起來更有效。本書的目的正是使你實現這一點。

      責任編輯:王培

      分享:
      延伸閱讀
        數博故事
        貴州

        貴州大數據產業政策

        貴州大數據產業動態

        貴州大數據企業

        更多
        大數據概念_大數據分析_大數據應用_大數據百科專題
        企業
        更多
        两个人的房间在线观看完整版