計(jì)算機(jī)本科畢業(yè)論文-基于大數(shù)據(jù)的用戶行為日志系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

摘要針對用戶行為日志，提出了一種基于大數(shù)據(jù)的用戶行為日志系統(tǒng)的設(shè)計(jì)方案。該方案基于公司現(xiàn)有框架，對用戶行為日志采集系統(tǒng)進(jìn)行了重組，提出了高可靠性、高可用性的設(shè)計(jì)要求。Flume框架用于實(shí)時(shí)收集用戶行為日志數(shù)據(jù)，ETL攔截器和Type攔截器用于過濾日志數(shù)據(jù)。通過優(yōu)化參數(shù)配置，實(shí)現(xiàn)了多線程日志采集，提高了日志采集系統(tǒng)的可靠性和實(shí)用性。Kafka框架用于實(shí)時(shí)傳輸日志。通過優(yōu)化生產(chǎn)者端、中間商端和消費(fèi)者端，實(shí)現(xiàn)了消息傳輸?shù)臏?zhǔn)確主語義，使系統(tǒng)的消息傳輸和存儲(chǔ)更加穩(wěn)定高效。Hive用于逐層構(gòu)建數(shù)據(jù)倉庫。通過分析用戶主題的相關(guān)指標(biāo)，為系統(tǒng)決策提供支持。實(shí)現(xiàn)數(shù)據(jù)可視化模塊，為系統(tǒng)開發(fā)人員提供方便、準(zhǔn)確的可視化服務(wù)。關(guān)鍵詞：大數(shù)據(jù)；用戶行為；Kafka框架；Hive；系統(tǒng)設(shè)計(jì)

相關(guān)概述隨著時(shí)代的變化，網(wǎng)站的高效發(fā)展，已經(jīng)存在于我們的生活之中，那么對于分析用戶行日志已經(jīng)成為每個(gè)網(wǎng)站必有的要求。企業(yè)的發(fā)展離不開決策，而決策又來自于數(shù)據(jù)，所以需要一套用戶行為日志分析系統(tǒng)，對網(wǎng)頁甚至各種各樣的日志數(shù)據(jù)進(jìn)行分析，分析后的數(shù)據(jù)都將是最好決策的基礎(chǔ)。開發(fā)環(huán)境介紹1.Hadoop大數(shù)據(jù)平臺(tái)提供了強(qiáng)大的存儲(chǔ)以及計(jì)算等強(qiáng)大的功能，它是一個(gè)框架體系可以容納各種所需要的插件以及軟件，兼容性也是極好的，將可用的計(jì)算機(jī)集群分配數(shù)據(jù)，完成存儲(chǔ)和計(jì)算任務(wù)，這些集群可以方便地?cái)U(kuò)展到數(shù)以千計(jì)的節(jié)點(diǎn)中，具有高擴(kuò)展性。2.Hive是一個(gè)基于Hadoop的數(shù)倉工具，用來對數(shù)據(jù)進(jìn)行ETL操作的，原理是將Hadoop存儲(chǔ)的文件映射成一張數(shù)據(jù)庫表，并切可以使用類似sql的語句進(jìn)行操作，底層是將sql轉(zhuǎn)發(fā)成mapreduce任務(wù)來執(zhí)行，數(shù)據(jù)倉庫的特征在于面向主題、集成性、穩(wěn)定性和時(shí)變性?？梢暂p松幫助公司對海良數(shù)據(jù)進(jìn)行分析處理。3.開發(fā)工具的是使用的idea編輯器，主要是其對用戶非常友好，有智能代碼提示，以及高效的插件處理。系統(tǒng)分析信息時(shí)代的快速發(fā)展，海量數(shù)據(jù)的處理與分析都在不斷發(fā)展，讓人們的生活也越來越智能越來越便捷，進(jìn)隨著時(shí)代的發(fā)展，特別是網(wǎng)頁的高速發(fā)展，通過在網(wǎng)頁上的點(diǎn)擊我們也可以獲取到更多的用戶行為日志，國內(nèi)的電商更是提出千人千面，而這些數(shù)據(jù)都來自人們多頁面的點(diǎn)擊、瀏覽時(shí)長，而對于網(wǎng)頁的分析是非常廣泛的，從最簡單的來說訪問者來自哪里，喜歡觀看的頁面是哪一個(gè)，不喜歡的是哪一個(gè)，通過大數(shù)據(jù)分析從而改善用戶最長時(shí)間的停留在該頁面，讓訪客更多的沉淀下來變成會(huì)員或客戶，通過更少的投入獲取最大化的收入。所以本課題就是應(yīng)對用戶行為日志的高效采集實(shí)現(xiàn)實(shí)時(shí)采集，通過Kafka對數(shù)據(jù)進(jìn)行實(shí)時(shí)傳輸，在數(shù)據(jù)分層建模離線處理以及Etl操作以及最后進(jìn)行展示。1.設(shè)計(jì)合理框架，對日志進(jìn)行采集，進(jìn)行前端埋點(diǎn)JavaScript采集，并使用Flume進(jìn)行實(shí)時(shí)的采集。2.數(shù)據(jù)預(yù)處理，對采集到的數(shù)據(jù)進(jìn)行處理，應(yīng)對于采集時(shí)的一些空數(shù)據(jù)，臟數(shù)據(jù)進(jìn)行處理。3.數(shù)據(jù)入庫，將采集到的數(shù)據(jù)進(jìn)行存入到數(shù)據(jù)倉庫并進(jìn)行相應(yīng)的Etl操作。4.數(shù)據(jù)的展示，將數(shù)據(jù)處理完成后運(yùn)用可視化工具進(jìn)行圖表展示。系統(tǒng)分析基本架構(gòu)采用基于大數(shù)據(jù)平臺(tái)Hadoop搭建大數(shù)據(jù)平臺(tái)，某些網(wǎng)站每天將會(huì)產(chǎn)生大約50G的日志文件，分布在不同服務(wù)器中對于數(shù)據(jù)采集都是一種很難，將數(shù)據(jù)采集完成后的入庫的處理也越顯示出來一些局限行，當(dāng)前設(shè)計(jì)架構(gòu)基本可以滿足以上需求。圖2.1當(dāng)前系統(tǒng)主要框架詳細(xì)設(shè)計(jì)思路采用前端埋點(diǎn)采集，提高數(shù)據(jù)采集的實(shí)時(shí)行基于flume進(jìn)行采集，實(shí)現(xiàn)對頁面的實(shí)時(shí)采集，以及連續(xù)采集還可以通過之定義js采集，在網(wǎng)頁中預(yù)先加入小段javascript代碼，這個(gè)代碼片段一般會(huì)動(dòng)態(tài)創(chuàng)建一個(gè)script標(biāo)簽，并將src屬性指向一個(gè)單獨(dú)的js文件，此時(shí)這個(gè)單獨(dú)的js文件（圖中綠色節(jié)點(diǎn)）會(huì)被瀏覽器請求到并執(zhí)行，這個(gè)js往往就是真正的數(shù)據(jù)收集腳本。通過Kafka進(jìn)行數(shù)據(jù)的傳輸，提高數(shù)據(jù)的傳輸效率基于Kafka的數(shù)據(jù)傳輸優(yōu)越性進(jìn)行數(shù)據(jù)傳輸以及可以對數(shù)據(jù)進(jìn)?分類也就是不同的topic，累加器相當(dāng)于是?個(gè)緩沖區(qū)，這個(gè)緩沖區(qū)其實(shí)是?個(gè)HashMap其中Key是Topic加分區(qū)號的形式，Value是?個(gè)雙端隊(duì)列。之所以這?會(huì)使?雙端隊(duì)列原因是因?yàn)橄l(fā)送失敗的時(shí)候會(huì)有?個(gè)重試的機(jī)制，如果消息沒有發(fā)送成功會(huì)再次放?雙端隊(duì)列中之后會(huì)被再次發(fā)送，其次還有?個(gè)Send線程來管理每個(gè)區(qū)的??，因?yàn)?產(chǎn)者底層是按照批次來進(jìn)?數(shù)據(jù)發(fā)送的，這?的感覺就像是?個(gè)輪詢，但是這樣的描述也不是特別的準(zhǔn)確，?先它在向雙端隊(duì)列?數(shù)據(jù)的時(shí)候會(huì)先做?下判斷(判斷這個(gè)數(shù)據(jù)是否已經(jīng)達(dá)到這個(gè)批次)如果達(dá)到了就會(huì)通過Send線程就會(huì)將這?批數(shù)據(jù)發(fā)送出去，反之則繼續(xù)等待。還有?種情況是按照時(shí)間來操作的，如果消息達(dá)到?定的時(shí)間以后回去檢查?下有沒有達(dá)到這個(gè)發(fā)送的批次閾值通過hive對數(shù)據(jù)進(jìn)行etl處理，減少重復(fù)重復(fù)操作基于hive搭建數(shù)倉對數(shù)倉進(jìn)行分層，減少重復(fù)重復(fù)操作，提高數(shù)據(jù)的復(fù)用率，規(guī)范每一層的開發(fā)。通過可視化工具進(jìn)行展示，實(shí)時(shí)查看數(shù)據(jù)分析情況數(shù)據(jù)庫數(shù)據(jù)表確認(rèn)收集的信息：名稱途徑備注訪問時(shí)間webserverNginx$msecIPwebserverNginx$remote_addr域名javascriptdocument.domainURLjavascriptdocument.URL頁面標(biāo)題javascriptdocument.title分辨率javascriptwindow.screen.height&width顏色深度javascriptwindow.screen.colorDepthReferrerjavascriptdocument.referrer技術(shù)選型本章主要說到此次系統(tǒng)開發(fā)過程中到的需要的一些技術(shù)，主要有flume采集技術(shù)，Kafka消息中間件技術(shù)、數(shù)倉技術(shù)以及hive技術(shù)，對于技術(shù)的應(yīng)用是該系統(tǒng)成功的關(guān)鍵。數(shù)據(jù)采集Flume采集時(shí)作為當(dāng)前實(shí)時(shí)以及離線采集中開源工具的頂流，它是一個(gè)結(jié)構(gòu)簡單、分布式的、高可用的、可靠的采集系統(tǒng)，主要結(jié)構(gòu)為，Source、Channel和Sink三個(gè)組成部分，通過它可以實(shí)現(xiàn)實(shí)時(shí)采集中實(shí)時(shí)解析數(shù)據(jù)分析數(shù)據(jù)的應(yīng)用。圖3.1flume架構(gòu)圖1.Flume在1.7以后提供了?個(gè)TailDirSource?來?持多?錄和斷點(diǎn)續(xù)傳功能。斷點(diǎn)續(xù)傳主要保證在服務(wù)器掛掉的情況下，再次啟動(dòng)服務(wù)數(shù)據(jù)不會(huì)丟失的問題。其原理就是在底層維護(hù)了?個(gè)offffset偏移量(也就是每次讀取?件的偏移量)Flume會(huì)通過這個(gè)偏移量來找到上次?件讀取的位置從?實(shí)現(xiàn)了斷點(diǎn)續(xù)傳的功能。2.Source簡單來說就是采集源，用于跟數(shù)據(jù)源對接，以獲取數(shù)據(jù)。3.Sink：下沉地，采集數(shù)據(jù)的傳送目的，用于往下一級agent傳遞數(shù)據(jù)或者往最終存儲(chǔ)系統(tǒng)傳遞數(shù)據(jù)。4.Channel：agent內(nèi)部的數(shù)據(jù)傳輸通道，用于從source將數(shù)據(jù)傳遞到sink；在整個(gè)數(shù)據(jù)的傳輸?shù)倪^程中，流動(dòng)的是event，它是Flume內(nèi)部數(shù)據(jù)傳輸?shù)淖罨締卧?。event將傳輸?shù)臄?shù)據(jù)進(jìn)行封裝。如果是文本文件，通常是一行記錄，event也是事務(wù)的基本單位。event從source，流向channel，再到sink，本身為一個(gè)字節(jié)數(shù)組，并可攜帶headers(頭信息)信息。event代表著一個(gè)數(shù)據(jù)的最小完整單元，從外部數(shù)據(jù)源來，向外部的目的地去。5.一個(gè)完整的event包括：eventheaders、eventbody、event信息，其中event信息就是flume收集到的日記記錄。(1)Source介紹幾種常用的sourceAvro

source：可以支持監(jiān)聽端口和IP。ThriftSource：跟Avro

source差不多但是不支持IP過濾，支持RPC協(xié)議。ExecSource：支持Linux命令。JMSSource：從jms消息隊(duì)列獲取消息。SpoolingDirectorySource：解析變更的數(shù)據(jù)可靠性極強(qiáng)。TaildirSource：可以監(jiān)控多個(gè)文件，有變更就傳輸不適合Windows系統(tǒng)。KafkaSource：支持從Kafka指定的topic中讀取數(shù)據(jù)。NetCatTCPSource：監(jiān)聽指定端口每一行文本都是一個(gè)event。(2)SinkSink是flume接收數(shù)據(jù)的容器，接收來自channel的數(shù)據(jù)，將數(shù)據(jù)寫入Kafka或者其他數(shù)據(jù)庫中。介紹幾種常用的sinkLoggerSink

:記錄info級別的數(shù)據(jù)HDFSSink:將數(shù)據(jù)寫入HDFS中HIVESink:將數(shù)據(jù)寫入HIVE中KAFKASink:將數(shù)據(jù)寫入KAFKA中HBASESink:將數(shù)據(jù)寫入HBASE中(3)ChannelChannel作為flume的管道接收source中的數(shù)據(jù)進(jìn)行暫存，然后根據(jù)規(guī)則將數(shù)據(jù)發(fā)送到sink中。介紹幾種常用的channelMemoryChannel：數(shù)據(jù)存入內(nèi)存JDBCChannel：存儲(chǔ)在持久化存儲(chǔ)庫中KAFKAChannel：存儲(chǔ)在Kafka集群中FILEChannel：文本存儲(chǔ)磁盤SpillableMemoryChannel：存儲(chǔ)在內(nèi)存隊(duì)列和磁盤中FlumeChannelSelectors：如果類型沒有指定，那么默認(rèn)“replicating”CustomChannelSelector：一個(gè)自定義channel選擇器（selector）是實(shí)現(xiàn)ChannelSelector的接口。消息中間件這次使用了Kafka作為消息中間件用來傳輸數(shù)據(jù)，之所以選中Kafka主要因?yàn)橐韵聨c(diǎn)：1.對于海量數(shù)據(jù)的傳輸對于海量數(shù)據(jù)的傳輸首先要先了解Kafka的結(jié)構(gòu)，結(jié)構(gòu)圖如下：圖3.2Kafka結(jié)構(gòu)圖Kafka每次傳輸數(shù)據(jù)都將數(shù)據(jù)會(huì)有生產(chǎn)者將數(shù)據(jù)放入到broker里每個(gè)broker里又有topic，每個(gè)topic里又有partition，當(dāng)數(shù)據(jù)進(jìn)入時(shí)數(shù)據(jù)就會(huì)根據(jù)broker劃分又會(huì)根據(jù)topic進(jìn)行劃分，Kafka將數(shù)據(jù)不斷追加到本地磁盤文件末尾的，并不是隨機(jī)讀寫的，這也導(dǎo)致了Kafka的高吞吐量特別高，但是這也有一個(gè)缺點(diǎn)就是不能刪除數(shù)據(jù)，而Kafka也不會(huì)刪除數(shù)據(jù)。2.對于跨機(jī)器傳輸數(shù)據(jù)，傳輸數(shù)據(jù)快。Kafka可以進(jìn)行集群部署的依靠zookeeper是可以搭建Kafka分布式集群，這也是Kafka的特性之一。Kafka傳輸數(shù)據(jù)特別快從生產(chǎn)者來說，生產(chǎn)者發(fā)送數(shù)據(jù)是按照批進(jìn)行發(fā)送的并不是一條一條數(shù)據(jù)進(jìn)行發(fā)送的，還有一個(gè)就是最重要的零拷?技術(shù)的應(yīng)?，零拷?其實(shí)是OS層?的?個(gè)技術(shù)，就是操作系統(tǒng)的PageCache利?這個(gè)操作系統(tǒng)的緩存?在加上調(diào)?操作系統(tǒng)的SendFile函數(shù)實(shí)現(xiàn)了對數(shù)據(jù)的處理提?了性能，所以采?零拷?技術(shù)之后就直接把進(jìn)程之間的流拷?直接省略了，使?操作系統(tǒng)的Buffffer從??幅的提升了性能，這也是Kafka特別快的原因。3.Kafka數(shù)據(jù)丟失。在Kafka的?產(chǎn)者將消息發(fā)送到Broker的過程可能會(huì)出現(xiàn)消息的重復(fù)或者丟失的情況，這個(gè)主要是靠ACK的配置來決定的。①Ack=-1：這種情況是不會(huì)丟失數(shù)據(jù)的，因?yàn)锽roker包含Topic，Topic?包含Partition，?Partition?邊還有副本，這?就會(huì)有Leader和Follower的概念，此時(shí)?產(chǎn)者發(fā)送消息后Leader會(huì)等待所有Follower的響應(yīng)后才會(huì)向?產(chǎn)者響應(yīng)，此時(shí)是不會(huì)丟失數(shù)據(jù)的，但是會(huì)有數(shù)據(jù)重復(fù)的問題這個(gè)問題可以在下游消費(fèi)數(shù)據(jù)的時(shí)候進(jìn)?處理?般都是采?去重的操作。②Ack=0：此時(shí)相當(dāng)于是消息的異步發(fā)送，?產(chǎn)者發(fā)送消息以后不會(huì)等待Leader這邊的任何響應(yīng)，如果在發(fā)送消息后系統(tǒng)發(fā)?停電或者宕機(jī)此時(shí)是會(huì)丟失數(shù)據(jù)的但是這種機(jī)制的特點(diǎn)是效率特別?。③Ack=1：此時(shí)?產(chǎn)者會(huì)等待Leader響應(yīng)，但是Leader響應(yīng)的時(shí)間是在接受到數(shù)據(jù)后?不是所有的Follower成功后繼續(xù)你那個(gè)響應(yīng)，如果在Leader剛響應(yīng)并且Follower沒有來得及進(jìn)?同步，此時(shí)服務(wù)器宕機(jī)也會(huì)丟失數(shù)據(jù)的。④Kafka的主要架構(gòu)Producer是Kafka消息的生成者Consumer是Kafka消息的消費(fèi)者ConsumerGroup是Kafka消費(fèi)者組，可以并行消費(fèi)Topic中的partition的消息Broker 緩存代理，Kafka集群中的一臺(tái)或多臺(tái)服務(wù)器統(tǒng)稱broker。Topic是Kafka處理資源的消息源(feedsofmessages)的不同分類。Partition是Topic物理上的分組，一個(gè)topic可以分為多個(gè)Partition，每個(gè)Partition是一個(gè)有序的隊(duì)列。Partition中每條消息都會(huì)被分配一個(gè)有序的Id(offset)。Message消息，是Kafka是通信的基本單位，每個(gè)producer可以向一個(gè)topic（主題）發(fā)布一些消息。hive對于大數(shù)據(jù)來說hive就是將Hadoop底層存儲(chǔ)的文件映射成一張表，使用hsql來進(jìn)行對文件處理，而hiveSQL底層是將SQL語句轉(zhuǎn)化為MR程序進(jìn)行計(jì)算的，計(jì)算資源調(diào)配是通過yarn來分配的，依賴于大數(shù)據(jù)Hadoop平臺(tái)的數(shù)倉工具，可以輕松幫助公司對海良數(shù)據(jù)進(jìn)行分析處理[]。Hive就是在Hadoop架構(gòu)之上，分析查詢數(shù)據(jù)方便，結(jié)構(gòu)圖如下:圖3.3hive架構(gòu)圖JDBC為常見的連接驅(qū)動(dòng)工具。解釋器、編譯器、優(yōu)化器完成HQL查詢語句從詞法分析、語法分析、編譯、優(yōu)化以及查詢計(jì)劃（plan）的生成。生成的查詢計(jì)劃存儲(chǔ)在HDFS中，并在隨后有MapReduce調(diào)用執(zhí)行。Hive的數(shù)據(jù)是存儲(chǔ)在HDFS中的，大部分查詢底層都是轉(zhuǎn)換成mapreduce來完成的。Hive將元數(shù)據(jù)都存儲(chǔ)在數(shù)據(jù)庫中如MySQL中，hive中的元數(shù)據(jù)有表的名稱，表的列、表的分區(qū)、表的屬性、表數(shù)據(jù)所在的目錄。Hive的metastore組件，包括兩個(gè)部分metastore服務(wù)和后臺(tái)數(shù)據(jù)的存儲(chǔ)，后臺(tái)數(shù)據(jù)庫就是存儲(chǔ)的介質(zhì)就是關(guān)系型數(shù)據(jù)庫，metastore服務(wù)是建立在后臺(tái)數(shù)據(jù)庫之上的，并且是可以和hive進(jìn)行交互的服務(wù)組件，默認(rèn)情況下是安裝在一起的，運(yùn)行在同一個(gè)進(jìn)程里的，也可以將其分離開，讓hive遠(yuǎn)程調(diào)用metastore服務(wù)，中間可以添加防火墻加強(qiáng)數(shù)據(jù)的安全性能，使用遠(yuǎn)程調(diào)用可以讓服務(wù)進(jìn)行不同進(jìn)程之間運(yùn)行，提高h(yuǎn)ive的穩(wěn)定性，提升hive的服務(wù)效率，以及對數(shù)據(jù)的安全性。服務(wù)器選擇服務(wù)器的選擇是設(shè)計(jì)的一個(gè)重要部分，服務(wù)器的質(zhì)量決定了應(yīng)用程序的效率?？梢允褂冒⒗镌苹蛘咂渌贫藖硎褂?，一方面是使用簡單而且其配置足夠，另一方面搭建其環(huán)境方面簡潔，選擇我們想要的配置就可以了。系統(tǒng)實(shí)施分析首先對系統(tǒng)進(jìn)行分析，分析用戶行為日志系統(tǒng)整體要求極其最重要的基礎(chǔ)，隨著用戶的的不斷發(fā)展，當(dāng)前系統(tǒng)應(yīng)該是一個(gè)可以擴(kuò)展的、可兼容的系統(tǒng)，對于數(shù)據(jù)量的不斷提高，應(yīng)對其的是一個(gè)可以高效采集、高效傳輸、高效存儲(chǔ)、高效分析的用戶行為日志系統(tǒng)，本章分析系統(tǒng)需求、設(shè)計(jì)目標(biāo)、以及功能需求，為接下來的系統(tǒng)做足準(zhǔn)備。實(shí)施分析分析實(shí)施是從平臺(tái)到實(shí)際軟件部署，以及軟件的版本，開發(fā)當(dāng)前系統(tǒng)的要求以及后期需求是否具備條件，以應(yīng)對不同數(shù)據(jù)的要求，對后期對集群部署。技術(shù)實(shí)施近年來，在大數(shù)據(jù)行業(yè)的不斷發(fā)展，技術(shù)的更新，讓我們可以使用較為一般的服務(wù)器也可以搭建大數(shù)據(jù)平臺(tái)，而且在眾多公司里已經(jīng)有搭建完成的系統(tǒng)，當(dāng)前系統(tǒng)的可行性時(shí)具備的，硬件、軟件、以及人員的可用性，當(dāng)前用戶行為日志系統(tǒng)都適合現(xiàn)在的使用。系統(tǒng)實(shí)施1.必須解決的系統(tǒng)問題：例如，公司管理問題和信息處理的解決方案。對公司提出的新的管理需求該如何滿足等。2.認(rèn)證體系的可行性研究應(yīng)包括目標(biāo)和計(jì)劃的可行性、技術(shù)可行性、經(jīng)濟(jì)可行性和技術(shù)可行性。開發(fā)方法是靜態(tài)系統(tǒng)分析和規(guī)劃的方法之一。系統(tǒng)需求的詳細(xì)分析。獲取與登錄系統(tǒng)、信息分類、信息檢索系統(tǒng)等相關(guān)的功能。這些功能是相互關(guān)聯(lián)的。這是必要的。通過對該公司的初步概述和外部分析，提出并討論了可能的解決方案。3.我們必須考慮制定其他三種制度的法律和原則。換句話說，我們必須考慮發(fā)展行政參與制度。優(yōu)化、創(chuàng)新、實(shí)用、高效、標(biāo)準(zhǔn)化的原則。選擇系統(tǒng)開發(fā)方法和創(chuàng)建開發(fā)計(jì)劃：選擇系統(tǒng)中定義的開發(fā)。操作系統(tǒng)實(shí)施根據(jù)所選操作系統(tǒng)其對大數(shù)據(jù)平臺(tái)實(shí)際的影響不大，而對應(yīng)命令行比較使用的，比如Linux。而大多數(shù)情況下大數(shù)據(jù)平臺(tái)的服務(wù)器都是Linux系統(tǒng)為主。根據(jù)所選機(jī)器型號搭配相應(yīng)的系統(tǒng)，也可以選擇在云端搭建大數(shù)據(jù)平臺(tái)，快捷方便，遷移平臺(tái)也很方便。需求分析功能需求分析隨著業(yè)務(wù)的不斷發(fā)展，日志規(guī)模也會(huì)越來越大，而將數(shù)據(jù)也會(huì)逐漸增多，所以當(dāng)前系統(tǒng)的整體要求包括一下幾點(diǎn)：1.前端埋點(diǎn)采集要求實(shí)時(shí)采集，實(shí)現(xiàn)對數(shù)據(jù)的實(shí)時(shí)傳輸，為系統(tǒng)基礎(chǔ)構(gòu)建數(shù)據(jù)結(jié)構(gòu)，并對不同機(jī)器的日志文件進(jìn)行采集。2.搭建消息中間件，構(gòu)建全方位的數(shù)據(jù)傳輸通道，可以接收多數(shù)據(jù)源傳遞的數(shù)據(jù)，并對所傳遞的數(shù)據(jù)進(jìn)行規(guī)則劃分進(jìn)行存儲(chǔ)，保證數(shù)據(jù)消費(fèi)時(shí)不會(huì)出現(xiàn)錯(cuò)誤，保證數(shù)據(jù)的完整性以及高效率的傳輸。3.基于Hive技術(shù)對數(shù)倉進(jìn)行分層，規(guī)范數(shù)據(jù)處理，減少對數(shù)據(jù)的重復(fù)處理，提高對數(shù)據(jù)的復(fù)用性。4.根據(jù)分析數(shù)據(jù)進(jìn)行可視化展示以及報(bào)表展示，分析于用戶主題相關(guān)信息，滿足對離線數(shù)據(jù)的分析處理。5.實(shí)現(xiàn)實(shí)時(shí)處理數(shù)據(jù)并對數(shù)據(jù)進(jìn)行可視化展示。本系統(tǒng)主要是通過在頁面上采集數(shù)據(jù)通過flume對數(shù)據(jù)實(shí)時(shí)收集傳輸，采集到的數(shù)據(jù)發(fā)送到Kafka中，Kafka將數(shù)據(jù)傳輸?shù)紿DFS上或者使用spark對數(shù)據(jù)直接進(jìn)行消費(fèi)，進(jìn)行實(shí)時(shí)數(shù)據(jù)處理，數(shù)據(jù)存儲(chǔ)到HDFS上后通過映射成表到hive，使用hive技術(shù)進(jìn)行數(shù)倉的分成搭建，根據(jù)需求對業(yè)務(wù)數(shù)據(jù)進(jìn)行報(bào)表分析，實(shí)現(xiàn)對數(shù)據(jù)的展示存儲(chǔ)等。軟硬件環(huán)境1.硬件環(huán)境CPU:coreI7:硬盤空間:128G。內(nèi)存:8G，安裝Linux系統(tǒng)，安裝nginx服務(wù)器、安裝HAdoop、安裝hive、安裝kafka、安裝flume、安裝spark、安裝可視化工具。2.軟件環(huán)境大數(shù)據(jù)平臺(tái)：CDH6.3.2開發(fā)工具：IEDA客戶端：Linux系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)在通過對系統(tǒng)需求分析階之后，本章將提出和完成對系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，大數(shù)據(jù)技術(shù)對應(yīng)用戶行為日志系統(tǒng)的各個(gè)具體步驟進(jìn)行詳細(xì)設(shè)計(jì)，并根據(jù)系統(tǒng)設(shè)計(jì)，完成三大模塊，日志采集模塊，數(shù)據(jù)傳輸模塊以及數(shù)據(jù)入倉及可視化處理模塊的設(shè)計(jì)與實(shí)現(xiàn)，對研究過程中的步驟進(jìn)行說明。架構(gòu)設(shè)計(jì)系統(tǒng)架構(gòu)設(shè)計(jì)根據(jù)對需求分析之后，當(dāng)前系統(tǒng)在于高效采集、高效傳輸、高效處理，而應(yīng)對要求當(dāng)前系統(tǒng)架構(gòu)如圖5-1所示：圖5.1架構(gòu)圖功能模塊設(shè)計(jì)功能設(shè)計(jì)根據(jù)功能分析和設(shè)計(jì)要求，將當(dāng)前系統(tǒng)分為詳細(xì)的模塊配置，其四個(gè)核心時(shí)數(shù)據(jù)收集模塊，數(shù)據(jù)傳輸模塊以及數(shù)據(jù)處理模塊和數(shù)據(jù)可視化模塊，并對這些模塊進(jìn)行了詳細(xì)說明。（1）數(shù)據(jù)收集模塊：是通過使用flume在前端頁面部署埋點(diǎn)采集，創(chuàng)建攔截器，根據(jù)需求對數(shù)據(jù)進(jìn)行過濾，可跨多機(jī)器采集實(shí)現(xiàn)分布式采集程序。（2）數(shù)據(jù)傳輸模塊，通過Kafka將收集到的數(shù)據(jù)進(jìn)行收集、存儲(chǔ)、傳輸，依據(jù)不同主題將數(shù)據(jù)放到主題中共消費(fèi)者消費(fèi)。（3）數(shù)據(jù)處理模塊，通過對Hive進(jìn)行分層將數(shù)據(jù)進(jìn)行階梯式處理，根據(jù)業(yè)務(wù)進(jìn)行數(shù)據(jù)的處理工作。（4）數(shù)據(jù)可視化模塊，根據(jù)已經(jīng)計(jì)算的數(shù)據(jù)進(jìn)行報(bào)表開發(fā)，將數(shù)據(jù)進(jìn)行展示。模塊功能模塊功能各個(gè)模塊之間相互連接相互關(guān)聯(lián)，從用戶頁面點(diǎn)擊到用戶行為日志分析，以及最終的數(shù)據(jù)可視化展示，都可以在簡單處理后進(jìn)行快速相應(yīng)。圖5-2.2統(tǒng)功能模塊圖數(shù)據(jù)倉庫數(shù)據(jù)倉庫概念結(jié)構(gòu)設(shè)計(jì)本課題通過對數(shù)據(jù)倉庫[]的分層建模來完成用戶的相應(yīng)的可視化展示，主要以多維度建模多維度分析來實(shí)現(xiàn)。數(shù)據(jù)倉庫的建模，一般采用雪花模型或者星形模型來進(jìn)行建模，雪花模型是一張維表或多張維表進(jìn)行關(guān)聯(lián)而并沒有與事實(shí)表連接，通過其他維表連接到事實(shí)表的就是雪花模型，使用程度不高，而星形模型是基于多張維表共同連接一張事實(shí)表叫做星形模型，在大數(shù)據(jù)領(lǐng)域更傾向于星形模型，因?yàn)樾切文Ｐ途S度少，效率比較高。事實(shí)表與維表發(fā)生在現(xiàn)實(shí)世界中的操作型事件，其所產(chǎn)生的可度量數(shù)值，存儲(chǔ)在事實(shí)表中。從最低的粒度級別來看，事實(shí)表行對應(yīng)一個(gè)度量事件，反之亦然。事實(shí)表表示對分析主題的度量。比如一次購買行為我們就可以理解為是一個(gè)事實(shí)。事實(shí)表的特征：表里沒有存放實(shí)際的內(nèi)容，他是一堆主鍵的集合，這些ID分別能對應(yīng)到維度表中的一條記錄。事實(shí)表包含了與各維度表相關(guān)聯(lián)的外鍵，可與維度表關(guān)聯(lián)。事實(shí)表的度量通常是數(shù)值類型，且記錄數(shù)會(huì)不斷增加，表數(shù)據(jù)規(guī)模迅速增長。維表每個(gè)維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關(guān)聯(lián)的任何事實(shí)表的外鍵，當(dāng)然維度表行的描述環(huán)境應(yīng)與事實(shí)表行完全對應(yīng)。維度表通常比較寬，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性。維度表示你要對數(shù)據(jù)進(jìn)行分析時(shí)所用的一個(gè)量，比如你要分析產(chǎn)品銷售情況，可以選擇按類別來進(jìn)行分析，或按區(qū)域來分析。這樣的分析就構(gòu)成一個(gè)維度。上圖中的用戶表、商家表、時(shí)間表這些都屬于維度表，這些表都有一個(gè)唯一的主鍵，然后在表中存放了詳細(xì)的數(shù)據(jù)信息?？偟恼f來，在數(shù)據(jù)倉庫中不需要嚴(yán)格遵守規(guī)范化設(shè)計(jì)原則。因?yàn)閿?shù)據(jù)倉庫的主導(dǎo)功能就是面向分析，以查詢?yōu)橹鳎簧婕皵?shù)據(jù)更新操作。事實(shí)表的設(shè)計(jì)是以能夠正確記錄歷史信息為準(zhǔn)則，維度表的設(shè)計(jì)是以能夠以合適的角度來聚合主題內(nèi)容為準(zhǔn)則?；贔lume采集模塊設(shè)計(jì)與實(shí)現(xiàn)針對前端埋點(diǎn)日志[]生成場景，通過flume1.7版本以后可以直接使用TaildirSource，進(jìn)行數(shù)據(jù)收集，使用這個(gè)Source可以監(jiān)控一個(gè)目錄，并且使用正則表達(dá)式匹配該目錄中的文件名進(jìn)行實(shí)時(shí)收集。詳細(xì)配置如下：a1.sources=r1a1.sources=r1a1.sources.r1.type=TAILDIRa1.sources.r1.channels=c1a1.sources.r1.positionFile=/var/log/flume/taildir_position.jsona1.sources.r1.filegroups=f1f2a1.sources.r1.filegroups.f1=/var/log/test1/example.loga1.sources.r1.filegroups.f2=/var/log/test2/.*log.*filegroups:指定filegroups，可以有多個(gè)，以空格分隔；（TailSource可以同時(shí)監(jiān)控tail多個(gè)目錄中的文件）positionFile:配置檢查點(diǎn)文件的路徑，檢查點(diǎn)文件會(huì)以json格式保存已經(jīng)tail文件的位置，解決了斷點(diǎn)不能續(xù)傳的缺陷。filegroups.<filegroupName>：配置每個(gè)filegroup的文件絕對路徑，文件名可以用正則表達(dá)式匹配通過以上配置，就可以監(jiān)控文件內(nèi)容的增加和文件的增加。產(chǎn)生和所配置的文件名正則表達(dá)式不匹配的文件，則不會(huì)被tail。配置HDFSsink屬性，基于文件閑置時(shí)間策略，當(dāng)配置該屬性后，在一定的時(shí)間里這個(gè)文件都沒有內(nèi)容寫入，當(dāng)關(guān)閉該文件進(jìn)行滾動(dòng)，到下一個(gè)文件寫入。Flume采集系統(tǒng)的搭建相對簡單[]：1、在服務(wù)器上部署agent節(jié)點(diǎn)，根據(jù)設(shè)計(jì)修改配置文件。2、啟動(dòng)agent節(jié)點(diǎn)，將采集到的數(shù)據(jù)匯聚到指定的Kafkatopic中。3、啟動(dòng)agent節(jié)點(diǎn)，將采集到的數(shù)據(jù)匯聚到指定的HDFS目錄中。數(shù)據(jù)傳輸模塊設(shè)計(jì)與實(shí)現(xiàn)Kafka作為一個(gè)分布式的消息中間件[]，其特點(diǎn)是高吞吐、易擴(kuò)展、持久化、兼容性強(qiáng)，主要是由Producer、Broker、Consumer三部分組成，生產(chǎn)者將接收到的數(shù)據(jù)推送至相應(yīng)的Broker中，而消費(fèi)者從對應(yīng)的Broker中抽取訂閱的數(shù)據(jù)。為防止Kafka丟失數(shù)據(jù)可以調(diào)整ACK機(jī)制，ACK有三個(gè)參數(shù)可調(diào)整：Ack=-1：這種情況是不會(huì)丟失數(shù)據(jù)的，因?yàn)锽roker包含Topic，Topic?包含Partition，?Partition?邊還有副本，這?就會(huì)有Leader和Follower的概念，此時(shí)?產(chǎn)者發(fā)送消息后Leader會(huì)等待所有Follower的響應(yīng)后才會(huì)向?產(chǎn)者響應(yīng)，此時(shí)是不會(huì)丟失數(shù)據(jù)的，但是會(huì)有數(shù)據(jù)重復(fù)的問題這個(gè)問題可以在下游消費(fèi)數(shù)據(jù)的時(shí)候進(jìn)?處理?般都是采?去重的操作。Ack=0：此時(shí)相當(dāng)于是消息的異步發(fā)送，?產(chǎn)者發(fā)送消息以后不會(huì)等待Leader這邊的任何響應(yīng)，如果在發(fā)送消息后系統(tǒng)發(fā)?停電或者宕機(jī)此時(shí)是會(huì)丟失數(shù)據(jù)的但是這種機(jī)制的特點(diǎn)是效率特別?。Ack=1：此時(shí)?產(chǎn)者會(huì)等待Leader響應(yīng)，但是Leader響應(yīng)的時(shí)間是在接受到數(shù)據(jù)后?不是所有的Follower成功后繼續(xù)你那個(gè)響應(yīng)，如果在Leader剛響應(yīng)并且Follower沒有來得及進(jìn)?同步，此時(shí)服務(wù)器宕機(jī)也會(huì)丟失數(shù)據(jù)的。也可以將Kafka的副本機(jī)制開啟，調(diào)整為3個(gè)，這樣也能保證數(shù)據(jù)不丟失。安裝Kafka，從官網(wǎng)下載安裝包進(jìn)行安裝，修改Kafka的配置文件，安裝的是Kafka的集群所以每臺(tái)服務(wù)器都要進(jìn)行修改，配置文件修改如下：broker.id=0broker.id=0work.threads=3num.io.threads=8socket.send.buffer.bytes=102400socket.receive.buffer.bytes=102400socket.request.max.bytes=104857600log.dirs=/export/servers/kafka_2.11-1.0.0/logsnum.partitions=2num.recovery.threads.per.data.dir=1offsets.topic.replication.factor=1transaction.state.log.replication.factor=1transaction.state.log.min.isr=1erval.messages=10000erval.ms=1000log.retention.hours=168log.segment.bytes=1073741824erval.ms=300000zookeeper.connect=node01:2181，node02:2181，node03:2181zookeeper.connection.timeout.ms=6000group.initial.rebalance.delay.ms=0delete.topic.enable==node01配置完成后啟動(dòng)Kafka集群，創(chuàng)建相對應(yīng)的topic同時(shí)創(chuàng)建相應(yīng)的副本以及分區(qū)相應(yīng)命令如下：bin/kafka-topics.sh--create--zookeepernode01:2181--replication-factor2--partitions3--topictest數(shù)據(jù)預(yù)處理模塊設(shè)計(jì)與實(shí)現(xiàn)數(shù)據(jù)入庫，對入庫后的數(shù)據(jù)進(jìn)行ETL處理，而ETL就是抽取各個(gè)地方的數(shù)據(jù)，對抽取到的數(shù)據(jù)進(jìn)行轉(zhuǎn)換，并最終加載到hive中的過程稱為ETL，本項(xiàng)目是加載與Hadoop之上的，對應(yīng)hive的數(shù)倉技術(shù)，將數(shù)據(jù)加載到數(shù)倉中，應(yīng)對后其數(shù)據(jù)的開發(fā)使用。Hive的安裝，從官網(wǎng)上下載Hive安裝包，安裝解壓并配置環(huán)境變量，安裝MySQL數(shù)據(jù)庫用來存儲(chǔ)hive元數(shù)據(jù)，安裝完成，驗(yàn)證Hive安裝結(jié)果。在完成Hive的安裝后對數(shù)據(jù)進(jìn)行建模，首先對數(shù)據(jù)進(jìn)行業(yè)務(wù)建模，通過對用戶訪問時(shí)間，新增用戶，用戶留存時(shí)間，用戶點(diǎn)擊頁面等多維度進(jìn)行業(yè)務(wù)分析建模，通過分析了解用戶需求。數(shù)倉分層該課題對數(shù)倉分為四層：第一層為ODS層，原始數(shù)據(jù)層主要存儲(chǔ)原始數(shù)據(jù)，這?層我們針對數(shù)據(jù)還做了分區(qū)，分區(qū)的維度是按照?期來進(jìn)?的，這樣可以保證以后在查詢的過程中不需要進(jìn)?全表的掃描就可以快速檢索到數(shù)據(jù)，直接提升了數(shù)據(jù)查詢的性能。第二層為DWD層，基礎(chǔ)數(shù)據(jù)層這?層我們就需要對上?層的數(shù)據(jù)進(jìn)?分解了，因?yàn)檫@?層的數(shù)據(jù)是需要對DWS層的?些指標(biāo)計(jì)算來做服務(wù)的，所以我們對數(shù)據(jù)進(jìn)?了?些粗粒度的分解。第三層為DWS層，數(shù)據(jù)匯總層這?層我們主要做了數(shù)據(jù)的預(yù)聚合，其實(shí)這?層的表經(jīng)過上層的處理已經(jīng)變得?常多，所以數(shù)據(jù)匯總非常重要。第四層為APP層，應(yīng)用層這一層是這?層主要是?來存放我們計(jì)算的各種指標(biāo)數(shù)據(jù)，特別是離線指標(biāo)的數(shù)據(jù)我們都是通過腳本來進(jìn)?調(diào)度的，計(jì)算完成后會(huì)導(dǎo)?app層做保存，然后導(dǎo)?到業(yè)務(wù)數(shù)據(jù)展示。數(shù)據(jù)可視化模塊Echarts是百度技術(shù)部開發(fā)的，提供直觀、生動(dòng)、可定制化的可視化圖表，提供了非常多的圖表，在繪圖前我們需要為ECharts準(zhǔn)備一個(gè)具備高寬的DOM容器：<body><!--為ECharts準(zhǔn)備一個(gè)具備大?。▽捀撸┑腄OM--><divid="main"style="width:600px;height:400px;"></div></body>然后就可以通過echarts.init方法初始化一個(gè)echarts實(shí)例并通過setOption方法生成一個(gè)簡單的柱狀圖，下面是完整代碼。<!DOCTYPEhtml><html><head><metacharset="utf-8"><title>ECharts</title><!--引入echarts.js--><scriptsrc="echarts.min.js"></script></head><body><!--為ECharts準(zhǔn)備一個(gè)具備大小（寬高）的Dom--><divid="main"style="width:600px;height:400px;"></div><scripttype="text/javascript">//基于準(zhǔn)備好的dom，初始化echarts實(shí)例varmyChart=echarts.init(document.getElementById('main'));//指定圖表的配置項(xiàng)和數(shù)據(jù)varoption={title:{text:'ECharts入門示例'},tooltip:{},mlegend:{data:['銷量']},xAxis:{data:["襯衫","羊毛衫","雪紡衫","褲子","高跟鞋","襪子"]},yAxis:{},series:[{name:'銷量',type:'bar',data:[5,20,36,10,10,20]}]};//使用剛指定的配置項(xiàng)和數(shù)據(jù)顯示圖表。myChart.setOption(option);</script></body></html>就可以看到生成的柱狀圖。系統(tǒng)測試系統(tǒng)測試概述本章對系統(tǒng)進(jìn)行最后測試，對日志采集模塊、數(shù)據(jù)傳輸模塊、數(shù)據(jù)預(yù)處理模塊、可視化模塊進(jìn)行功能測試以及對測試結(jié)果進(jìn)行分析，首先對應(yīng)用程序進(jìn)行測試，確保程序的運(yùn)行沒有問題，這也是測試的第一步，是確保測試流程成功的保證。測試環(huán)境測試系統(tǒng)的環(huán)境，根據(jù)服務(wù)器的規(guī)劃以及系統(tǒng)架構(gòu)對服務(wù)器進(jìn)行測試，每個(gè)模塊所對應(yīng)服務(wù)所在的集群規(guī)模，以及服務(wù)器狀態(tài)均為正常。功能測試被測試系統(tǒng)的功能，針對每個(gè)模塊進(jìn)行功能測試，F(xiàn)lume采集功能測試、Kafka數(shù)據(jù)傳輸功能測試、Hive數(shù)倉搭建以數(shù)據(jù)處理功能測試等相應(yīng)的功能進(jìn)行測試。測試結(jié)果測試功能測試步驟測試結(jié)果成功與否大數(shù)據(jù)平臺(tái)Hadoop查看Hadoop角色是否啟動(dòng)成功查看HDFS角色是否啟動(dòng)成功查看是否可以上傳文件到集群空間Hadoop角色啟動(dòng)成功HDFS角色啟動(dòng)成功文件上傳成功成功Flume集群查看Flume啟動(dòng)角色是否啟動(dòng)查看Flume采集是否成功角色啟動(dòng)成功采集日志成功成功Kafka集群查看Kafka啟動(dòng)角色是否成功查看Kafka能否接收數(shù)據(jù)查看數(shù)據(jù)存入HDFS是否成功角色啟動(dòng)成功接收