電商用戶數(shù)據(jù)分析系統(tǒng)設(shè)計中的平臺核心組件技術(shù)介紹概述目錄TOC\o"1-3"\h\u26983電商用戶數(shù)據(jù)分析系統(tǒng)設(shè)計中的平臺核心組件技術(shù)介紹概述 169211.1Hadoop架構(gòu) 1323731.1.1HDFS架構(gòu)原理 1318481.1.2MapReduce計算框架 257191.1.3Yarn資源調(diào)度 4102131.2Flume原理 6176911.3Kafka原理 81.1Hadoop架構(gòu)Hadoop是一個由Apache基金會開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)，主要解決海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的分析計算問題。Hadoop目前分為HDFS（數(shù)據(jù)存儲）、MapReduce（數(shù)據(jù)計算）、Yarn（資源調(diào)度）和Common（輔助工具）共四個部分。1.1.1HDFS架構(gòu)原理隨著數(shù)據(jù)量越來越大，在一個操作系統(tǒng)存不下所有的數(shù)據(jù)，那么就需要分到更多的操作系統(tǒng)管理的磁盤中去，但是這樣做不方便管理和維護，這時就迫切需要一種系統(tǒng)來管理多臺機器上的文件，這就是分布式文件管理系統(tǒng)。HDFS就是分布式文件管理系統(tǒng)的一種。HDFS，全稱HadoopDistributedFileSystem，首先是一個文件系統(tǒng)，用于存儲文件，通過目錄樹來定位文件；其次，它是分布式的，由很多服務(wù)器聯(lián)合起來實現(xiàn)其功能，集群中的服務(wù)器有各自的角色。HDFS適用一次寫入、多次讀出的場景，且不支持對文件的修改，適合用來做數(shù)據(jù)分析，并不適合用來做網(wǎng)盤應(yīng)用。HDFS具有高容錯性，可以將數(shù)據(jù)自動保存多個副本，通過增加副本的提高容錯性，某一個副本丟失以后，可以自動恢復(fù)。能夠處理數(shù)據(jù)規(guī)模達達到GB、TB甚至PB級別，并且可以構(gòu)建在廉價機器上，通過多副本機制，提高可靠性。HDFS的架構(gòu)如圖2-1所示：圖2-1HDFS架構(gòu)從圖中可以看到，HDFS包括NameNode、DataNode、Client和SencondaryNamenode。其中NameNode負(fù)責(zé)管理HDFS的名稱空間，配置副本策略，管理數(shù)據(jù)塊的映射信息，處理客戶端的讀寫請求。DataNode用于存儲實際的數(shù)據(jù)塊，執(zhí)行數(shù)據(jù)塊的讀或者寫操作。Client也就是客戶端，當(dāng)文件上傳到HDFS的時候，Client敷著將文件切分成一個一個的Block，然后進行上傳；與NameNode交互，獲取文件的位置信息；與DataNode交互，讀取或?qū)懭霐?shù)據(jù)；提供管理HDFS的命令；提供對HDFS增刪查改的命令。SecondaryNameNode用于輔助NameNode，分擔(dān)其工作量，比如定期合并Fsimage和Edits，并推送給NameNode，在緊急情況下，也可以輔助恢復(fù)NameNode。1.1.2MapReduce計算框架MapReduce是一個分布式編程框架，核心框架是基于Hadoop的數(shù)據(jù)分析計算，將數(shù)據(jù)處理過程分為兩個階段：Map和Reduce，Map過程負(fù)責(zé)把一個進程分解成多個進程，Reduce過程負(fù)責(zé)把分解后多進程處理的結(jié)果進行匯總。1）MapReduce框架具有以下優(yōu)點：（1）MapReduce易于編程通過簡單的實現(xiàn)一些接口，就可以完成一個分布式程序，這個分布式程序可以分布到大量廉價的PC機器上運行，也就是說你寫一個分布式程序，跟寫一個簡單的串行程序是一模一樣的，就是因為這個特點使得MapReduce編程變得非常流行。（2）良好的擴展性當(dāng)你的計算資源得不到滿足的時候，你可以通過簡單的增加機器來擴展計算能力。（3）高容錯性MapReduce設(shè)計的初衷就是使程序能夠部署在廉價的PC機器上，這就要求其具有很高的容錯性。（4）適合PB級別以上海量數(shù)據(jù)的離線處理可以實現(xiàn)上千臺服務(wù)器集群并發(fā)工作，提供海量數(shù)據(jù)處理能力。2）同時具有以下缺點：（1）不擅長實時計算MapReduce無法像MySQL一樣，在毫秒或者秒級內(nèi)返回結(jié)果。（2）不擅長流式計算流式計算的輸入數(shù)據(jù)是動態(tài)的，而MapReduce的輸入數(shù)據(jù)是靜態(tài)的，不能動態(tài)變化。這是因為MapReduce自身的設(shè)計特點決定了數(shù)據(jù)源必須是靜態(tài)的。（3）不擅長DAG（有向圖）計算多個應(yīng)用程序存在依賴關(guān)系，后一個應(yīng)用程序的輸入為前一個的輸出。在這種情況下，MapReduce并不是不能做，而是使用后，每個MapReduce作業(yè)的輸出結(jié)果都會寫入到磁盤，會造成大量的磁盤IO，導(dǎo)致性能非常的低下。MapReduce的核心編程思想如下圖2-2所示：圖2-2MapReduce的核心編程思想分布式的運算程序往往需要分成至少2個階段。第一個階段的MapTask并發(fā)實例，完全并行運行，互不相干。第二個階段的ReduceTask并發(fā)實例互不相干，但是他們的數(shù)據(jù)依賴于上一個階段的所有MapTask并發(fā)實例的輸出。MapReduce編程模型只能包含一個Map階段和一個Reduce階段，如果用戶的業(yè)務(wù)邏輯非常復(fù)雜，那就只能多個MapReduce程序，串行運行。MapReduce的工作流程是，MapTask收集我們的map()方法輸出的kv對，放到內(nèi)存緩沖區(qū)中，從內(nèi)存緩沖區(qū)不斷溢出本地磁盤文件，可能會溢出多個文件，多個溢出文件會被合并成大的溢出文件，在溢出過程及合并的過程中，都要調(diào)用Partitioner進行分區(qū)和針對key進行排序，ReduceTask根據(jù)自己的分區(qū)號，去各個MapTask機器上取相應(yīng)的結(jié)果分區(qū)數(shù)據(jù)，ReduceTask會取到同一個分區(qū)的來自不同MapTask的結(jié)果文件，ReduceTask會將這些文件再進行合并（歸并排序），合并成大文件后，Shuffle的過程也就結(jié)束了，后面進入ReduceTask的邏輯運算過程（從文件中取出一個一個的鍵值對Group，調(diào)用用戶自定義的reduce()方法）。1.1.3Yarn資源調(diào)度Yarn是一個資源調(diào)度平臺，負(fù)責(zé)為運算程序提供服務(wù)器運算資源，相當(dāng)于一個分布式的操作系統(tǒng)平臺，而MapReduce等運算程序則相當(dāng)于運行于操作系統(tǒng)之上的應(yīng)用程序。YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等組件構(gòu)成，如圖2-3所示。圖2-3Yarn組成其中，ResourceManager（RM）主要作用處理客戶端請求，監(jiān)控NodeManager，啟動或監(jiān)控ApplicationMaster，資源的分配與調(diào)度。ApplicationMaster（AM）作用負(fù)責(zé)數(shù)據(jù)的切分，為應(yīng)用程序申請資源并分配給內(nèi)部的任務(wù)，任務(wù)的監(jiān)控與容錯。NodeManager（NM）主要作用管理單個節(jié)點上的資源，處理來自ResourceManager的命令，處理來自ApplicationMaster的命令。工作機制如圖2-4所示：圖2-4Yarn工作機制MR程序提交到客戶端所在的節(jié)點。YarnRunner向ResourceManager申請一個Application。RM將該應(yīng)用程序的資源路徑返回給YarnRunner。該程序?qū)⑦\行所需資源提交到HDFS上。程序資源提交完畢后，申請運行mrAppMaster。RM將用戶的請求初始化成一個Task。其中一個NodeManager領(lǐng)取到Task任務(wù)。該NodeManager創(chuàng)建容器Container，并產(chǎn)生MRAppmaster。Container從HDFS上拷貝資源到本地。MRAppmaster向RM申請運行MapTask資源。RM將運行MapTask任務(wù)分配給另外兩個NodeManager，另兩個NodeManager分別領(lǐng)取任務(wù)并創(chuàng)建容器。MR向兩個接收到任務(wù)的NodeManager發(fā)送程序啟動腳本，這兩個NodeManager分別啟動MapTask，MapTask對數(shù)據(jù)分區(qū)排序。MrAppMaster等待所有MapTask運行完畢后，向RM申請容器，運行ReduceTask。ReduceTask向MapTask獲取相應(yīng)分區(qū)的數(shù)據(jù)。程序運行完畢后，MR會向RM申請注銷自己。目前，Hadoop作業(yè)調(diào)度器主要有三種：FIFO、CapacityScheduler和FairScheduler。Hadoop3.1.3默認(rèn)的資源調(diào)度器是CapacityScheduler。先進先出調(diào)度器（FIFO），按照到達時間順序，先到先分配資源。容量調(diào)度器（CapasityScheduler），支持多個隊列，每個隊列可以配置一定的資源，每個隊列采用FIFO調(diào)度策略。公平調(diào)度器（FairScheduler），如圖2-5所示圖2-5公平調(diào)度器原理1.2Flume原理Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)。Flume基于流式架構(gòu)，靈活簡單，如下圖所示，F(xiàn)lume的主要作用就是實時讀取服務(wù)器本地磁盤的數(shù)據(jù)，將數(shù)據(jù)寫入到HDFS存儲系統(tǒng)中。圖2-8Flume作用Flume組成架構(gòu)如圖2-9，圖2-10所示：圖2-9Flume組成架構(gòu)圖2-10Flume組成架構(gòu)詳情組件詳細(xì)介紹如下：Agent是一個JVM進程，它以事件的形式將數(shù)據(jù)從源頭送至目的，是Flume數(shù)據(jù)傳輸?shù)幕締卧gent主要有3個部分組成，Source、Channel、Sink。Source是負(fù)責(zé)接收數(shù)據(jù)到FlumeAgent的組件。Source組件可以處理各種類型、各種格式的日志數(shù)據(jù)，包括avro、thrift、exec、jms、spoolingdirectory、netcat、sequencegenerator、syslog、http、legacy。Channel是位于Source和Sink之間的緩沖區(qū)。因此，Channel允許Source和Sink運作在不同的速率上。Channel是線程安全的，可以同時處理幾個Source的寫入操作和幾個Sink的讀取操作。Flume自帶兩種Channel：MemoryChannel和FileChannel。MemoryChannel是內(nèi)存中的隊列。MemoryChannel在不需要關(guān)心數(shù)據(jù)丟失的情景下適用。如果需要關(guān)心數(shù)據(jù)丟失，那么MemoryChannel就不應(yīng)該使用，因為程序死亡、機器宕機或者重啟都會導(dǎo)致數(shù)據(jù)丟失。FileChannel將所有事件寫到磁盤。因此在程序關(guān)閉或機器宕機的情況下不會丟失數(shù)據(jù)。Sink不斷地輪詢Channel中的事件且批量地移除它們，并將這些事件批量寫入到存儲或索引系統(tǒng)、或者被發(fā)送到另一個FlumeAgent。Sink是完全事務(wù)性的。在從Channel批量刪除數(shù)據(jù)之前，每個Sink用Channel啟動一個事務(wù)。批量事件一旦成功寫出到存儲系統(tǒng)或下一個FlumeAgent，Sink就利用Channel提交事務(wù)。事務(wù)一旦被提交，該Channel從自己的內(nèi)部緩沖區(qū)刪除事件。Sink組件目的地包括hdfs、logger、avro、thrift、ipc、file、null、HBase、solr、自定義。Event是傳輸單元，F(xiàn)lume數(shù)據(jù)傳輸?shù)幕締卧?，以事件的形式將?shù)據(jù)從源頭送至目的地。1.3Kafka原理Kafka是一個分布式的基于發(fā)布/訂閱模式的消息隊列，主要應(yīng)用于大數(shù)據(jù)實時處理領(lǐng)域。Kafka的基礎(chǔ)架構(gòu)如下：圖2-12Kafka架構(gòu)設(shè)計（1）Producer：消息生產(chǎn)者，就是向kafkabroker發(fā)消息的客戶端；（2）Consumer：消息消費者，向kafkabroker取消息的客戶端；（3）ConsumerGroup（CG）：消費者組，由多個consumer組成。消費者組內(nèi)每個消費者負(fù)責(zé)消費不同分區(qū)的數(shù)據(jù)，一個分區(qū)只能由一個消費者消費；消費者組之間互不影響。所有的消費者都屬于某個消費者組，即消費者組是邏輯上的一個訂閱者。（4）Broker：一臺Kafka服務(wù)器就是一個broker。一個集群由多個broker組成。一個broker可以容納多個Topic。（5）Topic：可以理解為一個隊列，生產(chǎn)者和消費者面向的都是一個topic；（6）Partition：為了實現(xiàn)擴展性，一個非常大的topic可以分布到多個broker（即服務(wù)器）上，一個Topic可以分為多個partition，每個partition是一個有序的隊列；（7）Replica：副本，為保證集群中的某個節(jié)點發(fā)生故障時，該節(jié)點上的partition數(shù)據(jù)不丟失，且kafka仍然能夠繼續(xù)工作，kafka提供了副本機制，一個topic的每個分區(qū)都有若干個副本，一個leader和若干個follower。（8）Leader：每個分區(qū)多個副本的“主”，生產(chǎn)者發(fā)送數(shù)據(jù)的對象，以及消費者消費數(shù)據(jù)的對象都是leader。（9）Follower：每個分區(qū)多個副本中的“從”，實時從Leader中同步數(shù)據(jù)，保持和Leader數(shù)據(jù)的同步。Leader發(fā)生故障時，某個Follower會成為新的Leader。Kafka中消息是以Topic進行分類的，生產(chǎn)者生產(chǎn)消息，消費者消費消息，都是面向Topic的。Topic是邏輯上的概念，而partition是物理上的概念，每個partition對應(yīng)于一個log文件，該log文件中存儲的就是producer生產(chǎn)的數(shù)據(jù)。Producer生產(chǎn)的數(shù)據(jù)會被不斷追加到該lo