永磁同步電機雙環(huán)調速系統(tǒng)的仿真研究基于Hadoop技術的大數(shù)據(jù)分析系統(tǒng)的設計與實現(xiàn)1概述大數(shù)據(jù)分析系統(tǒng)是一個專門用于分析大規(guī)模數(shù)據(jù)的系統(tǒng)，可以根據(jù)數(shù)據(jù)部門或決策者提供的指標將企業(yè)每日產(chǎn)生的數(shù)據(jù)進行匯總分析。之后反饋分析結果，讓決策者可以清晰的看出每日企業(yè)的情況，也可以根據(jù)分析結果制定計劃。若分析發(fā)現(xiàn)企業(yè)可能處于亞健康狀態(tài)，決策者就可以根據(jù)情況制定策略以解決存在的問題，之后還可以繼續(xù)觀察，判斷策略是否起到了應有的作用。整個大數(shù)據(jù)分析系統(tǒng)主要分為五個模塊。數(shù)據(jù)采集，數(shù)據(jù)清洗，數(shù)據(jù)倉庫，數(shù)據(jù)分析，數(shù)據(jù)可視化。數(shù)據(jù)采集模塊用于將不同格式的數(shù)據(jù)上傳到系統(tǒng)集群。因為無法獲取到企業(yè)的真實數(shù)據(jù)，只好生成模擬數(shù)據(jù)，模擬數(shù)據(jù)是通過程序和數(shù)據(jù)庫函數(shù)模擬電子商務公司每日用戶數(shù)據(jù)格式生成，程序生成的數(shù)據(jù)包括用戶登錄產(chǎn)生的記錄和用戶點擊商品產(chǎn)生的記錄。數(shù)據(jù)庫腳本生成用戶行為數(shù)據(jù)，如下單、點贊、評論等。使用腳本模擬生成數(shù)據(jù)后，大數(shù)據(jù)分析系統(tǒng)會自動將數(shù)據(jù)上傳，并且根據(jù)記錄的格式進行分類。數(shù)據(jù)清洗模塊用于將采集來的數(shù)據(jù)格式化。將不同格式的數(shù)據(jù)規(guī)范成同一種可以高效分析的格式，并且將數(shù)據(jù)中的敏感數(shù)據(jù)項剔除。這些敏感信息包括用戶身份證、用戶銀行卡號、用戶手機號等。數(shù)據(jù)倉庫模塊是將數(shù)據(jù)分層存儲。數(shù)據(jù)分層可以高效的管理我們的數(shù)據(jù)，也可以將數(shù)據(jù)復用，減少重復工作。第一層是原始數(shù)據(jù)層，存放格式統(tǒng)一的數(shù)據(jù)。第二層是明細數(shù)據(jù)層，存放數(shù)據(jù)清洗后的數(shù)據(jù)。第三層是服務數(shù)據(jù)層，存放輕度匯總后的數(shù)據(jù)。第四層是數(shù)據(jù)應用層，存放根據(jù)指標分析出的結果。數(shù)據(jù)分析模塊是數(shù)據(jù)倉庫中的數(shù)據(jù)分析與挖掘，提取數(shù)據(jù)的價值。根據(jù)指標要制定的不同的數(shù)據(jù)分析方法，并不斷優(yōu)化分析策略。數(shù)據(jù)分析是每天都要進行的，所以大數(shù)據(jù)分析系統(tǒng)會使用腳本自動化工具，每天定時自動執(zhí)行數(shù)據(jù)分析腳本，減少人力物力。數(shù)據(jù)可視化是將分析結果美觀清晰的呈現(xiàn)，讓決策者可以一眼看出數(shù)據(jù)的趨勢。大數(shù)據(jù)分析系統(tǒng)使用各式各樣的圖表，包括柱狀圖、折線圖、扇形圖等。選取合適的圖表能夠更直觀的體現(xiàn)出數(shù)據(jù)分析結果。2課題研究背景與意義2.1課題研究背景隨著時代的發(fā)展，企業(yè)產(chǎn)生的數(shù)據(jù)量越來越大，數(shù)據(jù)格式越來越復雜，一般手段已經(jīng)難以高效穩(wěn)定進行大數(shù)據(jù)量的處理和分析。搭建一個大數(shù)據(jù)分析系統(tǒng)可以很好的解決現(xiàn)如今存在的問題，如數(shù)據(jù)激增、數(shù)據(jù)格式復雜與分析效率低等。所以搭建大數(shù)據(jù)分析系統(tǒng)會是未來大多數(shù)公司的一項關鍵基礎設施。2.2課題研究意義使用大數(shù)據(jù)分析系統(tǒng)相比傳統(tǒng)數(shù)據(jù)分析有以下優(yōu)勢：a)數(shù)據(jù)規(guī)模更大。互聯(lián)網(wǎng)用戶越來越多，每天產(chǎn)生的數(shù)據(jù)也越來越多。以前一家互聯(lián)網(wǎng)公司一個月可能產(chǎn)生100GB的數(shù)據(jù)，而現(xiàn)在一天產(chǎn)生的數(shù)據(jù)大小就能達到這個值。當對幾個月甚至幾年的數(shù)據(jù)進行分析時，數(shù)據(jù)量可能就會達到PT級別。傳統(tǒng)的數(shù)據(jù)分析是無法處理這么大規(guī)模的數(shù)據(jù)的，只能將數(shù)據(jù)分組統(tǒng)計。如果使用大數(shù)據(jù)分析系統(tǒng)，就可以輕松處理大規(guī)模的數(shù)據(jù)，而無需對數(shù)據(jù)進行其他操作，越多的操作，也就容易發(fā)生錯誤。b)數(shù)據(jù)分析速度更快。傳統(tǒng)的數(shù)據(jù)分析如果對1TB的數(shù)據(jù)進行分析，大概需要2到3個小時，而使用大數(shù)據(jù)分析系統(tǒng)，只要你根據(jù)數(shù)據(jù)量，合理的配置了大數(shù)據(jù)集群，那么處理相同的數(shù)據(jù)，大數(shù)據(jù)系統(tǒng)只需要5到10分鐘的時間。如果集群的性能足夠優(yōu)秀，那么這個時間可能更短。c)可處理的數(shù)據(jù)格式更多。大數(shù)據(jù)分析系統(tǒng)，使用Hive可以讀取很多種數(shù)據(jù)格式。他將會根據(jù)配置參數(shù)，決定該選擇哪種方式讀取數(shù)據(jù)，并轉換成自己指定的格式。而傳統(tǒng)的數(shù)據(jù)分析只能處理普通文件和格式化的數(shù)據(jù)，轉為成一種數(shù)據(jù)格式。公司如果業(yè)務復雜，那么傳統(tǒng)分析肯定是無法滿足數(shù)據(jù)分析的需求的。3大數(shù)據(jù)分析系統(tǒng)可行性研究3.1技術可行性研究大數(shù)據(jù)分析系統(tǒng)使用開源的Hadoop大數(shù)據(jù)計算框架，使用Flume與Kafka構建數(shù)據(jù)采集通道，使用Hive搭建分層數(shù)據(jù)倉庫，關系數(shù)據(jù)庫使用MySQL，數(shù)據(jù)展示使用SpringBoot、Mybatis與ECharts實現(xiàn)。Hadoop是一項成熟的大數(shù)據(jù)框架，已經(jīng)經(jīng)過10年的發(fā)展迭代，擁有完善的社區(qū)和豐富的說明手冊。Hadoop由HDFS、YARN與MapReduce共同組成，分別作為文件存儲系統(tǒng)、任務調度系統(tǒng)與計算系統(tǒng)。經(jīng)過時間的檢驗，HDFS與YARN可以很優(yōu)秀的處理大數(shù)據(jù)分析，而MapReduce由于其設計思想導致MR次數(shù)過多，導致效率較低，所以大數(shù)據(jù)分析系統(tǒng)使用TEZ計算引擎。TEZ會將YARN調度來的任務再次分析，找到多余的不必要的MR，大大減少了MR次數(shù)，縮短計算用時。Flume與Kafka用于搭建雙Flume采集通道。Flume可以將多個服務器的數(shù)據(jù)采集到Kafka，然后再由Flume消費Kafka中的數(shù)據(jù)，存儲于HDFS。使用兩層Flume，一是因為Flume可以采集多種格式的數(shù)據(jù)，二是為了將數(shù)據(jù)分類采集。Flume與Kafka也是十分成熟的技術，而且官方文檔詳細，易于使用。Hive是Hadoop的數(shù)據(jù)倉庫工具，能夠實現(xiàn)數(shù)據(jù)的提前、轉換、加載，是一種專門處理存儲于Hadoop中大規(guī)模數(shù)據(jù)的軟件。Hive學習成本低，使用類SQL語法，與Mysql語法基本相同，只是多了一些限制與方法。在數(shù)據(jù)分析方面更易于編寫出高效的HQL。數(shù)據(jù)可視化模塊使用當前企業(yè)流行使用的SpringBoot+Mybatis。SpringBoot相比Spring更加快速。它使用了大量的自動配置類，讓我可以快速的搭建一個web項目，而不需要填寫大量的配置。Mybatis是一個輕量級的ORM框架，用法簡單，只需要建立好對象與數(shù)據(jù)庫表之間的關系，再根據(jù)需求編寫SQL語句，就能快速的對數(shù)據(jù)進行增刪改查。3.2操作可行性研究大數(shù)據(jù)分析系統(tǒng)搭建在3臺虛擬機上，可視化程序部署與阿里云服務器。虛擬機已經(jīng)配置了路由，外網(wǎng)可發(fā)現(xiàn)虛擬機。分析人員可以使用ssh軟件連接虛擬機編寫HQL語句，配置自動化腳本，完成數(shù)據(jù)分析。決策者可以通過常用瀏覽器觀察到數(shù)據(jù)分析的結果。4大數(shù)據(jù)分析系統(tǒng)需求分析通過查閱相關大數(shù)據(jù)文檔與數(shù)據(jù)，了解到大數(shù)據(jù)分析系統(tǒng)需要如下功能，可分為五個方面。4.1數(shù)據(jù)采集模塊數(shù)據(jù)采集需要保證數(shù)據(jù)能夠快速不丟失的傳送到大數(shù)據(jù)服務器，并且根據(jù)數(shù)據(jù)類型存儲為不同文件將多個虛擬機下的日志采集到HDFS中；將MySQL中的業(yè)務數(shù)據(jù)采集到HDFS中；篩選數(shù)據(jù)，存儲在不同的路徑上。圖4-1日志采集需求圖4.2數(shù)據(jù)清洗數(shù)據(jù)清洗模塊需要將采集來的數(shù)據(jù)根據(jù)要求進行處理。將數(shù)據(jù)轉化為格式一致，易于分析的數(shù)據(jù)。去除無效數(shù)據(jù)段；數(shù)據(jù)脫敏；格式轉換。圖4-2數(shù)據(jù)清洗圖4.3數(shù)據(jù)倉庫數(shù)據(jù)倉庫做分層設計，分為ODS、DWD、DWS、ADS四層，分別存儲不同格式不同用途的數(shù)據(jù)。大數(shù)據(jù)分析系統(tǒng)通過Hive可以搭建分層的數(shù)據(jù)倉庫，Hive將數(shù)據(jù)模擬成表的形式，這樣就能輕易的使用類SQL語法進行數(shù)據(jù)處理。ODS原始數(shù)據(jù)層，存放原始數(shù)據(jù)，直接加載日志與業(yè)務數(shù)據(jù)，保持原始的數(shù)據(jù)格式；DWD結構與粒度和原始表完全相同，對ODS數(shù)據(jù)進行清洗（去除空值、臟數(shù)據(jù)）；DWS以DWD為基礎，將數(shù)據(jù)進行輕度匯總；ADS存放分析結果，為各種統(tǒng)計報表提供數(shù)據(jù)。圖4-3數(shù)據(jù)倉庫搭建圖4.4數(shù)據(jù)分析數(shù)據(jù)分析要針對數(shù)據(jù)倉庫中的數(shù)據(jù)，將原始的數(shù)據(jù)一層層的轉化，最終得出分析結果。日志數(shù)據(jù)分析：分析每日服務器產(chǎn)生的日志，統(tǒng)計用戶活躍度。業(yè)務數(shù)據(jù)分析：分析業(yè)務數(shù)據(jù)，統(tǒng)計商品信息和轉化率。綜合分析：結合兩者對用戶行為進行分析。圖4-4數(shù)據(jù)分析需求圖4.5數(shù)據(jù)可視化大數(shù)據(jù)分析系統(tǒng)需要搭建一個能展示數(shù)據(jù)分析結果的可視化平臺，決策者可以通過平臺上的各種數(shù)據(jù)表，了解公司的運轉狀況。還能知曉決策的實行是否起到預期的影響?？梢暬脚_需將數(shù)據(jù)倉庫ADS層中的分析結果導出到Mysql，再由系統(tǒng)從MySQL中讀取，將數(shù)據(jù)渲染到頁面上?？梢暬脚_需要展示如下信息：對分析用戶每日產(chǎn)生日志得出的結果，用柱狀圖、扇形圖與折現(xiàn)圖展示；對分析用戶業(yè)務數(shù)據(jù)得出的結果，用漏斗圖和折線圖展示圖4-5數(shù)據(jù)可視化需求圖5大數(shù)據(jù)分析系統(tǒng)概要設計大數(shù)據(jù)分析系統(tǒng)用于解決企業(yè)大規(guī)模數(shù)據(jù)的存儲與分析。本系統(tǒng)使用Hadoop大數(shù)據(jù)框架，Hadoop是原始數(shù)據(jù)倉庫的技術替代，可建立在廉價的服務器上，對硬件的需求不是很高。系統(tǒng)架構如圖5-1所示：Sqoop、Flume進行數(shù)據(jù)采集；Hadoop用于數(shù)據(jù)存儲與計算；Hive搭建數(shù)據(jù)倉庫；Echarts將數(shù)據(jù)可視化。圖5-1系統(tǒng)架構圖5.1Hadoop架構5.1.1Hadoop與數(shù)據(jù)倉庫ApacheHadoop是一個大數(shù)據(jù)框架，該框架將使用簡單的編程模型跨整個計算機集群對大規(guī)模數(shù)據(jù)集進行分布式處理。它能夠從單個服務器擴展到數(shù)千臺機器，每臺機器都提供本地計算和存儲。Hadoop本身不依靠硬件來提供高可用性，而是使用第二節(jié)點來保證高可用，因此計算機集群的某臺設備發(fā)生故障不會導致整個系統(tǒng)的崩潰。圖5-2Hadoop架構圖Hadoop架構如圖5-2所示，hadoop是套大數(shù)據(jù)框架包含大量的大數(shù)據(jù)解決方案，大數(shù)據(jù)分析系統(tǒng)將使用其中的ZooKeeper、HDFS、YARN、Flume、Sqoop、Hive、Tez。傳統(tǒng)的數(shù)據(jù)倉庫與Hadoop的差別如圖5-3所示。圖5-3Hadoop與數(shù)據(jù)倉庫差異圖由圖可以看出，Hadoop可以輕松的擴展集群，當數(shù)據(jù)激增，處理速度不足時，可以快速的擴展集群，以滿足需求。在數(shù)據(jù)量方面Hadoop支持10PB以上的數(shù)據(jù)，而數(shù)據(jù)倉庫只能支持不大于5PB的數(shù)據(jù)量，在如今是遠遠達不到要求的。在數(shù)據(jù)類型方面，Hadoop能夠支持多種格式的數(shù)據(jù)。5.1.2HDFS文件系統(tǒng)Hadoop分布式文件系統(tǒng)（HDFS）是一種旨在可以在廉價機器硬件上運行的分布式文件系統(tǒng)。它與現(xiàn)如今的分布式文件系統(tǒng)有許多共同之處。但是，與其他分布式文件系統(tǒng)的差別也很多。HDFS具有高度的容錯能力，旨在能夠在低成本硬件上部署。HDFS提供對應用程序數(shù)據(jù)的高吞吐量訪問，并且適用于具有大規(guī)模數(shù)據(jù)集的應用程序。HDFS放寬了一些POSIX要求，可以實現(xiàn)對文件系統(tǒng)數(shù)據(jù)的流式讀取。HDFS最初是作為ApacheNutchWeb搜索引擎項目的基礎結構而構建的。HDFS是ApacheHadoop核心項目的重要組成部分。圖5-4HDFS架構圖HDFS是的主從體系結構得。HDFS群集由單個NameNode和多個DataNode組成。NameNode用于存儲數(shù)據(jù)的元數(shù)據(jù)，指向文件存儲在哪個DataNode。許多數(shù)據(jù)節(jié)點，通常是集群中每個節(jié)點一個，用于管理與它們所運行的節(jié)點相連的存儲。在內部，文件根據(jù)大小和配置的參數(shù)被分成一個或多個塊，這些塊存儲在許多DataNode中。NameNode能確定塊到DataNode的映射，這樣我們就能知道一個文件被放在了哪些節(jié)點上。數(shù)據(jù)節(jié)點負責處理來自文件系統(tǒng)客戶端的讀寫請求。DataNode還根據(jù)NameNode的發(fā)送的指令執(zhí)行塊創(chuàng)建，刪除和復制等操作。5.1.3YARN數(shù)據(jù)計算框架ResourceManager和NodeManager共同組成數(shù)據(jù)計算框架。ResourceManager是在系統(tǒng)中所有應用程序之間仲裁資源的最終權限。NodeManager是每臺機器的框架代理，負責容器，監(jiān)視其資源使用情況（cpu，內存，磁盤，網(wǎng)絡），并將其報告給ResourceManager。ApplicationMaster是任務提交后發(fā)起的，任務被認領后，認領該任務的節(jié)點創(chuàng)建ApplicationMaster。Container是對每個節(jié)點上資源的抽象，ResourceManager以Container的形式將資源分配給NodeManager，當資源充足后，任務還是執(zhí)行。圖5-5YARN架構圖5.1.4TEZ計算引擎MapReduce是一種編程模型，用于大規(guī)模數(shù)據(jù)集（大于1TB）的并行運算。概念"Map（映射）"和"Reduce（歸約）"。Tez是Apache開源的支持DAG作業(yè)的計算框架，它直接源于MapReduce框架，核心思想是將Map和Reduce兩個操作進一步拆分。使用Tez是因為MapReduce在執(zhí)行某些任務時性能較低，Tez支持DAG作業(yè)可以減少任務中的MR次數(shù)，而MR次數(shù)越高，性能越低。由圖5-6可以看出未使用Tez，而使用MR，整個作業(yè)過程會有四個作業(yè)過程。而使用了Tez只會有一次MR。圖5-6Tez與MR對比圖5.2數(shù)據(jù)采集模塊5.2.1采集通道架構圖5-6數(shù)據(jù)采集通道架構圖數(shù)據(jù)采集通道是使用雙層Flume架構，由第一層Flume將日志從多個服務器采集到Kafka中，再由第二層Flume采集Kafka中的記錄到HDFS中。其中Kafka用于解決數(shù)據(jù)壓力過大的情況，可以根據(jù)數(shù)據(jù)的壓力，調整Flume與Kafka的配置，以防止阻塞。數(shù)據(jù)庫MySQL中的業(yè)務數(shù)據(jù)由sqoop導入，因為數(shù)據(jù)持久化存儲在數(shù)據(jù)庫中，所以可以直接采集到HDFS。5.2.2Flume圖5-7Flume架構圖ApacheFlume是一個分布式的、高可用的系統(tǒng)，它可以有效地收集、聚合和移動大量的日志數(shù)據(jù)，這些數(shù)據(jù)可以從許多不同的來源轉移到一個集中的數(shù)據(jù)存儲中。第一層Flume左邊對接文件，所以source選擇TailDirSource，可以支持文件斷點續(xù)傳功能，右邊對接Kafka，所以選擇KafkaChannel，可以省去sink環(huán)節(jié)，加快采集速度。第二層Flume左邊對接kafka，所以選擇KafkaSource，右邊對接HDFS，所以使用HDFSSink，就可以對接到Hadoop文件系統(tǒng)。5.2.3KafkaKafka是一個基于生產(chǎn)者消費者模式的分布式流媒體平臺，生產(chǎn)者將數(shù)據(jù)放入Kafka中的Topic，消費者再從Topic中獲取數(shù)據(jù)。圖5-8Kafka概念圖為保證producer發(fā)送的數(shù)據(jù)，能可靠的發(fā)送到指定的topic，topic的每個partition收到producer發(fā)送的數(shù)據(jù)后，都需要向producer發(fā)送ack（acknowledgement確認收到），如果producer收到ack，就會進行下一輪的發(fā)送，否則重新發(fā)送數(shù)據(jù)。圖5-8KafkaTopic圖5.2.3SqoopSqoop是一種目的在Hadoop數(shù)據(jù)庫或大型計算機集群之間傳輸數(shù)據(jù)的工具。您可以使用Sqoop將數(shù)據(jù)從MySQL或Oracle等關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）或大型機導入Hadoop分布式文件系統(tǒng)（HDFS），在HadoopMapReduce中轉換數(shù)據(jù)，然后將數(shù)據(jù)導出到RDBMS。Sqoop依靠數(shù)據(jù)庫描述要導入的數(shù)據(jù)的方式來自動執(zhí)行此過程。Sqoop使用MapReduce導入和導出數(shù)據(jù)，這提供了并行操作以及容錯能力。圖5-9Sqoop傳輸數(shù)據(jù)圖5.3數(shù)據(jù)清洗模塊數(shù)據(jù)清洗環(huán)節(jié)主要需要對采集來的原始數(shù)據(jù)進行處理。格式轉換；去除臟數(shù)據(jù)；數(shù)據(jù)脫敏。大數(shù)據(jù)分析系統(tǒng)使用自定義UDF與UDTF函數(shù)和HiveETL攔截器來完成這些需求。圖5-10Sqoop傳輸數(shù)據(jù)圖5.4數(shù)據(jù)倉庫模塊考慮要用分層的數(shù)據(jù)倉庫是因為分解復雜的分析流程；隔離原始數(shù)據(jù)；減少重復開發(fā)。圖5-11數(shù)據(jù)倉庫圖5.5數(shù)據(jù)分析模塊圖5-12Hive流程圖圖5-13數(shù)據(jù)倉庫圖Hive通過給用戶提供的一系列交互接口，接收到用戶的類SQL語句，調用系統(tǒng)的Driver，結合MetaStore，將這些指令翻譯成MapReduce程序，提交到Hadoop中執(zhí)行，最后，將執(zhí)行返回的結果輸出到用戶交互接口。5.6數(shù)據(jù)可視化模塊大數(shù)據(jù)分析系統(tǒng)使用如今非常流行的SpringBoot+Mybatis架構搭建可視化平臺。使用ECharts提供圖表支持。圖5-14數(shù)據(jù)倉庫圖5.6.1SpringBoot圖5-15SpringBoot架構圖圖5-14是借鑒《SpringBoot實戰(zhàn)開發(fā)》這一本書籍，這張架構圖清晰的說明了使用SpringBoot搭建的web系統(tǒng)是如何搭建的。使用SpringBoot的原因是因為它非常大的簡化了傳統(tǒng)Spring搭建后臺的步驟，不再需要配置大量的配置文件，也不需要創(chuàng)建web服務器，只需要完成初始化操作，便可以很快的將項目搭建起來。SpringBoot可以引入Web裝置，將使用SpringMVC處理請求。SpringMVC遵循MVC設計模式。識別url找到處理該請求的controller，然后再調用controller返回ModelAndView，最終通過ViewResolver將數(shù)據(jù)發(fā)送到前端渲染。5.6.2MybatisMybatis是一個輕量級的持久化框架，也是一款優(yōu)秀的持久層框架。它支持自定義SQL、存儲過程以及高級映射。MyBatis幾乎不用寫所有的JDBC代碼以及設置參數(shù)和獲取結果集的工作。MyBatis可以使用簡單的XML或注解來配置和映射原始類型、接口和JavaPOJO（PlainOldJavaObjects，普通老式Java對象）為數(shù)據(jù)庫中的記錄。數(shù)據(jù)庫數(shù)據(jù)庫MyBatis框架應用程序編程接口java數(shù)據(jù)庫連接應用程序mapper.xmlmybatis.xml圖5-16MyBatis框架工作原理示意圖6學生考勤系統(tǒng)的具體實現(xiàn)6.1搭建Hadoop集群大數(shù)據(jù)分析系統(tǒng)選取的技術，已經(jīng)在概要設計部分說明了選取的原因，這里就不做詳細闡述了。大數(shù)據(jù)分析系統(tǒng)針對企業(yè)產(chǎn)生的業(yè)務數(shù)據(jù)和每日服務器產(chǎn)生的日志進行分析。這些數(shù)據(jù)首先通過數(shù)據(jù)采集，將數(shù)據(jù)存儲于HDFS，在采集過程中進行數(shù)據(jù)清洗，保證在Hadoop文件系統(tǒng)的數(shù)據(jù)保持相同的數(shù)據(jù)結構。然后使用Hive搭建分層的數(shù)據(jù)倉庫，并根據(jù)指標進行數(shù)據(jù)分析，最后使用Sqoop將分析結果傳到MySQL，數(shù)據(jù)可視化平臺查詢數(shù)據(jù)展示。圖6-1系統(tǒng)架構圖表6-1展示了集群中三臺虛擬機各自需要啟動的服務。NameNode啟動在部署在固態(tài)硬盤的hadoop102中提高讀取元數(shù)據(jù)的速度。Yarn、Zookeeper、Kafka均勻分配在三臺服務器，其余軟件都部署在Hadoop102中充分利用服務器資源。表6-1集群節(jié)點分布服務名稱子服務服務器hadoop102服務器hadoop103服務器hadoop104HDFSNameNode√DataNode√√√SecondaryNameNode√YarnNodeManager√√√Resourcemanager√ZookeeperZookeeperServer√√√續(xù)表6-1服務名稱子服務服務器hadoop102服務器hadoop103服務器hadoop104Flume(采集日志)Flume√√KafkaKafka√√√Flume（消費Kafka）Flume√HiveHive√MySQLMySQL√SqoopSqoop√AzkabanAzkabanWebServer√AzkabanExecutorServer√服務數(shù)總計1166虛擬機環(huán)境準備克隆虛擬機；修改克隆虛擬機的靜態(tài)IP；修改主機名；關閉防火墻；創(chuàng)建用戶；配置用戶具有管理員權限。6.1.1部署完全分布式集群安裝JDK8，配置環(huán)境變量；將hadoop安裝包解壓，配置環(huán)境變量；配置ssh，實現(xiàn)免密訪問；重新設置core-site.xml、slaves、hadoop-env.sh、yarn.env.sh、hdfs-site.xml、yarn-site.xml配置文件。6.1.2啟動集群因為集群是第一次啟動，需要格式化NameNode。輸入jps指令，查看是否存在NameNode進程。繼續(xù)啟動HDFS，同樣要先看看是否存在進程，然后在啟動yarn，檢查進程。Web端查看SecondaryNameNode，瀏覽器中輸入：http://hadoop102:50070/dfshealth.html若發(fā)現(xiàn)集群狀態(tài)正常，則進行簡單的文件上傳、文件下載、文件刪除、文件移動等測試操作。6.1.3集群時間同步時間同步的方式：找一個機器，作為時間服務器，所有的機器與這臺集群時間進行定時的同步，比如，每隔十分鐘，同步一次時間。檢查ntp是否安裝；修改ntp配置文件；修改/etc/sysconfig/ntpd文件；重新啟動ntpd服務；設置ntpd服務開機啟動；在其他機器配置10分鐘與時間服務器同步一次；修改機器時間與網(wǎng)絡時間一致。集群參數(shù)優(yōu)化HDFS參數(shù)調優(yōu)node.handler.count=20*log2(ClusterSize)，比如集群規(guī)模為8臺時，此參數(shù)設置為60。Hadoop文檔原文如下。ThenumberofNamenodeRPCserverthreadsthatlistentorequestsfromclients.Ifnode.servicerpc-addressisnotconfiguredthenNamenodeRPCserverthreadslistentorequestsfromallnodes. 編輯日志存儲路徑node.edits.dir設置與鏡像文件存儲路徑.dir盡量分開，達到最低寫入延遲YARN參數(shù)調優(yōu)yarn-site.xml內存利用率不夠。這個一般是Yarn的2個配置造成的，單個任務可以申請的最大內存大小，和Hadoop單個節(jié)點可用內存大小。調節(jié)這兩個參數(shù)能提高系統(tǒng)內存的利用率。yarn.nodemanager.resource.memory-mb表示該節(jié)點上YARN可使用的物理內存總量，默認是8192（MB），注意，如果你的節(jié)點內存資源不夠8GB，則需要調減小這個值，而YARN不會智能的探測節(jié)點的物理內存總量。yarn.scheduler.maximum-allocation-mb單個任務可申請的最多物理內存量，默認是8192（MB）。Hadoop宕機（1）如果MR造成系統(tǒng)宕機。此時要控制Yarn同時運行的任務數(shù)，和每個任務申請的最大內存。調整參數(shù)：yarn.scheduler.maximum-allocation-mb（單個任務可申請的最多物理內存量，默認是8192MB）（2）如果寫入文件過量造成NameNode宕機。那么調高Kafka的存儲大小，控制從Kafka到HDFS的寫入速度。高峰期的時候用Kafka進行緩存，高峰期過去數(shù)據(jù)同步會自動跟上。6.2數(shù)據(jù)采集6.2.1安裝flume與kafka將flume安裝包發(fā)送到虛擬機hadoop102中，解壓配置環(huán)境變量；安裝ganglia檢測圖；圖6-2ganglia檢測圖Kafka將被安裝在三臺虛擬機上，步驟如下：解壓安裝包，配置環(huán)境變量；進入解壓路徑，創(chuàng)建logs文件夾；修改配置文件；啟動創(chuàng)建topic；安裝KafkaManager，用于監(jiān)控Kafka狀態(tài)。日志中會有用戶登錄信息和用戶行為信息，所以需要將數(shù)據(jù)按類型分別存儲。才用flume采集數(shù)據(jù)到kafka的過程中，按照數(shù)據(jù)的類型將數(shù)據(jù)分為兩類。如果數(shù)據(jù)中含有start字段，那么就會被放入topic_start，否則會被放入topic_event。消費flume直接可以對接兩種topic，分別存放在HDFS上，按照對應的topic名稱命名數(shù)據(jù)。圖6-3消費flume圖6.2.2日志數(shù)據(jù)格式日志分為啟動日志與事件日志啟動日志包括公共字段加上啟動事件字段。{ "action":"1", "ar":"MX", "ba":"HTC", "detail":"", "en":"start", "extend1":"", "g":"1L4M6J4F@", "hw":"640*1136", "l":"en", "la":"-37.0", "ln":"-100.3", "md":"HTC-19", "mid":"997", "nw":"4G", "open_ad_type":"2", "os":"8.1.7", "sv":"V2.9.1", "t":"1571584659764", "uid":"997"}事件日志包括服務器日志生成事件拼接上公共字段與業(yè)務字段的集合。1571610294526|{ "cm":{ "ln":"-103.3", "sv":"V2.9.9", "os":"8.2.8", "g":"JZAAPFRB@", "mid":"998", "nw":"3G", "l":"es", "vc":"12", "hw":"640*1136", "ar":"MX", "uid":"998", "t":"1571595416753", "la":"2.0", "md":"Huawei-8", "vn":"1.3.4", "ba":"Huawei", "sr":"G" }, "ap":"app", "et":[{ "ett":"1571521545937", "en":"newsdetail", "kv":{ "entry":"1", "goodsid":"211", "news_staytime":"12", "loading_time":"4", "action":"4", "showtype":"5", "category":"10", "type1":"" } }, { "ett":"1571545318283", "en":"loading", "kv":{ "extend2":"", "loading_time":"6", "action":"1", "extend1":"", "type":"1", "type1":"325", "loading_way":"1" } }]數(shù)據(jù)清洗大數(shù)據(jù)分析系統(tǒng)中自定義了兩個攔截器，分別是：ETL攔截器、日志類型區(qū)分攔截器。ETL攔截器主要用于，過濾時間戳不合法和Json數(shù)據(jù)不完整的日志，并對敏感數(shù)據(jù)加密。日志類型區(qū)分攔截器主要用于，將啟動日志和事件日志區(qū)分開來，方便發(fā)往Kafka的不同Topic。創(chuàng)建maven工程；引入flume相關jar包；編寫攔截器類，LogTypeInterceptor和LogETLInterceptor；打包放入flume的lib文件夾。圖6-4數(shù)據(jù)清洗圖數(shù)據(jù)倉庫首先需要安裝Hive：解壓安裝包，配置環(huán)境變量；配置hive-env.sh；修改hive內置數(shù)據(jù)庫為MySQL數(shù)據(jù)庫，將元數(shù)據(jù)存儲與MySQL中；使用Tez作為Hive的計算引擎。接下來使用Hive搭建數(shù)據(jù)倉庫，圖6-5畫出了所有表的層級。圖6-5數(shù)據(jù)倉庫總覽圖數(shù)據(jù)分析圖6-6數(shù)據(jù)分析關系圖一般指標可以使用內置函數(shù)如date_format、date_add、explode、collect_set等UDF和UDTF函數(shù)解決。但是有些分析指標不能或使用內置的函數(shù)難以解決，那么就需要自定義UDF與UDTF函數(shù)。圖6-7自定義UDF函數(shù)圖圖6-8自定義UDTF函數(shù)圖圖6-9描繪了系統(tǒng)業(yè)務各關系表之間的關系，大數(shù)據(jù)分析系統(tǒng)不僅需要分析每日的服務器日志，還需要對企業(yè)業(yè)務數(shù)據(jù)進行分析。圖6-9企業(yè)系統(tǒng)業(yè)務表關系圖對業(yè)務數(shù)據(jù)進行分析時，由于業(yè)務數(shù)據(jù)都存儲與關系型數(shù)據(jù)庫之中，所以表與表之間關系緊密。但是在數(shù)據(jù)分析時，如果一次分析需要涉及多張表的join操作會大大影響性能。所以需要先將多張表制成寬表。6.4.1ODS將HDFS中的日志數(shù)據(jù)以日分區(qū)導入Hive，只含有一個字段及每一行日志數(shù)據(jù)。得到原始數(shù)據(jù)啟動表與原始數(shù)據(jù)事件表。將HDFS中的MySQL業(yè)務數(shù)據(jù)按表的種類導入到Hive。圖6-10表的分類與同步策略6.3.2DWD解析啟動日志原始數(shù)據(jù)表，解析每一個字段。自定義UDF函數(shù)與UDTF函數(shù)解析原始事件表的公共字段與事件集合字段，將每一條數(shù)組，轉化為公共字段加上事件類型和事件詳情JSON的形式。接著根據(jù)不同的事件類型解析事件詳情JSON，形成多張事件表。將商品表與三級種類表降維成一張商品詳情表，其他業(yè)務數(shù)據(jù)表結構不變。圖6-11解析原始事件表6.4.3DWS用戶行為方面：根據(jù)指標對DWD層的啟動表與事件表進行匯總，為ADS層做好數(shù)據(jù)準備。主要統(tǒng)計出日活用戶明細、周活用戶明細與月活用戶明細。由于要分析用戶新增、留存、流失等相關指標，所以還需要統(tǒng)計出每日新增用戶明細與各時間段留存用戶明細。圖6-12DWS層用戶行為匯總業(yè)務數(shù)據(jù)方面：業(yè)務數(shù)據(jù)需要建立用戶行為寬表和用戶購買商品明細寬表，減少分析指標時的JOIN操作。這里創(chuàng)建寬表沒有使用JOIN方式而采用了零時表加UNIONALL，業(yè)務左右兩表數(shù)據(jù)量都相當大，使用JOIN會十分損耗性能。圖6-13DWS層用戶行為寬表6.4.3ADS開始分析用于輔助決策的指標，使用將根據(jù)各業(yè)務需求，編寫分析SQL，由Hive執(zhí)行后將數(shù)據(jù)保存在本層。用戶活躍與新增主題用戶活躍數(shù)：根據(jù)DWS匯總完的年月日活躍用戶數(shù)，計算出每天對應的年月日活躍用戶的數(shù)量，并判斷當天是否為周末或月末。圖6-14每日活躍用戶數(shù)量表新增用戶數(shù)：直接計算DWS層每日新增用戶明細表的今日新增用戶數(shù)量放入每日新增用戶數(shù)量表。用戶留存率：首先從留存用戶明細表中計算留存用戶數(shù)量，然后除以用戶創(chuàng)建當天的用戶新增數(shù)，得到留存比率。流失用戶數(shù)：最近7天未活躍的用戶。從每日活躍用戶明細表中得到最大活躍日期在7天前的用戶，計算出總數(shù)量。7天至少連續(xù)活躍三天的用戶數(shù)：首先從每日活躍用戶明細表中，查出最近7天活躍的用戶記錄，并以用戶Id分組對活躍時間排名，然后用活躍時間減去排名，得到的差值數(shù)相同則代表連續(xù)活躍，最后篩選就算出差值相同次數(shù)大于3次的用戶數(shù)，因為可能出現(xiàn)重復問題，最后根據(jù)用戶Id進行分組去重。圖6-157天至少連續(xù)活躍三天的用戶數(shù)系統(tǒng)業(yè)務主題：用戶行為漏斗分析：每日下單數(shù)占訪問數(shù)的比率與每日支付數(shù)占下單數(shù)的比率。首先從用戶行為寬表中計算出下單用戶數(shù)與支付用戶數(shù)（用戶支付與下單次數(shù)大于0，代表用戶當日下單過或支付過），最后連接用戶活躍表得出比率。圖6-16用戶行為漏斗分析GMV：一定時間段的成交總額，包括為已支付訂單與未支付訂單。對用戶行為寬表求和計算出訂單總次數(shù)與總金額。品牌復購率：各個品牌的各一級分類商品復購率。圖6-17品牌復購率6.6數(shù)據(jù)可視化大數(shù)據(jù)分析系統(tǒng)將展示五種分析結果，將使用不同的圖表展示。用戶活躍使用折線圖；用戶留存率使用表格的形式；商品轉化率使用漏斗圖地區(qū)銷量使用地圖；GMV使用折線圖加上柱狀圖。7預期效果大數(shù)據(jù)分析系統(tǒng)所有需求全部開發(fā)完成，效果圖片如下。7.1Hadoop集群圖7-1是Hadoop內置的管理系統(tǒng)，通過50070端口，可以訪問Hadoop后臺系統(tǒng)，查看系統(tǒng)運行狀態(tài)。由LiveNodes發(fā)現(xiàn)大數(shù)據(jù)分析系統(tǒng)三臺子節(jié)點運行正常，且沒有死亡幾點，三臺節(jié)點都成功注冊到Hadoop集群中。管理員可以通過在腳本中執(zhí)行任何方式的檢查來確定節(jié)點是否處于健康狀態(tài)。如果腳本檢測到該節(jié)點處于不正常狀態(tài)，則它必須以標準字符串ERROR開始打印一行錯誤信息到控制臺輸出。NodeManager會定期生成腳本并檢查其輸出。如上所述，如果腳本的輸出包含字符串ERROR，則該節(jié)點的狀態(tài)報告為不正常，并且ResourceManager將其列入黑名單。不會再將其他任務分配到該節(jié)點。但是，NodeManager會繼續(xù)運行該腳本，因此，如果該節(jié)點再次恢復正常，則它將自動從ResourceManager的黑名單節(jié)點中刪除。節(jié)點的運行狀況以及腳本的輸出（如果運行狀況不正常）對于管理員在ResourceManagerWeb界面是可見的。Web界面上還顯示自節(jié)點運行狀況良好以來的時間。圖7-1集群狀況總覽圖圖7-2是HDFS文件系統(tǒng)，可以看出HDFS運行正常。origin_data存放采集來的原始信息,warehouse存放著數(shù)據(jù)倉庫內的數(shù)據(jù)，其中包含四層數(shù)據(jù)，tez存儲著計算任務的狀態(tài)和tag圖。圖7-2HDFS文件系統(tǒng)圖7.2數(shù)據(jù)可視化7.2.1用戶活躍用折線圖展示每日活躍人數(shù)。圖7-3每日用戶活躍數(shù)圖每周活躍人數(shù)，展示七天活躍過的用戶數(shù)。圖7-4每周用戶活躍數(shù)圖每月活躍人數(shù)，展示每月活躍過的用戶數(shù)。圖7-5每月用戶活躍數(shù)圖7.2.2用戶留存率圖7-6是用戶留存率圖，展示了每日的新增用戶，并且在之后的一到七天內是否重新登錄，得出用戶的留存率。圖7-6用戶留存率圖7.2.3商品轉化率漏斗圖展示了瀏覽商品的次數(shù)到下單的數(shù)量再到支付的數(shù)量，之間的轉換關系。通過計算的出三者之間轉化的比率。圖7-7商品轉化漏斗圖7.2.4地區(qū)銷量圖7-8直觀的顯示了每個地區(qū)的商品銷量，可以通過顏色辨別出每個省購買商品次數(shù)，分為6個級別。當鼠標懸浮時還可以展示該省各個市購買商品在該省所占的比率。圖7-8地區(qū)商品銷量圖7.2.5GMVGMV圖使用折線圖加柱狀圖相結合的方式。折線展示總訂單數(shù)量，柱體表示總銷售額。圖7-9GMV統(tǒng)計圖8結束語經(jīng)過大四下整個學期的開發(fā)設計，大數(shù)據(jù)分析系統(tǒng)已全部開發(fā)完畢。該大數(shù)據(jù)分析系統(tǒng)的設計開發(fā)能夠高效分析企