摘要針對用戶行為日志，提出了一種基于大數據的用戶行為日志系統的設計方案。該方案基于公司現有框架，對用戶行為日志采集系統進行了重組，提出了高可靠性、高可用性的設計要求。Flume框架用于實時收集用戶行為日志數據，ETL攔截器和Type攔截器用于過濾日志數據。通過優化參數配置，實現了多線程日志采集，提高了日志采集系統的可靠性和實用性。Kafka框架用于實時傳輸日志。通過優化生產者端、中間商端和消費者端，實現了消息傳輸的準確主語義，使系統的消息傳輸和存儲更加穩定高效。Hive用于逐層構建數據倉庫。通過分析用戶主題的相關指標，為系統決策提供支持。實現數據可視化模塊，為系統開發人員提供方便、準確的可視化服務。關鍵詞：大數據；用戶行為；Kafka框架；Hive；系統設計

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

source：可以支持監聽端口和IP。ThriftSource：跟Avro

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

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